I figured something out today that I'm excited to start playing with. I think it could have a positive impact on the robots I'm working on.

I am using optimizer in some ways that probably don't align with its original purpose, which I understand is to select the most robust value in a range. Usually this translates to the center of a broad hill. That is smart, because it means that if optimal parameters shift slightly over time, they should still be in a profitable zone. The theory, as I understand, is that the "highest" value of a given range may not be the "best" value, especially if it is an outlier or spike. Ideally we want to see a broad hill of high objective values.

However, in some circumstances I want optimizer to choose the highest value, not the robust value. This is useful for functions where the individual neighbor values are not necessarily relevant to each other. For example, in my marketOpenCombo() function, I want to select the best combination of days for trading. There are 15 combinations to choose from, but they are all unique and not necessarily related. Therefore, while a broad hill could appear in the opt chart, it may not. Even worse, the best combination of days could be ignored because it may be considered an outlier or spike.

In observing visually how Zorro chooses optimizer values, I noticed that in cases where a broad hill does not exist (for example, all values are mostly good)... then Zorro prefers to have at least a handful of the good values in order to choose one. It occurred to me that in an opt chart that steps from 1 to 15 I possibly trick the optimizer by simply elongating the return values for each point of interest.

In other words... instead of only taking readings from:
1, 2, 3, 4, ... 15
I wanted to see if I could simulate this instead:
1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 4, ... 15, 15, 15

What I didn't realize was how easy this actually is to accomplish. Zorro's optimizer works on float values, while my purposes require int values. When the conversion takes place, it simply truncates the decimal portion and uses the whole number portion. Therefore the following sequence accomplishes exactly what I want:
1.05, 1.25, 1.65, 2.07, 2.32, 2.78 ...
The effect is that optimizer now sees 3 values and apparently that qualifies as a hill and exempts them from being an outlier or spike.

Look at these example screenshots to see better what I'm talking about. All that is required is a slight variation of the optimize() call, to get Zorro to choose the highest value instead of most robust value (which may or may not be the same).

original call: test values 1 thru 15 with step 1 between each:
optimize(15,1,15,1);

adjusted call: test values 1 thru 15, with (3 steps per whole number):
optimize(15,1,15.99,.33);