For a interdays trading backtest system, should I put day open, close, high, low, volume separately into array?
For a interdays trading backtest system, should I put day open, close, high, low, volume separately into array?
Loading saved threads...
laughingthunder · External communityPost link
External question — Quantitative Finance Stack Exchange
Author: laughingthunder
Original post: https://quant.stackexchange.com/questions/8860
License: CC BY-SA 3.0 — https://creativecommons.org/licenses/by-sa/3.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
I think there are two possible ways: 1. day open, close, high, low, volume separately into array, then I have 5 arrays to work with my calculation 2. Put all of these into one array or linklist to do the calculation.
I think the 1. would be more easy to handle all backtest calculations, do you agree?
Background information: I would develop my system with Java and run in either Windows 7 64 bits/ Ubuntu 64 bits. I will eventually connect the live trading version to Interactive Broker Java socket API.
Quote
Report
chrisaycock · External communityPost link
External answer — Quantitative Finance Stack Exchange
Author: chrisaycock
Original post: https://quant.stackexchange.com/a/8861
License: CC BY-SA 3.0 — https://creativecommons.org/licenses/by-sa/3.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
Go with the multiple arrays. This would give you a
column-oriented store
, which is far more cache-efficient when handling time-series data. Specifically, you are describing an "in-memory" database table that can be queried.
You'll also want to think about how to do your look-ups. Will you have a hash table that maps symbols to OHLC tables? Will you partition the tables by date? Think about what kind of queries you're going to run, and then structure your data to make this search easiest.
Quote
Report
assylias · External communityPost link
External answer — Quantitative Finance Stack Exchange
Author: assylias
Original post: https://quant.stackexchange.com/a/8892
License: CC BY-SA 3.0 — https://creativecommons.org/licenses/by-sa/3.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
Considering it is backtesting and ultra-performance is not very relevant**, I would suggest following good OOP principles:
create a
BarData
class which holds the fields you need (date, o, h, l, c, v etc.)
store the
BarData
s in an
ArrayList<BarData>
You can then store several time series in a
Map<String, List<BarData>>
or a guava
MultiMap<String, BarData>
.
That should make your life easier.
ps: I don't know the IB API - if they have built-in types that look like my BarData then you sould as well use them directly.
**And note the the difference of performance between arrays and ArrayLists
is not that big for most use cases
.
Quote
Report
Post Reply
Quoted from Forex.com.bd-Editorial External answer — Quantitative Finance Stack Exchange Author: chrisaycock Source score (net votes, not local likes): 4 Original post: https://quant.stackexchange.com/a/8861 License: CC BY-SA 3.0 — https://creativecommons.org/licenses/by-sa/3.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Go with the multiple arrays. This would give you a column-oriented store , which is far more cache-efficient when handling time-series data. Specifically, you are describing an "in-memory" database table that can be queried. You'll also want to think about how to do your look-ups. Will you have a hash table that maps symbols to OHLC tables? Will you partition the tables by date? Think about what kind of queries you're going to run, and then structure your data to make this search easiest.
Checking account access…