add zeros! and ones!, mutating versions of zeros and ones

[rfourquet]

The current alternative is to use fill!(x, 0), but this does not always
work, when convert(eltype(x), 0) is not defined, for example
when x is an array of DateTime objects.

Another benefit of introducing zeros! is that in some cases, the zero
element can't be known from the eltype alone, but rather from the values.
In this case, package can define their own appropriate method.
For example, we could define in Base a zeros!(::AbstractArray{<:AbstractArray})
which replaces each value v by zero(v).

[vtjnash]

Your second proposal of zeros!(x) = map!(zero, x, x) does sound like a good definition too (which is also the same as zeros!(x) = x .= zero.(x)). They all seem relatively trivial though, just depending on which we think is better.

[palday]

The current alternative is to use fill!(x, 0), but this does not always work, when convert(eltype(x), 0) is not defined, for example
when x is an array of DateTime objects.

If there is a (semantically) well-defined zero object for a type, then shouldn't the convert method also be defined, just on principle? And if it's not well defined, then any definition of zeros! seems problematic....

(Not commenting on the utility of the proposed functions in general, just that one part of the motivation.)

[rfourquet]

Your second proposal of zeros!(x) = map!(zero, x, x) does sound like a good definition too

Yes, I was just wondering about the case where constructing a zero is not cheap (zeros/fill! do fill the arrays with one unique object). But this could probably indeed be the default.

If there is a (semantically) well-defined zero object for a type, then shouldn't the convert method also be defined, just on principle?

I'm not sure that it makes sense for all objects defining zero to be created from 0 via convert. For example for DateTime objects.
Another point is that many types can have zero objects, but which can't necessarily be instantiated from the type alone. An example is zero vectors: zero([1]) works, but zero(typeof([1])) is not well defined. AbstractAlgebra and Nemo packages for example define tons of such types. Also, like for DateTime, imagining a matrix type which knows its dimensions, it's not clear that you should be able to create a zero matrix by converting from the integer 0 (a zero matrix is well defined but is not necessarily viewed as a number).

[palday]

Another point is that many types can have zero objects, but which can't necessarily be instantiated from the type alone.

Doesn't this hold equally for zero(T) and convert(T, 0)? I would generally expect convert(T, 0) to have similar semantics as zero(T), because if it's a zero value in that type, we should feel comfortable calling it 0. (But I can see the the argument for forcing a distinction between numeric multiplicative and additive identities/null and unit values and more general notions of these concept). My comment on zero objects was meant to be more general: if zero(T) doesn't make sense, then zeros(T, ...) shouldn't either.

Splitting hairs a bit here because I think this is the type of semantics that need to be very well documented for corner cases / counterintuitive behavior. 😄

[fredrikekre]

xref #19912