Hey guys!

This has been making me question my sanity and I just can't solve this by myself.

The patch I'm building is more complicated than this, but in trying to solve the problem I have isolated the strange behavior like this:

[number box 1]
I
[* 100}
I
[number box 2]
I
[int]
I
[number box 3]

As you shift-scroll number box 1, number box 2 and 3 should read the same as 1 but with the decimal point moved. BUT on certain, values, number box 3 will be one lower than the input of [int]. For example 20.38 will always output [int] as 2037.

It seems like [int] is not storing values property.

I'm using Purr Data 2.5.1, but the same happens in vanilla.

What am I missing here? I feel like it's right in front of me. Thanks in advance for your help!

the way that numbers are printed is not how they actually are. floating point numbers, represented in base 10, are actually stored in binary. this is true of your original number as well as the 100 you multiply your number with. When the number is displayed after the [* 100], it might not actually be 2038, it is a binary number that is extremely close. You'll notice that if you put 2038 right before the int, it will display correctly because that number is different in binary than 20.38 * 100.

edit: check this out: https://www.h-schmidt.net/FloatConverter/IEEE754.html
notice how if you put in 20.38 the value actually stored is 20.3799991607666015625

@seb-harmonik.ar
Thanks, that's a pretty intuitive explanation.

I don't suppose you could suggest a more consistent way moving a decimal point?

@Jazzmansteve
Ok, never mind!

[ + 0.499 ] after after the multiplication stage seems to work!