New var creation with right bit shift shows incorrect result using same initializer

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 . . . .

So that I may understand how floating point calculations are made under the hood

I pointed you to jsvMathsOp in one of the other posts you'd made when I looked at my email this morning. It's in there. At the end of the day Espruino uses the entirely standard C libraries for double arithmetic and converting between doubles/ints - so you would hope there would be no differences.

However conversion to/from Strings is done with Espruino's own functions (which happens in jsutils.c) - generally I can't use the built-in math functions for that because:

1. They don't abide by the JS spec in more serious ways (eg. parsing of invalid strings)
   
2. They bring in other parts of the C library which total maybe 50k of extra used code space, which we can't afford on a lot of platforms.