Dispatchable representations for one and zero

[oschulz]

My apologies in case this has been suggested before: I propose to add types One <: Integer and Zero <: Integer to the language (or some other dispatchable representation, see below).

We currently do have dispatchable, precision-independent representations for (e.g.) π and ℯ, and the concept has worked very well. I would argue that one and zero are even more fundamental concepts, and there should be a resolution-independent and dispatchable representation for them.

A nice prototype by @perrutquist exisits (https://github.com/perrutquist/Zeros.jl) - but in the end, this can't really be done outside of Base without type piracy (so Zeros.jl needs Zeros.@pirate Base).

Instead of separate types for one and zero we could, of course, also have something like IntegerVal{1} and IntegerVal{0}, similar to Irrational.

Having a dispatchable one and zero would allow for zero-memory arrays fill with one and zero, eliminating the need for constructs like FillArrays.Ones (one would simply use Fill(One(), n), CC @mcabbott, @dlfivefifty).

In addition, there would be a lot of potential for automatic and specialization-based code optimization. Statistics code that supports weights would run the same speed for One() weights as the unweighted version of the algorithm, while offering a single generic user interface, and so on (CC @nalimilan, @andreasnoack).

One could also dispatch on things like Distributions.Normal(Zero(), One()) for optimized code (CC @devmotion, could be very useful for prior transformations to standard normal and such).

Also concepts like one- and zero-valued gradients/tangents could profit from having a native, dispatchable one and zero (CC @oxinabox).

Also relates to #41840 (CC @mkitti): Having One and Zero would also very elegantly allow for

(::Colon)(::Zero, n) = Base.ZeroTo(n)
(::Colon)(::One, n) = Base.OneTo(n)

(We could add Base.ZeroTo at the same time, would be nice to have anyway.)

one and zero would continue to serve as ways to handle type/precision-specific ones and zeros.

[JeffBezanson]

😬

[oschulz]

@JeffBezanson , does the 😬 mean that it's a bad idea or that implementing it troublesome? 😉

[dlfivefifty]

Note that Fill(One(), n) will have eltype of One so is not the same as Ones

[oschulz]

Note that Fill(One(), n) will have eltype of One so is not the same as Ones

Oh, sure - I didn't mean as a direct replacement - though with a One in the language, maybe that would make for a better eltype of Ones long-term?

[perrutquist]

If One were part of Base, then there wouldn't be a need for a separate Base.OneTo. One could simply extend e.g. Base.StepRange to take an extra type parameter for the type of the starting value. (To avoid breaking things, let's call this new range type StartStepRange. The old StepRange{S,T} would simply be an alias for StartStepRange{T,S,T}.)
We can then implement OneTo in one line:

const OneTo{T} = StartStepRange{One, One, T}

ZeroTo{T} would be StartStepRange{Zero, One, T}, and UnitRange{T} would be StartStepRange{T, One, T}, etc.

[oscardssmith]

I think this is probably a good idea, but it will be a fairly big change.

[JeffBezanson]

I think these kinds of types, e.g. Irrational, have proven to be a mixed bag. When you consider the cases where they work well, it seems great and magical, but then they also cause an unending stream of bugs and missing methods. For example initializing something as x = Zero() is asking for type instabilities. We can say "don't do that", but that adds complexity. Having a type with only one instance also strains the definition of Integer in various other ways.

[vtjnash]

This isn't likely to be something we do in Base, though people can do whatever they want in packages and we can't interfere too much with those choices.

[dlfivefifty]

I agree with @vtjnash.

but in the end, this can't really be done outside of Base without type piracy

But none of @oschulz examples make clear why this needs to be in Base. Perhaps he can elaborate on why he felt it needed in Base?

Even if it's not going to be added, it's a good idea to have a record of what the trade-offs are in case it comes up again.

[oschulz]

But none of @oschulz examples make clear why this needs to be in Base.

Hm I took a closer look at https://github.com/perrutquist/Zeros.jl/blob/master/src/pirate.jl - it's indeed not a lot, and most of it wouldn't be acceptable in Base anyhow.

It would be kinda cool to have things like Base.sin(::Irrational{:π}) = Zero(), but it would be a breaking change, so we couldn't do it in v1.x anyway. So I'll retract my statement - it does not have to be done in Base. Adding it to the language would definitely increase the number of packages who use it (compared to having it in a package), but I realize that's not a strong enough argument.

[perrutquist]

I would say the only reason to have One and/or Zero in Base would be if they were actually used there. The methods introduced by Zeros.@pirate Base could all return one of false, true or 0.0 if needed.

[goretkin]

I think there are two separate things going on:

1. a generic One and Zero
2. "static" values (e.g. https://github.com/perrutquist/StaticNumbers.jl)

2 represents e.g. Int32(0) and Int64(0) differently, and I think that makes it easier to define how they behave, avoiding the issues raised here.

It means that Base.OneTo(n) is represented as something like

struct StepRange2{T1, T2, T3}
    start::T1
    step::T2
    stop::T3
end

Base.OneTo(n) = StepRange(Val{one(n)}(), Val{one(n)}(), n)

where the static "one" has an underlying value matching the type of n.

See also https://github.com/Tokazama/StaticRanges.jl