Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

sur-behoffski
G'Day,

[Sorry for not replying within the relevant thread, but I read the list
use digest mode.  Apologies if this offends anyone.]

I managed publish an article in the November 1997 edition of Dr. Dobb's
Journal.  In that same edition, was an extended interview with Prof.
William Kahan, entitled "A Conversation with William Kahan":

         http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/1997/9711/9711a/9711a.htm

IMHO, the entire Kahan article is well worth reading.

I'll pick out a couple comments about the difference between abstract/simple
formulas, versus complicated, but numerically stable algorithms, and end
with a longish extract about different rounding modes that the standard
lets the program(mer) select, and why being able to select the rounding
mode at runtime may be valuable:

--

         [...]
         DDJ: What should we programmers be learning?

         WK: What you should be learning are things from numerical-analysis
         classes, such as why the less accurate of two ways of calculating a
         function may be perfectly satisfactory for engineering work.  But I
         also tell programmers that argument [such as on the phone with
         customers] takes time and money, and since we know a way to do it
         which will circumvent the necessity for argument, by all means do
         it that way, if you can. You can dispense with the necessity of
         trying to persuade somebody of something which is, in fact, true --
         that two methods are just as good as one another, but which they
         have every right to disbelieve. There are all sorts of folks who
         tell you, "It's okay, this is just as good," and are wrong.

         Let's calculate accuracy well out of proportion with what anybody
         actually needs. They don't need it, but it doesn't matter. We'll do
         it that way and then there won't be any argument.

         [...]

--

About the difference between "intellectually economical" and simple:

--
         [...]

         DDJ: So what should our industry be doing?

         WK: I think it was Churchill who once said something about the
         essence of leadership being figuring out where people are going to
         go anyway and getting there ahead of them. The industry, in its
         own best interests, has to take a role that leads the customers,
         but not by too much. When it comes to numerical things, part of
         leadership is to provide an intellectually economical numerical
         ambiance.

         "Intellectually economical" doesn't necessarily mean simple. We
         have to understand the various arenas in which people want to
         depend upon computers. We have to understand them in some ways
         better than the customers. The customers don't always understand
         the issues because they are preoccupied with what matters to
         them, not with the design and construction of the systems upon
         which they depend.

         It's like being engaged in sewer repair. The art of sewer repair
         is to do it in such a fashion so as not to oblige others to think
         about it at all. If you have to think about it, the sewer
         repairmen haven't been doing their job.

         DDJ: So we programmers are not doing our job?

         WK: That's correct. It is straightforward to implement numerics
         better. I've written about it in a number of places. Look at my
         article about miscalculating the area and angles of a triangle at:

                 http://http.cs.berkeley.edu/~wkahan/Triangle.ps

         There's an abstract there that points to a number of
         misconceptions or superstitions. It doesn't seem to me to be all
         that difficult for the compiler community to serve these needs.

         If the industry gets far enough down a certain path, it can't
         turn, never mind go back! [...]

--

And, finally, some specific comments on why multiple different rounding
modes were mandated in the IEEE standard:

--

         WK: [...] But if you get rid of a [preprocessor] expression when
         someone has written it in cold blood, you're changing the
         semantics of his program.

         Similar are things like constant folding. You (the optimizer)
         look at an expression and decide, "Oh, this is a constant, so I
         can compute it at compile time." But maybe that expression was
         designed for a different rounding mode at run time than the one
         which prevails at compile time. There are reasons to change the
         rounding mode without mentioning it.

         There's all sorts of stuff in the IEEE Standard designed to help
         ordinary people do things like diagnose what may be screwing
         them in a module they got from someone else. Perhaps there's an
         algorithm that is pretty good for almost all data except yours.
         It doesn't know you personally, you understand! Your data just
         happens to be the kind that that particular algorithm doesn't
         like. How do you find out if this is the case?

         One way is to change the rounding mode, which will create
         different rounding errors. This identifies modules where it
         might be worth your time to investigate. If you didn't have this
         ability to change the rounding mode, you might not have any other
         way to identify which module among many supplied by
         multiple vendors was the likely candidate for further
         investigation.

         In any army, there's a soldier who doesn't get the message.  DEC
         Alpha decided to put the rounding mode not in a control word
         alone, but also in the opcode. That means that when you compile,
         you can compile the rounding modes in such a way that they don't
         respond to a change of control word setting, and therefore, when
         you rerun the code with the changed control word, you're going
         to get the same results as before.

         It isn't that this was a bad idea, to put the rounding mode in
         the opcode as well as the control word. The mistake was that they
         put the default rounding mode into the opcode. The default should
         have been left in the control word.

         [...]

