Logical expressions

Coding-related discussion: OpenPPL (Poker Programming Language) and internal OpenHoldem-script
Post Reply
yomismosol
Fish
Fish
Posts: 5
Joined: Mon Dec 16, 2019 10:09 am

Logical expressions

Post by yomismosol » Tue Jan 28, 2020 9:44 am

I've noticed something strange on the code, and I don't know if it was intended or it was an error of copy paste.

For example, on turn you have this:

WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND NOT (PairOnBoard) AND NOT (FlushPossible) AND (RaisesBeforeFlop) AND NOT (BotIsLastRaiser) AND Random <= 50 AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE
WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND NOT (PairOnBoard) AND NOT (FlushPossible) AND (RaisesBeforeFlop) AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE
WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND NOT (PairOnBoard) AND NOT (FlushPossible) AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE

As u can see, the second option includes the first one and the third one includes the second and first one, so if it is intented, first and second are useless. This happens a lot on code, for example also here:

WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND PairOnBoard AND NOT (FlushPossible) AND (RaisesBeforeFlop) AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE
WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND PairOnBoard AND NOT (FlushPossible) AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE

In this case, RaisesBeforeFlop is ignored. The second option includes the first one.

Also here:

WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveNutFlushDraw OR HaveSecondNutFlushDraw) AND (RaisesBeforeFlop) AND NOT (BotRaisedBeforeFlop) AND Random <= 50 AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE
WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveNutFlushDraw OR HaveSecondNutFlushDraw) AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE


There are a lot of places where this happens. If at least the raise of the pot size was different...it would be ok, but it is the same on all these cases.

Alex
Site Admin
Site Admin
Posts: 2533
Joined: Sun Mar 26, 2017 5:58 pm

Re: Dynamo - main thread

Post by Alex » Tue Jan 28, 2020 10:47 am

yomismosol wrote:
Tue Jan 28, 2020 9:44 am
I've noticed something strange on the code, and I don't know if it was intended or it was an error of copy paste.

For example, on turn you have this:

WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND NOT (PairOnBoard) AND NOT (FlushPossible) AND (RaisesBeforeFlop) AND NOT (BotIsLastRaiser) AND Random <= 50 AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE
WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND NOT (PairOnBoard) AND NOT (FlushPossible) AND (RaisesBeforeFlop) AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE
WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND NOT (PairOnBoard) AND NOT (FlushPossible) AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE

As u can see, the second option includes the first one and the third one includes the second and first one, so if it is intented, first and second are useless. This happens a lot on code, for example also here:

WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND PairOnBoard AND NOT (FlushPossible) AND (RaisesBeforeFlop) AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE
WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND PairOnBoard AND NOT (FlushPossible) AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE

In this case, RaisesBeforeFlop is ignored. The second option includes the first one.

Also here:

WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveNutFlushDraw OR HaveSecondNutFlushDraw) AND (RaisesBeforeFlop) AND NOT (BotRaisedBeforeFlop) AND Random <= 50 AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE
WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveNutFlushDraw OR HaveSecondNutFlushDraw) AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE


There are a lot of places where this happens. If at least the raise of the pot size was different...it would be ok, but it is the same on all these cases.
those code lines start the same, but as you can see conditions are different, so it's not a mistake.

Code: Select all

WHEN A and B and C 
is not the same as

Code: Select all

WHEN A and B and D

yomismosol
Fish
Fish
Posts: 5
Joined: Mon Dec 16, 2019 10:09 am

Re: Dynamo - main thread

Post by yomismosol » Tue Jan 28, 2020 3:26 pm

Not is is not.....

for example:

WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND NOT (PairOnBoard) AND NOT (FlushPossible) AND (RaisesBeforeFlop) AND NOT (BotIsLastRaiser) AND Random <= 50 AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE
WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND NOT (PairOnBoard) AND NOT (FlushPossible) AND (RaisesBeforeFlop) AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE
WHEN (HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND NOT (PairOnBoard) AND NOT (FlushPossible) AND NOT (dll$func942) RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp) FORCE

(HaveTopPair AND TopPairRank >= 8) AND (HaveBestKicker OR HaveSecondBestKicker) AND NOT (PairOnBoard) AND NOT (FlushPossible) is A
(RaisesBeforeFlop) is B
NOT (BotIsLastRaiser) is C
Random <= 50 is D
NOT (dll$func942) is E

