Re: vectors are something else

guile-devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vectors are something else

From:	Daniel Llorens
Subject:	Re: vectors are something else
Date:	Sat, 13 Apr 2013 02:40:55 +0200

Hello,

I've written this patch set while trying to understand how arrays are 
implemented in Guile. It does the following things.

1. array objects (most things produced by the array interface) are never 
vector? or uniform-vector?

Therefore, basic functions such as vector-ref, vector-length, etc. will fail 
with a type error on these objects. This is the behavior of bytevector-; after 
the patches each of these sets gives the same result (#t, #f, type error, type 
error)

(import (rnrs bytevectors))
(define (every-two a) (make-shared-array a (lambda (i) (list (* i 2))) 2))

(bitvector? (make-typed-array 'b #t 2))
(bitvector? (make-typed-array 'b #t '(1 2)))
(bitvector-ref (make-typed-array 'b #t '(1 2)))
(bitvector-ref (every-two (make-typed-array 'b #t 4)) 0)   <--------- except 
for this one

(bytevector? (make-typed-array 's8 0 2))
(bytevector? (make-typed-array 's8 0 '(1 2)))
(bytevector-s8-ref (make-typed-array 's8 0 '(1 2)) 0)
(bytevector-s8-ref (every-two (make-typed-array 's8 0 4)) 0)

(s8vector? (make-typed-array 's8 0 2))
(s8vector? (make-typed-array 's8 0 '(1 2)))
(s8vector-ref (make-typed-array 's8 0 '(1 2)) 0)
(s8vector-ref (every-two (make-typed-array 's8 0 4)) 0)

(uniform-vector? (make-typed-array 's8 0 2))
(uniform-vector? (make-typed-array 's8 0 '(1 2)))
(uniform-vector-ref (make-typed-array 's8 0 '(1 2)) 0)
(uniform-vector-ref (every-two (make-typed-array 's8 0 4)) 0)

(vector? (make-typed-array #t 0 2))
(vector? (make-typed-array #t 0 '(1 2)))
(vector-ref (make-typed-array #t 0 '(1 2)) 0)
(vector-ref (every-two (make-typed-array #t 0 4)) 0)

After the discussion with Daniel Hartwig (not in this patchset), every fourth 
case would work as with bitvector. That's the behavior of stable-2.0 except for 
bytevector-s8-ref (& friends). In stable-2.0, the offset-1 cases are all broken 
except for bytevector-s8-ref (& friends).

2. Any object obtained from SCM_I_ARRAY_V is assumed to have base 0, inc 1, 
lbnd 0. This is true of all such objects (bitvector, bytevector, string and 
vector). This removes a bunch of redundant (and sometimes buggy) index 
computation in array-map.c, arrays.c, etc.

3. scm_array_get_handle places pointers to the underlying vector implementation 
in the array handle, so that is called directly instead of going through 
array_handle_ref and array_handle_set. This results in minor speedups of 
array-copy! and array-fill! and the following speedup of two-arg array-map!:

(define a (make-array 0. 1000000 10))
(define b (make-array 0. 1000000 10))
(define c (make-array *unspecified* 1000000 10))

before:

scheme@(guile-user)> ,time (array-map! c (lambda (a b) (+ a b)) a b)
;; 3.796000s real time, 3.780000s run time.  0.520000s spent in GC.

after:

scheme@(guile-user)> ,time (array-map! c (lambda (a b) (+ a b)) a b)
;; 2.789000s real time, 2.800000s run time.  0.310000s spent in GC.

These timings are still terrible though. The main benefit is that the impl-> 
call sequence is now easier to follow.

4. vectors are identified with 'simple vectors', so uses of simple-vector-ref 
and such have been replaced by vector-ref and such.

5. remove uses of most generalized-vector functions.

5. extra tests, bits and pieces, such as transpose-array now works with rank 0 
arrays. 

All tests in stable-2.0 pass as they were.

I've seen at least a new bug: this fails at the repl after, it succeeded before.

scheme@(guile-user)> address@hidden(1 2 3)
While compiling expression:
ERROR: Wrong type (expecting vector): address@hidden(1 2 3)

However, this works fine:

scheme@(guile-user)> (call-with-input-string "address@hidden(1 2 3)" read)
$3 = address@hidden(1 2 3)

I haven't tried to debug this, but there're problems with the reader even in 
stable-2.0:

#b(#t #t) => error
#1b(#t #t) => ok
address@hidden(#t #t) => error
address@hidden(#t #t) => ok

my understanding is that all of these should work, and the printer actually 
produces the versions it doesn't read.

Anyway, the patches.

Regards

        Daniel

0001-Inline-generalized-vector-calls-in-array_handle_ref-.patch
Description: Binary data