In Repast they/we encountered that reflection costs tend to make wanting to work with Collections as the core of a mathematical evaluation a bit costly, In RePast the solution to this was to pickup the trove API (similar to BCEL) and actually generate bytecode optimizations of these types of method calls on the Collections of Objects.
Are we at a point where something like BeanListUnivariate (While a nice example usage of the API) is not something we ideally want to get people using when we release as it may require significant improvement or re-evaluation. If so, one trick would be to move its implementation into the test package hierarchy, as such we would be making it an Example usage of the API and not a full fledged Implementation people would use in the Long run.
Also, I've been considering some naming and consolidation of the lower end "Univariate" API. I think this is poorly named (think we discussed this before). I'm considering that Abstract/StoreUnivariate/Impl should probably be named "DescriptiveStatistics". and that Abstract/Univariate/Impl "StorelessDescriptiveStatistics" or "LiteDescriptiveStatistics"
Any thoughts? This would also allow us to remove runtime dependencies on commons-logging and bean-utils.
-Mark
-- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