--

I have to sheepishly admit that 99.9% of Numerical Methods are above my
head, but I'm glad that I've come to know about Prof. Kahan's work and
his very careful, but also accessible, writings about computerised
numerical computation.

I hope that this post is of value in the context of the recent/ongoing
discussion(s) about rounding modes, and their interaction with proposals
to set rounding modes for single/double/extended precision in Lua.

cheers,

sur-behoffski (Brenton Hoff)
programmer, Grouse Software

Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Albert Chan
On Jun 10, 2018, at 8:54 AM, sur-behoffski <[hidden email]> wrote:

> I managed publish an article in the November 1997 edition of Dr. Dobb's
> Journal.  In that same edition, was an extended interview with Prof.
> William Kahan, entitled "A Conversation with William Kahan":
>        http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/1997/9711/9711a/9711a.htm
>
> IMHO, the entire Kahan article is well worth reading.

I thoroughly enjoy the read, highly recommended.

Kahan excerpt from above:

"I don't feel that the architects of Java are wicked so much as premature
to think that they can write a universal language for every man to write
everything to run everywhere. That isn't going to happen, it's going to be
a turf war -- Bill Joy against Bill Gates. It's a lousy reason to write a
language, to write it in order to precipitate a turf war to bring things into
a territory more advantageous to Sun than the current situation."

I am reading another Kakan article on Java and IEEE (not yet finished).
It seems there is good reason even for sign of zero. (+/- 0.0)

IEEE people certainly know what they are doing ...

https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

p.s.
my naming of thread maybe misleading.
I was only proposing a *default* precision setting.


Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Hugo Musso Gualandi
In reply to this post by sur-behoffski
Thanks for the references, I found them very interesting.

By the way, the link to Prof. Kahan's article on miscalculating the
areas and angles of triangles has moved. It can now be found at:

    http://http.cs.berkeley.edu/~wkahan/Triangle.pdf

-- Hugo

Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Hugo Musso Gualandi
In reply to this post by sur-behoffski
Thanks for the references, I found them very interesting.

By the way, the link to Prof. Kahan's article on miscalculating the
areas and angles of triangles has moved. It can now be found at:

    http://http.cs.berkeley.edu/~wkahan/Triangle.pdf

-- Hugo

Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Albert Chan

> By the way, the link to Prof. Kahan's article on miscalculating the
> areas and angles of triangles has moved. It can now be found at:
>
>    http://http.cs.berkeley.edu/~wkahan/Triangle.pdf
>
> -- Hugo

Thanks.  I just think of another way to reduce error,
for calculating the area of the needle-like triangle.

I use another IEEE double property.
If value is integer 53 bits or less, add, subtract, multiply is *exact*
Sorry if it sound obvious to everyone, it is stated in PIL on Numbers

Example, Above article, Table 1 (line 3) sides of triangle:
a, b, c = 1e5, 99999.99979, 0.00029

This is the classic Heron formula for triangle area:
Area = sqrt(s * (s-a) * (s-b) * (s-c)),  where s = (a + b + c) / 2

Instead of plugging in the numbers, just scaled it so all values
are integers.  Scale by 1e5:  a,b,c = 1e10, 9999999979, 29

Area (scaled) = sqrt(10000000004 * 4 * 25 * 9999999975)
= 99999999895

Undo scaling: Area = 99999999895 / 1e10 = 9.9999999895

BTW, the article stated that heron formula return area = 17.6
I cannot reproduce it (even adjusting precision with gmpy2)

Anyone still have the old HP-15C calculator ?


Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Albert Chan
Thanks Hartmut for the HP-15C test. 
It seems HP-15C does *decimal* math, 10 significant digits, half-round-up

s = (a + b + c) / 2
= (1e5 + 99999.99979 + 0.00029) / 2
= (199999.9998 + 0.00029) / 2   -- round up
= 200000.0001 / 2                         -- round up again
= 100000.0001                               -- half-round-up

