Sign in to follow this  
Followers 0
trids

Bin() ..there, done that?

13 posts in this topic

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. :idiot:

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 :lol: ) 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? ( :D ). Please?

Share this post


Link to post
Share on other sites

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.


Ignorance is strength.

Share this post


Link to post
Share on other sites

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.  :idiot:

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  :lol: ) 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? ( :D ). Please?

<{POST_SNAPBACK}>

Bin there?

Share this post


Link to post
Share on other sites

@pacman

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

@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 :idiot:

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)

Share this post


Link to post
Share on other sites

;$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 :idiot: , you'd probably get vastly better performance using C++'s vector<bool> than by using strings.


Ignorance is strength.

Share this post


Link to post
Share on other sites

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

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 :D

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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? :idiot:

Share this post


Link to post
Share on other sites

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

<{POST_SNAPBACK}>

You're not alone :idiot:

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  :D

<{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.


Ignorance is strength.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

#11 ·  Posted (edited)

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 :idiot: . No offense intended.

Edit: I'm no MFC fan either.

Edited by Henrik

Ignorance is strength.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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))

blub

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0