2018-03-06 12:06 GMT-03:00 Henrik Sperre Johansen
:
> Esteban A. Maringolo wrote
> BaseX encode/decode can be simple enough to fit in a small workspace:
>
> base := 58.
> base58Lookup :=
> '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'.
> myNumber := 12345678901234567890.
>
> myStrin
Esteban A. Maringolo wrote
> Hi Richard,
>
> Certainly a BitStream is beyond what I initially thought.
>
> But it could be of some use to play with it, is it available somewhere
> with a friendly open source license?
>
> I might give it a try using it for my generator (tests are already
> passin
+100.
Strings are "dead bits", lacking behaviour specific to what they represent.
Your date example is an excellent portrayal of that. They should never be
used for holding structured data.
Think of strings (dead bits) in much the same way we think of paper (dead
trees).
On Mar 6, 2018 05:46,
Re "Strings are wrong", the influences on my thinking went like this.
(1) As an undergraduate, I did exercises with the Euler compiler
(written in Burroughs Algol) and the XPL compiler (written in XPL).
XPL had immutable strings, rather like AWK or Java, and a PL/I-ish
set of operation
Hi Richard,
Certainly a BitStream is beyond what I initially thought.
But it could be of some use to play with it, is it available somewhere
with a friendly open source license?
I might give it a try using it for my generator (tests are already
passing). Your example is almost complete, but if I
I note that the specification in question does not
deal with arbitrary bit strings but with "entropies"
that are 128 to 256 bits long and a multiple of 32 bits.
4 to 8 bits are copied from the front to the end.
(So selecting *this* bit field can be done by taking
the first byte of a ByteArray.) Th
2018-03-05 14:02 GMT-03:00 Stephane Ducasse :
> On Sun, Mar 4, 2018 at 9:43 PM, Esteban A. Maringolo
> wrote:
>> 2018-03-04 17:15 GMT-03:00 Sven Van Caekenberghe :
>>> Bits are actually numbered from right to left (seen from how they are
>>> printed).
>>
>> I understand bit operations, used it ex
2018-03-05 10:52 GMT-03:00 Richard O'Keefe :
> As I understand it, the OP's problem is that he wants to
> count bits from the high end, and Integers don't *have*
> a finite high end.
Exactly.
I want to work with a block of bits, today the best proxy for that is
using an Integer.
> Smalltalk/X ha
On Mon, Mar 5, 2018 at 2:52 PM, Richard O'Keefe wrote:
> As I understand it, the OP's problem is that he wants to
> count bits from the high end, and Integers don't *have*
> a finite high end.
>
> PL/I has bit strings. Common Lisp has bit strings.
> Some Schemes have copied Lisp. Eiffel _had_
It looks like having BitArray is a good approach.
Is there a MIT compatible version? I could add it to my collection collection :)
Containers I should migrate it to github.
Stef
On Mon, Mar 5, 2018 at 2:52 PM, Richard O'Keefe wrote:
> As I understand it, the OP's problem is that he wants to
> co
On Sun, Mar 4, 2018 at 9:43 PM, Esteban A. Maringolo
wrote:
> 2018-03-04 17:15 GMT-03:00 Sven Van Caekenberghe :
>> Bits are actually numbered from right to left (seen from how they are
>> printed).
>
> I understand bit operations, used it extensively with IP address eons ago.
>
> But if a spec s
As I understand it, the OP's problem is that he wants to
count bits from the high end, and Integers don't *have*
a finite high end.
PL/I has bit strings. Common Lisp has bit strings.
Some Schemes have copied Lisp. Eiffel _had_ bit strings,
more or less, but dropped them.
Smalltalk/X has a BitA
--- Begin Message ---
Just put that in Integer.
bitsSliceFrom: start to: end
"
Extract bits 4 to 6, i.e. 111 which equals to 7
2r1111000 bitsSliceFrom: 4 to: 6
"
| num mask |
self < 0 ifTrue: [self error: 'This operation is not allowed for n
--- Begin Message ---
Hi Esteban,
When you say "extract", what exactly do you mean?
Let's suppose you have 86, i.e. 2r1010110
Which case do you want?
a) 2r1010110 "2 to 5 = 2r10[1011]0 = 2r1011 = 11"
or
b) 2r1010110 "2 to 5 = 2r10[1011]0 = 2r00[1011]0 = 2r0010110 = 22"
Both cases can be dea
Please, if you do implement something, start with a Collection class and
call it something like BitArray. It might be appropriate to subclass under
ByteArray, but perhaps not.
On Mar 4, 2018 12:45 PM, "Esteban A. Maringolo"
wrote:
> 2018-03-04 17:15 GMT-03:00 Sven Van Caekenberghe :
> > Bits are
2018-03-04 17:15 GMT-03:00 Sven Van Caekenberghe :
> Bits are actually numbered from right to left (seen from how they are
> printed).
I understand bit operations, used it extensively with IP address eons ago.
But if a spec says: "Take the first n bits from the hash", it means
the first signific
Bits are actually numbered from right to left (seen from how they are printed).
But in a fixed amount of bits you could indeed number them the other way around.
It does not matter that you write the leading zeros or not, everything to the
left is zero anyway. When shifting, the right thing happe
I do bitshifts and masks on Integer.
What if you want to take the bits from the 3rd to the 7th? You have to
do a some arithmetic to get the slice you want.
I'm simply asking for something more dev-friendlier that adds a
"layer" on top of that, but that internally does regular bitwise.
What I don'
Take a 24-bit number and you want to isolate the first 5 (these are actually
the last, higher order) bits.
n := 2r10101000.
n >> (16+3).
If necessary, you can apply a mask (assume there are bits earlier/later still).
(n >> (16+3)) bitAnd: 2r1
Large integers behave as bit st
Is there any package/library that makes bitwise operations as simple
as with an Integer, but for larger numbers (as in a ByteArray).
Something that allows me to "slice" a sequence of bits, or extract
some using the same protocol as with a String of ones and zeros.
Now when I need to work with seq
20 matches
Mail list logo
