Thank you for looking into it, Rodolfo. However, I get somewhat different results if I run the first one another time after running the second one. When I do this I get the original result - 2000 (which is what I would hope).
However, I investigated further and got these results (I will note that adding PI wasn't necessary, it was just to show that there really are that many digits after the decimal point and they don't have to be zero):
[Z:\]Echo %@Eval[1E10000=10000,10000] >WithoutTimer.txt
[Z:\]Timer On & Echo %@Eval[1E10000=10000,10000] >WithTimer.txt & Timer Off
[Z:\]fc WithoutTimer.txt WithTimer.txt
Comparing files WithoutTimer.txt and WITHTIMER.TXT
Since it my not be obvious, extracting just the "difference" lines:
And there it is: two extra zeros.
And really weirdly (although it indicates that whatever is going on here is basically harmless) doing it again adding PI as in the original posting and comparing the results produces:
[Z:\]Echo %@Eval[1E10000+PI=10000,10000] >PIWithoutTimer.txt
[Z:\]Timer On & Echo %@Eval[1E10000+PI=10000,10000] >PIWithTimer.txt & Timer Off
Timer 1 on: 7:02:49
Timer 1 off: 7:02:49 Elapsed: 0:00:00.35
[Z:\]fc PIWithoutTimer.txt PIWithTimer.txt
Comparing files PIWithoutTimer.txt and PIWITHTIMER.TXT
Again highlighting the differences:
As you almost certainly can see in the above, the digits "79" are added to the result.
And if I do above again using "=40000" (the maximum value that is actually used is 10,000) I get the same results as immediately above, i.e. adding the inttial "Timer" command causes it to calculate two extra decimal digits.
And just to clarify exactly what is not as expected, the "WithoutTimer" versions have only 9,998 decimal digits meaning that they lack lack 2 decimal digits that they should have.
And to explain exactly what I was doing, Rodolfo, "@Eval" evaluates the contained expression, the "=10000,10000" indicates how many decimal places you want the result to have (10,000 obviously), and adding PI makes those extra 10,000 decimal places non-zero.