Consolidated NoteCaddy feature request thread

[sreticentv]

Hi,
You have some mistakes in your PLO evaluator.

1) AsKsQhQs on QsJs2d have 94.3% and AsKsQhQs on QsJs2d have 94.5% by a exhaustive method. Deviation for a Monte-Carlo method have not be more then 1% for 10K trials.
Definitely not a 2 percent!

2) Ac8s2s7c on 6s8c9cAhKc has 96 hand strength ( and I have been complaining about this from August) in 2.0.0.6088 !
It is impossible to explain by deviations.

Please, resolve this problem!

I never said I used monte carlo. How long did it take for that calculation when you ran your own simulation? You want me to fix it like it's so simple but in my last post I explained clearly how it was a trade off. Everyone wants 200+ hands per second so this is what's possible in that time frame. Please tell me which of the tradeoffs you prefer:

-10 hands per second processing
-Extra 1 gb download every time there's a patch

10k hands?
There are 16432 hand categories, so unless you simplify it further with regards to suits, by treating
(A2)(56) the same as (A5)(62) and (A6)(52) then I dont understand which 10k hands exactly
The (A2)(56) notation means double suited hand with A2 suited and 56 suited.

The problem with using all 16k is that the way the progression to turn and river works would cause the lookup tables to take up tons of memory. I tried to reduce each to where the % stayed very close but by the time you get to the river sometimes you end up off by some %

I'm not criticizing the method.
Lookup for every hand and every board would have probably hundreds of gigabytes (for rivers), but I need to know how hand strength as shown in your program relates to equity.

For example AKQQ+NFD on QJ2ss is the best possible hand, but also - random hand has 5.5% equity against it.
so the 90 strength as reported by NC would be somewhat close to 94.5% equity.

Please explain in bit more detail what how is the scoring determined.
From what you said there are 10k (why 10k not all 16432) and all flops in the lookup table
so presumably you calculated equity or some other statistic for each hand on each flop right?

And how is the process used for rivers? There are many more rivers than flops, so the lookup table would be way bigger.

You're doing good job with providing hand strength, but users (or at least me, because I care) should have better idea what strength=70% means
Does it have 70% equity vs random
or does it have higher equity than 70% of all hands?
This is very important to understand.

Long story short it means that it will win 70% of the time against all other hand combinations. What I am sensing is that for Omaha, all hands tend to have strong scores that are close together which minimizes the effectiveness of this number. If that's the case I could revisit it in the future

[vyvojer]

I never said I used monte carlo. How long did it take for that calculation when you ran your own simulation? You want me to fix it like it's so simple but in my last post I explained clearly how it was a trade off. Everyone wants 200+ hands per second so this is what's possible in that time frame. Please tell me which of the tradeoffs you prefer:

-10 hands per second processing
-Extra 1 gb download every time there's a patch

I prefer speed, not accuracy. And I fully understand, how long it takes enumerate all hands. My java simulation is much much slower.
The problem lies elsewhere. Why nuts has only 96 on the river? That means that 400 hands from 10K beat nuts. How it is possible?

Note that Ac7c on 6s8c9cAhKc has 100. But Ac7c8s2s has 96. And another a important note: Ac7c is "NutFlush", but Ac7c8s2s it's "NutFlush/8",like the river isn't last street .

[nilaynilay]

i will pencil it in

[Stasek]

The problem with using all 16k is that the way the progression to turn and river works would cause the lookup tables to take up tons of memory. I tried to reduce each to where the % stayed very close but by the time you get to the river sometimes you end up off by some %

But which 10k hand? What was the selection process?
The only reasonable way I can see for reduction from 16432 is by ignoring suit strength difference, thus equating
(AK)(32) with (A3)(K2) and (A2)(K3) for double suited hands for example.

Long story short it means that it will win 70% of the time against all other hand combinations. What I am sensing is that for Omaha, all hands tend to have strong scores that are close together which minimizes the effectiveness of this number. If that's the case I could revisit it in the future

So basically strength means 'equity vs random'? Or close to?
Does strength equal equity vs random for holdem?

If you run vs each other of 10k hand combinations, this is weighted equity right?
for example AKQJ rainbow has 24 combos
and AKQJ single suited - 144.

So if you ran equity vs AKQJr and AKQJss then it sholuld be weighted (24*equity_vs(AKQJr) + 144*equity_vs(AKQJss))/(24+144).

So again: how is this implemented in holdem (ie: what does strength mean for holdem exactly) and was strengh for omaha supposed to be similar, but with certain time/space saving simplifications?


I've run several strength checks and equity sims vs random
Board: Ks Qh 7d 4c 2d (so: no straight or flush possible)

First number is strengh, second- equity vs random hand

AQ93: 43 (49)
AQ92: 63 (73)
AK92: 72 (84)
9822: 85 (92)

NC is consistently underestimating hand strength up to 11% and this is unfortunatelly unacceptable.
Where does this problem come from?
Here there is no flush possible, so suits don't matter.
Also small number of simulations doesn't explain strength being consistently lower.

BTW - what language is NC written in?

[Stasek]

Example: cbet 60% (6/10) -15%
this is roughly how NC now shows data
and -15% means, that it happens 15% less than for avg population.
So to get population average id need to solve 60%/(100%-85%) = 70.6%

But I think (strongly convinced) that actual average frequency (70.6%) is more valuable than -15% relative difference.
So the request is to change that and display 70.6% population average rather than -15% (or display both).

[nilaynilay]

yes i agree. i have a proposal to have $average as a variable. But i am thinking now what you are suggesting might be better. coz it might reduce the space we need

and the deviation could be made into a extra variable? (for those that need it)

I also find it difficult to convert the deviation into average even when 4 tabling.

Another imp use of this is when i dont have notes on a player but i know what the average is for a particular move. for ex CR dry flop against btn raise when btn is a tag. if i know the average is say 60% fold thats valuable intelligence(reasonable,le to assume he will be in that ballpark assuming no other data)

Let us wait for Sretis input here.

[Stasek]

Is it possible to create NC note that shows how often villain folds to our cbet (I know it already exists in the HM2 hud)?
The opportunity would be: raised PF + cbet flop
success: raised PF + cbet flop + opponent folded

On a similar note: how about won @ showdown when [took specific line]
opportunity = all lines matching the specific line
success - as above + won @ sd

[Stasek]

Currently double suited hands like T943ds are displayed as T943ss.
And with that, "ss" suffix should be changed to mean only single suited hands (including hands with same 3 or 4 suits, like AsKsQsJs)

[Stasek]

actually, now hands without suffix seem to be single suited, "o" stands for rainbow, and "ss" for double suited?
Is that correct?

[Stasek]

I have some suggestions that would improve board readability

1.Sort flop by rank (so if flop is 2K9 display it as K92)
2. Suitedness
suited flop: add single 's'
monotone: 'm' - rather than sss
rainbow - nothing or 'r'

if rainbow flop and turn brings FD, again 's' is better than 'ss'
if turn brings second FD - mark it as 'ds' - so on AsKs9h 5h, that would be: AK9s 5ds
Maybe add space before turn card? eg: AK9r 5s6s

Hands are already nicely sorted by rank and that improves readability a great deal.