Cross-platformly deterministic to-the-power-of function
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
- zorg
- Party member
- Posts: 3441
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: Cross-platformly deterministic to-the-power-of function
Well, you did define print's format string to print a double-precision float with %g
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Re: Cross-platformly deterministic to-the-power-of function
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.
Re: Cross-platformly deterministic to-the-power-of function
Actually... I'm interested in FFI fixeds.
Will they be deterministic?
Will they be deterministic?
Tachytaenius
- zorg
- Party member
- Posts: 3441
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: Cross-platformly deterministic to-the-power-of function
And if you didn't tonumber it, just printed the ffi type with format %d ?
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Re: Cross-platformly deterministic to-the-power-of function
zorg:
But in this case, not even that:
However, the tostring() of that value gives: -84041051210270157LL
Surprisingly, it gives the same value in 32 bits.
wolfboyft:
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.
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)
Surprisingly, it gives the same value in 32 bits.
wolfboyft:
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.
Re: Cross-platformly deterministic to-the-power-of function
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?
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?
Tachytaenius
Re: Cross-platformly deterministic to-the-power-of function
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).wolfboyft wrote: ↑Sun May 27, 2018 11:16 am 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?
https://en.wikipedia.org/wiki/Unit_in_t ... Definition
(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.)wikipedia wrote: 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
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.
Re: Cross-platformly deterministic to-the-power-of function
To clarify, FFI really does seem like a good idea now:
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 wrote: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.
Tachytaenius
Re: Cross-platformly deterministic to-the-power-of function
Wait a minute... why couldn't I just make my library in pure Lua? Would that be even slower than FFI?
Tachytaenius
Re: Cross-platformly deterministic to-the-power-of function
I fail to understand how this:
I fail to see how FFI fits into that plan.
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.
follows from this:
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.wolfboyft wrote: ↑Sun May 27, 2018 2:53 pm--wolfboyft wrote: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.
I fail to see how FFI fits into that plan.
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.
Who is online
Users browsing this forum: Ahrefs [Bot], Google [Bot] and 91 guests