Из того, что я могу сказать, здесь много унаследованного багажа, и мы не должны использовать numpy.polyfit, и нам следует предпочесть numpy.polynomial.polynomial.Polynomial.fit.
Рассмотрим комментарии к этому выпуску github от 2016 года :
Хотя документация достаточно ясна, отмечая, что коэффициенты возвращаются [из numpy.polyfit - ред. ] с наивысшим значением-последний, это довольно легко пропустить и несовместимо с, например, numpy.polynomial.polynomial.polyfit().
И чуть позже
Имея сначала коэффициент нулевой степени,как это сделано в numpy.polynomial.polynomial.polyfit, определенно более логично. У меня сложилось впечатление, что единственная причина, по которой numpy.polyfit отклоняется от этого, - это историческая случайность, которую, конечно, сейчас почти невозможно исправить, поскольку многие программы могут зависеть от этого поведения. Возможно, самым простым решением было бы указать людям на «предпочтительное» решение в numpy.polyfit?
Из предыдущего комментария очевидно, что «историческая случайность» - это поведение MATLAB's polyfit, который первым принимает высокие заказы. В начале numpy сохранял это запутанное соглашение (которое, возможно, даже унаследовало от предшественника проекта), но позже numpy.polynomial.polynomial.polyfit был реализован для Do It Right ™. Принципиальным отличием является то, что (в отличие от MATLAB) Python использует индексы, основанные на 0, и в этом случае совершенно естественно сначала иметь нулевой порядок. С этим соглашением есть прекрасное свойство, что элемент k соответствует термину x**k.
Тогда есть еще более новая учетная запись в другом выпуске этого года , который пытается придать более согласованный характер. рисунок. Цитируя исторические воспоминания из этого вопроса:
History
(необязательно в хронологическом порядке)
- У определенного пакета линейной алгебры на основе JVM былаФункция
polyfit для подбора многочленов, которые сделали странный выбор дизайна, например, сначала возвращает коэффициенты с наивысшей степенью. - numpy, пытаясь поддержать беглецов из указанной среды, создал функцию
numpy.polyfit, котораяПодчеркнув, что выбор дизайна - NumPy реализован
numpy.ma.polyfit для замаскированных массивов, с использованием numpy.polyfit - В попытке исправить ошибки истории Numpy создал функцию
numpy.polynomial.polynomial.polyfit с почти точнота же подпись, но с более разумным упорядочением коэффициентов, и тихо предпочитали, чтобы люди использовали ее вместо - Люди были смущены этими двумя очень похожими функциями ( # 7478 );Кроме того, новая функция не смогла вернуть ковариационную матрицу, и у нее не было аналога маскированного массива
- При включении как нирваны API, так и изношенных клавиатур, numpy представил класс
numpy.polynomial.polynomial.Polynomial и задокументирован в numpy.polyfit что это был предпочтительный способ подбора полиномов, хотя он также не имел маскированной реализации и также не возвращал ковариационную матрицу
Ответы разработчиков по двум вопросам дают понять, чтоnumpy.polyfit - это технический долг, и, как говорится в его документации, новый код должен использовать класс Polynomial. Документация значительно улучшилась с 2016 года, теперь есть указатели от numpy.polyfit до Polynomial, но все еще остается много неясностей. В идеале оба метода polyfit должны объяснять свою ситуацию относительно других и указывать пользователям класс Polynomial как единственный очевидный способ написания нового кода.