Force a variable to be an integer

[e.sobole]

Hi.

I have a strange bug

local offY = - (drawY % self.data.tileheight)
print("-+-", offY, drawY, self.data.tileheight)

And the output is

21:31:00.305  -+-	-79.999999999997	3040	80

That mean self.data.tileheight is a float value and probably drawY is a float value too!

Is it possible to force a lua variable to be an integer ?

Of course, I found a solution to this specific problem. I’m asking for next time !

[XeduR]

This isn’t really a bug.

Lua uses double-precision floating-point numbers. There is no such thing as a “pure integer” in Lua.

If you want to force numbers to always be integers, you’ll need to use something like math.floor() or math.round(), etc. to do so.

[Siu]

Solution is already provided, however, don’t want this sample to be misleading.
Not sure how you’re getting

-79.999999999997

from

3040 % 80

, that’s a bit off.

[XeduR]

The reason for that is exactly the same as what I mentioned above: double-precision floating-point numbers.

The print function call is showing 3040, but in reality it’s a number very close to 3040 and the displayed value is simply rounded to 3040, but the real number is probably 3039.999999999997…

If you just input 3040 % 80, you’ll get 0, but if that 3040 isn’t hardcoded but rather the result of some calculations, then it’s calculated using floating-point numbers, i.e. it isn’t guaranteed to be an integer even if Lua displays it as such via print().

[e.sobole]

Exact XeduR

But I can believe Lua does not use integer value somewhere
Using float for loop for example should be very weird

for a = 1, 10 do
end

Lua 5.3 add bitwise operators:

&: bitwise AND
|: bitwise OR
~: bitwise exclusive OR
>>: right shift
<<: left shift
~: unary bitwise NOT

And that could work only with integer !
It could be nice if Solar2D was updated with the lastest version of Lua !

[Siu]

@XeduR

The reason for that is exactly the same as what I mentioned above: double-precision floating-point numbers.

The print function call is showing 3040, but in reality it’s a number very close to 3040 and the displayed value is simply rounded to 3040, but the real number is probably 3039.999999999997…

If you just input 3040 % 80, you’ll get 0, but if that 3040 isn’t hardcoded but rather the result of some calculations, then it’s calculated using floating-point numbers, i.e. it isn’t guaranteed to be an integer even if Lua displays it as such via print().

Ah yea, I understand better now, thanks for that!
I was expecting print() to show the full trail, and definitely little confusing if the number is used in its original value for the mathematical operation.

[XeduR]

In loops, as long as you are using integers, then they are treated as such, even though they aren’t “pure integers” in programming sense.

In Lua, or in any other language that uses floating-point numbers, the inaccuracies appear once you start doing operations on the numbers. As long as you just have a hardcoded integer value, it is accurate, but the moment that you do any operations with it, it can’t be guaranteed to be an exact integer.

For an over simplified example,
If you have 1, and you divide it by 3. You later multiply it by 3. A person would see it as (1/3)*3 = 1, but for a computer it would be 0.3333333333…*3, and it has to round up/down every value at some point, so it may or may not be treated as 1 or as something (infinitely or) very close to 1.

[e.sobole]

@XeduR

For an over simplified example,
If you have 1, and you divide it by 3. You later multiply it by 3. A person would see it as (1/3)*3 = 1, but for a computer it would be 0.3333333333…*3, and it has to round up/down every value at some point, so it may or may not be treated as 1 or as something (infinitely or) very close to 1.

Ok. I prefer that.

So if I’m using only Add, Sub and Mul Operation on integer, I should have an integer in return !
I can deal with that !
And math.floor will return an integer too !

I often use Javascript ou PHP which also uses variants but I had never seen such a side effect