Skip to content

[FIX] Cleanup ConfigSpace warnings#183

Merged
mfeurer merged 4 commits intoautoml:masterfrom
franchuterivera:remove_deprecation
May 20, 2021
Merged

[FIX] Cleanup ConfigSpace warnings#183
mfeurer merged 4 commits intoautoml:masterfrom
franchuterivera:remove_deprecation

Conversation

@franchuterivera
Copy link
Copy Markdown
Contributor

This PR aims to remove every warning from configspace (so we have a full green pytest run).

This is done by:

  • Removing pyparsing warnings
    /home/chico/.local/lib/python3.8/site-packages/pyparsing.py:3190: FutureWarning: Possible set intersection at position 3
  • Removing the deprecation warnings from numpy
<google-sheets-html-origin><style type="text/css"><!--br {mso-data-placement:same-cell;}--></style>
Config space deprecation warnings regarding np.float/np.bool
--
cated in NumPy 1.20; for more details and guidance: https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
cationWarning: `np.float` is a deprecated alias for the builtin `float`. To silence this warning, use `float` by itself. Doing this will not modify any behavior and is safe. If you specifically wanted    the numpy scalar type, use `np.float64` here.
cationWarning: `np.int` is a deprecated alias for the builtin `int`. To silence this warning, use `int` by itself. Doing this will not modify any behavior and is safe. When replacing `np.int`, you may    wish to use e.g. `np.int64` or `np.int32` to specify the precision. If you wish to review your current use, check the release note link for additional information.
rootdir: /home/chico/work/ConfigSpace_fork_removedeprecation

</google-sheets-html-origin>

@codecov
Copy link
Copy Markdown

codecov bot commented May 20, 2021

Codecov Report

Merging #183 (37d2fdb) into master (b2fe51e) will increase coverage by 0.01%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #183      +/-   ##
==========================================
+ Coverage   68.20%   68.22%   +0.01%     
==========================================
  Files          18       18              
  Lines        1774     1775       +1     
==========================================
+ Hits         1210     1211       +1     
  Misses        564      564              
Impacted Files Coverage Δ
ConfigSpace/read_and_write/pcs_new.py 88.00% <100.00%> (+0.03%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b2fe51e...37d2fdb. Read the comment docs.

pp_connective = pyparsing.Word("||" + "&&")
# A word matches each character as a set. So && is processed as &
# https://pythonhosted.org/pyparsing/pyparsing.Word-class.html
pp_connective = pyparsing.Word("|" + "&")
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be pyparsing.Literal then?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And the log above, too?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the catch of log. I have fixed that.

Leaving pp_connective = pyparsing.Word("|" + "&") as it is was intentional, as this line assumes you will be checking for & or | not &|.

I do not know much about pyparsing, but probably we can do some Combine or And to create this behaviour. In other words, if one just makes this literal this unit test fails.

Let me know how you want to proceed (that is re-writing the pyparsing statement or keeping the pyparsing.Word("|" + "&")).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. Can you check whether there's a union of literals we could use here to rewrite this statement to check for either "??" or "||"?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought it was gonna be more complicated, sorry about that. Let me know if this change is ok!

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change looks good. There's no need to keep this simple, this should be used only very rarely anyways, so it can be slow...

Copy link
Copy Markdown
Contributor

@mfeurer mfeurer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Is this ready to be merged?

@franchuterivera
Copy link
Copy Markdown
Contributor Author

Yes, it is, thanks for taking a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants