On Mon, Dec 29, 2008 at 4:36 PM, Charles R Harris

<charlesr.harris@gmail.com> wrote:
>
>

> On Sun, Dec 28, 2008 at 10:35 PM, David Cournapeau
> <david@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 :)

>
> 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

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).