[PATCH] double and float printing
Dalibor Topic
robilad at yahoo.com
Mon Apr 8 03:13:23 PDT 2002
Hi,
I'm resending the patch with all the files in a
gzipped tar archive. I assume
that the first try didn't get past an attachment size
filter somewhere.
this patch fixes my favorite bug: java.lang.Double and
Float string
conversion. It is so old, that it is even mentioned in
the
FAQ/FAQ.Known-Bugs file.
How does the patch work:
The API spec for toString says that doubles/floats are
printed with
as few digits as necessary to distinguish them from
adjacent
doubles/floats. I interpret it to mean: as few digits
as possible,
as long as converting the result of toString back to
double/float
gives us the value we have started with.
What the new toStringWithPrecision implementations
does, is to run a
binary search over different precisions until it finds
the one
resulting in the String with the least number of
digits, which can be
converted back to the original double.
Where this patch and jdk (1.3.1) differ:
* there are cases where we come up with _less_ digits
than jdk
does. The result still happily converts back to the
original value.
example:
long bits: toString converted
back: bits
converted back:string
(jdk)
-4356742874647865835 -2.31845256772633248E17
-4356742874647865835
-2.31845256772633248E17
(patched kaffe)
-4356742874647865835 -2.3184525677263325E17
-4356742874647865835
-2.3184525677263325E17
* there are cases where we differently represent the
same number:
example:
long bits toString c.b. bits c.b. string
(jdk)
2 1.0E-323 2 1.0E-323
(patched kaffe)
2 9.9E-324 2 9.9E-324
Sprintf from GNU libc 2.2.4 gives me 9.9...E-324 and
refuses to
round up. I'm not sure if sprintf is to blame, or my
sprintf format string.
What it also does:
* the patch removes the over/underflow recognition
from valueOf0. jdk
just returns Infinity or 0.0 and does not throw an
exception.
* it also changes the expected value on two regression
tests to a "correct"
one.
Where this patch is ugly:
* It duplicates code between Double.c & Float.c. I
tried to use a
single version, but my floats were printed with too
many digits. If
someone gets it to work without code duplication, I
owe you a beer:)
* It is slower than the jdk. Factor 2, approximately.
It is also
slower than the previous method. It seems to work
much better than
what we have right now, though.
What's attached:
* the patch
* the changelog
* a test program to verify my claims. Run DPTest with
kaffe/patched
kaffe/jdk and diff the output to see the difference.
have fun.
dalibor topic
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: double.patch.tgz
Type: application/x-tgz
Size: 4872 bytes
Desc: double.patch.tgz
Url : http://kaffe.org/pipermail/kaffe/attachments/20020408/aa683616/attachment-0003.bin
More information about the kaffe
mailing list