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

Reply via email to