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

Unify Requirements of Perturb Functions and their Usage in the Metrics #77

Closed
leanderweber opened this issue Mar 10, 2022 · 1 comment · Fixed by #88
Closed

Unify Requirements of Perturb Functions and their Usage in the Metrics #77

leanderweber opened this issue Mar 10, 2022 · 1 comment · Fixed by #88
Assignees

Comments

@leanderweber
Copy link
Collaborator

The currently implemented perturb functions have different requirements, e.g., in terms of expected input shape, and are thus not really interchangable for all metrics. Requirements should either be unified for perturb functions, or at least an informative error message should be thrown in the metrics if an inapplicable perturb function is used.

@leanderweber leanderweber self-assigned this Mar 10, 2022
@dkrako
Copy link
Collaborator

dkrako commented Mar 16, 2022

I think the most clean way of doing this would be to create some abstract classes or interfaces with abstract methods which specify the expected inputs, e.g. IndexPerturbatorInterface or PatchPerturbatorInterface. The calling metric then would just need to check if the passed perturbator object inherits from the expected type of perturbator.
This would also have the benefit of instantiating the perturbator object beforehand with any arguments wanted without unnecessarily dragging these arguments through the Metric implementations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants