3 questions about arrays
in [Lisp]
|
From: Spiros Bousbouras on 8 Dec 2009 17:35 On Sun, 06 Dec 2009 03:25:40 -0500 Barry Margolin <barmar(a)alum.mit.edu> wrote: > In article <qWzSm.40801$ic1.37168(a)newsfe16.ams2>, > Spiros Bousbouras <spibou(a)gmail.com> wrote: > > > On Sat, 05 Dec 2009 05:54:30 -0500 > > Barry Margolin <barmar(a)alum.mit.edu> wrote: > > > In article <OylSm.7781$6p6.1940(a)newsfe05.ams2>, > > > Spiros Bousbouras <spibou(a)gmail.com> wrote: > > > > > > > The problem here is that the standard does not allow a Lisp > > > > implementation to do this on the computer I'm using. > > > > > > The standard doesn't prevent Lisp implementations from allowing bignum > > > array indices. It just doesn't require it, so portable applications > > > can't depend on it. > > > > Each array dimension has to be smaller than ARRAY-DIMENSION-LIMIT and > > ARRAY-DIMENSION-LIMIT has to be a fixnum therefore array dimensions > > have to be fixnums. Each array index has to be smaller than the > > corresponding dimension therefore each array index also has to be a > > fixnum. (I'm assuming that if a,b are integers and 0 <= a <= b and b is > > a fixnum then a also has to be a fixnum.) > > All those limits only apply to portable applications. They don't > restrict implementations from allowing larger arrays as extensions, and > non-portable applications can use these larger indices. Well , if you say so I'm sure you're right but it's not obvious to me how it follows from (or is consistent with) the HS. So then the question becomes why have ARRAY-DIMENSION-LIMIT and ARRAY-TOTAL-SIZE-LIMIT at all ? Was it for backwards compatibility ? Actually even before the standard was created , why would an implementation introduce ARRAY-DIMENSION-LIMIT or ARRAY-TOTAL-SIZE-LIMIT ? It seems simpler to me not to have these constants and instead have MAKE-ARRAY and ADJUST-ARRAY return nil if the requested array was too large. -- Who's your mama ?
From: Spiros Bousbouras on 8 Dec 2009 17:38 On 6 Dec 2009 06:23:09 GMT Tamas K Papp <tkpapp(a)gmail.com> wrote: > On Sat, 05 Dec 2009 21:34:52 +0000, Spiros Bousbouras wrote: > > With the open source Lisps, you can define your own answer. Define my own answer ? What does that mean ? > > And that's the problem. I'm asking for fast fixnums plus arrays as large > > as the system can support plus standard conformance. I don't think > > that's a lot to ask for but I can't get it. > > You mean you don't have internet access to download 64 bit SBCL? Does the 64 bit SBCL run on a 32 bit computer ? If it does does it provide the fastest fixnums for the architecture ?
From: Kaz Kylheku on 8 Dec 2009 17:43 On 2009-12-08, Spiros Bousbouras <spibou(a)gmail.com> wrote: >> All those limits only apply to portable applications. They don't >> restrict implementations from allowing larger arrays as extensions, and >> non-portable applications can use these larger indices. > > Well , if you say so I'm sure you're right but it's not obvious to me > how it follows from (or is consistent with) the HS. So then the > question becomes why have ARRAY-DIMENSION-LIMIT and > ARRAY-TOTAL-SIZE-LIMIT at all ? It's so that standard-conforming programs can be written which check and obey these limits. Moreover, there are minimum values on these limits so that you can write conforming programs that use small arrays without bothering with these checks.
From: Spiros Bousbouras on 8 Dec 2009 18:12 On Sun, 6 Dec 2009 15:08:27 +0000 (UTC) Kaz Kylheku <kkylheku(a)gmail.com> wrote: > On 2009-12-05, Spiros Bousbouras <spibou(a)gmail.com> wrote: > > No it's not necessarily a failure of the implementation because an > > implementation is also responsible for assuring that the fixnums it > > provides are as fast as possible for the the architecture on which the > > implementation is running. So for example if an implementation is > > running on a 32-bit computer then fixnums likely have to ([1]) be at > > most 32 bits. So there are at most 31 bits to represent positive > > numbers. This means that you cannot create an array with more than > > 2**31 elements even if the elements are just bits in which case the > > array would comfortably fit in memory. > > An array of 2**32 elements will also fit comfortably into memory if they > are bits. I'll see your 2**32 elements and raise you to 2**33 elements. > A computer with 32 bit addresses which reference bytes is not capable > of addressing every bit of every byte in its address space. What do you mean addressing ? Who said anything about addressing ? You seem to be talking about what assembly instructions will be output by the compiler in order to manipulate the array. That's an entirely different issue. If the compiler can allocate the necessary number of bytes then it can manipulate individual bits even if it has to use masks and AND and OR. My concern was with whether the standard allows the programmer to create the array to begin with (plus my other requirements). > Can you name one programming language whose ANSI or ISO standard > requires implementations to overcome this issue in their implementation > of bit arrays? I'm afraid I don't understand what issue you have in mind. -- If at first you don't succeed, well, so much for skydiving. Victor O'Reilly
From: Kaz Kylheku on 8 Dec 2009 18:43
On 2009-12-08, Spiros Bousbouras <spibou(a)gmail.com> wrote: > On Wed, 09 Dec 2009 00:15:15 +0100 > pjb(a)informatimago.com (Pascal J. Bourguignon) wrote: >> >> Yes, that's because the CLHS is written avoiding as much as possible >> redundancy. If it is written at one place that there is a limit on >> the size of arrays, then it is not repeated at another place that you >> shouldn't try to allocate bigger arrays. > > But where does it say whose responsibility it is to enforce the size > restriction ? Nowhere. So that means that the behavior is undefined. Similarly, whose responsibility is to enforce that literal lists can't be modified? Requesting a larger array than array-dimension-limit or array-total-size-limit is simply outside of the scope of the ANSI Common Lisp standard. Implementations can diagnose such an attempt with an error signal, honor the attempt, if possible, or just behave unpredictably: allow the program to become corrupted and produce incorrect results, or the entire Lisp image to crash, with or without some error diagnostic, etc. Ensuring that some of these really bad things don't happen is a quality of implementation issue, as is the provision of huge arrays that can be indexed by bignums. |