4 ms·

Show HN: val – An arbitrary precision calculator language

34 points by crap 1y ago

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 :)

jasonjmcghee 1y 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-jit https://github.com/jasonjmcghee/basic-treesitter-cranelift-j...
occamatl 1y ago
> sqrt(10^100)-1 -> 100000000000000000000000000000000000000000000000000 Not what I expected.
- emaro 1y ago
  In the readme it says it uses double precision for numbers. Also not quite whet I expected from 'arbitrary precision'.
  - chriswarbo 1y 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.html https://www.chiark.greenend.org.uk/~sgtatham/spigot/spigot.h...
    - mananaysiempre 1y ago
      Also the AOSP calculator, of course[1,2,3]. [1] https://chadnauseam.com/coding/random/calculator-app https://chadnauseam.com/coding/random/calculator-app [2] https://dl.acm.org/doi/10.1145/2911981 https://dl.acm.org/doi/10.1145/2911981 [3] https://dl.acm.org/doi/10.1145/3385412.3386037 https://dl.acm.org/doi/10.1145/3385412.3386037
      - emmelaich 1y 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 https://github.com/robpike/ivy
- lttlrck 1y ago
  the addition of astro_float fixed this.
primitivesuave 1y 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 1y 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 1y ago
    That is awesome, I look forward to following the project and hopefully contributing! I became a better Rust programmer from reading your code :)
- jdhwosnhw 1y ago
  Do you mean, the first returns false and the second returns true?
  - primitivesuave 1y 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.
- johannesrexx 1y ago
  Rewrite it like so > 1/10 + 2/10 == 3/10 true >
I_complete_me 1y ago
I wish you well. And I clicked you a star on github. Keep up the good work.
crap 1y 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 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!
lttlrck 1y ago
This is cool. It love to have to base conversion functions, even if it's print only. Does that fit at all?
- lttlrck 1y ago
  and different input base notations, 0x, o, 0b etc
- crap 1y ago
  This definitely fits, base conversion is on the roadmap!
Randomizerr 1y ago
[dead]
librasteve 1y 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 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

34 points by crap 1y ago

jasonjmcghee 1y 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-jit https://github.com/jasonjmcghee/basic-treesitter-cranelift-j...

occamatl 1y ago

> sqrt(10^100)-1 -> 100000000000000000000000000000000000000000000000000 Not what I expected.

emaro 1y ago
In the readme it says it uses double precision for numbers. Also not quite whet I expected from 'arbitrary precision'.
- chriswarbo 1y 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.html https://www.chiark.greenend.org.uk/~sgtatham/spigot/spigot.h...
  - mananaysiempre 1y ago
    Also the AOSP calculator, of course[1,2,3]. [1] https://chadnauseam.com/coding/random/calculator-app https://chadnauseam.com/coding/random/calculator-app [2] https://dl.acm.org/doi/10.1145/2911981 https://dl.acm.org/doi/10.1145/2911981 [3] https://dl.acm.org/doi/10.1145/3385412.3386037 https://dl.acm.org/doi/10.1145/3385412.3386037
    - emmelaich 1y 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 https://github.com/robpike/ivy
lttlrck 1y ago
the addition of astro_float fixed this.

primitivesuave 1y 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 1y 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 1y ago
  That is awesome, I look forward to following the project and hopefully contributing! I became a better Rust programmer from reading your code :)
jdhwosnhw 1y ago
Do you mean, the first returns false and the second returns true?
- primitivesuave 1y 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.
johannesrexx 1y ago
Rewrite it like so > 1/10 + 2/10 == 3/10 true >

I_complete_me 1y ago

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

crap 1y 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 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!

lttlrck 1y ago

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

lttlrck 1y ago
and different input base notations, 0x, o, 0b etc
crap 1y ago
This definitely fits, base conversion is on the roadmap!

Randomizerr 1y ago

[dead]

librasteve 1y 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 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