[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: First calculation problem



PureBytes Links

Trading Reference Links




-----Original Message-----
From: Vitaly Larichev [mailto:vitaly-all@xxxxxxxxx]
Sent: Wednesday, September 06, 2000 2:46 PM
To: Guy Tann
Cc: PD Manager
Subject: RE: First calculation problem

Hi Guy,

For some reasons I haven't been able to post lately anything to the List.
Could you do it
for me, please? Even if you don't agree on this <g>.

Thanks a lot.

Cheers, Vitaly


Hi,

Ken's point is clear and solid. Since calculators, computers tackle numbers
in binary form
instead of decimal, AND considering  finite precision in representation of
the numbers,
each step when the conversion (from/to binary) occurs, produces a small
(initially) error
that after many steps may propagate down into significant digits making a
result wrong.
This is a phenomenon well known in computational methods - too much increase
in a
resolution (too many steps) may kill the accuracy. Likewise, I guess, it may
happen with
a calculation of EMA where one may naively assume (from the formal
definition of
EMA) that the longer time series given, the higher accuracy. Also, even a
single step may
give a wrong answer if a calculation is not properly scaled (like
subtracting 2 too close
numbers may exhaust the precision kept). All above is fair enough.

Guy actually asks about something different: Why MS vs. Excel, etc. give
different
results. Pretty much reasonable question, since given the same precision in
representation
of the numbers, why to differ? Obviously, it deals with the way numbers are
converted
to/from binary form. Melesse Ayalew wrote lately about the IEEE standards
...

>...Depending on the rounding
>...mode(there are four rounding modes in the IEEE Standard) the results
should be
>...identical if identical operation and identical rounding mode are used
whether it
>...is on a PC or CRAY supercomputer and the same IEEE standard is supported
in both
>...platform.

What were the choices made for Metastock and Excel, ... when deciding on the
rounding
modes?

This is the only question answering to which may resolve the issue, I guess.

IMHO, what's important here is to realize that there is no right and wrong
sides in this
problem (unless there is some stupid error in coding Metastock). But thanks
to the
difference (in significant digits) in Metastock and Excel, it probably shows
that
the accuracy for Guy might get exhausted at some point in his calculations
(even in his
Clipper or other non-Equis stuff! Time to thank Equis for raising a red flag
<g>?), and
he needs higher precision to proceed with confidence (both in Clipper, ...
and Metastock).
This is how it looks to me now, though I am often wrong :-( .

Thanks.

Vitaly

P.S. I often tried myself to calculate stuff outside Metastock (using
FORTRAN), and I've
never got identical results, usually only 1-2 significant digits were the
same. But there
were many other reasons for it, like differing algorithms used by Equis for
its canned
functions (the manual doesn't contain formulas for the algorithms) and ones
used by
me. There are many "small" details which matter actually. So, go figure
where the
difference come from! Even within Metastock, its Explorer and charts may
give and once
in a while do give different signals because of different data lengths used.