Re: [math] BeanUtils, BeanTransformers and BeanListUnivariate
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]
Re: [math] BeanUtils, BeanTransformers and BeanListUnivariate
--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote: > I'm starting to consider that the implementations we have of higher-end > Univariates (ListUnivariate/BeanListUnivariate) are a bit premature. > > 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. +1 It would be nice to see how people are actually using Commons-Math before we provide something like this functionality. While I would err toward guessing that people are doing the more bare-bones numerics I used to do, others might not, and only real usage will tell us whether it's needed as a core feature. > 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. +1 I never liked the Univariate label, and I have a feeling many users would be confused by it. Also, it seems to beg the question of extension to more than one dimension -- is the next one Bivariate (and the one after that Trivariate, etc.), or do we jump immediately to Multivariate? Al = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] BeanUtils, BeanTransformers and BeanListUnivariate
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? 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]