Desky. TDesk's trading drone.

[Ehrenmat]

Hey Matthias.

Great basic research you are doing here. I am eager to see a complete setup as soon as you are happy with it.

Cheers
Thomas

Hey Thomas!

Thank you very much. At the moment, I am working with WSPB since it causes a relatively low DD itself.

But I am still trying to find a way to optimize the overall take profit strategy dependent on the available funds. This is still a sketch from thoughts but some external input could help here: I'm thinking about a new sort of a trailing stop loss that counts in the behaviour of the overall equity over time. It came to my mind when I had some discussion about the Michaelis–Menten kinetics in terms of the underlying limited growth function.
We all have seen this approximation curve virtually: The profits number rises to some maximum relatively fast, then hovers around some pivot and then starts to fall fast again. This is when eveybody thinks: "Man, why didn't I just take the profit... But it could have gone higher though... Who knows!?".
Actually, I think we could know: In utilizing this "hovering around the presumed maximum equity over a limited time". That's my trailing stop loss theory that I'm working on. Practically, I want the trailing stop loss to climb over time as soon as the profit doesn't climb anymore. The last part can be depicted mathematically by comparing the profits ATR from one M1, M15 or H1 candle to the next. As soon as the the present profit ATR becomes smaller than the last one, the trailing stop loss climbs up by a given percentage of the distance between the highest profit and the actual SL.

I will code this in the next coming days and implement it in Desky to try it out. But to date, I don't know if the parameter "profit ATR" is a good approximation for the "hovering araound a maximum" and I have problems with the approximation of the rising trailing stop loss by a given percentage. I would rather link the amount of the profit ATR with the percentage... But as I said, it's all just thoughts at the moment.

Is this too far or too weird? What do you people think? I need your input

Cheers,

Mat

:hi:

[Wavegarrick]

Hey Matthias.

Great basic research you are doing here. I am eager to see a complete setup as soon as you are happy with it.

Cheers
Thomas

Hey Thomas!

Thank you very much. At the moment, I am working with WSPB since it causes a relatively low DD itself.

But I am still trying to find a way to optimize the overall take profit strategy dependent on the available funds. This is still a sketch from thoughts but some external input could help here: I'm thinking about a new sort of a trailing stop loss that counts in the behaviour of the overall equity over time. It came to my mind when I had some discussion about the Michaelis–Menten kinetics in terms of the underlying limited growth function.
We all have seen this approximation curve virtually: The profits number rises to some maximum relatively fast, then hovers around some pivot and then starts to fall fast again. This is when eveybody thinks: "Man, why didn't I just take the profit... But it could have gone higher though... Who knows!?".
Actually, I think we could know: In utilizing this "hovering around the presumed maximum equity over a limited time". That's my trailing stop loss theory that I'm working on. Practically, I want the trailing stop loss to climb over time as soon as the profit doesn't climb anymore. The last part can be depicted mathematically by comparing the profits ATR from one M1, M15 or H1 candle to the next. As soon as the the present profit ATR becomes smaller than the last one, the trailing stop loss climbs up by a given percentage of the distance between the highest profit and the actual SL.

I will code this in the next coming days and implement it in Desky to try it out. But to date, I don't know if the parameter "profit ATR" is a good approximation for the "hovering araound a maximum" and I have problems with the approximation of the rising trailing stop loss by a given percentage. I would rather link the amount of the profit ATR with the percentage... But as I said, it's all just thoughts at the moment.

Is this too far or too weird? What do you people think? I need your input

Cheers,

Mat

:hi:

Mat you are a Godsent , I have already implemented the changes you have made together with Steve's latest version and looking good.
I am following your posts with great interest.

Nothing is too weird about your thoughts, especially knowing when to get out. It is probably the hardest part of forex. Basically, In my manual trading I look at daily pivots converging from my buy or sell position before I close the trade. If my daily pivot moves back down in my buy direction for example I will look at closing the trade. If an ATR becomes smaller it means we are going into range mode and it would be good practice to move your stops up.

Hope we get more thoughts on this.

Thanks Mat.

Cheers
Leon.

[bodavid]

Mat,

Thank you for your creative outside the box way of thinking!

I think you are groundbreaking!


Cheers,
Ben

[lamdog330]

