I think that it would have some limitations in my case. I am dealing with
the special case of hessian-vector products, and there can be multiple
policies for computing such matrix-vector product:
-> Finite differencing : Hv = (grad(v+h) - grad(v-h)) / 2h
-> Some exact methods in some particular cases (for neural networks for
example) : user-provided.
These do not require the storage nor the knowledge of A (A couldn't even be
passed as an argument)
so the implementation is like that:
switch(method){
case NORMAL_PROD : conjugate_gradient(compute_prod_with(A), b);
case FINITE_DIFFERENCING :
conjugate_gradient(finite_differencing_hv_prod(grad), b); break;
case USER_PROVIDED : conjugate_gradient(user_provided_hv_prod, b); break;
}
As for the custom stopping criterion, it would also require some changes in
the tag, since tolerance wouldn't always make sense. For my application, I
happen to have a stopping criterion where the tolerance is automatically
computed.
This would require quite a few interface changes, but on the other hand I
can't imagine that I'm the only one on earth needing such features -- and
reimplementing CG/BiCGStab/GMRes from scratch because of this sounds
redundant... I I think that we could provide some more control over CG, and
keep the current interface solve(A, b, cg_tag(tol)), which would redirect
to something more complicated such as:
conjugate_gradient_impl(compute_prod_with(A), b, tolerance_stop(eps));
So that one would still be able to have more control if he wants to.
Philippe
2014-05-19 13:34 GMT+02:00 Karl Rupp <r...@iue.tuwien.ac.at>:
> 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
