Subtle bug with mul! and view

[simonbrandhorst]

Either a bug ... or I am not using it correctly.

julia> G = ZZ[1 2 3 ; 4 5 6; 7 8 9]
[1   2   3]
[4   5   6]
[7   8   9]

julia> T = ZZ[0 1; 1 0]
[0   1]
[1   0]

julia> mul!(view(G,1:2,:), T, view(G,1:2,:))
[4   5   6]
[4   5   6]

julia> G
[4   5   6]
[4   5   6]
[7   8   9]

[lgoettgens]

I think you are not supposed to use two different objects that share the same underlying memory in an unsafe operation.
Indeed, if you just create a single view, everything works:

julia> G = ZZ[1 2 3 ; 4 5 6; 7 8 9]
[1   2   3]
[4   5   6]
[7   8   9]

julia> T = ZZ[0 1; 1 0]
[0   1]
[1   0]

julia> v = view(G,1:2,:)
[1   2   3]
[4   5   6]

julia> mul!(v, T, v)
[4   5   6]
[1   2   3]

julia> G
[4   5   6]
[1   2   3]
[7   8   9]

[thofma]

I think we should still fix this.

[lgoettgens]

This breaks an assumption on the flint side. Two objects need to be identical or may not share memory.

I think the only thing we may be able to do here is to catch the case and throw an error

[thofma]

Today we (@lgoettgens and I) discussed this and came to the following conclusion:

• This is the expected behavior of flint. It is not a bug in flint, since the documentation says, as @lgoettgens mentioned, that things must either be egal (===) or do no "overlap".
• We do not check anything else in mul!, so for the same reasons we might keep this behavior and add a warning in the non-existing docstring.
• We can try to detect this and throw an error. Since matrices and views have the same type, the check will not be for free, even if there are no views involved. It is also complicated by the fact that there might be views of views etc. Still I want to check, how fast one can make this.