Re: Setting Float Precision in Lua.c

[KHMan <keinhong@...>]

On 6/11/2018 11:20 AM, Albert Chan wrote:
> > I'm sorry, something has gone wrong with my results:
> >
> > $ 32bit/lua -i
> > Lua 5.4.0 (work1)  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> > > x=1e16;y=2.9999;print(string.format("%.17g",x+y+y+y))
> > 10000000000000012
> >
> > $ 64bit/lua -i
> > Lua 5.4.0 (work1)  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> > > x=1e16;y=2.9999;print(string.format("%.17g",x+y+y+y))
> > 10000000000000006
>
> This is as expected, exact value of z = 1e16 + 8.9997
> In this case 1 ULP = 2 (that is why all output are even)
>
> 32bit/lua round in 64-bits --> +1.50015 ULP against z(exact)
> 64bit/lua round in 53-bits --> -1.49985 ULP against z(exact)
>
> I don't mind the slightly bad result.
> But I like both to return the *same* result.
> It is just simple addition, using the same Lua 5.4 work-1

One possible bump should bit-consistency be made a hard rule. FMA3 
will throw up inconsistencies versus a non-FMA FPU, if someone was 
to make a hot-rod JIT Lua supporting that. Or if someone makes a 
Lua module for a particular high-performance need. Who knows where 
future killer apps might go and what are their needs. Of course 
users can be sufficiently warned in such situations; this notion 
can go the other way too. The requirement of a bit-consistent FPU 
black box may be fragile in the long term, and perhaps code 
relying on bit-consistency should be guarded with sentinels for 
future-proofing.


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia