You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2008/02/11 06:33:46 UTC
[math] 1.2-RC1 available for review
The zips / tars are here:
http://people.apache.org/~psteitz/math-1.2-RC1/
The site included in the binary distro is here:
http://people.apache.org/~psteitz/math-1.2-RC1/docs/
Release notes:
http://people.apache.org/~psteitz/math-1.2-RC1/RELEASE-NOTES.txt
Ant, Maven 1 and Maven 2 builds should all work from the unpacked
source distribution.
Comments / suggestions for improvement welcome!
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] 1.2-RC1 available for review
Posted by Niall Pemberton <ni...@gmail.com>.
On Feb 11, 2008 12:46 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 2/11/08, Niall Pemberton <ni...@gmail.com> wrote:
> > The license-header.txt file is not included in the source distro -
> > which causes the checkstyle to fail when building from the src distro
> > - I've added that in (hope you don't mind):
> >
> > http://svn.apache.org/viewvc?view=rev&revision=620449
> >
> Thanks.
>
> > Theres a couple of other files in trunk that are not in the source
> > distro (test-jar.xml and testOnly.sh) - does that matter?
>
> testOnly.sh is a convenience script that runs m1 from the command line
> and just runs tests for a limited set of packages. test-jar.xml is
> for compiling and running tests against a pre-built jar (for JDK
> compatibility testing). I don't think we need to include these.
>
> >
> > Also there are no -sources.jar and -javadoc.jars which would be nice -
> > if you use the "rc" profile (specify -Prc on command line) these
> > should be produced - although I had "fun & games" getting the build to
> > produce everything for IO 1.4 and sign it all. IO's pom.xml also
> > defines an "rc" profile which produces the site and "assemblies" in
> > the "package" phase and I ran the following command for IO 1.4
> > release:
> >
> > mvn -Prc clean source:jar javadoc:jar install -DcreateChecksum=true
> >
> > this worked producing everything and creating checksums and signing
> > all the artifacts - the only downside was the -javadoc.jar and
> > -sources.jar inside the binary distro had a different timestamp from
> > the signed versions outside (because in commons-parent-7 the sources
> > and javadocs plugins are not attached to the "package" phase in the
> > "rc" profile - this will be fixed in commons-parent-8).
> >
> > If you want I can add an "rc" profile to commons math which attaches
> > the site, sources, javadoc and assembly plugin to the "package" pahse
> > then all you need to do to produce all the artifacts is:
> >
> > mvn -Prc install -DcreateChecksum=true
> >
> > (although I guess the maven way is to use the release plugin - but I
> > don't like the noise it produces [3 commits] for every release
> > candidate).
> >
> > Anyway if you think this is a good idea the profile would look like this:
> >
> > <profiles>
> > <profile>
> > <id>rc</id>
> > <build>
> > <plugins>
> > <plugin>
> > <artifactId>maven-site-plugin</artifactId>
> > <executions>
> > <execution>
> > <goals>
> > <goal>site</goal>
> > </goals>
> > <phase>package</phase>
> > </execution>
> > </executions>
> > </plugin>
> > <plugin>
> > <artifactId>maven-source-plugin</artifactId>
> > <executions>
> > <execution>
> > <id>create-source-jar</id>
> > <goals>
> > <goal>jar</goal>
> > </goals>
> > <phase>package</phase>
> > </execution>
> > </executions>
> > </plugin>
> > <plugin>
> > <artifactId>maven-javadoc-plugin</artifactId>
> > <executions>
> > <execution>
> > <id>create-javadoc-jar</id>
> > <goals>
> > <goal>jar</goal>
> > </goals>
> > <phase>package</phase>
> > <configuration>
> > <source>${maven.compile.source}</source>
> > </configuration>
> > </execution>
> > </executions>
> > </plugin>
> > <plugin>
> > <artifactId>maven-assembly-plugin</artifactId>
> > <executions>
> > <execution>
> > <goals>
> > <goal>attached</goal>
> > </goals>
> > <phase>package</phase>
> > </execution>
> > </executions>
> > </plugin>
> > </plugins>
> > </build>
> > </profile>
> > </profiles>
> >
> > Niall
> >
>
> Thanks, Niall. I will play with this. I am not comfortable with the
> machinations of the release plugin, so I will want to create all
> artifacts locally and then deploy "intentionally". I also prefer to
> sign artifacts and produce hashes explicitly using sign_and_hash.sh.
> I will figure out how to do this while getting the voted, signed
> artifacts from the official release published to the maven repo.
OK understood, if you don't need the checksums/signs done for you then
you can just use the following command (and forget the profile
suggestion I made) to produce all the artifacts:
mv -Prc site package assembly:assembly
Then its just a case of creating the checksums / signing. Once the
vote passes to release the maven stuff manually you just copy the
artifacts to:
http://people.apache.org/repo/m2-ibiblio-rsync-repository/commons-math/commons-math/1.2
Then the only other thing to do is take a copy of maven-metadata.xml
and edit it to add the 1.2 version:
http://repo1.maven.org/maven2/commons-math/commons-math/maven-metadata.xml
Create checksums/sign maven-metadata.xml and put it in
m2-ibiblio-rsync-repository as well
(which is what I did for Commons IO 1.4)
Niall
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] 1.2-RC1 available for review
Posted by Phil Steitz <ph...@gmail.com>.
On 2/11/08, Niall Pemberton <ni...@gmail.com> wrote:
> The license-header.txt file is not included in the source distro -
> which causes the checkstyle to fail when building from the src distro
> - I've added that in (hope you don't mind):
>
> http://svn.apache.org/viewvc?view=rev&revision=620449
>
Thanks.
> Theres a couple of other files in trunk that are not in the source
> distro (test-jar.xml and testOnly.sh) - does that matter?
testOnly.sh is a convenience script that runs m1 from the command line
and just runs tests for a limited set of packages. test-jar.xml is
for compiling and running tests against a pre-built jar (for JDK
compatibility testing). I don't think we need to include these.
>
> Also there are no -sources.jar and -javadoc.jars which would be nice -
> if you use the "rc" profile (specify -Prc on command line) these
> should be produced - although I had "fun & games" getting the build to
> produce everything for IO 1.4 and sign it all. IO's pom.xml also
> defines an "rc" profile which produces the site and "assemblies" in
> the "package" phase and I ran the following command for IO 1.4
> release:
>
> mvn -Prc clean source:jar javadoc:jar install -DcreateChecksum=true
>
> this worked producing everything and creating checksums and signing
> all the artifacts - the only downside was the -javadoc.jar and
> -sources.jar inside the binary distro had a different timestamp from
> the signed versions outside (because in commons-parent-7 the sources
> and javadocs plugins are not attached to the "package" phase in the
> "rc" profile - this will be fixed in commons-parent-8).
>
> If you want I can add an "rc" profile to commons math which attaches
> the site, sources, javadoc and assembly plugin to the "package" pahse
> then all you need to do to produce all the artifacts is:
>
> mvn -Prc install -DcreateChecksum=true
>
> (although I guess the maven way is to use the release plugin - but I
> don't like the noise it produces [3 commits] for every release
> candidate).
>
> Anyway if you think this is a good idea the profile would look like this:
>
> <profiles>
> <profile>
> <id>rc</id>
> <build>
> <plugins>
> <plugin>
> <artifactId>maven-site-plugin</artifactId>
> <executions>
> <execution>
> <goals>
> <goal>site</goal>
> </goals>
> <phase>package</phase>
> </execution>
> </executions>
> </plugin>
> <plugin>
> <artifactId>maven-source-plugin</artifactId>
> <executions>
> <execution>
> <id>create-source-jar</id>
> <goals>
> <goal>jar</goal>
> </goals>
> <phase>package</phase>
> </execution>
> </executions>
> </plugin>
> <plugin>
> <artifactId>maven-javadoc-plugin</artifactId>
> <executions>
> <execution>
> <id>create-javadoc-jar</id>
> <goals>
> <goal>jar</goal>
> </goals>
> <phase>package</phase>
> <configuration>
> <source>${maven.compile.source}</source>
> </configuration>
> </execution>
> </executions>
> </plugin>
> <plugin>
> <artifactId>maven-assembly-plugin</artifactId>
> <executions>
> <execution>
> <goals>
> <goal>attached</goal>
> </goals>
> <phase>package</phase>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> </profile>
> </profiles>
>
> Niall
>
Thanks, Niall. I will play with this. I am not comfortable with the
machinations of the release plugin, so I will want to create all
artifacts locally and then deploy "intentionally". I also prefer to
sign artifacts and produce hashes explicitly using sign_and_hash.sh.
I will figure out how to do this while getting the voted, signed
artifacts from the official release published to the maven repo.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] 1.2-RC1 available for review
Posted by Niall Pemberton <ni...@gmail.com>.
The license-header.txt file is not included in the source distro -
which causes the checkstyle to fail when building from the src distro
- I've added that in (hope you don't mind):
http://svn.apache.org/viewvc?view=rev&revision=620449
Theres a couple of other files in trunk that are not in the source
distro (test-jar.xml and testOnly.sh) - does that matter?
Also there are no -sources.jar and -javadoc.jars which would be nice -
if you use the "rc" profile (specify -Prc on command line) these
should be produced - although I had "fun & games" getting the build to
produce everything for IO 1.4 and sign it all. IO's pom.xml also
defines an "rc" profile which produces the site and "assemblies" in
the "package" phase and I ran the following command for IO 1.4
release:
mvn -Prc clean source:jar javadoc:jar install -DcreateChecksum=true
this worked producing everything and creating checksums and signing
all the artifacts - the only downside was the -javadoc.jar and
-sources.jar inside the binary distro had a different timestamp from
the signed versions outside (because in commons-parent-7 the sources
and javadocs plugins are not attached to the "package" phase in the
"rc" profile - this will be fixed in commons-parent-8).
If you want I can add an "rc" profile to commons math which attaches
the site, sources, javadoc and assembly plugin to the "package" pahse
then all you need to do to produce all the artifacts is:
mvn -Prc install -DcreateChecksum=true
(although I guess the maven way is to use the release plugin - but I
don't like the noise it produces [3 commits] for every release
candidate).
Anyway if you think this is a good idea the profile would look like this:
<profiles>
<profile>
<id>rc</id>
<build>
<plugins>
<plugin>
<artifactId>maven-site-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>site</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>create-source-jar</id>
<goals>
<goal>jar</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-javadoc-plugin</artifactId>
<executions>
<execution>
<id>create-javadoc-jar</id>
<goals>
<goal>jar</goal>
</goals>
<phase>package</phase>
<configuration>
<source>${maven.compile.source}</source>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>attached</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Niall
On Feb 11, 2008 5:33 AM, Phil Steitz <ph...@gmail.com> wrote:
> The zips / tars are here:
> http://people.apache.org/~psteitz/math-1.2-RC1/
>
> The site included in the binary distro is here:
> http://people.apache.org/~psteitz/math-1.2-RC1/docs/
>
> Release notes:
> http://people.apache.org/~psteitz/math-1.2-RC1/RELEASE-NOTES.txt
>
> Ant, Maven 1 and Maven 2 builds should all work from the unpacked
> source distribution.
> Comments / suggestions for improvement welcome!
>
> Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] 1.2-RC1 available for review
Posted by Phil Steitz <ph...@gmail.com>.
On 2/11/08, Luc Maisonobe <Lu...@free.fr> wrote:
> Phil Steitz a écrit :
> > The zips / tars are here:
> > http://people.apache.org/~psteitz/math-1.2-RC1/
> >
> > The site included in the binary distro is here:
> > http://people.apache.org/~psteitz/math-1.2-RC1/docs/
> >
> > Release notes:
> > http://people.apache.org/~psteitz/math-1.2-RC1/RELEASE-NOTES.txt
>
> Shouldn't we say in the release notes we are OSGI-compliant now ?
Yes. Should have included an "add" item to changes.xml when I
resolved the associated JIRA ticket. Sorry I missed that.
Phil
>
> Luc
>
> >
> > Ant, Maven 1 and Maven 2 builds should all work from the unpacked
> > source distribution.
> > Comments / suggestions for improvement welcome!
> >
> > Phil
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] 1.2-RC1 available for review
Posted by Luc Maisonobe <Lu...@free.fr>.
Phil Steitz a écrit :
> The zips / tars are here:
> http://people.apache.org/~psteitz/math-1.2-RC1/
>
> The site included in the binary distro is here:
> http://people.apache.org/~psteitz/math-1.2-RC1/docs/
>
> Release notes:
> http://people.apache.org/~psteitz/math-1.2-RC1/RELEASE-NOTES.txt
Shouldn't we say in the release notes we are OSGI-compliant now ?
Luc
>
> Ant, Maven 1 and Maven 2 builds should all work from the unpacked
> source distribution.
> Comments / suggestions for improvement welcome!
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] 1.2-RC1 available for review
Posted by sebb <se...@gmail.com>.
On 11/02/2008, Phil Steitz <ph...@gmail.com> wrote:
> The zips / tars are here:
> http://people.apache.org/~psteitz/math-1.2-RC1/
>
Sigs and digests OK. Contents look OK.
> The site included in the binary distro is here:
> http://people.apache.org/~psteitz/math-1.2-RC1/docs/
http://people.apache.org/~psteitz/math-1.2-RC1/docs/dependencies.html
does not have a web-site link for Commons Discovery, and refers to
http://jakarta.apache.org/commons/logging/
as the web-site for Commons logging.
RAT report includes a lot of what appear to to be temporary files, e.g.
junit134096952.properties
Also velocity.log.
Not sure if this is due to a limitation in RAT or whether the source
data was in an inconsistent state when the report was run, but ideally
these should be removed from the report.
RAT also shows that the following should have AL headers:
src/site/xdoc/userguide/xdoc.xsl
There don't seem to be any build instructions in the source or on the web-site.
Details of build tool(s) use and command-lines would be helpful.
The RELEASE-NOTES explain why the errors in the CLIRR report are API
compatible; perhaps a note should be added to the changes report as
well, otherwise there may appear to be a discrepancy between CLIRR and
changes.
[And perhaps the clirr application needs to allow for moving fields to
superclasses ...]
>
> Release notes:
> http://people.apache.org/~psteitz/math-1.2-RC1/RELEASE-NOTES.txt
>
> Ant, Maven 1 and Maven 2 builds should all work from the unpacked
> source distribution.
> Comments / suggestions for improvement welcome!
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] 1.2-RC1 available for review
Posted by Luc Maisonobe <Lu...@free.fr>.
Phil Steitz a écrit :
> On Feb 12, 2008 7:25 PM, Michael Heuer <he...@acm.org> wrote:
>> On Sun, 10 Feb 2008, Phil Steitz wrote:
>>
>>> The zips / tars are here:
>>> http://people.apache.org/~psteitz/math-1.2-RC1/
>>>
>>> The site included in the binary distro is here:
>>> http://people.apache.org/~psteitz/math-1.2-RC1/docs/
>>>
>>> Release notes:
>>> http://people.apache.org/~psteitz/math-1.2-RC1/RELEASE-NOTES.txt
>>>
>>> Ant, Maven 1 and Maven 2 builds should all work from the unpacked
>>> source distribution.
>>> Comments / suggestions for improvement welcome!
>>>
>>> Phil
>> A few comments for consideration:
>
> Thanks, Michael!
Thanks Michael! We're happy to see such deep analysis.
>> Null parameter checks are not consistent.
>>
>> Some classes throw NPE (PolynomialFunction, Complex, ComplexUtils,
>> RealMatrixImpl, MatrixUtils, etc.)
>>
>> Some classes throw IAE (UnivariateRealSolverUtils,
>> StorelessUnivariateStatistic, StatUtils, etc.)
>>
>> Many classes do neither (AbstractEstimator, GaussNewtonEstimator,
>> LevenbergMarquardEstimator, Rotation, RotationOrder, BigMatrix,
>> BigMatrixImpl, QRDecompositionImpl, RealMatrix, RealMatrixImpl,
>> AbstractStepInterpolator, DirectSearchOptimizer,
>> CorrelatedRandomVectorGenerator, EmpiricalDistribution,
>> EmpiricalDistributionImpl, RandomData, RandomDataImpl,
>> UncorrelatedRandomVectorGenerator, VectorialCovariance, VectorialMean,
>> etc.)
>>
>> e.g. EmpiricalDistributionImpl.StreamDataAdapter ctr is especially
>> problematic since NPE wouldn't be thrown until later, when either
>> computeBinStats or computeStats was called
>>
>
> Patches welcome on the last one. The others need to be looked at and
> discussed individually if we want to change behavior and API
> documentation. Javadoc patches welcome.
As far as I know, the only place where NPE is explicitely thrown is in
Complex.pow. All other references to NPE I found in the
src/java/**/*.java file are only in the javadoc comments. They do not
correspond to checks performed at [math] level. This seems quite
reasonable to me.
The case for IllegalArgumentException being thrown for null parameters
is different and must be addressed on a case by case basis. I agree this
is inconsistent, so we should either still perform the check and throw
the exception ourselves (just like Complex.pow does) or let the JVM
throw the exception automatically and not specify it in the javadoc.
However, this would be an API change and cannot be done in 1.2. We have
to wait for 2.0 for such changes.
Could you open a JIRA ticket with an objective fix set to 2.0 for this
issue ?
>
>
>> complex
>>
>> Complex and ComplexFormat could be final
>>
> Not a good idea at this time, IMO.
This would break compatibility. Once again, wait for 2.0. This is the
same sort of problem we encountered with the TOO_SMALL fields in the
matrix classes and which we cannot fix now for compatibility sake.
>
>> estimation
>>
>> AbstractEstimator has several protected fields and public methods that
>> are not final
>
> Here again, -1 on making these final.
There are no compatibility issues here since this class is new in
[math]. The maxCostEval and costEvaluations fields should be private and
the corresponding accessors should be final (they are public). Im am +1
on these two.
I'm not really sure about other fields and methods. Having private
fields and protected final accessors seems unnecessary verbose to me.
Those fields are really useful to the implementation classes and they
can change depending on the way the user calls the library (I sometime
use solvers in a loop and change the settings, sometimes even changing
the number of parameters or measurements between iterations).
>
>> SimpleEstimationProblem ArrayList unbound --> List unbound
>> SimpleEstimationProblem fields private ArrayList --> private final List
>
> Sounds reasonable. Any problems with these changes, Luc?
Why not ? Neither ArrayList nor List appear anywhere on the public
interface, this is really an implementation detail. If you prefer using
List, go ahead.
Declaring the fields to be final is a good idea.
>
>> fraction
>>
>> Fraction and FractionFormat could be final
>
> -1 for 1.2 at least.
I don't understand. [math] is a quite low level library, so we really
cannot know how it will be used and if users won't need to extends the
classes we propose.
The FractionFormat could be guaranteed to be immutable and the two
format fields could be made final in 2.0, though.
>> geometry
>>
>> Rotation minor javadoc fix "if axis norm is null" vs if (norm == 0) { ... }
>
> Patch welcome.
Good catch ! This appears at several places and should also be changed
in the exception error messages.
>
>> the API of Vector3D should be similar to RealMatrix/BigMatrix and
>> follow the same implementation pattern
>>
> Good point, but I am OK with the inconsistency and I suspect Luc and
> migrating Mantissa users would rather keep this as is. Luc?
This API is quite consistent as is, the getNorm(), add()and subtract()
methods are similar to the methods with the same names in the linear
package. The multiply(double) method is similar to the
scalarMultiply(double) method and has a name inconsistency. The other
methods are specific to this class.
If you consider changing multiply() to scalarMultiply() would bring a
more consistent package, then go for it, it is the right to do this
before we release the class in [math] for the first time. This is a
small change with regard to the package changes mantissa users will have
to do. If you want more important changes like removing some methods
like add and subtract with factor and vector, or generalizing the class
to any dimension or replacing the getX()/getY()/getZ() by
getEntry(index), then I would strongly argue against it.
>
>> linear
>>
>> BigMatrixImpl minor javadoc fix (data vs. d parameter name)
>> RealMatrixImpl minor javadoc fix (data vs. d parameter name)
>>
> Patch welcome
>
>> ode
>>
>> AbstractStepInterpolator has several methods that are protected and
>> modify private state or that are public and not final
>>
> Comments on this, Luc?
The only private parts of the state are the finalized and forward
boolean fields. They are modified by the protected constructors and
reinitialize (which acts as a disguised constructor called as part of
the prototype design pattern used in Runge-Kutta and embedded
Runge-Kutta implementations). The finalized field is also modified by
the public finalizeStep method which is final. All of this is
intentional. The weirdest thing is the prototype design pattern and the
reinitialize method, but I didn't find a clean way to do what I wanted.
What do you suggest here and for which fields ?
>
>> optimization
>>
>> method name change, DirectSearchOptimizer.minimizes(... --> minimize(...
>>
> Personally +1 on this change, but again need to think about Mantissa users.
You are right, and it is also a small change for Mantissa users, go ahead.
>
>> random
>>
>> refactor the decomposition in CorrelatedRandomVectorGenerator to a
>> separate class in linear package
>
> +1 but this is a little work. Could wait for 2.0, though this amounts
> to release-with-intention-to-deprecate.
I agree this slightly modified Cholesky decomposition may be useful
elsewhere, taking care of clashes with regular Cholesky decomposition.
Here, we add permutations and a stop condition on small vectors to
handle rank-deficient matrices (i.e. matrices that are only
semi-definite positive, not definite positive).
This could wait for 2.0 as a new feature with more bells and whistles.
There is no need to deprecate anything as it is a private method
modifying a private field.
>
>> ValueServer replace static ints with typesafe enum, minor javadoc fixes
>> (periods at end of sentences, etc.);
>
> Patches welcome
>
> >candidate for its own package, with
>> interface and multiple implementations
>>
> Can do this in 2.0.
>
>> transform
>>
>> better documentation as to difference between transform and transform2
>> and between inversetransform and inversetransform2
>> method name change, inversetransform --> inverseTransform
>> method name change, inversetransform2 --> inverseTransform2
>
> +1 on these. Any objections, Luc?
No problem.
Luc
>> util
>>
>> DefaultTransformer, NumberTransformer, TransformerMap not related to the
>> transform package desipe their names, better to delegate to
>> commons-convert? (or possibly use a similar pattern, e.g.
>> DoubleToStringConversion)
>
> These should be deprecated.
>> For "later":
>>
>> Generify matrix API
>> Package interfaces and implementation classes separately
>>
> +1 for 2.0
>> I realize that some of these cannot happen in a 1.2 release because of
>> API compatibility. I can provide patches for the others if desired.
>>
>
> Thanks again for the review and feedback and thanks in advance for patches.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] 1.2-RC1 available for review
Posted by Phil Steitz <ph...@gmail.com>.
On Feb 12, 2008 7:25 PM, Michael Heuer <he...@acm.org> wrote:
>
> On Sun, 10 Feb 2008, Phil Steitz wrote:
>
> > The zips / tars are here:
> > http://people.apache.org/~psteitz/math-1.2-RC1/
> >
> > The site included in the binary distro is here:
> > http://people.apache.org/~psteitz/math-1.2-RC1/docs/
> >
> > Release notes:
> > http://people.apache.org/~psteitz/math-1.2-RC1/RELEASE-NOTES.txt
> >
> > Ant, Maven 1 and Maven 2 builds should all work from the unpacked
> > source distribution.
> > Comments / suggestions for improvement welcome!
> >
> > Phil
>
> A few comments for consideration:
Thanks, Michael!
>
> Null parameter checks are not consistent.
>
> Some classes throw NPE (PolynomialFunction, Complex, ComplexUtils,
> RealMatrixImpl, MatrixUtils, etc.)
>
> Some classes throw IAE (UnivariateRealSolverUtils,
> StorelessUnivariateStatistic, StatUtils, etc.)
>
> Many classes do neither (AbstractEstimator, GaussNewtonEstimator,
> LevenbergMarquardEstimator, Rotation, RotationOrder, BigMatrix,
> BigMatrixImpl, QRDecompositionImpl, RealMatrix, RealMatrixImpl,
> AbstractStepInterpolator, DirectSearchOptimizer,
> CorrelatedRandomVectorGenerator, EmpiricalDistribution,
> EmpiricalDistributionImpl, RandomData, RandomDataImpl,
> UncorrelatedRandomVectorGenerator, VectorialCovariance, VectorialMean,
> etc.)
>
> e.g. EmpiricalDistributionImpl.StreamDataAdapter ctr is especially
> problematic since NPE wouldn't be thrown until later, when either
> computeBinStats or computeStats was called
>
Patches welcome on the last one. The others need to be looked at and
discussed individually if we want to change behavior and API
documentation. Javadoc patches welcome.
> complex
>
> Complex and ComplexFormat could be final
>
Not a good idea at this time, IMO.
> estimation
>
> AbstractEstimator has several protected fields and public methods that
> are not final
Here again, -1 on making these final.
> SimpleEstimationProblem ArrayList unbound --> List unbound
> SimpleEstimationProblem fields private ArrayList --> private final List
Sounds reasonable. Any problems with these changes, Luc?
>
> fraction
>
> Fraction and FractionFormat could be final
-1 for 1.2 at least.
>
> geometry
>
> Rotation minor javadoc fix "if axis norm is null" vs if (norm == 0) { ... }
Patch welcome.
> the API of Vector3D should be similar to RealMatrix/BigMatrix and
> follow the same implementation pattern
>
Good point, but I am OK with the inconsistency and I suspect Luc and
migrating Mantissa users would rather keep this as is. Luc?
> linear
>
> BigMatrixImpl minor javadoc fix (data vs. d parameter name)
> RealMatrixImpl minor javadoc fix (data vs. d parameter name)
>
Patch welcome
> ode
>
> AbstractStepInterpolator has several methods that are protected and
> modify private state or that are public and not final
>
Comments on this, Luc?
> optimization
>
> method name change, DirectSearchOptimizer.minimizes(... --> minimize(...
>
Personally +1 on this change, but again need to think about Mantissa users.
> random
>
> refactor the decomposition in CorrelatedRandomVectorGenerator to a
> separate class in linear package
+1 but this is a little work. Could wait for 2.0, though this amounts
to release-with-intention-to-deprecate.
> ValueServer replace static ints with typesafe enum, minor javadoc fixes
> (periods at end of sentences, etc.);
Patches welcome
>candidate for its own package, with
> interface and multiple implementations
>
Can do this in 2.0.
> transform
>
> better documentation as to difference between transform and transform2
> and between inversetransform and inversetransform2
> method name change, inversetransform --> inverseTransform
> method name change, inversetransform2 --> inverseTransform2
+1 on these. Any objections, Luc?
>
> util
>
> DefaultTransformer, NumberTransformer, TransformerMap not related to the
> transform package desipe their names, better to delegate to
> commons-convert? (or possibly use a similar pattern, e.g.
> DoubleToStringConversion)
These should be deprecated.
>
> For "later":
>
> Generify matrix API
> Package interfaces and implementation classes separately
>
+1 for 2.0
>
> I realize that some of these cannot happen in a 1.2 release because of
> API compatibility. I can provide patches for the others if desired.
>
Thanks again for the review and feedback and thanks in advance for patches.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] 1.2-RC1 available for review
Posted by Michael Heuer <he...@acm.org>.
On Sun, 10 Feb 2008, Phil Steitz wrote:
> The zips / tars are here:
> http://people.apache.org/~psteitz/math-1.2-RC1/
>
> The site included in the binary distro is here:
> http://people.apache.org/~psteitz/math-1.2-RC1/docs/
>
> Release notes:
> http://people.apache.org/~psteitz/math-1.2-RC1/RELEASE-NOTES.txt
>
> Ant, Maven 1 and Maven 2 builds should all work from the unpacked
> source distribution.
> Comments / suggestions for improvement welcome!
>
> Phil
A few comments for consideration:
Null parameter checks are not consistent.
Some classes throw NPE (PolynomialFunction, Complex, ComplexUtils,
RealMatrixImpl, MatrixUtils, etc.)
Some classes throw IAE (UnivariateRealSolverUtils,
StorelessUnivariateStatistic, StatUtils, etc.)
Many classes do neither (AbstractEstimator, GaussNewtonEstimator,
LevenbergMarquardEstimator, Rotation, RotationOrder, BigMatrix,
BigMatrixImpl, QRDecompositionImpl, RealMatrix, RealMatrixImpl,
AbstractStepInterpolator, DirectSearchOptimizer,
CorrelatedRandomVectorGenerator, EmpiricalDistribution,
EmpiricalDistributionImpl, RandomData, RandomDataImpl,
UncorrelatedRandomVectorGenerator, VectorialCovariance, VectorialMean,
etc.)
e.g. EmpiricalDistributionImpl.StreamDataAdapter ctr is especially
problematic since NPE wouldn't be thrown until later, when either
computeBinStats or computeStats was called
complex
Complex and ComplexFormat could be final
estimation
AbstractEstimator has several protected fields and public methods that
are not final
SimpleEstimationProblem ArrayList unbound --> List unbound
SimpleEstimationProblem fields private ArrayList --> private final List
fraction
Fraction and FractionFormat could be final
geometry
Rotation minor javadoc fix "if axis norm is null" vs if (norm == 0) { ... }
the API of Vector3D should be similar to RealMatrix/BigMatrix and
follow the same implementation pattern
linear
BigMatrixImpl minor javadoc fix (data vs. d parameter name)
RealMatrixImpl minor javadoc fix (data vs. d parameter name)
ode
AbstractStepInterpolator has several methods that are protected and
modify private state or that are public and not final
optimization
method name change, DirectSearchOptimizer.minimizes(... --> minimize(...
random
refactor the decomposition in CorrelatedRandomVectorGenerator to a
separate class in linear package
ValueServer replace static ints with typesafe enum, minor javadoc fixes
(periods at end of sentences, etc.); candidate for its own package, with
interface and multiple implementations
transform
better documentation as to difference between transform and transform2
and between inversetransform and inversetransform2
method name change, inversetransform --> inverseTransform
method name change, inversetransform2 --> inverseTransform2
util
DefaultTransformer, NumberTransformer, TransformerMap not related to the
transform package desipe their names, better to delegate to
commons-convert? (or possibly use a similar pattern, e.g.
DoubleToStringConversion)
For "later":
Generify matrix API
Package interfaces and implementation classes separately
I realize that some of these cannot happen in a 1.2 release because of
API compatibility. I can provide patches for the others if desired.
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org