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 On Tuesday, September 20, 2016 at 5:00:10 AM UTC-4, Chris Rackauckas wrote: > > 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. > > On Monday, September 19, 2016 at 10:08:16 PM UTC-7, esproff wrote: >> >> 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. >> >> On Monday, September 19, 2016 at 9:45:13 PM UTC-7, Chris Rackauckas wrote: >>> >>> 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. >>> >>> On Monday, September 19, 2016 at 9:27:38 PM UTC-7, esproff wrote: >>>> >>>> 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. >>>> >>>> On Monday, September 19, 2016 at 7:29:30 PM UTC-7, Chris Rackauckas >>>> wrote: >>>>> >>>>> 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? >>>>>>>>> >>>>>>>>
