Помощь зала

[ny_quant]

Будь проклят тот день, когда я сел за баранку этого пылесоса! (с)

Я уже не буду говорить по сотому разу про семантику питона, индентацию и неудобный дебаггер. Самая феноменальная черта питона это непредсказуемое поведение, когда буквально один и тот же (скопипащенный) код в одном месте работает, а в другом нет, и понять в чем дело нельзя от слова никак. Сегодня у меня выдался особенно интересный день, в том смысле, что удалось наступить на одни и те же грабли дважды. Причем второй раз обошлось даже без копипасты, а прямо в одном и том же месте в цикле. Жил да был один dataframe, никого не трогал, починял примус. В одном месте к нему применялась операция groupby. И все шло хорошо пока я не поменял один из параметров, которые контролируют процесс наполнения этого dataframe. И вдруг ни с того ни с сего привет из черного ящика:

File "C:\Users\...\AppData\Local\Programs\Python\Python38\lib\site-packages\pandas\core\groupby\groupby.py", line 747, in get_group
raise KeyError(name)

Что-то где-то пошло не так, очевидно гораздо раньше, чем случилась ошибка. Дай думаю выведу данные на экран - может пойму в чем дело. Код выглядел так:

print(pos)
positions = pos.groupby(by='sign')
print(positions)
longs = positions.get_group(1)

Цикл этот проработал очень много раз без проблем. На предыдущей перед обломом итерации напечаталось:

... ......exdate ......strike. sign
619 20170616.0 2200.0 1.0
620 20170616.0 2200.0 1.0
<много похожих строк>
792 20170421.0 2475.0 -1.0
793 20170421.0 2475.0 -1.0

pandas.core.groupby.generic.DataFrameGroupBy object at 0x000001DB90D0A760

(Точки я добавил в тело поста, чтобы подравнять заголовки колонок.) А в последний раз вот что:

... ......exdate ......strike. sign
619 20170616.0 2200.0 1.0
620 20170616.0 2200.0 1.0
<много похожих строк>
817 20170616.0 2445.0 -1.0
818 20170616.0 2445.0 -1.0

Empty DataFrame
Columns: [exdate, strike, sign]
Index: []

Empty DataFrame, вон оно как! Понятно теперь почему оттуда ничего нельзя вынуть и оно ломается. Но почему оно пустое??!! Колонка 'sign' есть? Есть. Числа в ней есть? Есть, причем в каждой строчке. Так какого же черта??? И что вообще люди делают в таких случаях? Идти дебаггером в библиотеку и искать почему оно ломается в groupby.py?

Пока что я схитрил и вместо

positions = pos.groupby(by='sign')
longs = positions.get_group(1)

написал

longs = pos[pos['sign'] > 0]

Это отлично сработало, причем для тех параметров, при которых groupby() работал без аварии, результаты получились идентичные. Это, конечно, хорошо, но не покидает ощущение, что ходишь по минному полю как ночью по тайге. Хотелось бы все же по ходу чему-то научиться и что-то понять. Особенно как искать черную кошку в темной комнате.

В комментарии особенно приглашается добродетельный юзер laoxia, который научил меня первым шагам с dataframe, а также все кто умеет питонить, особенно nefedor. Также я думаю, что скорее всего разбираются в теме misha_b и kobak. Извините если отвлек от важных дел.

Comments

[aklepatc.livejournal.com]

Pandas — это, всё таки, вещь в себе. Не совсем "Питон как он есть".

Извините, я понимаю, что мой комментарий не особо помогает. Я писал на Питоне много лет, но очень мало соприкасался с pandas.

[nefedor.livejournal.com]

Я вообще в Пандас не работал, я в numpy.
Но я думаю, что у тебя где-то в данных есть бяка. И в той строке где бяка, sign не 1 и не -1. В результате оно делает еще одну группу с sign=something_strange но строку туда не добавляет, так как порченную строку ей добавлять неохота - получается пустая категория, на что она и жалуется.
Вот за это я не люблю DataFrames :)
Вторая версия: у тебя категории по floating point, какой-то sign может быть не 1.0 в точности, а 1.0 + 1.e-alot или что-то похожее. Но скорее всего не это, а предыдущее.
Чтобы проверить ты можешь сделать set или dict:
d = {} # or s = set()
for row in data:
. . sign = row[-1]
. . d[sign] = 3.1415 # or s.add(sign)
а потом распечатать какие ключи получились:
print(d.keys()) # or print(s)
И если там есть бяка в sign, ты ее увидишь.

Как вообще бороться с такими вещами: гуглить.
Вот, например по "pandas groupby gives empty dataframe":
https://stackoverflow.com/questions/62303505/group-by-returns-empty-dataframe-and-no-error
https://github.com/pandas-dev/pandas/issues/743

