There was a PR that was prematurely merged, it's still being discussed: https://github.com/JuliaDiff/DualNumbers.jl/pull/11 In the meantime, a generic Cholesky factorization has been proposed ( https://github.com/JuliaLang/julia/pull/7236) which would solve the original issue but not necessarily match the speed of Chris's specialized approach.
On Sun, Jun 22, 2014 at 9:55 PM, John Myles White <[email protected]> wrote: > Maybe. Did someone create a pull request? > > — John > > On Jun 22, 2014, at 5:22 PM, Thomas Covert <[email protected]> wrote: > > did this code ever find its way into DualNumbers.jl? I do anticipate its > going to be quite helpful. > > -Thom > > > > > On Fri, Jun 6, 2014 at 10:32 AM, Thomas Covert <[email protected]> > wrote: > >> Haven't been able to try it since I'm currently travelling. I bet it >> will turn out to be useful though. >> >> >> On Friday, June 6, 2014, Chris Foster <[email protected]> wrote: >> >>> On Wed, Jun 4, 2014 at 7:21 AM, Thomas Covert <[email protected]> >>> wrote: >>> > Your code is about twice as fast (when N = 1000) as the code I >>> initially >>> > posted. I think the speed gains come from the fact that your code >>> does all >>> > its work on real numbers, so it only has to do one floating point >>> operation >>> > per operation, while my "choldn" works directly on DualNumbers. >>> Still, it >>> > would be great if there was a smart LAPACK routine to do the "Sylvester >>> > Equation" step as fast as the other standard back substitution >>> routines. >>> >>> I didn't find anything which solves the problem while fully exploiting >>> the available structure, but I think the version I've put in the pull >>> request here >>> >>> https://github.com/scidom/DualNumbers.jl/pull/11 >>> >>> should be pretty good efficiency wise since the heavy lifting >>> basically gets handed off to gemv calls. It is basically a forward >>> substitution, but exploiting the structure is important because the >>> underlying linear system is quite sparse. >>> >>> Did you end up using this in the end, or did you find a better way to >>> formulate the problem? >>> >>> ~Chris >>> >> > >
