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?

Reply via email to