From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hartwig Newsgroups: gmane.lisp.guile.devel Subject: Re: propose deprecation of generalized-vector-* Date: Tue, 19 Feb 2013 07:57:52 +0800 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> <1361204702.74716.YahooMailNeo@web120402.mail.ne1.yahoo.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1361238554 31827 80.91.229.3 (19 Feb 2013 01:49:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Feb 2013 01:49:14 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Feb 19 02:49:36 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 1U7cKn-00069D-7j for guile-devel@m.gmane.org; Tue, 19 Feb 2013 02:49:29 +0100 Original-Received: from localhost ([::1]:48478 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7cKS-0001hb-UD for guile-devel@m.gmane.org; Mon, 18 Feb 2013 20:49:08 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:39354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7cKQ-0001gW-DS for guile-devel@gnu.org; Mon, 18 Feb 2013 20:49:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7cKP-0004hz-7X for guile-devel@gnu.org; Mon, 18 Feb 2013 20:49:06 -0500 Original-Received: from mail-ie0-x22e.google.com ([2607:f8b0:4001:c03::22e]:58203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7cD3-0002hI-6L for guile-devel@gnu.org; Mon, 18 Feb 2013 20:41:29 -0500 Original-Received: by mail-ie0-f174.google.com with SMTP id k10so7811140iea.19 for ; Mon, 18 Feb 2013 17:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=WCzm5qrKxy/mDrbIg8Oxce6GAwgR84y2gmN98Bb09Co=; b=ZYWfjfCXHoRxoub8ccebPlLB8ruWBasateFcGpf8lTCBUOo1t2vmipVa97PAcbG6wF o9hk7w2zFhul5AGU/D1IeLvSYfpIb4Ynyfz7t6+xDT0GPGlIZeYYgPMQjGdB+PJEdq7s Lrl/gYuE90lxrDqGxv5uz05JpYl6u7TBD2mX7/okUNVuN6N7nouyECJdGXsCUEizPzIT 4MmJ8MqvoyT+0ZCHwtLjKos5+ruN9ubMfa1fOcnXAlrzy/kCoLb5yiFEJRpj3Gh1PetN qJlJKQ51o9NAx63S8yOQG+2vDdR3QZqcargicXHUGcJjQ+It1pjzxPoHZ8DB33qct+pn 0vdA== X-Received: by 10.50.40.131 with SMTP id x3mr8381973igk.10.1361231872367; Mon, 18 Feb 2013 15:57:52 -0800 (PST) Original-Received: by 10.64.76.51 with HTTP; Mon, 18 Feb 2013 15:57:52 -0800 (PST) In-Reply-To: <1361204702.74716.YahooMailNeo@web120402.mail.ne1.yahoo.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22e 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:15773 Archived-At: On 19 February 2013 00:25, Mike Gran wrote: > From: Noah Lavine >>Hello, >>>On Wed 23 Jan 2013 13:20, Daniel Llorens wri= tes: >>> >>>> In [2]: a =3D np.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 th= e >>>> 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. >>> >>>It could make sense, yes. What do others think? What happens for >>>array-set!? Care to propose a patch? >> >> >> I haven't worked with the array functionality, so I might be missing >> something, but I don't see why this is natural for array-ref. Right, these are my sentiments also (including the snipped part). Relaxing array-ref in the proposed way means it could hide programming errors, etc. Particularly with typed arrays, where previously the result will reliably be of the given type. > > One could imagine a Matlab-like syntax where array-ref has to have > the same number of indices as the underlying array, but, if an > index were replaced with a symbol, it would return a slice. > > if np is [[1, 2, 3], [4, 5, 6], [7, 8, 9]] > (array-ref np 1 1) -> 5 > (array-ref np 1 :) -> [4, 5, 6] > (array-ref np : 1) -> [[2], [5], [8]] > > Or maybe that's already in Scheme. I'll admit I've never done matrices > in scheme. Yes, but please lets imagine this only and not multiply the purpose of array-ref. Other languages do that kind of thing a lot with a sort of =E2=80=9Cguess what I really meant to do and do that instead=E2=80=9D, whic= h leads to messy documentation, programming errors, and security issues (Ruby-on-Rails?). This is certainly a common enough usage of make-shared-array to justify its own procedure with more helpful syntax. Even I would make this two procedures, array-slice and array-slice/shared, to decide between new or shared array. Regards