Scalar type for broadcasting

[TotalVerb]

I found myself needing a Scalar type for broadcasting purposes, to trick broadcast into not trying to broadcast something, even though it is a matrix. An initial (bad) implementation is here.

With #16986 close to merging, I wonder if such a feature would be desirable in Base.

[stevengj]

@TotalVerb, can you give an example of where you needed this?

[stevengj]

Wouldn't storing something in a 0-dimensional array do the trick?

[pabloferz]

After #16986 you might also wrap the array with a tuple as pointed out here #17411 (comment).

[TotalVerb]

That's a good point; this Scalar type is just a one-element tuple. The only difference is that I envision Scalar(1) .+ 1 to be 2, whereas (1,) .+ 1 to be (2,). That is to say, Scalar would be a zero-dimensional tuple, instead of a one-dimensional tuple with one element.

[TotalVerb]

@stevengj The current implementation of Scalar is basically just a 0-dimensional array, but it's a little slower than necessary because of the extra allocation.

[TotalVerb]

@stevengj An example of where I needed this is to support broadcasting for Basket, which are a collection of currencies. It is useful to support both broadcasting over the individual instruments within the collection, and to support broadcasting the collections as if they were instruments in their own right.

Another example is given in the README for Scalars.jl.

[stevengj]

(An aside: I don't think you need to define show(io, "text/plain", x) if you just want it to call show(io, x), as the former calls the latter by default.)

[TotalVerb]

@stevengj It's to override the method inherited from AbstractArray.

[stevengj]

Oh, right.

[stevengj]

A simpler solution, that wouldn't require us to define any new types, is for broadcast to treat Ref(x) as a 0-dimensional array of x. This seems like something we should do anyway, because that's effectively what Ref is, and it seems relatively easy to add once #16986 is merged.

[StefanKarpinski]

Related: #18271 (comment), wherein I proposed using Ref(x) with the syntax &x as a means of not dropping a scalar dimension when slicing or reducing. Of course, that entails considering Ref to be a 1-dimensional container, whereas this entails considering it to be a 0-dimensional container.

[TotalVerb]

I'm worried that the compiler may not be able to eliminate the allocation of a Ref.

[stevengj]

@StefanKarpinski, since you access a ref with ref[], it doesn't make sense to me to treat it as anything other than a 0-dimensional array. (Of course, getindex can always implement whatever method it wants for a Ref argument if you want magic handling of &x.)

@TotalVerb, in the rare cases where the heap allocation of a Ref object would matter compared to the cost of a broadcast over arrays of arrays, presumably in some kind of tight inner loop, couldn't you simply allocate the Ref outside the loop and mutate it as needed?