l0 not implemented correctly

function compare(x,y) does not called after following code.

nn_robust_attacks/l0_attack.py

Line 161 in d2067d5

if works < .0001 and self.ABORT_EARLY:

So, there is no checking whether the attack is success or not.

By default self.independent_channels is False
Then, we will run following code

nn_robust_attacks/l0_attack.py

Line 228 in d2067d5

valid = valid.reshape((self.model.image_size**2,self.model.num_channels))

nn_robust_attacks/l0_attack.py

Line 229 in d2067d5

totalchange = abs(np.sum(nimg[0]-img,axis=2))*np.sum(np.abs(gradientnorm[0]),axis=2)

So, valid has shape (pixels, channels), totalchange has shape (pixels`)``. Let's consider color image (3 channels). It turns out the shape of validandtotalchange``` not matched.

In the following code,

nn_robust_attacks/l0_attack.py

Line 237 in d2067d5

valid[e] = 0

You basically change initial channel value (0,0,0) to 0, which is not correct.

I believe this is what I want. If you have valid.shape == (pixels, channels) and you write valid[e] = 0 then numpy will perform the operation valid[e,:] = 0.

Did this code crash for you or somehow not give the solution?

I confirm that numpy will perform valid[e,:] = 0. Thanks!

Since I have added code to check whether the attack succeeds or not, I do not know whether the original code will crash or not. But, both l2 and li attack have the code to check whether the attack succeeds or not. I do not see any reason why not adding such code in l0 attack. Also, without checking, we do not know whether the found solution works or not.

Yeah, so for some reason I decided in the l0 attack that when it finds a valid solution, to restore the state which is known to be correct.

nn_robust_attacks/l0_attack.py

Lines 162 to 163 in d2067d5

    
           # it worked previously, restore the old value and finish 
        
           self.sess.run(set_modifier, {assign_modifier: oldmodifier})

I don't remember why I did it this way, but because I do it, it's not necessary to insert the compare call. (Although putting it in definitely wouldn't be harmful.)

Thank you for your clarification. I think your assumption is if the loss value is small enough, then it implies the attack will be successful. I add the validation check in my code since I want to do the attack in parallel, and the validation check is a safeguard.

	# it worked previously, restore the old value and finish
	self.sess.run(set_modifier, {assign_modifier: oldmodifier})