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

You are reading a single comment by @AkosLukacs and its replies. Click here to read the full conversation.

•

maze1980 in reply to @AkosLukacs
A re-implementation from the original C line
```
uint64_t frf = ((uint64_t)val << 19) / 32000000;
```
can be re-written to C code using floating point numbers
```
uint64_t frf = (uint64_t)((float)val * 0.016384);
```
and then converted to JavaScript:
```
var frf = Math.round(val * 0.016384);
```
(0.016384 is equal to Math.pow(2, 19) / 32000000)

•

AkosLukacs in reply to @maze1980

I meant the original intention of the code, so maybe we can figure out a way to do it without floating point operations and rounds.
Or maybe wouldn't gain anything, if this works well enough :)

•

Robin in reply to @AkosLukacs

Sun 2019.07.28

'I meant the original intention of the code'

@AkosLukacs, the source wasn't needed as I only requested a snippet of how Arduino masked bits.

Too many over-lapping projects here. Was working on a tutorial for bitwise operators.
Unable to locate a suitable example on this site, was curious how it was done with 'C'. Was sent the snippet in #1, which maze1980 pointed out is being used by others. The formula wasn't even needed as I was just after how to mask bits. But interestingly, the formula did assist us in uncovering why my implementation started throwing errors, as you discovered.

It does appear that the source sent me is a kludge copy of that or a similar file. Source that isn't commented is always suspect. Seeing the same no comments there (link #20) also, now puts the kludge chunk sent me in question.

So the formula does appear to have some physics/mathematical relationship for others to have used it.

Bigger fish to fry. Attempting to rework a rather large source is the big show stopper right now. Found this as an alternate means using additional memory:

Espruino loading source code from SD card?

Then on to having two devices talk back-n-forth, which I started here:

Does pinMode 'input' state place pin in tri-state mode

Using a formula to mask bits seems iffy anyway. What if down the road there becomes an EspruinoWiFi Deluxe using a different processor and different/unique floating point engine that is different from the existing one. Any attempt to port on to the new device, would result in errors there also. Then, immediately I'd get the blame for crappy code. A constants table makes more sense.

We'll wait for the manufacturer datasheet as you so pointed out.

Using named indexes would allow the ability to 'screen' a user request.

https://www.w3schools.com/js/js_mistakes.asp

So, this appears to be the better solution, or an array of constants.

Thank you for your assistance with the detective work. It has been an exciting exchange and a fantastic learning experience.

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

About

Espruino