Math Error about 123elf HOT 9 CLOSED

from 123elf.

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

from 123elf.

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!)

from 123elf.

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!

from 123elf.

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

from 123elf.

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)

from 123elf.

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.

from 123elf.

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.

from 123elf.

I added a paragraph to Known Bugs

from 123elf.