Skip to content
This repository has been archived by the owner on Jun 8, 2023. It is now read-only.

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

Open
Rikj000 opened this issue Jan 17, 2022 · 1 comment
Labels
Feature - Enhancement Update or improvement to existing feature Planned Planned feature, improvement or bugfix (not being worked on yet)
Milestone

Comments

@Rikj000
Copy link
Owner

Rikj000 commented Jan 17, 2022

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.

@Rikj000 Rikj000 added Feature - Enhancement Update or improvement to existing feature Planned Planned feature, improvement or bugfix (not being worked on yet) labels Jan 17, 2022
@Rikj000 Rikj000 added this to Planned in MoniGoMani - Global Development Progress via automation Jan 17, 2022
@Rikj000 Rikj000 added this to the v1.0.0 milestone Jan 17, 2022
@raftersvk
Copy link
Contributor

raftersvk commented Feb 3, 2022

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Feature - Enhancement Update or improvement to existing feature Planned Planned feature, improvement or bugfix (not being worked on yet)
Development

No branches or pull requests

2 participants