belated feedback Alex Shinn (16 Apr 2021 15:00 UTC)
Re: belated feedback Bradley Lucier (16 Apr 2021 17:08 UTC)
Re: belated feedback John Cowan (16 Apr 2021 18:25 UTC)
Re: belated feedback Bradley Lucier (17 Apr 2021 21:48 UTC)
Re: belated feedback Alex Shinn (18 Apr 2021 23:45 UTC)
Re: belated feedback Bradley Lucier (16 Apr 2021 23:46 UTC)
Re: belated feedback Alex Shinn (17 Apr 2021 00:03 UTC)
Re: belated feedback Bradley Lucier (17 Apr 2021 01:10 UTC)
Re: belated feedback Alex Shinn (17 Apr 2021 01:22 UTC)
Re: belated feedback Alex Shinn (30 Apr 2021 05:41 UTC)
Re: belated feedback Bradley Lucier (30 Apr 2021 14:17 UTC)
Re: belated feedback John Cowan (30 Apr 2021 15:04 UTC)
Re: belated feedback Bradley Lucier (30 Apr 2021 16:42 UTC)
Re: belated feedback Alex Shinn (01 May 2021 09:27 UTC)
array-elements-in-order? (Was: belated feedback) Bradley Lucier (16 Jan 2022 19:08 UTC)

Re: belated feedback Bradley Lucier 16 Apr 2021 17:08 UTC

On 4/16/21 10:59 AM, Alex Shinn wrote:
> Hi Bradley,
>
> First, thank you for all the work you put into this beautiful SRFI.
> There have been a plethora of array SRFIs, but none as comprehensive.

Thanks!

> I'm sorry I didn't have time to contribute to the original discussion,
> but have gone through recently, and have written a clean room,
> portable R7RS implementation:
>
> https://github.com/ashinn/chibi-scheme/blob/master/lib/srfi/179.scm

It seems very clean.

> It passes your test suite, though I had to comment out many tests
> which made use of internals of your implementation.  I also want to
> make the test suite deterministic - randomized tests are extremely
> difficult to work with.

Yes.  I suppose one could reset the SRFI 27 state before each block of
random tests, so if you do 100 tests in one run and in another run 1,000
tests, then the first 100 of those 1,000 would use the same random
sequence as the run with only 100 tests.

> For specialized-array-reshape, I was lazy and took advantage of the
> fact that indexing is reversible (though not necessarily as an affine
> transformation), and created a custom indexer which is the following
> composition:
>
>    (compose orig-indexer invert-orig-indexer new-domain-indexer)
>
> Thus the reshape never fails.

I have to say I don't understand this.

In looking at your code it appears that reshape-indexer always returns a
lombda, so the first clause of the cond in specialized-array-reshape is
always taken.  Am I missing something?

As you say, I believe new-indexer in specialized-array-reshape won't
necessarily be affine, right? If so, I fear that further Bawden-style
array transforms on the reshaped array won't work correctly, but I
haven't worked out an example yet.

If I were to try to find a counterexample I'd start by looking at the
example in the SRFI document:

(define A (array-copy (make-array (make-interval '#(3 4)) list)))

(define B (array-sample A '#(2 1)))

(array-display (specialized-array-reshape B (make-interval '#(8)))) ;;
=> fails

(array-display (specialized-array-reshape B (make-interval '#(8)) #t))

;;; Displays

;;; (0 0)   (0 1)   (0 2)   (0 3)   (2 0)   (2 1)   (2 2)   (2 3)

In your implementation does

(array-display (specialized-array-reshape B (make-interval '#(8))))

succeed?  If so, does

(array-sample (specialized-array-reshape B (make-interval '#(8))) '#(3))

return what one might expect?

>  However, I intend to flatten all of the
> affine transformations next, at which point I'll need to implement
> this properly.

Again, I don't quite understand this, but maybe I don't need to.

> f8-storage-class and f16-storage-class are bound to #f.
>
> Planned upcoming applications of arrays:
>
> * images: a standard representation should probably be a SRFI of its own
> * linear algebra: wrapping blas and/or cuda, with NNs a trivial application
> * data frames: matrices with named columns, ideally using
> column-oriented storage classes
>
> Some minor comments on the document itself:
>
> In interval-cartesian-product, the definition refers to
> array-lower/upper-bounds->list, which should presumably be
> interval-lower/upper-bounds->list.

Good catch, I'll prepare a pull request.

> What are the default values of the safe/mutable parameters?

Good question.  In my implementation safe? starts off #f, and mutable?
starts off #t.  I'm pretty sure this was discussed somewhere in the mail
list, but it doesn't seem to be in the document.  I'll add it to the
pull request.

> The name and description of array-elements-in-order? is misleading,
> suggesting it is the elements themselves which must be in order.
> Perhaps array-indices-in-order? or array-contiguous-and-in-order?
> would have been better.

True.

Brad