Re: [math] Frequency getUniqueCount

[Ted Dunning]

Or you can include the test case in the same patch.  That almost guarantees
you are far enough up the tree.

And using the same name is actually good.  Don't bother to delete the old
version, just upload with the same name.
JIRA will show old versions in greyed out style.

On Mon, Dec 6, 2010 at 7:51 PM, sebb  wrote:

> For example, it would be useful to have a test case that exercises the
> new method.
> This can be attached to the same JIRA (but with a different name, of
> course).
>

Re: [math] Frequency getUniqueCount

[sebb]

On 7 December 2010 03:10, Patrick Meyer  wrote:
> OK, I generated the patch file using Eclipse and it seems to have the
> information you described. I'm not sure if the revision part is correct
> though. The latest patch is named MATH-448.patch and it is now attached to
> the JIRA issue, https://issues.apache.org/jira/browse/MATH-448. I hope this
> latest file is what you need.

Almost there.

I see my previous mail was misleading.

I would expect most Commons developers to check out either a single
project, e.g.

https://svn.apache.org/repos/asf/commons/proper/math/trunk

in which case a patch relative to the project will start like:

Index: src/main/java/org/apache/commons/math/stat/Frequency.java
===
--- src/main/java/org/apache/commons/math/stat/Frequency.java   (revision 
1042422)
+++ src/main/java/org/apache/commons/math/stat/Frequency.java   (working copy)
etc.

This is easy to apply.
In Eclipse, select the project, then Team/Apply Patch.

With the patch as currently attached, which starts:

### Eclipse Workspace Patch 1.0
#P apache-math
Index: apache/commons/math/stat/Frequency.java
===
--- apache/commons/math/stat/Frequency.java (revision 1042596)
+++ apache/commons/math/stat/Frequency.java (working copy)
etc.

one first has to navigate to the directory "src/main/java/org" before
applying the patch.

Also, the patch has been done using the Eclipse Workspace as a Patch Root.
Unfortunately, this is not portable, as it depends on the exact names
given to the Eclipse projects.
For example, I use 'commons-math' - you have used "apache-math"

In future, please select Patch Root = Project in Eclipse.
[Unfortunately it does not seem possible to make this the default.]

However, no need to bother redoing this particular patch, but please
bear in mind for any other patches.

For example, it would be useful to have a test case that exercises the
new method.
This can be attached to the same JIRA (but with a different name, of course).

> Thanks,
> Patrick
>
>
>
>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Frequency getUniqueCount

[Ted Dunning]

Looks right to me.

Welcome to Apache contributorhood!

On Mon, Dec 6, 2010 at 7:10 PM, Patrick Meyer  wrote:

> OK, I generated the patch file using Eclipse and it seems to have the
> information you described. I'm not sure if the revision part is correct
> though. The latest patch is named MATH-448.patch and it is now attached to
> the JIRA issue, https://issues.apache.org/jira/browse/MATH-448. I hope
> this
> latest file is what you need.
>
> Thanks,
> Patrick
>
>
>
>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [math] Frequency getUniqueCount

[Patrick Meyer]

OK, I generated the patch file using Eclipse and it seems to have the
information you described. I'm not sure if the revision part is correct
though. The latest patch is named MATH-448.patch and it is now attached to
the JIRA issue, https://issues.apache.org/jira/browse/MATH-448. I hope this
latest file is what you need.

Thanks,
Patrick




> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [math] Storeless covariance

[Phil Steitz]

Patrick,

Thanks for contributing this.  Looks useful and IMO a good addition to
[math].  It would speed things up a bit if you added javadoc and a test
class.

Thanks again for your interest and contribution.

Phil

On Mon, Dec 6, 2010 at 9:14 AM, Patrick Meyer  wrote:

> There are now accurate algorithms for an incremental, storeless covariance
> that are extentions of West's algorithm for storeless variance. I submitted
> the algorithm and technical paper on its derivation in JIRA,
> https://issues.apache.org/jira/browse/MATH-449. It would be nice to have
> this added to org.apache.commons.math.covariance.
>
> Thanks,
> Patrick
>

Re: svn commit: r1042610 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/linear/RealVector.java

[sebb]

On 6 December 2010 22:21, Gilles Sadowski  wrote:
>> >> > -     * @deprecated in 2.2 (to be removed in 3.0). Please use
>> >> > -     * {...@link #map(UnivariateRealFunction)} directly with
>> >> > -     * the function classes in package
>> >> > -     * {...@link org.apache.commons.math.analysis.function}.
>> >> > +     * @deprecated in 2.2 (to be removed in 3.0).
>> >>
>> >> Why not leave the reference to #map(UnivariateRealFunction) ?
>> >
>> > Because the package "function" does not exist in MATH_2_X.
>>
>> I know that, but #map(UnivariateRealFunction) does exist (in the same
>> source file).
>>
>> It was only the reference to the package name that was wrong.
>>
>> If the replacement for the deprecated methods is not
>> #map(UnivariateRealFunction), then whatever is the replacement should
>> be specified in the Javadoc.
>
> The replacement is the method "map" (which exists) together with the
> appropriate function (which doesn't, unless someone wants to backport the
> "function" package).

There are several implementations of UnivariateRealFunction, e.g.
PolynomialFunctionLagrangeForm.

Are these not suitable as parameters to the map method?

> I think that we agreed with Phil that when the replacement doesn't exist, it
> is sufficient to warn the users with a terse deprecation message.

I don't think it is right to leave the user totally in the dark as to
how to resolve the deprecation warnings.

>
> Regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1042596 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math: analysis/solvers/ distribution/

[Phil Steitz]

On Mon, Dec 6, 2010 at 5:35 PM, Luc Maisonobe  wrote:

