On Fri, Nov 22, 2013 at 10:33 AM, Barry Smith <[email protected]> wrote:
> > Hmm, since under normal usage the factored matrix is owned by one of the > PCFactor subclass objects do we actually want the PCFactor subclass to > manage the viewing of them from the command line and not the “Mat” directly > ? Something like -pc_factor_mat_view xxx ? I think this approach > would lead to clean simple code, while trying to force it through the > MatSetFromOptions() to get the viewer would be convoluted since the > factored matrix may not exist when PCSetFromOptions() is called and > creating that matrix early (while possible) doesn’t seem the right model. I > prefer -pc_factor_mat_xxx options rather than -mat_xx options for anything > related to the factored matrix. > So I assume you would have PCFactor set the prefix of the matrix to prefix+"pc_factor_" and call MatViewFromOptions() inside the PCView()? Matt > Sound ok? > > Barry > > > On Nov 22, 2013, at 9:59 AM, Jed Brown <[email protected]> wrote: > > > Barry, at some point in your of Mat viewers, factored matrices became > > disconnected form -mat_view. PCLU does not call MatSetFromOptions() on > > the factored matrix and we don't want to do a MatSetFromOptions() on > > each iteration. Should MatGetFactor() be restructured to take a Mat > > that has already been created, so that it can have options set once? > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
