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)
Re: array-copy, array-stack, array-append: What should the defaults be? Alex Shinn (04 Oct 2021 08:24 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)

Re: array-copy, array-stack, array-append: What should the defaults be? Alex Shinn 04 Oct 2021 08:23 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