[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.

It's not misbehaving floor function. It's because 308.09 cannot be expressed exactly in base 2 (as a sum of powers of two), thus cannot be stored exactly as 64-bit floating-point number. The nearest number that can be stored in 64-bit floating point is less than 308.09. That's the error, it happens when the number is parsed from string "308.09" into 64-bit floating point; but from there everything works as it should. Multiply something less than 308.09 by 100 and you get a number less than 30809. Floor that and you get 30808 (correct).

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:

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

Then it means ZO_LocalizeDecimalNumber has a new bug.

No it's not ESO or Lua specific. Here Python:
It is not possible to store 308.09 in base-2 representation (in a finite number of bits), e.g. the most widely used binary64 (C double, Lua number, Python float). Regardless of whether the language is compiled to machine code, or bytecode, when the compiler translates the source string "308.09" into a number in base-2 representation, the value will inevitably be "something other than 308.09" (whether less or greater may depend on language, rounding mode or computer architecture, but it cannot be exact).

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.

if they replaced, it wasnt in any notes, right?