Naive fix for #13171

[Sacha0]

Ref JuliaLang/LinearAlgebra.jl#257. This fix's simplicity has me convinced that I'm either missing something or made a mistake.

[kshyatt]

Why is this an error and not something like ArgumentError? I thought we were trying to move away from error()?

[Sacha0]

No reason beyond mimicking

julia/base/abstractarraymath.jl

Lines 9 to 10 in 9a66205

	ctranspose(a::AbstractArray) = error("ctranspose not implemented for $(typeof(a)). Consider adding parentheses, e.g. A*(B*C') instead of A*B*C' to avoid explicit calculation of the transposed matrix.")
	transpose(a::AbstractArray) = error("transpose not implemented for $(typeof(a)). Consider adding parentheses, e.g. A*(B*C.') instead of A*B*C' to avoid explicit calculation of the transposed matrix.")

. Should I change it to ArgumentError, and if so should I change the linked definitions to ArgumentErrors as well? Thanks for reviewing! :)

[kshyatt]

I think we should keep this PR self-contained for now - you can always open a PR for those others later. But yeah, I think something like ArgumentError is more useful than error().

[Sacha0]

Cheers, revised to throw an ArgumentError. Thanks!

[ivarne]

Ideally it should be a MethodError (right?) But as long as we don't have #7512, we can't print the message in MethodError.

[andreasnoack]

I think packages will hit this more often. @JeffBezanson was also not happy about adding a lot of no-op (c)transpose methods including the cases Char and AbstractString. The question is therefore if we should go all the way and declare transpose separate from permutedims and require that arrays of strings or chars use permutedims.

As a follow up on the last comment, I'll mention that I'm trying to rebase my transpose immutable branch and realized that the Transpose immutable can't be restricted to wrap AbstractMatrix and can't be a subtype of AbstractArray either since people will definately want to do A'x for their custom linear operators that are not subtypes of AbstractMatrix. In that sense, we are also on the path to separating transpose from permutedims where the latter only deals with AbstractArrays.

[Sacha0]

I think packages will hit this more often. @JeffBezanson was also not happy about adding a lot of no-op (c)transpose methods including the cases Char and AbstractString. The question is therefore if we should go all the way and declare transpose separate from permutedims and require that arrays of strings or chars use permutedims.

As a follow up on the last comment, I'll mention that I'm trying to rebase my transpose immutable branch and realized that the Transpose immutable can't be restricted to wrap AbstractMatrix and can't be a subtype of AbstractArray either since people will definately want to do A'x for their custom linear operators that are not subtypes of AbstractMatrix. In that sense, we are also on the path to separating transpose from permutedims where the latter only deals with AbstractArrays.

+1 to decoupling speciously coupled concepts!

[andreasnoack]

Let's then try to remove the definitions for AbstractString and Char and adjust the tests.

[Sacha0]

Let's then try to remove the definitions for AbstractString and Char and adjust the tests.

Done. Thoughts? Thanks and best!

[andreasnoack]

Looks like datafmt.jl also needs some adjustments.

[Sacha0]

Looks like datafmt.jl also needs some adjustments.

Points for CI. What say you now, Travis?

[tkelman]

This needs to be a deprecation, not an immediate error.

[Sacha0]

Thanks for the review and merge!