I have never seen a calculator like this ...
With this, I match your area result of 17.60681685 exactly.

On Jun 12, 2018, at 5:38 PM, Hartmut Henkel <[hidden email]> wrote:

On Tue, 12 Jun 2018, Albert Chan wrote:

BTW, the article stated that heron formula return area = 17.6
I cannot reproduce it (even adjusting precision with gmpy2)

Anyone still have the old HP-15C calculator ?

yes :-) Keys still without bouncing, bright LCD, that's quality.

FWIW, my HP-15C tells 17.60681685 using the first formula in §1 on the
3rd example in Table 1, just tried. Else i have not followed the thread.

The 17.6 error comes from s: When it's 100000.000039999998989515
(Lua), Delta is 9.999999809638328685. But the HP-15C shows
 s=<a dir="ltr" href="tel:100000.0001" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="2" style="background-color: rgba(255, 255, 255, 0);">100000.0001, then it's 17.6068..., which you can confirm wit Lua.

 Best Regards, Hartmut
Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Dirk Laurie-2
2018-06-13 2:13 GMT+02:00 Albert Chan <[hidden email]>:

> Thanks Hartmut for the HP-15C test.
> It seems HP-15C does *decimal* math, 10 significant digits, half-round-up
>
> s = (a + b + c) / 2
> = (1e5 + 99999.99979 + 0.00029) / 2
> = (199999.9998 + 0.00029) / 2   -- round up
> = 200000.0001 / 2                         -- round up again
> = 100000.0001                               -- half-round-up
>
> I have never seen a calculator like this ...

I have an HP41C, but it no longer works. I can recall, however, that
it correctly evaluated 1e97 mod 97. Default Lua 5.3 on my machine says
"1e97"%"97" is 3, which is wrong. Lua 5.3 built as `make linux -e
MYCFLAGS=-DLUA_NOCVTS2N` and with a module supplying appropriate
string metamethods, gets it right. My much more modern calculator of a
different brand also gets it wrong.)

Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Viacheslav Usov
On Tue, Jun 26, 2018 at 11:52 AM Dirk Laurie <[hidden email]> wrote:

>  1e97 mod 97

[...]

> My much more modern calculator of a different brand also gets it wrong.)

The Windows (8.1, 10) calculator app produces 10. This is also the case with the stock calculator app on a Windows phone I bought a couple of years ago for less than USD 200. The Windows calculator is actually an amazingly good job, despite its drab appearances [1].

The stock PowerShell interpreters on those Windows systems and Python 3.6.5, all produce 3, even though I tried to convince them to use their big int facilities. But I am not too fluent with those, so perhaps that can still be done.

The stock claculator app on a a recent iPhone that costs more than any piece of hardware mentioned above does not have the Mod operator in its advanced mode :) That was also the case with the most popular calculator app I tried in AppStore. I have not tried more of them.

Cheers,
V.


Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Javier Guerra Giraldez
On 26 June 2018 at 12:42, Viacheslav Usov <[hidden email]> wrote:
> On Tue, Jun 26, 2018 at 11:52 AM Dirk Laurie <[hidden email]> wrote:
>
>>  1e97 mod 97

> The stock PowerShell interpreters on those Windows systems and Python 3.6.5,
> all produce 3, even though I tried to convince them to use their big int
> facilities. But I am not too fluent with those, so perhaps that can still be
> done.

python: 10**97 % 97

same in bc:  10^97 % 97



--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Viacheslav Usov
On Tue, Jun 26, 2018 at 3:29 PM Javier Guerra Giraldez <[hidden email]> wrote:

> python: 10**97 % 97

Hmm. But why not 1e97 % 97? Ah, it produces a floating point value, silly me :)

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Albert Chan
In reply to this post by Dirk Laurie-2

> On Jun 26, 2018, at 5:52 AM, Dirk Laurie <[hidden email]> wrote:
>
> I have an HP41C, but it no longer works. I can recall, however, that
> it correctly evaluated 1e97 mod 97. Default Lua 5.3 on my machine says
> "1e97"%"97" is 3, which is wrong.

