>
> >I think I've mentioned the error in game_std.h but the bug in
> >eval_low8.c makes me think nobody has used this lib to do any high/low
> >split investigation.
>
> Thanks for the bug report; will fix. Will eventually get a public CVS
> server running so you can do that yourself...

With the huge amount of traffic here I'm not sure thats really
important.

>
> >Brian -- I believe at one point you were working on a o/8 evaluator.
> >I know have an o8cmpn.c that does it by brute force. If you are not
> >going to have a reasonable evaulator done in the near future I'd like
> >to post this source.
>
> I'm pretty sure I've got working low and low8 evaluators in my sadly
> neglected library.
>
> My slighly-optimized plan for Omaha evaluation was this: Let H be the
> (four) cards in your and C be the common cards. Use the evaluator to
> evaluate M = eval(C union H), which would give you the best possible hand
> you could make if you broke the Omaha rules. Then do a brute-force
> enumeration of the 2-card subsets of H until you either get M (in which
> case you know you're done) or you exhaust the possibilities.
>
> I suspect this will likely yield slightly less than 2x factor of speedup
> over the brute force approach.

I tried a single O/8 example (a234 single suit vs. a2a3 ds) and got
less then a 15% speed up. Obviously that doesn't make a study but I
think your estimate of how much speedup you'll see is optimistic.
Think of it this way. If all O/8 hands were split pots between the
nuts then on average you would just see a 2x speedup. Any cases where
one of the hands did make it to the nuts would slow you down.

Omaha high might show a better speedup as you can short-circuit the
enumeration earlier.

mph