order_optimal_portfolio trades what it can that very minute. Freeze is used when applying it to individual positions.

I need it to basically do what an order_value() function does. There are times where I get 2 or 3 buy signals before a sell signal.

How Can I get the Buy Signal to act more similarly to a order_value?

edit: Got it to work with:
if (context.portfolio.positions[context.security].amount) > 0:
context.buy_weight += 0.2
etc...

I got the Sell Signal to work with the order_optimal_portfolio():
context.security = symbol('CRSP')

Create a pandas series or dict with securities and weights to order
weights ={context.security:0}

Create a TargetWeights object to set the order weights
This will become our ordering objective
weight_objective = opt.TargetWeights(weights)

Execute the order_optimal_portfolio method
order_optimal_portfolio(objective = weight_objective, constraints = [])

Still has MOST trades happening a minute late...

The Quantopian backtest engine (ie Zipline) simulates orders as being filled in the ephemeral time just after the close of the current minute and at the very start of the following minute. The order fill logic is run before the handle_data and any scheduled methods. The order fill logic uses data from the previous minute to determine fill price and volume. It's at the very beginning of the following minute and orders are timestamped as of that minute.

Therefore, new positions won't appear in the same minute that orders were placed. However, since orders are filled at the very start of the following minute, new positions are visible to any code run the following minute.

Attached is a backtest which shows this sequence. Look at the logs. They show orders as filled the minute after they are placed. They are filled at the close price of the previous minute. But, since they are filled before any scheduled methods, the positions can be traded again that same minute. Hope this makes sense.

I've looked at your clone and I am trying to understand your explanation. This is one of my first backtest algorithms on this site, so I thank you for your help and patience.

"simulates orders as being filled in the ephemeral time just after the close of the current minute and at the very start of the following minute"

This appears to be the case with my algorithm as the price executed is between the interval of [n+1,n+2], where 'n' is the price at the minute I wish the trade to be executed and 'n+1' and 'n+2' are the prices at the following minutes.

The timestamps are showing me that I am missing the prices by definite intervals every time, causing the algorithm to miss its buy/sell signals. I have thought about attempting to identify those marks the minute before, but that has a much lower probability of success and I believe that the current signals are possible to act on in actual practice.

Is there any order function to file an order at that exact time; or at least much before the close of the current minute?

But, since they are filled before any scheduled methods, the positions can be traded again that same minute. Hope this makes sense.

I see this. The following signals still are firing correctly despite the order missing the previous signals. I am still able to manually record prices to check, within a margin of error, how the algorithm would perform. However, I would love to utilize all of the nifty tools the full backtest provides.

Maybe it would help to have a conceptual overview of the backtester.

Generally the program is called Zipline and it's open sourced at https://github.com/quantopian/zipline . The code one writes in an algorithm is executed in the following order:

• initialize / this user defined method is executed exactly once when the algo is started
  
• before_trading_start / this user defined method is executed every trading day before the markets are open no orders can be entered here.

The following steps are repeated in this order every minute of the trading day beginning at minute 9:31 ET.

• the orders in the open orders list are executed based upon the slippage model / the first minute there won't be any.
  
• handle_data / this user defined method is executed every minute beginning at 9:31
  
• scheduled functions / any user defined scheduled functions are executed if they meet the schedule rules

The only two areas which orders can be placed are 'handle_data' and any 'scheduled functions' (or methods called by those). When an order is placed (ie one of the order methods is executed) it really just appends a new order to the open orders list. It doesn't get executed at that time. It just gets created and added to the list. If you check open orders right after an order is placed one can see the new order but the 'filled' field will always be 0.

It isn't until the next time through the loop (ie the next minute) that the open order list is checked and the orders are acted on. The fill price and fill amount is calculated based upon whatever slippage model one specifies in the 'initialize' method (or the default if none is specified). The fill price and volume are always based upon the previous minutes price and volume. So, if it helps, one can think of the order as being filled during the previous minute (the same minute that the order was placed). The fill price and volume are based on that data, and the resulting new positions are available to any code the following minute. However the timestamp in the trades list is the following minute because of the timing as shown above.

One comment you made "where 'n' is the price at the minute I wish the trade to be executed" . Remember that any prices one gets are ALWAYS from the previous minute. The 'current' price is actually the close of the last minute. To avoid any look ahead bias one can't know what the close price (for example) of the current minute is (it hasn't happened yet). One can only see prices which have already happened (ie from the last minute). This may be part of the confusion?

Hope this helps.

Ahhhh I see. That makes sense and is what I was afraid of.

Thank you Dan. I'm back to the drawing board.