Hi, okay, the tests in dependent projects triggered, I get segfaults when running CG with ublas-objects. I don't know the exact reason yet, but it needs to be fixed.
Best regards, Karli PS: I'll also reiterate the coding style we agreed upon (with not much effect) about half a year ago next week. Things get too inhomogeneous. > 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 > <mailto: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 > <mailto: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
