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 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. 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 get-go, or down the road. Up to whoever is doing the patching :) Phil > 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. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org