|
PureBytes Links
Trading Reference Links
|
On Fri, 26 May 2000, Pierre Orphelin wrote:
> > It is NOT a length - just an integer flag to select one af a few choices
> > in the study.
> > Your assumption is not correct.
> =====
> You pseudo code is not so clear on this point
Sorry it was not clear - I was trying to only include the relevant part.
> > In any case, if I have a block that starts 'if x=4', and x=0, the block
> > should NOT execute. Is this not correct?
>
> It executes when verifying, and bypass the if then bloc to chzck what is
> inside for the case
Actually, Gary Fritz got it right - it is a 'Series' issue. EL executes
code inside a 'non executable' block despite what the code says. This code
*will* execute at run time as well. To demo this, run StdErr with a length
of 3 - runs OK - then change it to 2 and it will give the err even at run
time.
I'd like to make sure I'm not missing yet another 'odd' behavior of
EL. Are you suggesting that there is yet another effect that occurs only
at compile time? In my case, the error does NOT occur at compile time
because the parameters only get to the 'barf' value at run time.
> It's not a bug.
Technically speaking, it is not. It is likely that Omega would probably
call it a 'feature' :-).
But it does seem strange when one writes a piece of code to make sure
something does NOT execute, and EL executes it anyway.
This Series/Simple stuff is a PITA, IMHO.
> You do not trust TS ,
I have to agree with this :-). It does too many strange things (see my
recent note re S&P error of 7!) to be trustworthy.
> and TS do not trust EL coders,
This is a noble idea on Omega's part, but it might have introduced more
problems than it is worth.
> so it verify when
> compiling that a possible 0 div could exist.
I'm still not sure what you are trying to tell me. In the case I was
describing, this error would not occur at compile time.
Thanks for the reply,
Larry
|