[siriusmd99]

If you don't need 10 and 11 then you can skip them by understanding as 12 and 13 which are 10+2 and 11 + 2
So just do this:

iNum = random_num(1,12)
if(iNum >= 10) iNum+=2;

This way 10 will be 12, 11 will be 13 and 12 will become 14.

[TheWhitesmith]

Originally Posted by siriusmd99 If you don't need 10 and 11 then you can skip them by understanding as 12 and 13 which are 10+2 and 11 + 2 So just do this: iNum = random_num(1,12) if(iNum >= 10) iNum+=2; This way 10 will be 12, 11 will be 13 and 12 will become 14.

Originally Posted by PRoSToTeM@ new num = random_num(1, 14 - 2); /*if (num >= 10) {     ++num;     if (num >= 11) {         ++num;     } }*/ if (num >= 10) {     num += 2; }

[TheWhitesmith]

For now fysiks's idea is the best for a small amount of numbers, for bigger I would suggest PRoSToTeM@'s

[fysiks]

Originally Posted by KiLLeR. I thought that the idea for 'while loops' are to use em, when you don't know how many times they gonna be executed?!?

When you use while loops, you need to know that the number of iterations is bounded, you don't necessarily need to know the exact number. For example, when reading the lines of a file, you know that the number of lines is bounded because you can't have an infinite length file.

Originally Posted by TheWhitesmith For now fysiks's idea is the best for a small amount of numbers, for bigger I would suggest PRoSToTeM@'s

No, actually that is wrong. My method is actually the best overall regardless of the size of the number set. PRoSToTeM's method is neat but it's not scalable. It become increasingly complicated as you add discontinuous exclusions. See my explanation and example here.

My method is equivalent to a lookup table often used in embedded code because it's best for speed of execution.

[PRoSToTeM@]

Originally Posted by fysiks So, what if you need to exclude 3, 8, 9, 15, 21, and 26? (Rhetorical Question) It's not scalable code. So, if you go with a more scalable solution now, then you wont' have to rewrite the [functional part of the] code in the future when you add more exclusions.

It can be rewrited for dynamic sets. Like this (it is O(N)):

new const sortedExcludedNumbers[] = {1, 3, 4, 5, 19, 30, 31, 150};
new generatedNumber = random_num(0, 999);
for (new i = 0; i < sizeof(sortedExcludedNumbers); ++i) {
  if (generatedNumber < sortedExcludedNumbers[i]) {
    break;
  }
  
  ++generatedNumber;
}

Originally Posted by fysiks No, actually that is wrong. My method is actually the best overall regardless of the size of the number set. PRoSToTeM's method is neat but it's not scalable. It become increasingly complicated as you add discontinuous exclusions. See my explanation and example here. My method is equivalent to a lookup table often used in embedded code because it's best for speed of execution.

Yes, your method is O(1). But it isn't cache-friendly for really huge sets. My methods also aren't cache-friendly, but for huge sets of exclusions.
So:
For both huge number sets and small exclusion sets my method should be better.
For both huge number sets and huge exclusion sets your method should be better.
For other your method should be better.

[aron9forever]

Originally Posted by KiLLeR. I thought that the idea for 'while loops' are to use em, when you don't know how many times they gonna be executed?!?

that's not the problem, but in cases where you use loops you need to know the time complexity of your operations (the O(n) stuff they are talking about)

for example, if while looping through all entities, you don't know how many there are, but you know it's never going to go over 512 because of game limit

similarly, where you have a number n of loops (like 512 here, 32 for players, so on) then a single loop is O(n) (at most n loops)

if it's one loop within the other (nested loops), both from 1 to n, then complexity is O(n*n) because worst case you will do n squared loops





now with the randomness, well, you don't know
theoretically speaking a true random function has a possibility to return the same value every single time
it's a tiny possibility, probably much less than winning the lottery, but the idea is the same, it CAN happen

that being said this doesn't apply here because it won't happen for long times like that just because it's not truly random and we assume there isn't a god fucking with us

it's still good to think about how efficient the code is though, and fysiks code has the best possible time, O(1) aka 1 single operation regardless of how many possibilities there are. I'm pretty sure the while loops here are all NP (you can't even predict the worst case scenario) which is pretty terrible from a theoretical programming point of view.

[PRoSToTeM@]

Originally Posted by aron9forever for example, if while looping through all entities, you don't know how many there are, but you know it's never going to go over 512 because of game limit

max entity count is 1365 for max players 32.
MaxEnts(MaxPlayers) = 900+15*(MaxPlayers - 1).