I have tickled bugs in numeric computation in both the squeak and the java implementations, using the e^x computation in my RPN calculator
http://scratch.mit.edu/projects/kevin_karplus/2164
The java implementation truncates results of e^x at a ridiculously low value (around e^41.366), while the squeak implementation works well up to a reasonable level, but crashes when you try e^1000
Neither the low truncation nor the crash are really acceptable results.
I was going to implement a more efficient e^x operation for large values of x, but there is really not much point if multiplication is not done correctly for large numbers.
Incidentally, the RPN calculator also shows how badly broken the variable display boxes are for large numbers (those that get show in scientific notation).
I'd really like to have the ability to control the variable display style---I particularly like the "engineering" notation available on HP calculators, where you have only powers of 1000. A number like 345678 is displayed as 345.678E+03
Offline
Hi, Kevin.
Problem noted. I'm pretty sure we can fix the large number crash in the Squeak implementation. I'm not sure what's going on with the Java implementation--should be good up to the precions of a double but perhaps a "float" variable crept in for some intermediate result.
-- John
Offline
The truncated value on the Java implementation is too small even for a float.
MAX_VALUE for float in java is 3.40282346638528860e+38.
(according to http://tns-www.lcs.mit.edu/manuals/java-api-1.1beta2/api/java.lang.Float.html#MAX_VALUE
)
Offline
The bug in java is just in the display of the variables, not in the calculation.
(Try squaring several times until the value maxes out, then square roots to get back---the computation comes out right, so the clipping is just a display bug.)
The variable display in both squeak and java is terribly buggy for numbers large enough to be displayed in scientific notation. The alignment and boundaries of the display windows get totally messed up.
Offline