Best (CD Bootable?) Linux Distro for Dominions?

[Cainehill]

Originally posted by Gandalf Parker:
It was something about the windows compiler not doing math formulas in quite the same order as generic open OS compilers.

Which is of course why (in C/C++ especially) explicit grouping (via parenthesises) is your friend. Makes it easier for the human programmer to know exactly what the code is going to do, and makes it harder for evil compilers to find wriggle room to twist the programmer's intent.

[alexti]

Originally posted by Cainehill:

quote:

---

Originally posted by Gandalf Parker:
It was something about the windows compiler not doing math formulas in quite the same order as generic open OS compilers.

Which is of course why (in C/C++ especially) explicit grouping (via parenthesises) is your friend. Makes it easier for the human programmer to know exactly what the code is going to do, and makes it harder for evil compilers to find wriggle room to twist the programmer's intent.

---

I'm curious. Is it possible to fix Johan's problem with just grouping by parenthesises? How would you rewrite the expression for that?

[Cainehill]

[quote] alexti:
[QB]I'm curious. Is it possible to fix Johan's problem with just grouping by parenthesises? How would you rewrite the expression for that? [\qb]

Well, if "It was something about the windows compiler not doing math formulas in quite the same order as generic open OS compilers" then odds are that the use of parathensises, and breaking the formula down into discrete lines of code, would take care of it.

Hard to say how to rewrite the expression without seeing the source code and expression, but the complex multiline statements often used to express formulas are a common source of problems. The C++ standard left a few too many things (like order of evaluation) undefined, meaning that even on the same platform, different compilers give different results. This is even without accounting for compiler inadequacies, where there is currently only one (Comeau / EDG) available that is approximately 100% compliant with the standard. (Last I knew, Comeau didn't support "export" on templates, but then, no one does.)

Another likely culprit, though, would be automatic promotion of floats to doubles - different compilers handle it differently, leading to some wildly disparate results. Again, often best handled through explicit casting, and breaking long statements into short ones, such that intermediate results aren't left to compiler whims.

Anyways - use of parenthesises, and breaking complex lines of code (especially calculation heavy code) down into shorter, simpler, statements makes multiplatform life _much_ easier.

Cainehill (whose Last job involved a lot of graphics, GUIs, and modeling & simulation with the same source on different hardware platforms and OSs)

[Graeme Dice]

Originally posted by Cainehill:
Well, if "It was something about the windows compiler not doing math formulas in quite the same order as generic open OS compilers" then odds are that the use of parathensises, and breaking the formula down into discrete lines of code, would take care of it.

Discrete lines can do it. Parentheses can't. The problem, from what we've been told, was that:
random1().LT.random2();//Let's mix FORTRAN and C because of the HTML rules on the board!

Was evaluated in the opposite order under VC++ (right to left) than GCC (left to right). That kind of statement appeared in the MR checking code, so as soon as a MR check happened, the whole rest of the battle was out of whack.

[alexti]

Originally posted by Cainehill:
Hard to say how to rewrite the expression without seeing the source code and expression

Johan has posted the code that was causing problems. It was like that:

code:

---

  if (n + d6() < m + d6())

---

and different compilers evaluated left and right subexpressions in a different order.

There was some thread a while ago, where programming contest was suggested. Now we have a good problem:

- how to make the expression produce consistent results (independent on compiler), according to the specified order of function d6 invocation (from left to right or from right to left)?
- can it be done without modifying the expression?

[alexti]

Hmm... after thinking a bit, I believe the following will do:

code:

---

class d6 {

public:

	static bool left_to_right;

	static int next_id;

	int id;

	int value;

	bool is_random;



	d6() { id = next_id++; value = 0; is_random = true; }

	d6(const d6& y) { *this = y; }



	int realize() const

	{

		if (is_random)

			return value + original_d6();

		return value;

	}



	bool operator<(const d6& y) const

	{

		int x1, y1;

		if ((id < y.id) == left_to_right)

		{

			x1 = realize();

			y1 = y.realize();

		}

		else

		{

			y1 = y.realize();

			x1 = realize();

		}



		return (x1 < y1);

	}

};



int d6::next_id = 0;

bool d6::left_to_right = true;



d6 operator+(int x, const d6& y)

{

	d6 result(y);

	result.value += x;

	return result;

}



d6 operator+(const d6& y, int x)

{

	return x + y;

}

---

Not that I'm recommending it though

[Cainehill]

Originally posted by alexti:

quote:

---

Originally posted by Cainehill:
Hard to say how to rewrite the expression without seeing the source code and expression

Johan has posted the code that was causing problems. It was like that:

code:

---

  if (n + d6() < m + d6())

---

and different compilers evaluated left and right subexpressions in a different order.

---

Ah - Graeme is right, parenthesis's wouldn't do it, but it wouldn't be 100% necessary to use discrete lines of code either:

code:

---

  if ((int left = n + d6()) && (int right = m + d6()) && (left < right))

---

Still not pretty, but each '&&' introduces a sequence point, and the short-circuit boolean rules means that the ones to the right are only executed if the previous one was true. Presuming that d6() returns a value between 1 and 6 (and that n and m are unsigned or otherwise always non-negative values), the first two are true, and the final, real, test is whether left is less than right.

Somewhat ugly, but not as counter-intuitive as using non-stochastic dice rolls.

[ March 27, 2004, 13:54: Message edited by: Cainehill ]