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/07/03 21:23:25 UTC
[math][collections] Customized Primitive Collections
Hey all,
After reviewing the needs in [math] for primitive collections and the
available implementations of Primitive Collections in [collections] is
become obviously clear to me that it is logical to refactor the great
DoubleArrays we use in [math] to extend the primitive collection
implementations.
From the [collections] group standpoint our goal would be to provide
customized implementations of double collections that are capable of
both growth/shrinkage in size and "rolling window" behavior .
From the standpoint of [math] the primitive tools in the [collections]
library provide an excellent "bridge" to provide efficient primitive[]
storage implementations that work well as both java.util.Collections and
double arrays. While we have allot of discussion about getting our math
package to work great with Collections, the [collections] group may
already have all the tools required to actually manage these
capabilities via their implementations without math needing to "reinvent
the wheel" in this case. And, making [math] work with the [collection]
library just "opens up the hangar doors" in terms of overall usability.
(Brents already exploring this usefull interaction with Frequency and
[collection] "Bag" implementations).
While we talk about code duplication being "allowed" in commons
projects, IMHO, this one place where its a poor decision to continue
doing so. With just a little research and interaction between the two
groups this "bridge" could easily be crossed. I'm willing to do some of
this leg work to accomplish the task given that I've been experimenting
with refactorings that turn DoubleArrays into Collections in the math
package.
Any input the [collections] group could provide on achieving this goal
would be of the greatest help, eventually, such extended implementations
could easily find a home in collections and be available for other
projects as well. As usual, I know you'll all let me know what you think
of this matter. I look forward to your viewpoints! ;-)
Cheers,
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.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][collections] Customized Primitive Collections
Posted by Rodney Waldhoff <rw...@apache.org>.
As far as I'm concerned the *.primitives.* packages are ready for release
at any time. Indeed, I use them regularly in production systems (via
Axion <http://axion.tigris.org> and others), and the non-deprecated code
has 100% coverage according to clover.
It may be reasonable, but not required in my mind, to "clone" the
IntCollections utilities to the other primitive types.
Also, it might be worth considering releasing
commons-collections-primitives.jar independent from
commons-collections.jar. There is no association between anything "under"
primitives and anything "over" it--they are completely independent except
for the testing framework.
- Rod <http://radio.weblogs.com/0122027/>
On Sun, 6 Jul 2003, Tim O'Brien wrote:
> <snip/>
>
> "rolling" could be implemented using a version of
> CircularFifoBuffer which could accept double primitives.
>
> It would be important to gauge the "Readiness" of the o.a.c.collections.primitives
> classes. Is there an sense of a timeline for the next collections release?
> Until we get an answer to that, I'd recommend that commons-math not add
> a dependency to the SNAPSHOT for collections.
>
> Tim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math][collections] Customized Primitive Collections
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Tim O'Brien wrote:
> <snip/>
>
> "rolling" could be implemented using a version of
> CircularFifoBuffer which could accept double primitives.
>
> It would be important to gauge the "Readiness" of the o.a.c.collections.primitives
> classes. Is there an sense of a timeline for the next collections release?
This is a good point we should discuss readiness with the collections
crew. Note, I think Rodney Wandhoff has handled the primitive collection
development so he is probably the most knowledgeable source for its status.
> Until we get an answer to that, I'd recommend that commons-math not add
> a dependency to the SNAPSHOT for collections.
>
I changed to the snapshot so we could at least experiment with them. We
should be careful about using these dependencies. I have not, as of yet
started to use them.
Note that in Maven, dependency on a SNAPSHOT during development is
resolved to a "version" on release of a distribution of your project.
You can set dependencies as SNAPSHOTs because the snapshots are just
soft links to a fully numbered version in the maven repository (this can
be a full release or a dated build). When you release, the SNAPSHOT is
resolved to the existing repository version. So your assured of having
the jar you developed against available in the future for download. Also
note that many Commons and Jakarta projects have released with
dependencies on dated jars, though I do recognize its also good to
release with dependencies on solid versions as they stick around longer
and tend to be more stable (in theory).
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math][collections] Customized Primitive Collections
Posted by Tim O'Brien <to...@discursive.com>.
<snip/>
"rolling" could be implemented using a version of
CircularFifoBuffer which could accept double primitives.
It would be important to gauge the "Readiness" of the o.a.c.collections.primitives
classes. Is there an sense of a timeline for the next collections release?
Until we get an answer to that, I'd recommend that commons-math not add
a dependency to the SNAPSHOT for collections.
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math][collections] Customized Primitive Collections
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Rodney is the main writer of the priitive collections.
>From my point of view, if we can add [math] as a user of [collections] all
the better. Hopefully there are no major changes needed. If I read
correctly, you will advise if there is anything blocking your use of the
classes.
Stephen
----- Original Message -----
From: "Mark R. Diggory" <md...@latte.harvard.edu>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, July 03, 2003 8:23 PM
Subject: [math][collections] Customized Primitive Collections
> Hey all,
>
> After reviewing the needs in [math] for primitive collections and the
> available implementations of Primitive Collections in [collections] is
> become obviously clear to me that it is logical to refactor the great
> DoubleArrays we use in [math] to extend the primitive collection
> implementations.
>
> From the [collections] group standpoint our goal would be to provide
> customized implementations of double collections that are capable of
> both growth/shrinkage in size and "rolling window" behavior .
>
> From the standpoint of [math] the primitive tools in the [collections]
> library provide an excellent "bridge" to provide efficient primitive[]
> storage implementations that work well as both java.util.Collections and
> double arrays. While we have allot of discussion about getting our math
> package to work great with Collections, the [collections] group may
> already have all the tools required to actually manage these
> capabilities via their implementations without math needing to "reinvent
> the wheel" in this case. And, making [math] work with the [collection]
> library just "opens up the hangar doors" in terms of overall usability.
> (Brents already exploring this usefull interaction with Frequency and
> [collection] "Bag" implementations).
>
> While we talk about code duplication being "allowed" in commons
> projects, IMHO, this one place where its a poor decision to continue
> doing so. With just a little research and interaction between the two
> groups this "bridge" could easily be crossed. I'm willing to do some of
> this leg work to accomplish the task given that I've been experimenting
> with refactorings that turn DoubleArrays into Collections in the math
> package.
>
> Any input the [collections] group could provide on achieving this goal
> would be of the greatest help, eventually, such extended implementations
> could easily find a home in collections and be available for other
> projects as well. As usual, I know you'll all let me know what you think
> of this matter. I look forward to your viewpoints! ;-)
>
> Cheers,
> -Mark
>
> --
> Mark Diggory
> Software Developer
> Harvard MIT Data Center
> http://www.hmdc.harvard.edu
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org