On 7/6/11 11:12 AM, Ted Dunning wrote:
> 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.
OK, I get it now, you are talking about implementation.
> 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.
I get it now, thanks. Its OK then to start with the public API that
Greg has suggested and look at operator approaches internally,
either from the getgo, or down the road. Up to whoever is doing
the patching :)
Phil
> 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.

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
