MC/EL frequently triggered traps (how to avoid)

Read before posting.
bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

MC/EL frequently triggered traps (how to avoid)

Postby bowlesj3 » 11 Aug 2010

This thread has evolved into a summary area of potential traps that new users can fall into if they are not aware of them. These are not bugs but rather items that will not likely change for a long time (if ever). It is a series of pointers to threads (or any material for that matter) that contain the information on the trap and how to avoid it. If you have something to add you can just create a post. It could be an existing topic covered. Janus and I have started it off.

Tricky areas of MC's EL programming:
============
1/ IntraBarPersist (variables getting reset if you do not use it) (Drawing object IDs should not use it).
viewtopic.php?f=5&t=6871


2/ MaxBarsBack (and the hidden recalculate)
viewtopic.php?f=5&t=7362


3/ MCs habit of deleting new drawing objects (Arw,Text,TL) once the last bar on chart has been reached and doing this until BarStatus=2.
viewtopic.php?f=5&t=6871 (same thread as intrabarpersist)

4/ Moving trend lines.
viewtopic.php?f=5&t=7598

5/ Care needs to be taken when deleting drawing objects (Arrows, Text, Trend Lines) from different studies on the same chart. Quick tip. Where possible create them on currentbar=1 and hide them when not in use so you avoid the problem.

6/ Large if statements (with many levels of if) can become tricky. Here is a numbering idea. Some formatting ideas exist in posts below.
viewtopic.php?f=5&t=7142

7/ Computing a new time in seconds is a bit tricky.
TimeToSeconds_S and SecondsToTime can be used. Here is a function as well.
viewtopic.php?f=5&t=6862
viewtopic.php?f=5&t=5934 (older version)




-------------------------------------------------------
Has this post been helpful to you?
Last edited by bowlesj3 on 15 Aug 2010, edited 18 times in total.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: For users new to MC who do not know about intrabarpersis

Postby janus » 11 Aug 2010

I also feel sorry for new users, not just because of what you have highlighted but also for a lot of other quirks. I've posted some over the past months (eg, duplicate update ticks) and have just recently discovered two more traps. One involving limit orders and how they are cancelled and re-submitted when a new market order is submitted (bad as it loses your position on the queue at the exchange for those brokers that allow your orders to be sent through). The other where a multi-contract buy at market order returned on the next update tick a value for the MarketPosition_at_Broker less than the number contracts that were supposed to be filled. I think I understand why this happens sometimes. So, just checking that MarketPosition_at_Broker is > 0 is not enough to know if the order has been completely filled. I should be checking if the number equals the expected value, or the increment if already long. I'm now testing the new keyword EntryName to see if this also helps. These and many other quirks in the way MC (and TS) does things creates a minefield for new users, and for that matter any user. What we need is a list of these quirks in the form of a consolidated repository on this forum so all users can be aware of them. We should have any new quirk discussed first in a separate thread to verify it is real, and if it is add it to the repository. This is more than just a "hints and tips" list as it goes deeper into the way MC works. It should contain example code and a brief discussion as to what is happening and why, plus where possible a workaround.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Re: For users new to MC who do not know about intrabarpersis

Postby bowlesj3 » 12 Aug 2010

Removed.
Last edited by bowlesj3 on 15 Aug 2010, edited 2 times in total.

User avatar
RobotMan
Posts: 375
Joined: 12 Jul 2006
Location: Los Altos, California, USA
Has thanked: 31 times
Been thanked: 13 times
Contact:

Re: For users new to MC who do not know about intrabarpersis

Postby RobotMan » 13 Aug 2010

My entry in the sticky would read:
IntraBarPersist: Not for the faint of heart.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Re: For users new to MC who do not know about intrabarpersis

Postby bowlesj3 » 13 Aug 2010

I have revised the subject and the first post.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: For users new to MC who do not know about intrabarpersis

Postby janus » 14 Aug 2010

I have revised the subject and the first post.
Good idea, - and nice start.


A general comment on if then else blocks.
I often see the following style used in studies:

Code: Select all

if condition then
begin
....
....
end
else
begin
...
...
end;
The one above is not that bad but I've seen other styles that are so confusing I had to reformat them to make sense of the flow.
I much prefer:

Code: Select all

if condition then begin
....
....
end else begin
...
...
end;
Maybe it's just me but it looks tidier and less confusing. I think it's because I've coded in FORTRAN a long time ago and that's how the blocking style looked like. Of course most other languages don't require the begin, and often don't use the intermediate end statements, and use endif instead of the last end, but that's not the point here.

The general comment and advice to programmers in EL is to use one of the two styles above.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Re: MC frequently triggered traps (how to avoid)

Postby bowlesj3 » 14 Aug 2010

Interesting idea Janus. They end up looking like well formated statements in other languages which are naturally suited to this style due to the fact that they do not have a "begin" and "end" part of the construct. I agree and the main thing is the end statement is on the same indent column as the if statement (as is the else statement too). You can still number them if you wish as my thread above suggests to help with moving about large amounts of code (including a copy of the number to both the else and end statement). I find the numbering handy when I copy chunks of code to the 10 second bar studies.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: MC frequently triggered traps (how to avoid)

