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 <t...@kelman.net> 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.) >
