Best array population & access optimization

[Mark Brownell]

Hi Dar,

On Friday, June 20, 2003, at 02:12  PM, Dar Scott wrote:

> In many cases you will not need to know whether Revolution uses string 
> numerals or an internal form of the number.
>
> The above test two and three will put numeral strings into the arrays. 
>  If you find that the encryption box is more efficient with internal 
> numbers in the array, then put (zap+0) into myList[i].  As you use the 
> numbers and replace them with calculated values, they will become and 
> stay the faster internal form.  Unless you do some weird magic, the 
> key is always a numeral.

Like:

repeat with eip = 1 to 16
    xL = bitXor( xL, myP2array[eip] )
    ----------- hexF
    a = bitAnd( bitAnd( xL, -16777216 ) / 16777216, 255 ) + 1
    -- etc...

The guy that thought this S-box, bit-shift stuff up has got to be a 
full-blown max-zoomed dweeb. It messes with your mind just to visualize 
the path taken by 8 characters split in half, shifted back and forth 
through four S-boxes and shifted at each level based on the cypher key 
at each change.

This gives me some things I can test for platform differences and speed 
tests
-- put (zap+0) into myList[i] --- I will test this for optimization


> All results are strings once they get to the message box.  The 
> property numberFormat is used to convert.  Your numbers are hardly 
> affected.  The quote marks will not show up on strings unless you put 
> them in the strings.

-- nice to know this. I'll check out the property numberFormat. There 
might be some stuff there that helps.


> Because the Blowfish S-boxes have only 256 entries, you might see if 
> using numToChar(i) as the key gives you any speed advantage.  Also, 
> since Blowfish uses 32-bit numbers, you might consider extracting four 
> char sets using a char chunk expression from a string instead of an 
> array and then use binaryEncode/binaryDecode.
>
> Dar Scott

I'm definitely interested in binaryEncode/binaryDecode for many parts 
of this in Rev. My own hex-converter loop is a real dog; I'm sure I'll 
discover some speed improvements there. I was reading about it last 
night.

The bit shifting process with bitXOr is fine for the S-boxes, however 
there is always more than one way to skin a cat.  I can't imagine doing 
bit-shifting in a numerical environment that had a consideration for 
charToNum/numToChar S-boxes. Interesting idea. The 64 bit block cypher 
broken into two 32 bit halves and sent left and right does work best as 
a char chunk expression from a string instead of an array. The text 
being encrypted is never placed into an array except while 64 bits are 
hashed based on the key. This idea to binaryEncode before encrypt 
wouldn't work as the block cypher works on 1 char at a time in 8 char 
chunks at a time. There is definitely a need to binaryEncode before 
placing encrypted text into a field object.

I was wondering if a binaryEncoded variable can be compressed and saved 
to the hard drive using Rev? Can it then be opened, decompressed, and 
binaryDecoded back into a variable?

Using numToChar:
> you might see if using numToChar(i) as the key gives you any speed 
> advantage.

It won't. It would even break the inventor's prerequisite advise to 
make the algorithm easier to implement. On the other hand it will 
extend the available number of unique keys that can exist in a key set; 
by using charToNum() to set 64 bit and 128 bit keys with more choices 
for keys. ... charToNum(204)

Thank you for your input on these arrays. I definitely have some 
experiments to work on, thanks to you.

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4295 bytes
Desc: not available
URL: <http://lists.runrev.com/pipermail/use-livecode/attachments/20030620/200c85cd/attachment.bin>