-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simple multiplication gets wrong answer #403
Comments
Here's another example: CL-USER> (* 99999995 99999995) The last digit should be a 5. |
JSCL represents all numbers as Javascript "number" (floats). There is no distinction between floats and integer, and no bignums. This was a more unavoidable limitation when we started JSCL. Nowadays it would be feasible to use Javascript bigints when possible to differentiate them from But it does require a bit of work on the compiler! It sounds like a fun project for sure. An open question is if using bigint would have bad performance implications or if the engines optimize for small bigints :-) We could make it optional by (at least temporarily) using some constructors for numbers with something like |
I'm not a JS coder, so I was unaware of this limitation. The math should be coded instead of using "default" JS constructs once the numbers reach that tipping point, I suppose. It probably means there are a lot more examples like this, and probably examples that are off by more than one digit. |
Indeed. Luckily there is a way foward now at least! Until then though, anything that goes out of this range will be wrong:
and functions like It's surprising how lot of code does still work considering those issues 🙂 |
Ugu;) Artifacts: CL-USER> (floatp 1.0)
NIL
CL-USER> (floatp 1.00000000001)
T
CL-USER> (floatp 1.000000000001)
T
CL-USER> (floatp 1.000000000000001)
T
CL-USER> (floatp 1.0000000000000001)
NIL sbclCL-USER> (1+ (expt 2 53))
9007199254740993
CL-USER> (expt 2 53)
9007199254740992 jsclCL-USER> (1+ (expt 2 53))
9007199254740992
CL-USER> (expt 2 53)
9007199254740992 |
I opened a WIP pull request to see what bignum support might look like at #404 |
(* 123456789 123456789)
15241578750190520
The answer should be 15241578750190521.
The text was updated successfully, but these errors were encountered: