search

JuliaQuant / Roadmap

High-level overview of group's goals and objectives
12 stars 5 forks source link

Decide whether to implement FinancialTimeSeries as a type #2

Closed milktrader closed 9 years ago

milktrader commented 9 years ago

I'm really not in favor of this because of all the duplication of code that happens from TimeSeries.

My current thinking is to add a parameterized metdata field to the TimeArray type and occupy that space with an Instrument type.

multidis commented 9 years ago

This would reduce nearly-duplicated code. Can we setup some performance tests with a large TimeArray, comparing the following options:

  1. Bare TimeArray
  2. TimeArray metadata-branch, parameterized type
  3. TimeArray with arbitrary metadata slot
  4. My current FinancialTimeSeries type

Context A: Repeated backtesting. For the test, let's say we use EMA calculation on a large array and go over cases 1:4 above.

Context B: Real-time order logic, possibly with lazy lists. For the test, check timing and memory allocation when assembling a large array by appending one "row" at a time.

milktrader commented 9 years ago

I can push the TimeSeries branches and you can push your FinancialTimeSeries implementation as a branch for now. How does that sound? We can open an issue for FinancialTimeSeries (create a branch with new type) and assign that to you @multidis. I've already assigned myself the TimeSeries branches here.

https://github.com/JuliaStats/TimeSeries.jl/issues/159

milktrader commented 9 years ago

@multidis you should have push/pull access to FinancialSeries and FinancialBlotter now. While you're still inspecting the latest state of the code, perhaps you can push branches for now until we decide on a cohesive plan for the master branch.

multidis commented 9 years ago

Let's try that @milktrader . To work with branches from Julia: Pkg.clone("branch-url") would re-write origin for the package, is there a convenient way to switch between branches locally?

milktrader commented 9 years ago

$ git checkout master $ git checkout my_brilliant_refactor

Do this in the .julia/v0.4/FinancialSeries directory, e.g.

To create the original branch

$ git checkout -b my_brilliant_refactor

multidis commented 9 years ago

Performance tests with base and parametric metadata-augmented TimeArray suggest that at least in the case of FinancialSeries.Instrument meta-value the performance is nearly unaffected. Thus, it seems to make sense to proceed by introducing a meta-field in TimeSeries.TimeArray.

milktrader commented 9 years ago

Nice work. Thanks! This does push forward the idea to include a parameterized metadata field in TimeArray.

milktrader commented 9 years ago

Closing this since TimeArray has meta field now.