-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add make_confidence_report_spsa.py #794
Conversation
@juesato @nottombrown @carlini I'm trying to clean up SPSA and integrate it into our newest multi-GPU, multi-attack, confidence aware eval system. I made a few basic changes like having it use the same argument names as ProjectedGradientDescent, support clip_min and clip_max, etc. Unfortunately, the core SPSA algorithm itself doesn't really seem to work. It results in NaNs. Steps to reproduce:
This results in a NaN. Any suggestions? |
I think the NaN may have been because the VM I was using had a GPU hardware or driver problem. After rebooting it, I no longer get the NaN. I do get a different error message though: File "/home/goodfellow/cleverhans/cleverhans/attacks.py", line 1991, in generate InvalidArgumentError (see above for traceback): Input to reshape is a tensor with 1003520 values, but the requested shape has 784 |
Is this currently using a batch size of 1280 by any chance? SPSA assumes a batch size of 1, because internally, the implementation uses batching by evaluating the model on many noised versions of the current input to do the finite difference gradient estimates. Since this already maxes out GPU utilization, I just didn't both implementing the reshaping necessary to support attacking a batch of multiple inputs. This used to error out, but I changed it in #509 to assume the Tensor being passed in has batch size 1 and then reshape appropriately. Harini pointed out to me today that SPSA only supporting batch size 1 isn't actually in the documentation. That's totally my bad, I'll send in a PR tomorrow. |
OK, thanks. Do you think it would be possible to support a batched interface by just wrapping what's currently there in a tf.while_loop that makes one adversarial example at a time? |
My original reasoning was (copying from #509): """ The TF implementation could of course support a tf.while_loop on the outside to loop over the batch dimension, but that seems overly complex to me, since the computation is really handling each image separately, and it's easy to handle outside TF. I think it makes sense for the numpy interface to support batches, so I changed that. I'm happy to implement this though, if you feel strongly about it. |
This is no longer WIP / this is done once the tests pass. |
Looks like I'll need some more help with this. The generate_np caching system is a big mess. While trying to get the tests to pass, I've cleaned up some problems with it, but I'm still left with two failures. The SPSA attack strength test for the FAIL: test_attack_strength_np (test_attacks.TestSPSA)Traceback (most recent call last): ======================================================================
|
Nevermind, I found why the tests were failing. I was detecting the format of the labels wrong. I was testing their shape and assuming int labels would have only one dimension, but they were actually getting passed in with an extra axis of dim 1. I changed it to assume that if the data is ints we need to call one_hot and otherwise we don't. |
Just looked at the change, that seems good to me - thanks! |
@juesato : do you mean go ahead and merge the branch? I wasn't sure if you meant for your comment to be a whole review, or just commenting on one thing. |
I'm happy with the changes related to SPSA (in |
Thanks! You're certainly welcome to review the rest of the PR if you're feeling charitable, but that seems like a lot to ask. @carlini , can you find someone to review the remaining files? ( |
Closing this, and re-opening with a rebased version: #820 |
No description provided.