Hey guys.
I just updated to the new Desky 3w today.

TargetBasketCash ($0 to $500)
BasketCashPercentageTarget is 0.0

It will show "All pair basket take profit = USD $20" no matter if I set from TargetBasketCash $0 to $500.

However, if I change BasketCashPercentageTarget to from 0.0 to 2, then it will correctly show "All pair basket take profit = 100".


**As usual, I clear all variables, restart, completely re-do my set files for Desky on new chart, delete mqlcache.dat, tried on two Terminals, FALSE all other settings under All Trades Belong in Basket including UseDynamicCashTP. I've read the manual and I don't see anything else that would influence this.

[SteveHopwood]

V 3x is in post 1. There is a fix for a teensy bug; I had forgotten to apply the Friday global basket take profit (BasketFridayCashTargets etc) to the dynamic global basket TP.

More usefully is a scaling out of a losing trade function suggested by one of our recent new members, ilworking. From the updated user guide and at the end of the Trade Exits inputs:

• Scale out stop loss: this is an idea put to me by ilworking. Instead of allowing a trade that is going wrong to hit its stop loss entirely, we close parts of the original trade at successive stop out levels.
  • The inputs:
    • UseScaleOutStopLoss: turns this feature on/off.
    • NoOfLevels: the number of stop out levels you want.
  • How it works:
    • Imagine you have a 0.4 lot size buy trade open. There are 100 pips in between the order opening price and the stop loss. You have NoOfLevels set to 4. There are 4 stop out levels, 25 pips apart (i.e. 100 pip stop loss divided by 4).
    • The market falls 25 pips, so Desky closes 0.1 lots of the trade, leaving 0.3 still open.
    • The market falls another 25 pips, so Desky closes 0.1 lots of the trade, leaving 0.2 still open.
    • The market falls another 25 pips, so Desky closes 0.1 lots of the trade, leaving 0.1 still open.
    • The market falls another 25 pips, so either Desky closes the remaining 0.1 lots or the order hits its stop loss, whichever happens first.
  • The pros: we save a lot of loss on a trade that hits its full stop loss.
  • The cons: we lose profits on a trade that is part-closed before returning in our direction and hitting its take profit.

Do not use this on a live account just yet. I could not fully test the code on demo on Friday, so there might be bugs to squish.

The next step will be to work out how to scale back in if a market turns out to be in a temporary reversal. Coders will see commented out code that starts to deal with this. It is commented out because I realised that I had no idea how best to do this. I decided to let you folks play with scaling out and tell me how you want the scaling back in to work. Over to you.

[SteveHopwood]

I have re-uploaded 3x to post 1. The scaling out code was not correct but appears to be working ok now.

Copy this over the top of the existing bool scaleOutStopLoss(int ticket) function if you want to DIY:

Code: Select all