Postby janus » 14 Aug 2010

I tend to document each block as well. For example:

Code: Select all

if condition then begin // comment 1
....
....
end else begin // comment 2
...
...
end;
I allows me to understand what each block is doing without reading the code to get an overall view of the flow of the complete study. I do the same with case statements.

Yes, the indentation is the same as in other languages. For example in FORTRAN, VB, PowerBasic and other similar Basic based languages it would be:

Code: Select all

if condition 1 then
....
....
else
....
....
end if
In C++:

Code: Select all

if condition 1
{
...
...
}
else
{
...
...
}
which actually looks more like the first EL example I posted earlier. It's just that the extra begin and end statements in EL I think tends to muddy it a bit, which is why I prefer the second EL example (and FORTRAN is in my brain).

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Re: MC frequently triggered traps (how to avoid)

Postby bowlesj3 » 14 Aug 2010

I sometimes comment the first if statement as you like to do (after the number I have assigned if I have chosen to do that) then copy the actual if statement down to the very end and have it on the line of the end statement within the {} brackets so I know exactly what if statement it is. This works okay as long as the if statement does not change and I do not forget to change the copy at the bottom. If I do forget I just update it when I notice it later. I sometimes use these methods in my other program.

I have a friend that reads IBM assembler often and at times programs traps for it. They are told they must have a comment on every single line of code. I often wish I had done this when I come back to my code and only do that when I have figured out what I did after the fact. I find that you get better comments when you come back and have those unanswered questions about it. Comments applied at the start often are not as helpful later since you have no way of anticipating the future questions. However as long as the code is easy to read it is often helpful.

I often mark large blocks of related code (which has no if statement) with a sandwich comment like this so I know where the related code starts and ends.

Code: Select all

{START: code that does whatever function.}
. . .
. . .
. . .
{END: code that does whatever function.}
It can be blocks of related variables as well. The comment after the "Start:" and "End:" marker is an exact match for both.

If the main one line comment needs explaining I indent it.

Code: Select all

{START: code that does whatever function.}
{ details}
{
Another format for details
Another format for details
}
. . .
. . .
. . .
{END: code that does whatever function.}
This simple technique often saves time. EL can't do this but in languages where a function can be created in the same module I at times I will create a function to do this "block of related code" documenting even if the function was only called once but normally I won't since this is easier and you could end up with a lot of single call functions.

I just devised another technique where this block becomes very very large. It is an after the fact technique.

Code: Select all

{START: code that does whatever function.}
. . .
. . .
. . .
. . .
. . .code you are investigating {INSIDE: code that does whatever function.}

. . .
. . .
. . .
. . .
{END: code that does whatever function.}
The comment after the word INSIDE: is an exact match to the START: and END: comment. This technique helps you keep aware of where you are (what block you are looking at).
Last edited by bowlesj3 on 16 Aug 2010, edited 3 times in total.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: MC frequently triggered traps (how to avoid)

Postby janus » 14 Aug 2010

II have a friend that reads IBM assembler often and at times programs traps for it. They are told they must have a comment on every single line of code.
I started out writing 1000's of line of assembler on various systems (PDP, VAX-VMS, Motorola, etc.) and I also found commenting each and every line to be well worth it. In fact, going over my own code at the time without comments was a waste of time - it was often quicker to re-write the code from scratch. This is why commenting is so useful, even in higher level languages of today. When I finished with a study now, I often go back and put in extra comments to make sure I can quickly go over it in the future without wasting time trying to decipher what I did. It also takes a special breed of person to enjoy doing this - I love programming. It's so challenging. Having said this one can go too far, and I do have a life, as we all should do.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Re: MC frequently triggered traps (how to avoid)

Postby bowlesj3 » 15 Aug 2010

I originally trained in Assembler, Cobol and RPG (LOL, using cards). Cobol instructors taught us to use long variable names and function names, which were self documenting. I have always done this and in this sense I have effectively documented every single line of code right from day one. I normally do not place extra comments on every line unless the code is complex and I figure I will have problems on a revisit later. It is a judgement call. Beginning programmers using EL as their first language should develop this habit too so I guess this is a good discussion for this thread.

Regarding assembler, it has just occurred to me (for the very first time actually) that since it is essentially machine language, the assembler format of machine language was most likely created because the machine language printout has no way of being self documenting (due to its crammed nature). By creating the assembler format of machine language they effectively just reformatted the visual presentation into "one line per operation code" so there was room to put a comment on each line of code and make it self documenting just like Cobol was at that time. It also allows one to see the goto branches visually. I think I just figured out the difference between the assembly process and the compile process (never really understood the difference until now). In short assembler has no functions (except branch and link) and thus assembly is a simpler process of reformatting the (one operation code per line format of assembler) into (crammed machine language format) for machine reading. In short, much less work.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Re: MC/EL frequently triggered traps (how to avoid)

Postby bowlesj3 » 12 Sep 2010

Regarding (lining up the ending of the if statement the way other languages do) I came up with a unique way to simulate this in EL. It is in the thread below near the buttom (as of 2010/Sep/12 at the very bottom).

viewtopic.php?f=5&t=7142


Return to “MultiCharts FAQ”