[Numpy-discussion] failure building trunk with mingw
Charles R Harris
charlesr.harris at gmail.com
Sun Nov 22 13:26:57 EST 2009
On Sun, Nov 22, 2009 at 8:37 AM, <josef.pktd at gmail.com> wrote:
> On Sun, Nov 22, 2009 at 10:25 AM, David Cournapeau <cournape at gmail.com>
> wrote:
> > On Mon, Nov 23, 2009 at 12:14 AM, <josef.pktd at gmail.com> wrote:
> >> On Sun, Nov 22, 2009 at 10:01 AM, David Cournapeau <cournape at gmail.com>
> wrote:
> >>> On Sun, Nov 22, 2009 at 11:45 PM, Charles R Harris
> >>> <charlesr.harris at gmail.com> wrote:
> >>>>
> >>>> Might be nice to print out the actual values of np.spacing and
> np.nextafter
> >>>> here.
> >>>>
> >>>
> >>> Yes, I should add some utilities to print those for this kind of test.
> >>> But in this case, I know the problem: mingw gcc use 80 bits long
> >>> double but it uses the MS runtime which considers double and long
> >>> double to be the same (8 bytes).
> >>>
> >>> I think the real fix is to force npy_longdouble to be double on mingw,
> >>> but I don't want to make that change now for 1.4.0.
> >>
> >> adding the failing type in the test to the failure message would also
> >> be helpful
> >
> > Yes, you're right. I also used the nose facility for using generators
> > for complex corner cases, but with retrospect, it is not so useful,
> > because you don't get a name when you have a failure (or maybe I am
> > using it wrong).
>
> I don't know what the policy for the use of assert in numpy is,
> but if you use the function np.testing.assert_ then you can add a
> failure message with eg. repr(t)
>
>
They should all use assert_ as it is designed to work even in optimized
environments. However, this is not enforced, official policy ;)
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20091122/01e22b9e/attachment.html>
More information about the NumPy-Discussion
mailing list