Charles R Harris wrote:
Yes, that too. But I was thinking of the ufunc returning nan when needed
I think this is better for consistency, yes. NaN is not a number, so it has no sign :) More seriously, I think those features should be clearly listed and thought out before being implemented, particularly wrt error handling and testing. I would rather see umathmodule.c cleaning first, wo any functionality change, and then, once integrated in the trunk, do the NaN changes in a branch, in particular because of broken implementations which will not do what you expect. Personally, I also have changes for NaN handling, but on my private git import of numpy. Also, if we fix this, we should fix this once for all, and with a lot of tests, if only to test on buggy implementations. cheers, David