report at bugs
Jun 25, 2008, 1:30 AM
Post #3 of 37
(379 views)
Permalink
|
Mark Dickinson <dickinsm[at]gmail.com> added the comment:
> -1 on Nick's suggestion to normalize hex output so that nearby floats
> have nearby reprs. This unnecessarily complicates a simple, straight-
> forward presentation. In the paper referenced by Terry Reedy,
> normalized presentations were not used
As far as I can tell, that paper *does* use normalized presentations:
with the exception of subnormals and zeros, all hex floats have a leading
digit of 1. This is the same normalization that Java's toHexString uses,
and that C's printf %a format modifier uses on all machines that I've
tested (though the C standards don't seem to lay down the law on this).
I think this is helpful. For example, on the first page of section 4.1 of
the paper Terry Reedy references, the author gives two different results
produced by running the same sin() computation on different systems. The
results are:
-0x1.95b011554d4b5p-1
and
-0x1.95b0115490ca6p-1.
Looking at these results, it's readily apparent that the error is somewhat
less than 1000 ulps. But the current hex() output for these two numbers
is:
'-0x195b011554d4b5 * 2.0 ** -53'
and
'-0xcad808aa48653 * 2.0 ** -52'
It's much less clear that these numbers are close, or how close they are.
I guess I just have a feeling that changes to the least significant bits
of a number shouldn't produce big changes in its representation.
> and I've never seen that done anywhere else.
I'm not sure I've ever seen this *not* done anywhere else.
P.S. You should blame me for the normalization comment, not Nick. :)
_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com
|
1
