numpy.polynomial.polynomial.polyfit and numpy.polyfit return coefficients in different order

[ckrapu]

Hi,

This is my first issue so I apologize if I have gotten something obviously wrong. Essentially, it appears that when using the polyfit function from numpy.polynomial.polynomial, the coefficients are returned with lowest order first; this is the opposite of what happens when the function numpy.polyfit is called. I believe that the documentation for both functions states that the highest order coefficient should be returned first. As an example, I've attached a screenshot of an IPython notebook with a minimal example along with the code. My version of numpy is 1.10.4 and I am on Debian 3.16.0-4.

from numpy.polynomial.polynomial import polyfit 
import numpy as np                            
print np.version.version
print np.polyfit([1,2],[2,4],1)
print polyfit([1,2],[2,4],1)

[ckrapu]

As a quick update - the code is written correctly and the documentation actually does describe what each function returns correctly. This is no longer a bug or a documentation problem. Still, it is confusing that two functions that are very, very similar return values in different ways. This led to an error that was extremely difficult for me to track down as I had chosen to use one version yet assumed output from another.

[granttremblay]

Chiming in to second @ckrapu : this behavior is bizarre and inconsistent with expectations. While the documentation is reasonably clear in noting that coefficients are returned with highest-order last, this is fairly easy to miss, and is inconsistent with, e.g. numpy.polynomial.polynomial.polyfit().

This can result in a very hard to track-down bug in one's code. I'm wondering if this bizarre behavior can be deprecated?

[charris]

No. The polynomial package deals with series. You won't find any texts on complex analysis that start their series with the infinite power. The fact that Matlab (TM) got it wrong is no reason to go there...

[mhvk]

Having the zero-degree coefficient first, as done in numpy.polynomial.polynomial.polyfit is definitely more logical. I was under the impression that the only reason numpy.polyfit deviates from this is historical accident, which of course is nearly impossible to correct now since many programmes may depend on this behaviour. Maybe the easiest solution would be to point people to the "preferred" solution in numpy.polyfit?

[clbarnes]

As well as the order of coefficients being different, the result of the full argument is different: dumps a bunch of extra stuff into the output tuple in numpy.polyfit, and puts them all in a list in numpy.polynomial.polynomial.polyfit. The "correct" API would be for the output signature to be Tuple[np.ndarray, Optional[Tuple[np.ndarray, int, np.ndarray, float]]]]; just as the "correct" ordering of coefficients is 0-first.

This duplication is obviously confusing. It looks identical to the much more common situation of a top-level module re-exporting a common function buried in subpackages. np.polyfit and np.polynomial.polynomial.polyfit should both reference each other in their docs, laying out the differences. One should be picked as the favourite, and the other should have a deprecation warning thrown on it, even if it never gets removed. It doesn't break anyone's code and it encourages the community to pick

one-- and preferably only one --obvious way to do it.

[charris]

I'm going to close this, as the root complaint won't be fixed.