On 6/11/2018 11:20 AM, Albert Chan wrote:
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.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-Riox=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-Riox=1e16;y=2.9999;print(string.format("%.17g",x+y+y+y))10000000000000006This 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
-- Cheers, Kein-Hong Man (esq.) Selangor, Malaysia