Yes, Pardiso certainly has Cholesky. Also general symmetric indefinite Bunch-Kaufman with inertia output, which makes it quite useful for non-convex optimization applications. Not sure about sparse QR in Pardiso or some other component of MKL but it might be in there somewhere.
On Thursday, April 16, 2015 at 9:53:50 AM UTC-7, Viral Shah wrote: > > Can Pardiso do cholesky as well as LU? I think QR is probably still > missing in MKL. > > -viral > > > > > On 16-Apr-2015, at 10:10 pm, Tony Kelman <to...@kelman.net <javascript:>> > wrote: > > > > MKL contains Pardiso and a number of other sparse routines that can be > quite useful and could be good alternatives to SuiteSparse (as well as > providing some additional functionality that SuiteSparse does not have), > but would of course need to have Julia bindings written for them. The API > documentation for MKL is quite comprehensive so I don't expect this would > be all that challenging, but work still needs to be done on the sparse > linear algebra functionality in base to make things more flexible so you > could easily swap out different backend solver libraries. The situation is > a bit more complicated than with swapping out different dense Blas/Lapack > implementations where the API's are standardized. > > > > > > On Thursday, April 16, 2015 at 9:32:01 AM UTC-7, Viral Shah wrote: > > The useful parts of SuiteSparse are all GPL. So, for a GPL-free build, > it is straightforward to completely avoid using SuiteSparse. > > > > One of the things I want is to have a version of Julia built with Intel > compilers and linked to MKL. Julia can already use Intel's BLAS, LAPACK, > LIBM, and FFT routines. There is also a VML package for vector math > functions. The only big missing piece is sparse solvers - but perhaps that > is ok for people, who can use Intel's sparse solvers or MUMPS or something > else. > > > > -viral > > > > On Thursday, April 16, 2015 at 7:51:38 PM UTC+5:30, Isaiah wrote: > > I recently annotated the license list to give myself (and others) a > quick-look grasp of the license situation: > > > > > https://github.com/JuliaLang/julia/commit/d2ee85d1135fd801f1230530f39f05369f6384df > > > > > I agree with Tony that in the short-term, distributing a GPL-free binary > ourselves is not a priority, but pull requests to make the situation > clearer or to make a GPL-free build simpler would be fine. For example, > there could be a NO_GPL Makefile variable, and a macro on the Julia side to > annotate and selectively exclude GPL stuff from the system image (FFTW and > Rmath should be, respectively, easy and very easy to exclude, however I'm > not sure how deeply entangled the SuiteSparse stuff is). > > > > > > > > On Thu, Apr 16, 2015 at 10:04 AM, Tony Kelman <to...@kelman.net> wrote: > > It's certainly a long-term goal. 0.4 is far enough behind-schedule > already that it's very unlikely to happen by then. Like most things in open > source, it's limited by available labor. People who want to see it happen > will need to help out if they want it to happen faster. For this particular > issue of GPL dependencies, the most useful places to contribute would be > helping set up BinDeps for the forked Rmath-julia library so it does not > need to be built by base and Distributions.jl can still work well and be > easy to install, and asking on the "New DFT API" pull request whether there > are specific areas where Steven Johnson needs help - likely answers are > benchmarking, conflict resolution to rebase to master, and setting up FFTW > as a package with automatic BinDeps etc. > > > > Removing things from Base has proven difficult to do smoothly, and while > it will be necessary to slim down the mandatory runtime dependencies for > embedding, static compilation, and less-restrictive licensing use cases, a > lot of work still needs to be done to figure out how to manage code > migrations in the least disruptive manner possible. I don't think this is > the primary concern of any core Julia developers or contributors at the > moment (in fact several people have said they would strongly prefer to not > remove any other code from Base until after 0.4.0 is released, and I agree > with that), but help and contributions are always welcome. > > > > > > On Wednesday, April 15, 2015 at 6:51:44 AM UTC-7, Sebastian Good wrote: > > Is producing a non-GPL Julia build still on the radar? It might be a > nice goal for the 0.4 release, even if we have to build it ourselves (e.g. > against MKL, etc.) > > > > On Monday, April 21, 2014 at 5:00:47 PM UTC-4, Steven G. Johnson wrote: > > > > > > On Monday, April 21, 2014 4:40:38 PM UTC-4, Tobias Knopp wrote: > > Yes this is awesome work you have done there. Do you plan to implement > the real-data FFT, DCT and DST in pure Julia also? Then one could really > think about moving FFTW into a package. Hopefully its author is ok with > that ;-) > > > > I plan to implement real-data FFTs, and move FFTW into a package. > > > > Pure-Julia DCT and DST are not in my immediate plans (they are a PITA to > do right because there are 16 types, of which 8 are common); my feeling is > that the need for these is uncommon enough that it's not terrible to have > these in a package instead of in Base. (Hadamard transforms and MDCTs > are also currently in packages.) > > > >
