Page 2 of 2
Re: Rounding issues & Memory
Posted: Mon Apr 22, 2013 4:29 pm
by retrotails
Boolsheet wrote:To address your other questions.
retrotails wrote:Would it be noticeably more efficient in any manner to have all globals in ONE string? (assuming they're numbers from 0-255)
I don't understand this question. Can you rephrase it?
Like the string 'abc ' that has 4 values, 97, 98, 99 and 32. I can use those as variables with string.byte() and string.char(), so a 4 character string has 4 bytes of memory I can use as 4 separate variables, so long as I know what position corresponds to what variable. The string functions will slow it down to far below performance with actual bytes, but it might save on memory while making saving/loading easier.
Re: Rounding issues & Memory
Posted: Mon Apr 22, 2013 4:58 pm
by Robin
It's not going to be worth it. Just use a table of numbers when you need a table of numbers.
Re: Rounding issues & Memory
Posted: Mon Apr 22, 2013 5:03 pm
by Plu
Odds are this problem can also be fixed by multiplying your numbers by 1000000 and then dividing them when you need to output them, that'll garuantuee they remain integers during the calculations. (Well... simple calculations anyway; you still won't be able to do 1/3 or such)
Re: Rounding issues & Memory
Posted: Mon Apr 22, 2013 6:33 pm
by Robin
That works, under these very specific assumptions:
- You multiply the numeric constants with this constant. So you have literally 999000 in your code and not 0.999 * 1000000
- You are very careful with addition and multiplication. For addition, you need to multiply any "normal" integer with 1000000 before adding it to such a "fake" integer. For multiplication, you need to make sure at least one of the numbers is a "normal" integer. If you multiply two "fake" integers, you need to divide the result of the multiplication by 1000000.
- That's it, I think. This space reserved for future gotchas I might think of.
Technically, it should be enough to multiply by 5^
n instead of by 1000000, for a certain
n, but figuring out the right
n can be tricky.
Re: Rounding issues & Memory
Posted: Tue Apr 23, 2013 8:38 am
by T-Bone
Using an inexact representation of floating numbers is a very reasonable optimization, especially for games where performance is often much more important than accuracy, and should be considered a feature, not a bug.
Re: Rounding issues & Memory
Posted: Tue Apr 23, 2013 9:31 am
by vitaminx
I was running into the same issue when using floats in loops.
I've posted it to the Lua mailing list and got some interesting answers, maybe that clears things up regarding floats and rounding errors:
http://lua-users.org/lists/lua-l/2013-03/msg00979.html
Re: Rounding issues & Memory
Posted: Tue Apr 23, 2013 1:22 pm
by retrotails
micha wrote:Do you have an example, where it is important to obtain an integer in the end, while in between you have non-integers?
Code: Select all
table = {}
for x = .2, 0, -0.1 do
table[x*10] = x
end
for i, k in pairs(table) do
print('i = ' .. i, 'k = ' .. k)
end
print(table[1])
Out:
Code: Select all
i = 2 k = 0.2
i = 1 k = 0.1
i = 2.7755575615629e-16 k = 2.7755575615629e-17
nil
This, maybe. Unless I did something wrong which is totally possible.
Re: Rounding issues & Memory
Posted: Tue Apr 23, 2013 1:28 pm
by Robin
What's wrong with:
Code: Select all
for x = 2, 0, -1 do
table[x] = x/10
end
?
Re: Rounding issues & Memory
Posted: Tue Apr 23, 2013 1:28 pm
by micha
retrotails wrote:micha wrote:Do you have an example, where it is important to obtain an integer in the end, while in between you have non-integers?
Code: Select all
table = {}
for x = .2, 0, -0.1 do
table[x*10] = x
end
for i, k in pairs(table) do
print('i = ' .. i, 'k = ' .. k)
end
print(table[1])
Out:
Code: Select all
i = 2 k = 0.2
i = 1 k = 0.1
i = 2.7755575615629e-16 k = 2.7755575615629e-17
nil
This, maybe. Unless I did something wrong which is totally possible.
I understand the code, but I don't understand why in reality you would ever code something like this.
So, I won't let that count as a valid example.
