The only downstream contex that was using batch_order_target_percent
already had all necessary prices, so calling batch_order_target_percent
was wasteful.
Previously, a dataframe passed into BcolzDailyBarWriter.write that was
missing an expected session between its first and last sessions would be
written incorrectly. Upon converting the dataframe to a ctable, the
values for all days following the gap would be shifted backwards, and
nans would be shifted in at the end.
This commit handles the issue by asserting that the number of rows in
the input table matches the number of sessions in the calendar between
the table's first and last sessions.
Also fixes a test that was mistakenly using minutes_in_range where it
should have been using sessions_in_range (uncovered by this change).
* ENH: Use regular rounding to calculate order amounts.
We previously tried to prevent accidental over-ordering by truncating
orders down unless they were within 1e-4 of the next higher integer.
Unfortunately, this makes it easy for a sell order to be one share short
of the desired position.
Using regular rounding treats both buys and sells in the same way.
* ENH keep non-rounding behavior consistent, but leave code structured to make easier to override
* DOC make round_order public and describe behavior in docstring
Capital base is included in the sim params, so we should define the
value there, or use the default.
This change also unifies the default capital base as 1e5, as was
previously defined in algorithm.py.
Enable unadjusted history for continuous futures.
The history array is filled by the values for the underlying contracts,
where the contract used changes based on rolls.
e.g., if a `1d` history window was over the range
`2016-01-20` -> `2016-02-29` with contracts with a suffix of `F16` that
rolls at the beginning of the session on `2016-01-26`, `G16` on
`2016-02-26`, and `H16` on `2016-03-26`. The `2016-01-20` ->
`2016-01-25` portion would use the values for `F16', the `2016-01-26` ->
`2016-02-25` portion would use `G16` and the `2016-02-26` ->
`2016-02-29` portion would use `H16`.
Using the same contracts as above, a `1m` history window over the range
(using a timezone of US/Eastern) `2016-01-25 4:00PM` -> `2016-01-25
7:00PM` would fill the `4:00PM` -> `6:00PM` portion with data for `F16`
and the `6:01PM` -> `7:00PM` portion with data for `G16`, since the
beginning of the `2016-01-26` session is `2016-01-25 6:01PM`.
Supports `1d` and `1m`.
Also adds the `sid` field to `history` to assist in showing the active
contract at each dt in the window.
Add the ability for an algorithm to request the current contract for a
future chain via `data.current`.
e.g.:
```
data.current(ContinuousFuture('CL', offset=0, roll='calendar'),
'contract')
```
In favor of a new method `set_restrictions` which takes a Restrictions
object. Calls to `set_do_not_order_list` should raise a deprecation
warning and create an equivalent Restrictions object, with which
`set_restrictions` will be called. For convenience, create a
RestrictionsSet from which the "restrictions" version of a security
list can be accessed
`future_chain` will be replaced by the as yet to be implemented method,
`data.current_chain`
Also removing `FutureChain` which will be replaced by another version
which only supports indexing and iteration.
