Open asmeurer opened 1 year ago
A complication here is that libraries that use views would not be able to make
.H
a view unless they add a special conjugate-complex dtype.
It's worth noting that libraries that use JIT compilers (e.g., JAX and PyTorch) will likely be able to optimize these operations even without explicit views.
PyTorch has a special "complex conjugate bit", which makes torch.Tensor.H
an O(1) operation even in eager mode. I believe the conclusion from the NumPy discussion was that something like that is also desired if .H
is going to be a thing (implemented as special dtype - the details probably don't matter, just that it's a lot of work and it's not moving forward).
I'd prefer not to touch .H
, because we can't really adopt it without giving NumPy (and perhaps other libraries) the choice between (a) doing a lot of work, (b) not being compliant, or (c) letting go of a pretty fundamental design rule that attribute access should be cheap.
It might be useful to have a special function for a hermitian transpose, which would be equivalent to
conjugate(matrix_transpose(x))
.
This seems easier to do.
See for instance https://github.com/numpy/numpy/issues/13797. It might be useful to have a special function for a hermitian transpose, which would be equivalent to
conjugate(matrix_transpose(x))
.The other suggestion is a
.H
operator on matrices. A complication here is that libraries that use views would not be able to make.H
a view unless they add a special conjugate-complex dtype. See the discussion at https://github.com/numpy/numpy/issues/13797. (the.H
attribute is really the bigger thing here, as it least to more readable code, but if it is added it probably makes sense to also add a corresponding function)