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

Fri 2019.07.26

Good evening AkosLukacs and maze1980 as I sit down for my morning coffee.

Thanks for cranking out those calcs @AkosLukacs.

'there is something wrong with floating point calculation'

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:

uint64_t frf = ((uint64_t)val << 19) / 32000000;

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

https://github.com/espruino/Espruino/blob/master/libs/math/jswrap_math.c#L330

Just looking around and found the comment at L291 for Math.pow() VERY interesting.

Maybe this is why the F.P. calcs are off?