[110] Filters Ignored (> Add Net Profit per M/Y Filter Options)

I think I had the operator around the wrong way.

Still a little confused given this seems to only be working intermittently, that is provided it's function is what I'm thinking.

My expectation is that setting Avg. Profit Per Month > $0 requires there to be a profit for each and every month in the test period.

If this is just and average of the entire test period then the option is useless along with the Daily and Yearly being redundant because that would mean Per Day x30 = Per Month and Per Month x12 = Per Year.

If that is correct, maybe the 'Avg.' can be removed from these # of Trades and Profit Per d/m/y Filters and make them absolute for the nominated period so they can actually be useful.

What you want is a "Minimal profit per month". It is possible to compute statistics like this, but I think this condition will be extremely strict. It would be extremely difficult to find a strategy that will have all months profitable in real trading.

Hi Mark,

Yes, that sounds like what I'm after. I realise a monthly application is very strict, but we are chasing the 1/1M after all...  ;)

I'm doing a brute force approach with Random Generation so this suits, and if I can find some with this then, yipee!

Now just waiting for AMD to release a 7nm 64C/128T Threadripper to really put the hurt on those numbers...

This also seems to me a way to apply minimal complexity of filtering to target a high quality outcome.

If you can please add the following in a future build it would be appreciated:

Minimum Profit Per Month

Minimum Profit Per Year

I am still curious about those 'Avg.' filters, is their behaviour as I detailed where they are an average over the entire test period and equivalent by x30 and x12?

p.s. I sent you some Forum messages, did you receive them?

thanks, Al

Hi Mark,

I was thinking further on this and it would make more sense to align with current naming conventions, so use Net Profit:

• Net Profit per Month ±
• Net Profit per Year ±

You'll notice I've added the http://unicode.org/cldr/utility/character.jsp?a=00B1 suffix to indicate the input supports negative values.

The only issue might be some users perceiving that to mean deviation, in which case another way of displaying input options would need to be used.

As you pointed out this would be a strict requirement if the only input option is => 0, if you can enable negative numbers for the input it can be set to e.g. => -12.5% so as to allow for losses while restricting them to a floor level.

thanks, Al