November Vintage in Berkley, CA - Dredgedredgedredge
@rikter Lesbimagical and I are running simulations, which if run enough times become the same as the exact computation thanks to the Central Limit Theorem (CLT).
Simulations are commonly used machine learning and statistical techniques for problem solving. The combinatorics (hypergeometric and binomial) is a mathematics/probability concept where they are getting the exact value. The reason the latter is not used in a number of situations is because of the complexity of many problems, it is much easier to solve by leaning on the CLT.
@vaughnbros I was about to post that my best guess as to what you were doing was just a simple If no bazaar, mull. If powder and no bazaar, powder, continue until either bazaar or 1 non serum powder. Do it 10 million times and you catch it all. Is this correct? My instinct is always to do direct calcs, but this is a situation where that is cumbersome.
Just curious, what is your number on p (bazaar)? I come up with .875, but thats a simplified number that doesnt consider powder. It also includes the chance that its your top card.
My powder logic is exact; since it simulates the actual deck, if I draw a hand with 4 powders, it removes all of them for the redraw. p(Bazaar) w/Powder, not considering top card or scry, is 94.7% in my runs.
@vaughnbros yessssss, playing against hate is an excellent thing to add. I'm trying to focus right now on the validity of leaving out Dread Return + answering the FKZ v Dragonlord question.
@Lesbimagical I prefer DLK to FKZ as an out to Moat, a lack card for ichorid/unmask etc. Im probably not going to run a haste guy in the future, considering just ashen rider and elesh norn
@rikter It's 94.7% before scry as mentioned by Lesbimagical.
I have to look at my code again for the % off of scry, it's something like 2% though so it has minimal effect on the overall percentage.
@rikter Its not a decision tree. Its just a simulation that says:
- If Bazaar stop else
- If Powder then exile hand draw that many else
- Repeat from 1 until 1 card left in hand.
- Scry/Draw top cards until you find Bazaar or hit 8 cards in hand for slow dredge.
From there then you can add logic like:
- Draw 2, discard 3.
- Dredge 2 different cards.
- Dredge 1 card.
- Repeat from 2.
To finish dredging your deck.
You run these loops 10 million times, or something like that for the Central Limit theorem to kick in and give you an accurate estimate. (each loop is the equivalent of 1 hand in real life so the efficiency compared to self experience is insane.)
You can also query your hands for the probability of having blue card + force, leylines, and other important starting hand cards.
@rikter the "i prefer" in this post is the reason for the sim - this is a solvable problem, but all of the Dredge talk is based on preferences haha
I've got some decision logic going where when you dredge it decides what to dredge (preferencing highest #, it isn't very smart yet). Similar with Ichorid triggers, but I'd like it to be smart about triggering Ichorid.
Adding Amalgam in is going to be >.<
@Lesbimagical Yeah I can see that. Im guessing this is because you want to calculate avg turns to win in a goldfish scenario? Maybe you program those decisions by running a little subroutine that runs through the permutations a million times and picks the one that generates the highest average power on board? You could also add another layer that uses the most mana, because in game 1 when I dont need to hold cards to pitch to bazaar when I dig for an answer, I start hardcasting narcos and such if I have mana.
Preferencing highest # bc that's just generally how it works, particularly g1.
I don't think I care about hardcasting creatures, really, that to me is just not a common enough occurrence to account for. I imagine eventually it could account for mana in a g2/3 scenario, for Depths / Stage. Honestly I'm not super invested in this haha, I write code 40+ hours a week so writing more when I get home is rarely what I want to do.