| a5a851ef18cf45152fc0901a07e2f6aa303ef702 |
|
24-Oct-2017 |
Joachim Sauer <jsauer@google.com> |
Use DecimalFormat_ICU58_Android in DecimalFormat.
java.text.DecimalFormat delegates most behaviour to
android.icu.text.DecimalFormat.
ICU 59 introduced a variety of behaviour changes many of which are not
desireable to inherit for java.text.DecimalFormat.
This changes java.text.DecimalFormat to delegate to
android.icu.text.DecimalFormat_ICU58_Android instead. This class is the
ICU 58 implementation of DecimalFormat that ICU ships for testing
purposes only.
This is a stop-gap measure until we can get the new implementation
configured in a way to be close enough to the old behaviour to use in
java.text.DecimalFormat.
This commit also partially reverts the test that were changed to
accomodate the switch to ICU 59 in commit
51f8d749d3100694d695fa0cd32d2fb99c02ba74.
The reason the revert is only partial is that not all test changes were
caused by code changes. A significant portion was caused by CLDR changes
which still affect us, even if we use DecimalFormat_ICU58.
Bug: 68143370
Test: CtsLibcoreTestCases
Change-Id: If50d927265136e8de964b54ae879291c7be85cfc
|
| 51f8d749d3100694d695fa0cd32d2fb99c02ba74 |
|
29-Apr-2017 |
Fredrik Roubert <roubert@google.com> |
Updated test expectations for ICU 59.
Bug: 62410016
Test: CtsLibcoreOjTestCases
Test: CtsLibcoreTestCases
Change-Id: I49de49cd356f6e28429e4fc22d493f77b5efe4c5
|
| ab22958b647b5e06711539bf3bf1082bc3b007da |
|
16-Feb-2017 |
Adam Vartanian <flooey@google.com> |
Fix and reenable DecimalFormatTest
The problems underlying the suppressed DecimalFormatTest test cases have
been fixed, but the test had a separate bug where it appropriately
truncated the output for formatting a very large number but didn't scale
it properly, so the test was still failing.
Also fix the bug reference for a different text-formatting suppression.
Bug: 17656132
Test: vogar ... org.apache.harmony.tests.java.text.DecimalFormatTest
Test: cts run -m CtsLibcoreTestCases -t org.apache.harmony.tests.java.text.DecimalFormatTest
Change-Id: I85266515e6645627f5aa9200c0d1de41f9ac9cc0
|
| ee45ecd0a2b6f276ec7eca4dddfb9b1351c0c042 |
|
25-Oct-2016 |
Fredrik Roubert <roubert@google.com> |
Updated test expectations for ICU 58.
Bug: 31328818
Test: CtsLibcoreOjTestCases
Test: CtsLibcoreTestCases
Change-Id: Iee8abcf03bbd580aa12cf9ff3b2e9435be03d1f1
|
| 34ba8b516b5fd28fbf6a8608be6a7596716a8166 |
|
17-Jul-2015 |
Rayhaan Jaufeerally <rayhaan@google.com> |
Migrate DecimalFormat to use ICU4J.
This change migrates the underlying implementation of
DecimalFormat to use the Java version of the ICU library.
All all issues related to Harmony test failures have been
tracked down and everything not yet fixed in ICU has a
draft fix in the following commits:
https://android.googlesource.com/platform/external/icu/+/7a53939fbc0103d77d09d0174c52df850363caff
https://android.googlesource.com/platform/external/icu/+/90d4668d4d710507b3302de044e3a398cc4fe5ba
https://android.googlesource.com/platform/external/icu/+/4de0761d798b9a92826397e603835c742c8ff873
Behaviour change: Now a new instance of DecimalFormat()
has 309 as the maximumIntegerDigits instead of 20000000
which it was before. This is because it doesn't make
sense to have this value when ICU will only use up to 309
to format numbers.
Furthermore, ICU4J now returns patterns in the form of
<positive-part>;<negative-part> for displaying the
difference between positive and negative number formats.
Tests have been adjusted accordingly.
Benchmarks:
benchmark JAVA NATIVE
_formatAsExponent10e100 96 40
_formatAsExponent10e1000 13 34
_formatAsExponent10e3 37 33
_formatAsExponent10e9 38 33
_formatBigDecimal10e100 99 64
_formatBigDecimal10e1000 306 249
_formatBigDecimal10e3 34 29
_formatBigDecimal10e9 39 33
_formatE 18 39
_formatEur 7 22
_formatEurWithCents 14 37
_formatGrouping_BigDecimal10e100 104 63
_formatGrouping_BigDecimal10e1000 307 249
_formatGrouping_BigDecimal10e3 34 29
_formatGrouping_BigDecimal10e9 35 34
_formatPi 18 39
_formatToCharacterIterator10e100 3231 148
_formatToCharacterIterator10e1000 90411 4789
_formatToCharacterIterator10e3 163 34
_formatToCharacterIterator10e9 318 44
_formatUSD 8 31
_formatUsdWithCents 14 38
Tested on Nexus 5, times in us.
Change-Id: I642fd02acd3bcd198960cdf2a8d973db7baec42b
|
| bf164d9eda14761f4b86d52e637d9f3287b9fa96 |
|
01-Oct-2014 |
Neil Fuller <nfuller@google.com> |
Applying skipped merges
This contains previously-skipped merges for:
bd1ed0e0
93ad3c2a
Change-Id: Ied3a7d9b0b8dc93de4a5c93ed962fb73324c3891
|
| 5e46bd928832dc638f41f9959427bef088d2184e |
|
26-Sep-2014 |
Neil Fuller <nfuller@google.com> |
Rewrite tests and add tests that demonstrate a bug
The bug:
DecimalFormat.format() behavior is slightly
lossy around 15 decimal digits even without any
digit constraints.
This change isolates the test failures that result from
this bug to 2 test cases:
test_formatDouble_bug17656132
test_formatDouble_roundingProblemCases
Example of the bug:
Double: 999999999999999.9 is represented as an IEEE 754
value which is exactly decimal 999999999999999.875
When format(999999999999999.9) is called on a DecimalFormat
with large MaxIntegerDigit and MaxFractionDigit....
Correct answer: "999999999999999.9"
Actual answer: "1000000000000000"
By contrast Double.toString() prints 9.999999999999999E14
for Android and the RI (correctly).
The DecimalFormat is printing to 16 decimal digits: The
inclusion of the 16th digit implies slightly more precision
than IEEE 754 provides (~15.9 decimal digits for most of the
representable range).
However, the use of 16 decimal digits for outputting IEEE 754
appears consistent with Double.toString() and elsewhere.
Before printing, DecimalFormat appears to be rounding to
15 decimal digits internally (or something similar).
Parsing "1000000000000000" produces a different double
representation than the original double
(one that is closer to 1000000000000000 than
999999999999999.9). This is the bug - we just lost information.
We should be able to round-trip a double if there is no rounding
since every double is representable with decimal and we have
sufficient digits available to represent it (close enough) in
decimal.
Additional tests have been added to demonstrate the bug
and also demonstrate the (correct) formatting behavior when the
formatter is rounding.
test_formatDouble_maxFractionDigits: rounding at 1, 10, 14 digits
after the dp.
test_formatDouble_roundingTo15Digits: rounding at 15 total digits
overall
test_formatDouble_bug17656132: Demonstrates the bug concisely.
The test changes:
test_formatDouble_wideRange():
implicitly assumed that the any loss of accuracy
when a decimal string was turned into a double
would be undone when format() was called, and it would
always arrive back at the original string. The test
has been re-written here to use BigDecimal rather than
Double.parseDouble(), and to compare two doubles rather
than original string with the output from format().
The test was previously failing with the RI for 1E23:
the closest representable double to 1E23 is exactly
99999999999999991611392.
The value produces "99999999999999990000000" when formatted
with the RI and not "100000000000000000000000". On Android
it was passing for 1E23 because of bug 17656132 rounding
back to the original decimal value.
This test was previously failing on Android with 1E-309 because
below 1E-308 IEEE 754 starts losing precision and the closest
representable value is not close to the original string. The
test now isn't affected if the double being tested is not close
to the original decimal; it passes providing the can be round
tripped.
test_formatDouble_roundingProblemCases: Re-written like the
_wideRange test but continues to demonstrate the bug due to
the test values (intentionally) chosen.
Bug: 17656132
(cherry picked from commit 4e92b6265acb1d12109e311819dd64b27ec85df5)
Change-Id: I0b3245d8984999b2731508bb90de785492bb211b
|
| 93ad3c2aba58918769a99b1fcf842fc92b473511 |
|
25-Sep-2014 |
Neil Fuller <nfuller@google.com> |
Fixing formatDouble scientific notation tests
Rather than having perpetually failing test cases the current Android
behavior has been captured and compared against the Android docs.
The "problem cases" have been merged into one test.
The tests now execute all format() calls and report at the end if any
fail, rather than failing at the first problem. This makes debugging
and comparison easier.
Each output from the affected tests has been inspected. The formatter
settings and some justification have been documented in the tests for
later engineers.
For format() with scientific notation the desired behavior is often
unclear because some parts of the docs contradict others about how
much the min/max integer/fraction values are used.
Many of the "problem cases" were the result of the significant
digit rules not being obeyed by the RI which probably introduced
doubt as to whether Android/ICU was correct.
None of the results were found to be actually wrong, i.e. they appear
to output the input number to the correct amount of precision.
When using min/max integer/fraction digits (i.e. not using '@'
characters), apparently by design DecimalFormat does
not produce strings that make clear the number of significant digits
used to generate them. e.g. 1.0 output to 4 sig digits does not output
1.000E0, but may output 1.0E0 or 1E0 depending on the pattern.
Bug reports have been created to record why some categories of results
are ok or to follow up where behavior is open to interpretation, e.g.
the choice of exponent, or whether leading or trailing zeros are
present in the output.
Bug: 17654561
Bug: 17653864
Bug: 17652647
Bug: 17652196
Bug: 12781028
(cherry picked from commit 279c42d3171bb72601f24de842a8770f903edcfe)
Change-Id: I2968e1d977a8a4e40381da330e38209a268d90fb
|
| bd1ed0e04e15d81a8a1f9eae1ce14c0d2829bb35 |
|
23-Sep-2014 |
Neil Fuller <nfuller@google.com> |
Tidy up DecimalFormatTest
The intent is to clean up the code to make it more obvious
where things are failing and why. The names of the tests now
better reflect their purpose and the code is reformatted.
Some tests have been merged where they overlapped and some
have been split.
(cherry picked from commit 8f4123761cebf7a925b1df887282014e420ac14e)
Change-Id: Ia0e99d3620c30933f9a6ed1143b915dd843e521e
|
| 4e92b6265acb1d12109e311819dd64b27ec85df5 |
|
26-Sep-2014 |
Neil Fuller <nfuller@google.com> |
Rewrite tests and add tests that demonstrate a bug
The bug:
DecimalFormat.format() behavior is slightly
lossy around 15 decimal digits even without any
digit constraints.
This change isolates the test failures that result from
this bug to 2 test cases:
test_formatDouble_bug17656132
test_formatDouble_roundingProblemCases
Example of the bug:
Double: 999999999999999.9 is represented as an IEEE 754
value which is exactly decimal 999999999999999.875
When format(999999999999999.9) is called on a DecimalFormat
with large MaxIntegerDigit and MaxFractionDigit....
Correct answer: "999999999999999.9"
Actual answer: "1000000000000000"
By contrast Double.toString() prints 9.999999999999999E14
for Android and the RI (correctly).
The DecimalFormat is printing to 16 decimal digits: The
inclusion of the 16th digit implies slightly more precision
than IEEE 754 provides (~15.9 decimal digits for most of the
representable range).
However, the use of 16 decimal digits for outputting IEEE 754
appears consistent with Double.toString() and elsewhere.
Before printing, DecimalFormat appears to be rounding to
15 decimal digits internally (or something similar).
Parsing "1000000000000000" produces a different double
representation than the original double
(one that is closer to 1000000000000000 than
999999999999999.9). This is the bug - we just lost information.
We should be able to round-trip a double if there is no rounding
since every double is representable with decimal and we have
sufficient digits available to represent it (close enough) in
decimal.
Additional tests have been added to demonstrate the bug
and also demonstrate the (correct) formatting behavior when the
formatter is rounding.
test_formatDouble_maxFractionDigits: rounding at 1, 10, 14 digits
after the dp.
test_formatDouble_roundingTo15Digits: rounding at 15 total digits
overall
test_formatDouble_bug17656132: Demonstrates the bug concisely.
The test changes:
test_formatDouble_wideRange():
implicitly assumed that the any loss of accuracy
when a decimal string was turned into a double
would be undone when format() was called, and it would
always arrive back at the original string. The test
has been re-written here to use BigDecimal rather than
Double.parseDouble(), and to compare two doubles rather
than original string with the output from format().
The test was previously failing with the RI for 1E23:
the closest representable double to 1E23 is exactly
99999999999999991611392.
The value produces "99999999999999990000000" when formatted
with the RI and not "100000000000000000000000". On Android
it was passing for 1E23 because of bug 17656132 rounding
back to the original decimal value.
This test was previously failing on Android with 1E-309 because
below 1E-308 IEEE 754 starts losing precision and the closest
representable value is not close to the original string. The
test now isn't affected if the double being tested is not close
to the original decimal; it passes providing the can be round
tripped.
test_formatDouble_roundingProblemCases: Re-written like the
_wideRange test but continues to demonstrate the bug due to
the test values (intentionally) chosen.
Bug: 17656132
Change-Id: I7d81e38bd1f9dbfd1e1b2caa60a6bb16b871b925
|
| 279c42d3171bb72601f24de842a8770f903edcfe |
|
25-Sep-2014 |
Neil Fuller <nfuller@google.com> |
Fixing formatDouble scientific notation tests
Rather than having perpetually failing test cases the current Android
behavior has been captured and compared against the Android docs.
The "problem cases" have been merged into one test.
The tests now execute all format() calls and report at the end if any
fail, rather than failing at the first problem. This makes debugging
and comparison easier.
Each output from the affected tests has been inspected. The formatter
settings and some justification have been documented in the tests for
later engineers.
For format() with scientific notation the desired behavior is often
unclear because some parts of the docs contradict others about how
much the min/max integer/fraction values are used.
Many of the "problem cases" were the result of the significant
digit rules not being obeyed by the RI which probably introduced
doubt as to whether Android/ICU was correct.
None of the results were found to be actually wrong, i.e. they appear
to output the input number to the correct amount of precision.
When using min/max integer/fraction digits (i.e. not using '@'
characters), apparently by design DecimalFormat does
not produce strings that make clear the number of significant digits
used to generate them. e.g. 1.0 output to 4 sig digits does not output
1.000E0, but may output 1.0E0 or 1E0 depending on the pattern.
Bug reports have been created to record why some categories of results
are ok or to follow up where behavior is open to interpretation, e.g.
the choice of exponent, or whether leading or trailing zeros are
present in the output.
Bug: 17654561
Bug: 17653864
Bug: 17652647
Bug: 17652196
Bug: 12781028
Change-Id: I6b3944b40ff837ecafd1b1be62c5824edb979930
|
| 8f4123761cebf7a925b1df887282014e420ac14e |
|
23-Sep-2014 |
Neil Fuller <nfuller@google.com> |
Tidy up DecimalFormatTest
The intent is to clean up the code to make it more obvious
where things are failing and why. The names of the tests now
better reflect their purpose and the code is reformatted.
Some tests have been merged where they overlapped and some
have been split.
Change-Id: Ic31e2062c2682b6b3ac349c8fb76c9b9809e2150
|
| e5fea3d504609d22337a5311d3ce0e72314bceee |
|
15-Nov-2013 |
Narayan Kamath <narayan@google.com> |
Use a consistent package path for harmony tests.
Harmony was never consistent about where they put their
tests. There's no reason we have to be the same.
Also, there's no need to have separate subtrees for nio,
nio_char etc. etc.
This change makes all existing apache harmony tests
subpackages of "org.apache.harmony.tests" and put them under
libcore/harmony-tests.
We somehow managed to end up with two vastly different
copies of CharsetDecoderTest & CharsetEncoderTest. I've
renamed the copies CharsetDecoder2Test & CharsetEncoder2Test
to avoid having to go in and resolve the complicated
diffs or speculate about the reasons for their
divergence.
Change-Id: Ic34e69c2faab8893edd54e05eccd7091f4a09abd
|
| 4ee5bab39d817c293d5bcc1f9a93af97368946ee |
|
05-Sep-2013 |
Elliott Hughes <enh@google.com> |
More java.text test cleanup/fixes.
I investigated http://bugs.icu-project.org/trac/ticket/10353 further
and decided it's WAI, so we can remove a TODO implying that icu4c was
incorrect. Also merge the remaining OldDecimalFormatTest tests, removing
duplication.
Change-Id: I1941dd1bef3b5eae258960ca8a5fcd2e7de0c926
|
| 8c80e6bbbe48bc1a3a2c0c0a2eed252e1c04ea2c |
|
05-Sep-2013 |
Elliott Hughes <enh@google.com> |
Only use public API for icu4c's FieldPositionIterator.
Change-Id: I247f7c644537b8e9f67f4f27360ce1449fa04300
|
| 8f9976752b2a6e834994ca5790025bc46a3ef340 |
|
31-Aug-2013 |
Elliott Hughes <enh@google.com> |
Fix a DecimalFormat crash when formatting the empty string.
We don't even need a general-purpose iterator, and it's never exposed
to user code, so we can simplify things quite a bit. The key change
though is that a null array is not an error condition --- it just
means we didn't actually output anything.
Bug: https://code.google.com/p/android/issues/detail?id=59600
Change-Id: I7ec0bab00e15ab5c3a4dbd15e2dc81494f68e82f
|
| 74473971cc9d960376295fbcc430320c9ed62991 |
|
29-Aug-2013 |
Elliott Hughes <enh@google.com> |
Fix harmony java.text test failures.
There were plenty of bad tests here, but there were some real bugs too.
* DecimalFormat was only handling RoundingMode.UNNECESSARY for double
formatting.
* DecimalFormat was not ensuring that it's superclass' fields were
being correctly updated.
* NumberFormat was throwing NPE for a null object because of an
improved detail message, despite being specified to throw IAE.
* We weren't mapping NumberFormat.Field instances to the corresponding icu4c
UNUM_x_FIELD constant, so we weren't actually setting FieldPosition
objects correctly.
* SimpleDateFormat was not formatting milliseconds correctly with 'S'.
* NativeDecimalFormat wasn't handling JNI NewString OOME correctly.
Bug: 2528220
Bug: 3056865
Bug: 3057080
Bug: 3057090
Change-Id: Iac11f902f2e9649e596e7e7b7bc501b13e956fca
|
| 994e4e5ded616a100ca42b16cffa36aa9f595f64 |
|
28-Aug-2013 |
Elliott Hughes <enh@google.com> |
Add harmony java.text tests.
Change-Id: Id8d0acd77d08ff337b4851ae74a48cc002d66cd9
|