Re: vectors are something else

[Daniel Llorens]

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.

> 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. However, those 
permissive functions should be part of the array implementation, even if they 
are part of the vector interface. Same for the uniform-vector- functions. And 
live with the bytevector-ref inconsistency.

> address@hidden(a b c d) is:
> 
> Element       a b c d
> Array index   1 2 3 4
> Vector index  0 1 2 3
> 
> There is some utility in permitting [1] where an arrays indices
> are vector-compatible: array data (or a subset) can be passed to
> a procedure expecting a vector without copying.

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. 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)

> Is it worth the overhead to support this in the vector code?  I
> think so, but then, haven't looked at the code :-)

The vector code can hardly support itself as it is :-(  

> 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.

> 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

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.

> Perhaps.  I assume that ?array-map!? etc. are more efficient for
> accessing multiple elements with the startup overhead is
> amortized over all the elements.

Unfortunately this is not so. The array-map functions are type generic and the 
type dispatch is done on each element access. Only the array handle access is 
amortized over each rank-1 section. This is something that I want to fix.

There are some vector functions that do type dispatch out of the inner loop, 
e.g. in libguile/random.c, and that's obviously how you would work with arrays 
in C outside of Guile.

I still think that array-ref shouldn't result in a chain of 4 nested calls.

> Are those results from stable-2.0?  I do not reproduce some of
> the type errors on my system, e.g.:
> 
> (bitvector-ref (make-typed-array 'b #t '(1 2)) 0) => #t

I've rebuilt and you are right, it must have been an older version.

>> a. the array implementation can rely on all [vector] types
>> having known base=0 and inc=1.
> 
> Is that not already the case?

It is, but for some reason the array functions don't make use of this fact. 
It's pretty confusing.

--

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).

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

Regards

        Daniel