Also note that I believe a similar issue is already in the Linux Debian bug database on GST. Are you using Debian and if not so, what kind of Linux ?
On Solaris, in GNU smalltalk I'm using a 32bit version of GST and I get: st> 1.234567890q0 1.23456789 st> 1.23456789123456789q0 1.23456789123456789 st> 1.2345678987654321d0 1.234567898765432 st> 1e-4 0.00001 st> 1e-5 0.00001 st> 1e-3 0.001 st> .1d0 stdin:7: expected expression st> .1d0 stdin:8: expected expression st> 0.1d0 0.1 st> 1.23456789123456789d0 1.234567891234568 Note that the result 1e-5 and 1e-4 are the same for me , but this is not a problem for internal arithmetic. The internal representation is OK (and arithmetic on the objects is also OK); I think this is somewhere some issue in the external printing routines "displaying" the internal representation / converting it to output format. Regards, David Stes ----- Op 13 feb 2021 om 18:08 schreef David G. Pickett davidgpick...@comcast.net: > Running gst on Linux, the blizzard of math errors and invalid exceptions > is a real disgrace. Just entering numbers makes it disgrace itself: > > dgp@dgp-p6803w:~ > $ (cd smalltalk-3.2.91 ; ./gst) > GNU Smalltalk ready > > st> 1.234567890q0 > 1.23456789 > st> 1.23456789123456789q0 > 1.253 > st> 1.2345678987654321d0 > 1.23456789876501 > st> 1e-4 > 0.00001 > st> 1e-5 > 0.0000063715563 > st> 1e-3 > 0.001 > st> .1d0 > stdin:7: expected expression > st> 0.1d0 > 0.1 > st> 1.23456789123456789d0 > 1.35236 > st>
