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 lowlevel 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.steitz@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 lowlevel 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 MATH607 is addressing.
