github.com

Wrote this to learn more about the `chumsky` parser combinator library, rustyline, and the `ariadne` error reporting crate.

Such a nice DX combo for writing new languages.

Still a work in progress, but I thought I'd share :)

34
19
primitivesuave 4 days ago

The UI is awesome, amazing work! However, arbitrary precision implies that there is no fixed upper limit to the number of digits - simple tests like `0.1 + 0.2 == 0.3` and `2^53 == 2^53 + 1` (both produce "false") indicates you're still using IEEE 754 double precision floats.

If "arbitrary precision" is not as important to you as "high precision", a 128 bit decimal has enough precision for 99% of real-world applications.

crap 4 days ago

Thanks for checking it out! Should have been more clear that this is actively being worked on. This is ultimately the goal, and I'm currently working on integrating `astro_float` as the base for numbers.

primitivesuave 3 days ago

That is awesome, I look forward to following the project and hopefully contributing! I became a better Rust programmer from reading your code :)

johannesrexx 2 days ago

Rewrite it like so

> 1/10 + 2/10 == 3/10 true >

jdhwosnhw 3 days ago

Do you mean, the first returns false and the second returns true?

primitivesuave 3 days ago

Ah you're right, thank you for pointing it out!

In the previous version of this comment (where I was still reading it incorrectly) I added a fun fact, that the significand of an IEEE 754 double-precision float is only allocated 52 bits, but the "hidden bit trick" provides an extra bit of precision when the normalized form starts with 1.

crap 3 days ago

Thanks to everyone who gave feedback!

Arbitrary precision is now supported in 0.3.0 after integrating the `astro_float` (https://docs.rs/astro-float/latest/astro_float/index.html) `BigFloat` type as the base for numbers in the language.

Still working out the kinks, but its live so give it a try!

occamatl 4 days ago

> sqrt(10^100)-1 -> 100000000000000000000000000000000000000000000000000

Not what I expected.

emaro 4 days ago

In the readme it says it uses double precision for numbers. Also not quite whet I expected from 'arbitrary precision'.

chriswarbo 4 days ago

Hmm, yeah. It cites `bc` as prior art, which is quite widely used; but another interesting arbitrary-precision calculator is spigot https://www.chiark.greenend.org.uk/~sgtatham/spigot/spigot.h...

emmelaich 3 days ago

Ivy does big numbers (not arbitrary) but does rationals too. It's an APL subset.

    0.1 + 0.2
    3/10
https://github.com/robpike/ivy

lttlrck 3 days ago

the addition of astro_float fixed this.

jasonjmcghee 4 days ago

Hey nice! We have similar interests. I built something similar, but with way less calculator functionality than you did :D

But the main idea I was going for was real-time JIT evaluation with rendered errors (specifically learning / using cranelift JIT) - less to do with the calculator aspect.

I ended up choosing miette for errors.

https://github.com/jasonjmcghee/basic-treesitter-cranelift-j...

lttlrck 3 days ago

This is cool.

It love to have to base conversion functions, even if it's print only. Does that fit at all?

crap 3 days ago

This definitely fits, base conversion is on the roadmap!

lttlrck 3 days ago

and different input base notations, 0x, o, 0b etc

librasteve 2 days ago

very cool, welcome to the small club of CLI calculator authors! before I read this I knew of frink and crag (https://raku.land/zef:librasteve/App::Crag since you ask)

Crag is built on raku so has some neat tricks up its sleeve - you can see Crag of the Day to see some in action...

  crag '0.1+0.2=0.2'   #True (arbitrary precision)
  crag '₃₆123.45'      #3F.G77777  (base 36)
  crag 'e ** (i * π) =~= -1'   #True  (math symbols, complex numbers)
  crag '0rMCMXLIV'     #1944 (Roman numerals)
  crag '^<௪௨ mph>'     #42mph  (Unicode and units)
hee hee

I_complete_me 4 days ago

I wish you well. And I clicked you a star on github. Keep up the good work.