[Numpy-discussion] long double woes on win32

Charles R Harris charlesr.harris at gmail.com
Sat Aug 16 10:11:01 EDT 2008


On Sat, Aug 16, 2008 at 12:47 AM, David Cournapeau <cournape at gmail.com>wrote:

> On Fri, Aug 15, 2008 at 7:11 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> > Doesn't mingw use the MSVC library?
>
> Yes, it does. But long double is both a compiler and library issue.
> sizeof(long double) is defined by the compiler, and it is different
> with mingw and visual studio ATM. I don't know what the correct
> behavior should be, but the fact is that they are different.
>
> > are the same type, so this seems to be a bug in mingw. I suppose numpy
> could
> > detect this situation and define the types to be identical, but if this
> is
> > impractical, then perhaps the best thing to do is issue an error message.
>
> It is impractical in the short term because defining SIZE_LONG_DOUBLE
> to 8 breaks the mingw build, and fixing it would require fixing the
> whole math function configuration (the whole HAVE_LONGDOUBLE_FUNCS and
> co mess). That's highly non trivial code because of the tens of
> different possible configurations, and is fundamental to the whole
> numpy, since it affects the math functions effectively used.
>
> > There's isn't much you can do about long doubles while maintaining MSVC
> > compatibility.
>
> Does that mean you are in favor of letting things the way they are now
> for 1.2, and fix this on 1.3/1.2.1 ?
>

Yes. I don't think MS will support "true" long doubles any time soon and
this affects printing and the math functions. I'm not sure what the best
solution is, there are various possibilities.

1) We could define the numpy longdouble type to be double, which makes us
compatible with MS and is effectively what numpy compiled with MSVC does
since MSVC long doubles are doubles. Perhaps this could be done by adding a
-DNOLONGDOUBLE flag to the compiler flags and then defining longdouble to
double. But this means auditing the code to make sure the long double type
is never explicitly used so that the mingw compiler does the right thing. I
don't think this should be a problem otherwise except for the loss of "true"
long doubles and their extra bit of precision.

2) We can keep the mingw "true" long doubles and avoid any reliance on the
MS library. This may already be done for the math functions by effectively
computing the long double functions as doubles, but I will have to check on
that. In any case, some of the usefulness of long doubles will still be
lost.

3) We can write our own library functions. That seems like a lot of work but
perhaps there is something in the BSD library we could use. I think BSD uses
the gnu compiler but has it's own libraries.

In any case, these solutions all look to be more than two weeks down the
road, so in the short term we probably have to go with the current
behaviour.

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


More information about the NumPy-Discussion mailing list