Charles R Harris wrote:
>
>
> On Tue, Mar 10, 2009 at 4:19 PM, Timothy Hochberg
> <[email protected] <mailto:[email protected]>> wrote:
>
>
>
> On Tue, Mar 10, 2009 at 2:49 PM, Charles R Harris
> <[email protected] <mailto:[email protected]>> wrote:
>
>
>
> On Tue, Mar 10, 2009 at 3:16 PM, Stéfan van der Walt
> <[email protected] <mailto:[email protected]>> wrote:
>
> 2009/3/10 Pauli Virtanen <[email protected] <mailto:[email protected]>>:
> > Nonzero Python object, hence True. Moreover, it's also
> True in Python:
>
> Also in C:
>
> #include <math.h>
> #include <stdio.h>
>
> int main() {
> double nan = sqrt(-1);
> printf("%f\n", nan);
> printf("%i\n", bool(nan));
> return 0;
> }
>
> $ ./nan
> nan
> 1
>
>
> So resolved, it is True.
>
>
> I appear to be late to the party, but IMO it should raise an
> exception in those cases where it's feasible to do so.
>
>
> That also seems reasonable to me. There is also the unresolved issue
> of whether casting nan to an integer should raise an exception,
> currently it is just converted to 0.
I think it is reasonable as well - but I am worried about the
integration with seterr (not just for this case, but in general in our
way toward better handling of this kind of things). I note that matlab
convert nan to 0 as well - presumably they did not handle it besides
what C guarantees (that is not much in that case I believe):
a = nan;
int32(a); % gives 0
in C:
#define _ISOC99_SOURCE
#include
<stdio.h>
#include
<math.h>
int
main(void)
{
printf("nan is %f\n",
NAN);
printf("nan is %d\n",
(int)NAN);
return
0;
}
prints nan and 0 respectively - it may well be implementation dependent,
but it seems that (int)nan simply gives back the nan binary representation.
cheers,
David
_______________________________________________
Numpy-discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
