[open] LocalizeDecimalNumber
/script d(ZO_LocalizeDecimalNumber(308.08*100))
30,808 script d(ZO_LocalizeDecimalNumber(308.09*100)) #german client |
Ok, I'm adding some context to this.
ZO_LocalizeDecimalNumber() used to convert a number like 1234.56 to the string "1,234.56" (or "1.234,56" on German/French clients). Now, this function doesn't do that anymore. First it doesn't convert to to 'European' format anymore, second it throws the above LUA error on different occasions. Is this function just bugged or does it have a different use now? If the second, is there any replacement? |
zo_floor(308.09*100) is 30808 and not 30809!
Because of that, the number is not detected as an integer. Real good catch. |
/script d(math.floor(308.09*100))
= 30808 |
It looks like you're right, votan. The error is triggered by misbehaving floor functions.
|
Quote:
|
I know that it's a precision problem. That doesn't change the fact, that the result is (inherently) wrong.
However, ZO_LocalizeDecimalNumber() needs to find a way to work around that. Otherwise the function becomes pretty much useless for floating point numbers. It used to work before (with rounding errors), but that changed with the last update. |
works fine:
lua Code:
|
This function was changed with 4.3.5.
Maybe it is an ESO Lua specific precision problem. Here is another number to test: 303.9*100 |
Quote:
Quote:
Code:
>>> 308.09 * 100 Some numbers simply don't have finite representation in some bases. For example 1/3 (one third). In base-3, it is simply 0.1; in base-6 it is 0.2; in base-12 it is 0.4; but in base-10 it is 0.333333333... ad infinitum. |
It seems they have replaced ZO_LocalizeDecimalNumber with a new function ZO_CommaDelimitDecimalNumber. The former has been moved into the addoncompatibilityaliases.lua and just references the latter.
|
Quote:
|
All times are GMT -6. The time now is 05:25 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI