[Numpy-discussion] problem with float64's str()

[Charles R Harris]

On Thu, Apr 10, 2008 at 7:06 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Thu, Apr 10, 2008 at 7:57 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> > On Thu, Apr 10, 2008 at 6:38 PM, Robert Kern <robert.kern at gmail.com>
> wrote:
> > >
> > > On Thu, Apr 10, 2008 at 7:31 PM, Charles R Harris
> > > <charlesr.harris at gmail.com> wrote:
> > > > > That said, str(float_numpy_scalar) really should have the same
> rules
> > > > > as str(some_python_float).
> > > >
> > > > For all different precisions?
> > >
> > > No. I should have said str(float64_numpy_scalar). I am content to
> > > leave the other types alone.
> > >
> > > > And what should the rules be.
> > >
> > > All Python does is use a lower decimal precision for __str__ than
> > __repr__.
> > >
> > >
> > > > I note that
> > > > numpy doesn't distinguish between repr and str, maybe we could
> specify
> > > > different behavior for the two.
> > >
> > > Yes, precisely.
> >
> > Well, I know where to do that and have a ticket for it. What I would
> also
> > like to do is use float.h for setting the repr precision, but I am not
> sure
> > I can count on its presence as it only became part of the spec in 1999.
> Then
> > again, that's almost ten years ago. Anyway,  python on my machine
> generates
> > 12 significant digits. Is that common to everyone?
>
> Here is the relevant portion of Objects/floatobject.c:
>
> /* Precisions used by repr() and str(), respectively.
>
>   The repr() precision (17 significant decimal digits) is the minimal
> number
>   that is guaranteed to have enough precision so that if the number is
> read
>   back in the exact same binary value is recreated.  This is true for IEEE
>   floating point by design, and also happens to work for all other modern
>   hardware.
>
>   The str() precision is chosen so that in most cases, the rounding noise
>   created by various operations is suppressed, while giving plenty of
>   precision for practical use.
>
> */
>
> #define PREC_REPR       17
> #define PREC_STR        12
>
>
OK, I've committed a change that fixes the problem that started this thread,
but I'm going to leave the ticket open for a while until I decide what to do
about longdouble. The precisions are now

#define FLOATPREC_REPR 8
#define FLOATPREC_STR 6
#define DOUBLEPREC_REPR 17
#define DOUBLEPREC_STR 12
#if SIZEOF_LONGDOUBLE == SIZEOF_DOUBLE
#define LONGDOUBLEPREC_REPR DOUBLEPREC_REPR
#define LONGDOUBLEPREC_STR DOUBLEPREC_STR
#else /* More than probably needed on Intel FP */
#define LONGDOUBLEPREC_REPR 20
#define LONGDOUBLEPREC_STR 12
#endif

I'm open to suggestions.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080410/eac909aa/attachment.html>