You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 8, 2023. It is now read-only.
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.
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-hyperoptagainst 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
mgm-hurrymax_initial_zero_trade_punishment_epochs_allowedsetting inmgm-configmgm-hurrycommand &if the amount of initial 0 trade punishment epochs exceeds over the configured
max_initial_zero_trade_punishment_epochs_allowed,mgm-hurryabort the HyperOpt & automatically start a new one(With identical command/params/config, but a different random state)
max_ho_retries_allowedsetting to prevent infinite loops when the user configures amgm-configthat will never be able to yield any "best" resultsNote
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.