SRFI 231 - Easy conversion for common array formats Jens Axel Søgaard (13 Jan 2022 15:53 UTC)
Re: SRFI 231 - Easy conversion for common array formats Bradley Lucier (13 Jan 2022 19:30 UTC)
Re: SRFI 231 - Easy conversion for common array formats Jens Axel Søgaard (13 Jan 2022 21:46 UTC)
Re: SRFI 231 - Easy conversion for common array formats Bradley Lucier (16 Jan 2022 22:11 UTC)
Re: SRFI 231 - Easy conversion for common array formats John Cowan (17 Jan 2022 18:50 UTC)
Re: SRFI 231 - Easy conversion for common array formats Bradley Lucier (18 Jan 2022 16:52 UTC)
Re: SRFI 231 - Easy conversion for common array formats John Cowan (19 Jan 2022 23:25 UTC)
Re: SRFI 231 - Easy conversion for common array formats Lucier, Bradley J (19 Jan 2022 23:45 UTC)
Re: SRFI 231 - Easy conversion for common array formats Bradley Lucier (20 Jan 2022 15:54 UTC)
Re: SRFI 231 - Easy conversion for common array formats Jens Axel Søgaard (20 Jan 2022 16:19 UTC)
Re: SRFI 231 - Easy conversion for common array formats Bradley Lucier (20 Jan 2022 17:57 UTC)
Re: SRFI 231 - Easy conversion for common array formats Jens Axel Søgaard (20 Jan 2022 19:08 UTC)

Re: SRFI 231 - Easy conversion for common array formats Bradley Lucier 13 Jan 2022 19:30 UTC

On 1/13/22 10:52 AM, Jens Axel Søgaard wrote:
> Hi All,
>
> Existing Scheme libraries often represent array-like or matrix-like data
> as nested lists or as nested vectors. It's common to see the values
>
>    '((1 2)
>      (3 4))
>
> and
>
>    #'(#(1 2)
>        #(3 4))
>
> representing a 2x2 matrix.
>
>
> In order to use srfi 231 from older code, it would make sense to have
> functions that convert back and forth between old and new.
>
> If this is a good idea, I suggest the names  lists->array and
> vectors->array
> or perhaps nested-list->array and nested-vector->array.
> As default they construct an array with a generic storage class.
>
> The dimension of the new array is implicitly determined by the input data.
> There needs to be a check that the axis sizes are consistent.
>
> /Jens Axel
>

This suggestion raises some questions in my mind.  My thinking is not
very clear on this topic.

1.  This notation seems useful mainly for small arrays (in size and in
dimension).  In my case I've used

(list->array '(1 2
                3 4)
              (make-interval '#(2 2)))

In my image-processing apps, arrays are never small enough to be
represented as constants in code.

So question (1): How useful is this notation outside of writing
documentation, etc., where you want to use small examples?  Or would you
use it as a quick and easy format for reading and writing array data to
files?  Or something else?

2.  More generally, I've asked in various forums (fora?) about how
people use arrays, in Scheme and other languages, but did not get any
replies.  In my studies, it seems that APL turns everything into arrays
(even some control structures in some sense), I've used Matlab and
spreadsheets to teach numerical methods, and I understand vectors,
matrices, and tensors, but I don't know how other people use arrays.

So, do some people write a lot of array code with literal array
constants?  That would be interesting to know.

3.  An array with a generic storage class can store lists or vectors or
other arrays as its entries, so without specifying a domain interval, or
at the very least a domain dimension, the examples you give are
ambiguous.  I suppose if arrays hold only numbers, then it is unambiguous.

4.  Would one also like array->nested-lists or array->nested-vector?
Right now there's array->list but not array->vector.