Math Error

[rruhle]

Launch 123 from terminal, add numbers below in any cell of new worksheet

32.91-675.19+642.28

Arranged in any order, the sum of these 3 currency values = 0, but -1.1E-13 is shown. You can see a 27-digit fraction if format=(G), column width=30+

-0.000000000000113686837721616

This Error follows similar 3-digit numbers > 500, or when x => 5 as shown below:

32.91-x75.19+x42.28

My version of 123elf has the modified macro-step routine: lotus123r3_1.0-4betajammy_i386.deb

[krackout]

Let me point out that both Python and Lua REPLs give the same result as 123elf.

Nevertheless, 123msdos gives 0 (zero) as a result.

[rruhle]

Thank you, is there a link regarding this issue or progress ?

[taviso]

Hmm, it seems like a normal floating point rounding error - those are just a side effect of how floating point values are stored - but then how does the DOS version avoid it?

We do replace a lot of the old math routines with modern versions so they can make use of modern hardware, maybe we dropped one that does something clever.

Let me see if I can figure out what the DOS version is doing...

(I'm sure @rruhle already knows this, but you can use @ROUND(X, 2) as a workaround if this is breaking a worksheet!)

[taviso]

I notice Google Sheets also gives -1.14E-13, so it seems like 123 DOS must be using some slow but accurate soft fp routines?

I'll investigate, I don't know what the options are yet!

[krackout]

Some more info, from my setup (I'm not certain if they are exactly the same versions):
R4 MS-DOS on dosemu, using Tavis' driver, gives 0 (zero) as a result. R4 MS-DOS on DOSbox, Lotus' vga driver, gives -1.14E-13. It changes 32.91-675.19+642.28 to 32.90999999999999-675.19+642.28

[taviso]

very interesting - I wonder if dosemu reports no math coprocessor present, so 123 uses softfp but DOSbox reports it does have x87 support so 123 uses hardware fp?

If that is the case, we could make it optional. It's hard to believe 123 is using infinite precision, so there are probably other (different) inaccuracies in the software routines too. The only way to avoid them is to use bignums (like gnu mp), which are perfectly accurate but slow and big.

(This is because you cant perfectly store every floating point number, so very small rounding errors can be introduced. This is normally an acceptable trade-off - you get fast, hardware accelerated mathematics that can be stored in a very memory efficient way. The alternative is bignums, which are slow and big and have to be handled in software - but are infinite precision and perfectly accurate)

[taviso]

It seems like Excel also does this: https://en.wikipedia.org/wiki/Numeric_precision_in_Microsoft_Excel

So I think the only question remaining is how R4 in dosemu is avoiding it, just some quick testing seems to suggest it is doing more aggressive rounding.

[krackout]

very interesting - I wonder if dosemu reports no math coprocessor present, so 123 uses softfp but DOSbox reports it does have x87 support so 123 uses hardware fp?

In both DOSbox & dosemu, 80486 is mentioned as coprocessor by 123 (Worksheet -> Status). I think 80486 integrated an FPU.

123elf reports 80387 as math coprocessor.

[taviso]

I added a paragraph to Known Bugs