| Welcome Guest, please sign in to participate in a discussion. | Search | Active Topics | |
Registered User
Joined: 10/7/2004
Posts: 799
Location: Duluth, GA
|
Copyright 2005 by James D. Dean, All Rights Reserved
Never develop the PCF directly in the TC editor ... do it separately in NotePad or WordPad.
The "Find/Replace" (Ctrl-H) feature is SUPERB for minimizing errors and speeding things up when writing long PCF's.
Use hard returns liberally throughout the PCF, to help you visualize its pieces correctly ... indentation can also help - but do NOT use Tabs, only spaces. Tabs WILL mess up the TC editor ... but it doesn't tell you :~(
SAVE those original, nicely formatted PCF's as txt or rtf files in a dedicated folder, with the SAME NAME as you give the PCF in TC.
Copy / paste that formula into TC's editor. Click Test to check it ... if there are errors, do NOT fix them in the Editor ... go back to your archive NotePad version and fix it there, then recopy.
Once it Tests OK, do the recalc and CHECK the results carefully by assigning the PCF to a WL tab column and sorting it - CAREFULLY examine a couple high-value results, and a couple low-value results, and a couple that are near zero.
If you find errors, once again, any fixes should be done in the Notepad version. Sometimes opening up the TC editor Test window again and working your way thru the values that show up can help find the problem.
Things to watch out for:
1) Mis-matched parentheses - the TC checker will NOT always catch these!
2) Matched but mis-placed parentheses - I suggest you write out the PCF in Notepad with only one paren per line (hard returns between), then count out the pairs from the inside, out.
3) Incorrect Function syntax - the editor will catch spelling errors like Sotc14.8.3, but will NOT know that you really wanted it to be Avg(Stoc14.8,3) to match the Stoc14,8,3 plotted line!
4) Use of Avg when you want to match a plot that uses XAvg. Or vice-versa.
5) DaysAgo parameters that match up properly - it's easy to mistype these, or forget one here or there in a long equation.
6) Math-Operator order of precedence - in a formula without paren's, * and / always calc before + and - (as if there were paren's around the */ expression) ... otherwise it flows from left to right.
7) Boolean-Operator order of precedence - in a formula without paren's, OR operators always evaluate before AND operators (as if paren's were around the OR portion).
8) Watch out for divide-by-zero errors ... the most common one is a denominator of the form (H-L), or (O-C), or (C-C1), etc ... it's quite possible for any of these to eval to zero ... to avoid this, change the denominator to something like (H-L+.0001)
If all that seems to be OK but the answer STILL seems wrong, then go back and CHECK YOUR ALGEBRA, and the theory behind the formula.
If possible, break the formula down into component pieces and create+check PCF's of each piece ... in fact, it's often a good idea to do this at the beginning of the process, then lump the (checked) pieces together at the end.
I hope this helps!
Jim Dean
|
|
Registered User
Joined: 1/1/2005
Posts: 2,645
|
The following additional comments may be helpful:
1) Mis-matched parentheses - the TC checker will NOT always catch these!
The editor will tell you if you have a left parenthesis with no matching right parenthesis. A right parenthesis with no matching left parenthesis will just be ignored. I have yet to see an exception to this.
6) Math-Operator order of precedence - in a formula without paren's, * and / always calc before + and - (as if there were paren's around the */ expression) ... otherwise it flows from left to right.
Beware! In mathematics, * is executed before /, i.e.,
a/b*c = a/(b*c)
in mathematics; whereas,
a/b*c = (a/b)*c
in most computer programs.
7) Boolean-Operator order of precedence - in a formula without paren's, OR operators always evaluate before AND operators (as if paren's were around the OR portion).
Beware! This is peculiar to TC2005. In other programs and mathematics, AND is executed before OR.
Any comments will be appreciated.
Thanks,
Jim Murphy
|
|
Registered User
Joined: 10/7/2004
Posts: 1
|
Thanks for summarizing PCF formula creation.
Your advice is particularly good for those of us who have typos.
Thanks, Jim (bustermu), for your post. It's the small things that can screw up a formula.
|
|
Registered User
Joined: 3/7/2005
Posts: 23
|
Jim,
I strongly disagree with you on one point. In everything I ever learned about mathematics, * and / have equal precedence and are evaluated left to right. a/b*c = (a/b)*c in every mathematical context I've ever heard of.
But I do recommend, as I'm sure you do, to use parentheses whenever the remotest possibility for confusion exists.
Rob Richardson
|
|
Registered User
Joined: 1/1/2005
Posts: 2,645
|
Rob,
Thanks for pointing out my error. Until your remarks, I was unaware that my statement was even controversial. After a little reading, my statement concerning mathematics should have been something like:
In mathematics, implied multiplication indicated by juxtaposition takes precedence over division, i.e.,
a/bc = a/(bc)
in mathematics; whereas,
a/b*c = (a/b)*c
in most computer programs. The former is (or, at least, was) the position of the American Mathematical Society, but not without controversy.
I do not know but my guess is that a*b was introduced as multiplication by FORTRAN where exponentiation was a**b. Exponentiation by a^b, also a guess, was introduced by BASIC.
In mathematics, (* ) is usually a unary involution operator, i.e., (b*)* = b, and the multiplication in b*c is indicated by the juxtaposition. For example, if a, b, and c are column vectors and (* ) is conjugate transpose, you have no choice but:
a/b*c = a/(b*c).
One would think that this should continue to hold in the case of one-dimensional real vectors.
Do you think that is enough defense of an essentially indefensible position? I agree with you, when in doubt, use parentheses.
Thanks,
Jim Murphy
|
|
Registered User
Joined: 3/7/2005
Posts: 23
|
Jim,
I never even thought about precedence in an expression like "a/bc". If I came across that, I would probably handle it the way the society says I should without even thinking about it. I am a reasonably mathematical person, but I would have proceeded to come up with the correct answer without any consideration that I was violating a rule I've known since second grade!
Rob
|
|
Registered User
Joined: 1/1/2005
Posts: 2,645
|
On p. 84 of Allendoerfer and Oakley, _Principles of Mathematics_, 1969 we find:
(a/b) x (c/d) = ac/bd
which is generally true only if the right side is interpreted as:
(ac)/(bd)
|
|
Registered User
Joined: 10/7/2004
Posts: 799
Location: Duluth, GA
|
Jeesh guys can we get back to something that has to do with TC, please?
|
|
|
Guest-1 |