🐞 Don't apply weak/strong signal overrides during BackTest/Dry/Live Modes after a 1st HyperOpt Run about monigomani HOT 3 CLOSED

🚀

from monigomani.

Instead of the above mentioned fix I decided to tackle this issue a bit differently.

I will automatically override weak signals utilised by HyperOpt at all times.
This also means during the 1st HyperOpt run.
Imagine:

{
    "min_weighted_signal_value": 0,
    "max_weighted_signal_value": 100,
    "search_threshold_weighted_signal_values": 22
}

Currently on your 1st HyperOpt run you have a search space of 0 - 100,
HyperOpt will still use a weak signal ("weight" below 22 in the 1st run) & it will also count as triggered.
But on your 2nd HyperOpt run it would override "weak" signals found with a weight below 22 to 0 to disable "hyperopting" them (aka make them static zero's through the whole HO).
Besides the overrides the refined search space logic also applies during the 2nd HO run.

With my proposed changes: on your 1st HyperOpt run you have a search space of 0 - 100,
HyperOpt will immediately override weak signals (set their "weight" to 0 if the value used for said epoch is below 22 in the 1st run) & it won't count as triggered anymore either.
On your 2nd HyperOpt run it would still override "weak" signals found back to 0 to still disable "hyperopting" them.
Refined search space logic would still be applied during the 2nd HO run.

This would also kind of eliminate the need to do 2 individual HyperOpt runs, because the weak signal & strong signal overrides would already be applied straight from the start, meaning we don't "manually interfere" (overriding weak/strong signals after a HO) anymore after the 1st run results are found (which was/is the reason for the 2nd HO)

from monigomani.

Also will reduce the time needed for a HO a bit because I have reduced the search space size 🙂 :
Imagine if you have a search space from 0-100 & a threshold of 22
Currently there would be 22 chances to override to 0 and 22 chances to override to 100 on the 2nd HO run, because we're literally searching between 0 - 100, but the 2nd run overrides anything below/above the threshold value.

With the new changes it will only search between 22 - 78 due to the threshold value of 22 already reducing the search space. But if the outer bounds of the search space are used, then it will automatically override to it's actual search space limits (0 & 100). Thus now instead of 22 chances to hit an override for strong/weak signals, there is only 1 chance to hit it, but it's already applied from the 1st HO run.

This should create a more refined HO (because there's way less values/combinations to go through) right from the initial HO + I truly think this is a cleaner implementation after all, because it's way less hacky with the HO process
It also leads to the fixing above mentioned bug. The backtest results will match again, because the value used can only be one value, while on the current build it can be 22 different values, being overriden once a backtest has been started

from monigomani.