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.
Nice, but using a byte code manipulator in [math]? Shudder! We don't do byte code! Isn't there a high-level API available for this purpose?
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"
Sounds useful: +1.
This would also allow us to remove runtime dependencies on commons-logging and bean-utils.
I somehow think the commons package could use another reorganization, for example splitting a JDK 1.3 compatibility package with nestable exceptions a a bunch of other stuff delivered in 1.4 out of [lang].
Why does beanutils depend on logging? Maybe a split of this package could help too.
Unrelated to math but perhaps to the beanutils dependencies: While working on [text] I noticed some similar patterns: - core library with deps mainly on [lang] - tools depending on ant (for ant tasks), [cli], [digester], [logging] and others - Unit tests depending on all kinds of weird libs.
How should commons components be organized? Should we have o.a.c.stuff o.a.c.stuff.tools o.a.c.stuff.anttask or rather o.a.c.stuff o.a.c.tools.stuff ...
Opinions?
J.Pietschmann
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
