*(c::Number, A::Operator) about approxfunbase.jl HOT 5 CLOSED

Probably. hanging it to c === zero(c) and c === one(c) fixes it?

from approxfunbase.jl.

That would fail for BigFloat because they're mutable but not treated as such.

Is there a good reason for the cases? Seems there are three different type outcomes of this method. Does ConstantTimesOperator have a big overhead compared with ZeroOperator?

from approxfunbase.jl.

Poor design? Premature optimisation? Feel free to delete it and see if tests still pass

from approxfunbase.jl.

The very next line is suspect too: any reason why *(A::Operator,c::Number) = A*(c*one(domainspace(A))) isn't *(A::Operator,c::Number) = c*A?

from approxfunbase.jl.

Because it’s applying the operator to a constant function, which returns a function. If/when it’s revamped, operators will be functions of functions, applying an operator will be A(f) instead of A*f and composing operators will be A\circ B instead of A*B.

This will in practice be lowered to quasi arrays which have well-defined matrix operations

from approxfunbase.jl.