[Numpy-discussion] formatting issues, locale and co
Mon Dec 29 21:12:32 CST 2008
On Mon, Dec 29, 2008 at 4:36 PM, Charles R Harris
> On Sun, Dec 28, 2008 at 10:35 PM, David Cournapeau
> <firstname.lastname@example.org> 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 :)
> 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 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
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).
More information about the Numpy-discussion