I'm just realizing that, while such checks make sense in the case of
self-assignement, we probably shouldn't do it for inner_prod(), since it
should technically result in a different expression tree. The good way to
implement it would be through a pre-processor for scheduler::statement
(like in Theano), but we're not there yet. So, i'll just perform an
additional check within CG for now
Philippe
2014-05-21 23:04 GMT+02:00 Philippe Tillet <phil.til...@gmail.com>:
> Hi,
>
> Ok thanks, i'll do it!
> I did this trick:
>
> template<typename VectorType, typename PreconditionerType>
> class z_handler{
> public:
> z_handler(VectorType & residual) : z_(residual){ }
> VectorType & get() { return z_; }
> private:
> VectorType z_;
> };
>
> template<typename VectorType>
> class z_handler<VectorType, viennacl::linalg::no_precond>{
> public:
> z_handler(VectorType & residual) : presidual_(&residual){ }
> VectorType & get() { return *presidual_; }
> private:
> VectorType * presidual_;
> };
>
> And then, in the code:
>
> z_handler<VectorType, PreconditionnerType> zh(residual);
> VectorType& z = zh.get();
>
> The rest can either be done as if(&z == &residual) or by checking
> self-assignments, and the address of the arguments of norm. I've chosen the
> latter option, since I don't see any drawback to redirecting inner_prod to
> norm2 when the two arguments are the same, or returning *this directly for
> a self-assignment. Plus, some users might end up doing similar things too,
> so it's better to have it handled internally
>
> Philippe
>
>
>
> 2014-05-21 21:35 GMT+02:00 Karl Rupp <r...@iue.tuwien.ac.at>:
>
> Hi,
>>
>>
>> > I've slightly modified the CG implementation to handle preconditionned
>>
>>> CG and unpreconditionned CG in the same routine (without adding any
>>> extra allocation/copy), but I can't find a routine to test that I
>>> haven't introduced a bug. Running
>>> grep "cg_tag" tests/src/*
>>> returns no result.
>>> Do we have a test for the iterative solvers, or just examples?
>>>
>>
>> unfortunately there is no native test in ViennaCL itself. Some other
>> Vienna-libraries test their solvers against viennacl-dev, so this part of
>> functionality is checked indirectly.
>>
>> The easiest way to verify proper operation 'by hand' is to check the
>> residuals reported through 'solverbench'.
>>
>> Btw: How does your unified implementation behave performance-wise? I
>> think the reason this was not unified is that a plain CG somewhere saves a
>> memory transfer (norm() instead of inner_prod() or related). On the other
>> hand, the pipelined CG version I'll push soon will require some extra
>> tweaks for ViennaCL-types, so it's good to have a single 'generic'
>> implementation for non-ViennaCL types.
>>
>> 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
