Thread Tools Display Modes
03/01/19, 03:18 PM   #1
Verbalinkontinenz
 
Verbalinkontinenz's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2016
Posts: 11
[open] LocalizeDecimalNumber

/script d(ZO_LocalizeDecimalNumber(308.08*100))

30,808

script d(ZO_LocalizeDecimalNumber(308.09*100))



#german client

Last edited by Verbalinkontinenz : 03/01/19 at 03:21 PM. Reason: open tag?
  Reply With Quote
03/01/19, 04:01 PM   #2
Arkadius
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 4
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?
  Reply With Quote
03/01/19, 04:15 PM   #3
votan
 
votan's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2014
Posts: 577
zo_floor(308.09*100) is 30808 and not 30809!
Because of that, the number is not detected as an integer.
Real good catch.
  Reply With Quote
03/01/19, 04:57 PM   #4
Verbalinkontinenz
 
Verbalinkontinenz's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2016
Posts: 11
/script d(math.floor(308.09*100))

= 30808
  Reply With Quote
03/01/19, 05:24 PM   #5
Arkadius
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 4
It looks like you're right, votan. The error is triggered by misbehaving floor functions.
  Reply With Quote
03/01/19, 07:41 PM   #6
merlight
AddOn Author - Click to view addons
Join Date: Jul 2014
Posts: 671
Originally Posted by Arkadius View Post
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).
  Reply With Quote
03/02/19, 01:39 AM   #7
Arkadius
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 4
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.

Last edited by Arkadius : 03/02/19 at 01:52 AM.
  Reply With Quote
03/02/19, 02:01 AM   #8
Scootworks
 
Scootworks's Avatar
AddOn Author - Click to view addons
Join Date: Nov 2014
Posts: 312
works fine:
lua Code:
  1. /script d(ZO_LocalizeDecimalNumber(zo_roundToNearest(308.09*100, .01)))
  Reply With Quote
03/02/19, 03:29 AM   #9
votan
 
votan's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2014
Posts: 577
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
  Reply With Quote
03/02/19, 05:46 AM   #10
merlight
AddOn Author - Click to view addons
Join Date: Jul 2014
Posts: 671
Originally Posted by votan View Post
This function was changed with 4.3.5.
Then it means ZO_LocalizeDecimalNumber has a new bug.

Originally Posted by votan View Post
Maybe it is an ESO Lua specific precision problem.
Here is another number to test: 303.9*100
No it's not ESO or Lua specific. Here Python:
Code:
>>> 308.09 * 100
30808.999999999996
>>> 303.9 * 100
30389.999999999996
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.
  Reply With Quote
03/02/19, 07:01 AM   #11
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,566
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.
  Reply With Quote
03/02/19, 11:02 AM   #12
Verbalinkontinenz
 
Verbalinkontinenz's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2016
Posts: 11
Originally Posted by sirinsidiator View Post
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?
  Reply With Quote

ESOUI » Developer Discussions » Bug Reports » [open] LocalizeDecimalNumber

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off