Siege Rolls; Confirmation Bias my ARSE!!!

[Fanstar1]

Just write a small program to roll the dice 100 times and see what kind of deviations you get and see if they correlate to what you saw or now. Run it many times.

to be fair, not everyone is a programmer

 

[Kwami]

I think that logical good faith assumption here is that the dice rolls are *intended* to be fair. I kind of see that you are coming from the viewpoint that the underlying process is truly random and use results from different systems as confirmation. But the excess of '1's (which is likely means excess of zeroes in lower bits) is fairly suspicious. I would be much less suspicious of too many '14's. The underlying process is obviously non-random and programming errors disproportionally favor getting excess of zeroes, so possibility that something goes wrong on OP's system is hard to exclude.

You keep saying lower bits, but I don't think that you know what you're talking about. Every number that you can possibly roll on a siege tick fits into only four bits. All of those bits would be considered "lower bits" when discussing a 32-bit PRNG. Also, most PRNG algorithms don't suffer from a "lower bit" problem. That flaw is most often found in LCPRNGs, which EUIV doesn't use for anything. Even then, most implementations of rand() don't rely on the lower 16 or so bits for anything at all.

Since EUIV uses a Merssene Twister, none of that even matters. MTs don't suffer from a low-bit problem. They can suffer from initialization problems, but who manually initializes a MT? There's one built into the C++ standard library. I can't imagine why Paradox wouldn't just use that one. There's even a convenient way of getting a seed without doing any work (i.e. std::random_device).

 

[alexti]

You keep saying lower bits, but I don't think that you know what you're talking about. Every number that you can possibly roll on a siege tick fits into only four bits. All of those bits would be considered "lower bits" when discussing a 32-bit PRNG.

Typically people use the same PRNG for everything. For example 32-bit one for rolling numbers from 0 to 13 and then they get to the 0 to 13 range by doing modulo operation. This means that lower bits has disproportional importance on the result. It's easier to see if you roll from 0 to 15 - in this case only lower 4 bits matter and the higher 28-bits are completely irrelevant.

Also, most PRNG algorithms don't suffer from a "lower bit" problem. That flaw is most often found in LCPRNGs, which EUIV doesn't use for anything. Even then, most implementations of rand() don't rely on the lower 16 or so bits for anything at all.

Since EUIV uses a Merssene Twister, none of that even matters. MTs don't suffer from a low-bit problem. They can suffer from initialization problems, but who manually initializes a MT? There's one built into the C++ standard library. I can't imagine why Paradox wouldn't just use that one. There's even a convenient way of getting a seed without doing any work (i.e. std::random_device).

*Most* is not very useful term. Very popular LCGs do. Mersenne-Twister also has this problem in the beginning of a sequence if it is not initialized well. For most uses you are relying on *all* bits being uniformly distributed - this is a primary criterion for a quality PRNG. Keep in mind that Clausewitz existed before MT appeared in C++ standard library, so it doesn't necessarily use the best solution that is available today. Historically people initialize MT in all kind of ways. For the start, the original initialization routine by the creators of MT was flawed, when it was discovered it was updated and what is commonly used now is 3rd (or maybe 4th) iteration of bootstrapping algorithm. So depending when developers got the code (presumably from MT authors site) it might be using different initialization code. And, of course, having good bootstrapping algorithm available and actually using it is not the same thing .

 

[Råttan]

On an other note, whilst still being in line with the threads theme:

I find it disturbing that AI tends to (as I see it) rival you more likely than other AI. Not a big test, but: (all in 1.18)
10 starts as Brandenburg: Bohemia rivals me 9 times.
10 starts as Austria: Bohemia Rivals Brandenburg 2 times.

 

[Wizzington]

On an other note, whilst still being in line with the threads theme:

I find it disturbing that AI tends to (as I see it) rival you more likely than other AI. Not a big test, but: (all in 1.18)
10 starts as Brandenburg: Bohemia rivals me 9 times.
10 starts as Austria: Bohemia Rivals Brandenburg 2 times.

There is no code that makes AI rival players more often. The way starting rivals are setup can be skewed by the fact that the player picks last, but it's not inherenty for or against you.

 

[bbqftw]

if you start as Austria you remove lucky bonus from Austria which could affect some things

 

[Arunvik]

I find it disturbing that AI tends to (as I see it) rival you more likely than other AI. Not a big test, but: (all in 1.18)
10 starts as Brandenburg: Bohemia rivals me 9 times.
10 starts as Austria: Bohemia Rivals Brandenburg 2 times.

Tried the same thing:

15 starts as Brandenburg: Bohemia rivals me 7 times.
15 starts as Austria: Bohemia rivals Brandenburg 6 times.
15 starts as Bohemia: I rival Brandenburg 15 times.

The sample size is still pretty small, but I don't really see anything weird here.

 

