Cross-platformly deterministic to-the-power-of function

[zorg]

Well, you did define print's format string to print a double-precision float with %g

[pgimeno]

Yeah, but that doesn't really matter. It's tonumber that converts it to float. I used that because without string.format, I was getting -8.404105121027e+16. Using %d still outputs -84041051210270160.

[wolfboyft]

Actually... I'm interested in FFI fixeds.
Will they be deterministic?

[zorg]

Yeah, but that doesn't really matter. It's tonumber that converts it to float. I used that because without string.format, I was getting -8.404105121027e+16. Using %d still outputs -84041051210270160.

And if you didn't tonumber it, just printed the ffi type with format %d ?

[pgimeno]

zorg:

And if you didn't tonumber it, just printed the ffi type with format %d ?

You can't use string.format. If you use it, you're using the Lua library. If you're using the Lua library, you're using Lua types.

But in this case, not even that:

Code: Select all

luajit: main.lua:11: bad argument #2 to 'format' (number expected, got cdata)

However, the tostring() of that value gives: -84041051210270157LL

Surprisingly, it gives the same value in 32 bits.



wolfboyft:

Actually... I'm interested in FFI fixeds.
Will they be deterministic?

I suppose they will. There's been a pretty big change in LuaJIT 2.1, though, which I've heard is used in LÖVE for Android, so I'd advise you to test there.

I can't vouch for the performance, though. The cdata needs to be allocated, handled and garbage-collected when it's not compiled. A loop of 50 iterations in the example above didn't get compiled, that's why I chose 70.

But once again, floats are not that bad. Since you have to test anyway, I'd test the IEEE-754 compliance first, because it's likely that it won't cause problems in any of the supported platforms, and you get the cross-platform behaviour you are after without any extra effort on your side.

[wolfboyft]

Right... so LuaJIT uses IEEE-754 floats. Addition, subtraction and such should work fine for any length of playback from what I have gathered.

I'm just really confused about other things and kinda torn between lots of options?
I won't be using any implementations of math.sin or ^ (which references math.pow) et cetera that are not the ones supplied by Lua(JIT?)
But do those not reference something else? Something that can vary from one IEEE-754-compliant machine to another IEEE-754-compliant machine?

I really ought to be testing to find out myself, to be honest. More "it's easier to ask for forgiveness than permission" than "look before you leap..." right?

[pgimeno]

Right... so LuaJIT uses IEEE-754 floats. Addition, subtraction and such should work fine for any length of playback from what I have gathered.

I'm just really confused about other things and kinda torn between lots of options?
I won't be using any implementations of math.sin or ^ (which references math.pow) et cetera that are not the ones supplied by Lua(JIT?)
But do those not reference something else? Something that can vary from one IEEE-754-compliant machine to another IEEE-754-compliant machine?

IEEE-754 only guarantees correctly rounded results within 1/2 ULP (Unit in the Last Place) of the exact result for a few operations, including +, -, *, / and square root (math.sqrt).

https://en.wikipedia.org/wiki/Unit_in_t ... Definition

The IEEE 754 specification—followed by all modern floating-point hardware—requires that the result of an elementary arithmetic operation (addition, subtraction, multiplication, division, and square root since 1985, and FMA since 2008) be correctly rounded, which implies that in rounding to nearest, the rounded result is within 0.5 ULP of the mathematically exact result

(FMA stands for Fused Multiply-Add: FMA(a,b,c) = a*b+c, where the result must be within 1/2 ULP of the exact result, which wouldn't be guaranteed if the product was rounded before performing the addition. This operation is not supported by LuaJIT anyway.)

If you use any other transcendental function, e.g. math.sin(), or a power with a non-integer exponent other than 1/2, in two machines that are IEEE-complaint, you could get a different result in each, because IEEE-754 does not have the same requirements for them as it does for the other operations. If you need to use those, you'll need to implement your own algorithm using a combination of +, -, *, / and sqrt, in case you want your result to be identical cross-platform. A Chebyshev polynomial or a Taylor series are two typical approaches for approximating many of these functions, using only multiplications and additions.

[wolfboyft]

To clarify, FFI really does seem like a good idea now:

An IEEE-754 compliant FPU will be deterministic for basic arithmetic.
Different maths libraries will use basic arithmetic differently to make functions.
So as long as the FPU is IEEE-754-compliant a lack of determinism is the library's fault.
So therefore I do need to use one library if I want determinstic values.

--

From what I've researched, "correctly rounded within half ULP" means that as far as this float can be accurate, it will be accurate.

Thank you for the hint with Chebyshev polynomials. I will try to research into this.

[wolfboyft]

Wait a minute... why couldn't I just make my library in pure Lua? Would that be even slower than FFI?

[pgimeno]

I fail to understand how this:

To clarify, FFI really does seem like a good idea now:

follows from this:

An IEEE-754 compliant FPU will be deterministic for basic arithmetic.
Different maths libraries will use basic arithmetic differently to make functions.
So as long as the FPU is IEEE-754-compliant a lack of determinism is the library's fault.
So therefore I do need to use one library if I want determinstic values.

--

If you restrict yourself to using addition, subtraction, multiplication, division and square roots, and implement your own library for other operations (if you need them, in the first place), you should get the same (numeric) results in all platforms. If your library doesn't use the platform's transcendental functions at all (or powers to non-integer exponents), it will be safe. Square roots via math.sqrt are safe.

I fail to see how FFI fits into that plan.

From what I've researched, "correctly rounded within half ULP" means that as far as this float can be accurate, it will be accurate.

More or less, yes. By correctly rounded I mean using the round-to-nearest-or-even rule.

It also means that you will get cross-platform-compatible results for the five operations supported, provided the platform supports IEEE-754 semantics AND defaults to round-to-nearest-or-even.