Bin() ..there, done that?

[trids]

I'm using AU3 to do some bit-level processing for a Genetic Algorithm (and am finding the BitShift, BitAnd etc functions immensely satisfying, thanks to all concerned!) .. but I'm running out of space in a 32-bit integer.

Is there any chance of adding a new Bin() function, please? Along the lines of the current Dec() and Hex(). This would make it possible to store the bits in a string (up to 2GB ) which I can then splice and turn back into 32-bit integers for further processing by the BitAnd(), BitShift() family.

Either that, or perhaps expand the BitAnd(), BitShift() family to accept string arguments? ( ). Please?

[Henrik]

Genetic Algorithm? Interesting. How many bits do you need to work on?

Regarding your proposed Bin() solution: Won't you still have to handle carryover from one word to the next? E.g. if you shift a 64-bit word.

expand the BitAnd(), BitShift() family to accept string arguments?

Again, how many bits are we looking at? If there's a lot, it will probably be rather inefficient to handle them in strings.

Methinks your requirements could be realized easily and fairly efficiently in C++ (but not with strings). As far as I know AU3, both of your proposals will still leave you to code a lot of housekeeping stuff.

[SumTingWong]

I'm using AU3 to do some bit-level processing for a Genetic Algorithm (and am finding the BitShift, BitAnd etc functions immensely satisfying, thanks to all concerned!) .. but I'm running out of space in a 32-bit integer. 

Is there any chance of adding a new Bin() function, please? Along the lines of the current Dec() and Hex(). This would make it possible to store the bits in a string (up to 2GB  ) which I can then splice and turn back into 32-bit integers for further processing by the BitAnd(), BitShift() family.

Either that, or perhaps expand the BitAnd(), BitShift() family to accept string arguments? ( ). Please?

<{POST_SNAPBACK}>

Bin there?

[trids]

@pacman

Thanks for the link .. I'll resort to a UDF if I can't get my Christmas wish

@Henrik

The more bits the better, cos with only the 32 at the moment, it limits the potential scope (and number) of the variables. So 32 is ok for just illustrative purposes. But with the 2 Gigs that a string offers, the potential gets more ... serious

Of course you're right .. BitShift() with string operands is a bit redundant (basic string manipulation). But the BitAnd, BitOr etc are the focus for string operands.

Even if the result of the "enhanced" BitAnd operation (say) is restricted to a 32-bit result, it would still help immensely if the operands could be expressed as strings.

Eg (assuming that Bin(5,6) = "000101" ) ..

;$sA = "001101 .. 101011"   <-- up to 2Gb !
;$sB = "011101 .. 100111"   <-- up to 2Gb !
    $nResult = BitAnd( StringMid($sA, $nStart, $nLen),  StringMid($sB, $nStart, $nLen) )
    $sA = StringLeft($sA, $nStart - 1) & Bin($nResult, $nLen) & StringMid( $sA, nStart + $nLen + 1)

[Henrik]

;$sA = "001101 .. 101011"   <-- up to 2Gb !
;$sB = "011101 .. 100111"   <-- up to 2Gb !

<{POST_SNAPBACK}>

I was thinking performance.

Your example strings are actually 2 GB, not 2 Gb (assuming ASCII strings). If you really want to work with 2147483647 bit expressions , you'd probably get vastly better performance using C++'s vector<bool> than by using strings.

[trids]

Absolutely! Performance is a big factor .. but first I want to break the 32bit-chromosome limit

I'm looking at a string as AU3's alternative to the 32bit integer: where shifting and parsing are still manageable via string-equivalents of BitShift, and any string-literacy for BitAnd-type functions that some kind soul might add to AU3.

See, I'm a AU3 junkie and can barely read C++ :">

But if you can think of a way to make C++'s vector<bool> type accessible to AU3-mortals like me (and to AU3's BitAnd-etc functions), then that might be quite exciting

[Valik]

AutoIt doesn't use STL, so there isn't a std::vector<anything> anywhere to be found, much less the specialized vector<bool>.

[trids]

AutoIt doesn't use STL, so there isn't a std::vector<anything> anywhere to be found, much less the specialized vector<bool>.

<{POST_SNAPBACK}>

Aaah .. ok, thanks for the input Valik.

So we're left with string-literate Bit-functions and a Bin/Dec convertor then ..

Please?

[Henrik]

See, I ... can barely read C++  :">

<{POST_SNAPBACK}>

You're not alone

But if you can think of a way to make C++'s vector<bool> type accessible to AU3-mortals like me (and to AU3's BitAnd-etc functions), then that might be quite exciting 

<{POST_SNAPBACK}>

My thoughts were to put the vector & the associated bit operations in a (C++) dll, then call that dll from AU3. Perhaps someone with practical DllCall() experience would care to comment on the feasibility of this approach?

Now I'm expecting somebody (I'm not saying who!) to accuse me of 'bloated OOP'-thinking.

[Valik]

Would that really be faster than just using strings in AutoIt? You have the overhead involved of marshalling in and out of a DLL; meaning double lookups (DllCall lookup + DllCall has to find the function in the DLL).

Incidentally, I assume the "bloated-OOP" comment is a comment about my "bloated-fat-chick OOP way" remark (Or however I worded it). Don't get me wrong, I love OOP. I like elaborate, eloquent OO designs. However, MFC and to some extent STL just goes overboard with it. Everything is linked to everything else so to use 1 tiny little feature adds 30289221489 bytes to your file since that one feature relies on this thing relying on that thing which relies on those two things over there.

[Henrik]

Would that really be faster than just using strings in AutoIt?  You have the overhead involved of marshalling in and out of a DLL; meaning double lookups (DllCall lookup + DllCall has to find the function in the DLL).

<{POST_SNAPBACK}>

The answer to that question probably depends on the word length. If the strings are very large, the string approach will be slow.

Incidentally, I assume the "bloated-OOP" comment is a comment about my "bloated-fat-chick OOP way" remark (Or however I worded it).  Don't get me wrong, I love OOP.  I like elaborate, eloquent OO designs.  However, MFC and to some extent STL just goes overboard with it.  Everything is linked to everything else so to use 1 tiny little feature adds 30289221489 bytes to your file since that one feature relies on this thing relying on that thing which relies on those two things over there.

<{POST_SNAPBACK}>

Seems my little stimulus-response experiment worked fine . No offense intended.

Edit: I'm no MFC fan either.

Edited December 22, 2004 by Henrik

[trids]

Meantime, I'll proceed with strings of binary characters then in the hope that Dec() and Hex() will soon get a little brother.

Here's the UDF that will be standing in until then (or somethjing very like this):

Func _Bin2Dec($psBin)
;Converts a string of "0"s and "1"s to a decimal value

    If StringLen($psBin) > 64 then Return -1

    $nRet = 0
    $n2Yx = 1  ; 1, 2, 4, 8, 16, 32 ....
    For $nPos = StringLen($psBin) to 1 Step -1
        $nRet = $nRet + $n2Yx * Number(StringMid($psBin, $nPos, 1))
        $n2Yx = $n2Yx + $n2Yx
    Next
    Return $nRet
    
EndFunc

[tylo]

For what it is worth, here are some functions that enables you to work with arrays of bits...

Func BitvecDim(byref $bv, $n)
   Dim $bv[($n+31)/32]
EndFunc

Func BitvecSet(byref $bv, $i)
   $bv[$i/32] = BitOR($bv[$i/32], BitShift(1, -BitAnd($i, 31)))
EndFunc

Func BitvecUnset(byref $bv, $i)
   $bv[$i/32] = BitAnd($bv[$i/32], BitNot(BitShift(1, -BitAnd($i, 31))))
EndFunc

Func BitvecInvert(byref $bv, $i)
   $bv[$i/32] = BitXor($bv[$i/32], BitShift(1, -BitAnd($i, 31)))
EndFunc


Func BitvecGet(byref $bv, $i)
   Return BitAnd($bv[$i/32], BitShift(1, -BitAnd($i, 31))) <> 0
EndFunc

; ----------------

Global $V
BitvecDim($V, 128)

BitvecSet($V, 90)
BitvecSet($V, 91)
BitvecSet($V, 92)
BitvecInvert($V, 92)
BitvecInvert($V, 93)
BitvecUnset($V, 90)

msgbox(0, "OK", BitvecGet($V, 90) & " " & BitvecGet($V, 91) & " " & BitvecGet($V, 92) & " " & BitvecGet($V, 93))