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?
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
