You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Mark R. Diggory" <md...@latte.harvard.edu> on 2003/11/07 02:04:56 UTC
[math] BeanUtils, BeanTransformers and BeanListUnivariate
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
Re: [math] BeanUtils, BeanTransformers and BeanListUnivariate
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] BeanUtils, BeanTransformers and BeanListUnivariate
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] BeanUtils, BeanTransformers and BeanListUnivariate
Posted by Al Chou <ho...@yahoo.com>.
--- "Mark R. Diggory" <md...@latte.harvard.edu> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org