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
DeepFool doesn't exactly match the latest reference implementation #283
Comments
related to #282 |
Apparently, the DeepFool reference implementation changed after release (and after the Foolbox version was created), which explains some of the undocumented deviations, see e.g. LTS4/DeepFool@10cf642 |
In case we switch to logits instead of softmax, we might want to keep softmax as an option. |
By softmax you mean cross entropy? The difference of cross entropies is equivalent to the difference in logits. |
yes, I meant cross-entropy |
Ok, but at least in that sentence our cross-entropy implementation should be equivalent to the logit-based original implementation. |
which sentence? |
Sorry, I overlooked the fact that they are exactly equivalent. Then the cross-entropy part is fine. So regarding this issue, there is only one question left. This difference is explicitly mentioned in the comments, so potentially Foolbox users are aware of this, so this is good. However, a potential problem with this implementation (I'm not sure how thoroughly the authors of DeepFool tested their pytorch implementation) is that this kind of overshooting may fail in some cases. Namely, we observed that in some cases I think that it's actually fine to some extent (although it differs from the original paper), but the main question is whether you count such a point (if 2 classes have exactly the same maximum logit) as an adversarial example in the end? Or is it decided non-deterministically, which class is argmax in the end? |
If I am not mistaken, it is deterministic and well-defined ( |
The Pytorch implementation performs the overshoot in a better way by multiplying the total deviation:
|
Indeed. From the docs:
Oh yes, I didn't notice that. The variant with multiplying the total perturbation should work better. |
Seems like the
i.e. if top1 < label, then the point on the decision boundary between 2 classes will be counted as an adversarial example, but if top1 > label, then not. Although a proper overshooting scheme (i.e. with multiplying the total perturbation by |
This was reported to me by @max-andr. Most of the differences are actually explicitly mentioned in comments in our implementation, but we should check again if we can match the reference implementation more closely and possible mention deviations in the docs, not just in comments.
@max-andr might create a PR to fix this
The text was updated successfully, but these errors were encountered: