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