2.08 and Incompatible Battle Reports

[Peter Ebbesen]

Originally posted by alexti:

code:

---

  if (x + 2d6 < y + 2d6)

---

To eliminate this problem you could make the function:

code:

---

  int random_compare(int x, int y, int nx, int ny)

  {

    int x1 = x + nx*illwinter_dice();

    int y1 = y + ny*illwinter_dice();

    return (x1 - y1);

  }

---

and use comparison

code:

---

  if (0 > random_compare(x,y,2,2))

---

A nice idea, though it fails in the execution. 2d6 is not shorthand for two times the result of a d6, but for the openended result of rolling 2 d6'es (openended: sixes are rerolled and added potentially ad infinitum

Easy enough to modify, of course, though it makes for ugly code and only deals with inequalities. The order of evaluation problem can occur anywhere where two random calls are used within the same expression.

[General Tacticus]

How about :

a = 2d6;
b = 2d6;
if ( x + a < y + b ) ...

Don't tell me there's a compiler around daft enough to evaluate b before a in this case !

[Arryn]

Originally posted by General Tacticus:
How about :

a = 2d6;
b = 2d6;
if ( x + a < y + b ) ...

Don't tell me there's a compiler around daft enough to evaluate b before a in this case !

This should work just fine, under normal conditions.

EDIT: caveat: it actually is possible to force the compilers I've used into screwing this up. It involves tweaking settings so the compiler re-orders the statements so that it reads ...

b = a = 2d6

Which, of course, looks the same as your example to anyone who's not a gamer or mathematician. We know that 2 calls to "d6" do not necessarily return the same answer.

[ February 26, 2004, 09:01: Message edited by: Arryn ]

[General Tacticus]

Originally posted by Arryn:


EDIT: caveat: it actually is possible to force the compilers I've used into screwing this up. It involves tweaking settings so the compiler re-orders the statements so that it reads ...

b = a = 2d6

Which, of course, looks the same as your example to anyone who's not a gamer or mathematician. We know that 2 calls to "d6" do not necessarily return the same answer.

And you can also make them believe that '<' means '>', or for that matter that "=" in the code means 'print("I'm a genius")' . But we are here to help compilers do the right thing, not to screw their settings and help them be total idiots

[Arryn]

Originally posted by General Tacticus:
... and help them be total idiots

This is just too good to resist: as opposed to what they would otherwise be? (less-than-total idiots)

[Johan K]

Originally posted by General Tacticus:
How about :

a = 2d6;
b = 2d6;
if ( x + a < y + b ) ...

That's the one that is used now. Easy to read and it should be foolproof.

[PhilD]

Originally posted by General Tacticus:
And you can also make them believe that '<' means '>', or for that matter that "=" in the code means 'print("I'm a genius")' . But we are here to help compilers do the right thing, not to screw their settings and help them be total idiots

You've obviously never had to work on optimizing a compiler... (neither have I, but I do occasionally teach some programming)

Warning: Tech speak coming up. If you're only into computer games and not programming, maybe you should skip this. Well, maybe you should skip the whole thread, apart from the "we found the bug and it will be corrected in the next patch" bit.

If your function calls are guaranteed to not have any side effects, the rearrangement Arryn "suggested" is actually a good move; it makes the compiled program faster by saving a (potentially costly) function call. This is a case of the compiler "helping" a sloppy programmer (and all programmers are sloppy).

Of course, if your function call has a side effect, it's a very bad move because one call will not have the same side effect as two calls. In this case, calling the dice-rolling function has a side effect, since it modifies the state of the random generator, so it's pretty important.

I don't know enough of the C specification to say whether there's a keyword to let the compiler know that a given function call is guaranteed to not have any side effects, but I suppose some compilers can be tweaked to assume that they are...

[And I don't even know whether "side effect" is the correct English translation for the French "effet de bord"; all my teaching is done in French, I admit...]