Groups 136 of 99+ julia-users › Any serious quant finance package for Julia? 21 posts by 9 authors Ferenc Szalma 9/11/15 Are there any quant finance packages for Julia? I see some rudimentary calendar and day-counting in Ito.js for example but not much for even a simple yield2price or price2yield or any bond objects in Julia packages on GitHub. What is the best approach, using C++ function/object from Quantlib, to finance in Julia? Avik Sengupta 9/11/15 My hope has been that Ito would become the consolidated financial math package, with functionality similar to Quantlib. Unfortunately, while I laid down the base, I haven't made as much progress as I would have liked (primarily for lack of time), but I do hope to rectify that in the near future. Needless to say, contributions welcome. On Friday, 11 September 2015 07:05:39 UTC+1, Ferenc Szalma wrote: Are there any quant finance packages for Julia? I see some rudimentary calendar and day-counting in Ito.js for example but not much for even a simple yield2price or price2yield or any bond objects in Julia packages on GitHub. What is the best approach, using C++ function/object from Quantlib, to finance in Julia? Ken B 9/11/15 In case you haven't seen it yet, there's also the InterestRates.jl package. - show quoted text - Ferenc Szalma 9/11/15 I missed this package while searching for a quantlib-like package yesterday. I just took a quick look, I saw various models like the Swensson, Nelson-Siegel and spline interpolation, but I haven't got to the point of how various country's calendars are taken into account, or handling the trade date - settlement date and next settlement date problems, etc. I'll take another look later. Thanks. - show quoted text - John Nelson 9/11/15 Re: [julia-users] Re: Any serious quant finance package for Julia? I'm interested too. Relatedly, I started writing a limit order book matching engine package last week. Right now, it only has a single reference implementation -- think, "so simple that there are obviously no deficiencies." It's (almost) well-tested, and will serve as verification scaffolding for elaborated engines, tailored to the use case. Right now, I see a MCMC-ready engine and a speed-optimized one. (Fast enough for algorithmic trading, not HFT. I have no delusions there.) I'll probably push v0.0.1 next month. (If you want, send me a private email, and I'll be sure to email you when I do.) I think it's a wonderful way to show of Julia, and I want it for myself. But, my dissertation proposal defense just got scheduled for the 30th. Priorities, shifted. - show quoted text - Ferenc Szalma 9/11/15 @Avik Sengupta Thanks for coding up Ito.jl even if it is really just the start. Comparing Ito's code with the Quantlib C++ code it helps a lot with understanding how C++ code translates into Julia code, especially for a newbie in Julia like myself. I just noticed you gave a talk on how to interface various languages with Julia on YouTube: https://www.youtube.com/watch?v=AyeArSTzas8 in June and posted only just a few days ago. Do you think it'd be easier to just call Quantlib C++ functions from Julia or re-writing that code in Julia would be easier. Quantlib object are certainly embedded into a complex structure, so translation may be difficult. I am just trying to find the most effective way of using Quantlib or Quantlib-like objects and functions with the least coding time overhead. - show quoted text - Avik Sengupta 9/11/15 While Julia has had a brilliant C interface from the start, calling C++ has been much more difficult. There is work going on under Cxx.jl to make it easy to call C++, but it is still not seamless (it needs a newer version of LLVM compared to base Julia, for one, and there are other limitations). I would hope that Julia has fast native implementation of many of the algorithms in Quantlib. A lot of the code in Quantlib is core mathematical routines, which are already present in base Julia or many of its packages. So given the difficulties in calling C++, I would personally favour a native implementation. But of course, such decisions depends heavily on your situation. Regards - Avik - show quoted text - Ferenc Szalma 9/11/15 Yes, watching just now Keno Fischer's talk at JuliaCon 2015 after watching yours, I can see the big difference in complexity between the C and C++ interfaces. Still it seems like Keno figured C++ out eventually and what he shows is pretty impressive. Do you have any info on how stable Julia 0.4 is on the necessary newer version of LLVM? Also what do you see as other limitations that you mention? - show quoted text - Tom Breloff 9/11/15 My guess, based on what little I know of Keno's progress, is that we're probably within a couple months of a C++ wrapping party... I know I'm planning on doing some of it myself, just waiting for the release buzz to calm down before getting my hands dirty. I'm only mildly familiar with quantlib... How complex are the underlying methods that you care about? It would be better to implement in pure Julia if reasonable. - show quoted text - Ferenc Szalma 9/12/15 @Tom Breloff Quantlib is useful because it has an industry strength calendar/date library containing all the day count conventions and its calendar is maintained (e.g. when the Queen of England turns 100 holiday comes along, you don't need to enter that in your calendar manually). I don't think the underlying methods are particularly complex in Quantlib, though I don't know what would be a good measure of complexity. Quantlib's class structure has a certain amount of complexity, however, as it implements many GOF design patterns, and I don't quite know how they translate to a completely different, functional paradigm. I mainly need the date libraries and certain simple pricing methods, which I can build my more complex calculations on. A good example of how these simpler Quantlib pricings go is described in a simple language here: https://quantcorner.wordpress.com/2011/01/31/us-treasury-notes-and-quantlib/, where the fixedRateBond, bondEngine and the discountingTermStructure are the three main objects working together in some sort of strategy pattern. This particular pattern is given in Julia since it is a functional language, but complexity arises around the class hierarchy of each of these objects. - show quoted text - Christopher Alexander 10/1/15 I think the Ito package is a great start, and I've forked it to work on adding to it other features of Quantlib (as best as I can!). I'm glad someone mentioned the InterestRates package too as I hadn't seen that. I work at major bank in risk, and my goal is to at some point sell them on the power of Julia (we are currently a Python/C++ shop). - Chris On Friday, September 11, 2015 at 2:05:39 AM UTC-4, Ferenc Szalma wrote: Are there any quant finance packages for Julia? I see some rudimentary calendar and day-counting in Ito.js for example but not much for even a simple yield2price or price2yield or any bond objects in Julia packages on GitHub. What is the best approach, using C++ function/object from Quantlib, to finance in Julia? Femto Trader Sep 17 Hi guys, Not sure if we can consider this package as a "serious quant finance" one... but I wrote some month ago https://github.com/femtotrader/TALib.jl It's a Julia wrapper for TA-Lib (technical analysis library) Status is still "Work In Progress" Kind regards Le vendredi 11 septembre 2015 08:05:39 UTC+2, Ferenc Szalma a écrit : Are there any quant finance packages for Julia? I see some rudimentary calendar and day-counting in Ito.js for example but not much for even a simple yield2price or price2yield or any bond objects in Julia packages on GitHub. What is the best approach, using C++ function/object from Quantlib, to finance in Julia? Chris Rackauckas Sep 17 Thanks Femto Trader for bumping this. I took a quick look at Quantlib (and Ito) and I have to say, their numerical methods are very rudimentary (in fact, one of their methods for stochastic processes, EndPointEuler, doesn't have finite moments for its error due to KPS 1994...). For anything that isn't a Jump Process you can currently use DifferentialEquations.jl which has higher Strong order methods for solving the SDEs (with efficient adaptivity coming whenever my paper gets past peer review... short summary: mathematicians don't like computer science tools to show up in their math papers even if it makes it faster...). That's the thing though, you have to know the stochastic differential equation for the process. That said, it would pretty trivial to use dispatch so that way you define a "GeneralizedBlackScholes" equation, when then uses dispatch to construct an SDE and apply an optimized SDE method to it. Since you can already do this manually, it would just take setting up an object and a dispatch for each process. Would this kind of ease-of-use layer for quants be something anyone is interested in? The other thing is the Forward Kolmogorov PDEs associated to the SDEs. Currently I have FEM methods for Poisson and Semilinear Heat Equations which, as with the SDEs, can define any of the processes. This has a few more fast methods than Quantlib, but it doesn't have TRBDF2 (but that would be pretty trivial to implement. If you want it let me know, it should take less than hour to modify what I have for the trapezoid rule since it's just about defining the implicit function, NLsolve handles the solving). However, for most PDEs in finance you likely don't need the general boundaries that FEM provides and so FDM (finite difference methods) can probably be used. I haven't coded it up yet because I was looking for the right implementation. I am honing in on it: ImageFiltering.jl gives a good n-dimensional LaPlacian operator (and if I can convince Tim Holy it's worthwhile, parallel/multithreaded), and I will be building up Grids.jl memory-efficient iterators for storing the space. This should lead to blazing fast FDM implementations where the only actual array are the independent variable (the option price) itself, so it should also be pretty memory efficient. I'll be pairing this with the standard methods but also some very recent Implicit Integrating Factor Methods (IIF) which should give a pretty large speedup over anything in Quantlib for stiff equations. Would anyone be interested in a quant ease-of-use interface over this as well? (If you'd like to help speed this up, the way to do that is to help get Grids.jl implemented. The ideas are coming together, but someone needs to throw together some prototype (which shouldn't be too difficult)) Note that Jump Processes can easily be done by using callback functions (independent jumps can be computed in advance and then use an appropriate tspan, adding the jump between the intervals. Dependent jumps just need to use a callback within to add a jump in the appropriate intervals and maybe interpolate back a bit, likely better with adaptive timestepping), and I'll probably make an API to make this easier. Let me know what you guys would like to see on the differential equation / stochastic processes side and I'll make it happen. I'm doing most of this stuff for SPDEs in stochastic systems biology, but the equations are literally the same (general SDEs and semilinear Heat equations) so I'm plowing through whatever I can. - show quoted text - Christopher Alexander Sep 19 I had started the QuantLib.jl package, but the goal was basically a rewrite of the C++ package in Julia. I haven't given it much love lately, but I hope to pick it back up sometime soon. Anyone who wants to join in is definitely welcome! Chris - show quoted text - esproff Sep 19 I'd be interested in getting involved in this, I've been writing up some portfolio optimization and visualization routines in Julia with the help of Convex.jl and Gadfly.jl, this could possibly eventually be merged into Ito.jl or QuantLib.jl or w/e we decide is the official Julia quant finance library. - show quoted text - Chris Rackauckas Sep 19 I was saying that Quantlib, not Quantlib.jl, had rudimentary numerical methods. The main reason is probably because they only implemented a few here and there, instead of focusing heavily in the numerical solvers or using available libraries. There's no reason to do this in Julia: you have access to a large set of packages to provide the different aspects. Piecing together a metapackage of Julia packages in a way that curates them into a library specific for solving financial equations would easily give you a more sophisticated package than Quantlib achieves. That's why I'm asking what you'd like to see on the differential equations side because DifferentialEquations.jl already offers a bunch of methods for SDEs which could have simple front-ends thrown on them to become "GeneralizedBlackScholes" and etc. solvers. The same should be done with the other parts of Quantlib like optimization, and you'll easily get a vast library routines specifically tailored to mathematical finance problem which will outperform what is given by Quantlib. As to esproff's suggestion, Plots.jl should be targeted instead of Gadfly for a few reasons. For one, plot recipes are a powerful way to link a package to plotting ability that would make most of the plotting work trivial. Secondly, recipes would add plotting capabilities without having a large dependency like Gadfly. Thirdly, it would let you choose whatever your favorite plotting backend is. Fourthly, Gadfly doesn't support 3D plots which are one standard way of showing things like FDM results. There's no need to unnecessarily limit our plotting abilities. Lastly, the developer of Plots.jl is a financial guy himself who has already commented on this thread (Tom Breloff), which always a bonus. As for targeting Convex.jl to put optimization routines over, I am not sure. I would keep up with the developments of JuliaOpt and JuliaML to see what packages seem to be growing into the "go-to which offers the functionality" (currently Optim.jl is the most, the metapackge Learn.jl may be an interesting target in the future). The "obvious" choice in some cases may be to target JuMP, but experiences from LightGraphs.jl seem to show that it doesn't play nicely with other packages as a conditional dependency (i.e. if you want to use it, you might have to force everyone to have it and it's a big install.) This is actually what has stalled a package for parameter inference for ODEs/SDEs/PDEs: it's not clear to me what to target right now if I want as much functionality as possible but want to minimize the amount of re-writing in the future (once this is together though, you could stick a front-end on this as well to do parameter inference for financial equations). - show quoted text - esproff Sep 20 Ok Chris I'll definitely check out Plots.jl. As for optimization packages, more than one will probably have to be used depending on the problem: disciplined convex vs numerical vs global vs etc. And, as always, some optimization algorithms will have to be custom rolled out since established packages will never have everything you need exactly as you need it. - show quoted text - Chris Rackauckas Sep 20 If you implement an optimization routine for a specific type of functions, why not have that maintained with the API and structure of Optim.jl, and then use it for your specific case? What about the JuliaML interfaces / the Optim iterator interface do you find would be a limitation to a quant library? Optim.jl and things like Learn.jl are designed to be metapackages which contain numerous solvers, each optimized for different domains. I think any optimization algorithm would benefit from the infrastructure that is being built into these packages, instead of making one off implementations (let alone then it's easier to use for other applications). And the iterator format is pretty general allows a ton of flexibility. If there's something about the design that you see not working for this, it's better to help them fix their design than to attempt to double up efforts and (most likely) not get more optimized algorithms. - show quoted text - esproff Sep 20 I've only used Convex.jl extensively, and NLopt.jl a bit, so I don't really know whether Julia's optimization ecosystem would cover all possible eventualities, I'm just speaking from experience when I say that it's rare that I'm able to rely solely on off-the-shelf packages when writing numerical algorithms. If that's not the case here than so much the better. - show quoted text - Chris Rackauckas Sep 20 We're using Julia: packages correctly designed with multiple dispatch (DifferentialEquations.jl, the direction that JuliaML and Optim.jl are going with the iterator interfaces, etc.) allow for these to be extendable: adding a new algorithm is just making a new dispatch or a new type. So if your specific algorithm isn't implemented, then you can implement it into one of these packages without even modifying their source (though PRs would likely be accepted). And using specialized types while injecting code into callbacks or in an iterator format should allow almost anything. I'm not sure what's missing. But what's gained is that the algorithms would plug into the package and get all the goodies like convergence testing, plot capabilities, etc., while all you have to do is specify one part. - show quoted text - Christopher Alexander Sep 20 I definitely wanted to start integrating some of the existing Julia packages for solvers etc that I basically wrote based off the C++ Quantlib code - maybe in a version 2. Why re-invent the wheel, so to speak (and you're right, they'd definitely be faster)? I'm probably going to start working on the package more now that v0.5 is official. Chris - show quoted text -