> Hi Gilles,
>
> Le 06/12/2010 23:27, Gilles Sadowski a écrit :
> > Hi.
> >
> >>> Log:
> >>> MATH-452
> >>> Made all static variables (accuracies) "private".
> >>
> >>
> >> We have already started a discussion on a similar point some months ago.
> >> Last message is here: ,
> >> but we did not really conclude.
> >>
> >> To summarize my point from a few months ago, one use case for these
> >> public values is that a use program can do something like this to first
> >> initialize a Graphical User Interface, then let the user change the
> >> values he wants, and later retrieve the actual values (which may be
> >> unchanged) to build the solver.
> >>
> >> // initialize GUI
> >>
> solverGui.setRelAccuracy(BaseAbstractUnivariateRealSolver.DEFAULT_RELATIVE_ACCURACY);
> >>
> solverGui.setAbsAccuracy(BaseAbstractUnivariateRealSolver.DEFAULT_ABSOLUTE_ACCURACY);
> >>
> >> // fire the GUI
> >> ...
> >>
> >> // in the action callback from the GUI OK button, create the solver
> >> double rel = solverGui.getRelAccuracy();
> >> double abs = solverGui.getAbsAccuracy();
> >> BrentSolver mySolver = new BrentSolver(rel, abs);
> >>
> >>
> >> Another simpler use case is simply to have the default value available
> >> in the Javadoc without being forced to get commons-math sources.
> >>
> >> So I still consider this kind of public constats are usefule. Despite
> >> the fact within commons-math they are used only in some constructors,
> >> the fact they are public allow them to be also used in user code.
> >
> > I think that we can satisfy this use-case without exposing the variables:
> >
> > ---CUT---
> >> BrentSolver mySolver = new BrentSolver();
> >>
> >> // initialize GUI
> >> solverGui.setRelAccuracy(mySolver.getRelativeAccuracy());
> >> solverGui.setAbsAccuracy(mySolver.getAbsoluteAccuracy());
> >>
> >> // fire the GUI
> >> ...
> >>
> >> // in the action callback from the GUI OK button, create the solver
> >> double rel = solverGui.getRelAccuracy();
> >> double abs = solverGui.getAbsAccuracy();
> >>
> >> mySolver = new BrentSolver(rel, abs);
> > ---CUT---
>
> Creating two solvers to use only one and simply hiding constants seems
> awkward to me. Just letting the constants visible is simpler.
>
> I think what Sebb pointed out in this issue was not that the constants
> were public, but that these constants were duplicated. I agree with him
> here. However solving the issue by removing the duplication and having
> constants defined in the top level interface is more straightforward.
>

+1.  One more thing that Gilles was careful to maintain, but gives more
reason to keep the constants public is that they are part of the
documentation - e.g.

- * Construct a solver with default accuracy.
+ * Construct a solver with default accuracy (1e-6).

Keeping the constants public eliminates the need to repeat this.

Phil

>
> best regards,
> Luc
>
> >
> >
> > Regards,
> > Gilles
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: svn commit: r1042596 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math: analysis/solvers/ distribution/

[Luc Maisonobe]

Hi Gilles,

Le 06/12/2010 23:27, Gilles Sadowski a écrit :
> Hi.
> 
>>> Log:
>>> MATH-452
>>> Made all static variables (accuracies) "private".
>>
>>
>> We have already started a discussion on a similar point some months ago.
>> Last message is here: ,
>> but we did not really conclude.
>>
>> To summarize my point from a few months ago, one use case for these
>> public values is that a use program can do something like this to first
>> initialize a Graphical User Interface, then let the user change the
>> values he wants, and later retrieve the actual values (which may be
>> unchanged) to build the solver.
>>
>> // initialize GUI
>> solverGui.setRelAccuracy(BaseAbstractUnivariateRealSolver.DEFAULT_RELATIVE_ACCURACY);
>> solverGui.setAbsAccuracy(BaseAbstractUnivariateRealSolver.DEFAULT_ABSOLUTE_ACCURACY);
>>
>> // fire the GUI
>> ...
>>
>> // in the action callback from the GUI OK button, create the solver
>> double rel = solverGui.getRelAccuracy();
>> double abs = solverGui.getAbsAccuracy();
>> BrentSolver mySolver = new BrentSolver(rel, abs);
>>
>>
>> Another simpler use case is simply to have the default value available
>> in the Javadoc without being forced to get commons-math sources.
>>
>> So I still consider this kind of public constats are usefule. Despite
>> the fact within commons-math they are used only in some constructors,
>> the fact they are public allow them to be also used in user code.
> 
> I think that we can satisfy this use-case without exposing the variables:
> 
> ---CUT---
>> BrentSolver mySolver = new BrentSolver();
>>
>> // initialize GUI
>> solverGui.setRelAccuracy(mySolver.getRelativeAccuracy());
>> solverGui.setAbsAccuracy(mySolver.getAbsoluteAccuracy());
>>
>> // fire the GUI
>> ...
>>
>> // in the action callback from the GUI OK button, create the solver
>> double rel = solverGui.getRelAccuracy();
>> double abs = solverGui.getAbsAccuracy();
>>
>> mySolver = new BrentSolver(rel, abs);
> ---CUT---

Creating two solvers to use only one and simply hiding constants seems
awkward to me. Just letting the constants visible is simpler.

I think what Sebb pointed out in this issue was not that the constants
were public, but that these constants were duplicated. I agree with him
here. However solving the issue by removing the duplication and having
constants defined in the top level interface is more straightforward.

best regards,
Luc

> 
> 
> Regards,
> Gilles
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1042596 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math: analysis/solvers/ distribution/

[Gilles Sadowski]

Hi.

