Have a dedicated neighborhood property and a get_neighborhood method on Cell#2309
Have a dedicated neighborhood property and a get_neighborhood method on Cell#2309
Conversation
EwoutH
left a comment
There was a problem hiding this comment.
I like the general design!
Any performance implication on caching? Mostly good probably, right?
Co-authored-by: Ewout ter Hoeven <[email protected]>
|
just a quick observation about cellspaces. A random walk is now a one liner: |
|
That’s really nice! I would appreciate a deprecationwarning for |
AFAIK that is not possible because the name clashes with the property. |
|
It looks like this does introduce some errors. |
|
Performance benchmarks:
|
|
These benchmark results are exactly opposite of #2308. So seems to cancel out and are just based on an outdated branch or whatever. |
|
Performance benchmarks:
|
EwoutH
left a comment
There was a problem hiding this comment.
Was starting to type something about API compatibility and deprecation warnings, but then remembered this is all in the experimental space.
Love the experimental space!
|
Thanks, great to have it in! Please make sure that pre-commit passes before merging. Always a bitch to clean up (done in 7037a32). |
This picks up on a discussion in #2296. In the current code, we have method named
Cell.neighborhood. This is an unfortunate name. So we agreed to split this into a property for the direct neighborhood (i.e. radius = 1) and aget_neighborhoodmethod for larger radii. We had a bit of discussion on the names, but I decided to keep it simple:neighborhoodandget_neighborhood. I have updated the docstrings to clearly explain when to use which one.