>> >> That's a nice argument for a different convention, really it is. It's not >> enough for changing a convention that already exists. Now, the polynomial >> object could store coefficients in this order, but allow construction with >> the coefficients in the standard convention order. That would have been a >> fine compromise from my perspective. > > I'm much happier with the current solution. As long as I stick with > the np.polynomial classes, I don't have to *think* about coefficient > order. With a hybrid I would always have to worry about whether this > animal is facing front or back.
I don't think you would have to worry about it at all. It would just be an interface you personally wouldn't ever call. In other words, you just provide the option for someone else to specify their *input* arrays in reverse order. You could keep them stored in this "natural order" just as they are now. > I wouldn't mind if the old order is eventually deprecated and dropped. > > (Another example: NIST polynomial follow the new order, 2nd section > http://jpktd.blogspot.ca/2012/03/numerical-accuracy-in-linear-least.html > no [::-1] in the second version.) Thanks for providing the additional references. I do recognize that the convention is in use elsewhere. >> >> It is *much*, *much* easier to create binaries of downstream packages than >> to re-write APIs. I still think we would be better off to remove the >> promise of ABI compatibility in every .X release (perhaps we hold ABI >> compatibility for 2 releases). However, we should preserve API >> compatibility for every release. > > freeze the API wherever it got by "historical accident"? Not quite. You can add new and different APIs. You just can't change old ones. You also have to be careful about changes that break the implied but not specified code contract of current users. Even the strategy of "deprecating APIs needs to be used very judiciously and occasionally. We can deprecate APIs but can't remove them for several releases --- say 4 or 5. You are correct, I'm concerned about users that have built additional packages on top of NumPy. Some of these we know about, many of them we don't know about --- as they are in internal systems. Many users are shielded from NumPy changes by other APIs, this is an avenue of exploration that can and will continue. We aren't there yet, though, and I don't think the "plans for NumPy change" have previously considered enough the impact on users of NumPy. Thank for your voicing your comments and perspective. -Travis _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
