3 questions about arrays
in [Lisp]
|
From: Spiros Bousbouras on 8 Dec 2009 20:39 On Mon, 7 Dec 2009 21:00:37 +0000 (UTC) Kaz Kylheku <kkylheku(a)gmail.com> wrote: > > I think that, barring some fantastically exceptional circumstances, the use of > a 500 megabyte bit array indicates a computer science flunkie between the > keyboard and chair. Are you calling me a computer scientist ?
From: Thomas A. Russ on 8 Dec 2009 20:07 Spiros Bousbouras <spibou(a)gmail.com> writes: > 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 ? I guess it's time for you to upgrade your computer. 64-bit machines are not uncommon anymore, and it seems like you need a larger address space. So it may be time to start saving up for a hardware upgrade. -- Thomas A. Russ, USC/Information Sciences Institute
From: Spiros Bousbouras on 8 Dec 2009 21:10 On 08 Dec 2009 16:50:54 -0800 tar(a)sevak.isi.edu (Thomas A. Russ) wrote: > Spiros Bousbouras <spibou(a)gmail.com> writes: > > > 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. > > Well, let's assume for the sake of argument that these constants didn't > exist and that the specification adopted your suggestion of just > returning NIL if the sizes were too big. > > So, now you write a program and it fails because the array you asked for > is too big and MAKE-ARRAY returns NIL. How do you then find out what > the limit is? Do you then need to write a loop trying successively > bigger values until you happen to locate the implementation limit? You would try smaller values rather than bigger but yes you would write a loop. And you're not interested in the implementation limit , whatever that is , but on whether you can get an array as big as you need to do your job , at the time you ask for it and under the memory usage situation of your programme. > It seems far friendlier to mandate that this information is available, > and much more useful to have it in a form that can be inspected by a > program rather than hidden in the implementation notes in a loose-leaf > binder on my bookshelf. I don't see how it is useful. It's not as if there is any guarantee that as long as your array size is below ARRAY-TOTAL-SIZE-LIMIT and each dimension is below ARRAY-DIMENSION-LIMIT the array will be succesfully created. Every time you create a new Lisp object the possibility exists that you will run out of memory and that garbage collection won't be able to release enough memory. I don't think the standard specifies a way for such an occurrence to be signalled whereas with my method you would have a way which works for array creation (but not for the creation of other objects). Apart from that why is there a need for both ARRAY-DIMENSION-LIMIT and ARRAY-TOTAL-SIZE-LIMIT ? In what situation ARRAY-TOTAL-SIZE-LIMIT on its own wouldn't be enough ? > I wrote a small bit-flags utility that used FIXNUMs to encode small bit > vectors for storing binary option information. One of the items when > defining a new class of such bit-flags was to make sure that the fixnum > range was big enough for the number of flags one wanted to have. This > involved checking the size of MOST-POSITIVE-FIXNUM against the number of > bits required for the particular set of flags. Yes , MOST-POSITIVE-FIXNUM is useful but it's not what I asked about. -- Even real life has plot holes.
From: Barry Margolin on 9 Dec 2009 00:53 In article <wGDTm.34688$Ld7.28734(a)newsfe14.ams2>, Spiros Bousbouras <spibou(a)gmail.com> wrote: > On 08 Dec 2009 16:50:54 -0800 > tar(a)sevak.isi.edu (Thomas A. Russ) wrote: > > Spiros Bousbouras <spibou(a)gmail.com> writes: > > > > > 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. > > > > Well, let's assume for the sake of argument that these constants didn't > > exist and that the specification adopted your suggestion of just > > returning NIL if the sizes were too big. > > > > So, now you write a program and it fails because the array you asked for > > is too big and MAKE-ARRAY returns NIL. How do you then find out what Return NIL? What is this, C? It should signal an error. > > the limit is? Do you then need to write a loop trying successively > > bigger values until you happen to locate the implementation limit? > > You would try smaller values rather than bigger but yes you would write > a loop. And you're not interested in the implementation limit , > whatever that is , but on whether you can get an array as big as you > need to do your job , at the time you ask for it and under the memory > usage situation of your programme. But often you're doing something based on input from the user. It's useful to have these constants so that the program can provide useful feedback. I suppose the limit could be in the error object, rather than a constant. But it seems inappropriate for the error object to contain something not specific to the particular context, but just a general attribute of the implementation. Another thing that makes the constants useful is that the application can check them at the start, and abort immediately with an error like "Sorry, this implementation doesn't support large enough arrays." Isn't this better than running for a while and then aborting when it gets to the point where it needs the large array? -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: Tim Bradshaw on 9 Dec 2009 02:39
On 2009-12-09 01:07:55 +0000, tar(a)sevak.isi.edu (Thomas A. Russ) said: > 64-bit machines are not uncommon anymore, and it seems like you need a > larger address space. So it may be time to start saving up for a > hardware upgrade. I think it's worth looking at what he wrote a couple of articles back: On 2009-12-09 01:30:15 +0000, Spiros Bousbouras <spibou(a)gmail.com> said: > >> BTW, why do you need bit vectors with more than 500 million elements? > > I don't at present. As I've said in a previous post I'm curious i.e. > I'm trying to understand why the standard says what it says. The > mention of bit vectors was for illustration purposes , you could modify > my examples to use something other than bit vectors Or, in other words, he *doesn't actually have a problem he wants to solve*. Watch out for mad people. |