Float Anomaly

[Tepeix]

I just get this strange result with a float:

I get the big number 33554432 and i do -1.
And the result is the same number 33554432..

Someone could explain this anomaly ? Did i try to use to much big float here ?

..stress me a little as now i imagine that i could make error like this without realizing,
or maybe that i must avoid high memory thing ?

Thanks for any responses !)

[tulamide]

The readout doesn't work correctly.

Many reasons for it. Sloppy code, sloppy translation to a string, etc. Definitely not the single float format.
The 32 bit float representation of decimal 33554432 is

Code: Select all

0-10011000-00000000000000000000000

The 32 bit float representation of 33554431 is

Code: Select all

0-10010111-11111111111111111111111

[Tepeix]

Thanks !
I think you re right that this is not a float problem, but not sure for the readout.
(probably because i need a readout to verify my readout.!)

I dig a little more and try to simplify.
Seams like it as relation with the e+007 notation where the program recall correctly the part of the value that are hiden but not when an addition have modified them. It works fine with -10.

But strangely i don't get the same bug for 16777216 which will be read as 1.67772e+007..

[Tepeix]

Finally i have confirmation that this is not only the readout with this little program.
Converting the input float to a int and trying to use the famous delay counter that use (andps) (or even pand) instruction, i get nothing if i try to input the float, which say that the program see it as a 33554432.

Seams even more strange.. If i input the float 33554431 without any subtraction it will not work also !
And even if i input 33554432 then subtract 1 inside the code this is not working !!

Thanks to divine providence or anything else, it works when declaring the variable inside the asm code !!)

But this thing as other make me think that computer are not pure rationality but something esoteric that need sometime strange formula and experience to be use

[Tepeix]

Another strange anomaly.. And this time even declaring float variable inside the asm code ,(

Seams like the program consider that 33554431, 33554432, 33554433 and 33554434 are the same number when compared !(

[Tepeix]

Even worse with this.. I declare the variable x=33554434. Then make a counter that add 1 every cycle.
And the result is always 33554432. It also do the same with +2..
I begin to think that those number must be avoided as float or is it my computer that have a problem ?

[tulamide]

Again, floats are not the issue. I pointed that out already, so won't go that path again.

But it seems, you're confusing a lot of data types, ignoring that they are all different. So, in order to clear this mess up a little bit, here are a few facts.

1) A float is not an integer is not a string is not a stream! They are all different data formats that you can't just mix.
2) Do you even realize that, when looking at an int prim, or a float prim, you DON'T see the number, but a string? In order to see a value, it has to be converted to a string. You can't rely on a string as the actual number. It isn't.
3) Do you realize that, when you enter "numbers" into a string prim, it is not a value, but a string? In order to make it a value, it has to be converted into a value data type like integer or float. You can't rely on a string being a value.
4) Your "proofs" are just reliances on a readout, of which I told you, that it doesn't work correctly.
5) mono stream will not work, unless you activate a sound output. That's its whole purpose of existence - to send out audio data.
6) Using an int prim to feed a blue stream forces Flowstone to convert a 64-bit integer data type into a 32-bit single floating point data type.

And a tip: Use a RubyEdit to check your values. It has an error free conversion to string, when using the watch method. Just look at the user guide, chapter 8, for details on usage.

[Tepeix]

Very thanks to said it
I'm a little tired at this hour but i promise you i get something strange here that could not only be the readout.
Or maybe when you run this little program it increment like it might do and my computer or cpu add a problem !!

Yes the readout have implication but here even if it's the case after sometime it might indicate more than 33554432 because it's an increment. (it would maybe not indicate ..33,..34 but might for higher number)

(the file here is the code i used to make the image in my last post.)

I begin to even doubt about my own very simple code !) But let's try keep rational.
the code simply load the value, add 1 then write it again.
But it doesn't see any difference between those number and the increment doesn't occur.
Would be happy if it's my computer or if my code was wrong !

(i also tried with this site to see the binary conversion and it seams that ..32 or..33 give the same :https://www.binaryconvert.com/)

[Tepeix]

I find some explanation.
Well, it's really very strange that this thing is not explained in any book or tutorial about float or in the definition !
Most of time it's said that a float could represent 2^31-1 and have a good precision.

But in fact this precision decline more and more when you reach high number.

This article explain it : https://blog.demofox.org/2017/11/21/flo ... precision/

When reaching 2^20 or 16777216 the max precision become 2 and you could not increment by 1 anymore.
16777217 does not exist !
At 33554432 the max precision become 3 and increment by 2 does not work..

That's very new to me and i think that float must be better explained as we tend to think that the precision will stay the same when reaching high number but it's not the case and very misleading !

[tulamide]

Oh dear! You're absolutely correct! How I missed that is a mystery to me.

Yes, the float format's resolution ("step size") is dependend on the size of the value. The more bits it uses, the less resolution there is available. I'm very sorry to have you let down on this point!

But please, don't think that renders my remarks regarding data types and conversion wrong. It's important you understand, that everytime you use the wrong data type, a conversion takes place. And everytime you convert a value, new precision issues will arise. Always make sure to use the correct data type for the value(s) you expect. In your case, you don't want to deal with high integer numbers in float. Instead try to find a relative value substitute (For example, instead of counting +1, try counting +0.1 or even smaller, since floats are more precise on fractions than on integers, although this precision is of course also limited).

Again, sorry for misleading you!