|
PureBytes Links
Trading Reference Links
|
Lionel:
1. Apologies for confusing the issue by adding a meaningless trailing zero.
2. The Precision function does truncate and we couldn't change it without
changing the results of every formula currently written by users.
3. Although I disagree, your comment doesn't do anything to identify or
solve any problems with MetaStock.
4. There is no way for a user to make a setting in Windows to change the
NATIVE floating point representation in our applications (or any other
application that I know of). You can change DISPLAY formats, but you cannot
change internal storage representation.
5. The digits of precision are defined by the floating point representation
used by the software. (single precision gives 6-7 digits, double precision
gives 15 digits and a long double gives 19 digits of precision, each of
these with larger memory requirements).
Ken Hunt
Programming Manager
Equis International
-----Original Message-----
From: Lionel Issen [mailto:lissen@xxxxxxxxx]
Sent: Tuesday, August 29, 2000 3:59 PM
To: metastock@xxxxxxxxxxxxx
Subject: Re: First calculation problem
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.
2. The precision function should round off, not truncate. See item 1
above.
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.
>
|