commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject [math] BeanUtils, BeanTransformers and BeanListUnivariate
Date Fri, 07 Nov 2003 01:04:56 GMT
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.

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message