From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: propose deprecation of generalized-vector-* Date: Thu, 21 Feb 2013 19:22:52 -0500 Message-ID: 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> <2D31D517-08F8-4D07-84DB-098E335AE0AD@bluewin.ch> <874nh9boqe.fsf@pobox.com> <96617E9F-D83C-48EE-B84D-7CD45C4181C2@bluewin.ch> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b111d8f30426d04d6453188 X-Trace: ger.gmane.org 1361492581 8179 80.91.229.3 (22 Feb 2013 00:23:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Feb 2013 00:23:01 +0000 (UTC) Cc: Andy Wingo , guile-devel To: Daniel Llorens Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Feb 22 01:23: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 1U8gQ5-0003Ue-Bp for guile-devel@m.gmane.org; Fri, 22 Feb 2013 01:23:21 +0100 Original-Received: from localhost ([::1]:59428 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8gPk-0002kc-T8 for guile-devel@m.gmane.org; Thu, 21 Feb 2013 19:23:00 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8gPh-0002kV-NH for guile-devel@gnu.org; Thu, 21 Feb 2013 19:23:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U8gPe-0006uD-Vi for guile-devel@gnu.org; Thu, 21 Feb 2013 19:22:57 -0500 Original-Received: from mail-da0-f50.google.com ([209.85.210.50]:60593) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8gPe-0006tz-Kb for guile-devel@gnu.org; Thu, 21 Feb 2013 19:22:54 -0500 Original-Received: by mail-da0-f50.google.com with SMTP id h15so55943dan.37 for ; Thu, 21 Feb 2013 16:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=D23GGewF7cZPyu6L5BmpOMjUBZEo5bgo5nF7zyF07KM=; b=LcdaR59ToUPe+3kvrAv2ZNrZbJkcvZze6TH25b5hJSHMl92xEoGlxLxPYOefM3rECV UPZWc6jLtpqAJgQRuzr2v6Rppzi6Ut11Q7CaUq0RBFN5pTnpDLIFaD82ImtDKFmUmSi7 4o+a8dR+7ZD+m6qLL4agkEe2g60bYHi3aOka5oeYk82NgZUo+Uj7Toaa7D3fohjQiN2x yazeo13hrB17SlUEqC+yEk+AaAuuEgh4MK+yw2R+t8t5P7Ar2RKNvYtDrPNqrFopAwkt agkbrPVWFSwzp7eX3mRDEbID0x7qkxblbBL4gBvAIAAXkLg1DyY8HE65hT6Uz7zNN73u Z1sw== X-Received: by 10.66.232.97 with SMTP id tn1mr948376pac.124.1361492573173; Thu, 21 Feb 2013 16:22:53 -0800 (PST) Original-Received: by 10.68.157.42 with HTTP; Thu, 21 Feb 2013 16:22:52 -0800 (PST) In-Reply-To: <96617E9F-D83C-48EE-B84D-7CD45C4181C2@bluewin.ch> X-Google-Sender-Auth: OPFii2JGETr4KjuPrjFmz9BzW9U X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.210.50 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:15794 Archived-At: --047d7b111d8f30426d04d6453188 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, On Wed, Feb 20, 2013 at 8:13 PM, Daniel Llorens wrote: > > On Feb 18, 2013, at 16:55, Andy Wingo wrote: > > > It could make sense, yes. What do others think? What happens for > > array-set!? Care to propose a patch? > > Patch is attached. It looks a bit unwieldy because I am duplicating > scm_array_handle_pos(), and I also had to fix the recent array_ref_1 > optimization, but it shouldn't be slower for the old use. > Thanks for working on this! > ... > > --- > > It was interesting to read the other replies, thank you (plural). It was > disappointing that nobody seems to be using arrays, but not very > surprising. I use them a fair amount, but mostly for interfacing with > C/C++. I do little with them in Guile since 1) the facilities are really > not there or they are inconvenient to use, 2) when I need arrays I need > speed and Guile isn't there either (yet!). > I agree about the speed issue, but I hope it will get better soon. The RTL VM will fix some of it, and native compilation will fix more. > More than getting this patch accepted (as it is or with different functio= n > names), my concern is that what this patch does cannot be done on the use= r > side except through make-shared-array, which is too slow. So I think > there's a good argument that scm_i_make_array(), SCM_I_ARRAY_V(), > SCM_I_ARRAY_BASE() and SCM_I_ARRAY_DIMS() should be published. > > Now some optional motivation: > > In other languages that have arrays, rank-0 arrays are not differentiated > from the scalar inside. This is the right approach if you want to treat > arrays of any rank as values. Then you can say that a rank-n array is > > ------------------- > a rank-n array of rank-0 cells > a rank-(n-1) array of rank-1 cells > ... > a rank-1 array of rank-(n-1) cells > a rank-0 array of rank-n cells =3D a rank-n cell. > > Figure 1. > ------------------- > > The extended versions of array-ref and array-set! allow you to use a > rank-n array as any of these. > I'm actually not very enthusiastic about this, not because you shouldn't be able to do this, but because in order to enable the automatic de-ranking, you have to have Guile assume which dimensions you want to map over. That's how C, C++ and Fortran do it because that's how arrays are actually stored in memory, so maybe that is the right way. It just seems too low-level for me - I'd rather see an array-slice function that can split along any dimensions. > Old Guile used to have something called =91enclosed arrays=92, they are > described in the 1.6 manual. This is a mechanism inspired by APL that > allows one to split an array as in Figure 1, so that if you have a functi= on > that operates on rank-k arrays, you can array-map! it on arrays of any ra= nk > >=3D k. > > Example: > > (define A #((1 2) (3 4) (5 6)) > (define (sqr x) (* x x)) > (define (norm v) (+ (sqr (array-ref v 0)) (sqr (array-ref v 1)))) > (define out #(0 0 0)) > (array-map! out norm (enclosed-array A 1)) > > out =3D> #(5 25 61), hopefully (I don't have Guile 1.6 here to try). > > In later versions of APL (and most obviously in J) people realized that > this is a bad way to go about things, since the reason you want to split = A > in rank-1 cells is =91norm=92. That is, rank-1 is a property of the funct= ion > =91norm=92. And you don't need to do any conversions to iterate over the = rank-1 > cells of A; you only need to move a pointer on each iteration, but to do > this array-map! should be aware of the rank of the procedure in each of i= ts > arguments. > This gets at the heart of my issue with the array functionality. As far as I can tell, in Guile, there is no way to figure out what the rank of a function is. That's why you have to be explicit about what you're mapping over. I suppose the Common Lisp-y approach would be to make an object property called 'rank', set it for all of the built-in arithmetic functions, and maybe have some way to infer the rank of new functions That might be interesting, but I'm skeptical. > ... > > Finally, to fuel the discussion of what kind of array operations Guile > should provide, here is a list similar things that I have read about. I > imagine there are many more. The software is all open source. > > ... > Thanks a lot for starting the conversation. I would like to see Guile provide enough array functionality for serious scientific computing, and it sounds like you want the same thing. I don't really know what's missing yet, though, because I haven't tried to write a program that would use it. I think the idea of splitting arrays is great. My only concern is making it part of array-ref. I still think that's a really bad idea, because it introduces a new class of errors that are really easy to make - accidentally getting an array when you expected whatever was inside the array. I'm coming at this as a user of Matlab and Fortran. In those languages, this isn't a problem, because operations automatically map over arrays, so having an array where you expected a value doesn't lead to new errors. But in Scheme, operations *don't* automatically map, so getting an array could lead to an exception at some point later in a program when really the error was that you didn't give enough indices to array-ref. Other than that, I'm excited about having this. Best, Noah --047d7b111d8f30426d04d6453188 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello,


On Wed, Feb 20, 2013 at 8:13 PM, Daniel Llorens <daniel.= llorens@bluewin.ch> wrote:

On Feb 18, 2013, at 16:55, Andy Wingo wrote:

> It could make sense, yes. =A0What do others think? =A0What happens for=
> array-set!? =A0Care to propose a patch?

Patch is attached. It looks a bit unwieldy because I am duplicating s= cm_array_handle_pos(), and I also had to fix the recent array_ref_1 optimiz= ation, but it shouldn't be slower for the old use.

Thanks for working on this!
=A0
...

---

It was interesting to read the other replies, thank you (plural). It was di= sappointing that nobody seems to be using arrays, but not very surprising. = I use them a fair amount, but mostly for interfacing with C/C++. I do littl= e with them in Guile since 1) the facilities are really not there or they a= re inconvenient to use, 2) when I need arrays I need speed and Guile isn= 9;t there either (yet!).

I agree about the speed issue, but I= hope it will get better soon. The RTL VM will fix some of it, and native c= ompilation will fix more.
=A0
More than getting this patch accepted (as it is or with different function = names), my concern is that what this patch does cannot be done on the user = side except through make-shared-array, which is too slow. So I think there&= #39;s a good argument that scm_i_make_array(), SCM_I_ARRAY_V(), SCM_I_ARRAY= _BASE() and SCM_I_ARRAY_DIMS() should be published.

Now some optional motivation:

In other languages that have arrays, rank-0 arrays are not differentiated f= rom the scalar inside. This is the right approach if you want to treat arra= ys of any rank as values. Then you can say that a rank-n array is

-------------------
a rank-n array of rank-0 cells
a rank-(n-1) array of rank-1 cells
...
a rank-1 array of rank-(n-1) cells
a rank-0 array of rank-n cells =3D a rank-n cell.

Figure 1.
-------------------

The extended versions of array-ref and array-set! allow you to use a rank-n= array as any of these.

I'm a= ctually not very enthusiastic about this, not because you shouldn't be = able to do this, but because in order to enable the automatic de-ranking, y= ou have to have Guile assume which dimensions you want to map over. That= 9;s how C, C++ and Fortran do it because that's how arrays are actually= stored in memory, so maybe that is the right way. It just seems too low-le= vel for me - I'd rather see an array-slice function that can split alon= g any dimensions.
=A0
Old Guile used to have something called =91enclosed arrays=92, they are des= cribed in the 1.6 manual. This is a mechanism inspired by APL that allows o= ne to split an array as in Figure 1, so that if you have a function that op= erates on rank-k arrays, you can array-map! it on arrays of any rank >= =3D k.

Example:

(define A #((1 2) (3 4) (5 6))
(define (sqr x) (* x x))
(define (norm v) (+ (sqr (array-ref v 0)) (sqr (array-ref v 1))))
(define out #(0 0 0))
(array-map! out norm (enclosed-array A 1))

out =3D> #(5 25 61), hopefully (I don't have Guile 1.6 here to try).=

In later versions of APL (and most obviously in J) people realized that thi= s is a bad way to go about things, since the reason you want to split A in = rank-1 cells is =91norm=92. That is, rank-1 is a property of the function = =91norm=92. And you don't need to do any conversions to iterate over th= e rank-1 cells of A; you only need to move a pointer on each iteration, but= to do this array-map! should be aware of the rank of the procedure in each= of its arguments.

This gets at the heart of my issue w= ith the array functionality. As far as I can tell, in Guile, there is no wa= y to figure out what the rank of a function is. That's why you have to = be explicit about what you're mapping over.

I suppose the Common Lisp-y approach would = be to make an object property called 'rank', set it for all of the = built-in arithmetic functions, and maybe have some way to infer the rank of= new functions That might be interesting, but I'm skeptical.
=A0
...

Finally, to fuel the discussion of what kind of array operations Guile shou= ld provide, here is a list similar things that I have read about. I imagine= there are many more. The software is all open source.

...

Thanks a lot for starting= the conversation. I would like to see Guile provide enough array functiona= lity for serious scientific computing, and it sounds like you want the same= thing. I don't really know what's missing yet, though, because I h= aven't tried to write a program that would use it.

I think the idea of splitting arrays is gre= at. My only concern is making it part of array-ref. I still think that'= s a really bad idea, because it introduces a new class of errors that are r= eally easy to make - accidentally getting an array when you expected whatev= er was inside the array. I'm coming at this as a user of Matlab and For= tran. In those languages, this isn't a problem, because operations auto= matically map over arrays, so having an array where you expected a value do= esn't lead to new errors. But in Scheme, operations *don't* automat= ically map, so getting an array could lead to an exception at some point la= ter in a program when really the error was that you didn't give enough = indices to array-ref.

Other than that, I'm excited about havi= ng this.

Best,
Noah

--047d7b111d8f30426d04d6453188--