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