[Ex Mudder]

I mean, if you prove that the mersienne twister is biased in such a precisely specific way that somehow it always ends up giving favorable siege rolls to the AI in Europa Universalis 4, you're probably gonna make a whole lot of people look dumb.

I don't think it's very likely though.

I have seen a bunch of unlikely RNG behaviour in Paradox games (4 spark of genius in a row in Stellaris for example). I know about confirmation bias and random doesn't mean even, and the more you play the more likely the less likely things are to happen eventually. I also know that this weird stuff usually stops happening if I save, quit, and reload the game. So when I see it, I think it is most likely something similar to the AI going to sleep. But the "doesn't persist on reload" makes it hellish to prove.

 

[Ziggy187]

#############################################
RETRACTED
#############################################

I stand corrected. The community is right, Wiz is right, I am an idiot, a goof, a moron, a freak, and I should be publicly flogged into humiliation. I am a man of my word and I retract my claim that the siege rolls are bias towards “1’s”. I completely and utterly apologize for any frustration I may have caused to those of you that were trying to tell me I was in error. If this statement satisfies the issue for you, stop reading as what follows is how I came to this enlightened conclusion, why the myth is propagated and a simple fix to reduce this perception from spreading.

Last night I got the data set I was expecting to prove me wrong. I got an overwhelming occurrence of wall breaches compared to disease outbreaks, to the tune of 3:1. Yes, my sample size WAS too small. I don’t believe there was anything wrong with the calculations I ran yesterday for the data set I had at the time. However, I believe I used poor judgement in choosing that method to analyze the data for this application. There is nothing wrong with the game or the RNG system. I will say it is random with an affinity towards being streaky, much more than I was expecting. The main issue that causes people, such as myself, to believe the system is flawed has more to do with perception than mechanics. I understand why PDX uses the term “confirmation bias” because that is exactly what is occurring.

The only way to tell what the siege roll is, is by opening the siege interface. It is very obvious when a “disease outbreak” occurs because your army receives damage. This is very noticeable since your army is the focal point during a war. Also, the fact that the siege progress stops because the attrition has dropped below the minimum army unit number required. The only way to tell if a wall breach occurs is by the tiny little icon on the castle info. It does not however show if multiple breaches have occurred. Also, this tiny icon is easily overlooked while the player is busy fighting a war. These two cases of disease outbreaks being obvious and wall breaches being subtle are the main cause for the perceived bias. However, another issue is also prevalent. The final roll that wins the siege is not known. Obviously if it’s a “1” it is known because you didn’t win the siege. If it is a wall breach you have no way of capturing that data point so the data sets get skewed slightly to show more disease outbreaks. This is especially true when a siege of 7% or 14% chance of winning actually wins. More than likely, a wall breach was rolled but not seen or noticed by the player.

The easiest fix is to make the wall breach roll more noticeable. The easiest way to do that is with a wall breach sound such as a demolition, explosion, large cannon, something discernable in the event a field battle interface is opened with its battle noise. Other ideas could be to add a small number over the wall breach to show 0, 1, 2 or 3. Also, similar to the casualties that appear during a battle, a ghost number over the castle could float up showing the siege roll. IDK, I’m just trying to help and sorry for this becoming much larger than I ever intended it to become. Sorry guys.

 

[Shock360]

#############################################
RETRACTED
#############################################

I stand corrected. The community is right, Wiz is right, I am an idiot, a goof, a moron, a freak, and I should be publicly flogged into humiliation. I am a man of my word and I retract my claim that the siege rolls are bias towards “1’s”. I completely and utterly apologize for any frustration I may have caused to those of you that were trying to tell me I was in error. If this statement satisfies the issue for you, stop reading as what follows is how I came to this enlightened conclusion, why the myth is propagated and a simple fix to reduce this perception from spreading.

Last night I got the data set I was expecting to prove me wrong. I got an overwhelming occurrence of wall breaches compared to disease outbreaks, to the tune of 3:1. Yes, my sample size WAS too small. I don’t believe there was anything wrong with the calculations I ran yesterday for the data set I had at the time. However, I believe I used poor judgement in choosing that method to analyze the data for this application. There is nothing wrong with the game or the RNG system. I will say it is random with an affinity towards being streaky, much more than I was expecting. The main issue that causes people, such as myself, to believe the system is flawed has more to do with perception than mechanics. I understand why PDX uses the term “confirmation bias” because that is exactly what is occurring.

The only way to tell what the siege roll is, is by opening the siege interface. It is very obvious when a “disease outbreak” occurs because your army receives damage. This is very noticeable since your army is the focal point during a war. Also, the fact that the siege progress stops because the attrition has dropped below the minimum army unit number required. The only way to tell if a wall breach occurs is by the tiny little icon on the castle info. It does not however show if multiple breaches have occurred. Also, this tiny icon is easily overlooked while the player is busy fighting a war. These two cases of disease outbreaks being obvious and wall breaches being subtle are the main cause for the perceived bias. However, another issue is also prevalent. The final roll that wins the siege is not known. Obviously if it’s a “1” it is known because you didn’t win the siege. If it is a wall breach you have no way of capturing that data point so the data sets get skewed slightly to show more disease outbreaks. This is especially true when a siege of 7% or 14% chance of winning actually wins. More than likely, a wall breach was rolled but not seen or noticed by the player.

The easiest fix is to make the wall breach roll more noticeable. The easiest way to do that is with a wall breach sound such as a demolition, explosion, large cannon, something discernable in the event a field battle interface is opened with its battle noise. Other ideas could be to add a small number over the wall breach to show 0, 1, 2 or 3. Also, similar to the casualties that appear during a battle, a ghost number over the castle could float up showing the siege roll. IDK, I’m just trying to help and sorry for this becoming much larger than I ever intended it to become. Sorry guys.

I'm glad you listened to reason next time just try to be more understanding from the start?

 

[Wizzington]

Anyone who can admit fault is cool in my book, so no worries. It's all good.

 

[Shock360]

Anyone who can admit fault is cool in my book, so no worries. It's all good.

Inb4 wiz was going to post to admit defeat but realized he got lucky and made this post instead

 

[Tavior]

There is no code that makes AI rival players more often. The way starting rivals are setup can be skewed by the fact that the player picks last, but it's not inherenty for or against you.

I think the perception that AI "picks the player more often than not" comes from that Player will tend do rather well in the region where they are and will usually end up with 4-5 rival or so because those extra rival don't have anyone else to pick on.

Of course that doesn't cover all fringe cases.

 

[mysticdueler]

#############################################
RETRACTED
#############################################

I stand corrected. The community is right, Wiz is right . . . I am a man of my word and I retract my claim that the siege rolls are bias towards “1’s”. I completely and utterly apologize . . .

No need to be too harsh - you've done what almost no one else on the internet could ever hope to do: admit they were wrong! Besides, there were some fun statistics shared - and who doesn't love that?!

 

[Lilje]

However, another issue is also prevalent. The final roll that wins the siege is not known. Obviously if it’s a “1” it is known because you didn’t win the siege. If it is a wall breach you have no way of capturing that data point so the data sets get skewed slightly to show more disease outbreaks. This is especially true when a siege of 7% or 14% chance of winning actually wins. More than likely, a wall breach was rolled but not seen or noticed by the player.

This was taken into account and no rolls after a positive siege % was reached was registered during my runs.

 

[MutantPenguin]

So totally aside from anything else mentioned in this thread so far, I thought they changed the way wall breaches work so that they're no longer tied to high die-rolls a few patches ago?

 

[Kultra]

So totally aside from anything else mentioned in this thread so far, I thought they changed the way wall breaches work so that they're no longer tied to high die-rolls a few patches ago?

They are still tied, its just that now you can make them a lot more common. A Breach now depends on you rolling above (14-Artillery Bonus to siege) so assuming a lvl 8 Fort, and you have 25 Artillery units on the siege, any roll above a 9 will be a Breach.

 

[Iche_Bins]

No need to be too harsh - you've done what almost no one else on the internet could ever hope to do: admit they were wrong! Besides, there were some fun statistics shared - and who doesn't love that?!

And with a reasonable tone
It was an interesting discussion to read.

 

[Philadelphus]

So totally aside from anything else mentioned in this thread so far, I thought they changed the way wall breaches work so that they're no longer tied to high die-rolls a few patches ago?

@Alsadius actually just updated the siege section of the wiki page on land warfare with a new empirically-derived formula for breaches last night.

Also, Ziggy187, no need to beat yourself up over this! I really enjoyed the discussion going on in this thread—it got me to dust off my stats knowledge from college. I think we're all a little bit more informed now, and I admire anyone with the guts to change their mind on a forum. Plus:

The easiest fix is to make the wall breach roll more noticeable. The easiest way to do that is with a wall breach sound such as a demolition, explosion, large cannon, something discernable in the event a field battle interface is opened with its battle noise. Other ideas could be to add a small number over the wall breach to show 0, 1, 2 or 3. Also, similar to the casualties that appear during a battle, a ghost number over the castle could float up showing the siege roll.

I think this is a really good idea! I like the idea of having a noticeable noise that plays when you get a breach. It might be valuable information if you're waiting to assault a fort but can't watch that particular army all the time, and it would just be nice to hear my glorious artillery blasting enemy fortifications into rubble in the background.

Come to think of it, maybe have another noise for when a disease outbreak happens. I'm sure the CK II team would be willing to lend one of their Reaper's Due sickness noises…

 

[Xinkc]

It's confirmation bias.

Hope this helps.

Helps me.