From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Llorens Newsgroups: gmane.lisp.guile.devel Subject: vectors are something else Date: Thu, 11 Apr 2013 01:07:41 +0200 Message-ID: <26E44D8E-2A75-466E-BFAE-07E15F60A981@bluewin.ch> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1365635268 3122 80.91.229.3 (10 Apr 2013 23:07:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Apr 2013 23:07:48 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Apr 11 01:07:52 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UQ47M-0000ec-FK for guile-devel@m.gmane.org; Thu, 11 Apr 2013 01:07:52 +0200 Original-Received: from localhost ([::1]:50266 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQ47M-0005Sp-0U for guile-devel@m.gmane.org; Wed, 10 Apr 2013 19:07:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQ47H-0005S5-T8 for guile-devel@gnu.org; Wed, 10 Apr 2013 19:07:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQ47G-0003kB-Q4 for guile-devel@gnu.org; Wed, 10 Apr 2013 19:07:47 -0400 Original-Received: from zhhdzmsp-smta18.bluewin.ch ([195.186.227.133]:52793) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQ47G-0003jt-Jm for guile-devel@gnu.org; Wed, 10 Apr 2013 19:07:46 -0400 Original-Received: from [195.186.99.130] ([195.186.99.130:43687] helo=zhbdzmsp-smta11.bluewin.ch) by zhhdzmsp-smta18.bluewin.ch (envelope-from ) (ecelerity 2.2.3.47 r(39824M)) with ESMTP id ED/2E-19106-EB0F5615; Wed, 10 Apr 2013 23:07:43 +0000 Original-Received: from [10.0.1.10] (83.79.31.165) by zhbdzmsp-smta11.bluewin.ch (8.5.142) (authenticated as dll@bluewin.ch) id 510085AB06DC87E4 for guile-devel@gnu.org; Wed, 10 Apr 2013 23:07:42 +0000 X-Mailer: Apple Mail (2.1085) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 195.186.227.133 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16216 Archived-At: 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 =3D> #1f64@1(0.0 0.0) so far so good. (uniform-vector? a) =3D> #t (f64vector-ref? a) =3D> #t so far so good. (uniform-vector-ref a 0) =3D> 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 =3D 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 =3D h.base + (idx - h.dims[0].lnbd) * h.dims[0].inc Cf. (vector-ref #@1(1 2 3 4) 1) =3D> 2 (wrong) but (array-ref #@1(1 2 3 4) 1) =3D> 1 (right) I have patches for the above; however, the problems go well beyond. (bitvector? (make-typed-array 'b #t 2))) =3D> #t (bitvector? (make-typed-array 'b #t '(1 2))) =3D> #f (bitvector-ref (make-typed-array 'b #t '(1 2))) =3D> type error = (consistent with #f) (bytevector? (make-typed-array 's8 0 2))) =3D> #t (bytevector? (make-typed-array 's8 0 '(1 2))) =3D> #f (bytevector-ref (make-typed-array 's8 0 '(1 2))) =3D> type error = (consistent with #f) (s8vector? (make-typed-array 's8 0 2))) =3D> #t (s8vector? (make-typed-array 's8 0 '(1 2))) =3D> #t (s8vector-ref (make-typed-array 's8 0 '(1 2))) =3D> type error = (inconsistent with #t) (uniform-vector? (make-typed-array 's8 0 2))) =3D> #t (uniform-vector? (make-typed-array 's8 0 '(1 2))) =3D> #t (uniform-vector-ref (make-typed-array 's8 0 '(1 2))) =3D> 0 (consistent = with #t, but wrong) (vector? (make-typed-array #t 0 2))) =3D> #t (vector? (make-typed-array #t 0 '(1 2))) =3D> #f (vector-ref (make-typed-array #t 0 '(1 2)) 0) =3D> 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=3D0 and inc=3D1. 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.=20 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!=3D1 = and base!=3D0 for non-array objects. This will push some of the array = functionality into bitvector, bytevector, etc (where inc=3D1 and base=3D0 = 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).