Jump to content

SDI still not working as intended


Viluin
 Share

Recommended Posts

[quote name='Locke' timestamp='1308003799' post='2730776']
Random number generators aren't random, they're pseudo-random. It's not so much a bug as the limitations of what computers can do.
[/quote]


read the original topic next time

My collection of data shows that it blocks 50.4% of the attacks, allthough its not as huge as other collections people have shown, its ANOTHER proof of a faulty system.

Edited by oinkoink12
Link to comment
Share on other sites

[quote name='oinkoink12' timestamp='1308004671' post='2730782']
read the original topic next time

My collection of data shows that it blocks 50.4% of the attacks, allthough its not as huge as other collections people have shown, its ANOTHER proof of a faulty system.
[/quote]
And that is an explanation for faultiness. If it's not giving the proper random results, that is because it...wait for it...isn't random, and it is physically impossible for it to be [i]truly[/i] random. It should be closer than that, but it's likely not at all an issue with the code (I highly doubt such a large bug would have gone on unfixed all this time) and just with whatever library the language admin used to make the game uses. Unless you want him to teach computers to think randomly there's probably no fixing it. [url="http://www.random.org/"]True random generators exist[/url], but he would need to overhaul his entire implementation in a way that may not even be possible in his chosen language (ASP.NET, I believe).

Link to comment
Share on other sites

[quote name='Locke' timestamp='1308020801' post='2730894']
And that is an explanation for faultiness. If it's not giving the proper random results, that is because it...wait for it...isn't random, and it is physically impossible for it to be [i]truly[/i] random. It should be closer than that, but it's likely not at all an issue with the code (I highly doubt such a large bug would have gone on unfixed all this time) and just with whatever library the language admin used to make the game uses. Unless you want him to teach computers to think randomly there's probably no fixing it. [url="http://www.random.org/"]True random generators exist[/url], but he would need to overhaul his entire implementation in a way that may not even be possible in his chosen language (ASP.NET, I believe).
[/quote]

I feel that you may be misinformed here, or meaning to say something different.

Just because a computer's random number generator is only pseudo-random does not mean that it should not average out at the expected value after several thousand generations. The issue here is not likely to be due to random number generators not being random; because they are 'random' (try a test in Excel, averaging 10,000 random numbers between a range and note the deviation from the expected result; then run the test again, by pressing F9, and again, and again...).

From what's being said, an implemented 50/50 split as opposed to 60/40 seems highly likely (if the statistics focus on SDI usage), given the large input data.

Link to comment
Share on other sites

[quote name='dealmaster13' timestamp='1308044743' post='2731053']
I feel that you may be misinformed here, or meaning to say something different.

Just because a computer's random number generator is only pseudo-random does not mean that it should not average out at the expected value after several thousand generations. The issue here is not likely to be due to random number generators not being random; because they are 'random' (try a test in Excel, averaging 10,000 random numbers between a range and note the deviation from the expected result; then run the test again, by pressing F9, and again, and again...).

From what's being said, an implemented 50/50 split as opposed to 60/40 seems highly likely (if the statistics focus on SDI usage), given the large input data.
[/quote]
As I said (hence "It should be closer than that"), it shouldn't be that large a difference, however just because it is does not mean that it isn't the cause; I would consider it more likely than a bug that has gone unnoticed and unfixed since it was last brought up. I like to assume the the programmers who make these games aren't idiots and thus assume the most difficult and hard to fix problem, as the easier ones would have been handled.

Link to comment
Share on other sites

It seems to either block none or several in a row for me. I rarely ever get 1 or 2 thwarted, it's more like 4-5 thwarted in a row and then it gets a direct hit. I think the issue hasn't really been that it's a bug per se (~52% when it should be 60% is not so bad), but that the patterns are a little funny. Some alliances try to manipulate the patterns by putting a one shot one kill policy and such, which might get slightly more nukes in than you'd statistically get with a poor random generator.

Edited by MrMuz
Link to comment
Share on other sites

[quote name='admin' timestamp='1308091652' post='2731453']
Checked the code today and everything looks good from what I can see. The split is 60/40. That doesn't mean that it will always be 60/40, since it is random.
[/quote]

Lol, there is no way it's going to be 50/50 spot on over many thousands of nuclear attacks when it should be almost 60/40, with every single alliance in the game thwarting significantly less than expected. Something is messed up somewhere.


[quote name='Locke' timestamp='1308020801' post='2730894']
And that is an explanation for faultiness. If it's not giving the proper random results, that is because it...wait for it...isn't random, and it is physically impossible for it to be [i]truly[/i] random. It should be closer than that, but it's likely not at all an issue with the code (I highly doubt such a large bug would have gone on unfixed all this time) and just with whatever library the language admin used to make the game uses. Unless you want him to teach computers to think randomly there's probably no fixing it. [url="http://www.random.org/"]True random generators exist[/url], but he would need to overhaul his entire implementation in a way that may not even be possible in his chosen language (ASP.NET, I believe).
[/quote]

Pseudorandom number generators may not be truly random, but they do produce the right results. If I write a 60/40 RNG then I can guarantee you it will spit out numbers at almost exactly that rate over a decent sample. Whether or not it's truly random only refers to the way each number is generated and whether or not it can be predicted, not the distribution of the results.

Edited by Viluin
Link to comment
Share on other sites

[quote name='admin' timestamp='1308091652' post='2731453']
Checked the code today and everything looks good from what I can see. The split is 60/40. That doesn't mean that it will always be 60/40, since it is random.
[/quote]
Based on analysis of tens of thousands of nuclear attacks, the ratio is always within a percentage point of being a 50/50 split. With the samples sizes given, this would be akin flipping a coin 100 times and always getting heads. Yes, it's [I]technically[/I] possible, but the likelihood of it being chance becomes vanishingly small. Something is either overwriting the 60/40 percentage with a 50/50 one, there is a bug causing thwarted attacks to be underreported by exactly 1/3 or there is a significant flaw in the underlying random number generator that is being used.

Link to comment
Share on other sites

[quote name='Delta1212' timestamp='1308194697' post='2732205']
Based on analysis of tens of thousands of nuclear attacks, the ratio is always within a percentage point of being a 50/50 split. With the samples sizes given, this would be akin flipping a coin 100 times and always getting heads. Yes, it's [I]technically[/I] possible, but the likelihood of it being chance becomes vanishingly small. Something is either overwriting the 60/40 percentage with a 50/50 one, there is a bug causing thwarted attacks to be underreported by exactly 1/3 or there is a significant flaw in the underlying random number generator that is being used.
[/quote]
Or the way we're using the tests to prove that the SDI block rate is not 60% has assumptions that don't necessarily hold in the situation we're testing, but we assume it does.

Either that or I think the independence issue brought up in the other thread more or less by Typoninja has an greater influence over the results (even if some of us are thinking it doesn't).

It's going to be skewed towards a lower block rate in my opinion because people generally don't care how many nukes it takes to get a hit as long as one hits and I don't think the numbers average out between the people that get a successful nuke hit with few nukes and those that takes a lot of nukes to get 1 hit. I'm not sure how to prove it though....

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...