|
PureBytes Links
Trading Reference Links
|
Since there has been some question regarding the precision of
TS5, I decided to answer the following question to the list even
though it was asked of me privately.
> Chris,
>
> Can you elaborate on this? FWIW, I ran the code on my copy
> of TS5 (PR1) and got zero as well (i.e. it failed). However,
> running the old "z = x - (x/y)*y" where x = 4195835 and y =
> 3145727 also returns zero. I thought the latter was
> classified as "double precision"......at least according to
> the Pentium floating point bug documentation I read. What's
> the deal, exactly?
>
> Best regards,
> <name removed>
Single precision on the x86 allows for a 23-bit mantissa plus
a sign bit. An additional 8 bits are used as a biased exponent,
thus bringing the total width of a single precision number to
32 bits. Ignoring special cases, the mantissa normalization
rules reformulate the result so that it is of the form 1.xxxx
where "." is a binary (cf., decimal) point and "xxxx" are a
sequence of binary digits (bits). It is the first 23 bits of
the "xxxx" part that is stored in the single precision mantissa.
However, the least significant of these 23 bits are subject to
some additional complexities that I will describe in a moment.
(The astute reader may have noticed that the leading 1 is not
stored in the mantissa. It is presumed to be there, thus having
the effect of doubling the precision of the mantissa).
The numbers 4195835 and 3145727 are both representable in a 23-bit
mantissa without any loss of precision. Therefore, they are also
representable in double or extended precision. But I perform
4195835/3145727, the result does not fit into a 23-bit mantissa.
In fact, it doesn't even fit into a 64-bit mantissa, which is the
largest that the x86 processor handles internally. So what does
the x86 processor do? That depends on the state of so-called guard
bits that are generated during the calculation plus the Rounding
Control bits and Precision Control bits in the FPU Control Word
inside the x86 processor.
So now, when I perform 4195835/3145727 * 3145727, I cannot know
what the answer is unless I know the mode that TS has set the
Rounding Control and Precision Control bits to in the FPU Control
Word. It's possible TS doesn't set them and they have who-knows-what
values - maybe they change from each invocation of TS - I don't know!
But I do know that these bits affect the result in any of the matissa
sizes that TS may use - 23-bit (single), 53-bit (double) or 64-bit
(extended) precision.
All that being true, what do I get when I store the result. This
adds an additional dimension to the problem because, independent
of the Rounding Control and Presision Control, I can store a 32,
64 or 80-bit result. Yes, I can even store a result with greater
precision than I performed the calculation in!
So, as to the question, "What's the deal, exactly?". Without
doing a lot of work, I do not know. But I do know it is very
easy to draw incorrect conclusions from the experiment "z = x -
(x/y)*y" that you performed.
This is equally true of any experiment we perform regarding the
precision of EL statements.
For example, the experiment Miles dunbar perfromed for us:
var: x(0);
x = 1.000000000015 - 1.000000000010;
if x = .000000000005 then plot1(x,"pass") else plot2(x,"fail");
plotted "fail".
What failed? Or the real question, what was evidently performed in
single precision and what was not? Maybe the only thing performed
in single precision was the parsing of the statements. Even if all
else was performed in extended precision, Miles result would be the
expected result. But this does not necesarily sound the death knell
for those who have suffered precision problems in pre-TS5 versions.
Personally, I would like a definitive statement from Omega on how
precision is handled. I am not expecting such a statement now nor
in the future. If such a statement is given, I will expect it to
be ambiguous, basically not helpful and possibly erroneous. (Maybe
I will be unexpectedly suprised :-) ).
So if we really want to know, we probably have to work it out
ourseleves. But we need to be very careful how we construct our
tests. I do not have the time at the moment to construct a set of
tests. But if anyone does, you may want to solicit a critique
of the tests and results from the group.
Chris Norrie
|