--- Al Chou <[EMAIL PROTECTED]> wrote: > --- Phil Steitz <[EMAIL PROTECTED]> wrote: > > Here is an updated version. I will try to submit a patch to the > > task.xml reflecting this before I leave this AM, but I am running out of > > time... > > > > * Improve numerical accuracy of Univariate and BivariateRegression > > statistical > > > computations. Encapsulate basic double[] |-> double mean, variance, min, > > max > > > computations using improved formulas and add these to MathUtils. > (probably > > > should add float[], int[], long[] versions as well.) Then refactor all > > > univariate implementations that use stored values (including > UnivariateImpl > > > with finite window) to use the improved versions. -- Mark? I am chasing > > down > > > the TAS reference to document the source of the _NR_ formula (done), > which > > I will add > > > to the docs if someone else does the implementation > > > > Al submitted a patch covering part of this last night. > > Note that I didn't do anything in the finite-window part of > UnivariateImpl.insertValue(), because I didn't know how. I just realized we > may just be able to use the "weight = -1" case described in Hanson and Chan & > Lewis. I'll read them more carefully to see if that's correct. > > Also, the corrected two-pass algorithm still needs to be put into > StoreUnivariateImpl, right? >
Yes, if we think it will make a difference. Chan's paper suggests that the standard two-pass algorithm, which we have in the AbstractStoreUnivariate now, is just about as good. There is no need to mess with the insertvalue stuff, we just need to make sure that when the actual statistics are reported in the finite window case, the best "stored" computations are performed directly on the stored vector. This is one reason that I wanted to encapsulate these vector computations into StatUtils. > > > > * Framework and implementation strategie(s) for finding roots or > > real-valued > > > functions of one (real) variable. Here again -- largely done. I would > > prefer > > > to wait until J gets back and let him submit his framework and R. Brent's > > > algorithm. Then "our" Brent's implementation and usage can be integrated > > > (actually not much to do, from the looks of the current code) > > > > Need to make a decision here. I suggest that Brent makes the > > improvements that he has in mind to J's framework, puts into the new > > package (earlier post) and refactors existing stuff. > > Sounds reasonable (or do I say "+1"?). I think we need _something_ submitted > in the way of root finding framework so we can give feedback. > > > > > * Polynomial Interpolation -- let Al tell us what to do here. Even > better, > > let > > > Al do it (he he). > > Use rational functions, per Al's suggestions. Maybe implement natural > > spline instead. Al? Anyone? > > I need to find a non-NR reference to the Stoer and Bulirsch algorithm for > rational function interpolation (I don't own a copy of their book), otherwise > I'll just be relying on NR's description. > > I don't have an objection to providing cubic splines, though we should be > aware > that they open the door to providing a tridiagonal linear system solver. I was just thinking of them as an alternative approximation solution. > > > > Al > > ===== > Albert Davidson Chou > > Get answers to Mac questions at http://www.Mac-Mgrs.org/ . > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
