Rikj000 / MoniGoMani

Isn't that what we all want? Our money to go many? Well that's what this framework/strategy hopes to do for you! By giving you & HyperOpt a lot of signals to alter the weights from.

Home Page:https://monigomani.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

⚡️ `mgm-hurry` - Detect initial 0 trade punishment epochs + auto restart HO if needed

Rikj000 opened this issue · comments

With MoniGoMani's current implementation it will force the bot to do 0 buys and 0 sells as a punishment when it detects impossible total weights needed or impossible triggers needed.

Which saves us the trouble from having to check the mgm-config-hyperopt against these issues.

However with unlucky random states this can also lead to an initial 750 or more epochs with 0 trade punishment epochs.
This will often lead to a not fully optimized HO due to not enough actual epochs being left in the HO.

Solution proposal

  • Detect the amount of initial epochs with 0 trade punishments with mgm-hurry
  • Add a max_initial_zero_trade_punishment_epochs_allowed setting in mgm-config
  • If no explicit random state is passed in the mgm-hurry command &
    if the amount of initial 0 trade punishment epochs exceeds over the configured max_initial_zero_trade_punishment_epochs_allowed,
  • Then make mgm-hurry abort the HyperOpt & automatically start a new one
    (With identical command/params/config, but a different random state)
  • We also need to add some max_ho_retries_allowed setting to prevent infinite loops when the user configures a mgm-config that will never be able to yield any "best" results

Note

If we could come up with a way to prevent impossible total weights needed or impossible triggers needed without 0 trade punishment epochs, then that solution would be preferred.
Since currently we do "loose" quite a few epochs to this solution.

This idea looks good but quite complex to implement and also I think that running higher number of HO won't necessarily bring better results.
Also I think there is a simpler approach in which we could try to find a way to reduce the number of punished trades during 1st HO, instead of running more and more HO hoping to find a valid epoch at some time.

This is the reason why I changed some of the default parameters in the mgm-config file and also why I proposed to change the behaviour of the punishment directly in the master strategy.
The new approach is the following (already included in the last commits of PR #247):

  1. check that there is at least one valid trend out of those configured to be tradable (by default all 3 trends tradable)
    => if not punish hard = 0 trades
  2. now that there are some effective possible buy parameters, check if at least 1 buy trade found
    => if not no need to search for sell
  3. if at least 1 buy trade check if at least one valid trend for sell
  4. if yes calculate sell weight/conditions
  5. a real valid epoch is considered, as soon as there is at least 1 buy trade and 1 sell trade
    => if not punish hard = 0 trades

from my tests, the output of that gives quicker result during 1st HO, because we give freqtrade some feedback when we have working parameters, so that it can use this to look for better parameters for the next batch of epochs.

the second part of the reflexion is to try to reduce the search space by using different parameters in the default mgm-config.
These are the changes I mase on my build :

  • max signal weight value 20 instead of 100 (threshold 2 instead of 22)
  • max number of candles for lookback : 3 instead of 8. now that we have a good separation of triggers and guards we want them to fire as closest as possible from each other. looking back 8 candles means looking in the last 4h, seems way too much for me if we want to have profitable results.
  • min trend triggers needed and search threshold = 1 since we now have a separation of triggers and guards, max number of signals in each type is 4