Hi,
2014-05-19 15:14 GMT+02:00 Karl Rupp <r...@iue.tuwien.ac.at>:
> 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().
>
>
I think I get it, finally. It's indeed possible through something like.
struct virtual_matrix{
std::size_t size1();
std::size_t size2();
computation_tag tag;
};
namespace viennacl{
namespace linalg{
void prod(virtual_matrix, viennacl::vector<>); // do dispatch it
}
}
Although not very intuitive, this does not look too dirty. It's actually
better than my initial solution because it would allow me to use any
viennacl routine transparently. Such matrix-free trickery should definitely
be documented through an example :P
>
>
> 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 criterion is pretty complicated, so I cannot explain it in too much
detail. The monitor needs to be initialized with the first residual value :
I do monitor.init(p0) in my case. I'm aware that this needs not be in the
CG procedure itself, but it would cost one more product then, which could
be quite a lot in some cases. But well, it can be the price to pay for a
clearer interface.
>
>
> 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...
Well, whenever one has a big dense matrix that cannot be stored in memory,
at least :)
>
>
>
> 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.)
>
>
This is no longer necessary for the product :) Now, for the tolerance, I
think that a monitor has to be passed, but this can be done through the tag
using virtual functions. Sure, it will add a vtable and a vptr inside a
tag, but I can't think of a reasonable scenario when the memory footprint
would be dominated by the solver's tags :P
Philippe
> 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
