[patch] dojo.number.format may misformat very large numbers

[ChiefPilot]

Using dojo.number.format with an exponent >= 21 returns a misformatted string. Using the Firebug console, the following input :

n=3.1415e21 str = dojo.number.format(n); console.log(str)

...generates the following output:

3.141

I *think* the issue happens in dojo.number._formatAbsolute() function within number.js, when it splits a string representation of the value apart using the decimal as the separator at line 192. This results in ['3', '1415e21']. Subsequent pattern matches then result in the 'e21' being stripped.

A possible workaround or solution is attached. This alters the behavior such that the exponent is preserved if present. It does not alter the underlying javascript behavior of changing large values into exponential format.

[ChiefPilot]

Possible workaround / solution for dojo number.js

[Adam Peller]

at this time, exponents are not supported and precision is limited (at least) by Javascript binary floating point representation. Patterns using 'E' generate a warning. Not sure it's worth accommodating e input given all these limitations.

[ChiefPilot]

Replying to peller:

at this time, exponents are not supported and precision is limited (at least) by Javascript binary floating point representation. Patterns using 'E' generate a warning. Not sure it's worth accommodating e input given all these limitations.

That makes sense and I saw several places in the code where such was stated. I believe there is a bug here, however, even for non-exponents. The input

n=10000000000000000000000
str = dojo.number.format(n);
console.log(str)

...produces output of :

1e,+22

...which is clearly not correct. I discovered this shortly after submitting the ticket; I do not have a patch to submit at this time but am working on one and would be happy to share if there is any interest.

[Adam Peller]

right. dojo.number basically doesn't handle large numbers, wherever scientific notation comes into play, nor is it able to deal with precision beyond (or perhaps even approaching) the limits of binary floating point.

[Adam Peller]

...but it's true it would be better to fail outright, rather than produce this kind of result. See also #8756

[bill]

Maybe you want to close as patchwelcome, or leave open to add an error message.

[duong.nguyen]

Fixed number._formatAbsolute method to works woth exponential string representation of very large and small numbers.

[duong.nguyen]

This issue also makes NumberTextBox? validation fails on both very large and very small absolute values, on which toString returns exponential format. I have attached a patch even though it does not fix the precision issue.

[bill]

Can you add a test to your patch?

Reopening this ticket since it is marked "patchwelcome".

[duong.nguyen]

Number test patch test is added

[barbossusus]

This may be a better regular expression: dojo.number._toString = function(value){ ... scientificNotation = valueString.match(/[+\-]*((?:0|[1-9])\d*)(?:[\.][0-9]*){0,1}[eE]([+\-])([0-9]*)/); ... }

[barbossusus]

Please ignore the previous regular expression. This would be a better one: dojo.number._toString = function(value){ ...................................................................................

var valueString = String(value),

scientificNotation = valueString.match(/([+\-]{0,1}(?:0|[1-9][0-9]*)[\.][0-9]*){0,1}[eE]([+\-])([0-9]*)/);

................................................................................... }

Also, see attached screenshot. Thanks.

[dylan]

Need to verify CLA and integrity of patch. Will review for 1.12.

[dylan]

Ticket planning... move current 1.13 tickets out to 1.15 to make it easier to move tickets into the 1.13 milestone.