HP41C does BCD math, "1e97" converted to 10^97 (nice ...)

HP41C must have a dedicated MOD key.
Otherwise, x % y == x - int(x / y) * y will likely loses all precision.

Lua convert "1e97" to hexfloat = 0x1.2ba095dc7701ep+322
Since Lua can only see the hexfloat, 3 is also right (w/ hexfloat)
Wrong result is due to strtod error, trying to fit "1e97" to 53 bits.

To confirm: I use my rpn: https://github.com/achan001/MAPM-5

> rpn
1e97 g 97 % ?     # Lua way, g = exact hexfloat
3

1e97 97 % ?        # HP41C way
10

I just downloaded WP31s *FREE* app to my ipad.
It does BCD math (16 decimal digits, halfway round-to-even)

WP31s: 1e97 ENTER 97 f-MORE MOD ==> 10

Since 97 is prime, 10 ^ 97 % 97 = 10 (Fermat little theorem)
--> HP41C and WP31s both get the mod right.



Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Sean Conner
In reply to this post by Dirk Laurie-2
It was thus said that the Great Dirk Laurie once stated:

> 2018-06-13 2:13 GMT+02:00 Albert Chan <[hidden email]>:
> > Thanks Hartmut for the HP-15C test.
> > It seems HP-15C does *decimal* math, 10 significant digits, half-round-up
> >
> > s = (a + b + c) / 2
> > = (1e5 + 99999.99979 + 0.00029) / 2
> > = (199999.9998 + 0.00029) / 2   -- round up
> > = 200000.0001 / 2                         -- round up again
> > = 100000.0001                               -- half-round-up
> >
> > I have never seen a calculator like this ...
>
> I have an HP41C, but it no longer works. I can recall, however, that
> it correctly evaluated 1e97 mod 97. Default Lua 5.3 on my machine says
> "1e97"%"97" is 3, which is wrong. Lua 5.3 built as `make linux -e
> MYCFLAGS=-DLUA_NOCVTS2N` and with a module supplying appropriate
> string metamethods, gets it right. My much more modern calculator of a
> different brand also gets it wrong.)

[spc]lucy:~>lua-51
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> print(1e97 % 97)
-8.8928324534259e+79
>
[spc]lucy:~>lua-52
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> print(1e97 % 97)
-8.8928324534259e+79
>
[spc]lucy:~>lua-53
Lua 5.3.4  Copyright (C) 1994-2017 Lua.org, PUC-Rio
> print(1e97 % 97)
3.0
>

I don't think any of these are right.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Luiz Henrique de Figueiredo
>> print(1e97 % 97)
> 3.0
>
> I don't think any of these are right.

The correct result is 10 because of Fermat's little theorem[1] since
97 is prime.

[1] https://en.wikipedia.org/wiki/Fermat%27s_little_theorem

Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Tim Hill
In reply to this post by Dirk Laurie-2


> On Jun 26, 2018, at 2:52 AM, Dirk Laurie <[hidden email]> wrote:
>
> 2018-06-13 2:13 GMT+02:00 Albert Chan <[hidden email]>:
>> Thanks Hartmut for the HP-15C test.
>> It seems HP-15C does *decimal* math, 10 significant digits, half-round-up
>>
>> s = (a + b + c) / 2
>> = (1e5 + 99999.99979 + 0.00029) / 2
>> = (199999.9998 + 0.00029) / 2   -- round up
>> = 200000.0001 / 2                         -- round up again
>> = 100000.0001                               -- half-round-up
>>
>> I have never seen a calculator like this ...
>
> I have an HP41C, but it no longer works. I can recall, however, that
> it correctly evaluated 1e97 mod 97. Default Lua 5.3 on my machine says
> "1e97"%"97" is 3, which is wrong. Lua 5.3 built as `make linux -e
> MYCFLAGS=-DLUA_NOCVTS2N` and with a module supplying appropriate
> string metamethods, gets it right. My much more modern calculator of a
> different brand also gets it wrong.)
>

