|
Lexicographical access to arrays
John Cowan
(09 Apr 2026 18:59 UTC)
|
|
Re: Lexicographical access to arrays
Per Bothner
(09 Apr 2026 19:47 UTC)
|
|
Re: Lexicographical access to arrays
Alex Shinn
(09 Apr 2026 23:48 UTC)
|
|
Re: Lexicographical access to arrays
Bradley Lucier
(10 Apr 2026 00:22 UTC)
|
|
Re: Lexicographical access to arrays Per Bothner (10 Apr 2026 01:48 UTC)
|
|
Re: Lexicographical access to arrays
John Cowan
(10 Apr 2026 05:52 UTC)
|
|
Re: Lexicographical access to arrays
Bradley Lucier
(10 Apr 2026 15:33 UTC)
|
|
Re: Lexicographical access to arrays
Bradley Lucier
(10 Apr 2026 15:36 UTC)
|
|
Re: Lexicographical access to arrays
Bradley Lucier
(11 Apr 2026 00:32 UTC)
|
|
Re: Lexicographical access to arrays
John Cowan
(11 Apr 2026 04:03 UTC)
|
|
Re: Lexicographical access to arrays
Bradley Lucier
(11 Apr 2026 17:37 UTC)
|
On 4/9/26 17:22, Bradley Lucier wrote:
> "Sharing" specialized arrays as in Kawa (and, to be clear, I don't know Kawa)
I'm not talking about Kawa - I'm talking about SRFI-164.
> and SRFI 231 (and NumPy and Racket and ...) means that elements that are "adjacent" in row-major order can be widely dispersed in memory.
>
> And that doesn't even get into "generalized" arrays.
>
> So the only way to implement something like array-major-aref would be something like Kawa's rowMajorToEffectiveIndex in ./gnu/lists/Arrays.java (and speaking of things I don't know, I don't know Java) which would take your number n and compute a multi-index
>
> i_0 i_1 ... i_d-1
>
> by finding the remainder and quotient of n by successive dimension sizes ("width"s in SRFI 231).
While in the general case you do need a number of remainder/quotient operations,
I don't think it needs to be a primitive operation as in Kawa: that's an artifact
of Kawa trying to efficiently handle many variants without excessive code bloat.
(I was trying to minimize the amount of boxing needed given the many possible
combinations of ranks, low-level uniform vectors types, and transformations.
It was probably overly complicated, and newer JVM developments would probably
have changed the tradeoffs.)
> That is not an efficient way to access array elements. To do something to all array elements in row-major order, it would be better to use a bulk array operation like array-for-each (or interval-for-each if you want to work at the multi-index level), which steps through the array elements in row-major order.
I agree - it is not in an efficient way to access array in the general case.
However, SRFI-164 does have the concept of "simple array", implemented as simple
transform of a an underlying simple vector. In those cases, array->vector is trivial
(just extract the underlying vector), and thus array-major indexing is trivial.
In the general case, you can make a copy to an efficient vector using array-flatten.
I'm not really arguing for array-major-aref, but I suggest if you're going to
have it, I'd provide it in the form of a transformation, like array->vector.
And optimize the "simple array" case.
--
--Per Bothner
xxxxxx@bothner.com http://per.bothner.com/