J.Pietschmann wrote:
Mark R. Diggory wrote:
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?
No no no, that wasn't my intention to suggest...just that maybe even the Beanish stuff should be more of a user application level than a math implementation level.
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.
I found another dependency on logging in Discovery. It may be silly to consider this as something I can remove from runtime dependency. I think also its always valuable to have around and maybe it is good practice that programmers should really be using logging as much as they should be using junit testing.
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?
hmm, I'm unsure of the repercussions, I'll let others comment.
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]
