This happens periodically to me when optimizing a strategy. It seems to be intermittent, and only occurs when selecting "Net Profit" as the metric to assign. Mostly seen, or maybe always seen, on the one minute time frame. This is the beginning of the text in the log:

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
at WealthLab.Strategy.StorePreferredValues(String symbol, WealthScript ws, List`1 values)
at WealthLabPro.Optimization.b(Double A_0)
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

This is something new. Let's collect 'evidence' and get to the bottom of this.

1. What strategy? Any, all, some, particular?
2. What optimizer(s)? Any, all, some, just one?
3. Any dependence on the symbol, data loading range, single symbol or multi-symbol mode, Raw Profit or Port.Sim. mode, position size etc?

It seems to happen when I run an optimization for a larger data set - the biggest is about 70 symbols, on one minute data. Doesn't seem to matter which strategy. I may get the error when optimizing the whole set, but then I can turn around and just optimize one symbol and it works fine. I always use the Particle Swarm optimizer set to highest net profit, Clerc Basic Optimizer, plus genetic optimizer, 20,10. Always raw profit mode, position size and period don't seem to make any difference in regards to the error. In typing this, I wonder if changing the metric inside the optimizer would result in the same error for a different metric? I'll try it and see what happens. Thanks.

Thanks for the information. Please change the optimizer to Exhaustive or Monte Carlo. We have to make sure that we aren't troubleshooting a Particle Swarm Optimizer issue.

I get these errors all the time. But they are very hard to reproduce, so I have never reported them. Some comments:

1) If your strategy creates a situation such that no trades are performed on a given stock in the dataset being optimized, then you will get this error when trying to assign Preferred Values, and this is very reproducible. The logistics are that PVs can't be assigned if a stock has never traded, but the PV assignment code fails to guard against that circumstance.

2) I've only seen this problem with the Swarm Optimizer when using the "Clerc Tribes" or "Clerc Basic (OEP 0)" algorithm. If you switch to some other algorithm that's not as good (less optimal), the problem goes away.

3) I write my own indicators. In so doing, I initialize:

CODE:
Please log in to see this code.

inside my indicators so they only trade if they are able to lower this value later in the calculation of the indicator. This prevents the indicator from erroneously triggering a trade on a bad stock that would otherwise loose money. However, if you have a dataset of bad stocks when doing this, then it creates condition #1 above.

I seriously doubt anybody (but me) is doing #3, so they should never see #1. It's been my experience if you weed out all the "bad stocks" that shouldn't be trading in the first place, the problem goes away.

Since the problem is next to impossible to reproduce, I have considered offering to troubleshooting it myself once I got better with the Visual Studio debugger. But I'm not there yet.

Thanks Mark. Two reports and both mention the PSO's Clerc algorithm. I've renamed the thread and moved it under the Extensions category.

Yes, thanks. I think weeding out some symbols is probably a good idea. I did run it using a different optimization metric, and when trying to save the result with that same metric, I get the same error. So it's definitely something with that particular Clerc... setting.

QUOTE:
I think weeding out some symbols is probably a good idea.

From the Optimization tab where you have the Swarm Optimizer selected, after the Swarm Optimizer has ran with the Clerc Tribes or Clerc Basic algorithm, select the Progress Log sub-tab. Look through that progress log and delete all stocks from that dataset that never traded.

Now rerun the optimization again taking care all stocks have traded at least once. At this point, you're safe to set the Preferred Values for these stocks without the object-never-assigned error.

If you do get a WL crash, I would quit, then restart WL. Failure to do so may result in future problems assigning Preferred Values correctly. I know because I have had much experience with this bug.

Let me state that the original error is coming from the WL Optimization Controller, not the Particle Swarm Optimizer(PSO) which is a slave component. I suspect it has to do with how that controller stores the parameters. I've seen cases where a parameter will display one value (bottom left) but when I click on the description to update the parameter, the update pop-up shows a different value. This only seems to happen in the presence of optimization.

As author of PSO, I can tell you...PSO has code to not use results where there are no trades. The reason is that "no trades" returns a Net Profit near zero. For a poor strategy (or even a good one early in the optimization process), this meaningless zero may be the best solution, attracting other particles. Attracting particles toward parameter sets that produce no trades is counterproductive. The lesson here is to limit START and STOP so as to produce trades. Try values manually for a new strategy to get a feel for where it produces trades before optimizing.

QUOTE:
... the original error is coming from the WL Optimization Controller, not the Particle Swarm Optimizer (PSO) which is a slave component.

I tend to agree. I do not think the no-trades-error problem is related to the optimization code itself. For production stock screening, my mode of operation (MO) is to:

1) First optimize with a "poor," randomly-behaving optimizer to identify the "bad stocks" that give negative returns. These get deleted from the dataset before switching to a better optimizer. If I try trading with the better optimizer initially, these bad stocks won't trade at all, and I'll get the no-trades-error problem.

2) When you optimize with a strong strategy and strong optimizer against "Net Profit" or "Profit per Bar", the bad stocks tend not to trade because doing so will yield negative returns. In effect, not trading bad stocks is the optimum solution for these poor players.

3) I would leave the poor-player stocks in the dataset if I could. But since they lead the no-trades-error problem that causes WL to crash on PV assignment, I just delete them instead. I've been dealing with this no-trades-crash problem for months, and this is the best work around.

QUOTE:
Attracting particles toward parameter sets that produce no trades is counterproductive.

And I agree. The optimizer should try to get trades in whenever possible. But if these trades are resulting in negative returns, then it's best to not trade at all.

In my final optimization, I get a dataset win% in the high 60s or low 70s when optimizing against Net Profit. And I get a dataset win% in the mid 70s when optimizing against Profit per Bar. These are acceptable results, so I know the final Particle Swarm optimizer with the Clerc algorithm is working well.

By the way, I don't use Preferred Values at the stock level because I think it leads to overfitting.

Rather, to compensate for different stocks subsequently behaving differently while showing the same "numbers", I use an adaptive method based on priority. Every time the strategy closes a position, it tables the open priority and resulting gain/loss. One of my parameters is "Prior Result." Then, in my open rules, I average the prior results "near" the priority I'm about to use (if there are enough priors). If the average is less than the "Prior Result" parameter, the Buy/Sell is bypassed. So the strategy "learns." This works for me as a swing trader but may not work for longer hold times because there may never be enough "priors."

And I pretty exclusively use the PSO "Clerc Tribes" algorithm.

QUOTE:
I don't use Preferred Values at the stock level because I think it leads to over fitting.

Over fitting is a continual problem because a single stock may only trade eight times over a two-year data range. And that's hardly enough trades to fit a three parameter model for a single stock. Doing the math, (8 observations)-(3 df for the model)=(5 df for error) where df=degrees of freedom. That's only five df left for error, which is the bare minimum!

But one should also recognize there are time independent parameters and time dependent parameters in a model. Wealth Lab's optimization facility only addresses the time independent parameters. That leaves the WL user to fend for himself to try to tune the time dependent parameters (or use WL's neural network facility to tune time dependent parameters, which I haven't yet tried). And unfortunately, the Wealth Lab Users Guide doesn't emphasize this difference enough. Perhaps they assume every WL user is a numerical analyst, who should know better.

I would think WL would offer "conventional" adaptive tuning options (other than neural networks, which isn't conventional) to assist with adjusting the time dependent parameters as well. Yes, I know there's a PctRank indicator, but does everyone know how to use it for adaptive parameter tuning? The AdaptiveLookback indicator looks easy to use (disclaimer: I have used it) for period tuning. Has anyone written a zeros-of-a-function indicator or similar fix-point-methods indicator for adaptive parameter tracking/tuning? Or maybe users just call external numerical libraries for their adaptive parameter tuning needs, which is an excellent option.

What's missing is a tutorial explaining to the non-numerical analyst how to deal with adaptive tuning of time dependent parameters. Just telling them to install the neural networks extension (which even I haven't done) isn't really enough. Of course, there's a counter argument that says some users don't want to optimize their time dependent parameters that much. They are happy just using the existing WL adaptive indicators that are already available.