On Tue, Nov 24, 2009 at 11:51 AM, Roy Stogner <[email protected]> wrote: > > On Tue, 24 Nov 2009, John Peterson wrote: > >> On Tue, Nov 24, 2009 at 11:10 AM, Roy Stogner <[email protected]> >> wrote: >>> >>> It looks like the cholesky back substitution never reuses b(i) outside >>> of (or at later iterations in) the i loop; surely we can replace that >>> with a single scalar on the stack. The LU back substitution is >>> trickier, since that's storing a full vector's worth of temporary >>> data, but do we need to store said temporary data in b? It looks like >>> we can probably get away with using the unfinished parts of x instead. >> >> So: keep the same interface and rework the algorithms? > > To the extent that that's possible and efficient, anyway. If we > wanted to add an additional overwrite-in-place interface, though, > that's not a bad idea. As you discovered, typically we discard the > rhs after using it anyway. > >> We could still maintain a two-vector input API, but the Lapack >> implementation would have to make a copy of the RHS before the back >> substitution step overwrites it internally. > > I think having both one-vector and two-vector versions sounds like the > way to go; that way people who don't need to save the RHS don't waste > time saving it in the Lapack implementation.
OK, cool. And I'll assume we are agreed that the two-vector versions should not modify their rhs inputs any longer, just to be on the safe side... -- John ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
