Implications of array broadcasting
Bradley Lucier
(24 Oct 2024 18:55 UTC)
|
Re: Implications of array broadcasting
Alex Shinn
(28 Oct 2024 06:17 UTC)
|
Re: Implications of array broadcasting
Bradley Lucier
(30 Oct 2024 23:57 UTC)
|
Re: Implications of array broadcasting
Alex Shinn
(31 Oct 2024 13:15 UTC)
|
Re: Implications of array broadcasting Bradley Lucier (02 Nov 2024 04:24 UTC)
|
Re: Implications of array broadcasting
Alex Shinn
(03 Nov 2024 22:21 UTC)
|
Re: Implications of array broadcasting
Bradley Lucier
(05 Nov 2024 03:08 UTC)
|
Re: Implications of array broadcasting
Alex Shinn
(07 Nov 2024 00:27 UTC)
|
Re: Implications of array broadcasting
Bradley Lucier
(07 Nov 2024 20:29 UTC)
|
Re: Implications of array broadcasting
Alex Shinn
(08 Nov 2024 00:01 UTC)
|
Re: Implications of array broadcasting
Bradley Lucier
(08 Nov 2024 20:51 UTC)
|
Re: Implications of array broadcasting
Alex Shinn
(08 Nov 2024 22:54 UTC)
|
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. Given this, I don't see a real big problem with copying this smaller argument array if necessary before broadcast. Brad