Re: vectors are something else

[Daniel Hartwig]

On 12 April 2013 20:37, Daniel Llorens <address@hidden> wrote:

[Tail first:]

> After [0], I'm open on allowing general, 0-indexed, rank-1
> arrays to the vector- functions, but I'll send the patches
> anyway that forbid this. The tests all pass (which maybe shows
> how poor the coverage is).
>

Great.  This strikes a nice balance, with simple enough semantics
and flexability to massage array data for vector-coded modules.
I doubt _anyone_ will miss using non-0-indexed arrays that way.

> It's should be simple to revert to the permissive vector-
> behavior (minus the bugs) if that's what we end up deciding.

Yes, bugs :-)


>
> Message: 8
> Date: Fri, 12 Apr 2013 18:15:05 +0800
> From: Daniel Hartwig <address@hidden>
>
>> Too restrictive IMO, you may as
>> well just not permit any array passed to vector
>> interfaces.
>
> Being restrictive would be my preference, yes.
>
>> [Besides, you can already get at the underlying vector
>> using ?shared-array-root?.]
>
> That would cover your 'passing data without copying' scenario
> below, although admittedly only when inc=1.
>

Not so useful when you want to work with e.g. a subset of the
data.

>> This compatibility is based on the
>> indices themselves, not how they are calculated (e.g ?inc!=1? is
>> not relevent for compatibility).
>
>
> [0] This is true. It makes logical sense to allow rank-1 arrays
> with lbnd 0 to be accepted by the vector functions. I can go
> back on this.

This also matches the note in the manual about vectors being the
special case of rank-1 arrays.  It is implied that these are
0-indexed, rank-1 arrays.

> I think that allowing (vector-ref address@hidden(a b c d) 0) is a logical
> error and it doesn't make sense to me as an extension.

We approached this from two different angles, based on whether
the object or the type defines the indices.

In any case, treating these non-0-indexed arrays as vectors is
a complicated semantic, that is difficult to justify and not
needed given:

> You can obtain a proper 0-indexed vector from this without
> copying by using make-shared-array (in the general case)
>
> (make-shared-array address@hidden(a b c d)
>   (lambda (i) (list (+ i 1))) 4)
> => #(a b c d)
>


>> This suggestion:
>>
>>> Might as well have (vector-ref address@hidden(1 2 3 4) 1) work properly
>>> [by returning ?1? instead of ?2?].
>>
>> is not possible: the vector interface must use vector indexing
>> which means the first element of any object has index ?0?.
>
> Only true if that object is a vector; otherwise we can do whatever we want.
>

Ah.  Of course the vector interface is only (currently) specified
for vectors :-)

>> For non-rank-1 arrays, the indices are clearly incompatible
>> though ?array-contents? already establishes a precedent for
>> the rank-1 ordering of the elements, and supporting that
>> case could be possible as well.
>
> array-contents doesn't work on general arrays, only on arrays
> that can be unrolled without copying. You can always unroll
> explicitly.
>
> There can be an array-row-major-ref function, if somebody finds
> that useful. E.g.
>
> http://trac.sacrideo.us/wg/wiki/ArraysCowan
>

Neat.

> There's C interface for this in Guile. I'm against extending
> vector-ref to do it. Same for any other implicit unrolling as
> some NumPy functions do.
>

Right.  Best to keep interfaces simple and predictable.