commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] API changes for RC2
Date Sun, 26 Sep 2004 18:15:12 GMT
Mark R. Diggory wrote:
> Yes, I have no problem with .descriptive and .regression. Your correct 
> about the hierarchical decomposition, thats why if we can identify our 
> own "policy" for hierarchical decomp. then at least we have a clear 
> defense when package renaming is requested.

OK, I will get to work on this. If no one complains, I will cut RC2 
including this change.
> Think of it more as "Iterators" or "Enumerations", These classes provide 
> the same sort of functionality for the Collections API. Yes, there are 
> "copy semantics" and "concurrent modification rules" that need to be 
> employed the same as Collections. As well, I would suggest the idea that 
> a Matrix be "final" and "Immutable" in the same way as any 
> java.lang.Number implementation, and if not possible in all cases, then 
> the mutability should possibly be done internally in the implementation.

I agree with the usefulness and how you are thinking about this. The 
question is, shouldn't these factory/iterator-type thingies be in separate 
classes -- i.e., does this stuff really belong in the RealMatrix interface 
itself?  Unless the answer is yes, we can add these in 1.1

>> What we need to do here, if we want to get this done correctly before 
>> 1.0 is design a "RandomSource" or "RandomGenerator" interface. 
>> Unforturnatlely, java.util.Random is not an interface and what we need 
>> is to abstract an appropriate interface that will represent this and 
>> any other PRNG (or RNG) that users may want to plug in. This will be 
>> tricky and will require some research and discussion.  We can do this 
>> now; but it will take some time. I would prefer to move forward with 
>> the release, adding a factory to produce RandomData impls, including a 
>> "PRNG-pluggable" version of RandomDataImpl in 1.1.
> This would be the benefit of using RngPack for all Random Number 
> generation, its API already supports this and has a RandomElement 
> interface with various Implementations including one that wraps 
> java.util.Random.
> We can either work to integrate RngPack directly into Commons Math, or 
> put RngPack on ibiblio and make Commons Math dependent on it. This would 
> mean we include the RngPack jars into the Commons Math distributions. 
> This should not be an issue because the package has been relicensed 
> under a BSD style license that is completable with Apache's.

Strong -1 to the dependency (at least for now), but +1, as noted above, to 
making the PRNG pluggable post-1.0, with RngPack providers easily 
integrated (i.e., consider RandomElement in the design of the interface 
that we use). In the end you may be correct that RngPack is "the" PRNG 
framework that we want; but I at least am not ready to jump to that 
conclusion -- and accept the dependency -- at this point. Do you really 
feel that it is essential to complete this prior to 1.0?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message