bool scaleOutStopLoss(int ticket)
{

   /*
   Called from countOpenTrades()
   
   This function examines an open trade to see if the phased stop loss should be used.
   Returns 'true' if there is a part-closure, else false.
   
   This cannot be applied to hedged trades.
   */
   
   //Check the order is still open
   if (!betterOrderSelect(ticket, SELECT_BY_TICKET, MODE_TRADES))
      return(false);
      
   //Cannot work this function if there is no stop loss
   if (closeEnough(OrderStopLoss(), 0) ) 
      return(false); 

   //Save stuff for easier typing
   int type = OrderType();
   string symbol = OrderSymbol();
   double stop = OrderStopLoss();
   double price = OrderOpenPrice();
   
   getBasics(symbol);//Always good to include this in a function

   //No further action needed if the trade is in profit
   if (type == OP_BUY)
      if (bid > price)
      {
         return(false);
      }//if (bid > price)
      
   if (type == OP_SELL)
      if (ask < price)
      {
         return(false);
      }//if (ask < price)
      
   
   //We have a trade and it is a loser. Calculate the distance
   //in between the order open price and the stop loss. The order open price
   //does not change following a partial closure. Not when tested on a GP demo, at least. Fuck
   //only knows what happens with the criminal element masquerading as 'brokers'.
   double slpips = MathAbs(price - stop);
   //Calculate the sl levels at which to partially close the trade.
   double slLevel = slpips / NoOfLevels;
   
   //A variable to tell the code that part-closure is needed.
   bool closeNeeded = false;
   //A variable to hold the calculated price at each level.
   double calculatedLevel = price;
   //A variable to hold the amount to part-close
   double lotsToClose = normalizeLots(symbol, Lot / NoOfLevels);
   //Alert(lotsToClose);
   double targetLots = 0;
   
   //Loop through the levels and set the closeNeeded bool if the market has moved to
   //the calculatedLevel price
   for (int cc = 1; cc <= NoOfLevels; cc++)
   {
            
      //Buy trade
      if (type == OP_BUY)
      {
         //The trade is losing by at least one level
         calculatedLevel-= slLevel;
         if (bid <= calculatedLevel)
         {
            //We need to know if there has already been a partial close at this stop level
            targetLots = Lot - (lotsToClose * cc);            
            if (OrderLots() > targetLots)
            {
               closeNeeded = true;
               break;
            }//if (OrderLots() > targetLots)
               
         }//if (bid <= calculatedLevel)
            
      }//if (type == OP_BUY)
      
      
      //Sell trade
      if (type == OP_SELL)
      {
         //The trade is losing by at least one level
         calculatedLevel+= slLevel;
         if (ask >= calculatedLevel)
         {
            //We need to know if there has already been a partial close at this stop level
            targetLots = Lot - (lotsToClose * cc);            
            if (OrderLots() > targetLots)
            {
               closeNeeded = true;
               break;
            }//if (OrderLots() > targetLots)
         }//if (ask <= calculatedLevel)
            
      }//if (type == OP_SELL)
      
      
      //Alert(calculatedLevel);
   }//for (int cc = 1; cc <= NoOfLevels; cc++)
   
   //Should part of the trade be closed:
   if (closeNeeded)
   {
      bool result = OrderClose(ticket, lotsToClose, OrderClosePrice(), 5, clrNONE);
      if (result)
         return(true);
   }//if (closeNeeded)
   

   //Got here, so no closure
   return(false);

}//End bool scaleOutStopLoss(int ticket)

I have added this note to the user guide:

IMPORTANT NOTE: this function can only work accurately with a fixed lot size. Using it in conjunction with variable lot sizing will give unpredictable results.

[SteveHopwood]

There is a line of code in Desky that tells him to wait for 10 seconds so that TDesk has time to initialise - you see that, "Waiting for TDesk to initialise" message when you first load him.

You can imagine how annoying it is to wait for 10 seconds to see if the latest bit of code I have added is working, so I comment this line of code out when working on the bot. I forgot to uncomment it when I uploded the latest fix.

Simply redownload Desky if this has caused the expired TDesk version error when you restart a platform that already has TDesk and Desky loaded. Alternatively, load up the source code and search for:
Comment("Waiting for TDesk to initialise.....");

If the line of code underneath is greyed out and reads:
//Sleep(10000);

then remove the "//" so that it becomes:
Sleep(10000);

[SteveHopwood]

Hey folks, here is something for you to think about. Look at this chart:

GBPJPYM5.png

Ignore that this is an M5 chart containing HGI. Ignore a lot of the yellow text apart from the spread right at the bottom. This is the demo that I am testing the scaling out stop loss. There is a buy and a sell trade taken out withing seconds of each other. Deaksy has closed out 50% of the (so far) unsuccessful sell. I took the pic during rollover, when the normal GP GJ spread of < 1 pip has widened to just over 33 pips.

The dotted red line is a sell trade stop loss. The solid red line is the Ask. You can see how close this is to triggering the stop loss and closing the trade at a stonking loss.

In the event: rollover passed; the spread returned to normal; the trade survived, just.

It was a close run thingy though.

So here is my question. Is there a demand for functionality that removes stop loss and take profit prices from open orders during x minutes before rollover, and then replaces them once the storm has passed?

Responses from experienced traders please. I am not interested in uninformed speculation.

[tomele]

Hi Steve.

Definitely yes. Otherwise the brokers have us where they can play with us.

Cheers

[SteveHopwood]

Hi Steve.

Definitely yes. Otherwise the brokers have us where they can play with us.

Cheers

No need for further response folks. What Thomas wants is what he gets.

Besides, he provided the rollover code to start with.

'twill be done.