[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
>
>
>
> svn blame tells me that those have been there unchanged since 1999.
>

I left this note on my ticket.

 These values should really be determined at compile time, not hardwired in
at lines 611-621 of scalartypes.inc.src. Maybe use the values in float.h,
which on my machine give

single digits 6
double digits 15
long double digits 18

The current values we are using are 8, 17, and 22 whereas the values above
are supposed to guarantee reversible conversion to and from decimal. Of
course, that doesn't seem to be the case in practice, they seem to need at
least one more digit. The other question is if all the common compilers
support float.h

The numbers above were generated by

#include <float.h>
#include <stdio.h>

int main(int argc, char** argv)
{
    printf("single digits %d\n",FLT_DIG);
    printf("double digits %d\n",DBL_DIG);
    printf("long double digits %d\n",LDBL_DIG);

    return 1;
}

The reason I wanted to use float.h for the repr precisions is that at some
point long double is bound to be quad precision, I think it already is on
some machines and it used to be on vaxen. So I wanted it to carry over
naturally when the change came. I note that arrays and scalars print
differently and I'm not sure where the array print is implemented.

Chuck


>
> You may want to steal the function format_float() that is defined in
> that file, too.
>

I'll look at it. At the moment we use %.*g

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