[ny-quant.livejournal.com]

Спасибо!

Я проверил: все 1.0 или -1.0, хотя я и не понимаю какая разница, т.к. groupby должен группировать в любом случае, нет?

Да и не может там быть больше ничего, т.к. все записи добавляются в dataframe командами

pos.loc[posIndex] = [exdate, strike, 1]
pos.loc[posIndex] = [exdate, strike, -1]

Я вообще-то гуглил но ничего толкового не нашел. Завтра попробую почитать то, что нашел ты. По первой ссылке пока что ничего не понял. Не владею ни лямбдами ни join.

[nefedor.livejournal.com]

Еще пишут, названия колонок могут быть проблемой:
https://stackoverflow.com/questions/56815086/pandas-groupby-is-giving-keyerror-even-when-the-key-exists

И тут что-то заумное про индексы:
https://github.com/modin-project/modin/issues/1900

[malyj-gorgan.livejournal.com]

pandas are like that, yes :) прямых ответов у них не бывает

Мой внутренний самоцензор говорит:
a. rename "sign" to smth non-keywordy, like "sgn" or "_sign"
b. ... and make sure it's .astype(int), grouping by floats is bad form
...
and then wrap the whole thing into try/except
тогда, как сломается, можно на него посмотреть

[malyj-gorgan.livejournal.com]

А, Нефедор выше уже все написал

[ak_47]

Как уже выше отметили, это скорее не проблема питона как такового, а конкретные тонкости Pandas.

Без контекста тяжело понять почему. Думаю, nefedor прав насчёт мусора в данных.
А каким дебаггером вы пользуетесь? В чём неудобство?

[ny-quant.livejournal.com]

По-моему никакого мусора нет, быть не может, и главное на операцию groupby это по-моему влиять не должно, т.е. она должна бы работать с любым мусором. Иначе это баг. После стольких лет развития и миллионов пользователей? Правда?

IDLE 3.8

Я привык к тому, что если навести мышку на переменную, то покажут что у нее внутре. А тут хрен тебе. А если это не просто скаляр, а скажем dataframe, то и вовсе не покажут, надо делать print чтобы что-то увидеть - тоска смертная. Вверх-вниз (up/down) по стеку ходить нельзя, или я пока не сообразил как.

[ny-quant.livejournal.com]

Спасибо, я забыл, что вы тоже data scientist.

Заменил sign->sgn. Не помогло.

Про astype(int) не понял. Извините, я начинающий.

Пока что код такой:

pos = pd.DataFrame(columns = ['exdate', 'strike', 'sgn'])

pos.loc[posIndex] = [exdate, strike, 1]
...
pos.loc[posIndex] = [exdate, strike, -1]

Куда мне этот astype(int) впендюрить?

[ny-quant.livejournal.com]

Виноват, не въезжаю. Что означает эта странная фраза собака - друг человека ?

df = df.to_numpy()
df = pd.DataFrame(df)

Такое впечатление, что тут предлагают из dataframe перейти в какой-то NumPy array и вот там уже буде счастье? Так может мне и с самого начала не надо было с dataframe заводиться?

Вообще, если кому-то это кажется хоть в каком-то смысле нормальным, то I am all ears.

[ak_47]

Сейчас такое качество софта везде, что уже ничего нельзя предполагать. Хотя насчёт миллионов пользователей и многих лет развития согласен. В популярных продуктах явные баги довольно быстро находят и оперативно чинят.

IDLE 3.8

Это жесткач. Я бы посоветовал хоть что-нибудь более юзабильное. Например, VSCode с плагином для питона. Там будет и нормальный дебаггер, и более приятный REPL.

С Pandas я никогда не работал, но эти трудности будут с любой продвинутой библиотекой. Особенно если там оптимизации для производительности. Похоже что dataframe это абстракция, которая сама не содержит данные, а только даёт доступ. Поэтому и не видно ничего.

[ny-quant.livejournal.com]

Я попробовал поменять column header sign->sgn, но это не помогло.

[ny-quant.livejournal.com]

Я бы и сам посоветовал хоть что-нибудь более юзабильное, но будучи чайником не знал где его искать. Спасибо, попробую на досуге VSCode, хотя что такое REPL я все равно не знаю.

В С++ классы тоже вроде как абстракция, но в итоге оказалось возможно расколупать любой объект по ходу дебаггинга. А это какой-то блин прошлый век и, что самое поразительное, при огромном энтузиазме почтеннейшей публики.

[ak_47]

REPL это read, eval, print loop, т.е. интерактивная среда в которой мы набираем код и тут же его интерпретируем и видим результаты. То окно, где вы пишете питоновский код после промпта ">>>".

