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: Re: propose deprecation of generalized-vector-* Date: Wed, 23 Jan 2013 13:20:43 +0100 Message-ID: <2D31D517-08F8-4D07-84DB-098E335AE0AD@bluewin.ch> References: <0F432FA1-CFF8-4A22-A477-5291A1B9925D@bluewin.ch> <87ip9mgzp4.fsf@gnu.org> <878v7m5xdh.fsf@pobox.com> <2E5FFE0D-9001-409C-BCD4-9EE3BF9883F0@bluewin.ch> <87mww0nu8l.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1358943665 31525 80.91.229.3 (23 Jan 2013 12:21:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Jan 2013 12:21:05 +0000 (UTC) Cc: ludo@gnu.org, guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jan 23 13:21:24 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 1TxzKP-00086L-7l for guile-devel@m.gmane.org; Wed, 23 Jan 2013 13:21:17 +0100 Original-Received: from localhost ([::1]:37740 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxzK8-0001c6-1C for guile-devel@m.gmane.org; Wed, 23 Jan 2013 07:21:00 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxzK2-0001ba-MP for guile-devel@gnu.org; Wed, 23 Jan 2013 07:20:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TxzK1-0007u0-EO for guile-devel@gnu.org; Wed, 23 Jan 2013 07:20:54 -0500 Original-Received: from zhhdzmsp-smta18.bluewin.ch ([195.186.227.133]:50197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxzJz-0007td-5k; Wed, 23 Jan 2013 07:20:51 -0500 Original-Received: from [195.186.99.130] ([195.186.99.130:60959] helo=zhbdzmsp-smta11.bluewin.ch) by zhhdzmsp-smta18.bluewin.ch (envelope-from ) (ecelerity 2.2.3.47 r(39824M)) with ESMTP id 95/1E-27475-C95DFF05; Wed, 23 Jan 2013 12:20:48 +0000 Original-Received: from [10.23.3.35] (128.179.67.121) by zhbdzmsp-smta11.bluewin.ch (8.5.142) (authenticated as dll@bluewin.ch) id 4F50AE981C22B1BA; Wed, 23 Jan 2013 12:20:44 +0000 In-Reply-To: <87mww0nu8l.fsf@pobox.com> 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:15561 Archived-At: On Jan 23, 2013, at 10:06, Andy Wingo wrote: > For C, that makes sense. Something should be done for Scheme as well, > but it's not terribly urgent. Perhaps make scm_array_ref not be bound > to "array-ref", and instead bind "array-ref" to some function that = takes > two optional arguments and a rest argument. A poor man's = case-lambda... Just saying=85 I have written a general rectangular selector for arrays as in APL. It depends on having a prefix-selection operator. Here's an example from = numpy: In [1]: import numpy as np In [2]: a =3D np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) In [3]: a Out[3]: array([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) In [4]: a[1] Out[4]: array([4, 5, 6]) In [5]: a[1, 1] Out[5]: 5 array-ref can be extended very simply to do that. It accumulates on the = position as it is done now, but if the index list comes up short it = makes a shared array with the remaining axes instead of giving a rank = error. So it shouldn't be any slower than array_ref. This cannot be done properly from user code with current Guile because = scm_i_make_array() and friends are internal. The only option is = make-shared-array. Now, this is a nice interface for general slicing, = but it requires creating a closure that is only going to be used rank+1 = times, plus a bunch of lists. Let's say that I want to iterate through = the rows of a [100000 x 3] array. Moving from row to row is = fundamentally just moving a pointer. make-shared-array is not a = practical way to do it. The extension of array-ref below isn't a real fix for this use case, = because we're still creating a array descriptor for each iteration. But = it's way faster than make-shared-array and it is a natural extension. = I'm proposing a patch for this. The only wart is what happens with arrays of rank 0. The function below = doesn't return views of rank 0, but the element instead, just as = array-ref does. The only advantage of returning a rank 0 view is that = one could in principle modify the array through it, but they are a pain = to deal with otherwise. My =91solution=92 is to treat the result of = array-ref as read-only. In APL/J there's no difference between an array of rank 0 and a scalar, = so this problem doesn't exist. We may have a similar extension to = (array-set! array obj . idxlist) where obj is an array of rank = (rank(obj)-length(idxlist)) but an element if this gives 0. This would = be just a wrapper over array-copy(array-ref) or the current array-set!. Otherwise I think it should be possible to manipulate SCM_I_ARRAY_DIMS = directly, at least from C. Unless there is a way already and I didn't = realize, that would be great. // Generalization of array-ref where the number of indices may be = smaller than the rank of a. SCM from_(SCM a, SCM i_) { SCM i =3D i_; scm_t_array_handle ah; scm_array_get_handle(a, &ah); scm_t_array_dim * as =3D scm_array_handle_dims(&ah); int arank =3D scm_array_handle_rank(&ah); int k =3D arank; ssize_t pos =3D 0; for (; k>0 && scm_is_pair(i); --k, ++as, i=3Dscm_cdr(i)) { ssize_t ik =3D scm_to_ssize_t(scm_car(i)); if (iklbnd || ik>as->ubnd) { scm_array_handle_release(&ah); scm_error_scm(scm_from_locale_symbol("out-of-range"), = SCM_BOOL_F, scm_from_locale_string("indices out of = range"), SCM_EOL, i_); } pos +=3D (ik-as->lbnd)*as->inc; } SCM o; if (k>0) { if (k=3D=3Darank) { o =3D a; } else { o =3D scm_i_make_array(k); SCM_I_ARRAY_V(o) =3D SCM_I_ARRAY_V(a); SCM_I_ARRAY_BASE(o) =3D pos + SCM_I_ARRAY_BASE(a); // = since arank>1. scm_t_array_dim * os =3D SCM_I_ARRAY_DIMS(o); for (; k>0; --k, ++as, ++os) { os->ubnd =3D as->ubnd; os->lbnd =3D as->lbnd; os->inc =3D as->inc; } } } else if (scm_is_null(i)) { o =3D scm_array_handle_ref(&ah, pos); // these may be = non-arrays. } else { scm_array_handle_release(&ah); scm_error_scm(scm_from_locale_symbol("out-of-range"), = SCM_BOOL_F, scm_from_locale_string("too many indices"), = SCM_EOL, i_); } scm_array_handle_release(&ah); return o; } > FWIW this is not the case. Vectors hold SCM objects, whereas uniform > vectors hold unpacked machine values. Ok, I think I understand that. Still I don't see where the vref field = for the srfi4 types is set. The conversions seem to be done in = bytevector.c, can you point this out? I've also noticed scheme@(guile-user)> (f64vector-ref #s64(1 2 3) 0) $1 =3D #.# scheme@(guile-user)> (c64vector-ref #f64(1 2 3) 0) $3 =3D 1.0+2.0i (!) Regards Daniel