NumberPrintPolicy deficiencies

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

NumberPrintPolicy deficiencies

Steven Kelly
Hi,

Why when I define a NumberPrintPolicy with a thousandsSeparator does it
not get used:

Locale current printAsNumber: 12345. " =>  Text for '12345'  "

I can see HOW to do it - I add a collection of tokens for a format
string like '#,##0.##' as the policy inst var of my Locale's
NumberPrintPolicy (Aside: pretty confusing to call the iv "policy", when
it's not a PrintPolicy). But why are none of the supplied locales doing
this? They all do it for currencies, but not for numbers. At least on
Windows, the locale settings show the thousands separator should be used
for both.

How do I define the policy string so that it gives the right results for
common numbers:

number     results with these formats:
           #,##0     #,##0.######   I would like:
1234       1,234     1,234.         1,234
1234.0     1,234     1,234.         1,234.0
1234.5     1,235     1,234.499968   1,234.5
1234.5d    1,235     1,234.5        1,234.5
1234.5s3   1,235     1,234.5        1,234.500

In other words I either never get the decimal point and digits after it,
or then I always get the decimal point, even if there's nothing after
it. Could we change this so that if the number is an integer, we get no
decimal point, and if it is a float etc. we get the decimal point and at
least the first digit after it?

There are also oddities in how floats behave - 1234.5 printString is
'1234.5', not '1234.499968', so why the difference here? Maybe we need
to merge the good behavior of printString (respects the accuracy of
floating and fixed point numbers, e.g. 1234.5s3 prints 1234.500) with
the ability to format thousands and decimals of NumberPrintPolicy.

I think if our new "optional decimal point" also meant "and display as
many decimal digits after this as the number merits, based on what
printString would do", we would be pretty close - there would be no need
to specify any #'s or 0's after the optional decimal point, but
specifying #'s would limit the maximum number of digits, and specifying
0's would limit the minimum number of digits.

Cheers,
Steve