Hey, > Wouldn't a custom overload require to write in the viennacl namespace?
yes - do you see any problem with that? A user does not need to alter any of the ViennaCL source files. Best regards, Karli > > On May 19, 2014 1:03 PM, "Karl Rupp" <r...@iue.tuwien.ac.at > <mailto:r...@iue.tuwien.ac.at>> wrote: > > Hi Philippe, > > > What would you guys think about using some additional control > over the > > iterative solvers. I've thought about: > > - Matrix-vector product policy : can be useful for "matrix-free" > > implementations. > > This already works. Just overload prod() and prod_impl() accordingly for > a user 'matrix' type. I agree that an example should be added on how to > do this, as this has shown up several times already: > https://github.com/viennacl/viennacl-dev/issues/74 > > > > - Custom stopping criterion > > Yes. At least provide a switch between 'true residual' and > preconditioned residual. > > > > - For CG, a policy for "what to do when the matrix is found to be > > indefinite (pAp < 0) > > The easiest is to throw an exception. > > > > I've had to reimplement CG for this reason (for nonlinear truncated > > newton methods), and some others users might have had to reimplement > > them too in some other context. > > 1.) It would be nice to provide a callback hook which gets called after > each iteration with the current solution vector. This can be both a > monitor and a custom stopping criterion at the same time. > > 2.) A status flag which indicates whether the function exited because of > a successful termination, or whether the maximum number of iterations > was reached, or the solver diverged. Possibly others. > > > > Can you think about any other functors one could pass for other > solvers > > such as GMRES (for which I have no knowledge)? > > I can only think of very solver-specific quantities. For example, one > can compute some estimates on the condition number from GMRES. > > > What makes these changes somewhat messy is the current API: With > x = solve(A, x, solver_tag()); > the only possibility to provide these customizations is to put them into > the tag, e.g. > cg_tag my_cg_tag; > my_cg_tag.set_something(a); > x = solve(a, x, my_cg_tag()); > assert( my_cg_tag.status() == VIENNACL_CG_CONVERGED ); > which makes this all quite messy because the tag needs to be a > const-reference, so all status flags and the like need to be mutable. > This was a bad design choice... :-( > > I've got a couple of improvements to CG and friends in line, so I can > also implement these extensions as needed. Any suggestions for further > enhancements are welcome :-) > > Best regards, > Karli > > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform > available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > ViennaCL-devel mailing list > ViennaCL-devel@lists.sourceforge.net > <mailto:ViennaCL-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/viennacl-devel > ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
