Функция round () ведет себя иначе в функции apply ()

Я взял строку из фрейма данных, которая выглядит следующим образом:

https://i.stack.imgur.com/Y9LUE.png

или

Clicks  Spend   clk_ar  CPC     AdRank  temp    tempRan
36.0    248.76  59.94   6.91    1.67    1.665   1.67

Мне нужно округлить значения двумя цифрами в столбце temp

Опция 1:

round(df.temp,2)

OUTPUT:
1676725    1.66
Name: temp, dtype: float64

Вариант 2:

df.temp.apply(lambda x:round(x,2))

OUTPUT:
1676725    1.67
Name: temp, dtype: float64

Две функции раунда показывают разное поведение. Очевидно, что вариант 1 соответствует поведению Python 3. См. Поведение округления Python 3.x

Мне просто интересно, почему вариант 2 так себя ведет. Спасибо за вашу помощь!

См. Также здесь.

DSM 09.08.2018 20:02

Немного удивляет меня то, что извлечение значений из Pandas Series с dtype np.float64 дает реальные объекты Python float, а не объекты NumPy float64. (Два раунда по-разному на Python 3 даже при использовании встроенной функции Python round.)

Mark Dickinson 09.08.2018 20:05

За исключением того, что если вы извлекаете значения из напрямую посредством индексации, вы делать получаете экземпляры np.float64 вместо экземпляров float. Только под apply вы таинственным образом получаете обычные float. Ага!

Mark Dickinson 09.08.2018 20:06
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
4
3
717
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Я думаю, причина здесь в numpy docs

Notes

For values exactly halfway between rounded decimal values, NumPy rounds to the nearest even value. Thus 1.5 and 2.5 round to 2.0, -0.5 and 0.5 round to 0.0, etc. Results may also be surprising due to the inexact representation of decimal fractions in the IEEE floating point standard [1] and errors introduced when scaling by powers of ten.

В варианте 1 вы округляете numpy.float, который использует правила about.

В варианте 2 вы округляете тип данных Python с плавающей запятой документы здесь.

Удовольствие с арифметикой с плавающей запятой:

round(1.675, 2)  
1.68

round(2.675, 2) 
2.67

Это более тонко, чем это. Фактически, round Python во всех случаях следует правилу «ближайших связей к четным», а NumPy - нет. Но из-за обычной природы двоичной с плавающей запятой «То, что вы видите, не то, что вы получаете», фактически округляемое значение - это вовсе не половина дела. На типичной машине фактическое округляемое значение будет 1.66500000000000003552713678800500929355621337890625, которое следует округлить в большую сторону.

Mark Dickinson 09.08.2018 19:52

@MarkDickinson Спасибо за эту информацию и понимание.

Scott Boston 09.08.2018 19:55

Да, прости; Я излишне придираюсь; разница в том, как вы заявляете, что мы округляем экземпляры NumPy float64 по сравнению с обычными float на Python, хотя это немного загадка, почему мы получаем обычные float для Python из Series с dtype np.float64.

Mark Dickinson 09.08.2018 20:08

@MarkDickinson Не нужно извиняться, я ценю такие идеи. Еще раз спасибо.

Scott Boston 09.08.2018 20:09

Другие вопросы по теме