Feature: Infinite length integers

[n1ywb-1]

@brianharvey mentioned this is high on his wishlist

C23 adds the _BitInt() type macro for arbitrary size ints; supported by clang and GCC 14; BITINT_MAXWIDTH 8388608 on clang. BitInts support all the normal integer operations. Standard library support isn't quite there yet and the ABI is unstable, but those aren't necessarily blockers.

typedef unsigned _BitInt(1024) uint1024_t;
uint1024_t a = eleventyquintillion;

Python has a highly optimized arbitrary length integer implementation. It's written in portable C that we could probably adapt to our needs. We would have to keep their GPL-compatible license on whatever files we ganked https://docs.python.org/3/license.html#python-software-foundation-license-version-2

There's also https://gmplib.org/ "GNU MP is a portable library written in C for arbitrary precision arithmetic on integers, rational numbers, and floating-point numbers. It aims to provide the fastest possible arithmetic for all applications that need higher precision than is directly supported by the basic C types."

Or roll our own.

[brianharvey]

Yeah, I've been assuming we'd use the GNU one. Last time I actually looked into it, it was just for integers. If we can support the entire Scheme numeric tower, that would be awesome. (But they don't include complex numbers in that description...?)

Aside from doing the arithmetic itself, there are syntax issues to consider if we support exact rationals and complex numbers:

Welcome to Berkeley Logo version 6.2.4(version_6.2.4rc1-1-g1eaef7d)
? make "2/3 9
? pr :2/3
2 has no value
? pr thing "2/3
9
? make 5/6 23
? pr thing 5/6
23
? pons
Make "0.833333333333333 23
Make "2/3 9
? make 3+4i 99
I don't know how  to 4i
? make "3i 7
? pr :3i
7
? make "0+i 87
? pr :0+i
0 has no value
? pr :0\+i
87
? 

We might want to reject those MAKE instructions, although maybe not, since we currently let you use an integer as a variable name. But if not, then we'd want to change the tokenization rule following a colon. If you can use a number as a variable name, that should work consistently.

Also, turtle graphics would have to know how to round exact rationals to integer pixel coordinates. And we'd have to reject turtle coordinates with a nonzero imaginary part. Although I suppose if someone uses a drone as a turtle the imaginary part could mean how high off the ground to move. :)

Exact rational and complex support is something we'd want to let users turn off and on, probably defaulting to off, not just because of the tokenization issue but because Logo's main target audience of little kids would be confused. Depending on just how much it slows us down, we might just always support bignums, though.

[n1ywb-1]

We could reuse parts of GNU Guile, if you think it supports all that. I'm not sure how you feel about incorporating 3rd party code, but it's GPL like us. Sub-pixel coordinates are on my personal wishlist since SVG coords are floating point and it supports subpixel rendering. Ironically the turtle->.svg-file logo program I wrote outputs floats, since that's what `pos` returns. I may hack this in for the web port. I take it you're kidding about the drone, but I built this when I was a kid [image: image.png]

…

On Wed, Apr 2, 2025 at 12:04 AM Brian Harvey ***@***.***> wrote: Yeah, I've been assuming we'd use the GNU one. Last time I actually looked into it, it was just for integers. If we can support the entire Scheme numeric tower, that would be awesome. (But they don't include complex numbers in that description...?) Aside from doing the arithmetic itself, there are syntax issues to consider if we support exact rationals and complex numbers: Welcome to Berkeley Logo version 6.2.4(version_6.2.4rc1-1-g1eaef7d) ? make "2/3 9 ? pr :2/3 2 has no value ? pr thing "2/3 9 ? make 5/6 23 ? pr thing 5/6 23 ? pons Make "0.833333333333333 23 Make "2/3 9 ? make 3+4i 99 I don't know how to 4i ? make "3i 7 ? pr :3i 7 ? make "0+i 87 ? pr :0+i 0 has no value ? pr :0\+i 87 ? We might want to reject those MAKE instructions, although maybe not, since we currently let you use an integer as a variable name. But if not, then we'd want to change the tokenization rule following a colon. If you can use a number as a variable name, that should work consistently. Also, turtle graphics would have to know how to round exact rationals to integer pixel coordinates. And we'd have to reject turtle coordinates with a nonzero imaginary part. Although I suppose if someone uses a drone as a turtle the imaginary part could mean how high off the ground to move. :) Exact rational and complex support is something we'd want to let users turn off and on, probably defaulting to off, not just because of the tokenization issue but because Logo's main target audience of little kids would be confused. Depending on just how much it slows us down, we might just always support bignums, though. — Reply to this email directly, view it on GitHub <#214 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BP756A5F3CXY437LB4XWJCD2XNOWHAVCNFSM6AAAAAB2IHWCJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZRGI4DIOBYGE> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: brianharvey]*brianharvey* left a comment (jrincayc/ucblogo-code#214) <#214 (comment)> Yeah, I've been assuming we'd use the GNU one. Last time I actually looked into it, it was just for integers. If we can support the entire Scheme numeric tower, that would be awesome. (But they don't include complex numbers in that description...?) Aside from doing the arithmetic itself, there are syntax issues to consider if we support exact rationals and complex numbers: Welcome to Berkeley Logo version 6.2.4(version_6.2.4rc1-1-g1eaef7d) ? make "2/3 9 ? pr :2/3 2 has no value ? pr thing "2/3 9 ? make 5/6 23 ? pr thing 5/6 23 ? pons Make "0.833333333333333 23 Make "2/3 9 ? make 3+4i 99 I don't know how to 4i ? make "3i 7 ? pr :3i 7 ? make "0+i 87 ? pr :0+i 0 has no value ? pr :0\+i 87 ? We might want to reject those MAKE instructions, although maybe not, since we currently let you use an integer as a variable name. But if not, then we'd want to change the tokenization rule following a colon. If you can use a number as a variable name, that should work consistently. Also, turtle graphics would have to know how to round exact rationals to integer pixel coordinates. And we'd have to reject turtle coordinates with a nonzero imaginary part. Although I suppose if someone uses a drone as a turtle the imaginary part could mean how high off the ground to move. :) Exact rational and complex support is something we'd want to let users turn off and on, probably defaulting to off, not just because of the tokenization issue but because Logo's main target audience of little kids would be confused. Depending on just how much it slows us down, we might just always support bignums, though. — Reply to this email directly, view it on GitHub <#214 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BP756A5F3CXY437LB4XWJCD2XNOWHAVCNFSM6AAAAAB2IHWCJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZRGI4DIOBYGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- --Jeff

[n1ywb-1]

Maybe a flying turtle isn't the best idea, but how about 3d printing? On Wed, Apr 2, 2025 at 10:07 PM Jeff Laughlin ***@***.***> wrote:

…

We could reuse parts of GNU Guile, if you think it supports all that. I'm not sure how you feel about incorporating 3rd party code, but it's GPL like us. Sub-pixel coordinates are on my personal wishlist since SVG coords are floating point and it supports subpixel rendering. Ironically the turtle->.svg-file logo program I wrote outputs floats, since that's what `pos` returns. I may hack this in for the web port. I take it you're kidding about the drone, but I built this when I was a kid [image: image.png] On Wed, Apr 2, 2025 at 12:04 AM Brian Harvey ***@***.***> wrote: > Yeah, I've been assuming we'd use the GNU one. Last time I actually > looked into it, it was just for integers. If we can support the entire > Scheme numeric tower, that would be awesome. (But they don't include > complex numbers in that description...?) > > Aside from doing the arithmetic itself, there are syntax issues to > consider if we support exact rationals and complex numbers: > > Welcome to Berkeley Logo version 6.2.4(version_6.2.4rc1-1-g1eaef7d) > ? make "2/3 9 > ? pr :2/3 > 2 has no value > ? pr thing "2/3 > 9 > ? make 5/6 23 > ? pr thing 5/6 > 23 > ? pons > Make "0.833333333333333 23 > Make "2/3 9 > ? make 3+4i 99 > I don't know how to 4i > ? make "3i 7 > ? pr :3i > 7 > ? make "0+i 87 > ? pr :0+i > 0 has no value > ? pr :0\+i > 87 > ? > > We might want to reject those MAKE instructions, although maybe not, > since we currently let you use an integer as a variable name. But if not, > then we'd want to change the tokenization rule following a colon. If you > can use a number as a variable name, that should work consistently. > > Also, turtle graphics would have to know how to round exact rationals to > integer pixel coordinates. And we'd have to reject turtle coordinates with > a nonzero imaginary part. Although I suppose if someone uses a drone as a > turtle the imaginary part could mean how high off the ground to move. :) > > Exact rational and complex support is something we'd want to let users > turn off and on, probably defaulting to off, not just because of the > tokenization issue but because Logo's main target audience of little kids > would be confused. Depending on just how much it slows us down, we might > just always support bignums, though. > > — > Reply to this email directly, view it on GitHub > <#214 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BP756A5F3CXY437LB4XWJCD2XNOWHAVCNFSM6AAAAAB2IHWCJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZRGI4DIOBYGE> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > [image: brianharvey]*brianharvey* left a comment > (jrincayc/ucblogo-code#214) > <#214 (comment)> > > Yeah, I've been assuming we'd use the GNU one. Last time I actually > looked into it, it was just for integers. If we can support the entire > Scheme numeric tower, that would be awesome. (But they don't include > complex numbers in that description...?) > > Aside from doing the arithmetic itself, there are syntax issues to > consider if we support exact rationals and complex numbers: > > Welcome to Berkeley Logo version 6.2.4(version_6.2.4rc1-1-g1eaef7d) > ? make "2/3 9 > ? pr :2/3 > 2 has no value > ? pr thing "2/3 > 9 > ? make 5/6 23 > ? pr thing 5/6 > 23 > ? pons > Make "0.833333333333333 23 > Make "2/3 9 > ? make 3+4i 99 > I don't know how to 4i > ? make "3i 7 > ? pr :3i > 7 > ? make "0+i 87 > ? pr :0+i > 0 has no value > ? pr :0\+i > 87 > ? > > We might want to reject those MAKE instructions, although maybe not, > since we currently let you use an integer as a variable name. But if not, > then we'd want to change the tokenization rule following a colon. If you > can use a number as a variable name, that should work consistently. > > Also, turtle graphics would have to know how to round exact rationals to > integer pixel coordinates. And we'd have to reject turtle coordinates with > a nonzero imaginary part. Although I suppose if someone uses a drone as a > turtle the imaginary part could mean how high off the ground to move. :) > > Exact rational and complex support is something we'd want to let users > turn off and on, probably defaulting to off, not just because of the > tokenization issue but because Logo's main target audience of little kids > would be confused. Depending on just how much it slows us down, we might > just always support bignums, though. > > — > Reply to this email directly, view it on GitHub > <#214 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BP756A5F3CXY437LB4XWJCD2XNOWHAVCNFSM6AAAAAB2IHWCJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZRGI4DIOBYGE> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > -- --Jeff

-- --Jeff

[brianharvey]

I'm not sure how you feel about incorporating 3rd party code

That boat sailed when we started using wxWidgets! :)

