In the volume share slippgae, the current amount had the direction,
i.e. buy/sell was baked into the value of `cur_amount` which then
needed to have the direction multiplied out when parts of the slippage
model needed to take in just the magnitude/amount into account.
So calculate the current volume, use that in calculations and then
apply at the order direction at order time.
Also, when applying the direction to the magnitude of the sell,
use copysign to make the code more explicit about taking the direction
of the order, instead of it possibly having some scalar impact.
As well as remove direction from volume_share calculation since that
calculation and subsequent calculations only care about the magnitude,
so make the disregard for direction more explicit by removing it.
Since `cur_amount` before it's changed by the direction, is always
a positive value, multiplying it back by the direction should also
always be positive.
Found that when implementing different slippage model, needed the
open amount in several places/functions, having the open amount
as a property of an order should help reduce the need for passing that
around and maintaining the value separately.
instead of just limiting it with max_date. This allows for an
additional "live" day appended to the end, fixing various uses
of the trading_day_map, and replacing the isolated check in
get_next_close.
- Change the expected type for order information from the string
of the order id to an `Order` object, so that it matches the same
abstraction level as passing in an event.
- Change the order (not to be confused with the parameter named `order`)
of the parameters so that they go from left to right in order of
static -> dynamic, i.e. the parameters most likely to change within
each invoration are the amount and price, with amount more likely
to change than price.
create_transaction accepted both sid and order, which in all cases
was derived from the current event, so remove `sid` and `order`,
replacing them with event
If there is a scenario where sid and order need to be set independently
of each other, then the underlying Transaction object can be called
directly.
Looking towards making writing custom slippage models slightly easier
by removing the redundancy.
Work towards a set_slippage method accepts a function that takes
event and orders as the argument, instead of being tightly bound
to using classes like FixedSlippage etc., in that scenario the
instances of SlippageModel will be used via `__call__`, so that
backwards compatiblity is maintained.
Now that the tradesimulation transform calls the blotter/slippage
within, instead of being wrapped in a slippage generator, the logging
for slippage can rely on the processor set within the tradesimulation
loop, instead of maintaining its own.
Now that the tradesimulation loop has changed to use benchmarks
as a 'clock', the logic for setting the current time can be grouped
together at the beginning of each iteration instead of the date
and snapshot grouping.
Also, can remove the snapshot_dt and use simulation_dt instead
of having two variables that were keeping track of the same value.
Also, it is no longer needed to peek into the data to get the first
simulation_dt now that simulation_dt is set at the beginning of each
loop iteration.
The check to filter out orders for zero shares wasn't truncated the
number of shares to an integer before checking, so if a fractional
amount less than 1 was being passed in, it wasn't being filtered out
even though it should have been. This is now fixed.
The override should be used to filter out symbols not in the universe,
however it was returning false positives.
To remove the false positives, after the contains check passes,
ensure that the key exists in the _data member.
In the batch_transform we were incrementing the trading_days counter if there
is a new day event. Thus with a window_length of 1 and daily bars you will
update the batch_transform on the first day which is correct. But with minutes
you update with the first minute bar of the day which is not correct.
This is fixed by calculating the market_close explicity and seeing whether the
event.dt is on or past it.
I also added a unittest to test the correct behavior of this.
Before the change to the RollingPanel, window_length
specified the number of days that should be in a window.
The previous commit broke this if data was minute resolution.
By passing bar='minute' to the batch_transform we internally
multiply the window_length by 60*6.5 to have a full day.
Also adds a (still rudamentary) test for batch_transform
with minute data.
The new example is almost identical to the dual_moving_average one.
However, instead of our in-house mavg transform it uses the new
talib exponential moving average (EMA).
When setting timeperiod in the talib function it subtracts by 1. We then used this subtracted value to set the window_length in the batch_transform which was then not passing a big enough panel. Ultimately this caused the talib transforms to always return nans.
This also makes the unittest more stringent by explicitly comparing the output of the wrapped TALib moving average to pandas rolling_mean().
Finally, this also allows passing of window_length instead of timeperiod to allow usage of the same interface as before.
BarData should, at least for the time being, be compatible with
existing algorithms that had worked against the prior usage of
an ndict as data, which provided `has_key`.
Of note, the Python language has deprecated `has_key` in favor
of using `in` and `__contains__`.
The datetime was only being set while updating the universe with the
bar's trade events.
Now that benchmarks are used as a clock, it is possible to have
benchmarks without having trade bars during that dt, so the datetime
should be updated via benchmark as well.
Set the data_frequency member of an algorithm on the sim_params
configuration object.
Though the extra setting is slightly redundant, it is needed to
ensure that the same data_frequency is used throughout.
Should fix a bug where an algo that was intended to be run in minute
mode was operating as if it were daily in performance.
Possible TODO: Remove data_frequency as a param to TradingAlgorithm,
in favor of only being a property of sim_params.
With the benchmark returns marked at midnight, the performance packet
for a day was emitted *before* any events for that day were processed.
Fix by expecting benchmarks marked at the market close, for backtests
that use minute data but emit performance results daily, so that the
benchmark handles at the end of day.
TST: Also, add test that exercises the event loop with minutely data,
(with benchmarks that are marked end of day), since that combination
was previously uncovered.
Working towards performance and risk logic being aware of
data frequency, as different handling of order of events based
on the data frequency is needed.
Backing out slice vs. valid(), because of an incompatiblity with
starting a minutely emitted session mid-day, since the midday start
date is not yet wired through SimulationParameters.
The slicing syntax is more explicit about declaring:
'get all returns up until the current dt'.
Also, protects against NaNs that occur before the current dt
being silently ignored.
i.e. the *_returns_cont series *should* have values from start
to current dt, but the .valid() call was occluding a bug where
it wasn't.
The leading date of the date range was never called with update,
because in the main loop the todays_date variable was
incremented before update was called.
Fix by moving the increment to the next trading day to after the
call to update.
Eddie Hebert