The following line doesn’t error but doesn’t have any affect on b2
b2[vec(b2)][ p2[xhalt*2:end] ] .= false;
Working in the same scope:
b3 = @view b2[vec(b2)];
b3[ p2[rmax+1:end] ] .= false;
b2 is a bitvector, p2 a vector of ints
Repeatable
b2 = trues(50); p2 = randperm(50);
b2[b2][p2[20:end]] .= false;
> sum(b2)
50Please provide a self-contained MWE, with b2 etc defined.
b2[b2][p2] .= false , and
b2[p2][p2] .= false fair the same aswell
b2[vec(b2)] does not create a view so the behavior is expected to be different.
It seems to be the second set of square brackets causing the trouble though, the b3 part is a work around
I wouldn’t have expected that much difference ;D
No. It’s not. The first is getindex and only the second is setindex!. The original code is equivalent to b3 = b2[vec(b2)]; b3[...].
Difference between? Adding the b3 shouldn’t make a difference and doesn’t. The difference is when you add @view and that’s exactly what it is meant to do.
The key is that the syntaxes
A[I] = X
A[I] .= X
modify A. In your case, A = (b2[vec(b2)]) — which is a copy and thus doesn’t modify the original b2. That’s why the view works, since views propagate their changes back to the original object.
behaviours of get/setindex on the left hand side.
I think it’s a little confusing to call the first square brackets at fault because it would work without the second set, eg, b2[b2] .= false should be fine, but i guess that is a technical answer - how julia uses getindex and setindex in this case
So, is the current behaviour intended?
Yes.
So you mean getindex and setindex! should behave the same? I can take a few guesses why you might think that way (if they are wrong, please ignore…):
Well, you were never comparing the two. For the original code, the getindex, i.e. the first bracket, is definitely what gives you the behavior you didn’t expect. Now, if you were comparing it to something that you never mentioned, then sure, adding the second one could be how you get from a working version to this version. There are just so many changes that you could’ve made though, so it’s impossible for others to guess what was the last change you made. FWIW, removing the first square bracket will also make it “work”.
I did look at learning python a while back, but they used the phrase “syntactic sugar” too many times in the first video lecture 
Technically i’d be a former octave user, though i only used it a little, enough to pass a few MOOCs
Naively i would’ve thought all indexing on the left would be or reduce to setindexes
tbh I’m not sure if that’s fair use of the ‘moving the goalposts’ concept but point taken - I say this because it seems very much stating the obvious that it works with just the one set of brackets
Is there any chance that we could have this behaviour changed at some point, specifically for the left-hand side? The work around isn’t too bad but I at least would find the double-indexing set method quite convenient at times
Maybe a diy job I guess, it shouldn’t be too hard to add a method to setindex! make a function to combine indexes
That is extremely unlikely (so unlikely that I don’t think it is worth spending too much time on it).
Also, a good default approach when you learn a language is to give the existing implementation a bit more of the benefit of the doubt and just blindly accept that things are the way they are for some reason. After a while, when you are more familiar with things, you might see that the behavior actually made sense. If it still feels odd, and then voicing concerns might be reasonable.
You may consider my concerns voiced, reasonable or otherwise =)
I shan’t ask for the sense of the behaviour
add /spoiler: some prior art