-
Notifications
You must be signed in to change notification settings - Fork 67
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
WIP: Adapt #1703
base: develop
Are you sure you want to change the base?
WIP: Adapt #1703
Conversation
I'm running the following code:
and getting the following error:
which I think occurs because |
Thanks, @lcadalzo, I hadn't tested with model predictions. |
5) Minimal dependencies (framework-specific) | ||
|
||
User stories: | ||
a) Initialize an attack with an interesting input |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the user story Initialize an attack with an interesting input
, not sure I'm following exactly what's meant since you can pass whatever to ART's generate()
or in the case here,__call__()
. Or do you mean the init within the epsilon ball that gets added to the input? If so, it looks like this code restricts you to either random or None.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the desire is to enable the init within the epsilon ball. The code needs to be modified to enable passing in an init function instead of those two choices.
|
||
# logits: | ||
self.task_metric = lambda y_pred, y_true: ( | ||
y_pred.detach().argmax(dim=1) == y_true.detach() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just pointing out a challenge here. While setting this task_metric is simple enough for classification, this would break for non-classification tasks and is much less straightforward to define in those cases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Point taken
return tuple(position) | ||
|
||
|
||
class PGD_RandomPatch(PGD_Patch2): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it necessary to have an additional class for patch pgd and random patch pgd, as opposed to this just being something set or defined in the former?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to collapse as much as possible - but wanted to start from simple attacks, move to complex ones, and then see how to combine them effectively.
# ])(epsilon) | ||
|
||
|
||
class EoTPGD_Linf(PGD_Linf): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems like the number of distinct classes needed is multiplying rapidly. Would you also need a class for EoT L2, EoT Patch, EoT random patch, etc.?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should have added a note on this one: this was meant to demonstrate how to extend a class to use EoT. I would remove this class, actually. Or, if EoT can be added as a wrapper around an existing class, then that would prevent that sort of class explosion.
I need a better way of handling / representing random components - that would enable specification of what you're performing the expectation over.
No description provided.