[Numpy-discussion] long double woes on win32
Charles R Harris
Sat Aug 16 17:18:09 CDT 2008
On Sat, Aug 16, 2008 at 3:02 PM, Charles R Harris <email@example.com
> On Sat, Aug 16, 2008 at 2:46 PM, David Cournapeau <firstname.lastname@example.org>wrote:
>> On Sat, Aug 16, 2008 at 2:07 PM, Charles R Harris
>> <email@example.com> wrote:
>> > There is seems to be a problem in defining the functions called for the
>> > different types.
>> I don't know enough about this part of the code to be sure about the
>> whole function calls stack, but I would guess this is not surprising
>> and even expected: you force long double to be double, but you still
>> call the long double function if you do np.exp, so this cannot work.
> Part of the problem is that the loops/functions called depend on the
> typecode, i.e., dtype.char, which stays as 'g' even when the underlying type
> is float64. We can't really fix that because the C-API still allows folks to
> create arrays using the typecode and we would have to fudge things so the
> right "wrong" descr was returned. Ugly, and a left over from numeric which
> defined types to match the c types instead of the precision. Maybe we should
> rewrite in FORTRAN ;) Anyway, I think the easiest solution might be to use
> npy_func internally and add a -DNOLONGDOUBLE flag to override the values
> returned by the distutils test code. Whether we should try such a big
> modification before 1.2 is another question.
Another place this could be fixed for the ufuncs is in the ufunc code
generator, i.e., in __umath_generated.c lines like
exp_functions = PyUFunc_g_g;
exp_data = (void *) expl;
could have expl replaced by exp. But there are likely other problems that
will need fixing.
Too bad there isn't a flag in gcc to automatically compile long doubles as
doubles. There *is* one to compile floats as doubles.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion