A question, is following logic correct?
flops
We can have 52*51*50/6=22100 different flops.
And such (if we would adapt EQarray code a bit) we would require 22100 stored EQArray ('x','y','z','__','__') of 56Mb =113Gb instead of 52^3=140 608 / or 7690Gb.
EQ, all-in at flop
And such, if we set up a tree where a random flop is dealt; the code would each time have to consult one of the 22100 stored EQArray stored at HD.
At first sight, we could say that we are required to generate all these 22100 EQArrays if we get a hand at flop that goes all-in at flop.
However, if we eventually went through all possible flops for each [i,j][a,b] aka went through all the possible EQArrays (that do not conflict); we can conclude that the resulting equity of [i,j][a,b]=sum(1/22100 * EQ('x','y','z','__','__'))
Now, if our code is written correctly, we do not sum 22100 EQ's, we actually sum less as some boards are impossible to be dealt.
And such, instead of having to adapt code; generate and store 22100 EQArray stored at HD; generate each flop; combine the equities; we can actually just use EQArray('__','__','__','__','__') for each hand we get all-in at flop.
Now, EV, all-in at flop
Let's assume that the EV is of algebraic form [a + b EQ('x','y','z','__','__')]
and such
EVflop = sum(1/22100 * [a + b EQ('x','y','z','__','__')])
once again, if our code is written correctly, we do not sum 22100 EV's, we actually sum less as some boards are impossible to be dealt.
= a+b[sum(1/22100 * EQ('x','y','z','__','__'))]
OR = a + b EQ('__','__','__','__','__')
Once again we can just use EQArray('__','__','__','__','__') for each hand we get all-in at flop.
turns
after 4 cards; there are 22100 * 49 = 1 082 900 boards possible.
However, we can once again adapt EQArray code, simply because in the above line each board of 4 cards is present 4 times.
To rephrase it : 52*51*50*49/24 = 270 725
And such we require the software to generate 270 725 EQ('x','y','z','a','__')
or 14.46Tb of information.
EQ turns after flop call
If we move to the turn; there are theoretically 49 EQ('x','y','z','a','__') over which we sum the EQ's. However each time 4 EQArrays will not be counted as they conflict with cards present in the starting hands.
However, we once again arrived into:
EQ(turn) = sum(1/49*EQ('x','y','z','a','__'))
which is equal to EQ('x','y','z','__','__') for the specific flop dealt.
And such instead of having to adapt code for turns; generate and store 270 725 EQ('x','y','z','a','__') stored at HD; generate each turn; combine the equities; we can actually just use EQ('x','y','z','__','__') for the specific flop dealt whenever a hand goes all-in at turn after a flop call.
Once again, at this time we can think that we require EQ('x','y','z','__','__') when we go to turn after flop call; however because we will iterate all flops, and after a flop is generated, we will iterate over all turns, we can just use once again EQArray('__','__','__','__','__') whenever a hand goes all-in at turn after a flop call.
EV turn after flop call
EQ river after flop+turn call
EV river after flop+turn call
idem dito
And such we can just use EQArray('__','__','__','__','__') whenever we get a hand all-in; simply because our software will iterate over all possible flops, all possible turns, all possible rivers and combine the results. And instead of letting our software iterate over all these things correctly and combine correctly; this iteration and combination is already done and present into EQArray('__','__','__','__','__')