[math] derivatives UnivarateRealFunction (diff'able)
About 4 weeks ago there was discussion w/ adding a derivative method to an extension of the o.a.c.m.analysis.UnivariateRealFunction interface. I apologize for the time delay but I had previously contributed some code that made it to the expiremental branch in the project for FunctionOperators.see: http://cvs.apache.org/viewcvs.cgi/jakarta-commons/math/src/experimental/org/apache/commons/math/analysis/ anyway at the time I just wanted to re-focus the group on this concept as it relates to Derivates. There is a DerivativeOperatorFactory which creates a function D, such that D(f) = f' numerically. The reason I did this was to build a framework to add do numerical initial-value problems. A lot of these methods use as a base Taylor series approximations, and hence there is a need for higher order derivative evaluations. long and short, I thought that the DerivativeOperator approach would be a nice start to this without having to program a Function and it's derivative(s). Any thoughts? -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
my 2cents (1) I think it would be best to get a 1.0 release of commons-math as a jakarta-commons subproject before any movement (the good-old KISS acronym comes to mind) (2) I am not sure to what extent math may get developed, as was stated in a different thread previously Java is not the best platform for Numerical Analysis. That being said, I dont forsee commons-math as a serious Numerical Anaylsis lib, rather a convenient and useful tool to explore 'simple' problems. This could be significant in research, in my opinion you dont really need to 'crank' up the system in most cases, and have a handy library that can get some nice results quickly in a Java setting is very valueable. There are plenty of high-scale number crunchers, and most of the best performing ones will always be in F77 due to its static nature. It may very well be that some of the value out of the math project is as an SPI to these backend 'crunchers' which provides a nice Java interface to interact with the rest of the world. (leading me back to the beginning of this rambling...) (3) I am thoroughly confused as to the pros-cons of what moving this the apache-commons level would do. I like the idea of a 100% java framework at this point (leading me back to point #1). In summary, I think it should stay where it is for now. -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Numerical Derivative pattern q.
I have been scratching out an implementation of a numerical derivative to
add to the commons-math and keep going back and forth between two
approaches.
(all this would be in the o.a.c.math.analysis package)
(for brevity I have omitted the prefix UnivariateReal* )
(1) a couple classes like Differentiator (interface) and
DifferentiatorFactory (class), where we have a method like
Differentiator DifferentiatorFactory.getDefaultDifferentiator(
Function f )
and another method like double Differentiator.derivate( double x)
or double Differentiator.value(double x)
this keeps the same type of pattern as that of the *Solver
OR
(2) Add a class like DerivativeFactory which has a method like
Function DerivativeFactory.getDefaultDerivative( Function f )
and use the existing double Function.value( double x) to obtain the
numerical estimate.
I first implemented it using approach (1) but as the code and usage
turned out, it seems that (2) was easier to use (and numerically has the
same number or operations and function evaluations).
--
using (2) the client code would look like
public myMethod() {
UnivariateRealFunction f = new SomeUserDefinedFunction();
UnivariateRealFunction fprime =
DerivativeFactory.newInstance().getDefaultDerivative( f );
System.out.println( f'(1.0) = + fprime.value(1.0) );
}
-
of course the Factory could allow for multiple types of Derivatives, the
one I have currently implemented is a centered 5-point algorithm, which
has an operational parameter of h (or a step-size), there may also be
parameters to handle infinite derivative or jumps.
--
Matt Cliff
Cliff Consulting
The label said install Windows 98 or better so I installed Linux.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[math] implementation of Polynomial Function
Attached are two new files that implement a Polynomial as a
UnivariateRealFunction and should be added to the
org.apache.commons.math.analysis packages in both java and test
respectively.
I do not have commit privileges and would appreciate on the the math
contributors or members to add these.
also, I have added a patch that will remove the firstDerivative and
secondDerivative methods from the UnivariateRealFunction interface (and
appropriate unit test). This item was still pending consensus. I plan to
write a couple classes such as UnivariateRealDifferentiator that will give
numeric approximates using point evaluation to achieve this. I also plan
to contribute UnivariateRealIntegrator pattern.
--
Matt Cliff
Cliff Consulting
303.757.4912
720.280.6324 (c)
The label said install Windows 98 or better so I installed Linux.
Index: src/java/org/apache/commons/math/analysis/CubicSplineFunction.java
===
RCS file:
/home/cvspublic/jakarta-commons/math/src/java/org/apache/commons/math/analysis/CubicSplineFunction.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 CubicSplineFunction.java
--- src/java/org/apache/commons/math/analysis/CubicSplineFunction.java 1 Nov 2003
16:04:12 - 1.1.1.1
+++ src/java/org/apache/commons/math/analysis/CubicSplineFunction.java 7 Nov 2003
23:15:43 -
@@ -122,7 +122,6 @@
* @param x the point for which the first derivative should be computed
* @return the value
* @throws MathException if the derivative couldn't be computed.
- * @see UnivariateRealFunction#firstDerivative(double)
*/
public double firstDerivative(double x) throws MathException {
if (x xval[0] || x xval[xval.length - 1]) {
@@ -145,7 +144,6 @@
* @param x the point for which the first derivative should be computed
* @return the value
* @throws MathException if the second derivative couldn't be computed.
- * @see UnivariateRealFunction#secondDerivative(double)
*/
public double secondDerivative(double x) throws MathException {
if (x xval[0] || x xval[xval.length - 1]) {
Index: src/java/org/apache/commons/math/analysis/UnivariateRealFunction.java
===
RCS file:
/home/cvspublic/jakarta-commons/math/src/java/org/apache/commons/math/analysis/UnivariateRealFunction.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 UnivariateRealFunction.java
--- src/java/org/apache/commons/math/analysis/UnivariateRealFunction.java 1 Nov
2003 16:04:12 - 1.1.1.1
+++ src/java/org/apache/commons/math/analysis/UnivariateRealFunction.java 7 Nov
2003 23:15:43 -
@@ -74,27 +74,4 @@
*/
public double value(double x) throws MathException;
-/**
- * Compute the value for the first derivative of the function.
- * It is recommended to provide this method only if the first derivative is
- * analytical. Numerical derivatives may be acceptable in some cases.
- * An implementation should throw an UnsupportedOperationException if
- * this method is not implemented.
- * @param x the point for which the first derivative should be computed
- * @return the value
- * @throws MathException if the derivative couldn't be computed.
- */
-public double firstDerivative(double x) throws MathException;
-
-/**
- * Compute the value for the second derivative of the function.
- * It is recommended to provide this method only if the second derivative is
- * analytical. Numerical derivatives may be acceptable in some cases.
- * An implementation should throw an UnsupportedOperationException if
- * this method is not implemented.
- * @param x the point for which the first derivative should be computed
- * @return the value
- * @throws MathException if the second derivative couldn't be computed.
- */
-public double secondDerivative(double x) throws MathException;
}
Index: src/test/org/apache/commons/math/analysis/InterpolatorTest.java
===
RCS file:
/home/cvspublic/jakarta-commons/math/src/test/org/apache/commons/math/analysis/InterpolatorTest.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 InterpolatorTest.java
--- src/test/org/apache/commons/math/analysis/InterpolatorTest.java 1 Nov 2003
16:04:12 - 1.1.1.1
+++ src/test/org/apache/commons/math/analysis/InterpolatorTest.java 7 Nov 2003
23:15:43 -
@@ -89,31 +89,21 @@
x=
+ x
+ y=
-+ f.value(x)
-+ y'=
-+ f.firstDerivative(x)
-+ y''=
-+ f.secondDerivative(x));
++ f.value(x));
+
x = 0.5;
System.out.println(
x=
+ x
+ y
Re: [Math] common-math and bloated 3rd party libraries
On Wed, 5 Nov 2003, Mark R. Diggory wrote: Hmm, not to be critical, but 5.1 is almost at the end of its product lifecycle. Weblogic has had several releases since 5.1 that solve many of these issues do they not? I say this mostly to identify that there is a limitation as to how far back in terms of versioning we, as a new tool, should consider supporting. I would have attempted to deal with an issue like this with BEA, not neccessarily with the java community at large because they create too many jars (I'm saying this lightly). Not to nip a subject in the butt. But this has moved way off the issue associated with how dependent the different commons projects (and specifically related to math dependencies). I hope we can draw it back into this subject. -Mark I agree with minimizing the number of dependent Jar's. I also agree with statements made earlier in this thread related to supporting older JDKs (if JDK1.2 works for your app why should use of this component force you to change?) Regarding the logging; It has been suggested that the logging dependency be isolated to the test classes only on not required for the runtime lib. This makes sense to me, with the caveat that we must have a robust exception hierarchy so that logging can be plugged in at a higher level. Regarding the Discovery, I see only two instances where the DiscoveryClass is used (UnivariateRealSolverFactory, and DistributionFactory), both of which use only the newInstance(Class,String) method. Off hand I dont see the advantage of using the DiscoveryClass here, my impression is the find() methods are the 'meat' of the DiscoveryClass. commons-collections, this seems only prudent to keep, as I can only imagine that the linear algebraic routines will become more complicated, and collections lends itself naturally to mathematical constructs. this leaves commons-lang, and commons-beanutils None of these are used very extensively, however I can see how these are useful. commons-lang is used only in the MathException class, as a trade off for removing logging I think that the NestableException becomes necessary. commons-beanutils is used by the *Transformer classes (seems good to me). -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] interface for UnivariateRealFunction (differentiability)
What is the purpose for having the firstDerivative() and secondDerivative() methods on a UnivariateRealFunction ? It is a little troubling to me to have at this level (perhaps if needed a subclass such as UnivariateDifferentiableRealFunction ). Most numerical processes only require a function analysis, also when doing anything 'challenging' the differentiablity can get complicated, if not impossible. -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] interface for UnivariateRealFunction (differentiability)
I suggest that we remove the derivative methods from the interface. My thought is that in general, a user would not need to calculate and program the first and second derivatives. I'd like to put a little more thought into the Differentiable interface, there are two tracks of thought here: (1) dealing with truly differentiable functions (e.g. polynomials) which can easily have the derivative methods exposed, and (2) applying the appropriate numerical diff. logic at the appropriate place. That is maybe something analagous to the UnivariateRealSolver pattern that an numerical routine such as a three-point or five-point forumla for the derivatives. wrt the term Univariate I am impartial. I would lean towards leaving it as is for now. Once Multivariate functions are introduced this can be addressed (my preference is to get a 1.0 release out in a single variable). On Fri, 7 Nov 2003, Mark R. Diggory wrote: Not attached to this, a Differentiable Interface would be acceptable to me too. On another subject, maybe because of my naivety, why are these interfaces called UnivariateRealFunction and not simply something more generic like RealFunction? I say this strictly because of what I consider an overuse of the term Univariate in many of our Classnames... -Mark [EMAIL PROTECTED] wrote: The CubicSplineFunction is the only place, that I'm aware of, that truly implements these methods. Also, these method are never called anywhere in the code, save the unit tests. This includes calls through either the interface or the concrete classes. As I see it we have three choices: 1) let it as is 2) add a differentiable interface per Mike's suggestion. 3) remove the derivative methods from the interface and keep them only on CubicSplineFunction. In order of preference, I choose 2, 1, 3. On Fri, 07 Nov 2003 15:02:46 -0500, Mark R. Diggory wrote: [EMAIL PROTECTED] wrote: What is the purpose for having the firstDerivative() and secondDerivative() methods on a UnivariateRealFunction ? One of the interpolating routines use the first and second derivatives. It is a little troubling to me to have at this level (perhaps if needed a subclass such as UnivariateDifferentiableRealFunction ). This might be a good idea. When I used the solvers to evaluate the inverse cumulative distribution functions, I found the UnivariateRealFunction interface a bit cumbersome for my needs. Some methods do not neccessarily need to be exposed via an interface if they are used internally. While some UnivariateRealFunction implementations may require this capability, is it required to be in the interface? -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Brent Worden http://www.brent.worden.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Proposal for Package restructuring and Class renaming
I agree On Fri, 7 Nov 2003, Mark R. Diggory wrote: I have several modifications I'm planning to make, but in the spirit of consensus I want to propose them and attempt to get some agreement. So math developer opinions on the subject would be good. 1.) o.a.c.math.stat.distributions -- o.a.c.math.distributions Gives this package a more generic position to hold more than just stat distributions. 2.) Like in my last emails concerning Univariate I would like to, (and have done so in my checkout successfully) Make the following Class changes: interface o.a.c.m.stat.StoreUnivariate -- abstract class o.a.c.m.stat.DescriptiveStatistics this actually becomes a factory class and uses Discovery to instantiate new instances of the following implementations *default implementation* o.a.c.m.stat.StoreUnivariateImpl -- o.a.c.m.stat.univariate.StatisticsImpl *alternate implementations* o.a.c.m.stat.UnivariateImpl -- o.a.c.m.stat.univariate.StorelessStatisticsImpl o.a.c.m.stat.ListUnivariateImpl -- o.a.c.m.stat.univariate.ListStatisticsImpl o.a.c.m.stat.BeanListUnivariateImpl -- o.a.c.m.stat.univariate.BeanListStatisticsImpl The benefit of this is that the Alternate Implementations can all be instantiated from the o.a.c.m.stat.DescriptiveStatistics factories newInstance(...) methods. Thus alternate implementations of DescriptiveStatistics can be written as Service Providers and set in the environment/JVM configuration. We can now write SP's for other tools like Matlab, Mathematica, JLink, C++ libraries, R, Omegahat ... the list goes on and on... Someday, I'd like to see this design extended for Bivariate Statistics and Regression Classes. Eventually for Random Number generation as well. -Mark -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party librarie
Mark: What is your plan for the BeanTransformer.transform() method regarding logging/exception throwing? (in particular as to how the current junit test is executing) On Thu, 6 Nov 2003, Mark R. Diggory wrote: Brent, I've been experimenting with some refactoring that removes 100% of our dependencies on bean-utils, The first usage was BeanTransformer, the second usage was in DefaultTransformer. I rewrote DefaultTransformer to not need bean-utils with only a few extra lines of code, I expect it is also a bit more efficient because of the removal of extra method calls to been-utils. I'm attempting to do this with BeanTransformer (but its a bit more challenging as its using some bean introspection instead of just attempting to turn the object into a double). Logging is only in a few places outside of this, I think I can remove this runtime dependency. So in my book I think we reasonably accomplish trimming down the runtime dependencies to the following commons-discovery commons-collections commons-lang And trim the compile time dependencies down to commons-discovery commons-collections commons-lang commons-logging Does this sound at all reasonable? -Mark [EMAIL PROTECTED] wrote: commons-logging: A little more investigation revels, commons-beanutils depends on commons-logging. Hence, the only way to remove commons-math's dependency on commons-logging, is to remove commons-math's dependency on commons-beanutils. So, as long as commons-math is dependent on commons-beanutils, nothing is gained, in terms of bloat, by removing the commons-logging dependency. My stance is to use commons-logging. commons-discovery: Since I added the discovery stuff I will be its advocate. One of the visions for commons-math is to create a kind of service provider API for math routines and break commons-math into two logical parts: the SPI and the default implementation. Then, commons-math would either invite other service providers (Mathematica, MatLab, S-Plus, ...) to create adaptors or we would develop them. The route we have chosen to enable the SPI is via the abstract factories. To instantiate concrete factory instances, I decided to use the features provided by commons-discovery. Prior to its injection, the concrete factories used system properties for instantiation. This is limiting in the sense only one service provider can be used per JVM and in a app server type deployment, there may be a need to have utilize many different service provides for different applications. With commons-discovery, the system property approach is still supported along with properties files and the Jar SPI specification. The later two would enable the possibility of have multiple service providers under one JVM. Thus, using commons-disovery nothing is lost over the original implementation and some nice flexibility is gained. My stance is to use commons-discovery. commons-collections: commons-lang: commons-beanutils: No one seems to be objecting to these much so won't bother defending our reasons for using them. Here's a thought. One thing we might do to limit the proliferation of jars is to create a jar containing commons-math as all of its dependencies. Maven has an uberjar plugin that might be the ticket to creating such a jar. There ares risk with deploying such a jar as there might be version conflicts if other versions of the dependencies are deployed separately. I'm not a big advocate of this strategy (I've had to many struggles working with products that came bundled with old version of xerces) but it might be to quell some of the dependency backlash. Brent Worden http://www.brent.worden.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Math] Commons Math Contributions
- Original Message - From: Matt Cliff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 7:08 AM Subject: Commons Math Contributions I recently download the math commons subproject and would like to help out. This is my first open source contribution effort and am looking forward to extending to other projects. I have a background in Mathematics (MS and thesis work in Stochastic Analysis) and for the past several years worked as a project lead for a Java Company. Basically, (1) What is the best way to contribute? (submit patches to this mailing list or through the bug tracking system?) Also, will the bug tracking a new Math component to the Commons project? (2) What should I be working on? (what do we need to do to get it to a 1.0 release?) I would be more comfortable doing some 'maintenance' type work intially, downstream I can offer more substantitve math (I had done a bunch of work with DASSL and DASPK and their applications to Stochastic differential equations). (3) Will there be a link on the http://jakarta.apache.org/commons/index.html page to the Math Compont page? (4) I added a quick type-o patch for the tasks.xml doc to see if it is the proper format. (this is a cvs diff output) looking forward to helping out. -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. Index: xdocs/tasks.xml === RCS file: /home/cvspublic/jakarta-commons/math/xdocs/tasks.xml,v retrieving revision 1.2 diff -u -r1.2 tasks.xml --- xdocs/tasks.xml 1 Nov 2003 16:35:03 - 1.2 +++ xdocs/tasks.xml 5 Nov 2003 14:59:26 - @@ -21,7 +21,7 @@ ddClover tests show gaps in test path coverage. Get all tests to 100% coverage. Also improve test data and boundary conditions coverage./dd dtCode review./dt dd -pCode review is a continuous rpocess that all Contributors and Developers should practice while working on the code base./p +pCode review is a continuous process that all Contributors and Developers should practice while working on the code base./p ul liJavadoc generation is still throwing warnings. Bring the Javadoc into compliance (i.e. reach zero warnings)./li liVerify that the code matches the documentation and identify obvious inefficiencies or numerical problems. All feedback/suggestions for improvement/patches are welcome./li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons Math Contributions
I recently download the math commons subproject and would like to help out. This is my first open source contribution effort and am looking forward to extending to other projects. I have a background in Mathematics (MS and thesis work in Stochastic Analysis) and for the past several years worked as a project lead for a Java Company. Basically, (1) What is the best way to contribute? (submit patches to this mailing list or through the bug tracking system?) Also, will the bug tracking a new Math component to the Commons project? (2) What should I be working on? (what do we need to do to get it to a 1.0 release?) I would be more comfortable doing some 'maintenance' type work intially, downstream I can offer more substantitve math (I had done a bunch of work with DASSL and DASPK and their applications to Stochastic differential equations). (3) Will there be a link on the http://jakarta.apache.org/commons/index.html page to the Math Compont page? (4) I added a quick type-o patch for the tasks.xml doc to see if it is the proper format. (this is a cvs diff output) looking forward to helping out. -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. Index: xdocs/tasks.xml === RCS file: /home/cvspublic/jakarta-commons/math/xdocs/tasks.xml,v retrieving revision 1.2 diff -u -r1.2 tasks.xml --- xdocs/tasks.xml 1 Nov 2003 16:35:03 - 1.2 +++ xdocs/tasks.xml 5 Nov 2003 14:59:26 - @@ -21,7 +21,7 @@ ddClover tests show gaps in test path coverage. Get all tests to 100% coverage. Also improve test data and boundary conditions coverage./dd dtCode review./dt dd -pCode review is a continuous rpocess that all Contributors and Developers should practice while working on the code base./p +pCode review is a continuous process that all Contributors and Developers should practice while working on the code base./p ul liJavadoc generation is still throwing warnings. Bring the Javadoc into compliance (i.e. reach zero warnings)./li liVerify that the code matches the documentation and identify obvious inefficiencies or numerical problems. All feedback/suggestions for improvement/patches are welcome./li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Math] Commons Math Contributions
I recently download the math commons subproject and would like to help out. This is my first open source contribution effort and am looking forward to extending to other projects. I have a background in Mathematics (MS and thesis work in Stochastic Analysis) and for the past several years worked as a project lead for a Java Company. Basically, (1) What is the best way to contribute? (submit patches to this mailing list or through the bug tracking system?) Also, will the bug tracking a new Math component to the Commons project? (2) What should I be working on? (what do we need to do to get it to a 1.0 release?) I would be more comfortable doing some 'maintenance' type work intially, downstream I can offer more substantitve math (I had done a bunch of work with DASSL and DASPK and their applications to Stochastic differential equations). (3) Will there be a link on the http://jakarta.apache.org/commons/index.html page to the Math Compont page? (4) I added a quick type-o patch for the tasks.xml doc to see if it is the proper format. (this is a cvs diff output) looking forward to helping out. -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. Index: xdocs/tasks.xml === RCS file: /home/cvspublic/jakarta-commons/math/xdocs/tasks.xml,v retrieving revision 1.2 diff -u -r1.2 tasks.xml --- xdocs/tasks.xml 1 Nov 2003 16:35:03 - 1.2 +++ xdocs/tasks.xml 5 Nov 2003 14:59:26 - @@ -21,7 +21,7 @@ ddClover tests show gaps in test path coverage. Get all tests to 100% coverage. Also improve test data and boundary conditions coverage./dd dtCode review./dt dd -pCode review is a continuous rpocess that all Contributors and Developers should practice while working on the code base./p +pCode review is a continuous process that all Contributors and Developers should practice while working on the code base./p ul liJavadoc generation is still throwing warnings. Bring the Javadoc into compliance (i.e. reach zero warnings)./li liVerify that the code matches the documentation and identify obvious inefficiencies or numerical problems. All feedback/suggestions for improvement/patches are welcome./li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
