stevehopwoodforex.com
https://www.stevehopwoodforex.com/phpBB3/
Print view

Slopey Peaky Bob
https://www.stevehopwoodforex.com/phpBB3/viewtopic.php?t=5389
Page 22 of 84
Author:  SteveHopwood [ Sat Jun 23, 2018 4:25 pm ]
Post subject:  Slopey Peaky Bob

V 1q is in post 1:
  • Added a pips trailing stop. Details in the user guide. Also added extra functionality so that SPG saves the value of a trailing stop in a Global Variable (small filed held on your disk drive), so SPB can pick up where he left off following a platform restart.
  • Added the trading done for the week thingy - details in the user guide.
  • Thomas and Rene developed a function to return a pair's pip factor that should accommodate just about anything thrown at it, so I have replaced the existing function with theirs.
I have updated the UG in line with the way that SPB has evolved into a basket trader as well as giving the Tests Database a plug. I added an ATR explanation. There were some typos that I spotted and a couple of factual inaccuracies that I amended. I have added the "Peak HiLo Indicator" pdf to post one; this pdf explains how to use the indi in greater detail than in the UG.

SUPERIMPORTANT NOTE TO ATR USERS. Zennor's post just a bit higher up made me realise that the GridAtrMultiplier input was an incorrect input. I have changed it to GridAtrDivisor, so SPB will nod divide the ATR reading by GridAtrDivisor to get the distance betw[*]een the grid trades.

DIY enthusiasts and people who want to check my code, here is how to find it:
  • Do a search for "//Addition to John's code". This will take you to lines:
    • 285
    • 721
    • 5575
    • 5601
    • 5630
    • 5660
  • Do a search for "//Trading done for the week stuff". This will take you to lines:
    • 353
    • 699
    • 1022
    • 5752
    • 5841
    • 5928
  • Do a search for "//Thomas and Rene provided this pip factor function. Thanks guys." Copy the new code over the top of your existing function.
:xm: :rocket:
Author:  SteveHopwood [ Sat Jun 23, 2018 6:21 pm ]
Post subject:  Slopey Peaky Bob

Zennor has just emailed to say I put the wrong user guide into post 1. :arrrg: The correct one is now in place. Thanks Zennor :clap: :clap: :clap:

:xm: :rocket:
Author:  SteveHopwood [ Sat Jun 23, 2018 7:38 pm ]
Post subject:  Slopey Peaky Bob

Kopan just emailed me with something I meant to ask the Real Coders when I posted 1q a couple of posts up.

This code snippet throws up a warning of, "possible loss of data due to type conversion" at compilation time:
//Extract the time.
datetime WeekStartTime = GlobalVariableGet(DoneForTheWeekGV);

Empty4 datetime variables are stored as integer values based on the number of seconds to have elapsed since Jan 1st 1970 - hence the massive values stored in the DoneForTheWeekGV global. It easily converts the seconds back into a usable date once they are extracted, yet the bloody compiler still sends this blasted warning.

The warning means nothing here but will spook the less experienced DIY enthusiasts. It bloody well annoys me.

Any of you guys know what to do to suppress this blasted warning?

:xm: :rocket:
Author:  tomele [ Sat Jun 23, 2018 8:00 pm ]
Post subject:  Slopey Peaky Bob

Hi Steve.

Try: datetime WeekStartTime = (datetime) GlobalVariableGet(DoneForTheWeekGV);

...beep...
Thomas
SteveHopwood » 23 Jun 2018, 20:38 wrote:Kopan just emailed me with something I meant to ask the Real Coders when I posted 1q a couple of posts up.

This code snippet throws up a warning of, "possible loss of data due to type conversion" at compilation time:
//Extract the time.
datetime WeekStartTime = GlobalVariableGet(DoneForTheWeekGV);

Empty4 datetime variables are stored as integer values based on the number of seconds to have elapsed since Jan 1st 1970 - hence the massive values stored in the DoneForTheWeekGV global. It easily converts the seconds back into a usable date once they are extracted, yet the bloody compiler still sends this blasted warning.

The warning means nothing here but will spook the less experienced DIY enthusiasts. It bloody well annoys me.

Any of you guys know what to do to suppress this blasted warning?

:xm: :rocket:
Author:  SteveHopwood [ Sat Jun 23, 2018 9:50 pm ]
Post subject:  Slopey Peaky Bob

tomele » Sat Jun 23, 2018 8:00 pm wrote:Hi Steve.

Try: datetime WeekStartTime = (datetime) GlobalVariableGet(DoneForTheWeekGV);

...beep...
Thomas
It works folks. Try it.

Why it is so hard for the rest of us peasants to discover this information is a surprise to me. Rene introduced me to this concept a while ago. So why is it so bloody hard to use the info going forward?

