On Wed, Mar 11, 2009 at 11:41 AM, Charles R Harris < charlesr.har...@gmail.com> wrote:
> > > On Wed, Mar 11, 2009 at 11:06 AM, Christopher Barker < > chris.bar...@noaa.gov> wrote: > >> Sturla Molden wrote: >> > Why not raise an exception when NaN is evaluated in a boolean >> > context? bool(NaN) has no obvious interpretation, so it should be >> > considered an error. >> >> +1 >> >> Though there is clearly a lot of legacy around this, so maybe it's best >> to follow C convention (sigh). >> >> Bruce Southey wrote: >> > Also, I think that conversion to an integer should be an error for >> > all of these because there is no equivalent representation of these >> > floating point numbers as integers and I think that using zero for >> > NaN is wrong. >> >> +1 >> >> A silent wrong conversion is MUCH worse than an exception! >> >> As for MATLAB, it was entirely doubles for a long time -- I don't think >> it's a good example of well thought-out float<->integer interactions. >> >> >> > Now for the other two special representations, I would presume that >> > Numpy's PZERO (positive zero) and NZERO (negative zero) are treated >> > as nothing. Conversion to integer for these should be zero. >> >> +1 >> >> > Note this defines the min/max behavior: >> > >> > * |min(x,NaN) = min(NaN,x) = x| * |max(x,NaN) = max(NaN,x) = x| >> >> nice -- it's nice to have these defined -- of course, who knows how long >> it will be (never?) before compilers/libraries support this. >> > > Raising exceptions in ufuncs is going to take some work as the inner loops > are void functions without any means of indicating an error. Exceptions > also need to be thread safe. So I am not opposed but it is something for the > future. > > Casting seems to be implemented in arraytypes.inc.src as void functions > also without provision for errors. I would also like to see casting > implemented as ufuncs but that is a separate discussion. > Hmm, I don't really want to see type conversions go through all the calling machinery of ufuncs. Let's say I'd like to see the kind of inner loops used for ufuncs also used for type conversions. So I would see introducing exceptions starting with at least two steps: 1) Have ufunc type loops return an integer error code. This should just involve replacing void with int and returning 0 in the current loops. 2) Change the type conversion loops to ufunc type loops. Chuck
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