> > Log:
> > MATH-452
> > Made all static variables (accuracies) "private".
> 
> 
> We have already started a discussion on a similar point some months ago.
> Last message is here: ,
> but we did not really conclude.
> 
> To summarize my point from a few months ago, one use case for these
> public values is that a use program can do something like this to first
> initialize a Graphical User Interface, then let the user change the
> values he wants, and later retrieve the actual values (which may be
> unchanged) to build the solver.
> 
> // initialize GUI
> solverGui.setRelAccuracy(BaseAbstractUnivariateRealSolver.DEFAULT_RELATIVE_ACCURACY);
> solverGui.setAbsAccuracy(BaseAbstractUnivariateRealSolver.DEFAULT_ABSOLUTE_ACCURACY);
> 
> // fire the GUI
> ...
> 
> // in the action callback from the GUI OK button, create the solver
> double rel = solverGui.getRelAccuracy();
> double abs = solverGui.getAbsAccuracy();
> BrentSolver mySolver = new BrentSolver(rel, abs);
> 
> 
> Another simpler use case is simply to have the default value available
> in the Javadoc without being forced to get commons-math sources.
> 
> So I still consider this kind of public constats are usefule. Despite
> the fact within commons-math they are used only in some constructors,
> the fact they are public allow them to be also used in user code.

I think that we can satisfy this use-case without exposing the variables:

---CUT---
> BrentSolver mySolver = new BrentSolver();
> 
> // initialize GUI
> solverGui.setRelAccuracy(mySolver.getRelativeAccuracy());
> solverGui.setAbsAccuracy(mySolver.getAbsoluteAccuracy());
> 
> // fire the GUI
> ...
> 
> // in the action callback from the GUI OK button, create the solver
> double rel = solverGui.getRelAccuracy();
> double abs = solverGui.getAbsAccuracy();
> 
> mySolver = new BrentSolver(rel, abs);
---CUT---


Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1042610 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/linear/RealVector.java

[Gilles Sadowski]

> >> > -     * @deprecated in 2.2 (to be removed in 3.0). Please use
> >> > -     * {...@link #map(UnivariateRealFunction)} directly with
> >> > -     * the function classes in package
> >> > -     * {...@link org.apache.commons.math.analysis.function}.
> >> > +     * @deprecated in 2.2 (to be removed in 3.0).
> >>
> >> Why not leave the reference to #map(UnivariateRealFunction) ?
> >
> > Because the package "function" does not exist in MATH_2_X.
> 
> I know that, but #map(UnivariateRealFunction) does exist (in the same
> source file).
> 
> It was only the reference to the package name that was wrong.
> 
> If the replacement for the deprecated methods is not
> #map(UnivariateRealFunction), then whatever is the replacement should
> be specified in the Javadoc.

The replacement is the method "map" (which exists) together with the
appropriate function (which doesn't, unless someone wants to backport the
"function" package).

I think that we agreed with Phil that when the replacement doesn't exist, it
is sufficient to warn the users with a terse deprecation message.


Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1042596 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math: analysis/solvers/ distribution/

[Luc Maisonobe]

Hi,

Le 06/12/2010 12:56, er...@apache.org a écrit :
> Author: erans
> Date: Mon Dec  6 11:56:26 2010
> New Revision: 1042596
> 
> URL: http://svn.apache.org/viewvc?rev=1042596&view=rev
> Log:
> MATH-452
> Made all static variables (accuracies) "private".


We have already started a discussion on a similar point some months ago.
Last message is here: ,
but we did not really conclude.

To summarize my point from a few months ago, one use case for these
public values is that a use program can do something like this to first
initialize a Graphical User Interface, then let the user change the
values he wants, and later retrieve the actual values (which may be
unchanged) to build the solver.

// initialize GUI
solverGui.setRelAccuracy(BaseAbstractUnivariateRealSolver.DEFAULT_RELATIVE_ACCURACY);
solverGui.setAbsAccuracy(BaseAbstractUnivariateRealSolver.DEFAULT_ABSOLUTE_ACCURACY);

// fire the GUI
...

// in the action callback from the GUI OK button, create the solver
double rel = solverGui.getRelAccuracy();
double abs = solverGui.getAbsAccuracy();
BrentSolver mySolver = new BrentSolver(rel, abs);


Another simpler use case is simply to have the default value available
in the Javadoc without being forced to get commons-math sources.

So I still consider this kind of public constats are usefule. Despite
the fact within commons-math they are used only in some constructors,
the fact they are public allow them to be also used in user code.

Luc

