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: Fri, 1 Mar 2013 10:01:40 +0100 Message-ID: <14C63C7B-DEA6-4C0C-AB18-17695BC5FAD3@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> <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 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1362128568 2918 80.91.229.3 (1 Mar 2013 09:02:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Mar 2013 09:02:48 +0000 (UTC) Cc: Andy Wingo , guile-devel To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Mar 01 10:03:11 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 1UBLrx-0006en-Jj for guile-devel@m.gmane.org; Fri, 01 Mar 2013 10:03:09 +0100 Original-Received: from localhost ([::1]:49938 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBLrc-0007H2-G5 for guile-devel@m.gmane.org; Fri, 01 Mar 2013 04:02:48 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:43828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBLqi-0005Py-8k for guile-devel@gnu.org; Fri, 01 Mar 2013 04:01:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UBLqc-0003G7-Bc for guile-devel@gnu.org; Fri, 01 Mar 2013 04:01:52 -0500 Original-Received: from zhhdzmsp-smta18.bluewin.ch ([195.186.227.133]:59231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBLqa-0003FY-PF for guile-devel@gnu.org; Fri, 01 Mar 2013 04:01:45 -0500 Original-Received: from [195.186.99.130] ([195.186.99.130:44810] helo=zhbdzmsp-smta11.bluewin.ch) by zhhdzmsp-smta18.bluewin.ch (envelope-from ) (ecelerity 2.2.3.47 r(39824M)) with ESMTP id CB/F9-12532-57E60315; Fri, 01 Mar 2013 09:01:42 +0000 Original-Received: from [10.0.1.10] (83.78.38.148) by zhbdzmsp-smta11.bluewin.ch (8.5.142) (authenticated as dll@bluewin.ch) id 510085AB0332900D; Fri, 1 Mar 2013 09:01:41 +0000 In-Reply-To: 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:15848 Archived-At: On Mar 1, 2013, at 03:42, Noah Lavine wrote: > There should still be an operator that splits in other ways, but I = agree that we can shortcut that in many cases. One think I like about the frame / cell split is that you know that the = result will have the same frame. So I imagine an operator (do-with-frame array-op (arg0 2 1) (arg1 ...) ...) that transposes 2 1 to 0 1 before the array op, and when the array op = is done you know that the output shape will be 2 1 ... axes of the = output cell ... However you still can't transpose the frame back = without knowing what the array op did to the cell. There're specific = types of operations where this works because the frame would be gone = (reductions, or any time the output rank is 0) or it would be unaffected = (rank 1 to rank 1 operations, like 'shuffle this axis'), but not in = general. That's one reason why the axes specification is ad hoc in those = other languages. If array functions know their ranks, we could make this = work automatically often enough, but sometimes you'd still have to say = 'I don't know how to do that'. > 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) = module where we put useful array functions. That's a good idea. I have my own slow reduction and I imagine that the = expedient vector->list / array->list and back is done way too often. > think this comes down to a more fundamental difference - I still don't = think that functions should automatically map over arrays, and 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. I actually agree here! I don't want regular scheme functions to have = things done to them around their back, it would be another language. I = can accept why you want array-ref to be strict. Indeed my approach tends = to a confusion between a 2-array of 2-arrays and a 4-array. In = guile-ploy you can see this in collapse-array ---if the verb doesn't = provide an output shape, I make an assumption. I also banish 0-rank = arrays. The idea is to make special array-functions to get the array behavior. = Like ufuncs in NumPy. > 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. Guile has gotten a lot better recently. I wish I had a clue about = compilers though. > 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 totally agree with this. > I really like the ply function that lets you connect functions with = rank information to functions without it. My idea was to define +., -., etc. as array versions of +, -, and so on. = Then when the library was mature enough, (+. ...) would be transformed = into (ply +. ...). However I've fallen into the vice of doing things on = the spot, like (ply (make-verb + ...) ...). There's a lot of this in the = test script. > 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. I've thought about what could be provided on the Scheme side. The = problem is that if you give strides / lbnd / ubnd directly, you still = need to create a bunch of lists for any slicing, although maybe not as = many as with make-shared-array. This is worse for ops that are going to = be used inside loops a lot, like array-ref. The recent scm_c_array_ref_1 = functions help, but it's just a specific case. All array operations are = in C, maybe that's why they are opaque? I mean scheme@(guile-user)> ,optimize (vector-ref #(1 2 3) 0) $1 =3D 1 scheme@(guile-user)> ,optimize (array-ref #(1 2 3) 0) $2 =3D (array-ref '#(1 2 3) 0) > However, I don'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 you've presented is a great compromise, because it = lets you put rank annotations on some functions, but not all. >=20 > What do you think? Agreed, I'm sorry I wasn't clear in the other messages. This array = extension should be a library. What I'd like from Guile is the = facilities to allow it to be efficient. Best regards, =09 Daniel