> Then we're back to dependency issues where now theres "another" > interface that is restrictive and difficult to expand upon easily, it > will be hard to add things to the library because everyone will be > arguing about what should/shouldn't be in interface, uughh. :-( > > I am becoming more and more against having these "generic" Univariate > interfaces where a particular statistic is embodied in a "method". every > time someone comes up with a "new method" there will be debate about > should it be in the interface or not. Instead of just being an > additional class that can be added to the package. This is the benefit > of a framework over monolithic interfaces. >
Preach on brother Mark. I too would argue that the Univariate interfaces need to change and take on more of the look and feel provided by Mark and his statistic objects. One reason for this is flexibility. By forcing Univariate to determine the statistics it can compute we limit users as to when they can use Univariate's features of window and storageless computation. That is to say, a user only gets the benefit of those features iff the statistics they need computed are defined by the interface. Granted, we've taken some effort to include the most commonly used statistics in the interface, but others remain that the user might have a need for but can't leverage Univariate to compute them. By using statistic objects, like those supplied by Mark, and some way to supply those object data via the Univariate objects we can eliminate that limitation of the current design. Another reason for this is performance. The storageless Univariate implementation is a compute all or nothing design. Because of this, every time a new statistic is added to the interface, the extra computation needed to compute the new statistic slows down the computation of the existing statistics. With the current design, if a new statistic is added, all current users of Univariate in adversely effected, in terms of performance, by the change even though they don't rely on the new statistic. For instance, add Mark's auto-correlation coefficients and all of a sudden all existing test statistics using Univariate have gotten slower. That is a clear sign of bad design. Still another reason is maintenance. With every new statistic added to Univariate, besides the method added to support the statistic, numerous other methods need to change to support the computation, most notably addValue. Each addition of a statistic will make that method more complex which in turn makes it harder to debug, harder to change, and harder to understand. Also, with changing existing, working code, one runs the risk of introducing errors where none previously existed. It would royally bite, once we added auto-correlation coefficients again and then have variance no longer work. In comparison, it's impossible to break existing code by adding new code that isn't dependent on anything else, such as the case with Marks statistic objects. Brent Worden http://www.brent.worden.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
