In that case you don't even 2 procs/operators that do the same thing, they're different. One is checking if a proc call returns a true value, and other is checking if a proc call returns 1. I'd say the prob() one would be slightly faster, since it does the former-method's checking internally and therefore faster, but it doesn't really matter much and if it interests you, actually check with method is faster. :P
That wouldn't be an accurate test of efficiency, as it would depend on the random result of each procedure. You want to discard the random number -- your only concern is how much CPU time the random number generator takes in each case, not the numbers you obtain from it.
Which one is faster? What other times would two procs that do the same thing, be faster than the other?
its hard to say with built-in procs because how they really work is unknown to most people. however, with procs this straightforward i'd assume that the difference in speed is very small. the execution time for these two statements is said to be constant, because the time they take (on average) is some constant amount of time. the execution time depends on nothing else aside from your machine's ability to process the instructions.
here's an example where one bit of code is (rather obviously) faster than the other. to check which weapon a player has equipped, consider the following methods:
mob proc get_weapon() for(var/obj/weapon/w in src) if(w.equipped) return w
mob var obj/weapon/weapon proc equip_weapon(w) src.weapon = w get_weapon() return src.weapon
the first method depends on how many items you have. the more items you have, the more items you may have to check before you find the item that is equipped. the second method keeps a reference so you can always reference the equipped item right away. the first method is said to take linear time, because the execution time depends on one thing (the number of items you have) and the time grows linearly (as in, it could be expressed in the form of y = mx + b where y is the average time and x is the number of items you have). the second method takes constant time because the time it takes to reference the variable does not depend on any other factors. by storing the object reference in mob.weapon, you can access the variable just as quickly whether you have 10 items or 10,000 items.
we're only concerned with the speed of the if statement here, so it doesn't matter how likely it is that the expression is true. if we were talking about the speed of the entire function, then it would depend on how likely the if statement is true and what the code inside the if block is.
is 2 + 3 faster than 17 + 89 because the numbers are smaller? computers are good at computation, and they don't get scared of big numbers or having to carry.
#10 Feb 10 2007, 6:09 pm (Edited on Feb 10 2007, 8:28 pm)
Rand(randlow,randhigh) is:
num = SystemTime % ((randhigh-randlow)+1)
num += randlow
return num
Prob(randchance) is:
num = SystemTime % 100
num += 1
if(num <= randchance) return 1
Based on that I'd say it makes no damn difference. Or at least so small that it's not worth considering unless you plan to run this game on a typewriter.
EDIT: BYOND doesn't literally do it like this, but it this illustrates the difference between to the two commands. IE they are both just slightly different variations of what is essentially the same random number generator.
#11 Feb 10 2007, 6:52 pm (Edited on Feb 10 2007, 7:10 pm)
For some reason I really don't think you know this for a fact.
[Edit]
Yea, definitely. The way you have probability set up returns the same value for 50 for an extendning period of time, while the built-in one is fairly random in the way it works. Random is fine, though.
[Edit #2]
Scratch what I said about random. It has a pattern.
#12 Feb 10 2007, 8:16 pm (Edited on Feb 10 2007, 8:25 pm)
Actually you're right, they don't literally do it like that, but it illustrates the difference between the two commands. If "SystemTime % number" was to be replaced with a more complex algorithm the difference in time between the two commands would be still be the same.
Scratch what I said about random. It has a pattern.
All pseudo-random number generators have a pattern. Some, like the Mersenne Twister, just have exorbitantly long ones (2^219937 - 1). Of course, Mersenne has its own problems: each 32-bit Mersenne generator requires 2,496 bytes of memory (double that for a 64-bit generator), so you can't just have a Mersenne Twister generator get created and discarded whenever you need a small sequence of random numbers -- rather, the Mersenne generator has to be seeded at program startup and kept in memory from that point on.
using some sort of timer to generate random numbers would only have that pattern if you're calling it at regular intervals. the odds of calling it every millisecond, or every clock cycle, are slim.
even if there is a pattern it can be hard to tell. suppose in a game all players attacks have an 80% chance to hit. if there is a pattern it may happen that, if the only random numbers that are generated are for attacks, that every fifth attack misses. however, random numbers are being generated for all things and all players. the pattern may never be seen because while it exists, no player is seeing all of the numbers that are being generated.
it depends on the game, but, you could use the same method of [link] but replace SystemTime with an incremented count and most people would never notice.
also, the point was that no matter how the two functions work, they are almost identical. the bulk of each function is generating a random number, which is theoretically done the same way in each.
Scratch what I said about random. It has a pattern.
Well, yeah, but that's not the point of the example. Replace SystemTime with RandomNumberGenerator(SystemTime) and it'll be more technically accurate. There, happy now? =)
Which will still have a certain pattern, no matter what kind of random number generator it is. Unless it's a hardware-based one, however those are infeasible for proper use in programs anyway. :P
Yes. But for most uses (and especially for game programming), nobody cares.
i heard a story of a teacher that gave an assignment where all you had to do is flip a coin 200 times and write down all the outcomes. 200 coin flips is a lot, so most people didn't do it and just wrote down "heads, tails, heads, etc." 200 times. the teacher could tell who actually flipped a coin and who wrote down fake results. to try to make their fake results appear random, people would avoid having strings of 4 or 5 of the same result. but really, in 200 coin flips is very common to have strings of 4 or 5 of the same result in a row.
there was a point to that story. people may perceive something as being random when it isn't, and they may think that isn't random when it really is. players in games will always find a bias. if your attacks have a 90% chance to hit and you miss four times in a row, that's entirely possible with a random number generator but people won't like it. i believe it was city of heroes that had a system to try to balance out things like that, so that you'd miss 10% of your attacks, but never too many in a row. once players found out about how that worked, instead of blaming their misses on the RNG they blamed it on that balancing system.
