Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

max is by default over the keys. This also avoids a type error because dict.get actually returns an Optional type. #610

Closed
DBrughmans opened this issue Mar 18, 2022 · 3 comments · Fixed by #612
Assignees
Labels
Type: Bug Something isn't working

Comments

@DBrughmans
Copy link

max is by default over the keys. This also avoids a type error because dict.get actually returns an Optional type.

Originally posted by @jklaise in #541 (comment)

This change is causing me issues in newer versions. This change does not result in the same output. I think the goal is to find the key which is paired with the highest value. The new method just returns the key which is the highest value.

cat_vars
{0: 2, 2: 3, 5: 8, 13: 2, 15: 2, 17: 2, 19: 3}
max(cat_vars)
19
max(cat_vars,key=cat_vars.get)
5

Versions after this commit do not work with categorical features for me.

@jklaise jklaise self-assigned this Mar 18, 2022
@jklaise jklaise added the Type: Bug Something isn't working label Mar 18, 2022
@jklaise
Copy link
Contributor

jklaise commented Mar 18, 2022

@DBrughmans you're absolutely correct, this is a bug and an oversight from me. The original function of key=cat_vars.get was to find the categorical variable with the most number of categories so that we can allocate a tensor big enough to hold information of category embeddings. With the buggy change this is no longer the case. By some accident, in the examples we have both versions of the max give the same answer since the variable with the most categories happens also to have the highest key. Compounded with the fact that the variable is named max_key explains why I thought the behaviour should be the same when it clearly isnt.

I will revert the bug in an upcoming PR and look to release version 0.6.5 asap. Apologies for causing trouble.

@jklaise
Copy link
Contributor

jklaise commented Mar 18, 2022

@DBrughmans I've published version 0.6.5 on PyPI which reverts the bug, if you upgrade, things should work as before. Thanks again for bringing this to our attention.

@DBrughmans
Copy link
Author

Thanks for the fast response!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants