In the simplest instance, an operator based solver might be able to advertise an incremental accumulation interface if it maintains an internal representation that could be used as a linear operator. As more data is added, the internal representation could be augmented and then whatever form exists could be used when solving is required. By retaining old solutions, some economy could be had relative to finding new solutions, but this would definitely not be a truly incremental solver.
Whether an operator based solver is more low-level than any other solver is, of course, in the eye of the beholder. I called the operator approach lower level simple because it could be hidden behind a facade to emulate the alternative view while a solver such as LUD cannot emulate operator based solutions. It is fine to push out such consideration as being out of scope, but I think it would be nice to consider them for just a moment since small changes now could facilitate later integration if that is desirable. On Wed, Jul 6, 2011 at 11:03 AM, Phil Steitz <phil.ste...@gmail.com> wrote: > > Looking through commons there is public interface DecompositionSolver. > > Perhaps an extension of this interface is what you are thinking of? > > > > Phil what are your thoughts? > > Sorry to be slow to respond on this. I am not sure I understand > exactly what Ted is getting at, as it would seem that at least from > the model definition / data acquisition standpoint, what you have > defined is about as low-level as you can get and appropriate for the > use case, which is to support incremental adding / streaming of data > into a multiple regression model (like the "storeless" statistics > elsewhere in [math]). Enabling large models to be specified via > linear operators as well would be good if that is the suggestion, > but it is not clear to me how a linear operator model specification > interface could support the use case that the MATH-607 is addressing.
