MWE - setindex bug?

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

b2 = trues(50); p2 = randperm(50);
b2[b2][p2[20:end]] .= false;
> sum(b2)

Please 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.

1 Like

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.

1 Like

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?


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…):

  • If you are from python (or other language that returns view from indexing by default) then the short answer is that it’s been considered but it’s breaking enough and the performance of operations on views are bad enough that we believe it’s better to be explicit when views are required. (The performance issue isn’t a problem for python since it was slow anyway).
  • If you are from C++ (or other languages that uses getindex to implement setindex!) then julia has a completely different object model and you’ll get a lot more related surprises.

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”.

1 Like

I did look at learning python a while back, but they used the phrase “syntactic sugar” too many times in the first video lecture :wink:
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