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

Sat 2019.07.27

'I wouldn't go this way and stick with JavaScript for simplicity'

Sort of agree with you but, . . . as @AkosLukacs and yourself have pointed out, and with the note in the link from #10 that I found, there is an issue (fewer identical upper MSB values-see your #9) with the floating point values compared with other means. This severely (in my need) affects accuracy where the LSB bits will be needed. My suggestion for an attempt with inline 'C' might bypass what the Javascript Math library does, which is dependent on floating point. Don't know if the inline 'C' functions might use the identical floating point mechanism at the hardware level.    i.e. Math.pow() is the library layer on top of the Espruino Javascript layer on top of inline 'C' asm on top of the physical hardware layer itself.

EDIT:
Note to @Gordon would you briefly describe how the floating point section works to build it's values please, and maybe where in the source they are extracted. Are log tables used? More of a curiosity question as I hadn't realized how complex doing 'simple' math actually is for a micro.

https://github.com/espruino/Espruino/blo­b/master/libs/math/jswrap_math.c#L291

Just thought of a possible hacky solution using the original Arduino script. As my design will require the end user to input one of only 20 to 50 valid values using this C++ function conversion, I could possibly write a small Arduino code file and build a table of those values that it puts out. Then using an array or switch case code block in Javascript, extract the hex bits already converted that way. This would however, make for headaches for future user update requests of the finished deployed module.

Naaaahh, as a purist, I'll wait and see if we can find a Javascript solution.