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: vectors are something else Date: Tue, 16 Apr 2013 10:31:27 +0200 Message-ID: <6802138D-98E4-4C12-8D48-990325705EDF@bluewin.ch> References: <9D053760-46BC-46F1-B84D-07902E777FF2@bluewin.ch> <87haj72q08.fsf@tines.lan> <9282A433-1C3C-4D65-BDCB-9824F9227815@bluewin.ch> <877gk32e13.fsf@tines.lan> 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 1366101094 13900 80.91.229.3 (16 Apr 2013 08:31:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Apr 2013 08:31:34 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Apr 16 10:31:38 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 1US1Ig-0004DR-Dv for guile-devel@m.gmane.org; Tue, 16 Apr 2013 10:31:38 +0200 Original-Received: from localhost ([::1]:56621 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1US1If-0008JB-U2 for guile-devel@m.gmane.org; Tue, 16 Apr 2013 04:31:37 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1US1Ia-0008DL-Qc for guile-devel@gnu.org; Tue, 16 Apr 2013 04:31:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1US1IZ-0006sm-Ca for guile-devel@gnu.org; Tue, 16 Apr 2013 04:31:32 -0400 Original-Received: from zhbdzmsp-smta15.bluewin.ch ([195.186.99.132]:59585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1US1IZ-0006sJ-6e for guile-devel@gnu.org; Tue, 16 Apr 2013 04:31:31 -0400 Original-Received: from [195.186.227.130] ([195.186.227.130:54344] helo=zhhdzmsp-smta12.bluewin.ch) by zhbdzmsp-smta15.bluewin.ch (envelope-from ) (ecelerity 2.2.3.47 r(39824M)) with ESMTP id E6/58-29501-06C0D615; Tue, 16 Apr 2013 08:31:29 +0000 Original-Received: from [10.0.1.10] (81.62.254.89) by zhhdzmsp-smta12.bluewin.ch (8.5.142) (authenticated as dll@bluewin.ch) id 510085B007262420; Tue, 16 Apr 2013 08:31:28 +0000 In-Reply-To: <877gk32e13.fsf@tines.lan> 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.99.132 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:16260 Archived-At: On Apr 16, 2013, at 08:19, Mark H Weaver wrote: > Yes, I did, and generally I strongly prefer column [1], but we have to > be very careful what changes we make in a stable release series that > might break compatibility with existing code. I find this frustrating > as well, which is one reason why I agree with Andy that shifting focus > to 2.2 soon would be a good idea. All right. > I think you misunderstood me. I'm not talking about the cost of the > 'make-shared-array' call itself. I'm talking about the fact that in > order to support arrays that might have been created using > 'make-shared-array', things like 'array-ref' must apply an arbitrary > affine transformation to the indices in order to compute the offset = into > the linear storage. Sorry if it sounded that way; the specific mention of make-shared-array = puzzled me. There are, after all, other functions that imply such a = transformation, e.g. transpose-array. > assume anything about what kind of array is passed in. Such an array > might have been created by 'make-shared-array', and thus might use an > arbitrary affine transformation. If 'vector-ref' can be used on such = an > array, then this procedure would have to fetch the stride and offset = and > do the multiplication each time. If there's a loop that calls this > top-level procedure, then the compiler can't do anything with this. Since vector-ref takes a single index, 'arbitrary affine transformation' = is b+d*i, all three scalars. In a context where the compiler can't do = any meaningful optimization, is this going to matter? At any rate, I accept your point that the indexing cannot be optimized = out in general. > This is a weak argument. You can always make shorter names for them. I wasn't serious. > I don't think that arrays should ever be printed as #(2 4). The obvious alternative is #1(2 4). As of now, these are 100% = equivalent.