[Numpy-discussion] formatting issues, locale and co
Charles R Harris
Mon Dec 29 22:26:52 CST 2008
On Mon, Dec 29, 2008 at 8:12 PM, David Cournapeau <email@example.com>wrote:
> On Mon, Dec 29, 2008 at 4:36 PM, Charles R Harris
> <firstname.lastname@example.org> wrote:
> > On Sun, Dec 28, 2008 at 10:35 PM, David Cournapeau
> > <email@example.com> 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
> >> > 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
> > 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 : '%s' % np.float32(1)
> > Out: '1.0'
> > In : '%f' % np.float32(1)
> > Out: '1.000000'
> > I don't see any way to work around that without changing the way the
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion