[Numpy-discussion] formatting issues, locale and co

[Charles R Harris]

On Mon, Dec 29, 2008 at 8:12 PM, David Cournapeau <cournape at gmail.com>wrote:

> On Mon, Dec 29, 2008 at 4:36 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Sun, Dec 28, 2008 at 10:35 PM, David Cournapeau
> > <david at ar.media.kyoto-u.ac.jp> wrote:
> >>
> >> Charles R Harris wrote:
> >> >
> >> >
> >> >
> >> >     I put my yesterday work in the fix_float_format branch:
> >> >      - it fixes the locale issue
> >> >      - it fixes the long double issue on windows.
> >> >      - it also fixes some tests (we were not testing single precision
> >> >     formatting but twice double precision instead - the single
> precision
> >> >     test fails on the trunk BTW).
> >> >
> >> >
> >> > Curious, I don't see any test failures here. Were the tests actually
> >> > being run or is something else different in your test setup? Or do you
> >> > mean the fixed up test fails.
> >>
> >> The later: if you look at numpy/core/tests/test_print, you will see that
> >> the types tested are np.float, np.double and np.longdouble, but at least
> >> on linux, np.float == np.double, and np.float32 is what we want to test
> >> I suppose here instead.
> >>
> >> >
> >> > Expected, but I would like to see it change because it is kind of
> >> > frustrating. Fixing it probably involves setting a function pointer in
> >> > the type definition but I am not sure about that.
> >>
> >> Hm, it took me a while to get this, but print np.float32(value) can be
> >> controlled through tp_print. Still, it does not work in all cases:
> >>
> >> print np.float32(a) -> call the tp_print
> >> print '%f' % np.float32(a) -> does not call the tp_print (nor
> >> tp_str/tp_repr). I have no idea what going on there.
> >
> > I'll bet it's calling a conversion to python float, i.e., double, because
> of
> > the %f.
>
> Yes, I meant that I did not understand the code path in that case. I
> realize that I don't know how to get the (C) call graph between two
> code points in python, that would be useful. Where are you dtrace on
> linux when I need you :)
>

I'm not sure we are quite on the same page here. The float32 object has a
"convert to python float" method, (which I don't recall at the moment and I
don't have the source to hand). So when %f appears in the format string that
method is called and the resulting python float is formatted in the python
way. Same with %s, only __str__ is called instead.

>
> >
> > In [1]: '%s' % np.float32(1)
> > Out[1]: '1.0'
> >
> > In [2]: '%f' % np.float32(1)
> > Out[2]: '1.000000'
> >
> > I don't see any way to work around that without changing the way the
> python
> > formatting works.
>
> Yes, I think you're right. Specially since python itself is not
> consistent. On python 2.6, windows:
>
> a = complex('inf')
> print a # -> print inf
> print '%s' % a # -> print inf
> print '%f' % a # -> print 1.#INF
>

How does a python inf display on windows?


>
> Which suggests that in that case, it gets directly to stdio without
> much formatting work from python. Maybe it is an oversight ? Anyway, I
> think it would be useful to override the tp_print member ( to avoid
> 'print a' printing 1.#INF).
>

Sounds like the sort of thing the python folks would want to clean up, just
as you have for numpy.

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