My HP41C still works (those were the days, HP), and yes you are correct.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Roberto Ierusalimschy
In reply to this post by Sean Conner
> [spc]lucy:~>lua-51
> Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> > print(1e97 % 97)
> -8.8928324534259e+79
> >
> [spc]lucy:~>lua-52
> Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> > print(1e97 % 97)
> -8.8928324534259e+79
> >
> [spc]lucy:~>lua-53
> Lua 5.3.4  Copyright (C) 1994-2017 Lua.org, PUC-Rio
> > print(1e97 % 97)
> 3.0
> >
>
> I don't think any of these are right.

As already explained, what is wrong in Lua 5.3 is 1e97. Floating-point
rounding...

Correct 1e97:
0x4ae825771dc07672ddd0f8e8ac39250971ac4210cecb6f656caeb910a000000000000000000000000

Representation of 1e97 as an IEEE double:
0x4ae825771dc0780000000000000000000000000000000000000000000000000000000000000000000

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Sergey Zakharchenko
In reply to this post by Sean Conner

Hello,

I'm sorry to interrupt the number-theoretic discussion but these seem way off:

> Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> > print(1e97 % 97)
> -8.8928324534259e+79

> Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> > print(1e97 % 97)
> -8.8928324534259e+79

I get 0 on all platforms I can test Lua 5.[12] on, which is of course as bad as 3 but not *this* bad. Could any patches you use have affected this?

Best regards,

--
DoubleF

Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Levente Kovacs
I have this on Debian stable:

lev@mercury:~$ lua5.1
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> =1e97 % 97
0
>
lev@mercury:~$ lua5.2
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> = 1e97 % 97
0
>
lev@mercury:~$ lua5.3
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
> =1e97 % 97
3.0
>

On Wed, Jun 27, 2018 at 3:26 PM, Sergey Zakharchenko
<[hidden email]> wrote:

> Hello,
>
> I'm sorry to interrupt the number-theoretic discussion but these seem way
> off:
>
>> Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
>> > print(1e97 % 97)
>> -8.8928324534259e+79
>
>> Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
>> > print(1e97 % 97)
>> -8.8928324534259e+79
>
> I get 0 on all platforms I can test Lua 5.[12] on, which is of course as bad
> as 3 but not *this* bad. Could any patches you use have affected this?
>
> Best regards,
>
> --
> DoubleF

Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Luiz Henrique de Figueiredo
In reply to this post by Sergey Zakharchenko
> I get 0 on all platforms I can test Lua 5.[12] on, which is of course as bad
> as 3 but not *this* bad. Could any patches you use have affected this?

On Mac OS X 10.11.6 I get

Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> print(1e97 % 97)
0

Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> print(1e97 % 97)
0

Lua 5.3.4  Copyright (C) 1994-2017 Lua.org, PUC-Rio
> print(1e97 % 97)
3.0

Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Roberto Ierusalimschy
In reply to this post by Roberto Ierusalimschy
> As already explained, what is wrong in Lua 5.3 is 1e97. Floating-point
> rounding...
>
> Correct 1e97:
> 0x4ae825771dc07672ddd0f8e8ac39250971ac4210cecb6f656caeb910a000000000000000000000000
>
> Representation of 1e97 as an IEEE double:
> 0x4ae825771dc0780000000000000000000000000000000000000000000000000000000000000000000

Just to be sure:

0x4ae825771dc07672ddd0f8e8ac39250971ac4210cecb6f656caeb910a000000000000000000000000 % 97 is 10

0x4ae825771dc0780000000000000000000000000000000000000000000000000000000000000000000 % 97 is 3

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Comment about IEEE floating-point rounding... (was: Setting Float Precision in Lua.c)

Roberto Ierusalimschy
In reply to this post by Luiz Henrique de Figueiredo
> > I get 0 on all platforms I can test Lua 5.[12] on, which is of course as bad
> > as 3 but not *this* bad. Could any patches you use have affected this?
>
> On Mac OS X 10.11.6 I get
>
> Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> > print(1e97 % 97)
> 0
>
> Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> > print(1e97 % 97)
> 0
>
> Lua 5.3.4  Copyright (C) 1994-2017 Lua.org, PUC-Rio
> > print(1e97 % 97)
> 3.0

Lua 5.1/5.2 computed the module (a%b) with (a - floor(a/b) * b),
which may introduce other rouding errors. Lua 5.3 computes the module
with 'fmod'; at least in my machine, the only error is the one in the
representation of 1e97 itself (see my other messages).

-- Roberto