Hey,
Wouldn't a custom overload require to write in the viennacl namespace?
On May 19, 2014 1:03 PM, "Karl Rupp" <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
> 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
