Python update trouble (2.3 to 2.4): x<<y

[Gonzalo Monzón]

Thank you very much John,

I missed the point to add the *and* to workaround the long result issue! 
I think I understand it now.

I am timing the code once translated, so here are the results for the 
crc calculation function. I did expected a big gap, as this does a lot 
of lookups to the crc table (a typical call gets 20-250 characters long) 
so the C extension version with a simple array and pointers perform 
really a lot better. The C code was glued with pyrex.

Fortunately I don't need a great performance for this code in the PocketPC!

C CalcCRC16
        1 loops -> 4.75e-006 secs
   210562 loops -> 0.133 secs
  1580403 loops -> 0.973 secs
  1580403 loops -> 0.973 secs 0.971 secs 1.12 secs
  1580403 loops, best of 3 trials: 0.614 usec per loop

Python CalcCRC16
        1 loops -> 0.000102 secs
     9834 loops -> 0.832 secs
    11824 loops -> 1.01 secs
    11824 loops -> 1.01 secs 1.02 secs 1.01 secs
    11824 loops, best of 3 trials: 85.1 usec per loop

Tested with: CalcCRC16('klldjs at ajsdla#kjfdsfj32389293rhcnacak12932842fjos')

C Version:

long CalcCRC16(char *str)
{
    long crc;
   
    for(crc = 0xFFFF; *str != 0; str++) {
        crc = CRC16Table [(( crc >> 8 ) & 255 )] ^ ( crc << 8 ) ^ *str;
    }
   
    return crc;
}


John Machin escribió:

>For a start,
>  
>
>>>>22002496167782427386022437441624938050682666541682 & 0xffffffffL
>>>>        
>>>>
>67560050L
>  
>
>so you could just do that at the end.
>But you don't really want to be carrying all that rubbish around,
>getting longer and longer each time around the loop. And let's further
>the translation into Python by getting rid of the xrange gizmoid and a
>few other undesirables:
>
># tested on your 1 test value
>def CalcCRC16v2(astr): # don't shadow str()
>    # global gCRC16Table # don't need this
>    crc = 0xFFFFL # start as a long
>    for c in astr:
>        crc = gCRC16Table[((crc >> 8) & 255)] ^ ((crc & 0xFFFFFF) << 8)
>^ ord(c)
>    return crc
>
>That should get you going. Although the whole calculation will be done
>with longs instead of ints, the longs will never exceed 32 bits so it
>shouldn't be too slow.
>
>HTH,
>John
>
>  
>