[jrincayc]

Hm, adding 3rd party code depends on the license (GPL3 should be fine). I would like to minimize hard dependencies (as in dependencies that every UCBLogo configuration needs). wxWidgets is a soft dependency since X11 can be compiled without it (and presumably WASM soon as well).

[n1ywb-1]

the wasm port does not depend on wx, because, sadly, wx is not supported on wasm. There is an aborted port kicking around...

I agree on minimizing hard dependencies, it seems wise given the nature of this project. That's why I'm doing the web app in vanilla JS instead of using a heavy framework that sucks in 300 useless NPM packages that will be abandoned next year.

[brianharvey]

Two things:

1. As it says up at the top of this thread, native JS support for bignums is supposedly right around the corner. So, we could just wait.

2. For what it's worth, Snap! uses schemeNumber.js by John Tobey, because it also supplies exact rationals and complex numbers. If we wanted to do that, we'd have to think about the syntax of / and + respectively.

[n1ywb-1]

JS bignum doesn't help WX builds... unless we build JS into Logo... which is not actually that hard...

If this is something we want to explore I'd suggest https://bellard.org/quickjs/

I've used it to develop against the Minecraft Bedrock API; it's a pretty normal JS environment. It's slow compared to V8 (node, chrome), but they don't have Google's budget for optimization. It's main advantage is that it's small and simple with no dependencies and low memory usage. It's written in portable C.

QuickJS is a small and embeddable Javascript engine. It supports the ES2023 specification including modules, asynchronous generators, proxies and BigInt.

It optionally supports mathematical extensions such as big decimal floating point numbers (BigDecimal), big binary floating point numbers (BigFloat) and operator overloading.

Small and easily embeddable: just a few C files, no external dependency, 210 KiB of x86 code for a simple hello world program.

[n1ywb-1]

QuickJS has a few other features of potential interest

QuickJS embeds the following C libraries which can be used in other projects:
libregexp: small and fast regexp library fully compliant with the Javascript ES2023 specification.
libunicode: small unicode library supporting case conversion, unicode normalization, unicode script queries, unicode general category queries and all unicode binary properties.
libbf: small library implementing arbitrary precision IEEE 754 floating point operations and transcendental functions with exact rounding. It is maintained as a separate project.