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: Mon, 15 Apr 2013 16:08:01 +0200 Message-ID: <63795617-219D-4416-98B7-1EC0A7B9BA71@bluewin.ch> References: <9D053760-46BC-46F1-B84D-07902E777FF2@bluewin.ch> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1366034893 22552 80.91.229.3 (15 Apr 2013 14:08:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Apr 2013 14:08:13 +0000 (UTC) Cc: guile-devel@gnu.org To: Daniel Hartwig Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Apr 15 16:08:17 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 1URk4u-0000yF-Vq for guile-devel@m.gmane.org; Mon, 15 Apr 2013 16:08:17 +0200 Original-Received: from localhost ([::1]:43698 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URk4u-0004tH-CL for guile-devel@m.gmane.org; Mon, 15 Apr 2013 10:08:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URk4l-0004lB-JL for guile-devel@gnu.org; Mon, 15 Apr 2013 10:08:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URk4i-0004rT-Qk for guile-devel@gnu.org; Mon, 15 Apr 2013 10:08:07 -0400 Original-Received: from zhhdzmsp-smta18.bluewin.ch ([195.186.227.133]:44668) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URk4i-0004qp-KJ for guile-devel@gnu.org; Mon, 15 Apr 2013 10:08:04 -0400 Original-Received: from [195.186.99.130] ([195.186.99.130:56583] helo=zhbdzmsp-smta11.bluewin.ch) by zhhdzmsp-smta18.bluewin.ch (envelope-from ) (ecelerity 2.2.3.47 r(39824M)) with ESMTP id 6F/CD-19106-2C90C615; Mon, 15 Apr 2013 14:08:03 +0000 Original-Received: from [172.16.96.17] (62.2.203.131) by zhbdzmsp-smta11.bluewin.ch (8.5.142) (authenticated as dll@bluewin.ch) id 510085AB0745C0A0; Mon, 15 Apr 2013 14:08:02 +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:16251 Archived-At: On Apr 15, 2013, at 14:28, Daniel Hartwig wrote: > Though such an array is potentially still a vector according to the = simple > explanation in the manual. So this requires introducing a more > complicated discussion of when is an array a vector. Not really. One just needs to say 'these functions produce vectors. = Everything else doesn't'. > And a lot of the > uses for treating some arrays as vectors will be lost with this, as it > quite restrictive on the layout of the source data. True. One could use arrays though. > Given the semantic complications and lesser utility, it may as well be > that no vectors are arrays and reject all. No disagreement here. > In this case, =91vector?=92 still must answer #f as the offset = indexing > makes the object not a vector. Right? Well... it's really the same argument of 'it is an error'. We can do = whatever. > Most non-vector objects passed to =91vector-ref=92 will throw an = error, > except for offset arrays. Since the result is unspecified aka =93it = is > an error=94, it doesnt have to be correct (ie. include lbnd). Wrong is wrong. Besides, people tend to rely on unspecified behavior. = It's the worst we could do.=20 > Is it > really much faster to do one or the other: >=20 > if lbnd !=3D 0: error > index =3D =85 >=20 > vs: >=20 > index =3D lbnd + ... The second should actually be just index =3D ... You do this by having the base index point to the element at index 0 and = not to the first element. This is a mistake all through the Guile array = code. A branch would certainly be slower. However, if the array implementation = was exposed to the compiler, the lbnd!=3D0 check could be hoisted out of = any array loop. So both would end up being identical in that case. I prefer the second option. But if it comes to you and I having to = agree, I'd be ok with the first. I'm sending a poll to get some more reactions. Regards Daniel