
Math.pow
> Looks like you have found something:>Math.pow(2,19) == 524288 =false
AFAIK all math operations are floating point operations in javascript & Espruino.
So while(something << 19) / 32000000
is perfectly valid 64 bit integer operation in C, and probably reasonably performant since bitshifting is supported since forever. That just doesn't exist in javascript.
What's the source of those operations?

'Looks like you have found something'
I can't take the credit for that, @maze1980 did the groundwork in #9. (unless of course you are referring to comment at L291)
'That just doesn't exist in javascript.'
So original assumption correct, what is the best way to supply the operand to be able to perform this stunt in Javascript? All docs I've read so far indicate use of integers. But aren't integers a representation of what is store using F.P.? hmmmmm
'So while (something << 19) / 32000000 is perfectly valid 64 bit integer operation in C'
But doesn't the divide convert from integer to F.P. for the calculation, introducing rounding error as you so kindly pointed out?
'What's the source of those operations?'
Part of a massive Arduino script I want to see if it possible to run using EspruinoWiFi's, so that those guys don't have all the fun!! ;)
Fri 2019.07.26
Good evening AkosLukacs and maze1980 as I sit down for my morning coffee.
Thanks for cranking out those calcs @AkosLukacs.
Yes, I agree. I remember removing the parseInt() wrapper as the integer result was not the same as the corresponding one compared to the E notation.
So, how serious is a non compatible F.P. calculation engine or what acceptable error range? I haven't found any specification docs on the site yet.
Thanks @maze1980 for the intermediate steps as a possible work around.
I also, plucked all the toString(16) toString(2) parseInt() etc from the multitude of lines created trying to isolate this issue.
The Mozilla docs indicate that for bit manipulation, 2's compliment is used. It is also indicated that only 1's and 0's are used, rather than numbers. So big question, what is the proper way to get from user input to only 1's and 0's?
The original C++ line to convert:
C/C++ uses 64 bits in their shift calculations. But the divide sign bothers me in the above line. Still searching for docs on 2's compliment and using division. Doesn't F.P. get used (yes?) under the hood when dividing? If yes, then the above, although works on Arduino, seems rather pointless. Why go to the trouble of left shifting, maintaining the 1's and 0's only to introduce rounding error with F.P. division? Sadly absolutely no docs or examples with that source. (maybe the author realized that the lower LSB weren't really needed?)
Since we are limited to 32 bits for bitwise calcs in Javascript, maybe an answer might be to somehow mask off the MSB just before left shift into no mans land, and shift that bit into a separate var container nineteen times, thus preserving 1's and 0's up to 64 bits? But, then how to properly handle the division? The author of the Arduino source must have had a reason to left shift nineteen times, rather than just do the calculation in F.P. wouldn't you agree?
Is anyone able to confirm that only integer values, for both operands and flags, (maybe not hex either) should be used in bitwise calcs?
In the mean time until the F.P. issue can be looked at, will just use constants to prove out the initial code conversion, but will need a solution for down the road in a ~month or so.
Time for more research. . . .
EDIT:
I wonder if inline 'C' using E.compiledC will improve things?
Just did a lookup for the Math.round() function
Just looking around and found the comment at L291 for Math.pow() VERY interesting.
Maybe this is why the F.P. calcs are off?