|
PureBytes Links
Trading Reference Links
|
Pierre,
You will learn my French non-programming firend that CPU time doesn't matter
1 bit in code like this - in most EL code. The bottom line is getting it
done. I wouldn't want you programming for me beause your useless attention
to trivial detail costs me money and wastes me time. Get a clue. This rules
is readability first then CPU time if it matters at all which it useally
doesn't. This isn't assembly language programming and there's nothing
iterative here to slow the PC down. Being the keen-eyed Elton John type you
are (now I really know you must spend more time practicing you instruments
than writing code) I would expect that you would actually notice a
millsecond or two difference in the time it takes for my pentium II to
execute the extra statements. Unfortunately, your attention to detail is
not usefulin this case because this is such a small function. I also have
iterative code the solves the same thing. It gets the job done and it gets
it done well.
iRawPrice = 0 is good defensive programming weather it needs to be there or
not because god knows Omega EL is quirky enough. If you were a programmer
you'd know this.
Reading yours....
God Pierre in your attempt to quickly criticize without thinking -- SO
TY[ICAL OF YOUR BLIND AFFLICATION -- YOU WILL REALZIE THAT THIS CODE WAS NOT
MEANT TO BE PLOTTED!!!!!!!!!! A PLOT OFTHIS CODE IS USELESS YOU PIN HEAD.
GET A F--IN CLUE!
DO TRADERS REALLY TRUST YOUR EURO-FUZZY P.O.S. SOFTWARE?
THIS IS A FUNCTION THAT I USE IN A LARGER SYSTEM TO CREATE A TEXT FILE. THE
VALUE THAT THIS FUNCTION RETURNS IS WRITTEN TO A TEXT FILE THEN AN EXCEL VBA
PROGRAM CREATES A TRADESHEET FOR ME PRINTING THIS VALUE.
If I thought your suggestions had any merit Pierre I'd be the first to
complement you . BUT ALL OF THEM ARE NITS LIKE SO MCUH OF YOUR CRAP DOESN'T
AMOUNT TO A HILL OF BEANS. ADDING YOUR SUGGESTIONS WOULD MAKE AOBSOLUTELY
NO DIFFERENCE IN THE TIME OR OUTPUT OF THIS FUNCTION.
THE BOTTOM LINE IS THAT 3.5 YEARS AGO I NEEDED A SOLUTION AND THIS WORKS
WELL I MIGHT ADD.
SO GO TO SCHOOL HERE PIERRE BECAUSE YOU'LL LEARN THAT IN AMERICA WE ACTUALLY
THINK BEFORE WE BASH AND ASK OURSELVES IF THERE'S A GOOD REASON FOR IT.
GO BACK INTO THE HOLE YOU CRAWLED OUT OF HERE BECAUSE YOU'RE OUT OF YOUR
LEAGUE MY FRENCH NON PROGRAMMING FRIEND.
Go back to writing your stupid little indicators and crappy web pages and
leave the real programming to professionals like me.
Brian.
-----Original Message-----
From: Orphelin@xxxxxxx [mailto:Orphelin@xxxxxxx]
Sent: Thursday, November 12, 1998 6:40 AM
To: Omega-list
Subject: Next bar, next bash
Dans un courrier daté du 12/11/98 09:09:03 Heure d9iver Pari3 Madrid, Brian
Massey écrit:
>
> In the code I posted yesterday concerning pivot points in OSC for
tomorrow,
> I left out a critical piece of info (adding c[1] to the part in
> parentheses).
>
> Here's what it should be (see below to compare to last night's)
>
> Inputs : ePrice(NumericSeries);
> Vars: iRawPrice(0);
>
> iRawPrice = 0;
> iRawPrice = c[1] + (c[1] * RateOfChange(ePrice,2)[0] / 100) ;
>
> TS_STPivot = iRawPrice;
>
Ah, this is interesting...
First, your solution, even fixed, is not good EL programming at all:
Assuming that the code was valid, it's CPU time wasting for a such a simple
code:
Knowing that ROC= 100(c/c[n] -1), your above formula should write simpler:
iRawPrice = c[1] + (c[1] * RateOfChange(ePrice,2)[0] / 100) ;
<==> iRawPrice c[1] + (c[1] *( 100*(ePrice/ePrice[2]-1)*100;
Now, I assume that ePrice could nothing different than c, because you make
use
of c and c[1] in the above formula.
This will change nothing to the following remark.
<==> iRawPrice = c[1] + (c[1] *( 100*(c/c[2]-1)/100;
<==> iRawPrice = c[1] + (c[1] (c/c[2]-1);
<==> iRawPrice = c[1] + (c[1] (c/c[2]-1);
<==> iRawPrice = c[1] + c[1]*c/c[2]-c[1]);
<==> iRawPrice = c[1]*c/c[2];
The general formula will be:
iRawPrice = c[length-1]*c/c[length];
Where length is the lookback period of the ROC.
Second, you do not need to write:
iRawPrice = 0;
This is useless in this case.
You should know that EL carries previous values of variables
from bar to bar when using a series function.
This will produce an annoying 0 plot when curentbar<length, making the
indicator scale from 0 to price.
To avoid this , you need to write:
iRawPrice = ePrice;
Third, you do not need to use a temporary variable like iRawprice.
Better to use the function name directly in this case:
TS_STPivot = c[1]*c/c[2];
Fourth, instead of using price as input ( that is not consistent
with the close values that you use in the next bar ROC formula,
better is to use lenght and price as inputs:
Your user function should write:
Inputs : ePrice(NumericSeries), length(numericsimple);
TS_STPivot=ePrice; ( avoids the zero plot during early bars).
TS_STPivot = ePrice[length-1]*ePrice/ePrice[length];
All of this spares the following operations:
1 multiplication
1 division
1 addition.
1 substraction
...and remove one variable from the code, and is of general use.
Thanks to give me the chance to give you some simple EL lessons.
Brillant people often need some when they go off road when avoiding cold
thinking.
I, of course, do not mean that you are not a good programmer.
I only point out that when someone has a strong and definitive advice on
anything, he could
be more careful before sending 4 messages a day.
Your EL programmer friend and sometimes useful Omega-List spammer,
-Pierre Orphelin
Spam section starts below:
Download our free neurofuzzy logic software "The Assistant for Expert
Traders
version2", designed by pop stars.
www.sirtrade.com
|