[Numpy-discussion] Binary ufuncs: minimum
Travis E. Oliphant
Tue May 27 17:11:24 CDT 2008
> So the segfaults are defined behavior? ;) It's like pulling teeth
> without anesthesia to get these things defined and everyone is going
> to think I'm an a-hole. It's a dirty job, but someone has got to do it.
I actually appreciate what you are doing. Obviously the segfaults are
It's just that there are constraints we have to work within (unless you
are proposing to change the general versus specific coercion
behavior). These constraints might change the testing approach that is
taken as well as the possible proposed solutions. It's hard to engage
the conversation until the questions show an understanding of that.
My point is that we should look at the code to determine what is the
expected behavior because not only is that what is being done, but that
is also the framework we currently have within which to make changes.
It is not much different from what Numeric originally provided.
Unit tests should help us make sure the code is being executed under all
possible circumstances. I don't know how to do that without actually
looking at the code. The only thing that changes the coercion behavior
in a ufunc-specific way is what underlying loops are available and the
inputs and outputs that are defined.
> What about abs(-128) returning a negative number for int8?
That looks like an issue with the implementation (I didn't realize that
-MIN_INT == MIN_INT in C) and that is how the underlying loop is
> Might it not be better to return the corresponding unsigned type?
This is not a "coercion" rule in my mind --- it is a output type
issues. And yes, we can change this on a per-ufunc basis because the
output type can be defined for each input type in the ufuncs.
Yes, it does make sense to me for abs to use an unsigned type for integers.
> Can't check that at the moment, as I'm trying to get 64 bit Ubuntu
> installed on a software raid1 partition for further checks, and Ubuntu
> overwrote my MBR without asking. It's a traditional Ubuntu thing.
Bummer. I didn't realize Ubuntu was so forceful.
Thanks again for finding all these corner cases that are of interest in
improving NumPy. My point should be distilled down to separating out
what are ufunc inner-loop definition issues (i.e. what are the output
and input types for a given ufunc and how are they implemented) and what
are real "coercion" rule issues because they are very different pieces
of code and we are not very limited in the former case and fairly
limited in the latter (without significantly more work).
More information about the Numpy-discussion