A cython __richcmp__ function isn't allowed to assume that its first
argument is the same as the type of the class to which it belongs, so
our code needs to account for either of its two arguments being of the
wrong type.
Furthermore, the correct way for __richcmp__ to handle when it doesn't
know how to do a comparison is to return NotImplemented.
Python 3 for some reason doesn't like usage of the cmp() built-in, so
instead of using cmp(), just subtract the two ints being compared.
In addition to making this work with Python 3, it should also be more
performant since it no longer requires calling the cmp() method.
The >= comparison for the Cythonized Security object was actually
doing <=. Fix this and add unit tests for all the Security object rich
comparison operators.
The class is not yet used. Adding this class is part of the effort to allow Zipline
simulation of more types of assets than stocks.
DEV: Adds build_ext to .travis.yml
Previously the class SerializeableZiplineObject was used to
house basic __setstate__ and __getstate__ methods. It wasn't
really doing much that was helpful, so it is now gone.
Some unit tests for test_tradingcalendar failed on 2015-03-01, because the
addition of 365 days put the end date at 2016-02-29; when the replaces
the year on that date it fails because there is no 2017-02-29.
Instead use relativedelta with a year argument which accounts for leap
years.
Fixes the following test failure:
```
======================================================================
ERROR: test_day_after_thanksgiving (tests.test_tradingcalendar.TestTradingCalendar)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./tests/test_tradingcalendar.py", line 211, in test_day_after_thanksgiving
tradingcalendar.end.replace(year=tradingcalendar.end.year + 1)
File "tslib.pyx", line 297, in pandas.tslib.Timestamp.replace (pandas/tslib.c:7325)
ValueError: day is out of range for month
----------------------------------------------------------------------
Ran 1 test in 0.001s
```
as it is a backwards compat. Without sorting the orders are filled by
order date. With sorting the orders are moved to back of queue after
partil fills. If all orders are fully filled, there is no
deviation. Also there is no portfolio difference as this is about
assigning fills to equivalent orders.
For use in a function that wraps de-serialization, to call instead of
creating the OrderedDicts from a module outside of the object.
So that the other module does not need to the internals of this object,
also to ensure that the cythonized OrderedDict is used, when available.
This need should be superseded with serialization versioning.
When calculate_positions_value used np.dot, the return type was a
np.float64. Which allows the use of 0.0 in division to not raise an
exception.
Fix by expliciting creating an np.float64 with 0 value.
Add a set_positions method so that the serialization process can rebuild
from just the positions, since the last_sale and amounts are derivable
from those values.
Also, use the private naming convention for last sale price and amount
members, so that those members are ignored by the serialization process.
based OrderedDict. Series/ndarray can only be sped up so much because
they weren't designed for fast iterative mutations.
This also cut down on the # of intermediate Series being generated
during perf stat generation. Things like s[s > 0] will create a new
Series for s > 0.
Moved cython to requirements.txt and added cyordereddict
Reduce overhead of the attribute access of grabbing the process_event
and process_trade from both the algorithm object and the perf_tracekr or
blotter, by assigning those functions to a variable once per snapshot.
For more discussion see https://github.com/quantopian/zipline/pull/485.
Basically, 1000 is just a number that was supposed to be high enough if no volume was available. It turns out that number is actually very low so now we are increasing it so that volume restrictions should no matter. 1e9 of shares ought to be enough for anybody ;).
Thanks to @jlowin for pointing that out.
Currently, `order_percent()` and `order_target_percent()` both operate as a percentage of `self.portfolio.portfolio_value`. This PR lets them operate as percentages of other important MVs.
(also adds `context.get_market_value()`, which enables this functionality)
For example:
```python
order_percent('AAPL', 0.5)
order_percent('AAPL', 0.5, percent_of='cash')
order_target_percent('MSFT', 0.1, percent_of='shorts')
tech_stocks = ('AAPL', 'MSFT', 'GOOGL')
tech_filter = lambda p: p.sid in tech_stocks
for stock in tech_stocks:
order_target_percent(stock, 1/3, percent_of_fn=tech_filter)
```
Limited use of `pandas` data structures in both `HistoryContainer` and
`RollingPanel`. Where possible, methods were amended to return raw
`ndarrays` with the indexing logic done separately. This allows us to
cut down the number of times pandas objects are created both as returns
and intermediate values. The separation of indexing from data access
allowed us to minimize the times we’d make use of pandas indexes.
This required that that certain methods like `NDFrame.ffill` be replaced
with versions that work with `ndarrays`. Some of this was done via
straight numpy methods and others by access pandas internal
machinery. Outside of allowing us to use faster ndarrays, many of these
function provided speedups over their pandas counterparts as we didn’t
require the extra features like handling multiple dtypes. i.e. np.isnan
is faster than pd.isnull, but only works with certain dtypes.
and added a new test case
was not iterating over lookup date directory names, and
therefore mising all by one list of stocks.
discovered because of differing sort orders between
my local machine, other devs, and travis ci.
Jonathan Kamens