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, 28 Feb 2013 22:46:08 -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> <441E015F-F545-48DF-AF96-E1FEA64F64A3@bluewin.ch> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8fb2088cf7502504d6d4d883 X-Trace: ger.gmane.org 1362109583 17357 80.91.229.3 (1 Mar 2013 03:46:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Mar 2013 03:46:23 +0000 (UTC) Cc: Andy Wingo , guile-devel , Daniel Llorens To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Mar 01 04:46:46 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 1UBGvl-0007YZ-I7 for guile-devel@m.gmane.org; Fri, 01 Mar 2013 04:46:45 +0100 Original-Received: from localhost ([::1]:38340 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBGvQ-0002AI-Aq for guile-devel@m.gmane.org; Thu, 28 Feb 2013 22:46:24 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:55467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBGvE-00029z-7l for guile-devel@gnu.org; Thu, 28 Feb 2013 22:46:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UBGvB-00044t-JA for guile-devel@gnu.org; Thu, 28 Feb 2013 22:46:12 -0500 Original-Received: from mail-pb0-f43.google.com ([209.85.160.43]:46972) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBGvB-00044U-50 for guile-devel@gnu.org; Thu, 28 Feb 2013 22:46:09 -0500 Original-Received: by mail-pb0-f43.google.com with SMTP id md12so1482432pbc.30 for ; Thu, 28 Feb 2013 19:46:08 -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=rxLCtzBvLFk7aT3vKbpI+OW6flWmd1qw8nobNqCWvpo=; b=yBhu7GtnVmq375eB9JZucwAkw4e461goZgRJ4Kcm1Tm94Cs9lxVB25C0sFSMRI97o2 B8mXSSRrr6MW0mk7IHDzukBRqddQUa0h4DpGnYQ01DOepqGVILozdjHCCpnWT63jCPL7 +iNQByrTdxkjqayJCZDV7WRX5TFmP2KjAxiveiJ0Pvm7kAo5Dio8cbYjGaZEcI7W635m 388jI1HOvObA+gTeFNd7s0MZGcP7aP2i7wOfTojgnH2lT+egF/+5T4cH8yTUbzIx4vlN 9nuAdUPbs00SHFyCNKLkwc8TCmfM0b2xM2OjZ97VLlcuBVpBHiwkLD+e5XQ0BfKUefcd NHVw== X-Received: by 10.68.191.106 with SMTP id gx10mr12762520pbc.151.1362109568337; Thu, 28 Feb 2013 19:46:08 -0800 (PST) Original-Received: by 10.68.157.42 with HTTP; Thu, 28 Feb 2013 19:46:08 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: dLr2eNWv6VshAsI6La_qK9dk7A0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.160.43 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:15846 Archived-At: --e89a8fb2088cf7502504d6d4d883 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable After reading through my email, I realize that I left out the most important part - a reason *why* functions shouldn't map over arrays. My reason is that this makes function application a more complicated process. Right now, functions are very simple things in Scheme. If we add automatic mapping behavior, the mental model becomes more complicated. It seems cleaner to leave this in a module that users could load or not as they choose. However, I realize that this argument isn't very persuasive. I am open to other reasons to make this work. Best, Noah On Thu, Feb 28, 2013 at 9:42 PM, Noah Lavine wrote= : > Hello, > > > On Thu, Feb 28, 2013 at 2:10 PM, Daniel Llorens > wrote: > >> >> On Feb 22, 2013, at 01:22, Noah Lavine wrote: >> >> > 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. >> >> That's on Scheme, but there are also many optimization issues related to >> array operations. Temporaries, order of traversal, etc. >> > > Yes, you're right. This will be a long-term project. > > >> > 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 automat= ic >> de-ranking, you have to have Guile assume which dimensions you want to m= ap >> 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. >> >> enclosed-array also let you pick what axes you wanted for the cell. You >> needed to specify those axes every time. That feels /more/ low level to = me. >> >> The memory order of arrays in Guile is absolutely low level detail, >> especially since it can change at any time. However the =BFlogical? orde= r of >> the axes is not. It's simpler to define the looping operation so that th= e >> frame (the axes one loops over) consists of the axes that come first. It >> plays well with the rank extension / matching mechanism that I show at t= he >> end and with the view of an array as a list. >> > > Yes, I think you've persuaded me that there is a "natural" order to axes. > There should still be an operator that splits in other ways, but I agree > that we can shortcut that in many cases. > > >> > This gets at the heart of my issue with the array functionality. As fa= r >> 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 mappin= g >> 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 Th= at >> might be interesting, but I'm skeptical. >> >> Exactly, this is what is needed. Then you can write array functions that >> can be extended for arguments of higher rank without the function itself >> having to deal with those extra axes that are none of its concern. >> Otherwise you need to give axis indications left and right. I've suffere= d >> this in numpy. This information belongs with the function. >> > > (I'll reply to this below) > > >> > 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 i= t. >> >> It's a problem, because one needs at the very least mapping and >> reductions to write any kind of numeric program. Guile has absolutely >> nothing for array reductions and the mapping is very low level. >> > > A slow array reduction is easy enough to add, but I'm guessing that's not > what we need. :-) Perhaps we should have some sort of (ice-9 array) modul= e > where we put useful array functions. > > >> > 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 ov= er >> arrays, so having an array where you expected a value doesn't lead to ne= w >> 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. >> >> In my experience the kind of rank errors you describe are unlikely to >> happen, because in most programs the ranks of arrays are static. > > > That's a good point. I'm still not convinced, because making array-ref do > this means that array-ref can return two fundamentally different types of > results - arrays and other objects. This is very different than most > functions. But I think this comes down to a more fundamental difference -= I > still don't think that functions should automatically map over arrays, an= d > you do. If they did automatically map, then I would agree with you about > array-ref, because then arrays wouldn't be fundamentally different types > from the objects they contained. > > >> It's a bit like function arity, the general case is important and must b= e >> supported, but most functions have fixed arity, and that reveals many >> optimization opportunities. If the rank of an array is known, then the r= ank >> of the array-ref result is also known. The Guile compiler seems to ignor= e >> all of this right now, but it probably shouldn't. >> > > I agree that the compiler should be better, but as one of the people > working on it, there are lots of things that it should do and presently > doesn't. I don't know when we'll get nice array optimizations. > > >> I've implemented the idea of assigning rank to functions and then >> extending these over arrays of higher rank. At this point I'm mostly >> interested in having the basic mechanism right, so the code is probably = a >> bit rough. >> >> I wrote some description of how it works in the README. Please have a >> look and let me know what you think. You can find it at: >> >> https://gitorious.org/guile-ploy >> > > I read through your README. I still haven't looked at the code, but that > looks very cool! I would be excited to have a library like that in Guile = - > but I think that this should be optional, and that not *every* function > should have rank information. This is because while it is fairly natural > for programs that involve a lot of array processing, I don't think it is = as > natural for, for example, networking code or the web server. I really lik= e > the ply function that lets you connect functions with rank information to > functions without it. > > >> I also wanted to write a bit about passing arrays between C/C++ and >> Guile, but it's really a different matter, so maybe some other time. The >> problem here is that each library has its own calling convention and has >> different constraints on the kind of arrays it takes, so it's not someth= ing >> that the ffi can handle transparently. >> > > Yes, that seems like a big issue. > > I definitely agree that we should provide enough primitive operators to > write fast array code in Guile. Your README says that certain functions > can't be implemented efficiently without access to the underlying array > representation - that should certainly change. However, I don't think tha= t > we should make every function have rank information, when it's not really > used in most areas of programming. I think the library you've presented i= s > a great compromise, because it lets you put rank annotations on some > functions, but not all. > > What do you think? > > Best, > Noah > --e89a8fb2088cf7502504d6d4d883 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
After reading through my email, I realize that I= left out the most important part - a reason *why* functions shouldn't = map over arrays.

My reason is that this makes function applica= tion a more complicated process. Right now, functions are very simple thing= s in Scheme. If we add automatic mapping behavior, the mental model becomes= more complicated. It seems cleaner to leave this in a module that users co= uld load or not as they choose.

However, I realize that this argument isn't very persuas= ive. I am open to other reasons to make this work.

Best,<= br>
Noah



On Thu, Feb 28, 2013 at 9:42 PM, Noah Lavine <noah.b.lavine@gmail.com> wrote:
Hello,


On Thu, Feb 28, 2013 at 2:10 PM, Daniel Llo= rens <daniel.llorens@bluewin.ch> wrote:

On Feb 22, 2013, at 01:22, Noah Lavine wrote:

> 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.

That's on Scheme, but there are also many optimization issues rel= ated to array operations. Temporaries, order of traversal, etc.

Yes, you're right. This will = be a long-term project.
=A0
> I'm actually not very enthusiastic about this, not because you sho= uldn'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 array= s are actually stored in memory, so maybe that is the right way. It just se= ems too low-level for me - I'd rather see an array-slice function that = can split along any dimensions.

enclosed-array also let you pick what axes you wanted for the cell. Y= ou needed to specify those axes every time. That feels /more/ low level to = me.

The memory order of arrays in Guile is absolutely low level detail, especia= lly since it can change at any time. However the =BFlogical? order of the a= xes is not. It's simpler to define the looping operation so that the fr= ame (the axes one loops over) consists of the axes that come first. It play= s well with the rank extension / matching mechanism that I show at the end = and with the view of an array as a list.

Yes, I think you've persuaded me= that there is a "natural" order to axes. There should still be a= n operator that splits in other ways, but I agree that we can shortcut that= in many cases.
=A0
> This gets at the heart of my issue with the array functionality. As fa= r 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 proper= ty called 'rank', set it for all of the built-in arithmetic functio= ns, and maybe have some way to infer the rank of new functions That might b= e interesting, but I'm skeptical.

Exactly, this is what is needed. Then you can write array functions t= hat can be extended for arguments of higher rank without the function itsel= f having to deal with those extra axes that are none of its concern. Otherw= ise you need to give axis indications left and right. I've suffered thi= s in numpy. This information belongs with the function.

(I'll reply to this b= elow)
=A0
> 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 mi= ssing yet, though, because I haven't tried to write a program that woul= d use it.

It's a problem, because one needs at the very least mapping and r= eductions to write any kind of numeric program. Guile has absolutely nothin= g for array reductions and the mapping is very low level.

A slow array reduction is easy= enough to add, but I'm guessing that's not what we need. :-) Perha= ps we should have some sort of (ice-9 array) module where we put useful arr= ay functions.
=A0
> I think the idea of splitting arrays is great. My only concern is maki= ng it part of array-ref. I still think that's a really bad idea, becaus= e it introduces a new class of errors that are really easy to make - accide= ntally getting an array when you expected whatever was inside the array. I&= #39;m coming at this as a user of Matlab and Fortran. In those languages, t= his isn't a problem, because operations automatically map over arrays, = so having an array where you expected a value doesn't lead to new error= s. But in Scheme, operations *don't* automatically map, so getting an a= rray could lead to an exception at some point later in a program when reall= y the error was that you didn't give enough indices to array-ref.

In my experience the kind of rank errors you describe are unlikely to= happen, because in most programs the ranks of arrays are static.
=A0
That's a good point. I'm still not conv= inced, because making array-ref do this means that array-ref can return two= fundamentally different types of results - arrays and other objects. This = is very different than most functions. But I think this comes down to a mor= e fundamental difference - I still don't think that functions should au= tomatically map over arrays, and you do. If they did automatically map, the= n I would agree with you about array-ref, because then arrays wouldn't = be fundamentally different types from the objects they contained.
=A0
It'= ;s a bit like function arity, the general case is important and must be sup= ported, but most functions have fixed arity, and that reveals many optimiza= tion opportunities. If the rank of an array is known, then the rank of the = array-ref result is also known. The Guile compiler seems to ignore all of t= his right now, but it probably shouldn't.

I agree that the compiler should be = better, but as one of the people working on it, there are lots of things th= at it should do and presently doesn't. I don't know when we'll = get nice array optimizations.
=A0
I've implemented the idea of assigning rank to functions and then exten= ding these over arrays of higher rank. At this point I'm mostly interes= ted in having the basic mechanism right, so the code is probably a bit roug= h.

I wrote some description of how it works in the README. Please have a look = and let me know what you think. You can find it at:

=A0 =A0 =A0 =A0 https://gitorious.org/guile-ploy

I read through your README. I still haven't looked at the code,= but that looks very cool! I would be excited to have a library like that i= n Guile - but I think that this should be optional, and that not *every* fu= nction should have rank information. This is because while it is fairly nat= ural for programs that involve a lot of array processing, I don't think= it is as natural for, for example, networking code or the web server. I re= ally like the ply function that lets you connect functions with rank inform= ation to functions without it.
=A0
I also wanted to write a bit about passing arrays between C/C++ and Guile, = but it's really a different matter, so maybe some other time. The probl= em here is that each library has its own calling convention and has differe= nt constraints on the kind of arrays it takes, so it's not something th= at the ffi can handle transparently.

Yes, that seems like a big issue.
I definitely agree that we should provide enough primitive = operators to write fast array code in Guile. Your README says that certain = functions can't be implemented efficiently without access to the underl= ying array representation - that should certainly change. However, I don= 9;t think that we should make every function have rank information, when it= 's not really used in most areas of programming. I think the library yo= u've presented is a great compromise, because it lets you put rank anno= tations on some functions, but not all.

What do you think?

Best,
Noa= h

--e89a8fb2088cf7502504d6d4d883--