[jira] Updated: (TRINIDAD-1678) TrNumberFormat.prototype.numberToString doesn't account for numbers represented via scientific notation

["Gabrielle Crawford (JIRA)" <de...@myfaces.apache.org>]

     [ https://issues.apache.org/jira/browse/TRINIDAD-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gabrielle Crawford updated TRINIDAD-1678:
-----------------------------------------

    Resolution: Fixed
        Status: Resolved  (was: Patch Available)

> TrNumberFormat.prototype.numberToString doesn't account for numbers represented via scientific notation
> -------------------------------------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1678
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1678
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Components
>    Affects Versions:  1.2.12-core
>            Reporter: Cale Scholl
>            Priority: Minor
>         Attachments: scientificNotation_1.2.12.2.patch, scientificNotation_trunk.patch
>
>
> ISSUE:
> ----------
> Say we have a 22-digit number string "7777777777777777777777". When this is converted to object it becomes 7.777777777777777e+21. This confuses TrNumberFormat.prototype.numberToString, as the poor guy thinks he's dealing with a fractional number, when really it's a big ass integer. 
> FIX:
> -----
> The solution is, when converting from object to string, we first convert the string from scientific notation to standard expanded notation before applying any other formatting. See TrNumberFormat.scientificToExpanded.
> Note that I also added a utility method TrNumberFormat.trimLeadingZeroes. This is preferable to the previous hack -- parseInt(parseFloat(numberString)) -- because parseInt fails to correctly parse numbers represented via scientific notation (e.g. 7.777e+21 becomes 7).
> TESTS:
> ----------
> Tested using the following:
> <af:inputText label="default" id="it1">
>   <af:convertNumber maxFractionDigits="40"/>
> </af:inputText>
> Results:
> (1) "7777777777777777777777" -> 7.777777777777777e+21 -> "7,777,777,777,777,777,000,000"
> (2) "0.00000000000000000000123456" -> 1.23456e-21 -> "0.00000000000000000000123456"
> (3) "1234.567890123456789012" -> 1234.567890123457 -> "1,234.567890123457"
> When would this fix possibly be useful? See case (2) above. That's the only case where scientific notation is used AND we don't lose any precision.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.