Generalize or restrict a few basic operators

[dkarrasch]

This is an attempt to close #43903. While I was at it, I restricted the fallback made the most generic fallbacks simply do what the docstring says, so right and left division operators fall back to multiplication with the inverse.

\(x,y) = adjoint(adjoint(y)/adjoint(x))

to Numbers, and replaced adjoint by conj it by inv(x)*y. The reason is that we don't have a method for adjoint(x::Any), so this fallback is somewhat pointless (edit: unless someone guesses that overloading adjoint is necessary). Also, the docstring of \ doesn't state that it can be defined via / and adjoint. For types that are not subtype of Number or AbstractArray, I believe \ simply needs to be defined explicitly. That's what I have done with ModInt in the generic tests.

[dkarrasch]

One potentially annoying thing with the definition -(x, y) = x + (-1)*y is the following error from CI:

Test Failed at /Users/julia/buildbot/worker-tabularasa/tester_macos64/build/share/julia/test/errorshow.jl:401
  Expression: occursin("MethodError: no method matching -(::Vector{Float64}, ::Rational{$(Int)})", err_str)
   Evaluated: occursin("MethodError: no method matching -(::Vector{Float64}, ::Rational{Int64})", "MethodError: no method matching +(::Vector{Float64}, ::Rational{Int64})\nFor element-wise addition, use broadcasting with dot syntax: array .+ scalar\nClosest candidates are:\n  +(::Any, ::Any, !Matched::Any, !Matched::Any...) at operators.jl:593\n  +(!Matched::Base.TwicePrecision, ::Number) at twiceprecision.jl:290\n  +(!Matched::LinearAlgebra.UniformScaling, ::Number) at ~/buildbot/worker-tabularasa/tester_macos64/build/share/julia/stdlib/v1.9/LinearAlgebra/src/uniformscaling.jl:144\n  ...")

So the error message becomes slightly misleading.

[dkarrasch]

@nanosoldier runtests(ALL, vs = ":master")

[nanosoldier]

Your package evaluation job has completed - possible new issues were detected. A full report can be found here.

[StefanKarpinski]

Does this need review to move forward? If so, any idea who?

[dkarrasch]

Does this need review to move forward? If so, any idea who?

Yes, I think so. Would be good if some of the core devs could take a look if these are reasonable as fallbacks. Maybe @stevengj, @vtjnash, @JeffBezanson for a start? The tests and the ecosystem seem happy, but there may be underlying assumptions that are not laid out in tests.

[stevengj]

LGTM.

[vtjnash]

I don't know the math sufficiently well to claim whether these are equivalent

[vtjnash]

this seems possibly incorrect for many types (e.g. Unsigned), and less likely for promotion to be defined than negation

[dkarrasch]

This was the main requested feature in the related issue. This change causes a different error than the one previously expected in the int.jl tests.

[vtjnash]

gotcha. As I replied above, I have no context for this change, so I am mostly the wrong person to ask.

[dkarrasch]

Are the ambiguity test failures in linuxaarch64 real? If not (tests pass on all other platforms or fail for obviously unrelated reasons), then this can be merged.

[bkamins]

This PR breaks DataFrames.jl tests (fortunately tests only). Before I start fixing DataFrames.jl could you please explain me the rationale behind allowing for example:

julia> +(nothing)

julia> *(nothing)

julia> +("some string")
"some string"

julia> using Dates

julia> *(Date(2020, 5, 15))
2020-05-15

Thank you!

CC @nalimilan

[dkarrasch]

Is the failing test a new one? DataFrames.jl was not listed as failing in the nanosoldier run from March. I'm very sorry for the breakage!

The general idea of this PR is to make vector space calculus the generic default as discussed in #43903. I might have overdone it with + and *, but I felt that if we have a generic -, then the same should apply to the other basic operations. I'll open a draft PR in which I restrict + and * back to Number, and then we can choose whether we want to revert this one or go forward with the other.