On 10/31/24 09:15, Alex Shinn wrote:
> So we
> are left with the dilemma: array-broadcast is an efficient
> way to broadcast without copying data, but we require the
> input to it to be copied (or to have been immutable to begin
> with which is not always practical).
That's true.
It seems that arrays are usually broadcast to expand a small array to
match a larger array by repeating the elements of the small array. So
the argument to array-broadcast usually has many fewer entries compared
to the result, and to the domains of the other arrays in the operation.
Actually, in many cases the broadcast just amounts to a reshape,
without increasing the size, so copying the input loses 100% of the
benefit. In other cases you may only replicate 2 or 3 times, so the
copy is still a substantial fraction of the result size.
On the other hand, I don't really see what the problem is.
Mutating the broadcast result is obviously problematic because
you can mutate the same underlying element multiple times, but
this is resolved by making the result immutable. However, I
don't see what's surprising about the results when mutating the
input. If you mutate one element of the input then multiple
elements in the result will be changed, but that's to be expected,
and if you made the same mutation _before_ broadcasting then
you'd see the same result.
I think it's fine to make the result immutable but allow the input
to be mutable.