Because the argument you typed into the > and < objects does not contain a decimal point, you are doing integer comparisons with a float input. The float gets converted to int by the < and > objects. But the maximum positive number that a 32-bit int can represent is 2147483647, so if you send in any float greater than that (or greater than 2147483520, in fact), it will get converted into a negative number. (Floats that large get very imprecise, but the trade-off is that they can go higher than 2147483647.) Perhaps this little patch will exemplify it. Try dragging the float number box to output numbers greater than or less than 2147483520.

Thanks a lot Christopher! I just didn't need float precision and so i chose to compare integers (and I thought it was less expensive for the cpu), but now, since i'm forced to, I won't scale the It's so strange that ints turn negative... is it a sort of convention, just to let you (in some way) know that the number is out of digits? thanks again, m

No. All 32-bit signed integers "greater than" 2147483647 are actually representations of negative numbers from -2147483648 to -1.

Bit 31 is considered the "sign" bit; if it's set, the number is negative and all other bits mean their opposite ("ones' complement").

Do a Wikipedia search on "Integer_(computer_science) and/or "Signed number representations" and/or "Ones'_complement" for more info.

Ah yes! Bit depth is half positive and half negative, starting from 0 and coming back to -1. The negative half is the one with the last bit set... did you call it the 31st bit because the first is "bit 0"?

Yes. I think I should have more correctly said either "bit 31" or "the 32nd bit".

Thank you