|
PureBytes Links
Trading Reference Links
|
I concur with the issue regarding the in-reference parameters supporting
Series-type of values......
this is a HUGE improvement...
However, for system builder, it becomes a problem for customers who do not
upgrade to the latest release !!!!
This is why we need SP4 so quickly......few are actually upgrading to
SP3....myself included.
I WANT this new functionality, but not all of the other side-effects of SP3.
> -----Original Message-----
> From: Alan Mi [mailto:ami@xxxxxxxxxxxxxx]
> Sent: Friday, November 12, 1999 3:00 AM
> To: omegalist
> Subject: RE: SP3 Compiler Bug
>
>
> Mark,
>
>
> Your initial posting is basically the same as
> http://www.jurikres.com/down/sp3.txt I have the following
> questions / comments.
>
> To clarify for your readers, your description of EL
> compiler's auto-detect process can be made more accurate
> this way: Simple if and only if the function's code
> references neigher the history of a variable declared within
> the function, nor that of the function itself ( as in
> _XAverage=price*alph+_XAverage[1]*(1-alph) ). If you
> reference Close[1] or Highest(High,5)[1], it is not detected
> as Series.
>
> You have a "theory" that the Series/Simple function type
> spec is ignored. You must have at least one example that
> supports the theory. Can you share one example with us here?
> I agree that all the numbered problems exist if the theory
> holds true. I agree that SP3 real time users should be
> alerted on this issue while it is still under investigation.
>
> I just installed SP3 on a backburner PC and had a chance to
> test it. I have a couple of scenarios to test and I have not
> finished testing. but so far the results are negative, not
> supporting your theory. So at least it does not always
> ignore the spec. See the comments for plotting results. Here
> is a siimple one:
>
>
> {Function _FuncSimple1: (property sheet Simple set)}
> var: bringForward(10);
> if CurrentBar=1 then bringForward=20;
> _FuncSimple1 = bringForward;
>
>
> {Function _FuncSeries1: (property sheet Series set)}
> var: bringForward(10);
> if CurrentBar=1 then bringForward=20;
> _FuncSeries1 = bringForward;
>
>
> {Indicator _FuncTest}
> var: fSimple1(0);
> var: fSeries1(0);
> if CurrentBar>1 then begin
> fSimple1=_FuncSimple1;
> fSeries1=_FuncSeries1;
> end;
>
> Plot1(fSimple1);
> {SP2: 0 1st bar, 10 2nd bar and on
> since init. on the first bar is skipped}
> {SP3: same!!!}
> Plot2(fSeries1);
> {SP2: 0 1st bar, 20 2nd bar and on}
> {SP3: same!!!}
>
>
>
> Here is the OR memo to you that you posted in your follow up
> posting. "In the revised model for handling Series
> Functions, Easy language will calculate each Series Function
> for each instance. What this means is that some calculations
> that were not taken into account before by the compiler, are
> handled now. This is the main cause of the Floating Point
> Errors that users have been finding." I can provide some
> historical perspective.
>
> 2000i introduced in reference parameters for functions,
> similar to the Pascal var or the C++ non-constant reference
> parameter, which is a huge leap forward in terms of system
> development- it's one order of magnitude easier to develop
> large studies. It allows more efficient code too. One
> example is that you now can combine the built-in Linear
> Regression Value and Slope (same logic) if you need both, a
> 100% speed up. There is one problem though: any function
> that has a reference type parameter is doomed to be Simple
> and no variable history or function history reference is
> allowed. This is extremely inconvenient; array is a clumsy
> alternative but often forbidingly. The reason is this.
> Series function calls are calculated at the beginning of a
> function/study regardless of the wrapping conditions. You
> described all that in your 99 Fall OR Magzine article.
> Therefore, they have to limit (all) the actual parameters
> passed to any series function to numbers or inputs. But the
> actual parameters for reference parameters can be anything
> but number or input.
>
> We customers (me included) must have pounded hard enough on
> them to relax this restriction. They not only listened, but
> quite to my amazement, they got it stuck so quickly into
> SP3. Not only did they relax the restriction for certain
> scenarios as I suggested to them (and ran by you but you
> doubted the feasibility), they removed it! The other key
> feature we customers have pushed thru for SP3 is GS custom
> symbol list. One end of the customer spectrum feels tickled
> while the other end frowns. Great so long as load stability
> is not hampered but in reality, something got to give.
>
> What I don't understand about their memo is "some
> calculations that were not taken into account before". If
> they did not change the auto-detect algorithm as they seem
> to imply, all the "trouble code" verified in SP2, meaning
> that the parameters for series functions are all numbers or
> inputs, what could be those "calculations"? Mind boggling.
> Why don't you ask for an example from them to show what this
> means?
>
> Examples, folks, taletell examples we need.
>
>
> Alan Mi
>
>
|