Handle Dates-array arithmetic with promote_op

[timholy]

This fixes the ambiguity warnings triggered by #12115. It also introduces a new abstract type, AbstractScalar and makes use of it in defining operations.

CC @GordStephen, @quinnj.

[tkelman]

Can you describe briefly what the difference is between Number and AbstractScalar ? Which of Number's behaviors are not going to be defined by default for AbstractScalar ? Would any promotion (or other) documentation need to be adjusted for this?

(hopefully I'm not the only one who's going to have this question)

[quinnj]

Hmmm... I guess this is ok. AbstractTime was kind of a catch all for all the Dates types, but this should be ok. The piece that may not make as much is the parsing Slot types, but those probably need to be reconfigured anyway.

[timholy]

Basically, the idea is that if someone was reluctant to call their type a Number, we should have some notion of AbstractScalar. So this is perhaps more of a question for @quinnj about why it isn't a Number.

[andreasnoack]

I've actually wanted something like an AbstractScalar or NonArray for a while. Right now we have this definition for transpose which I'd really like to have narrowed down to something like NonArray/AbstractScalar

[timholy]

I should add that another approach would be to use traits and introduce isscalar.

[tkelman]

This question comes up a lot, a few times at JuliaCon for example, people often want to have container types that are conceptually number-like but aren't necessarily compatible with every single thing that we define in base for Number. Maybe one more level of granularity in the abstract type hierarchy wouldn't hurt, but the real solution to the "which behaviors do you want" problem is out of scope here and will probably be something traits-like.

[timholy]

If we want to define AbstractTime <: Number then I'd be happy indeed to drop the first commit.

[lindahua]

scalar (in math context) is mainly used to refer to the coefficients in linear algebra (see https://en.wikipedia.org/wiki/Scalar_(mathematics)). In this sense, it is more specialized (instead of more general) than number.

What about call it Atom, which indicates that the instance should be considered as a whole, instead of being a collection of ingredients.

[lindahua]

In the mean time, for symmetry, we may also consider introducing something like AbstractContainer.

[mbauman]

Some (brief) prior discussion here: #9270 (comment), which also mentions Atom. I feel like there's been other issues discussing this idea, but I can't find them now. If we do this, it should probably be exported like the other abstract types.

I don't like how this moves arithmetic from Number to AbstractScalar. I think arithmetic is inherently a number-y thing to do. While time Periods could be Numbers, I don't think Date should be.

Edit: Hm, looking closer I realized that it only defines mixed array/AbstractScalar arithmetic. I suppose that makes sense. Never mind me.

[timholy]

Thanks for the excellent discussion.

I'm tempted to rework this using traits. Methods like *(A::AbstractArray, B::Number) = A .* B would be redefined as

abstract IsContainerTrait
immutable AbstractContainer <: IsContainerTrait end
immutable AbstractAtom <: IsContainerTrait end

iscontainertrait(::AbstractArray) = AbstractContainer()
iscontainertrait(::Number) = AbstractAtom()
iscontainertrait(::AbstractTime) = AbstractAtom()

@inline *(A, B) = *((A, iscontainertrait(A)), (B, iscontainertrait(B)))
function *{AT,BT}(Atrait::Tuple{AT,AbstractContainer}, Btrait::Tuple{BT,AbstractAtom})
    ....
end

However, I worry about adding yet another system (even for internal use) this late in 0.4. At this point, I wonder if the best course would be to revert #12115 and have people who need this functionality get it via a package. See #12115 (comment). Thoughts? Especially @quinnj, who hasn't chimed in about that yet.

[mbauman]

It seems like we really want to define *(::AbstractArray, ::Not{AbstractArray}), with some magical Not{} that's the opposite of Union{}.

[StefanKarpinski]

It seems like we really want to define *(::AbstractArray, ::Not{AbstractArray}), with some magical Not{} that's the opposite of Union{}.

There goes decidability of subtyping.

[jakebolewski]

You can do subtyping with negation types and have it be decidable.

[StefanKarpinski]

Sure, but is Julia's subtyping decidable if you add negation types? I'm not sure, but I doubt it.

[timholy]

OK, I think I found a minimalistic way to do this. When I looked more carefully, the Array/Scalar operations were not really the core source of the problem.

[mbauman]

call(::DotRDivFun?

[timholy]

'Doh! Thanks.

[tkelman]

Yeah, this looks much simpler and uncontroversial now.