Re: consider exclusive index ranges Aubrey Jaffer (29 Nov 2003 19:18 UTC)
|
Re: consider exclusive index ranges
Per Bothner
(29 Nov 2003 19:58 UTC)
|
Re: consider exclusive index ranges Aubrey Jaffer 29 Nov 2003 19:18 UTC
| * To: srfi-47@srfi.schemers.org | * Subject: consider exclusive index ranges | * From: Ray Blaak <xxxxxx@ensemble-systems.com> | * Date: Thu, 13 Nov 2003 10:06:41 -0800 | * Delivered-to: srfi-47@srfi.schemers.org | | Title: consider exclusive index ranges | | > One more comment: Why specify bounds as two-element lists rather than as | > pairs? It seems a bit strange to allocate two cons cells when the data | > is known to always contain exactly two values. Is there some reason why | > (make-array '#(foo) '(0 2) '(0 2)) | > is preferable to | > (make-array '#(foo) '(0 . 2) '(0 . 2)) | | Allow both. Typing (0 . 2) all the time is more tedious. (0 2) is | just as easy to read (easier in fact, I think) and easier for the | programmer to write. Yes; and in a proportional font, ( 0 . 2 ) starts looking like a fractional index. | My point is to consider the use of exclusive ranges instead of | inclusive ones. My instinct is that things like array slicing and | subsetting will compose better using exclusive ranges. We are discussing half-exclusive ranges; 0 is a valid index. | Consider exclusive: | | (let* ((n ...) | (mid (/ n 2)) | (a (make-array default (list 0 n))) | (first-half (array-slice arr (list 0 mid))) | (second-half (array-slice arr (list mid n))))) | | versus inclusive: | | (let* ((n ...) | (mid (/ n 2)) | (a (make-array default (list 0 (- n 1)))) | (first-half (array-slice arr (list 0 (- mid 1)))) | (second-half (array-slice arr (list mid (- n 1)))))) You have convinced me that half-exclusive ranges look like the better choice. I have written some code just like your inclusive example. How deeply ingrained are inclusive array bounds? Looking through my code-base I find two uses of non-0-based arrays. In SIMSYNCH they are used to provided a couple convenient storage locations associated with an array. And my sequence-comparison code in SLIB does because the algorithm was originally expressed using negative indexes for one of its arrays. A couple hours of work can rectify these. But why provide non-0-based indexes at all? The representations for ranges in both SRFI-47 and SRFI-25 are ad-hoc and un-schemely. Non-0-based array indexes also torpedo write/read invariance unless the external representation includes the shape (instead of just the rank). None of the syntaxes discussed so far do this. So I have removed pair bounds and ARRAY-SHAPE from SRFI-47. http://swissnet.ai.mit.edu/~jaffer/srfi-47 has the latest until the editor updates http://srfi.schemers.org/srfi-47/srfi-47.html.