Karl Rupp <[email protected]> writes: > Cool! For packaging, we should either integrate it completely (i.e. make > it part of the ViennaCL namespace), or keep it entirely separate, > similar to how e.g. amgcl handles things. Packaging the two together > would be a nightmare for packagers (Toby, please correct me if I'm wrong).
Yeah, you're right: distribution packagers prefer to keep things at a sensible granularity; to avoid dependency hell and a security nightmare, distributions prefer to 'unbundle' bundled software, so that separate pieces can be upgraded or patched as needed and independently. > Yep, that's exactly why I've spent quite a bunch of effort on the > 'infrastructure' rather than adding more and more implementations of > algorithms and preconditioners recently. Having a full-fledged API for > all three backends now makes algorithm development a lot more fun :-) To me, the ViennaCL infrastructure is one of its most exciting properties :) And, as an aside, I'd be generally in favour of integrating the nonlinear minimisation library into ViennaCL (or at least into pyViennaCL), since I'm starting a course on nonlinear optimisation in October, and so Philippe's work is quite interesting to me. Best, Toby ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/viennacl-devel
