[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Réf. : Re: Réf. : RE: [Bug-gnubg] Analysis bug ?

From: Massimiliano . Maini
Subject: Réf. : Re: Réf. : RE: [Bug-gnubg] Analysis bug ?
Date: Mon, 13 Mar 2006 09:36:40 +0100

>It does redo the computations. What it gets wrong is that it for some
>strange reason think the cube is a pass.
>When, in the analysis it checks whether it is a take or a drop it use
>logic like:
>if( -arDouble[ OUTPUT_DROP ] < -arDouble[ OUTPUT_TAKE ] ) {
>So it is a code inconsistency which should be corrected anyway. What I
>don't get is why it arrives at pass, when it checks for the reason for
>the double being bad.

Yeah, that's strange. In analysis.c (updateStatcontext) it takes decisions
calling CashPoint instead of comparing equities. Also, function CashPoint
is used only here ... very suspect. Deciding using equities should look
like :

eq[NO_DOUBLE] > min(eq[TAKE],eq[PASS]) --> it was a no double :
      - if eq[PASS] > eq[TAKE] (the opp will take), it is a "wrong double
(below DP)"
      - if eq[PASS] < eq[TAKE] (the opp will pass), the it is a "wrong
double (above TG)"

I would definitely go with equity comparison (same code as analysis,
eventually factor out a fcn called from both places), but using the CP do
determine if the wrong double is "below DP" or "above TG" should be ok :
it assumes that the CP is in between the DP and the TG, but I don't see
why this should't be the case all the time (better ask to some theoretician
though). Maybe something is broken in CashPoint...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]