In another thread, Tim gave an example of an XG error that XG makes in
a particular position (probably class of position) intermittently.
However, the bug affects XG's evaluations only, not its play.

As a python coder (among other things), I found another example of unpredictable behaviour. This behaviour changed between runs of exactly
the same codebase on exactly the same machine.

What the code does (as part of a test) is to take the mean of several
instances of 0.1. Sometimes, it correctly calculates the mean to be 0.1 but sometimes it calculates the mean to be (approx) 0.1 - 1e-17 (in other words
0.0999999999.....(I'm too lazy to count out all the 9s.))

So, at least in python, we can get undefined behaviour very readily with
very simple examples.
I very much doubt that this would happen in C++ where arithmetic
processes are much better documented and standardised.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/13/2022 5:51 AM, peps...@gmail.com wrote:

In another thread, Tim gave an example of an XG error that XG makes in
a particular position (probably class of position) intermittently.
However, the bug affects XG's evaluations only, not its play.

I don't actually know that the bug does not affect its play, although
it's true that I don't have any examples.

What the code does (as part of a test) is to take the mean of several instances of 0.1. Sometimes, it correctly calculates the mean to be 0.1 but sometimes it calculates the mean to be (approx) 0.1 - 1e-17 (in other words
0.0999999999.....(I'm too lazy to count out all the 9s.))

So, at least in python, we can get undefined behaviour very readily with
very simple examples.
I very much doubt that this would happen in C++ where arithmetic
processes are much better documented and standardised.

Part of the problem lies not with Python or C++ but with the IEEE
floating point standard itself, which does not completely specify
everything.

---
Tim Chow

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/13/2022 8:35 AM, Timothy Chow wrote:

On 9/13/2022 5:51 AM, peps...@gmail.com wrote:

What the code does (as part of a test) is to take the mean of several
instances of 0.1.  Sometimes, it correctly calculates the mean to be
0.1 but sometimes it calculates the mean to be (approx) 0.1 - 1e-17
(in other words
0.0999999999.....(I'm too lazy to count out all the 9s.))

So, at least in python, we can get undefined behaviour very readily with
very simple examples.
I very much doubt that this would happen in C++ where arithmetic
processes are much better documented and standardised.

Part of the problem lies not with Python or C++ but with the IEEE
floating point standard itself, which does not completely specify
everything.

My understanding is that in C and C++, even if you've declared the
datatypes as floating point, if all the operands are integer values it
uses the algorithm for integer arithmetic instead of floating point
(with all the issues you have to deal with when using a finite model of
the real numbers).

Been a long time since I did anything in either language, and my memory
may be faulty. Not sure about Python since I never did anything serious
with it where I needed to worry about such things.

--
Ah....Clem
The future is fun, the future is fair.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, September 13, 2022 at 3:01:00 PM UTC+1, ah....Clem wrote:
...

My understanding is that in C and C++, even if you've declared the
datatypes as floating point, if all the operands are integer values it
uses the algorithm for integer arithmetic instead of floating point
(with all the issues you have to deal with when using a finite model of
the real numbers).

....
This seems unlikely. Because it means that if you write double x = 5.0000000; double y = 6.000000000;

double z = x + y;

Then the underlying compiler code would need to say ["If x has an integer value then..."]
The compiler would then have to check that 5.000000000 == 5 and that doesn't sound at all C++-like,
as the philosophy of C++ is very much to avoid unnecessary checking.

However, it's entirely possible that the (fully legal C++ code) :
double x = 5;
double y = 6;
double z = x + y;

operates in the way you said. No reason that the compiler can't check that there is no dot in the expression for
the double and then treat it as an integer.
If you don't like this, write double x = 5.0 instead.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On September 13, 2022 at 6:35:19 AM UTC-6, Tim Chow wrote:

On 9/13/2022 5:51 AM, peps...@gmail.com wrote:

In another thread, Tim gave an example of an XG error
that XG makes in a particular position (probably class
of position) intermittently. However, the bug affects
XG's evaluations only, not its play.

I don't actually know that the bug does not affect its play,
although it's true that I don't have any examples.

Have you found enough similar examples to justify his
saying a "class" (possibly many "classes") of positions?

And what about "intermittently"? Have you checked to
see if it's "consistent" rather than "intermittent"? (which
wouldn't take only a minimal effort)

I very much doubt that this would happen in C++ where
arithmetic processes are much better documented and
standardised.

Part of the problem lies not with Python or C++ but with
the IEEE floating point standard itself, which does not
completely specify everything.

XG was developed (or rather "translated into"??) Delphi. So,
definitely not related to languages nor even IEEE standards.

Some decimal numbers can't be represented in any finite
amount of bits. Thus, some precision loss is inevitable in
any hardware/software platform. But I thought you would
all know that already. Besides, calculating equities to only
4 or 6 decimal digits shouldn't suffer from this problem. I
wonder what I may be missing in this conversation..?

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On September 13, 2022 at 3:51:47 AM UTC-6, peps...@gmail.com wrote:

As a python coder (among other things), I found .....
What the code does (as part of a test) is to take the
mean of several instances of 0.1. Sometimes, it
correctly calculates the mean to be 0.1 but sometimes
it calculates the mean to be (approx) 0.1 - 1e-17

I would like to watch you discuss this in a Python forum... ;)

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/13/2022 3:57 PM, MK wrote:

On September 13, 2022 at 6:35:19 AM UTC-6, Tim Chow wrote:

On 9/13/2022 5:51 AM, peps...@gmail.com wrote:

In another thread, Tim gave an example of an XG error
that XG makes in a particular position (probably class
of position) intermittently. However, the bug affects
XG's evaluations only, not its play.

I don't actually know that the bug does not affect its play,
although it's true that I don't have any examples.

Have you found enough similar examples to justify his
saying a "class" (possibly many "classes") of positions?

What I can say is that this sort of thing has happened to me
a number of times when I have clicked "Analyze Session" after
just concluding a 7-point match against XG. That is, some
move will be evaluated in some bizarre manner. I haven't
kept track, but I'd guess that I've noticed it happening maybe
1 out of every 500 matches or so.

I haven't noticed any particular pattern to the specific
positions or decisions that get bizarrely evaluated, though.

And what about "intermittently"? Have you checked to
see if it's "consistent" rather than "intermittent"? (which
wouldn't take only a minimal effort)

Yes, when I try re-evaluating, the anomaly goes away. At least,
every time that I've tried.

---
Tim Chow

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)