primitivesuave 2 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 2 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 a day 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 11 hours ago

    Rewrite it like so

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

  • jdhwosnhw a day ago

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

    • primitivesuave a day 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 2 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 2 days ago

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

Not what I expected.

jasonjmcghee 2 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...

librasteve 5 hours 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
lttlrck a day ago

This is cool.

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

  • crap 20 hours ago

    This definitely fits, base conversion is on the roadmap!

  • lttlrck a day ago

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

I_complete_me 2 days ago

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