Charles R Harris wrote: > > umathmodule.c is cleaned/done. Or was until I put in some of the nan > handling. But some of the nan comparisons were just odd, in particular > the sign function, which was effectively undefined. And since the > current behavior is an accident of comparison choices and order, I > consider it undefined also. So at a minimum I would fix up > sign/maximum/minimum.
Yes, I was not arguing about making the changes, but about making them together in the same branch. Because I bet you only build on linux, and if something is broken on one platform, it will be difficult to make the difference between pure code changes and feature changes. Whereas if you have two branches (the second being on top of the other one), then we can test the two differently. This makes job of testers much easier, I believe. At least, it makes my life easier when testing with ICC, MS compilers and co. > > I'm am currently working off your branch (at your suggestion). Is it > safe to use NAN? I've just answered to your private email about that point :) > > Yes, the tests will define the standard. There is one test for sign of > complex numbers that currently breaks, but I don't consider that > important as anyone currently relying on sign when the array contains > nans is out of their mind. An option for making the code more portable > is to make the various comparison operators macros, then worry about > fixing the macros for various compilers. Yes, that's by far the best method for compatibility. Implement a layer of compatibility, and then do as if you were on a common platform. That's the whole point of my clean_math_branch, BTW. This make tracking bugs much easier, cheers, David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion