Jump to content

TheNumberPi

Members
  • Posts

    15
  • Joined

  • Last visited

Posts posted by TheNumberPi

  1. <snip>

    The starting seed and the following numbers are completely independend in any random number generator:

    from any sequence it is impossible to calculate the next number, nor the previous, unless you know exactly the whole sequence.

    The following numbers are completely determined by the starting seed. Given the seed, all subsequent numbers are predetermined. Whether it's practical to calculate the next number given previous numbers depends on the specific RNG algorithm. The output of a Mersenne twister (used in some C++ implementations) can be predicted after observing just 624 numbers. (The period is much longer). On the other hand, some cryptographically secure RNGs require computational power comparable to brute force decryption to predict. However, you still don't need the whole sequence to predict the output.

  2. The basic idea that computers can't actually generate random numbers is correct, but this doesn't mean your fate is predetermined. First, the server probably uses one RNG for everybody, rather than one RNG per character. That means what other people do and the order affects what numbers you roll. Since there are ~1000 players on any server, that means which roll of the RNG you get is effectively random due to network latency and such. If you click a few milliseconds later, you'd get a different roll. Second, when the server first boots up and creates a RNG, the seed (generally) isn't fixed. Usually it's set to something reasonably random like the time in nanoseconds. Since booting times aren't accurate to nanosecond precision, this is also pretty much random.

     

    TLDR: Even though the RNG is deterministic, other things that affect your luck are random, so your fate isn't totally predetermined.

     

    That may be, but it rises new questions.

     

    Wouldn't that mean that, for example, the 13th person to kill a TD on world 2 is guaranteed claws, or something like that?

    Nope.

    1. The initial seed is pretty much random (Java's new java.util.Random() uses the time in ms)
    2. The exact time you started killing the TD is subject to human randomness, so if someone does something requiring the RNG within that time, you get a different number.
    3. If jagex used fixed seeds and used a different RNG per monster, then you're right.
    4. Ignoring the random sequence of commands sent by players, the sequence of events would be predetermined after the seed selection.

  3. The basic idea that computers can't actually generate random numbers is correct, but this doesn't mean your fate is predetermined. First, the server probably uses one RNG for everybody, rather than one RNG per character. That means what other people do and the order affects what numbers you roll. Since there are ~1000 players on any server, that means which roll of the RNG you get is effectively random due to network latency and such. If you click a few milliseconds later, you'd get a different roll. Second, when the server first boots up and creates a RNG, the seed (generally) isn't fixed. Usually it's set to something reasonably random like the time in nanoseconds. Since booting times aren't accurate to nanosecond precision, this is also pretty much random.

     

    TLDR: Even though the RNG is deterministic, other things that affect your luck are random, so your fate isn't totally predetermined.

  4. The problem isn't the sample size - 7K is quite a large sample for statistical purposes. The margin of error is actually independent of the population size as long as the population is much larger than the sample. (see sample size on wikipedia) The problems are voluntary response bias and the sampled population. (see Response_bias on wikipedia). Tip.it's survey is likely to attract voters who feel strongly about the question, under-representing those who do not care. Also, the tip.it readers are not an accurate representation of all runescape players. (e.g. forum readers are more likely to have played longer than the average RS player).

  5. It's probably just an arbitrary programming choice

     

     

     

    IF (left key is down) THEN
    
       rotate left
    
    ELSE
    
       IF (right key is down) THEN
    
           rotate right
    
       END IF
    
    END IF

     

     

     

    So if both keys are down, it might just check for the left key and never bother checking the right key.

  6. It won't work till the make multiple games and the fact someone could get the same color over and over.

     

     

     

    Right, but you're leaving that to statistics then. It's safe to assume you will be red (and win) 1/4 of the time. Is there a more accurate assumption?

     

    The chance of being on the losing side for 100 games in a row is (3/4)^100 = 3.2*10^-13, which is practically zero. Furthermore, you'll win at least 20/100 games about 90% of the time, and at least 15/100 games about 99.5% of the time. (This is assuming that team assignments are completely random and that previous games have no effect on future games.)

  7. I'd like to see a few more trials, but I don't want to waste your time. I'm not to the hit values yet, I'm still trying to nail down the probability of a hit, based on strength, attack, and opponents defense. However, If my next few tests go as predicted, I can move on to more advanced things, such as that setup.

     

     

     

    I'm betting if you conducted the test again, you'd get different results (duh), as in different numbers receiving different proportions.

     

     

     

    Just curious, what style were you using?

     

     

     

    The low P-value (significant at the alpha = 0.01 level!) indicates that the sample size is already large enough and that the chance of getting the observed differences is low if all hits were equally likely. If I repeated the experiment and found that different numbers occurred more/less often, that would suggest that the unbalanced distribution was due to random chance alone and that either the previous P-value was a fluke or that the test assumptions were violated (namely, whether the sample can be treated as an SRS.)

     

     

     

    I was using defense mode.

  8. How many zeros did you hit?

     

    This is relevant because:

     

    -1/16 of your hits should have been naturally zero (due to the strength component)

     

    -Some (large) proportion of zeros should have been from failing attacks

     

    -If you knew the proportion of zeros you should have hit, and recorded those too, your x^2 GOF test would have different results.

     

     

     

    I'm not saying your data is invalid, or conclusion is definitely incorrect, there are just a few confounding variables that you haven't taken into account.

     

    There were 187 zeros. I excluded the zeros because it isn't possible to discern zeros due to strength from zeros due to missing. My goal was to examine the distribution of hits due to strength, so adding in the zeros would add in attack as a confounding variable. If we could discern zeros due to strength, the yes the GOF test would yield slightly different results, but I think my conclusions are still valid for the population of all nonzero hits.

  9. I just tested compfreak847's assertion that not each hit is equally likely. I found good evidence that each nonzero hit is not equally likely.

     

     

     

    My equipment/stats:

     

    70 attack, 70 strength

     

    Defense mode

     

    Rune scimitar, amulet of power, rune gauntlets, rune berserker shield

     

    Using cockroach soldiers

     

     

     

    [hide=Data]1 17

     

    2 7

     

    3 18

     

    4 9

     

    5 15

     

    6 17

     

    7 24

     

    8 14

     

    9 12

     

    10 5

     

    11 21

     

    12 14

     

    13 7

     

    14 11

     

    15 16[/hide]

     

     

     

    [hide=Stuff for statisticians]You can do a chi-square goodness of fit test to test H_0: each hit comes up with proportion 1/15 in the population of all possible hits; and H_a: at least one of the hit proportions differs from the hypothesized proportions. There is a total of 207 observations, so if H_0 is true we expect 207/15 observations per hit. The sample can be treated as an SRS, and all of the expected counts are at least 5, so the results should be good.

     

    The chi-square statistic is X^2 = sum (Observed - Expected)^2 / Expected = 29.30435.

     

    The number of degrees of freedom is 15 - 1 = 14.

     

    The P-value is Prob(Chi^2 >= 29.30435) = 0.0095027.

     

    This means that if each hit really was equally likely, the probability of getting such skewed results is only about 1 in 100.[/hide]

  10. I love how JAGeX is trying to improve F2P combat, but I don't think teleblock is going to much of a difference. First, F2P still lacks the binds or KO ability to back up the teleblock, so instead of teleporting, people will just run away to the nearest safe spot. Second, teleblock doesn't block the explorer's ring (the only ring a F2Per would ever wear).

  11. NO IT"S NOT A 3D ARRAY. Really, how stubborn can you be... JAVA ONLY SUPPORTS UP TO 2D ARRAYS! I LOOKED INTO THE WAY THE DATA IS STORED, YOU CAN SEE FROM THE LAYOUT ON YOUR PHYSICAL MEMORY THAT IT'S A 2D ARRAY! Ever heard of pointers in C-family? JAVA uses a similar technique although it's made completely transparant for the programmer. This is what makes java so easy, but also makes java terribly slow and easily "hackable"!
    Technically, Java only supports 1D arrays. Higher dimension arrays can be done as arrays of arrays. Thus, there is NO limit to the number of dimensions you can have. For example, the following code makes a 3D integer array with size 5*5*5:

     

    int[][][] stuff = new int[5][5][5];

     

    (This can be thought of as an array of 2D arrays, which in turn are arrays of 1D arrays.)

     

     

     

    Also, I don't know where you got 2D physical memory from, but again, computer memory is really just 1D. Pointers are essentially integers that refer to a certain place in memory. This is where the 4 GB memory on 32 bit systems comes from; 32 bits of data can hold at most 2^32 (4,294,967,296) different possible values.

     

     

     

    My personal opinion is that JaGEX implemented the map as a single 2D array with stairs and similar things acting as "teleports" to a separate location in the array.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.