Hey ho.

:xm: :rocket:
Author:  tomele [ Sat Jun 23, 2018 10:09 pm ]
Post subject:  Slopey Peaky Bob

Sometimes picturesque explanations help me understand things.

Look at it this way: A global variable is a double you can store whatever in. If you store a datetime in it, it is a double representing an integer representing a datetime value.

If you want to convert it back to a datetime, the compiler gets insecure. You could try to convert "threepinkunicorns" to a datetime, which would be of no avail. In strict mode, it will warn you until you explicitely tell it that you know what you are doing.

The "(datetime)" tells the compiler not to worry anymore and that the master knows there is a datetime stored that shall be converted. All is good then.

...beep...
Thomas


SteveHopwood » 23 Jun 2018, 22:50 wrote: It works folks. Try it.

Why it is so hard for the rest of us peasants to discover this information is a surprise to me. Rene introduced me to this concept a while ago. So why is it so bloody hard to use the info going forward?

Hey ho.

:xm: :rocket:
Author:  SteveHopwood [ Sat Jun 23, 2018 10:40 pm ]
Post subject:  Slopey Peaky Bob

tomele » Sat Jun 23, 2018 10:09 pm wrote:Sometimes picturesque explanations help me understand things.

Look at it this way: A global variable is a string you can store whatever in. If you store a datetime in it, it is a string representing an integer representing a datetime value.

If you want to convert it back to a datetime, the compiler gets insecure. You could try to convert "threepinkunicorns" to a datetime, which would be of no avail. In strict mode, it will warn you until you explicitely tell it that you know what you are doing.

The "(datetime)" tells the compiler not to worry anymore and that the master knows there is a datetime stored that shall be converted. All is good then.

...beep...
Thomas
Thanks Thomas. I get what you are saying. You have seen my use of Rene-taught (int) incidences many times in my code.

There must be a lot of (something) stuff available to us. How do we find it?

:xm: :rocket:
Author:  tomele [ Sat Jun 23, 2018 11:24 pm ]
Post subject:  Slopey Peaky Bob

Yes, there is a very comprehensive explanation here: https://docs.mql4.com/basis/types/casting

But I (as we all) like things simple.

As long as you dont add the compiler "strict" directive to your code, you can implicitely cast one data type to another. You can assign a double to an integer, a string to a double and so on, the compiler takes care to do the best of it. The result is not always what you would expect.

In "strict" mode, the compiler warns you of every implicit conversion. You must be explicit and confirm any conversion. You do this by preceding the expression with ("type"). "type" can be every data type you want the result being transformed to. You have the total control - and responsibility. Of course, the type you cast to must be the type of the variable you want to assign the result to. Examples:

int yyy=1245689; string xxx= (string) yyy;
int zzz=1231; double qqqq= (double) zzz;
int ddd=1234567; datetime ttt= (datetime) ddd;

This works with nearly all data types in MQ4. You can typecast nearly everything into everything. Whether it makes sense is your responsibility. There are functions to do more specific conversions like MathRound, DoubleToString etc. and you should always be very aware what you are doing when adding a ("type") to a statement.

Hope this helps.

SteveHopwood » 23 Jun 2018, 23:40 wrote: Thanks Thomas. I get what you are saying. You have seen my use of Rene-taught (int) incidences many times in my code.

There must be a lot of (something) stuff available to us. How do we find it?

:xm: :rocket:
Author:  DigitalCrypto [ Sun Jun 24, 2018 2:41 am ]
Post subject:  Slopey Peaky Bob

I thought the global variables were always stored as int/double as specified by the value pushed into them. It never occurred to me it was being stored as a string type. So this helped me too. I wouldn't know to go looking that deep for the answer. Thank you Thomas.

Note: Now that I know this I can probably trade my offline charts by setting global variables using an indicator in an offline chart and reading them in an EA on a regular chart. I will find out when the markets are open for testing.
Author:  tomele [ Sun Jun 24, 2018 8:31 am ]
Post subject:  Slopey Peaky Bob

DigitalCrypto » 24 Jun 2018, 03:41 wrote:I thought the global variables were always stored as int/double as specified by the value pushed into them. It never occurred to me it was being stored as a string type. So this helped me too. I wouldn't know to go looking that deep for the answer. Thank you Thomas.

Note: Now that I know this I can probably trade my offline charts by setting global variables using an indicator in an offline chart and reading them in an EA on a regular chart. I will find out when the markets are open for testing.
Hi DC.

You are right. A global variable is always a double, not a string. I mixed up something. I corrected that in my post.

Cheers
Thomas
All times are UTC Page 22 of 84