Hey everyone,
It seems like I may have found a bug in the way EL gets interpreted and translated into C++. I have confirmed this bug in MC12, MC14 and also the most recent version of TS - which means I'm either doing something wrong, or it's been like that since the start, and the problem itself might be at the core of the language itself.
In short: if we create an array, and based on a loop the array's contents are varied, and then we are calling a function with the contents of this array, and we are saving the return value to another array, indexed by the same loop - the results array will have incorrect results.
I have attached a piece of code - including a function and a signal that calls it. Could I ask some experienced people to take a look at this, look through the comments and either confirm the bug or let me know if I'm doing something wrong?
-Ben
Bug in the EL core compiler/interpreter
-
TJ
- Posts: 7743
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2222 times
Re: Bug in the EL core compiler/interpreter
I don't install codes in my computer. You have to post the text file.
-
TJ
- Posts: 7743
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2222 times
Re: Bug in the EL core compiler/interpreter
Not sure if this is the problem:
Check your counting . . .
Some counting start with ZERO,
Some counting start with ONE . . .
Check your counting . . .
Some counting start with ZERO,
Some counting start with ONE . . .
Re: Bug in the EL core compiler/interpreter
No TJ, that's not the problem. This is an actual bug in EL, I believe, however unlikely that sounds 
Sounds like you opened it up anyway. Do you still want me to post the text files?
Sounds like you opened it up anyway. Do you still want me to post the text files?
-
rrams
- Posts: 128
- Joined: 10 Feb 2011
- Location: USA
- Has thanked: 7 times
- Been thanked: 70 times
- Contact:
Re: Bug in the EL core compiler/interpreter
Hi c0ntango,
Hope you don't mind my opinion: I wouldn't technically call this a bug. This does give unexpected behavior, but a true software bug is if there is no way of producing an intended functionality. (Although in an academic setting there would be marks off for this design.)
So the question becomes how do you correctly write a function that sums negative integers in an array? Well you just have to implicitly inform the compiler to typecast the variable as a signed long integer instead of just an unsigned integer. In the function don't use variable1, use:
Does this accomplish what you want? You can submit this as a bug if you wish, but they have plenty of other things to work on.
Hope you don't mind my opinion: I wouldn't technically call this a bug. This does give unexpected behavior, but a true software bug is if there is no way of producing an intended functionality. (Although in an academic setting there would be marks off for this design.)
So the question becomes how do you correctly write a function that sums negative integers in an array? Well you just have to implicitly inform the compiler to typecast the variable as a signed long integer instead of just an unsigned integer. In the function don't use variable1, use:
Code: Select all
inputs: Trades[size](NumericArray);
vars: loop(0), negnum(-1);
negnum=0;
loop=0;
while loop<=array_getmaxindex(Trades)
begin
negnum+=Trades[loop];
loop+=1;
end;
Re: Bug in the EL core compiler/interpreter
Interesting.
When you manually init your value1 in your function then it works.
Just add this line in your function: elbug_func
the question is why this variable is not initialized with 0 on every function call?
Here is the whole function:
When you manually init your value1 in your function then it works.
Just add this line in your function: elbug_func
Code: Select all
loop = 0;
//Add, this line
value1 = 0;
Here is the whole function:
Code: Select all
inputs:
Trades[size] (NumericArray);
vars:
loop (00),
CurrentEquity (00),
EquityHigh (00),
CurrentDrawDown (00),
MaxDrawdown (00),
val(0)
;
loop = 0;
//Why has this variable to be resetted?
//Function is with function storage: simple
value1 = 0;
while loop <= array_getmaxindex(Trades) begin
value1 = value1 + Trades[loop];
{ Uncommenting the line below - strangely - seemingly
goes around the bug somehow and returns correct results. }
// if Trades[loop] < 0 then value1 = Trades[loop];
loop += 1;
end;
elbug_funct = value1 ;
Re: Bug in the EL core compiler/interpreter
Wow. I asked for the support of extremely senior developers - and I got it.
I appreciate both of you guy's help, time and advice.
Thank you!
I appreciate both of you guy's help, time and advice.
Thank you!
Re: Bug in the EL core compiler/interpreter
Hey Everyone,
Just an update here:
- I would definitely say this is a bug,
- The "factory defined" value1 variable has no impact on this, it happens with any variable,
- rrams solution actually didn't solve it, but wegi's solution does make the code behave as expected.
Anyway - I don't know if it's high enough priority to put in the project management system, I know MC team is busy fixing the unexpected behaviors of v14 and have plenty to work on in general. So we're all just better off initializing the variables at the starts of functions I guess.
-Ben
Just an update here:
- I would definitely say this is a bug,
- The "factory defined" value1 variable has no impact on this, it happens with any variable,
- rrams solution actually didn't solve it, but wegi's solution does make the code behave as expected.
Anyway - I don't know if it's high enough priority to put in the project management system, I know MC team is busy fixing the unexpected behaviors of v14 and have plenty to work on in general. So we're all just better off initializing the variables at the starts of functions I guess.
-Ben
Re: Bug in the EL core compiler/interpreter
Hey Everyone,
A second update. I don't think this has anything to do with arrays anymore. It is due to what is probably a design flaw in the interpreter itself, and what it looks like is when you call a function multiple times with different parameters in the same piece of code on the same bar, the variables in it will not be reset automatically. The easiest way to see it is if you take an input parameter and you add it to the variable's existing value with += or similar. I seriously doubt this is intentional and under certain circumstances it can have serious and far reaching consequences. Please check your code if you operate under such conditions.
-Ben
A second update. I don't think this has anything to do with arrays anymore. It is due to what is probably a design flaw in the interpreter itself, and what it looks like is when you call a function multiple times with different parameters in the same piece of code on the same bar, the variables in it will not be reset automatically. The easiest way to see it is if you take an input parameter and you add it to the variable's existing value with += or similar. I seriously doubt this is intentional and under certain circumstances it can have serious and far reaching consequences. Please check your code if you operate under such conditions.
-Ben
-
TJ
- Posts: 7743
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2222 times
Re: Bug in the EL core compiler/interpreter
TJ, man, come on, this is dummy code written for just the purpose of demonstrating this bug.
Re: Bug in the EL core compiler/interpreter
Just a comment Dude: I didn't know this was even supported:
Did you try ?:
It's been my experience that the interpreter parsing is weak.
I remember banging my head against the wall on this one:
Begin Once
Value1 = 10;
End;
Important: No error was thrown, but it wasn't working.
Then I had been told THAT'S NOT SUPPORTED, You must do this:
Once Begin
Value1 = 10;
End;
I was like: "Why wasn't an error thrown ?" Welcome to Power Language....full of surprises.
Code: Select all
negnum+=Trades[loop];
loop+=1;Code: Select all
negnum=negnum + Trades[loop];
loop = loop + 1;I remember banging my head against the wall on this one:
Begin Once
Value1 = 10;
End;
Important: No error was thrown, but it wasn't working.
Then I had been told THAT'S NOT SUPPORTED, You must do this:
Once Begin
Value1 = 10;
End;
I was like: "Why wasn't an error thrown ?" Welcome to Power Language....full of surprises.