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.

## Advertising

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? >>>>>>> >>>>>>