|
PureBytes Links
Trading Reference Links
|
Michel:
Don't take my word for it. Ask a prof at your local college/university.
You misunderstood what I wrote. I didn't say that putting a zero at the end
of a decimal number is incorrect, I said that putting a zero at the end of a
decimal, as the example in the Metastock manual is incorrect. If your number
is supposed to be truncated or rounded to 2 decimal places, putting a zero
in the 3rd decimal place is incorrect.
Example number with 2 decimal places:
3.14
not 3.140 (this means rounded or truncated to 3 decimal places)
Look up "significant figures" in a math, stat, or engineering book .
Lionel Issen
lissen@xxxxxxxxx
----- Original Message -----
From: michael <mslist@xxxxxxxxxxxxxxxx>
To: <metastock@xxxxxxxxxxxxx>
Sent: Wednesday, August 30, 2000 7:11 AM
Subject: RE: First calculation problem
> I disagree.
>
> <Ken:
> 1. Putting in the extra zero is NOT in accordance with several centuries
of
> mathematics terminology and definitions. The zero shows nothing and is
> simply confusing.>
>
> There is no mathematic rule that says not to show a zero at the end of a
> number.
>
> <2. The precision function should round off, not truncate. See item 1
> above.>
>
> There is a round function in MetaStock if you want to round. The purpose
of
> the precision function is to remove the undisired computer junk that goes
> into your calculation past the value that you want. Rounding would
compound
> the problem not fix it. The whole precision problem comes from your
> computer rounding unseen decimal places.
>
> I think your programmers are doing a great job balancing the request of
> power users and maintaining the ease of use and functionality of the
> program.
>
> Thanks,
> Michael
>
> -----Original Message-----
> From: owner-metastock@xxxxxxxxxxxxx
> [mailto:owner-metastock@xxxxxxxxxxxxx]On Behalf Of Lionel Issen
> Sent: Tuesday, August 29, 2000 5:59 PM
> To: metastock@xxxxxxxxxxxxx
> Subject: Re: First calculation problem
>
>
>
>
>
> 3. Your programmers apparently do not know or understand standard
> mathematics terminology and usage.
>
> 4. You didn't answer my earlier question on how to specify double and long
> precision when using metastock.
>
> 5. There is a rule for estimating the number of decimal points needed to
> maintain a certain level of accuracy/precision. I forget the details, but
it
> was in the literature few decades back.
> Lionel Issen
> lissen@xxxxxxxxx
> ----- Original Message -----
> From: PD Manager <pdmanager@xxxxxxxxxxxxxxxxx>
> To: <metastock@xxxxxxxxxxxxx>
> Sent: Tuesday, August 29, 2000 12:19 PM
> Subject: RE: First calculation problem
>
>
> > The documentation states that the Precision function TRUNCATES the
number
> to
> > the specified position. With truncation, no rounding takes place. The
> > examples in the manual show an extra zero on the end of the resulting
> number
> > to show that a truncation did indeed take place. As the example
> > prec(10.12981,2) returning 10.120 shows, all numbers after the second
> digit
> > to the right of the decimal are removed. The zero on the end of 10.120
is
> > there to show that everything from the third position and beyond has
been
> > converted to zero.
> >
> > As I stated earlier, a trick we used in the flight simulation business
was
> > to do everything in integer math. Multiply all of your numbers by a
power
> > of ten (equal to the number of digits to the right of the decimal that
you
> > are interested in) and then do a division by the same power of ten
> afterward
> > (assuming you have handled any intermediate values produced by
> > multiplication or division) and many of the precision problems will be
> > eliminated.
> >
> > Ken Hunt
> > Programming Manager
> > Equis International
> >
> >
> > -----Original Message-----
> > From: Guy Tann [mailto:grt@xxxxxxxxxxxx]
> > Sent: Tuesday, August 29, 2000 1:25 AM
> > To: metastock@xxxxxxxxxxxxx
> > Subject: RE: First calculation problem
> >
> >
> > Ken,
> >
> > Here is another question, which will further demonstrate my confusion.
> >
> > On Page 259 of my 7.01 Manual, there are two samples of how precision
> works.
> > The first example shows a formula "prec(10.12981,2)" returning 10.120.
> Now,
> > I would have thought that this should return 10.13. The second example
> > "prec(10.12981,4)" returns 10.12980. Again, according to how I look at
> > precision, this should return 10.1298. Both examples seem to contain
one
> > extra decimal position and the first one doesn't round properly. If
we're
> > using the prec() function and want no more than 2 decimals, I thought I
> > should use the formula prec(x,2). According to these examples I should
> use
> > prec(x,1). Which approach is correct? In addition, if the first
example
> in
> > the manual is correct, then I now know that I'll need to add rounding to
> > every calculation.
> >
> > Oops! Much to my surprise I just discovered that I will have to do my
own
> > rounding since, by MS' definition, rounding rounds to the nearest
integer.
> > Stupid me! I had made the assumption that if I defined 2 decimal places
> and
> > said round(), it would round the results to the second decimal position.
> > This might, by itself, be the cause of a lot of my problems. In my
first
> > conversion a few years ago, I had to add my own rounding in order to
> > successfully complete my parallel testing.
> >
> > Ken, I'm not trying to be difficult and if you want to continue this
> > off-line, that's fine with me.
> >
> > I guess I should explain why this is so important to us. We have
> developed
> > our trading rules over many years using programs without this "single
> > precision" problem (or possibly we were able to avoid it using our own
> > rounding. Part of this conversion process, and what takes me so much
> time,
> > is making sure that the MS output equals our Clipper output. Our first
> > conversion took me almost 6 months to come up with the correct results
(to
> > get our parallel processes in agreement). I've been working on this
> current
> > program for about a month trying to get to the point where we can start
> our
> > parallel testing.
> >
> > I understand that people use MS primarily for its charting capabilities
> and
> > that we are probably in the minority in that we went with Equis
primarily
> > for the Downloader. It wasn't until v6.5.2 that we were able to begin
> using
> > it for computation. Now, if we were developing new trading rules or new
> > systems, it probably wouldn't be such a big deal. Unfortunately, we are
> > trying to convert an existing system into MS and duplicate the results
of
> > that system. While we trade some pretty big numbers, big for us anyway,
I
> > can't go through an actual conversion to MS without being able to
> duplicate
> > our Clipper output.
> >
> > Guy
> >
> > " When I die, I want to go peacefully like my grandfather did, in his
> sleep.
> > Not yelling and screaming like the passengers in his car."
> >
> > -----Original Message-----
> > From: owner-metastock@xxxxxxxxxxxxx
> [mailto:owner-metastock@xxxxxxxxxxxxx]On
> > Behalf Of PD Manager
> > Sent: Friday, August 25, 2000 7:35 AM
> > To: 'metastock@xxxxxxxxxxxxx'
> > Subject: RE: First calculation problem
> >
> > MetaStock does indeed use single precision floating point numbers. As
you
> > mentioned, going to double precision would literally double the memory
> > requirements for data storage for charts and would also slow down
> > calculations. When you get into mathematical calculations, however,
going
> > to double precision doesn't necessarily make the problem better. PC
> > computer hardware still cannot accurately store a number as simple as
0.1
> > whether you are using single or double precision. It is stored as an
> > approximation. When it comes to floating point numbers, the hardware
can
> > really only accurately store fractional numbers that are powers of two
> (1/2,
> > 1/4, 1/8, 1/16 etc).
> >
> > Other software packages suffer from the same problem (including VB and
> > Excel) although some manage to mask it better than others. If you don't
> > believe this, I can submit a set of "simple" calculations that will
cause
> > Excel to show precision errors also.
> >
> > Some software packages will use other methods to store and/or calculate
> > floating point numbers. This usually involves something like BCD
encoding
> > or some type of integer encoded fixed point real numbers. While this
> > ultimately solves the precision problem, it has other problems with
speed
> of
> > calculations as well as a reduced ability to store large or very small
> > numbers.
> >
> > We have always been aware of this issue and that is why we added the
> > precision function to the formula language. It was put there in an
> attempt
> > to help those writing formulas to work with the precision they needed.
> >
> > Ken Hunt
> > Programming Manager
> > Equis International
> >
> >
> > -----Original Message-----
> > From: Kent Rollins [mailto:kentr@xxxxxxxxxxxxxx]
> > Sent: Friday, August 25, 2000 12:40 AM
> > To: metastock@xxxxxxxxxxxxx
> > Subject: Re: First calculation problem
> >
> >
> > Looks like you may have hit the old single-precision problem. PCs
> basically
> > have 3 native ways of storing floating point numbers: single-precision
(4
> > bytes), double-precision (8 bytes), and long double (10 bytes). The
> problem
> > is that each one of these representations has a limited number of
> "numbers"
> > that it can represent and from time to time you will hit a calculation
> that
> > reveals this limitation in all it's splendor. Single-precision floats
can
> > represent approximately 4 billion different numbers. That's a lot until
> you
> > consider that between 0 and 1 there are an infinite number of floating
> point
> > numbers. Double-precision has many, many more number that it can
> represent
> > (4 billion times 4 billion) and you RARELY see the kind of error you
have
> > hit when you are dealing with numbers on the scale of 1486 with only 2
> > places of precision. That leads me to suspect that Equis is using
> > single-precision numbers for these calculations (Omega does the same
> thing).
> > Saves memory, SLIGHTLY faster in computation, loses precision. There is
> > really no good reason for using singles in an app like this and there is
a
> > (now obvious) good reason not to. I would scream and yell at Equis.
Tell
> > Little Guy that if he convinces Equis to use doubles you'll buy him a
pony
> > and then drop him off in the programmer's offices.
> >
> > Ken Hunt, does MetaStock use single precision for these calculations?
> >
> > Kent
> >
> >
> > -----Original Message-----
> > From: Guy Tann <grt@xxxxxxxxxxxx>
> > To: Metastock User Group <metastock-list@xxxxxxxxxxxxx>
> > Date: Friday, August 25, 2000 1:29 AM
> > Subject: First calculation problem
> >
> >
> > List,
> >
> > Well, I decided to do a little more work and discovered my first
problem.
> >
> > Somehow, MS came up with the following:
> >
> > 1486.20
> > - 1469.40
> > 16.7999 instead of the more commonly expected 16.80
> >
> > Now the first number is the Close and the second number is the day's
low,
> so
> > we can't blame this on any previous calculation or anything left over
from
> > something else. Well, that's not quite true. The Low used in the
> > calculation was the result of an IF() statement that made sure that the
> Low
> > was really the Low by our definition (by checking it against the
previous
> > day's Close).
> >
> > What internal methodology might cause this excellent bit of subtraction?
> >
> > Granted, in checking out the 170-member dataset, I didn't check them
all.
> I
> > checked the first 20 and the last 20. Now I'll probably have to go back
> and
> > sample some in the middle.
> >
> > I used my trusty, solar powered calculator to double-check my Clipper
> output
> > and they both agree that MS is wrong. Any suggestions?
> >
> > This is making me very nervous and might force me back to Excel and/or
VB.
> > So far I've spent over two week on this relatively simple program and I
> have
> > to admit that I never thought it would be necessary to go back and
> > double-check such basic arithmetic.
> >
> >
> > Guy
> >
> > Never be afraid to try something new. Remember, amateurs built the ark,
> > professionals built the Titanic.
> >
>
>
|