so it would be
WHEN A AND B AND C AND D AND E RaiseBy....
WHEN A AND B AND E RaiseBy
WHEN A AND E RaiseBy

Alex
Site Admin
Site Admin
Posts: 2533
Joined: Sun Mar 26, 2017 5:58 pm

Re: Dynamo - main thread

Post by Alex » Tue Jan 28, 2020 6:19 pm

yomismosol wrote:
Tue Jan 28, 2020 3:26 pm
so it would be
WHEN A AND B AND C AND D AND E RaiseBy....
WHEN A AND B AND E RaiseBy
WHEN A AND E RaiseBy
In this order everything makes sense to me. It would be wrong in opposite order.

yomismosol
Fish
Fish
Posts: 5
Joined: Mon Dec 16, 2019 10:09 am

Re: Dynamo - main thread

Post by yomismosol » Wed Jan 29, 2020 7:17 am

Why? If you have a third condition with A and E, you just only need to be A and E to be true. If you add a first condition with more conditions that include A and E , even if they are false , at the end , the third condition will apply, so the first and second conditions are not necessary.

Maybe you are not understanding me or Im not understanding you, but I see it veruly clear

Alex
Site Admin
Site Admin
Posts: 2533
Joined: Sun Mar 26, 2017 5:58 pm

Re: Dynamo - main thread

Post by Alex » Wed Jan 29, 2020 11:29 am

yomismosol wrote:
Wed Jan 29, 2020 7:17 am
Why? If you have a third condition with A and E, you just only need to be A and E to be true. If you add a first condition with more conditions that include A and E , even if they are false , at the end , the third condition will apply, so the first and second conditions are not necessary.

Maybe you are not understanding me or Im not understanding you, but I see it veruly clear
i've splitted this discussion into new topic, if you don't mind. I think you mis-understand the usage of those logic expressions.
let me try to explain by this example:

Code: Select all

WHEN f$InPosition AND f$HaveMonsterHand RaiseBy 3 Force
WHEN f$InPosition Call Force
in terms of our discussion, it's the same as:

Code: Select all

WHEN A AND B RaiseBy 3 Force
WHEN A Call Force
so why we include "A" in both lines? Because in the first condition, we tell the bot to raise IF we are in position, AND we have monster hand.
In the second line we tell the bot to call ALL OTHER hands, if we are in position. Does it make sense now?
Every next line we tell the bot what to do, if our initial condition is not so strictly defined.

yomismosol
Fish
Fish
Posts: 5
Joined: Mon Dec 16, 2019 10:09 am

Re: Logical expressions

Post by yomismosol » Wed Jan 29, 2020 3:19 pm

In your example is working ok because A AND B is RaiseBy 3 and A is Call

In the example that I gave you we find this:

WHEN A AND B RaiseBy 3
WHEN A RaiseBy 3.

this is basic algebra, A contains (A AND B) and if the result is the same, (A AND B) can be ignored because of that.

In your example, the second WHEN is a Call and of course, the result is different, but in my example the result is the SAME. That is the problem, that if the result is the same, the "WHEN" with less conditions includes the "WHEN" with more conditions.

Do you understand me now? Change your example to both RaiseBy 3 and I think you will understand the problem. Look my example all the conditions finish with: RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp)

Alex
Site Admin
Site Admin
Posts: 2533
Joined: Sun Mar 26, 2017 5:58 pm

Re: Logical expressions

Post by Alex » Wed Jan 29, 2020 4:12 pm

yomismosol wrote:
Wed Jan 29, 2020 3:19 pm
In your example is working ok because A AND B is RaiseBy 3 and A is Call

In the example that I gave you we find this:

WHEN A AND B RaiseBy 3
WHEN A RaiseBy 3.

this is basic algebra, A contains (A AND B) and if the result is the same, (A AND B) can be ignored because of that.

In your example, the second WHEN is a Call and of course, the result is different, but in my example the result is the SAME. That is the problem, that if the result is the same, the "WHEN" with less conditions includes the "WHEN" with more conditions.

Do you understand me now? Change your example to both RaiseBy 3 and I think you will understand the problem. Look my example all the conditions finish with: RaiseBy ((PotSize * (0.75 + dll$func922)) * f$Bp)
yes, you are right, my bad - i didn't notice that resulting action was the same.
May be Frog can explain it? I guess it's just happened because he edited some codelines, and forgot to delete "duplicating" lines. It happened to me too sometimes, while working on profile code.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests