Trading made REALLY Simple: Coder's Chat

[gg53]

simplex wrote:

Ok, first of all I tried to get a grip on your ‘never trade against it’ rule, and failed. Maybe it’s just my noob interpretation of what that rule really means. Some USD based examples on H4, showing your plain and USDx version of ForexGT Dollar Index.

• AUDUSD: nearly perfect, but the reversal at the right end seems to be better resolved by the ‘plain’ version.
• EURUSD: not so perfect, looking at the left end, perfect for the rest. And again: the reversal at the right end is better resolved by the ‘plain’ version.
• GBPUSD: absolutely perfect.
• USDCAD: nearly perfect, but the reversal at the right end appears to be better resolved by the ‘plain’ version.
• USDJPY: trend lines on the indicators are contrary to price trend.

You seem to be very confident about your rule, so my simple interpretation is probably wrong. What does ‘never trade against it’ really mean? s.

By watching the USDx indicator, you are looking on just one side of the coin.

If one other currency (x) is much stronger compared to a rising USD – that will be the result.

In those cases I still DON’T trade against a rising USD, and search for a weaker currency then currency (x), that is pointing down, to trade against currency (x).

 

This way your trade will be safer, less risky, and yield more pips. There is no point in trading two strong currencies against one another.

 

G.

• This reply was modified 10 years, 3 months ago by gg53.

[smallcat]

gg53 wrote:

By watching the USDx indicator, you are looking on just one side of the coin. If one other currency (x) is much stronger compared to a rising USD – that will be the result. In those cases I still DON’T trade against a rising USD, and search for a weaker currency, pointing down, to trade against currency (x). This way your trade will be safer, less risky, and yield more pips. There is no point in trading two strong currencies against one another. G.

Nice information G .  @simplex : Thanks for your new toy clear Channel  …

[simplex]

Hi @VlanFx

I think that I have a solution now regarding our Partial Closing vs. Moving SL to BE issue. My solution aims to address both functions independently from each other, with no logic interdependence. Also the triggers for both values are volatility based using ATR multiples. Partial close will only be performed once per original trade.

Still needs a bit more testing and code cleaning, but I’m confident to send you my version tomorrow (embedded in an EA to check the functions).

s.

A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)

[gg53]

simplex wrote:

Hi @VlanFx I think that I have a solution now regarding our Partial Closing vs. Moving SL to BE issue. My solution aims to address both functions independently from each other, with no logic interdependence. Also the triggers for both values are volatility based using ATR multiples. Partial close will only be performed once per original trade. Still needs a bit more testing and code cleaning, but I’m confident to send you my version tomorrow (embedded in an EA to check the functions). s.

My preference is that all functions be independent, for user chice which one to implement. Later we’ll issue guidelines of the implication of each and the mutual effect, if any.

While In Trade, it preferably should look like this:

If InTrade()

TrailingStop();

BreakEven();

TrailingProfit();

etc…

ExitTrade(…on opposite signal…before SL)

 

G.

[simplex]

I absolutely agree:

gg53 wrote:

My preference is that all functions be independent, for user chice which one to implement.

That would also lead to a well-structured design based on exchangeable modules instead of a monolithic design that’s getting harder to manage with each additional feature.

To make single modules exchangeable, it’s also required to refrain from any use of global (input) variables inside those functions. Every function should internally use only local variables / parameters or parameters which are passed by reference when calling it. At the moment, we’re not very close to this preferred goal.

This will look a bit bulky at first sight, but it enhances the modularity of the overall design, making code maintenance easier in future.

To reduce the number of variables that need to be passed to a single function (bulkiness) and further enhance the serviceability of our code, declaration of meaningful ‘complex data types‘ struct ... is most useful. This not only enhances flexibility of single modules, it also makes the overall code much easier to understand. Those structures will automatically provide a logical bracket that keep together variables describing different aspects of the same objects. It will enhance the stability of functions’ interfaces when it comes to functional supplements. What often provokes a severe coding / debugging workload and is error prone is the urge to change a function’s interface when functional addendums are required. Clever use of complex data types can reduce this workload to ‘almost’ zero.

In general: the fewer global variables, the better.

s.

• This reply was modified 10 years, 3 months ago by simplex. Reason: Link added

A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)

[smallcat]

simplex wrote:

…  Clever use of complex data types can reduce this workload to ‘almost’ zero. In general: the fewer global variables, the better. s.

Hi Simplex,

Could you please give reason of using limited global variables ? As we know it is a good choice to call some result from other file (it is better, compared to using database just to access some small data) … Is it because of security reason ?

Thanks

[smallcat]

smallcat wrote:

Nice information G . @simplex : Thanks for your new toy clear Channel …

Adding adaptive MA & clear Signal to the Channel on M15.  Higher TF is set to M30 in example.  Promising of a good result (not forward testing yet)  …

Attachments:

You must be logged in to view attached files.

[smallcat]

gg53 wrote:

My preference is that all functions be independent, for user chice which one to implement …

This is nice G … but we must make sure that in each Function, there is a  “rule” so they are not opposing each other all time.  Lets say Function A moves the SL to level X , then Function B (based on its logic) moves the SL to level Y. After some seconds, Function A moves it again to level X … a endless dynamic moving that can cause our MT4 freeze …

[ edit: image is double posted, it is deleted … ]

[fuzzy]

Here is the latest NewsCalendar stuff.

Talking about  Globals.   I wacked the whole thing into a class to encapsulate it, as I didn’t want the array exposed.  I was thinking about it last week and talked myself into it over the weekend.

The only global I now have is the NewsCalendar object that will sit in the indicator or EA.

Did some more optimisation re: unnecessary file and web access and also added a random factor to the frequency of web access so we don’t have everyone trying to download at the same time.

I’ll leave it there for the moment I think, see what everyone thinks.

 

Attachments:

You must be logged in to view attached files.

[smallcat]

fuzzy wrote:

Here is the latest NewsCalendar stuff. Talking about Globals. I wacked the whole thing into a class to encapsulate it, as I didn’t want the array exposed. I was thinking about it last week and talked myself into it over the weekend. The only global I now have is the NewsCalendar object that will sit in the indicator or EA. Did some more optimisation re: unnecessary file and web access and also added a random factor to the frequency of web access so we don’t have everyone trying to download at the same time. I’ll leave it there for the moment I think, see what everyone thinks.

Great Fuzzy … Thanks for your hard work

[simplex]

@smallcat and everybody else interested:

smallcat wrote:

Could you please give reason of using limited global variables ?

Maybe try to change your view on our community project for a short while: consider we’re not only coding one EA, but a collection of flexible and exchangeable trading software modules instead. The overall goal of these modules should be to facilitate coding an EA, and the EAs which are the result of our work are happily accepted as a byproduct.

As for global variables, let’s look at a trailing stop function for example. There’s certainly more than only one algorithm to solve this task. We’re starting with algorithm A and implement it:

bool TrailStopA(...) {
   if (globalTrailingDistance > 0) {
      ...
      double myLocalVar = someLocalVar + (globalTrailingStep + point) * point;
      ...
   }
}

You see, that function TrailStopA() uses global variables of EA-wide scope to do its job. That way it is interlocked with the EA itself. If you now get a different idea about a TS (let’s say ATR based instead of fixed pips amount) you would write a new function TrailStopB() which uses different global variables. It would work, if done properly.

Now consider you have another EA and want to use one of your TS functions in that one. Could you easily implement your function over there? Obviously no: if that EA has different global variable names for TS, you would have to recode your function. That’s not complicated, but a nagging and unnecessary work.

Let’s consider your original function looked this way:

bool TrailStopA(double localTrailingDistance, double localTrailingStep) {
   if (localTrailingDistance > 0) {
      ...
      double myLocalVar = someLocalVar + (localTrailingStep + point) * point;
      ...
   }
}

Now the TS algorithm works on local parameters, which are handed over at the function’s interface. You do not have to change the function’s code when copying it to another EA. A first step to reusable code is done.

The next step might be to move a little bit towards OOP approach. Let’s consider your task does not require 2 parameters, but 10. Your function’s interface would be a bit bulky, and with every new parameter you would have to change not only its interface, but also those 37 code snippets in different projects where you have used your function. Not nice!

Simple workaround: all properties that describe our TS are packed in one complex data structure:

struct trailingStopParameters {
   double trailingDistance;             // trailing distance
   double trailingStep;                 // trailing step
};

trailingStopParameters tsParameters;

You would have to initialize your structure once (maybe in event handler OnInit), and then your function would look like this:

bool TrailStopA(trailingStopParameters tsParm) {
   if (tsParm.trailingDistance> 0) {
      ...
      double myLocalVar = someLocalVar + (tsParm.trailingStep+ point) * point;
      ...
   }
}

It would be called by something like:

if ( TrailStopA(tsParameters) ) {

   ...

}

Simple, ok? And now for the really valuable part!

What if months later (!!!) you think that it would be a good idea to pass some trigger value to your TS function to tell it whether to get active or not? Do you have to change all those 37 code lines where you have used your function until now? No, you just add the new property to your structure:

struct trailingStopParameters {
   double trailingDistance;             // trailing distance
   double trailingStep;                 // trailing step
   double triggerValue;                 // TS trigger
};

and use it inside your function:

bool TrailStopA(trailingStopParameters tsParm) {
   if (tsParm.triggerValue > 0) {
      ...
   }
   if (tsParm.trailingDistance> 0) {
      ...
      double myLocalVar = someLocalVar + (tsParm.trailingStep+ point) * point;
      ...
   }
}

Please note: the function’s interface will not be touched, so you don’t have to change all those code lines where you used it in the past. The only thing you have to care for is to properly initialize the new member of your structure.

More than that, the structure keeps together all parameters that are required to describe your trailing stop algorithm. So it acts as a logical bracket connecting all the properties of one object.

A lengthy post. @smallcat and everybody else: I hope I managed to describe my view on this topic in a comprehensible way.

Any questions / comments / critical addendums?

s.

(Hmmm … I really hope that code formatting works inside this post!)

A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)

[simplex]

One additional remark for those who are not familiar with the concept of complex data types: in my above example, I only used structure members of type double. Please note that this could be any data type:

struct trailingStopParameters {
   double trailingDistance;             // trailing distance
   double trailingStep;                 // trailing step
   double triggerValue;                 // TS trigger
   bool useTrigger;
   datetime timeToCheck;
   string comment;
   int counterStart;
};

All of them handed over to the receiving function by only one parameter!
Try to imagine the implications for your software design from a higher point of view.
s.

A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)

[simplex]

Great!

fuzzy wrote:

Here is the latest NewsCalendar stuff. Talking about Globals. I wacked the whole thing into a class to encapsulate it, as I didn’t want the array exposed.

As I posted somewhere else in this forum, I made the first steps of my ‘coding career’ using IBM punchcards and a language named FORTRAN 77 (now it’s up to you to make a guess about my physical age ) Anyway, OOP was not yet invented in those times.

Until now, I failed to get a good grip on the OOP approach. An experienced OOP tutor is what I need.

I will study your class code from a student’s point of view, and I hope you don’t mind if I post some noob questions as an OOP newbie.

I’m not convinced that it makes sense to encapsulate each and every bit of code in a class or something, but I’m really interested to learn about the details that make the difference. When it comes to creating reusable code, OOP is certainly state of the art.

s.

A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)

[smallcat]

simplex wrote:

@smallcat and everybody else interested:

smallcat wrote:

Could you please give reason of using limited global variables ?

Maybe try to change your view on our community project for a short while: consider we’re not only coding one EA, but a collection of flexible and exchangeable trading software modules instead. The overall goal of these modules should be to facilitate coding an EA, and the EAs which are the result of our work are happily accepted as a byproduct. As for global variables, let’s look at a trailing stop function for example. There’s certainly more than only one algorithm to solve this task. We’re starting with algorithm A and implement it:

bool TrailStopA(...) {
if (globalTrailingDistance > 0) {
...
double myLocalVar = someLocalVar + (globalTrailingStep + point) * point;
...
}
}

You see, that function TrailStopA() uses global variables of EA-wide scope to do its job. That way it is interlocked with the EA itself. If you now get a different idea about a TS (let’s say ATR based instead of fixed pips amount) you would write a new function TrailStopB() which uses different global variables. It would work, if done properly. Now consider you have another EA and want to use one of your TS functions in that one. Could you easily implement your function over there? Obviously no: if that EA has different global variable names for TS, you would have to recode your function. That’s not complicated, but a nagging and unnecessary work. Let’s consider your original function looked this way:

bool TrailStopA(double localTrailingDistance, double localTrailingStep) {
if (localTrailingDistance > 0) {
...
double myLocalVar = someLocalVar + (localTrailingStep + point) * point;
...
}
}

