Fix all_equal() and hence get_param_values(> #437
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
all_equal()
is pretty broken, so replace it withComparator.is_equal()
.Fixes #179
Incorporates #180
But, some issues...
To do:
name
parameter fromget_param_values()
Different definitions of equality
I'd like everything to be deciding equality the same way. However, it's probably tricky. You can't always have full equality checks everywhere (e.g. could be too expensive).
Comparator.is_equal()
does not (by default) handle numpy arrays orparam.Time
(*), both of which are (meant to be) handled byall_equal()
.Drop those from
all_equal()
(i.e. make it like default ofComparator.is_equal()
)?Or support those during
all_equal()
, i.e. retain all_equal's existing intended behavior, but comparisons done with Comparator (outside of all_equal) would by default behave differently.Or make
Comparator.is_equal()
handle numpy arrays and param.Time by default. (I'm not quite sure how it's supposed to work on skimming it, but it looks like Comparator is designed to allow comparisons without explicit imports, but even if not seems likely it could be made to work).(*) Has
_infinitely_iterable
attributeI'm not too sure. I prefer 1 or 3. When I think of param in the past, I think 3 is what I'd like. But I suspect there's a good reason the default of Comparator is not to handle various cases (performance?).
Retaining get_param_values( behavior of not showing auto-generated name
As noted in #179, a side effect of the incorrect all_equal() function is that it suppresses a parameterized's name from appearing in the result of
get_param_values(> if the name was auto-generated. I've added
suppress_auto_name
toget_param_values()
, defaulting to True, so that if is requested, an auto-generated name is not included.But I feel like there are often times when you don't want the name in the parameters you're dealing with, so I'd prefer suppress_auto_name to be respected whether or not onlychanged is True.
I haven't thought about it a lot. Whether to have this option and what it does might depend a bit on the outcome of the api discussions.