Re: ICU Proposal: change to scientific number format behavior

It's actually very complicated, weird, and somewhat broken.  It's difficult to
figure out how to fix the weirdness and/or brokenness, because I don't know
what part of the wierdness users have come to rely on, although I can get it to
pass our tests ok.  Even making it agree with our docs is a bit of a struggle.

When scientific formatting is on, the maximum integer digits controls the
exponent multiple instead.  (note: this actually used to not work, I'm planning
to fix it).  The number of integer digits you see depends on the exponent
multiple and the minimum number of integer digits. If the minimum number of
integer digits < the maximum number of integer digits, the set minimum is
ignored and the effective minimum is 1.  If the min and max are equal, then the
minimum is observed.

So the value of 1 for maximum integer digits really means that the exponent
isn't adjusted to a multiple.

The number of digits you see depends on a number of things.  The significant
digits are the sum of the minimum integer (what's set) and the minimum/maximum
fractional digits (if you're above the maximum, it rounds).  However, if these
values are zero, there's no minimum (or maximum) fractional digits, you get
whatever it takes to fully represent the number.  How many places appear before
the decimal point depend on the exponent adjustment.

Here are some examples:

mini: 3 maxi: 309 minf: 2 maxf: 2
n:1 --> $100.00E-2
n:12 --> $120.00E-1
n:123 --> $123.00E0
n:1234 --> $123.40E1
n:12345 --> $123.45E2
n:123456 --> $123.46E3
n:1234567 --> $123.46E4
n:12345678 --> $123.46E5

- max int is a default value, essentially it's unlimited
- since max int is > 8, the effective exponent multiple is 1 (my change)
- since the minimum is > the effective exponent multiple, it is observed,
leading to oddities like 100E-2
- the number of significant digits is min int + max frac = 5, so it's rounded
at 5 digits
- the number of displayed digits is 5, so you always get 5 digits

mini: 0 maxi: 1 minf: 0 maxf: 0
n:1 --> 1E0
n:12 --> 1.2E1
n:123 --> 1.23E2
n:1234 --> 1.234E3
n:12345 --> 1.2345E4
n:123456 --> 1.23456E5
n:1234567 --> 1.234567E6
n:12345678 --> 1.2345678E7
n:123456789 --> 1.23456789E8

- the min int is < the effective exponent multiple, so it is ignored and there
is 1 digit before the decimal.
- the number of significant and displayed digits shows everything

mini: 0 maxi: 3 minf: 0 maxf: 0
n:1 --> 1E0
n:12 --> 12E0
n:123 --> 123E0
n:1234 --> 1.234E3
n:12345 --> 12.345E3
n:123456 --> 123.456E3
n:1234567 --> 1.234567E6
n:12345678 --> 12.345678E6
n:123456789 --> 123.456789E6
[...]
n:123456789012345678 --> 123.456789012345678E15

- the effective exponent multiple is 3, so the exponents are adjusted to
multiples of 3 and the number of digits before the decimals are changed to
match("engineering notation").

Doug


--- George Rhoten <[email protected]> wrote:
> What does the value of 1 for maximum integer digits really mean?  The 
> maximum integer digits won't affect the exponent digits, right?  Can you 
> give an example?
> 
> Will this change prevent me from setting the maximum number of integer 
> digits to something like 20?  If I format a 64-bit number, there are times 
> that I will want to format the complete precision of that number (both 
> with integer and scientific notation).
> 
> George Rhoten
> IBM Globalization Center of Competency/ICU  San José, CA, USA
> 
> 
> 
> 
> Doug Felt <[email protected]>
> Sent by: [email protected]
> 10/23/2003 04:56 PM
>  
>         To:     [email protected]
>         cc: 
>         Subject:        ICU Proposal: change to scientific number format 
> behavior
> 
> 
> This proposal affects both ICU4J and ICU4C.  Please comment by Oct 31, 
> 2003.
> 
> In DecimalFormat, setScientificNotation(true) currently changes the state 
> of
> the formatter slightly-- it ensures that the minimum number of exponent 
> digits
> is at least 1.  Although it makes this change, it does not make other 
> changes--
> for example, it does not ensure that the maximum number of integer digits 
> is a
> reasonable number.  The problem with this (see jb2552) is that using a
> formatter with a high maximum outputs text with a large number of 0's.
> 
> This proposal is to change the behavior of setScientificNotation in two 
> ways:
> 1) no longer change the state of the formatter representing the number of
> exponent digits (though it will continue to behave as though the minumum 
> is 1)
> 2) if the maximum number of integer digits is > 8, behave as though the 
> maximum
> is 1.
> 
> This will allow a single call to setScientificNotation(true) to produce a
> formatter that formats numbers in a reasonable manner, and will ensure 
> that a
> subsequent call to setScientificNotation(false) restores the original
> formatter.  The value 8 was chosen as a reasonable upper limit for people 
> using
> exponential notation.
> 
> Other than the implementation change, the only API change is the following
> documentation change to setScientificNotation:
> 
> /**
> * <strong><font face=helvetica color=red>NEW</font></strong>
> * Set whether or not scientific notation is used.  When scientific
> notation
> * is used, the effective maximum number of integer digits is <= 8.  If the
> * maximum number of integer digits is set to more than 8, the effective
> * maximum will be 1.  This allows this call to generate a 'default'
> * scientific number format without additional changes.
> [...]
> */
> 
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
> _______________________________________________
> icu mailing list
> [email protected]
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
> 
> _______________________________________________
> icu mailing list
> [email protected]
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com