Now the TS algorithm works on local parameters, which are handed over at the function’s interface. You do not have to change the function’s code when copying it to another EA. A first step to reusable code is done. The next step might be to move a little bit towards OOP approach. Let’s consider your task does not require 2 parameters, but 10. Your function’s interface would be a bit bulky, and with every new parameter you would have to change not only its interface, but also those 37 code snippets in different projects where you have used your function. Not nice! Simple workaround: all properties that describe our TS are packed in one complex data structure:

struct trailingStopParameters {
double trailingDistance; // trailing distance
double trailingStep; // trailing step
};

trailingStopParameters tsParameters; You would have to initialize your structure once (maybe in event handler OnInit), and then your function would look like this:

bool TrailStopA(trailingStopParameters tsParm) {
if (tsParm.trailingDistance> 0) {
...
double myLocalVar = someLocalVar + (tsParm.trailingStep+ point) * point;
...
}
}

It would be called by something like:

if ( TrailStopA(tsParameters) ) {

...

}

Simple, ok? And now for the really valuable part! What if months later (!!!) you think that it would be a good idea to pass some trigger value to your TS function to tell it whether to get active or not? Do you have to change all those 37 code lines where you have used your function until now? No, you just add the new property to your structure:

struct trailingStopParameters {
double trailingDistance; // trailing distance
double trailingStep; // trailing step
double triggerValue; // TS trigger
};

and use it inside your function:

bool TrailStopA(trailingStopParameters tsParm) {
if (tsParm.triggerValue > 0) {
...
}
if (tsParm.trailingDistance> 0) {
...
double myLocalVar = someLocalVar + (tsParm.trailingStep+ point) * point;
...
}
}

Please note: the function’s interface will not be touched, so you don’t have to change all those code lines where you used it in the past. The only thing you have to care for is to properly initialize the new member of your structure. More than that, the structure keeps together all parameters that are required to describe your trailing stop algorithm. So it acts as a logical bracket connecting all the properties of one object. A lengthy post. @smallcat and everybody else: I hope I managed to describe my view on this topic in a comprehensible way. Any questions / comments / critical addendums? s. (Hmmm … I really hope that code formatting works inside this post!)

Hi Simplex,

Thanks a lot for this post and post #11279, very good and clear explanation … Easy to understand the reason 

And the code formatting works well, including the indent.

Thank you very much Simplex … 

[simplex]

One more thing: for a more elaborate example of how to use structures in practice, just study the latest news calendar version fuzzy posted lately.

s.

A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)

[simplex]

Great work:

fuzzy wrote:

Here is the latest NewsCalendar stuff.

I tested it, and after activating DLL import it displayed a line, except for timeframe M1. When placed on an M1 chart, every second indicator buffer ImpactBuffer is empty, so no line is displayed. I failed to find the reason in 5 minutes, so I’ll just report.

One basic question: why do you exclude bar zero in your main loop in OnInit()?

for(int i=limit-1; i>0; i–)

s.

EDIT: the M1 issue is related to the calendar file reading frequency. If this is reduced to zero, it works.

• This reply was modified 10 years, 3 months ago by simplex. Reason: additional info

A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)

[simplex]

smallcat wrote:

Lets say Function A moves the SL to level X , then Function B (based on its logic) moves the SL to level Y. After some seconds, Function A moves it again to level X … a endless dynamic moving that can cause our MT4 freeze …

I think that in one EA there should be only one function that manipulates the SL. And if there’s a good reason for two different functions doing so (one trailing stop function and one break even function) we’ve got two possibilities: either implement some sort of communication protocol between those functions so they can’t work against each other, or change our point of view and postulate that manipulating SL is one general task related to managing our trades, and this general task should be handled in one and only one function. I think the latter would be the safest and easiest way of implementation.

s.

A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)

[smallcat]

simplex wrote:

I think that in one EA there should be only one function that manipulates the SL. And if there’s a good reason for two different functions doing so (one trailing stop function and one break even function) we’ve got two possibilities: either implement some sort of communication protocol between those functions so they can’t work against each other, or change our point of view and postulate that manipulating SL is one general task related to managing our trades, and this general task should be handled in one and only one function. I think the latter would be the safest and easiest way of implementation. s.

Thanks Simplex, this is a good post. This makes sense 

[fuzzy]

simplex wrote:

Great!

fuzzy wrote:

