[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
vectors are something else
From: |
Daniel Llorens |
Subject: |
vectors are something else |
Date: |
Thu, 11 Apr 2013 01:07:41 +0200 |
After the array-map patches, I've gone through the vector/array implementation
and there's some stuff I'd like to fix. In stable-2.0 today:
(define a (make-typed-array ''f64 0 '(1 2))
a
=> address@hidden(0.0 0.0)
so far so good.
(uniform-vector? a)
=> #t
(f64vector-ref? a)
=> #t
so far so good.
(uniform-vector-ref a 0)
=> 0.0
This is a bug, since the valid indices are 1 and 2. This bug is in
scm_c_generalized_vector_ref (and elsewhere):
pos = h.base + h.dims[0].lbnd + idx * h.dims[0].inc
this should be (to fix the bug: it shouldn't be written like this, but let's
leave that aside for now)
pos = h.base + (idx - h.dims[0].lnbd) * h.dims[0].inc
Cf.
(vector-ref address@hidden(1 2 3 4) 1)
=> 2 (wrong)
but
(array-ref address@hidden(1 2 3 4) 1)
=> 1 (right)
I have patches for the above; however, the problems go well beyond.
(bitvector? (make-typed-array 'b #t 2))) => #t
(bitvector? (make-typed-array 'b #t '(1 2))) => #f
(bitvector-ref (make-typed-array 'b #t '(1 2))) => type error (consistent with
#f)
(bytevector? (make-typed-array 's8 0 2))) => #t
(bytevector? (make-typed-array 's8 0 '(1 2))) => #f
(bytevector-ref (make-typed-array 's8 0 '(1 2))) => type error (consistent with
#f)
(s8vector? (make-typed-array 's8 0 2))) => #t
(s8vector? (make-typed-array 's8 0 '(1 2))) => #t
(s8vector-ref (make-typed-array 's8 0 '(1 2))) => type error (inconsistent with
#t)
(uniform-vector? (make-typed-array 's8 0 2))) => #t
(uniform-vector? (make-typed-array 's8 0 '(1 2))) => #t
(uniform-vector-ref (make-typed-array 's8 0 '(1 2))) => 0 (consistent with #t,
but wrong)
(vector? (make-typed-array #t 0 2))) => #t
(vector? (make-typed-array #t 0 '(1 2))) => #f
(vector-ref (make-typed-array #t 0 '(1 2)) 0) => 0 (inconsistent with #f *and*
wrong)
This is what I would like to do:
Force, and assume, inc and base to be 1 & 0 for uniform-vector /
[srfi4type]vector / vector. That is, make all of the above behave as bitvector
and bytevector. The advantanges are
a. the array implementation can rely on all these types having known base=0 and
inc=1.
b. consistency.
Some programs may break, but they can't have relied on the behavior above
without being broken already. Nobody has reported these bugs for a long time
and the tests don't see them, I say we're good to go.
Thoughts?
Daniel
--
PS Some other, clearly worse, options:
1. Fix the bug above in uniform-vector-ref, etc. by having all the
uniform-vector functions be aliases for array-ref. For consistency, do the same
for bitvector- and bytevector- and srfi4vector- . Then all those functions pay
the abstraction cost of using array- (which is not so much the rank as the
type). It's also a fair amount of work. For example, the printer for uniform
vectors depends on the first valid index being 0, so just fixing the buggy line
above breaks the printer. The documentation does say that uniform-vectors are
indexed from 0...
2. Fix the bug above in uniform-vector-ref, etc. by allowing inc!=1 and base!=0
for non-array objects. This will push some of the array functionality into
bitvector, bytevector, etc (where inc=1 and base=0 are hardcoded) and generally
complicate the code. Ditto for fixes required in other places.
3. Do 0, 1, or 2 differently for each of the vector types, e.g. Having
srfi4vector- and uniform-vector- behave like bytevector-, but vector- behave
like array-. Besides not making much sense, it would complicate the
implementation of arrays (by which I mean, it wouldn't allow simplification
that is sorely needed).
- vectors are something else,
Daniel Llorens <=