Grant, the order_optimal_portfolio method has a rather precipitous drop-off in efficiency when the number of assets in the TargetWeights objective is above 1825. Attached is your algo but restricted to the top 1825 assets in the pipeline. It runs fine. Increase that number to 1830 and it times out. This isn't typically an issue since most often one's portfolio size is much less than that. So, limit the number of assets to less than 1825 and it should be OK.

Thanks Dan -

That's kinda odd, and sure comes across as a bug (I wasted a lot of time trying to sort out what was going on). I thought the idea was to rank across the entire universe for these single raw factors and y'all would sort out how to combine all of the factors?

Why not fix the problem with TargetWeights? Presumably, the optimizer isn't even running with constraints=[], and you are just passing the alpha to order_target percent?

Also, I had the thought that maybe there would be a work-around by calling TargetWeights twice?

I had been getting a lot of timeouts s as well and had no idea what was causing it. Never got this before when scoring all the stocks, only in the last week or so.

Not sure if these are related but we are looking at a couple of things which may have impacted timing over the past week. I'll get back with an update when we know more.

Thanks Dan -

For the time being, until you sort out what's going on, you could add a warning. It's a subtle bug.

Also, as I understand, you are encouraging/requiring ordering per the code I pasted below (i.e. not to use the optimizer at all). Is it equivalent just to use 'order_target_percent' or do you need us to use the TargetWeights objective and the unconstrained optimizer? The latter would seem to be an unnecessary complication if you just need the end-of-day relative weights?

    objective = opt.TargetWeights(alpha)  
    order_optimal_portfolio(objective=objective,  
                             constraints=[]  
                            )  

@Grant Indeed this was a problem with the optimizer. One of the solvers wasn't being loaded properly. It's been fixed. See this update https://www.quantopian.com/posts/update-optimize-timeout-fix. It turns out the choice of which solver the optimizer used was impacted by the number of assets. Above a certain number of assets, the optimizer tried to use the solver which wasn't being loaded, didn't find it, and simply waited. Below that number of assets it worked fine.

Good callout.

Thanks Dan. This does remind me that Q would benefit from a user-facing 21st century help ticket/bug tracking system, in my opinion, versus the current system of using forum posts. Just my two cents...

Hi Dan -

I don't understand why, with the call I show below, any optimizers would be called? There's nothing to optimize, so why would you not just pass the weights to order_target_percent (or an equivalent)?

My other confusion is that I thought you were discouraging use of the optimizer altogether. Piecing together information from the forum, you are interested not in trading algos that could be funded directly, but rather individual "raw" alpha factors (signals), with end-of-day weights output by the backtester (which has been hacked/re-purposed from a trading simulator to an alpha factor engine). As such, placing orders is irrelevant, and so shouldn't order_optimal_portfolio be dropped, and replaced with something like record_alpha_vector (which would simply capture the end-of-day alpha factor values)?

objective = opt.TargetWeights(alpha)  
order_optimal_portfolio(objective=objective,  
                             constraints=[]  
                            )