Here is the latest NewsCalendar stuff. Talking about Globals. I wacked the whole thing into a class to encapsulate it, as I didn’t want the array exposed.

As I posted somewhere else in this forum, I made the first steps of my ‘coding career’ using IBM punchcards and a language named FORTRAN 77 (now it’s up to you to make a guess about my physical age ) Anyway, OOP was not yet invented in those times. Until now, I failed to get a good grip on the OOP approach. An experienced OOP tutor is what I need. I will study your class code from a student’s point of view, and I hope you don’t mind if I post some noob questions as an OOP newbie. I’m not convinced that it makes sense to encapsulate each and every bit of code in a class or something, but I’m really interested to learn about the details that make the difference. When it comes to creating reusable code, OOP is certainly state of the art. s.

 

 

Yeah, my career started with Z80 processors and assembler.  I enjoyed Fortran 77 in Uni but not the pencil Cards 

Definitely not a OOP pro.  It maybe that I’m getting fuzzy memory and fuzzy brained these days,  I do feel tested, and grizzle by the endless use of classes.

Structures are great – big fan.  I probably would not have encapsulated the newsCalendar into a class if it was just for myself – out of laziness

for those learning programing:

Normally, classes are used more if the code needs to be reusable, (recently I wrote myself a rainbow indicator with 20 polynomial regression lines – class is the obvious choice for the design), where in the newsCalendar class this is not case.  (It could be if you wanted an instance of newCalendar for each symbol)  But in this case it was more for encapsulation benefits such as tidiness , safety for the myriad of variables and arrays it uses.

I haven’t done to much with MQL4 for a couple of years,so pre- ver600, now that classes are provided for I will be using them more and more.

 

 

[simplex]

Yep:

fuzzy wrote:

Structures are great – big fan.

Since structures were introduced to MQL I can’t imagine how I ever got along without them!

s.

A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)

[fuzzy]

simplex wrote:

Great work:

fuzzy wrote:

Here is the latest NewsCalendar stuff.

I tested it, and after activating DLL import it displayed a line, except for timeframe M1. When placed on an M1 chart, every second indicator buffer ImpactBuffer is empty, so no line is displayed. I failed to find the reason in 5 minutes, so I’ll just report. One basic question: why do you exclude bar zero in your main loop in OnInit()? for(int i=limit-1; i>0; i–) s. EDIT: the M1 issue is related to the calendar file reading frequency. If this is reduced to zero, it works.

 

Didn’t think of M1.  I often leave bar 0 off my personal stuff so i guess I did that automatically – oops.   (my tests of indicators are usually of bar 1)

this should fix it up

 

for(int i=limit-1; i>=0; i–)
{
datetime _time = Time;
if ((int(_time)-int(lastRefresh)) > minutesRefresh*60 ||
Period() ==  PERIOD_M1)   // not more frequent than once/(minutesRefresh * minute)
{
lastRefresh = _time;
int impact = updateNewsCalendar(_time);
ImpactBuffer = impact;
if (impact == newsCalFile_NotFound) ImpactBuffer = -1;
if (impact == newsItem_noneSelected) ImpactBuffer = 0;

}
}

[fuzzy]

simplex wrote:

That would also lead to a well-structured design based on exchangeable modules instead of a monolithic design that’s getting harder to manage with each additional feature. To make single modules exchangeable, it’s also required to refrain from any use of global (input) variables inside those functions. Every function should internally use only local variables / parameters or parameters which are passed by reference when calling it. At the moment, we’re not very close to this preferred goal.

A well functioning system that has all the features listed has the potential to get quite complex on the software side.

IMHO structures and classes, implemented without using too much voodoo tricks, whilst (perhaps) beyond the amateur to implement, can more easily be modified / adapted by both the amateur and experienced programmer.

[tankhang]

Hi @Simplex

 

Thanks for your explanation..

This is what I do normally.. change the 37 code using ‘Search and Replace’..  haha..

 

Tankhang

[simplex]

Ok:

tankhang wrote:

This is what I do normally.. change the 37 code using ‘Search and Replace’.. haha..

… and do you like this kind of work? I for myself try to avoid it.

s.

A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)

[simplex]

Yep:

fuzzy wrote:

Didn’t think of M1. I often leave bar 0 off my personal stuff so i guess I did that automatically – oops. (my tests of indicators are usually of bar 1) this should fix it up

This works – thanks for it!

s.

A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)

[Author]

Posts