> 
> Modified:
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BaseAbstractUnivariateRealSolver.java
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BisectionSolver.java
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BrentSolver.java
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/LaguerreSolver.java
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/MullerSolver.java
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/MullerSolver2.java
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/NewtonSolver.java
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/RiddersSolver.java
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/SecantSolver.java
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/AbstractContinuousDistribution.java
> 
> Modified: 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BaseAbstractUnivariateRealSolver.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BaseAbstractUnivariateRealSolver.java?rev=1042596&r1=1042595&r2=1042596&view=diff
> ==
> --- 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BaseAbstractUnivariateRealSolver.java
>  (original)
> +++ 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BaseAbstractUnivariateRealSolver.java
>  Mon Dec  6 11:56:26 2010
> @@ -34,12 +34,10 @@ import org.apache.commons.math.analysis.
>   */
>  public abstract class BaseAbstractUnivariateRealSolver UnivariateRealFunction>
>  implements BaseUnivariateRealSolver {
> -/** Default absolute accuracy */
> -public static final double DEFAULT_ABSOLUTE_ACCURACY = 1e-6;
>  /** Default relative accuracy. */
> -public static final double DEFAULT_RELATIVE_ACCURACY = 1e-14;
> +private static final double DEFAULT_RELATIVE_ACCURACY = 1e-14;
>  /** Default function value accuracy. */
> -public static final double DEFAULT_FUNCTION_VALUE_ACCURACY = 1e-15;
> +private static final double DEFAULT_FUNCTION_VALUE_ACCURACY = 1e-15;
>  /** Function value accuracy. */
>  private final double functionValueAccuracy;
>  /** Absolute accuracy. */
> 
> Modified: 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BisectionSolver.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BisectionSolver.java?rev=1042596&r1=1042595&r2=1042596&view=diff
> ==
> --- 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BisectionSolver.java
>  (original)
> +++ 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BisectionSolver.java
>  Mon Dec  6 11:56:26 2010
> @@ -28,10 +28,10 @@ import org.apache.commons.math.util.Fast
>   */
>  public class BisectionSolver extends AbstractUnivariateRealSolver {
>  /** Default absolute accuracy. */
> 

Re: svn commit: r1042610 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/linear/RealVector.java

[sebb]

On 6 December 2010 17:17, Gilles Sadowski  wrote:
>> > @@ -250,10 +250,7 @@ public interface RealVector {
>> >      *
>> >      * @param d Operator value.
>> >      * @return a mapped copy of the vector.
>> > -     * @deprecated in 2.2 (to be removed in 3.0). Please use
>> > -     * {...@link #map(UnivariateRealFunction)} directly with
>> > -     * the function classes in package
>> > -     * {...@link org.apache.commons.math.analysis.function}.
>> > +     * @deprecated in 2.2 (to be removed in 3.0).
>>
>> Why not leave the reference to #map(UnivariateRealFunction) ?
>
> Because the package "function" does not exist in MATH_2_X.

I know that, but #map(UnivariateRealFunction) does exist (in the same
source file).

It was only the reference to the package name that was wrong.

If the replacement for the deprecated methods is not
#map(UnivariateRealFunction), then whatever is the replacement should
be specified in the Javadoc.

>> [...]
>
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Frequency getUniqueCount

[sebb]

On 6 December 2010 17:06, Ted Dunning  wrote:
> Looks right.  I think that the base of the patch is one level too low.

The base level of patches should ideally be the top-level of an SVN
checkout, in this case commons-math/trunk, or possibly two levels
higher.
[Some people may check out multiple Commons projects at once.]

It's easy enough to drop extra path segments, but the current patch
has no path whatsoever (except in the comments).
This which makes it harder to apply.

Also there could be several files called Frequency.java.

It's also useful to include the SVN revision in the patch (rather than
BASE). If the patch is not applied for a while, it can be important to
know what revision it was created for.

Dunno how to do that in NetBeans; it happens automatically in Eclipse
when creating patches from an SVN workspace.

> It is also a nice convention to name the patch after the JIRA.  Thus your
> patch would be called MATH-448.patch
>
> It is also a nice convention to just upload on top of the previous version.
>  This leaves JIRA with a development
> history which is pretty interesting to take a look.

Possibly not relevant here though, when the content of the patch is
the same - just the wrapping is different.

> On Mon, Dec 6, 2010 at 9:03 AM, Patrick Meyer  wrote:
>
>> I originally used Netbeans to generate the Diff, then copy and pasted it
>> into Wordpad to save it. I just uploaded a new patch that was created with
>> the Netbeans "Export Diff Patch" function. Is this new file in the correct
>> format? (Please excuse the noob - I'll get the process right eventually.)
>>
>>
>>
>> On Mon, Dec 6, 2010 at 11:55 AM, Ted Dunning 
>> wrote:
>>
>> > How did you create this diff?
>> >
>> > The normal way is to use svn diff in the project root directory.
>> >
>> > On Mon, Dec 6, 2010 at 8:29 AM, Patrick Meyer 
>> wrote:
>> >
>> > > OK, I attached a diff file to,
>> > > https://issues.apache.org/jira/browse/MATH-448.
>> > > However, I am new to subversion and JIRA and I'm not sure I have done
>> > this
>> > > correctly. Please let me know if I have done something wrong. I am
>> happy
>> > to
>> > > volunteer and contribute to the project. I just want to make sure I am
>> > > using
>> > > he right process to submit changes.
>> > >
>> > > Thanks,
>> > > Patrick
>> > >
>> > >
>> > >
>> > > On Mon, Dec 6, 2010 at 10:46 AM, Ted Dunning 
>> > > wrote:
>> > >
>> > > > If you provide a suggested patch, this will go forward much more
>> > quickly
>> > > > than
>> > > > if you wait for a volunteer to appear out of the mists.
>> > > >
>> > > > It is after all a volunteer effort.  Go ahead and volunteer!
>> > > >
>> > > > On Mon, Dec 6, 2010 at 6:07 AM, Patrick Meyer 
>> > > wrote:
>> > > >
>> > > > > I have a small feature request for the org.apache.commons.math.stat
>> > > > > Frequency class. It is often useful to know the unique number of
>> > > elements
>> > > > > in
>> > > > > a frequency table. Would you add this feature? I submitted an issue
>> > > with
>> > > > > JIRA with the code needed to make this happen,
>> > > > > https://issues.apache.org/jira/browse/MATH-448.
>> > > > >
>> > > > > Thanks
>> > > > >
>> > > >
>> > >
>> >
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1042610 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/linear/RealVector.java

[Gilles Sadowski]

> > @@ -250,10 +250,7 @@ public interface RealVector {
> >      *
> >      * @param d Operator value.
> >      * @return a mapped copy of the vector.
> > -     * @deprecated in 2.2 (to be removed in 3.0). Please use
> > -     * {...@link #map(UnivariateRealFunction)} directly with
> > -     * the function classes in package
> > -     * {...@link org.apache.commons.math.analysis.function}.
> > +     * @deprecated in 2.2 (to be removed in 3.0).
> 
> Why not leave the reference to #map(UnivariateRealFunction) ?

Because the package "function" does not exist in MATH_2_X.

> [...]

Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Frequency getUniqueCount

[Ted Dunning]

Looks right.  I think that the base of the patch is one level too low.

It is also a nice convention to name the patch after the JIRA.  Thus your
patch would be called MATH-448.patch

It is also a nice convention to just upload on top of the previous version.
 This leaves JIRA with a development
history which is pretty interesting to take a look.

On Mon, Dec 6, 2010 at 9:03 AM, Patrick Meyer  wrote:

> I originally used Netbeans to generate the Diff, then copy and pasted it
> into Wordpad to save it. I just uploaded a new patch that was created with
> the Netbeans "Export Diff Patch" function. Is this new file in the correct
> format? (Please excuse the noob - I'll get the process right eventually.)
>
>
>
> On Mon, Dec 6, 2010 at 11:55 AM, Ted Dunning 
> wrote:
>
> > How did you create this diff?
> >
> > The normal way is to use svn diff in the project root directory.
> >
> > On Mon, Dec 6, 2010 at 8:29 AM, Patrick Meyer 
> wrote:
> >
> > > OK, I attached a diff file to,
> > > https://issues.apache.org/jira/browse/MATH-448.
> > > However, I am new to subversion and JIRA and I'm not sure I have done
> > this
> > > correctly. Please let me know if I have done something wrong. I am
> happy
> > to
> > > volunteer and contribute to the project. I just want to make sure I am
> > > using
> > > he right process to submit changes.
> > >
> > > Thanks,
> > > Patrick
> > >
> > >
> > >
> > > On Mon, Dec 6, 2010 at 10:46 AM, Ted Dunning 
> > > wrote:
> > >
> > > > If you provide a suggested patch, this will go forward much more
> > quickly
> > > > than
> > > > if you wait for a volunteer to appear out of the mists.
> > > >
> > > > It is after all a volunteer effort.  Go ahead and volunteer!
> > > >
> > > > On Mon, Dec 6, 2010 at 6:07 AM, Patrick Meyer 
> > > wrote:
> > > >
> > > > > I have a small feature request for the org.apache.commons.math.stat
> > > > > Frequency class. It is often useful to know the unique number of
> > > elements
> > > > > in
> > > > > a frequency table. Would you add this feature? I submitted an issue
> > > with
> > > > > JIRA with the code needed to make this happen,
> > > > > https://issues.apache.org/jira/browse/MATH-448.
> > > > >
> > > > > Thanks
> > > > >
> > > >
> > >
> >
>

Re: [math] Frequency getUniqueCount

[Patrick Meyer]

I originally used Netbeans to generate the Diff, then copy and pasted it
into Wordpad to save it. I just uploaded a new patch that was created with
the Netbeans "Export Diff Patch" function. Is this new file in the correct
format? (Please excuse the noob - I'll get the process right eventually.)



On Mon, Dec 6, 2010 at 11:55 AM, Ted Dunning  wrote:

> How did you create this diff?
>
> The normal way is to use svn diff in the project root directory.
>
> On Mon, Dec 6, 2010 at 8:29 AM, Patrick Meyer  wrote:
>
> > OK, I attached a diff file to,
> > https://issues.apache.org/jira/browse/MATH-448.
> > However, I am new to subversion and JIRA and I'm not sure I have done
> this
> > correctly. Please let me know if I have done something wrong. I am happy
> to
> > volunteer and contribute to the project. I just want to make sure I am
> > using
> > he right process to submit changes.
> >
> > Thanks,
> > Patrick
> >
> >
> >
> > On Mon, Dec 6, 2010 at 10:46 AM, Ted Dunning 
> > wrote:
> >
> > > If you provide a suggested patch, this will go forward much more
> quickly
> > > than
> > > if you wait for a volunteer to appear out of the mists.
> > >
> > > It is after all a volunteer effort.  Go ahead and volunteer!
> > >
> > > On Mon, Dec 6, 2010 at 6:07 AM, Patrick Meyer 
> > wrote:
> > >
> > > > I have a small feature request for the org.apache.commons.math.stat
> > > > Frequency class. It is often useful to know the unique number of
> > elements
> > > > in
> > > > a frequency table. Would you add this feature? I submitted an issue
> > with
> > > > JIRA with the code needed to make this happen,
> > > > https://issues.apache.org/jira/browse/MATH-448.
> > > >
> > > > Thanks
> > > >
> > >
> >
>

Re: [math] Frequency getUniqueCount

[Ted Dunning]

How did you create this diff?

The normal way is to use svn diff in the project root directory.

On Mon, Dec 6, 2010 at 8:29 AM, Patrick Meyer  wrote:

> OK, I attached a diff file to,
> https://issues.apache.org/jira/browse/MATH-448.
> However, I am new to subversion and JIRA and I'm not sure I have done this
> correctly. Please let me know if I have done something wrong. I am happy to
> volunteer and contribute to the project. I just want to make sure I am
> using
> he right process to submit changes.
>
> Thanks,
> Patrick
>
>
>
> On Mon, Dec 6, 2010 at 10:46 AM, Ted Dunning 
> wrote:
>
> > If you provide a suggested patch, this will go forward much more quickly
> > than
> > if you wait for a volunteer to appear out of the mists.
> >
> > It is after all a volunteer effort.  Go ahead and volunteer!
> >
> > On Mon, Dec 6, 2010 at 6:07 AM, Patrick Meyer 
> wrote:
> >
> > > I have a small feature request for the org.apache.commons.math.stat
> > > Frequency class. It is often useful to know the unique number of
> elements
> > > in
> > > a frequency table. Would you add this feature? I submitted an issue
> with
> > > JIRA with the code needed to make this happen,
> > > https://issues.apache.org/jira/browse/MATH-448.
> > >
> > > Thanks
> > >
> >
>

Re: [math] Frequency getUniqueCount

[Patrick Meyer]

OK, I attached a diff file to,https://issues.apache.org/jira/browse/MATH-448.
However, I am new to subversion and JIRA and I'm not sure I have done this
correctly. Please let me know if I have done something wrong. I am happy to
volunteer and contribute to the project. I just want to make sure I am using
he right process to submit changes.

Thanks,
Patrick



On Mon, Dec 6, 2010 at 10:46 AM, Ted Dunning  wrote:

> If you provide a suggested patch, this will go forward much more quickly
> than
> if you wait for a volunteer to appear out of the mists.
>
> It is after all a volunteer effort.  Go ahead and volunteer!
>
> On Mon, Dec 6, 2010 at 6:07 AM, Patrick Meyer  wrote:
>
> > I have a small feature request for the org.apache.commons.math.stat
> > Frequency class. It is often useful to know the unique number of elements
> > in
> > a frequency table. Would you add this feature? I submitted an issue with
> > JIRA with the code needed to make this happen,
> > https://issues.apache.org/jira/browse/MATH-448.
> >
> > Thanks
> >
>

Re: [VOTE] Release Commons VFS 2.0

[Ralph Goers]

On Dec 6, 2010, at 7:07 AM, Gary Gregory wrote:

> Hi Ralph:
> 
> While the src distro ran the Maven test goal OK for me on Vista + Java 6, I 
> see that no tests ran (0% success rate) according to 
> http://people.apache.org/~rgoers/commons-vfs/surefire-report.html
> 
> How can that be?
> 
> 

VFS is a multi-module project. The parent project has no unit tests. You would 
want to look at 
http://people.apache.org/~rgoers/commons-vfs/commons-vfs2/surefire-report.html.

Ralph


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons VFS 2.0

[Gary Gregory]

On Dec 6, 2010, at 10:49, "sebb"  wrote:

> On 6 December 2010 02:04, Ralph Goers  wrote:
>> This is a vote to release Apache Commons VFS 2.0.
>> 
>> Since the last candidate the package name was changed from vfs to vfs2. Many 
>> of the Jira issues were reviewed and those that required a possibly 
>> incompatible API change were addressed. Most instances of StringBuffer were 
>> replaced with StringBuilder. Some synchronization issues were addressed. 
>> Many javadoc and some checkstyle issues were addressed. The filesystem 
>> documentation was improved to list file system capabilities.
>> 
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [X] -1 no, do not release it because...
>> 
>> Ralph
>> 
>> tag: 
>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>>   (revision 1042381).
>> 
>> site: http://people.apache.org/~rgoers/commons-vfs/index.html
> 
> Does not mention that the new release uses a new package name and
> requires source updates to use.
> Ditto the Maven changes.
> 
> changes.xml has not been updated with a description of the release.
> Also, the date will need to be changed at some point.
> 
> I still think we should have tried to maintain binary compatibility -
> which I think would have been possible.
> However, assuming that the compatibility break is what the majority
> wants, this needs to be made very obvious, and there should be upgrade
> notes describing how to perform the change.
> 
> IMO there should be some RELEASE_NOTES in the source and binary archives.

+1  I've come to expect release notes in bin releases.

Gary

> 
> The source archive should probably exclude the DOAP.
> 
>> 
>> The following artifacts have been staged to the Apache Nexus Staging 
>> repository org.apache.commons-051 (u:rgoers, a:75.82.178.177) 
>> https://repository.apache.org/content/repositories/orgapachecommons-051/
>> 
>> commons-vfs2-examples-2.0-sources.jar
>> commons-vfs2-examples-2.0.jar.asc
>> commons-vfs2-examples-2.0.pom
>> commons-vfs2-examples-2.0-javadoc.jar.asc
>> commons-vfs2-examples-2.0.jar
>> commons-vfs2-examples-2.0-javadoc.jar
>> commons-vfs2-examples-2.0.pom.asc
>> commons-vfs2-examples-2.0-sources.jar.asc
>> commons-vfs2-project-2.0-site.xml
>> commons-vfs2-project-2.0.pom.asc
>> commons-vfs2-project-2.0.pom
>> commons-vfs2-project-2.0-site.xml.asc
>> commons-vfs2-2.0-sources.jar.asc
>> commons-vfs2-2.0-tests.jar.asc
>> commons-vfs2-2.0-javadoc.jar
>> commons-vfs2-2.0.jar.asc
>> commons-vfs2-2.0-test-sources.jar.asc
>> commons-vfs2-2.0-javadoc.jar.asc
>> commons-vfs2-2.0-test-sources.jar
>> commons-vfs2-2.0.pom.asc
>> commons-vfs2-2.0.jar
>> commons-vfs2-2.0.pom
>> commons-vfs2-2.0-sources.jar
>> commons-vfs2-2.0-tests.jar
>> commons-vfs2-sandbox-2.0.pom.asc
>> commons-vfs2-sandbox-2.0-javadoc.jar
>> commons-vfs2-sandbox-2.0-tests.jar
>> commons-vfs2-sandbox-2.0.jar.asc
>> commons-vfs2-sandbox-2.0-sources.jar
>> commons-vfs2-sandbox-2.0-sources.jar.asc
>> commons-vfs2-sandbox-2.0-tests.jar.asc
>> commons-vfs2-sandbox-2.0.pom
>> commons-vfs2-sandbox-2.0.jar
>> commons-vfs2-sandbox-2.0-test-sources.jar.asc
>> commons-vfs2-sandbox-2.0-test-sources.jar
>> commons-vfs2-sandbox-2.0-javadoc.jar.asc
>> commons-vfs2-distribution-2.0-bin.tar.gz.asc
>> commons-vfs2-distribution-2.0-src.tar.gz
>> commons-vfs2-distribution-2.0-src.zip
>> commons-vfs2-distribution-2.0-src.zip.asc
>> commons-vfs2-distribution-2.0.pom.asc
>> commons-vfs2-distribution-2.0.pom
>> commons-vfs2-distribution-2.0-bin.zip
>> commons-vfs2-distribution-2.0-src.tar.gz.asc
>> commons-vfs2-distribution-2.0-bin.tar.gz
>> commons-vfs2-distribution-2.0-bin.zip.asc
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons VFS 2.0

[sebb]

On 6 December 2010 02:04, Ralph Goers  wrote:
> This is a vote to release Apache Commons VFS 2.0.
>
> Since the last candidate the package name was changed from vfs to vfs2. Many 
> of the Jira issues were reviewed and those that required a possibly 
> incompatible API change were addressed. Most instances of StringBuffer were 
> replaced with StringBuilder. Some synchronization issues were addressed. Many 
> javadoc and some checkstyle issues were addressed. The filesystem 
> documentation was improved to list file system capabilities.
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [X] -1 no, do not release it because...
>
> Ralph
>
> tag: 
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
>   (revision 1042381).
>
> site: http://people.apache.org/~rgoers/commons-vfs/index.html

Does not mention that the new release uses a new package name and
requires source updates to use.
Ditto the Maven changes.

changes.xml has not been updated with a description of the release.
Also, the date will need to be changed at some point.

I still think we should have tried to maintain binary compatibility -
which I think would have been possible.
However, assuming that the compatibility break is what the majority
wants, this needs to be made very obvious, and there should be upgrade
notes describing how to perform the change.

IMO there should be some RELEASE_NOTES in the source and binary archives.

The source archive should probably exclude the DOAP.

>
> The following artifacts have been staged to the Apache Nexus Staging 
> repository org.apache.commons-051 (u:rgoers, a:75.82.178.177) 
> https://repository.apache.org/content/repositories/orgapachecommons-051/
>
> commons-vfs2-examples-2.0-sources.jar
> commons-vfs2-examples-2.0.jar.asc
> commons-vfs2-examples-2.0.pom
> commons-vfs2-examples-2.0-javadoc.jar.asc
> commons-vfs2-examples-2.0.jar
> commons-vfs2-examples-2.0-javadoc.jar
> commons-vfs2-examples-2.0.pom.asc
> commons-vfs2-examples-2.0-sources.jar.asc
> commons-vfs2-project-2.0-site.xml
> commons-vfs2-project-2.0.pom.asc
> commons-vfs2-project-2.0.pom
> commons-vfs2-project-2.0-site.xml.asc
> commons-vfs2-2.0-sources.jar.asc
> commons-vfs2-2.0-tests.jar.asc
> commons-vfs2-2.0-javadoc.jar
> commons-vfs2-2.0.jar.asc
> commons-vfs2-2.0-test-sources.jar.asc
> commons-vfs2-2.0-javadoc.jar.asc
> commons-vfs2-2.0-test-sources.jar
> commons-vfs2-2.0.pom.asc
> commons-vfs2-2.0.jar
> commons-vfs2-2.0.pom
> commons-vfs2-2.0-sources.jar
> commons-vfs2-2.0-tests.jar
> commons-vfs2-sandbox-2.0.pom.asc
> commons-vfs2-sandbox-2.0-javadoc.jar
> commons-vfs2-sandbox-2.0-tests.jar
> commons-vfs2-sandbox-2.0.jar.asc
> commons-vfs2-sandbox-2.0-sources.jar
> commons-vfs2-sandbox-2.0-sources.jar.asc
> commons-vfs2-sandbox-2.0-tests.jar.asc
> commons-vfs2-sandbox-2.0.pom
> commons-vfs2-sandbox-2.0.jar
> commons-vfs2-sandbox-2.0-test-sources.jar.asc
> commons-vfs2-sandbox-2.0-test-sources.jar
> commons-vfs2-sandbox-2.0-javadoc.jar.asc
> commons-vfs2-distribution-2.0-bin.tar.gz.asc
> commons-vfs2-distribution-2.0-src.tar.gz
> commons-vfs2-distribution-2.0-src.zip
> commons-vfs2-distribution-2.0-src.zip.asc
> commons-vfs2-distribution-2.0.pom.asc
> commons-vfs2-distribution-2.0.pom
> commons-vfs2-distribution-2.0-bin.zip
> commons-vfs2-distribution-2.0-src.tar.gz.asc
> commons-vfs2-distribution-2.0-bin.tar.gz
> commons-vfs2-distribution-2.0-bin.zip.asc

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Frequency getUniqueCount

[Ted Dunning]

If you provide a suggested patch, this will go forward much more quickly
than
if you wait for a volunteer to appear out of the mists.

It is after all a volunteer effort.  Go ahead and volunteer!

On Mon, Dec 6, 2010 at 6:07 AM, Patrick Meyer  wrote:

> I have a small feature request for the org.apache.commons.math.stat
> Frequency class. It is often useful to know the unique number of elements
> in
> a frequency table. Would you add this feature? I submitted an issue with
> JIRA with the code needed to make this happen,
> https://issues.apache.org/jira/browse/MATH-448.
>
> Thanks
>

RE: [VOTE] Release Commons VFS 2.0

[Gary Gregory]

Hi Ralph:

While the src distro ran the Maven test goal OK for me on Vista + Java 6, I see 
that no tests ran (0% success rate) according to 
http://people.apache.org/~rgoers/commons-vfs/surefire-report.html

How can that be?

Gary Gregory
Senior Software Engineer
Rocket Software
3340 Peachtree Road, Suite 820 . Atlanta, GA 30326 . USA
Tel: +1.404.760.1560
Email: ggreg...@seagullsoftware.com
Web: seagull.rocketsoftware.com  



> -Original Message-
> From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> Sent: Sunday, December 05, 2010 21:05
> To: Commons Developers List
> Subject: [VOTE] Release Commons VFS 2.0
> 
> This is a vote to release Apache Commons VFS 2.0.
> 
> Since the last candidate the package name was changed from vfs to vfs2. Many
> of the Jira issues were reviewed and those that required a possibly
> incompatible API change were addressed. Most instances of StringBuffer were
> replaced with StringBuilder. Some synchronization issues were addressed. Many
> javadoc and some checkstyle issues were addressed. The filesystem
> documentation was improved to list file system capabilities.
> 
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because...
> 
> Ralph
> 
> tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-
> project-2.0/  (revision 1042381).
> 
> site: http://people.apache.org/~rgoers/commons-vfs/index.html
> 
> The following artifacts have been staged to the Apache Nexus Staging
> repository org.apache.commons-051 (u:rgoers, a:75.82.178.177)
> https://repository.apache.org/content/repositories/orgapachecommons-051/
> 
> commons-vfs2-examples-2.0-sources.jar
> commons-vfs2-examples-2.0.jar.asc
> commons-vfs2-examples-2.0.pom
> commons-vfs2-examples-2.0-javadoc.jar.asc
> commons-vfs2-examples-2.0.jar
> commons-vfs2-examples-2.0-javadoc.jar
> commons-vfs2-examples-2.0.pom.asc
> commons-vfs2-examples-2.0-sources.jar.asc
> commons-vfs2-project-2.0-site.xml
> commons-vfs2-project-2.0.pom.asc
> commons-vfs2-project-2.0.pom
> commons-vfs2-project-2.0-site.xml.asc
> commons-vfs2-2.0-sources.jar.asc
> commons-vfs2-2.0-tests.jar.asc
> commons-vfs2-2.0-javadoc.jar
> commons-vfs2-2.0.jar.asc
> commons-vfs2-2.0-test-sources.jar.asc
> commons-vfs2-2.0-javadoc.jar.asc
> commons-vfs2-2.0-test-sources.jar
> commons-vfs2-2.0.pom.asc
> commons-vfs2-2.0.jar
> commons-vfs2-2.0.pom
> commons-vfs2-2.0-sources.jar
> commons-vfs2-2.0-tests.jar
> commons-vfs2-sandbox-2.0.pom.asc
> commons-vfs2-sandbox-2.0-javadoc.jar
> commons-vfs2-sandbox-2.0-tests.jar
> commons-vfs2-sandbox-2.0.jar.asc
> commons-vfs2-sandbox-2.0-sources.jar
> commons-vfs2-sandbox-2.0-sources.jar.asc
> commons-vfs2-sandbox-2.0-tests.jar.asc
> commons-vfs2-sandbox-2.0.pom
> commons-vfs2-sandbox-2.0.jar
> commons-vfs2-sandbox-2.0-test-sources.jar.asc
> commons-vfs2-sandbox-2.0-test-sources.jar
> commons-vfs2-sandbox-2.0-javadoc.jar.asc
> commons-vfs2-distribution-2.0-bin.tar.gz.asc
> commons-vfs2-distribution-2.0-src.tar.gz
> commons-vfs2-distribution-2.0-src.zip
> commons-vfs2-distribution-2.0-src.zip.asc
> commons-vfs2-distribution-2.0.pom.asc
> commons-vfs2-distribution-2.0.pom
> commons-vfs2-distribution-2.0-bin.zip
> commons-vfs2-distribution-2.0-src.tar.gz.asc
> commons-vfs2-distribution-2.0-bin.tar.gz
> commons-vfs2-distribution-2.0-bin.zip.asc

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1042610 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/linear/RealVector.java

[sebb]

On 6 December 2010 12:52,   wrote:
> Author: erans
> Date: Mon Dec  6 12:52:36 2010
> New Revision: 1042610
>
> URL: http://svn.apache.org/viewvc?rev=1042610&view=rev
> Log:
> MATH-453
> Removed Javadoc comment referring to non-existent package.
>
> Modified:
>    
> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/linear/RealVector.java
>
> Modified: 
> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/linear/RealVector.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/linear/RealVector.java?rev=1042610&r1=1042609&r2=1042610&view=diff
> ==
> --- 
> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/linear/RealVector.java
>  (original)
> +++ 
> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/linear/RealVector.java
>  Mon Dec  6 12:52:36 2010
> @@ -250,10 +250,7 @@ public interface RealVector {
>      *
>      * @param d Operator value.
>      * @return a mapped copy of the vector.
> -     * @deprecated in 2.2 (to be removed in 3.0). Please use
> -     * {...@link #map(UnivariateRealFunction)} directly with
> -     * the function classes in package
> -     * {...@link org.apache.commons.math.analysis.function}.
> +     * @deprecated in 2.2 (to be removed in 3.0).

Why not leave the reference to #map(UnivariateRealFunction) ?

If something is deprecated, ISTM that the the Javadoc should say what
to use instead.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[math] Storeless covariance

[Patrick Meyer]

There are now accurate algorithms for an incremental, storeless covariance
that are extentions of West's algorithm for storeless variance. I submitted
the algorithm and technical paper on its derivation in JIRA,
https://issues.apache.org/jira/browse/MATH-449. It would be nice to have
this added to org.apache.commons.math.covariance.

Thanks,
Patrick

[math] Frequency getUniqueCount

[Patrick Meyer]

I have a small feature request for the org.apache.commons.math.stat
Frequency class. It is often useful to know the unique number of elements in
a frequency table. Would you add this feature? I submitted an issue with
JIRA with the code needed to make this happen,
https://issues.apache.org/jira/browse/MATH-448.

Thanks