Comments (6)
I like this, are you thinking of something like a new package with a purpose much like the one of RecipesBase? A unified API for all the linear algebra packages out there.
from iterativesolvers.jl.
RecipesBase is not the best example because it has a very specific implementation for plotting. But yes, something like that, but more like MathProgBase (JuliaOpt/JuMP) and DiffEqBase (JuliaDiffEq/DifferentialEquations). I'll have a blog post explaining this all in some detail soon.
from iterativesolvers.jl.
I kind of like that \
would generally be "solve linear system" and that you could specify various methods to do that by wrapping the left-hand-side. However, in the case of direct solvers, this is also a matter of dividing computations into subcomponents where you can possibly reuse the expensive part of the computation (the factorization). This is less obvious for iterative solvers so it could be argued that
K = CGSetup(A,args...)
x = K \ b
is a complicated way of writing
x = CG(A,b,args...)
without compuational advantages.
I think that https://github.com/JuliaParallel/PETSc.jl has taken this approach, though, so it might be worth taking a look there.
from iterativesolvers.jl.
without compuational advantages.
It's not about the computational advantages. I explained this in more detail in a blog post. If IterativeSolvers has a common interface that matches other interfaces, package authors would not be required to write a different set of code to use IterativeSolvers.jl's methods, and so not only users but also package authors would greatly benefit.
from iterativesolvers.jl.
I had a short discussion with @JaredCrean2 @stevengj last year about this specific API issue, but I don't think it was conclusive.
To summarize, the design problem as I view it, is really one about object design and what the left operand of \
could mean in a generic function system, and the fact that in iterative methods we want \
or solve
to express the interaction between three [or even four] different types of data - A, b, algorithm specification, and possibly intermediate state of the algorithm.
a) Originally, I thought of as A\b
as purely a way to spell "solve Ax = b
". \
means "solve a matrix problem with its operands", in which case it is natural to interpret "A' \(A, b)
is naturally extended with keyword arguments modifying the meaning of "solve", for example,
i) \(A, b, method=:CG, atol=...)
specifying an algorithm and roundoff tolerance, or even
ii) \(A, b, method=CGSolver(atol=...)
, wrapping roundoff tolerance into the specification of the algorithm. CGSolver
is now an object with its own fields and possibly even its own API. An advantage of this approach is being able to spell the propagation of intermediate state quite naturally, passing in a CGSolver(data=...)
, say, or even as a different.
The advantage of this spelling is that it keeps A, b, algorithm specification, and possibly intermediate state separate.
The disadvantage is that there is no meaningful infix expression and hence no natural way to "hijack" an existing solve written as A \ b
to mean "do an iterative solve instead".
b) @JaredCrean2 presented to me last year an entirely different idea exposed in PETSc.jl. \
now means KSPSolve
, i.e. "when A is a KSPSolve object, solve the system Ax = b using a Krylov subspace method". The first operand is now a Solver object and no longer a matrix or matrix-like function. The spelling then looks something like KSPSolver(A, CGSolver(options)) \ b
, using a notation consistent with (a-ii).
The advantage of this spelling is that A \ b
is still a meaningful infix expression: A
can be substituted by a KSPSolver
. Arguably, it is the only meaningful infix design - A \ Solver(b)
is not sensible.
The disadvantage is that KSPSolver
now takes on characteristics of a God object - all the details of how to calculate and its intermediate data all has to be stuffed into this object. In particular, KSPSolver \ b
is no longer a pure operation (in the functional sense), since the internal state of the LHS will change (although IIRC it is not publicly accessible from the PETSc API).
My subjective opinion (which has changed since last year): the evidence points to (b) as the prevailing convention. To me, this looks like a pattern that is natural in class-based object-oriented programming, but not necessarily one that is natural in a generic function-based system. The convenient infix \
spelling doesn't work the moment you want any more complicated specification of what to do, requiring instead the prefix \(A, b, options=...)
form. Since it is easy to define the necessary method to support (b) with the (a) design, say:
\(::Solver, ::b) = \ (Solver.A, b, solver=Solver(Solver.alltheotheroptions))
we could do it, and might as well do it.
from iterativesolvers.jl.
Since it is easy to define the necessary method to support (b) with the (a) design, say:
That sounds like a good plan. I think the (b) design is necessary since otherwise it's really hard to build packages on top of. With the (b) design, a user just passes a function, and the package just needs to use that function. If it's done with a bunch of kwargs, the package then needs to keep those kwargs around, passing them through, maybe dividing them up if there were some other kwargs mixed in an IterativeSolvers.jl fails if giving an unknown kwarg: it just is a disaster.
So I have already setup part of DifferentialEquations.jl to work with the design (b). You can see from here that it gives a nice clean multi-package API:
http://docs.juliadiffeq.org/latest/features/linear_nonlinear.html#Linear-Solvers:-factorization-1
and it was dead simple to actually put it into affect (here's the only extra line of code in the actual method
). I'll see if I get around to an IterativeSolvers.jl solver which implements at least style (b) to really get this rolling.
from iterativesolvers.jl.
Related Issues (20)
- With left-preconditioning, there is no way to record residual on original equation
- Outdated documentation respect to new tolerance keywords
- GMRES throws error with left preconditioner HOT 1
- cg! sometimes returns NaNs
- lobpcg throws error for non-positive definiteness
- Many tests very sensitive to the RNG HOT 3
- Boundserror with multiple right hand sides HOT 3
- Errors in IterativeSolvers.jl HOT 1
- Spurious scaling of the default tolerance in `powm`
- Iterator protocol for IDR(s)
- Question about default value of `reltol`
- lsqr! not minimizing norm HOT 1
- powm function does not give the correct answer
- Segmentation fault (core dumped) HOT 1
- svdl fails for complex matrices due to type assertion
- error in CG with Preconditioner HOT 1
- Issue solving 1D Poisson Eq. HOT 1
- GMRES Fails Silently From Stagnation
- BiCGStab Fails Silently
- Using CHOLMOD.Factor as preconditionner
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from iterativesolvers.jl.