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: 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: Following up on SRFI 179 Alex Shinn 28 Sep 2021 07:36 UTC

On Sun, Sep 26, 2021 at 1:43 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.
>
> How about this for names and signatures?  Square brackets denote
> optional arguments:
>
> (define (array-stack  [storage-class
>                        [safe? (specialized-array-default-safe?)
>                        [mutable? (specialized-array-default-mutable?)]]]
>                        k array . arrays)
> )
> (define (array-append [storage-class
>                        [safe? (specialized-array-default-safe?)
>                        [mutable? (specialized-array-default-mutable?)]]]
>                        k array . arrays)
> )
>
> So if you want to specify mutable? you need to specify both
> storage-class and safe?.

Do we need to allow overriding the parameters directly here?
The caller can always use parameterize.

> I don't think storage-class should have a default.  If storage-class is
> not given then (a) if all arrays are specialized and have the same
> storage-class, then that's the storage-class of the result, otherwise
> (b) it's an error.  Every default I can imagine can lead to surprising
> errors down the road.

The default can store any value.  I think the biggest danger is it
could be much less efficient than expected.  The Gauche array
operations use the smallest backing storage that encompasses
all inputs, but that approach doesn't work with an open-ended set
of storage classes (which may not even be orderable).

On the other hand, requiring all inputs to have the same storage
class when the argument is omitted can break surprisingly when
one of the input storage classes changes for some reason.

> Also, I think that these should return a newly allocated specialized
> array even if arrays is the empty list.

I was actually considering an optimization where if we knew the
arrays were views into the same original array, we could return that :)

I don't feel strongly about this though.

--
Alex