[issue1580] Use shorter float repr when possible

2009-02-25 Thread Preston Briggs

Preston Briggs  added the comment:

In all this discussion, it seems that we have not discussed the
possibility of adapting David Gay's code, dtoa.c, which nicely handles
both halves of the problem.  It's also free and has been well exercised
over the years.

It's available here: http://www.netlib.org/fp/

It'd probably have to be touched up a bit.  Guido notes that, for
example, malloc is called without checking the return value. 
Nevertheless, the core is what we're looking for, I believe.

It's described in the paper: "Correctly rounded binary-decimal and
decimal-binary conversions", David M. Gay

It comes recommended by Steele and White (output) and by Clinger
(input), in the retrospectives on their seminal papers.

--
nosy: +preston

___
Python tracker 
<http://bugs.python.org/issue1580>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1580] Use shorter float repr when possible

2009-02-25 Thread Preston Briggs

Preston Briggs  added the comment:

>> It'd probably have to be touched up a bit.

> This may be an understatement. :-)

Probably so.  Nevertheless, it's got to be easier
than approaching the problem from scratch.
And considering that this discussion has been
going on for over a year now, it might be a way to
move forward.

> In the first 50 lines of the 3897-line dtoa.c file, I see this warning:
>
> /* On a machine with IEEE extended-precision registers, it is
>  * necessary to specify double-precision (53-bit) rounding precision
>  * before invoking strtod or dtoa.  [...] */
>
> It seems to me that figuring out how and when to do this, and
> writing and testing the appropriate configure/pyport/whatever
> code, is already a nontrivial task.

I would consider compiling the library with flags appropriate to forcing
64-bit IEEE arithmetic if possible.  Another possibility is to explore
gdtoa.c
which is supposed to include code for extended precision, quad precision,
etc.

Added file: http://bugs.python.org/file13176/unnamed

___
Python tracker 
<http://bugs.python.org/issue1580>
___>> It'd probably have to be touched up a 
bit.

> This may be an understatement. :-)Probably so.  Nevertheless, 
it's got to be easierthan approaching the problem from scratch.And 
considering that this discussion has beengoing on for over a year now, it 
might be a way to
move forward.
> In the first 50 lines of the 3897-line dtoa.c file, I see this 
warning:
> 
> /* On a machine with IEEE extended-precision registers, it is
>  * necessary to specify double-precision (53-bit) rounding precision
>  * before invoking strtod or dtoa.  [...] */
> 
> It seems to me that figuring out how and when to do this, and> 
writing and testing the appropriate configure/pyport/whatever
> code, is already a nontrivial task.
I would consider compiling the library with flags appropriate to 
forcing64-bit IEEE arithmetic if possible.  Another possibility is to 
explore gdtoa.cwhich is supposed to include code for extended precision, 
quad precision, etc.

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1580] Use shorter float repr when possible

2009-02-26 Thread Preston Briggs

Preston Briggs  added the comment:

This all started with email to Guido that y'all didn't see,
wherein I wondered if Python was interested in such a thing.
Guido said: Sure, in principle, please see the discussion associated
with this change.

I probably don't have all the required expertise today,
but I am patient and persistent.  I wouldn't be very fast either,
'cause I have other things on my plate.  Nevertheless, it seems like
an interesting project and I'm happy to work on it.

If Mark or someone else wants to jump in, that's fine too.

Preston

Added file: http://bugs.python.org/file13199/unnamed

___
Python tracker 
<http://bugs.python.org/issue1580>
___This all started with email to Guido that y'all didn't see,wherein 
I wondered if Python was interested in such a thing.Guido said: Sure, in 
principle, please see the discussion associatedwith this change.
I probably don't have all the required expertise today,but I am 
patient and persistent.  I wouldn't be very fast either,'cause I 
have other things on my plate.  Nevertheless, it seems likean interesting 
project and I'm happy to work on it.
If Mark or someone else wants to jump in, that's fine 
too.Preston
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com