Dynamic Insurance

**21forme** · 06-23-2022, 12:12 PM

Originally Posted by ShipTheCookies

As far as I'm concerned, if you are not winning your insurance bets 100% of the time like we do, then you're just guessing and gambling.

Helps to know the down card, doesn't it? Even so, it's probably not a good idea to win it 100% of the time.

**DSchles** · 06-23-2022, 12:25 PM

A couple of things not right above. Looks like a missing zero after the decimal in the bottom frequency. Also, if the edge is linear at 2.3% (.023) per each TC, then the edge can't be 8.274% at +6.5 and 8.057% at +6, which would mean an increase in edge of only 0.217% for half a true count. The increase has to be about 1.15%.

Don

**Freightman** · 06-23-2022, 01:06 PM

Originally Posted by Secretariat

Playing perfect insurance is far from winning the insurance bet 100% of the time.
The worse it can be is 33.3% over the long haul and won't likely be over 40% overall.
Is that what you meant or are you referring to a non-mathematical technique?

By the way, Don how much does perfect insurance add to TC+3 index insurance?

Food for thought
The clear answer is when remaining 10 value cards equal or exceed 33.33333% of remaining cards, further understanding there is no gain or loss at exactly 33.333333%. The clear accepted hypothesis is that insurance success increases per increase in true count. This further postulates that %success increases per true count.

It is further understood mathematical rates of success are calculated on 100% of hands arriving at the standard hi lo true 3.0 as being the break even point.

Understanding that true 3 is really a bucket of true counts from 3.0 to 3.99, the non obvious question is
-how to increase success at tc 3.0,
-when to take mathematically correct insurance below tc 3.0, as in for example, tc 2.0
-when not to take not mathematically non correct insurance above tc 3.0, as in for example tc 4.0 or 5.0.

This comes back to the theory of perfect insurance when 10 value cards consist of a minimum 33.33333% of total remaining cards, which really is different than taking insurance at tc 3.0. I’m aware of a particular regaled system that assists in this regard.

**Norm** · 06-23-2022, 01:09 PM

Originally Posted by 21forme

Helps to know the down card, doesn't it? Even so, it's probably not a good idea to win it 100% of the time.

Yeeeah. Biggest giveaway of hole carding.

**Freightman** · 06-23-2022, 01:14 PM

Originally Posted by Norm

Yeeeah. Biggest giveaway of hole carding.

Throwing back the little fish assists, as in returning small dealer errors which also assists.

**Norm** · 06-23-2022, 01:19 PM

Thing about hole carding and insurance is that insurance doesn't happen that often, and with short sessions it seems safe to always play it correctly. But, hole carding opportunities are also not all that common, and they are going to track you over multiple sessions if you keep winning while making unusual plays. So, don't make it easy for them.

**Secretariat** · 06-23-2022, 01:35 PM

Originally Posted by Freightman

Food for thought
I’m aware of a particular regaled system that assists in this regard.

... and of a couple of other delicious ones too

**Cacarulo** · 06-23-2022, 03:17 PM

Originally Posted by DSchles

A couple of things not right above. Looks like a missing zero after the decimal in the bottom frequency. Also, if the edge is linear at 2.3% (.023) per each TC, then the edge can't be 8.274% at +6.5 and 8.057% at +6, which would mean an increase in edge of only 0.217% for half a true count. The increase has to be about 1.15%.

Don

It looks like a decimal is missing but no, one of the indices is decimal (+6.5) and the other is integer (+6). To obtain decimal indices, the TC bucket is divided by ten.
A TC bucket of +6 corresponds to all TCs from 6.0 to 6.99. A TC bucket of +6.5 corresponds to all TCs from 6.5 to 6.599.
The following is an excerpt from the table of integer TCs (floored):

Code:

|         7 |  0.00331524876896957 |  0.10418173998459494 |
|         6 |  0.00603608732656385 |  0.08057113743332595 |
|         5 |  0.01112305412502699 |  0.05685869557587340 |
|         4 |  0.01962341523338983 |  0.03323476371276553 |
|         3 |  0.03458296110854670 |  0.00983492379097725 | ==> Index
|         2 |  0.06091233344817155 | -0.01337788912693772 |

Now an excerpt from the decimal table:

Code:

