Re: [math] BeanUtils, BeanTransformers and BeanListUnivariate

2003-11-07 Thread J.Pietschmann
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

Re: [math] BeanUtils, BeanTransformers and BeanListUnivariate

2003-11-07 Thread Al Chou
--- 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

Re: [math] BeanUtils, BeanTransformers and BeanListUnivariate

2003-11-07 Thread Mark R. Diggory
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

[math] BeanUtils, BeanTransformers and BeanListUnivariate

2003-11-06 Thread Mark R. Diggory
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,