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). On Monday, September 19, 2016 at 11:26:12 AM UTC-7, Christopher Alexander wrote: > > 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 > > On Saturday, September 17, 2016 at 11:28:36 AM UTC-4, Chris Rackauckas > wrote: >> >> 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 >> <https://github.com/JuliaMath/Grids.jl/issues/3> 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. >> >> On Thursday, October 1, 2015 at 7:34:32 PM UTC-7, Christopher Alexander >> wrote: >>> >>> 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? >>>> >>>
