[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: BIT-ARRAY-FUNCTIONS (version 6)
- To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
- Subject: Issue: BIT-ARRAY-FUNCTIONS (version 6)
- From: Barry Margolin <barmar@Think.COM>
- Date: Wed, 21 Jun 89 16:03 EDT
- Cc: CL-Cleanup@sail.stanford.edu
- In-reply-to: <19890621182512.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 21 Jun 89 14:25 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Mon, 19 Jun 89 18:39 EDT
From: Barry Margolin <barmar@Think.COM>
Date: Mon, 19 Jun 89 13:44 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Mon, 19 Jun 89 13:31 EDT
From: Barry Margolin <barmar@Think.COM>
I'd like to suggest an additional change, which seems to be consistent
with the attitude about use of bit vectors expressed in the proposal.
The BIT and SBIT functions should return 0 if asked to access outside
the bit array. This would maintain the tautology
(bit (bit-XXX v1 v2) n) == (logXXX (bit v1 n) (bit v2 n))
If slowing down these functions (they'd be the only array accessors
REQUIRED to check the dimensions) is considered unacceptable, then a new
accessor should be added.
I don't like this idea.
Could you elaborate? Why is it that you like the idea of assuming 0
elements on the end when combining bit vectors, but not when accessing
them? Either you think of them as being infinitely padded with zeros,
or you don't.
I disagree with the last sentence. I don't think the BIT function is in
the same category as the BIT-AND function, I think of it as being at a
different conceptual level.
That was why I suggested the possibility of inventing a new function for
this purpose (although the reason I gave wasn't complete).
I just can't think of a good name that would make it obvious that one is
just a pre-optimized bit array accessor and the other is for accessing
conceptually infinite bit vectors (or bit arrays, if the other part of
the proposal passes).
barmar