> > 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 bugs.
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 implemented. > 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). -Travis _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion