Hi,
> I think that it would have some limitations in my case.
Which?
> 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;
> }
In each case you pass something to conjugate_gradient() that is an
object, so an overload for prod() is sufficient. You are free to choose
whether you dispatch based on type or some runtime information later,
but in the end it's all about providing an operator that can be applied
to a vector - which we happen to call prod().
> 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.
Which input information do you require for that computation? A monitor
based on just the current guess for the solution is easy. Is additional
information required? (Note that you can hold references to the
matrix/operator and the right hand side in the monitor, so it's not
necessary to passed them each time)
> 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...
True, it's actually quite a frequent requirement for 'advanced' usage...
> 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));
Just passing a tolerance and maximum number of iterations already works
with the current API. ;-) How do you envision the API for setting your
own monitors? How are they called?
(I'm fine with passing monitors to the solver tags as function
pointers... With some C++ tricks one could also allow some templates in
the solver tags without breaking the existing interface so that a user
can pass his or her own functors.)
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
