[PATCH] double and float printing

Dalibor Topic robilad at yahoo.com
Mon Apr 8 03:13:23 PDT 2002


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
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
doubles/floats. I interpret it to mean: as few digits
as possible,
as long as converting the result of toString back to
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.


long bits:           toString                converted
back: bits
converted back:string
-4356742874647865835 -2.31845256772633248E17
(patched kaffe)
-4356742874647865835 -2.3184525677263325E17 

* there are cases where we differently represent the
same number:


long bits  toString    c.b. bits   c.b. string
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

* it also changes the expected value on two regression
tests to a "correct" 

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/jdk and diff the output to see the difference.

have fun.

dalibor topic

Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
-------------- 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