Hi Philippe, > I completely agree, concerning matrix-free implementations of the linear > solver. > > Their absence is the very reason why I had to reimplement solvers for > UMinTL.
I assume you are aware that you can overload viennacl::linalg::prod() for whatever custom 'matrix' type you pass to solve()? > Furthermore, some other fancy stopping criterions may be > provided. For example, some algorithms in unconstrained optimization use > CG on an indefinite matrix, and abort the solver once p^TAp < 0. There > are also some probabilistic stopping criterions for CG when the > matrix-free implementation is an estimator of the true matrix-vector > product. In the end, the CG I ended up with for UMinTL is pretty big and > flexible, and I think it would be a good thing to have the same thing > within ViennaCL. The monitoring capabilities for the iterative solvers in ViennaCL are indeed poor, not providing any feedback to the outside about the current residual and/or custom stopping criteria, convergence reasons, etc. Improving this is desirable, among many other things to do as well. Again a matter of priorities... ;-) Best regards, Karli ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/viennacl-devel