|       6.6 |  0.00050363113804453 |  0.08534201295461337 |
|       6.5 |  0.00083473498616494 |  0.08273895754443319 |
|       6.4 |  0.00047146975703350 |  0.08017878263750422 |
|       6.3 |  0.00065293210954556 |  0.07818503836651422 |
|       6.2 |  0.00067008637909370 |  0.07586590146650436 |
|       6.1 |  0.00070796350539883 |  0.07354326582705738 |
|       6.0 |  0.00079592077235900 |  0.07106944734401503 |
|       5.9 |  0.00081711234137873 |  0.06862911605002285 |
|       5.8 |  0.00087211359547566 |  0.06645018765390547 |
|       5.7 |  0.00105246716181200 |  0.06404919685528179 |
|       5.6 |  0.00094966578645078 |  0.06158099659365431 |
|       5.5 |  0.00108592174757746 |  0.05924308784833447 |
|       5.4 |  0.00098733161212243 |  0.05688713158492924 |
|       5.3 |  0.00114036580200978 |  0.05458947587356906 |
|       5.2 |  0.00145115679991322 |  0.05207825159686832 |
|       5.1 |  0.00119158716745514 |  0.04982801777757585 |
|       5.0 |  0.00157533211083177 |  0.04749574285278882 |
|       4.9 |  0.00135688381915618 |  0.04508841244534427 |
|       4.8 |  0.00161627897651803 |  0.04280303892446038 |
|       4.7 |  0.00148456768323722 |  0.04043611455393772 |
|       4.6 |  0.00187771613510238 |  0.03805977111190289 |
|       4.5 |  0.00192903392378417 |  0.03567680544194314 |
|       4.4 |  0.00204364816415973 |  0.03335720451412432 |
|       4.3 |  0.00204896336413966 |  0.03102128813444172 |
|       4.2 |  0.00226008197757142 |  0.02870127637506465 |
|       4.1 |  0.00223556215078928 |  0.02633804664735124 |
|       4.0 |  0.00277067903893174 |  0.02382858671796773 |
|       3.9 |  0.00252834012690595 |  0.02134678732674221 |
|       3.8 |  0.00273738804098899 |  0.01920145211732404 |
|       3.7 |  0.00299151159785184 |  0.01695344831590150 |
|       3.6 |  0.00318731337724916 |  0.01457566488583221 |
|       3.5 |  0.00329441274445343 |  0.01220811052235779 |
|       3.4 |  0.00328563984846646 |  0.00990131842604524 |
|       3.3 |  0.00357237696539312 |  0.00758366452968132 |
|       3.2 |  0.00422783837152764 |  0.00521097502843536 |
|       3.1 |  0.00406765817996126 |  0.00290770935920110 |
|       3.0 |  0.00469048185574888 |  0.00057823824153898 | ==> Index
|       2.9 |  0.00453857017978647 | -0.00179119665625683 |

Note that in the first table the difference between one TC and the next is approximately 0.023, as you rightly said:
Between +7 and +6: 0.10418173998459494 - 0.08057113743332595 = 0.02361060255126899
Between +6 and +5: 0.08057113743332595 - 0.05685869557587340 = 0.02371244185745255

But in the second the difference is obviously smaller:
Between +6.6 and +6.5: 0.08534201295461337 - 0.08273895754443319 = 0.00260305541018018
Between +6.5 and +6.4: 0.08273895754443319 - 0.08017878263750422 = 0.00256017490692897

The above is pure CA but I get the same results by simulation.

Sincerely,
Cac

**DSchles** · 06-23-2022, 04:30 PM

I understand. But I'm guessing that when aceside refers to a TC of +6.5, he isn't suggesting that your bucket be 0.1 wide!!

Don

**Cacarulo** · 06-23-2022, 05:26 PM

Originally Posted by DSchles

I understand. But I'm guessing that when aceside refers to a TC of +6.5, he isn't suggesting that your bucket be 0.1 wide!!

Don

Well, it's true. Actually in post #43 he says that at a TC of +6.5 the advantage is 7.4%. Then in post #48 he says that the advantage is 8.3%.
It is not clear what he meant, but 8.3% is quite close to the 8.27% that I calculated.

Sincerely,
Cac

**Freightman** · 06-23-2022, 05:26 PM

Originally Posted by DSchles

I understand. But I'm guessing that when aceside refers to a TC of +6.5, he isn't suggesting that your bucket be 0.1 wide!!

Don

Understood. The inescapable points on insurance are
1. High value cards must exceed low value cards
2. High value cards must exceed intermediate value cards
3. Perfect insurance occurs when 10 value cards equal or exceed 33.333% of remaining cards
4. True 2.4 and 3.0 DD and 6D respectively are guides only. Insurance can be mathematically accepted before published strike point. Insurance can be mathematically rejected at or above strike point.
5. Density of intermediate cards mathematically affect insurance decisions.

In conclusion - if point 5 above is valid (which it clearly is), then the obvious extension is density of intermediate cards should also affect betting, play and by extension, index decisions.

**DSchles** · 06-23-2022, 08:19 PM

Short summary of your above post: We can make more accurate insurance decisions by using methodologies superior to the Hi-Lo primary count alone. Duh!

Don

**Freightman** · 06-23-2022, 08:42 PM

Originally Posted by DSchles

Short summary of your above post: We can make more accurate insurance decisions by using methodologies superior to the Hi-Lo primary count alone. Duh!

Don

I’m pleased that you agree with the concept. The beauty of spelling it out is that it’s only a hop skip and jump to further understanding the impact of intermediate densities on cash received results - and from there, enjoying the improved results over simulated returns that a density based system will provide - such as the regaled FBM ASC.