2.08 and Incompatible Battle Reports

[alexti]

Originally posted by Johan K:

quote:

---

Originally posted by Pocus:
I have often battle inconstancies message now, with solo play on windows platform.

Bah, can't you let me be happy for more than 1 hour and 13 minutes.

---

To Johan K:

I guess you have few more places when the comparison looks like

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))

---

Finding all the places where the dice function is used and replacing it with the new comparison is not difficult, but the problem is that if you make a small cut-and-paste mistake somewhere, how do you find it?

I can think only about one method to ensure that everything is changed correctly. If you can save battle progress status on disk after every round, you can make "etalon" saves on the current Version and rerun the test on a modified Version, comparing battle status after every turn. If there's a difference you'd be able to go through debugger to find out where it comes from. (In the example I've given you'd have to run on Linux, so that the original evaluation order matches the one implemented in a new function). The drawback is that some obscure conditions may not get tested at all.

Alternative method is to write a program which will automatically do conVersion

Either way it doesn't look like an easy fix :-(
But I still hope that you don't have that many places where dice function is called more than once in the expression, so that those can be examined manually

[alexti]

Originally posted by Arryn:
Alexti, your examples are not the same. In the first example: 1) they have void returns and invoke I/O, which the optimizer treats differently.

How the optimizer would know about IO? printf is just some function residing in some library to which optimizer had no access. It only can see the header, where there's nothing that says that the function contains IO.

2) the statements are on separate lines, and IIRC there are various scoping rules to what the compiler will attempt to "consolidate" when it goes to generate machine code.

Some Languages consider line feeds as a language element, but not C/C++.

code:

---

  f(); f();

---

and

code:

---

  f();

  f();

---

are the same thing.

However, the most obvious thing you said that bears careful review is the statement "... it's safe to assume ...". It's never safe to assume anything. That's the first step towards making mistakes ...

You have to assume that the compiler works correctly (according to the standard) until proven otherwise, how are going to write any code otherwise?

Consider the following:

code:

---

  int a = 1;

  foo(a);

---

What if the compiler generate wrong code for assignement? Ok, here is an improvement:

code:

---

  int a = 1;

  if (a != 1)

    ERROR("!!!");

  foo(a);

---

But what if the code for comparison is wrong too? No problems:

code:

---

  int a = 1;

  if (a != 1 || (a-1))

    ERROR("!!!");

  foo(a);

---

But what if operator or (||) produces wrong code too?

Well, it's clear where it's going...

[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)