Well, that about wraps this up...MRAB was 100% correct, that solution
worked...not sure how I managed to mess it up when I tried it early.
Based on the incoming values of u here is the code with the minimal
number of maskings:
def findit(u):
mask = 0x
u += 0xe91aaa35
u ^= u >>
On Jul 10, 4:04 pm, Harald Luessen <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Jul 2008 Jordan wrote:
>
>
>
> >On Jul 10, 1:35 pm, MRAB <[EMAIL PROTECTED]> wrote:
> >> On Jul 10, 4:56 am, Jordan <[EMAIL PROTECTED]> wrote:
>
> >> > I am trying to rewrite some C source code for a poker hand evaluator
> >
On Thu, 10 Jul 2008 Jordan wrote:
>On Jul 10, 1:35 pm, MRAB <[EMAIL PROTECTED]> wrote:
>> On Jul 10, 4:56 am, Jordan <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> > I am trying to rewrite some C source code for a poker hand evaluator
>> > in Python. Putting aside all of the comments such as just using t
On Jul 10, 1:35 pm, MRAB <[EMAIL PROTECTED]> wrote:
> On Jul 10, 4:56 am, Jordan <[EMAIL PROTECTED]> wrote:
>
>
>
> > I am trying to rewrite some C source code for a poker hand evaluator
> > in Python. Putting aside all of the comments such as just using the C
> > code, or using SWIG, etc. I have
On Jul 10, 4:56 am, Jordan <[EMAIL PROTECTED]> wrote:
> I am trying to rewrite some C source code for a poker hand evaluator
> in Python. Putting aside all of the comments such as just using the C
> code, or using SWIG, etc. I have been having problems with my Python
> code not responding the sam
Well, I have figured out something that works:
def findit(u):
u += 0xe91aaa35
u1 = ~(0x - u) ^ u >> 16
u1 += ((u1 << 8) & 0x)
u1 ^= (u1 & 0x) >> 4
b = (u1 >> 8) & 0x1ff
a = (u1 + (u1 << 2) & 0x) >> 19
r = int(a) ^ hash_adjust[int(b)]
Jordan wrote:
> C:
>
> u starts at 1050
>
> u += 0xe91aaa35;
>
> u is now -384127409
Hm, a negative unsigned...
> Python:
>
> u starts at 1050
>
> u += 0xe91aaa35
>
> u is now 3910839887L
Seriously, masking off the leading ones is the way to go:
>>> -384127409 & 0x == 3
if after the first step (u += 0xe91aaa35) you apply this function:
invert = lambda x: ~int(hex(0x - x)[0:-1],16)
it returns the correct value (corrected the overflow)
but there is still something wrong, still looking into it, if someone
knows how to do this, feel free to comment :)
--
ht
I realize I did a pretty bad job of explaining the problem. The
problem is the python version is returning an r that is WY to big.
Here is an example run through that function in each language:
C:
u starts at 1050
u += 0xe91aaa35;
u is now -384127409
u ^= u >> 16;
u
I was actually just going through an example to show what was
happening each step of the way and noticed the overflow!!! bah, stupid
tricks tricks tricks!!!
The problem is def the overflow, I notice that I start to get negative
numbers in the C version, which makes me think that the & 0x
t
On Wed, 09 Jul 2008 20:56:59 -0700, Jordan wrote:
> I am trying to rewrite some C source code for a poker hand evaluator in
> Python. Putting aside all of the comments such as just using the C
> code, or using SWIG, etc. I have been having problems with my Python
> code not responding the same w
I am trying to rewrite some C source code for a poker hand evaluator
in Python. Putting aside all of the comments such as just using the C
code, or using SWIG, etc. I have been having problems with my Python
code not responding the same way as the C version.
C verison:
unsigned find_fast(unsign
Peter Hansen wrote:
Lucas Raab wrote:
Sorry, the third "byte" is what I meant.
Fair enough. Note, however, that as someone pointed out,
it's actually the *fourth* of something, and it would not
necessarily be a byte. In fact, in your case, it's not:
typedef unsigned long int word32 ;
void mu
Lucas Raab wrote:
Sorry, the third "byte" is what I meant.
Fair enough. Note, however, that as someone pointed out,
it's actually the *fourth* of something, and it would not
necessarily be a byte. In fact, in your case, it's not:
typedef unsigned long int word32 ;
void mu(word32 *a)
{
int i ;
Lucas Raab wrote:
> Sorry, the third "byte" is what I meant. As for code samples, I hope the
> following will work:
>
> typedef unsigned long int word32 ;
> void mu(word32 *a)
> {
> int i ;
> word32 b[3] ;
>
> b[0] = b[1] = b[2] = 0 ;
> for( i=0 ; i<32 ; i++ )
> {
> b[0] <<= 1 ; b[1]
Peter Hansen wrote:
Lucas Raab wrote:
I have the statement: "typedef unsigned long int word32" and later
on: "word32 b[3]" referencing the third bit of the integer.
If that's really exactly what you have, then you actually have
something defining an array of three unsigned long integers
named
Peter Hansen wrote:
but merely a "b[3]" reference somewhere, it would be referencing
the third element of an array called "b", which is possibly a byte,
"*Fourth* element... I'll come in again. Amongst our elements..."
-Peter
--
http://mail.python.org/mailman/listinfo/python-list
Lucas Raab wrote:
I have the
statement: "typedef unsigned long int word32" and later on: "word32
b[3]" referencing the third bit of the integer.
If that's really exactly what you have, then you actually have
something defining an array of three unsigned long integers
named "b". And even if y
Lucas Raab <[EMAIL PROTECTED]> wrote:
> I am currently in the process of porting some C code into Python and am
> stuck. I don't claim to be the greatest C/C++ programmer; in fact, my
> skills at C are rudimentary at best. My question is I have the
> statement: "typedef unsigned long int word
Lucas Raab wrote:
I am currently in the process of porting some C code into Python and am
stuck. I don't claim to be the greatest C/C++ programmer; in fact, my
skills at C are rudimentary at best. My question is I have the
statement: "typedef unsigned long int word32" and later on: "word32
b
I am currently in the process of porting some C code into Python and am
stuck. I don't claim to be the greatest C/C++ programmer; in fact, my
skills at C are rudimentary at best. My question is I have the
statement: "typedef unsigned long int word32" and later on: "word32
b[3]" referencing t
21 matches
Mail list logo
