Shape of transpose(x)' differs for real and complex x

[thisrod]

This is annoying if you run into it. I imagine that the best fix is a special method for the size of this complicated type of Complex array.

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.4.0-rc2.0 (2020-02-24)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> x = randn(3);

julia> transpose(x)'
3-element Array{Float64,1}:
 -0.36345466121621794
  0.07867715859941832
  0.14644026210406283

julia> x = Complex.(x);

julia> transpose(x)'
3×1 LinearAlgebra.Adjoint{Complex{Float64},LinearAlgebra.Transpose{Complex{Float64},Array{Complex{Float64},1}}}:
 -0.36345466121621794 - 0.0im
  0.07867715859941832 - 0.0im
  0.14644026210406283 - 0.0im

[KristofferC]

Could you explain a bit more what you think the problem is? What did you want to happen?

[StefanKarpinski]

I'd guess that the unexpected part is that adjoint "undoes" the transpose in the real case but not in the complex case. For real vectors transpose and adjoint are the same operation which is its own inverse. That's not the case for complex vectors. A possible different behavior would be for a composition of an adjoint and a transpose to produce an eagerly conjugated vector.

[KristofferC]

I'd guess that the unexpected part is that adjoint "undoes" the transpose in the real case but not in the complex case.

Maybe unexpected but then unexpectedly nice? If you want a vector all the time just collect it?

[thisrod]

What did you want to happen?

I want a way to deduce size(transpose(x)') from size(x), without having to know eltype(x). I think those sizes should always be the same, but I care less about what the answer is and more about it being consistent.

The context is that I tested some code for Array{Complex}, then it failed when I inadvertently gave it an Array{Real}. The transpose and the adjoint were many lines of code apart.

While writing this code, I'm starting to suspect that identifying adjoint vectors with row matrices is a mistake: dual vectors should be vectors, and if you want a vector to turn into a matrix you should have to explicitly cast or reshape it. E.g:

julia> x = randn(5);

julia> x == Array(x)
true

julia> x' == Array(x')
true

julia> x'*x
2.9138488824321147

julia> Array(x') * Array(x)
1-element Array{Float64,1}:
 2.9138488824321147

I would prefer:

julia> x'
5-element DualVector{Float64}:
...

julia> Array(x')
5-element Array{Float64,1}:
...

julia> x' isa AbstractArray
# not sure about that

julia> x' == Array(x')
false

julia> x'*x
2.9138488824321147

julia> Array(x') * Array(x)
ERROR: MethodError: no method matching *(::Array{Float64,1}, ::Array{Float64,1})
...

julia> Matrix(x')
1×5 Array{Float64,2}:
...

julia> Matrix(x')*Array(x)
1-element Array{Float64,1}:
...

But that's a side track for the issue.

[mcabbott]

I'm starting to suspect that identifying adjoint vectors with row matrices is a mistake

It certainly creates lots of edge cases... I wasn't around but most other options got discussed in #42

However I wonder whether there should be a lazy Conj wrapper, which does not change size, this would be the natural thing to return here.

[StefanKarpinski]

Why not just return an eagerly conjugated vector?

[mcabbott]

Someone could be relying on transpose(x)[1,1] = 0 updating x, I guess. Not sure I've ever knowingly done that.

[mbauman]

We did at one point have a lazy Conj wrapper in some of the initial sketch work... I don't recall all the considerations in deciding we didn't need it.

[StefanKarpinski]

I don't think being able to reliably mutate the original array through these kinds of mathy APIs is necessary. If you're doing this kind of operations it really implicitly treats the data as immutable mathematical objects rather than mutable containers.

[thisrod]

most other options got discussed in #42

Thanks for that link. As it happens, the code I'm working on was inspired by up and down tuples. (Basic idea: an (n,m)-tensor maps m-dimensional arrays to n-dimensional ones.) I'm going to post it as soon as I tidy up the README, and ask for pointers to whatever wheel I'm reinventing. That thread might have some pointers.

[StefanKarpinski]

Redesigning the way dual vectors work is off the table until 2.0, but the fact that the shape of transpose(x)' depends on the element-type of x is not ideal, let's focus on that. I would propose that in the complex case it be modified to produce a conjugated vector (eagerly).

[mbauman]

I feel like sometimes-aliasing behavior is worse than sometimes-column-sometimes-vector.

[StefanKarpinski]

Then the alternative would be to re-introduce the lazy Conj wrapper type and return that.

[mbauman]

@andyferris what would you think about bringing back the lazy Conj wrapper? Do you remember the iterations here?