-
Mon 2019.07.29
'it's probably a sign that the code should be working some other way'
Thank you @Gordon, that confirms (in summary) my closing comment in #22 and that will be the approach I shall use.
'but it seems like this is basically solved'
Actually, the equation helped @AkosLukacs locate the inconsistency as in the link to bug 1573 that you pointed to. It was code I just copied across for demonstration. Wasn't even needed as I was using constants. If there is a conversion issue (bug 1573) in question for constants, that could explain more than what our weekend exchange uncovered.
I'm after masking bits. The thread got side tracked with what the equation uncovered. Maybe there are two unique conflicting themes here.
'but the conversion ... into a ... (and back again) may not be exactly the same'
So that I may understand how floating point calculations are made under the hood, where is the better place to start on it's inclusion in Espruino? Is it done with Log tables? Where would they be defined? It just surprises me that the inconsistency compared with other techniques actually exists.
I'd hate to think that bit masking in unreliable . . . .
You are reading a single comment by @Robin and its replies.
Click here to read the full conversation.
Robin
Ok, so I'm a bit late to this as I had a long weekend, but it seems like this is basically solved now thanks to @AkosLukacs and @maze1980.
It's unfortunate that Espruino gets very slightly different answers when doing some floating point maths, but if you're dependent on the exact value of a floating point number after multiplying and dividing it, it's probably a sign that the code should be working some other way.
The differences in Espruino vs browser may actually be related to this bug: https://github.com/espruino/Espruino/issues/1573
So the maths itself may well be identical, but the conversion of the actual string into a floating point number (and back again) may not be exactly the same as the desktop browsers do it.