Registered User
Joined: 1/1/2005
Posts: 2,645
|
One would think that adding parentheses to a PCF would increase the computation time, but perhaps so little that you could not measure it with a timer with only one second increments.
I wrote the following PCF's:
1) 0.1234*C+0.1234*C+0.1234*C+....+0.1234*C
2) (0.1234*C+(0.1234*C+(0.1234*C+....+(0.1234*C)))...)
with each having 720 terms. When tested, they each produced the same correct result. The first took 13 seconds to test and the second took only 8 seconds. I am so far at a loss to explain this.
I always get comparable results nesting to the right. I have not yet nested in any other order.
Can anyone explain this? This is a significant result for writing EMA PCF's.
Any comments will be appreciated.
Thanks,
Jim Murphy
|
|
Worden Trainer
Joined: 10/1/2004
Posts: 18,819
|
I have no idea... We will have to see if StockGuy has any insight.
- Craig
Here to Help!
|
|
Registered User
Joined: 1/1/2005
Posts: 2,645
|
Here is some new information. I wrote the following PCF:
3) 0.1234*C)+0.1234*C)+0.1234*C)+...+0.1234*C)
with a total of 720 terms. The right parentheses are ignored. The computation time was again 13 seconds. As left parentheses were added on the left, the computation time decreased until the full compliment of 720 was reached. The final compution time was 7 seconds. The computed values are correct, but the computation time should not behave in that fashion.
Nested parentheses should increase computation time very slightly, not decrease it significantly.
Hopefully, we will get varification and an explanation.
Any comments will be appreciated.
Thanks,
Jim Murphy
|
|
Registered User
Joined: 1/1/2005
Posts: 2,645
|
There are additional surprises in computational time required for PCF's. Again consider the PCF's:
1) 0.1234*C+0.1234*C+0.1234*C+....+0.1234*C
2) (0.1234*C+(0.1234*C+(0.1234*C+....+(0.1234*C)))...)
Upon changing the number terms in each, I get the following computational times in seconds:
Terms,,,#1,,,#2
.,600,,,,7,,,,5
,,900...29,,,12
,1200,,140,,,24
For #1, if you double the number of terms, the computation time should at most double. If it taks 7 seconds for 600 terms, it should take no more than 14 seconds for 1200 terms, not 140 seconds.
Any comments or explanation will be appreciated.
Thanks,
Jim Murphy
|
|
Registered User
Joined: 10/7/2004
Posts: 799
Location: Duluth, GA
|
Your example is not a legitimate test IF the compiler does multiple passes to consolidate the string first.
The reason is that operator precedence makes these two equations identical, and the paren's would just be stripped out prior to execution, without requiring the multiple stack-push-pops which can be the bane of paren'd forms.
That is, your example:
1) 0.1234*C+0.1234*C+0.1234*C+....+0.1234*C
2) (0.1234*C+(0.1234*C+(0.1234*C+....+(0.1234*C)))...)
Should be changed to something like:
1) 0.1234*C+0.1234*C+0.1234*C+....+0.1234*C
2) 0.1234*(C+0.1234*(C+0.1234*(C+....+0.1234*C)))...)
If you want the test to really evaluate the time-impact of NECESSARY paren nesting calcs.
Jim Dean
|
|
Worden Trainer
Joined: 10/7/2004
Posts: 65,138
|
I just did Tanstaafl's experiment using four different formulas, each having 500 terms. Two of the formulas use nested parentheses, the other two precalculate the coefficients and don't have any parenthesis. Two of the formulas multiply each coefficent by just today's price, the other two use prices from the last 500 days.
1) 0.99*C+0.9801*C+0.970299*C+...+0.006637*C+0.00657*C+0.006505*C
2) 0.99*(C+0.99*(C+0.99*(C+...+0.99*(C+0.99*(C+0.99*C)))))...
3) 0.99*C+0.9801*C1+0.970299*C2+...+0.006637*C497+0.00657*C498+0.006505*C499
4) 0.99*(C+0.99*(C1+0.99*(C2+...+0.99*(C497+0.99*(C498+0.99*C499)))))...
I was actually a bit surprised at just how consistent the results were over several runs. Formulas 1 and 2 took 0:19 each while 3 and 4 took 4:15. The parenthesis didn't seem to make any difference in calculation time, looking up two years of prices had a significant effect.
-Bruce
Personal Criteria Formulas
TC2000 Support Articles
|
|
Registered User
Joined: 10/7/2004
Posts: 799
Location: Duluth, GA
|
Velly intellestink, Bruce ... thanks for doing the tests.
I suspect that whatever impact the parens are having is tiny in comparison to the other aspects of the calcs.
So I guess that the whole paren issue can be dropped re calc time ... its only remaining significance is that of keeping them balanced properly.
Jim Dean
|
|
Worden Trainer
Joined: 10/7/2004
Posts: 65,138
|
I added some unneccessary parenthesis to see if it changed anything. It didn't have any effect on the formulas using only today's price, but I got times as low as 3:30 on the formulas using 500 days of data. I'm not sure if this is significant however because now all of my times for the formulas using 500 days of data are lower (between 3:30 and 4:00) and are no longer as consistent, even for the same formula. Maybe there is some sort of background task on my computer affecting this. Anyway, the additional formulas I tried were:
5) (0.99*C)+(0.9801*C)+(0.970299*C)+...+(0.006637*C)+(0.00657*C)+(0.006505*C)
6) 0.99*C+(0.9801*C+(0.970299*C+...+(0.006637*C+(0.00657*C+(0.006505*C)))))...
7) (0.99*C)+(0.9801*C1)+(0.970299*C2)+...+(0.006637*C497)+(0.00657*C498)+(0.006505*C499)
8) 0.99*C+(0.9801*C1+(0.970299*2C+...+(0.006637*C497+(0.00657*C498+(0.006505*C499)))))...
-Bruce
Personal Criteria Formulas
TC2000 Support Articles
|
|
Registered User
Joined: 1/1/2005
Posts: 2,645
|
QUOTE (Tanstaafl) Your example is not a legitimate test IF the compiler does multiple passes to consolidate the string first.
The reason is that operator precedence makes these two equations identical, and the paren's would just be stripped out prior to execution, without requiring the multiple stack-push-pops which can be the bane of paren'd forms.
Jim D.,
If the complier does strip out unnecessary parentheses, that should make the two PCF's:
1) 0.1234*C+0.1234*C+0.1234*C+....+0.1234*C
2) (0.1234*C+(0.1234*C+(0.1234*C+....+(0.1234*C)))...)
have equal testing times. It should not cause the testing time for 2) to be less than that of 1). Right?
Thanks,
Jim Murphy
|
|
Registered User
Joined: 1/1/2005
Posts: 2,645
|
Bruce,
Our experiments were different in that:
1) I measured the time required to test the PCF's.
2) I believe you measured the time required to update the PCF's.
My guess is that you were unable to measure the time difference for your 1) and 6) because you did not use enough terms and because what little difference there might have been was lost in all the "bookkeeping" time.
I used PCF's for which the result could be varified. I am not sure that an indicated addition actually takes place between two positive numbers when one is large and the other is extremely small. Also, terms like C700 were not used because their access times would swamp the computation times induced by parentheses.
I expected the time to test:
1) to increase at most only linearly with the number of add's,
2) to increase insignificantly with the injection of any unnecessary parentheses.
I was completely surprised by the results. They have never been explained.
Any further help and/or explanation will be appreciated.
Thanks,
Jim Murphy
|
|
Worden Trainer
Joined: 10/7/2004
Posts: 65,138
|
bustermu,
I recreated your tests with some minor alterations. I created two formulas of 720 terms with identical, but random sets of coefficients (ranging from 0 to 1 and rounded to 4 digits past the decimal) and days ago parameters (ranging from 1 to 50). The version with the parentheses was always significantly faster during both testing and updating. The results were very close to yours, with the (unnecessary) parentheses cutting the times almost in half.
-Bruce
Personal Criteria Formulas
TC2000 Support Articles
|
|
Registered User
Joined: 1/1/2005
Posts: 2,645
|
Bruce,
Thanks for the additional information. It is nice to have questionable results confirmed or rejected.
Unfortunately, the excessive growth in computational time of a PCF with length cannot always be reduced by adding parentheses. For example, consider the sum of N duplicates of the PCF I gave for DX in:
PCF for Wilder's DX, and/or a CI for Wilder's ADX
The following table gives the measured testing time in seconds for the number of DX terms in the PCF:
Terms___Time
____1______3
____4_____58
___10____820
Given the 3 second base, the time for 4 terms should be no more than 12 seconds and the time for 10 terms should be no more than 30 seconds. The limited number of parentheses that can be added is of little help. The problem appears to be with the TC2005 program.
Thanks,
Jim Murphy
|
|
|
Guest-1 |