Following up on SRFI 179
Bradley Lucier
(22 Sep 2021 22:30 UTC)
|
Re: Following up on SRFI 179
John Cowan
(24 Sep 2021 19:24 UTC)
|
Re: Following up on SRFI 179
Alex Shinn
(25 Sep 2021 13:24 UTC)
|
Re: Following up on SRFI 179
Bradley Lucier
(25 Sep 2021 16:43 UTC)
|
Re: Following up on SRFI 179
Alex Shinn
(28 Sep 2021 07:36 UTC)
|
Re: Following up on SRFI 179
Bradley Lucier
(28 Sep 2021 20:20 UTC)
|
Re: Following up on SRFI 179
Bradley Lucier
(28 Sep 2021 20:30 UTC)
|
Re: Following up on SRFI 179
Bradley Lucier
(01 Oct 2021 00:07 UTC)
|
Re: Following up on SRFI 179
Alex Shinn
(01 Oct 2021 00:43 UTC)
|
array-copy, array-stack, array-append: What should the defaults be?
Bradley Lucier
(02 Oct 2021 18:42 UTC)
|
Re: array-copy, array-stack, array-append: What should the defaults be? Alex Shinn (04 Oct 2021 08:24 UTC)
|
Re: array-copy, array-stack, array-append: What should the defaults be?
Bradley Lucier
(04 Oct 2021 14:27 UTC)
|
Re: array-copy, array-stack, array-append: What should the defaults be?
Alex Shinn
(04 Oct 2021 21:34 UTC)
|
Re: array-copy, array-stack, array-append: What should the defaults be?
Bradley Lucier
(04 Oct 2021 22:04 UTC)
|
Re: array-copy, array-stack, array-append: What should the defaults be?
John Cowan
(04 Oct 2021 22:39 UTC)
|
Re: array-copy, array-stack, array-append: What should the defaults be?
Bradley Lucier
(16 Jan 2022 18:56 UTC)
|
Re: Following up on SRFI 179
Lucier, Bradley J
(05 Oct 2021 01:04 UTC)
|
Re: Following up on SRFI 179
John Cowan
(06 Oct 2021 01:26 UTC)
|
Re: Following up on SRFI 179
Lucier, Bradley J
(06 Oct 2021 13:48 UTC)
|
Re: Following up on SRFI 179
Bradley Lucier
(05 Oct 2021 19:54 UTC)
|
array-{append|stack|inner-product}
Bradley Lucier
(21 Oct 2021 15:52 UTC)
|
On Sun, Oct 3, 2021 at 3:42 AM Bradley Lucier <xxxxxx@math.purdue.edu> wrote: > > On 9/25/21 9:23 AM, Alex Shinn wrote: > >> 3) (array-append k a1 a2 ...) > >> > >> 4) (array-laminate k a1 a2 ...) > > Both of these are provided by (chibi math linalg): > > https://github.com/ashinn/alschemist/blob/master/chibi/math/linalg.scm > > For consistency with numpy, laminate is called stack, and the axis > > refers to the result dimension so has the more natural domain [0, > > res-dim). > > They are fairly general and I agree should be in the base library > > rather than a linear algebra library. > > I'm working to implement these as > > (array-append [storage-class] k a1 a2 ...) > (array-stack [storage-class] k a1 a2 ...) > > I'm leaning to say that if storage-class is not specified, then if a1 a2 > ... all have the same storage class, then that storage class is used, > otherwise generic-storage-class is used. The mutability and safety of > the result is determined by the settings of > (specialized-array-default-mutable?) and (specialized-array-default-safe?). That sounds reasonable. > This led me to think again about > > (array-copy array [storage-class [mutable? [safe?]]]) > > and the commit message of > > https://github.com/gambiteer/srfi-179-followup/commit/f2de257e87f341dc1edff0e7b060394bd9960349 > > says that > > 1. If the first argument to array-copy is a specialized array, then the > values of omitted arguments storage-class, mutable?, and safe? are taken > from the first argument, not generic-storage-class, > (specialized-array-default-mutable?), and > (specialized-array-default-safe?), respectively. > > So the new array is a true copy of the input specialized array. > > Any thoughts about what the defaults should be? I think this is fine - since the name says it is making a copy, it's reasonable to copy as faithfully as possible. The other original procedures returning new arrays are all transforms based on specialized-array-share, which also takes mutability and safety from the array argument. Since these are views sharing the same underlying storage it arguably makes more sense to share these settings than in a copy. The new procedures array-append and array-stack are special in that they take more than one array argument, so the more complex default is acceptable. But I still think it's worth considering making these constants instead of parameters, in which case for array-append and array-stack we need to revert to your more complex proposed signature. -- Alex