В С++ тоже могут быть классы, которые не содержат в себе данные, а достают их по требованию. Т.е. пока метод не вызовешь ничего не узнаешь что там. В таких случаях в дебаггере надо быть осторожным, чтобы side effects от вызовов не поменяли сами данные.

[malyj-gorgan.livejournal.com]

В какой то момент print(pos) выдает все эти 1.0, -1.0
можно проверить pos.sgn.dtype, он будет dtype('float64')
тогда надо набрать
>> pos['sgn'] = pos['sgn'].astype(int)
pos.sgn.dtype станет dtype('int64')

В этом месте очень хорошо бы для проверки написать такое:
assert pos.shape[0]>0 # this checks that you're grouping by non-empty df
assert set(pos.sgn) - {1,-1} == set() # this checks that column 'sgn' only has 1 and -1 values
ну или, если по условию задачи надо, чтобы были оба значения, и плюс и минус 1, то всего одна проверка:
assert set(pos.sgn) == {1,-1}

в момент, когда колонка сгн будет не в порядке, ассерт выдаст ошибку, и можно будет смотреть, че не так

Ну, или, как я писал, ту строчку, где сейчас ошибка, завернуть в try/except

Но, честно говоря, если вы используете groupby как фильтр для sgn= 1 or -1, то это неправильно, групбай для другого, в частности, если нету группы 1, то будет нехорошо. groupby создает сгруппированный объект для последующей аггрегации. А то, как вы написали работающий вариант -- как раз правильно
Или, если нравятся (как мне) explicit statements:
longs = pos.query("sgn == 1")

Кроме того, еще от внутреннего цензора, assignment через .loc — still a bad form. Не скажу, что там точно проблема, но там в разных версиях панд разные моменты то deprecated, то not supported...
В общем, если только вам не особенно важен тот или иной индекс, надо создать либо list of dicts
X = [{'exdate' : (скаляр), 'strike': <тоже скаляр>, 'sgn': (1 или -1)} ]
or, better, a dict where the values are list
X = {'exdate' : [list of values], 'strike': [another list of values, 'sgn': [list of ones and minus ones]}
после чего определеть датафрейм как
pos = pd.DataFrame(X)

Вообще, Python для ad hoc coding — почти идеален. Продакшен уже о другом, а прототипы идей на коленке клепать --милое дело

[spamsink]

Я в питон не умею, но умею в тег <pre>

N     exdate   strike sign
619 20170616.0 2200.0 1.0
620 20170616.0 2200.0 1.0
<много похожих строк>
792 20170421.0 2475.0 -1.0
793 20170421.0 2475.0 -1.0

[ak_47]

Чем так мучиться, почему бы сразу таблицу не завести и элементарным SQL из неё доставать всё что нужно?

[iv6.livejournal.com]

Полагаю, вам лучше подойдет Spyder. Там будет и Variable Explorer, и прочие радости.

[hervejoncour.livejournal.com]

Если до сих пор не нашли решения post the question in stackoverflow.com

[ticklish-frog.livejournal.com]

df = df.to_numpy()

выдает квадратную матрицу чисел внутри df. То есть, грубо, "забывает" имена колонок.

df = pd.DataFrame(df)

делает DataFrame из матрицы - то есть такой хитрый способ превратить имена столбцов в 0, 1, 2, ...

Но тут надо следить, что происходит с отсутствующими элементами.

Если Вы укажете версию Pandas, то можно будет посмотреть, если есть проблема с https://github.com/modin-project/modin/pull/2125 - ну или просто попробовать

pos.groupby(by=['sign'])

Неспроста в руководстве все примеры на groupby даются со списком из одного элемента!

[mi-b.livejournal.com]

а что она говорит если прямо перед проблемным groupby напечатать print(pos.isnull().values.any()) ?

[luxs135.livejournal.com]

Панда вообще немного глючная, а если учесть разное поведение в разных версиях, то вообще катастрофа.

[laoxia.livejournal.com]

Я, конечно, так сразу диагноз не поставлю, но слова "поменял один из параметров, которые контролируют процесс наполнения этого dataframe" и KeyError в get_group намекают, что стоит посмотреть, какие там есть группы, например, написав

print(positions.groups.keys())

и посмотрев чего оно напечатает. Если в том что оно напечатает нету той группы которая была в качестве параметра в последней get_group, то я бы стал смотреть чего там поменялось с наполнением этого dataframe.

[luxs135.livejournal.com]

А вообще, немного подумав - группировать по значению флоат - дело нехорошее.

[ny-quant.livejournal.com]

False - каждый раз, в том числе прямо перед обломом.