DNMY: rely on promote_op for many operations

[timholy]

Requires backporting of JuliaLang/julia#13803, do not merge yet. Once it gets backported, do not merge until the REQUIRE file has its julia version bumped. (I'm not sure which julia version it will end up in, or I'd add that change now.)

I noticed a few "Array"-type operations missing. While it would have been easier to write specialized methods to handle the operations I needed, it seemed best to try to get to the point where we supply the right traits and then rely on methods in Base.

[mlubin]

Very cool, thanks! Ref #179
Could we also shift to this approach for scalar operations?

[joehuchette]

This looks great, thanks!

[joehuchette]

Why is this change needed?

[timholy]

isa(x, SparseMatrixCSC) == true. If you leave it as a sparse matrix, you get a stack overflow because all other methods are implemented only for Array and so this method gets called again.

[timholy]

I think this basically closes #179.

I'm not exactly certain what you mean by shifting for scalar operations; unfortunately right now you have to basically implement scalar operations for both instances and types, e.g.,

(+)(lhs::Number, rhs::GenericAffExpr) = GenericAffExpr(copy(rhs.vars),copy(rhs.coeffs),lhs+rhs.constant)
Base.promote_op{R<:Real}(::AddFun, ::Type{R}, ::Type{AffExpr}) = AffExpr

But all those are scalar objects. Once you do that, the array operations follow automatically. (And you really only need the type-implementation for use in the array operations.)

Someday, someone will write a ReturnTypes.jl package that is an independent implementation of type-inference. Once it's working well, many of us will lobby to put this in base, and if that happens then we won't need the type-implementation. See the extensive discussion in JuliaLang/julia#12292 (comment).

[mlubin]

@timholy, I mean falling back on promotion rules to convert Number + AffExpr into AffExpr + AffExpr. Though there's some loss of efficiency there.

[timholy]

Oh, now I understand. That could be good for + and -, but (to state what's certainly obvious to you) I think for * you'd lose important type information, since Number*AffExpr -> AffExpr and not QuadExpr. Not sure it would be worth it for just + and -.

[mlubin]

@timholy, any interest in updating this PR?

[mlubin]

This is stale, but we still have #179 open