[jira] [Commented] (CONFIGURATION-451) commons-beanutils in two different version in dependency tree

2011-06-15 Thread Oliver Heger (JIRA)

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050233#comment-13050233
 ] 

Oliver Heger commented on CONFIGURATION-451:


So what do you suggest to solve the problem?

> commons-beanutils in two different version in dependency tree
> -
>
> Key: CONFIGURATION-451
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-451
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.6
>Reporter: Daniel Bimschas
>Priority: Minor
>  Labels: build, maven
>
> The Maven dependency tree (mvn dependency:tree) delivers:
> {quote}
> [INFO] | \- commons-configuration:commons-configuration:jar:1.6:compile
> [INFO] |+- commons-collections:commons-collections:jar:3.2.1:compile
> [INFO] |+- commons-logging:commons-logging:jar:1.1.1:compile
> [INFO] |+- commons-digester:commons-digester:jar:1.8:compile
> [INFO] ||  \- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] |\- commons-beanutils:commons-beanutils-core:jar:1.8.0:compile
> {quote}
> There is two times the commons-beanutils package with two different versions 
> which can potentially cause problems during runtime as it is not clear which 
> version is first in the classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (COMPRESS-133) Mention Debian/Ubuntu packages in AR format documentation

2011-06-15 Thread Bear Giles (JIRA)
Mention Debian/Ubuntu packages in AR format documentation
-

 Key: COMPRESS-133
 URL: https://issues.apache.org/jira/browse/COMPRESS-133
 Project: Commons Compress
  Issue Type: Improvement
  Components: Archivers
Reporter: Bear Giles
Priority: Trivial


The documentation for the AR format can/should mention that it is the basis for 
Debian/Ubuntu packages. A .deb file is actually an AR file with three elements:

_debian-binary_: version number ("2.0")

_data.tar.gz_: compressed tarball containing the package's files

_control.tar.gz_: compressed tarball containing the package's metadata 
(information, installation and removal scripts, etc.)

People will normally want to use the Debian package management tools but it's 
nice to know that we can access the 'original' content if necessary.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (COMPRESS-132) Add support for unix dump files

2011-06-15 Thread Bear Giles (JIRA)
Add support for unix dump files
---

 Key: COMPRESS-132
 URL: https://issues.apache.org/jira/browse/COMPRESS-132
 Project: Commons Compress
  Issue Type: Improvement
  Components: Archivers
Reporter: Bear Giles
Priority: Minor


I'm submitting a series of patches to the ext2/3/4 dump utility and noticed 
that the commons-compress library doesn't have an archiver for it. It's as old 
as tar and fills a similar niche but the later has become much more widely 
used. Dump includes support for sparse files, extended attributes, mac os 
finder, SELinux labels (I think), and more. Incremental  dumps can capture that 
files have been deleted.

I should have initial support for a decoder this weekend. I can read the 
directory entries and inode information (file permissions, etc.) but need a bit 
more work on extracting the content as an InputStream.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (LANG-684) Levenshtein Distance Within a Given Threshold

2011-06-15 Thread Gary D. Gregory (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050074#comment-13050074
 ] 

Gary D. Gregory commented on LANG-684:
--

I'm OK with that.

> Levenshtein Distance Within a Given Threshold
> -
>
> Key: LANG-684
> URL: https://issues.apache.org/jira/browse/LANG-684
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Reporter: Eli Lindsey
>Priority: Minor
> Fix For: 3.0
>
> Attachments: LevenshteinDistanceWithThreshold.patch
>
>
> It'd be nice to have a function that calculates the Levenshtein distance only 
> if it's within some integer threshold.  
> Oftentimes you care less about the actual LD and more about it being within a 
> certain range.  This common, limited computation can be performed much faster 
> than the normal unbounded LD method; instead of O(nm), you can do it in O(km) 
> (n and m are string lengths, k is the threshold).
> Also, providing a function like this makes it easier for library users to 
> rewrite the unbounded Levenshtein function to run in O(dm) time (d is the 
> edit distance) if necessary.
> I'm attaching a patch that implements this function and adds appropriate test 
> cases.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (LANG-684) Levenshtein Distance Within a Given Threshold

2011-06-15 Thread Matt Benson (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050063#comment-13050063
 ] 

Matt Benson commented on LANG-684:
--

I am no expert, and I see how LD might be used in proximity to soundex codecs, 
but at the end of the day I agree with Hen that it's not exactly a fit.  We 
should just add this improvement to [lang] and have done with it.

> Levenshtein Distance Within a Given Threshold
> -
>
> Key: LANG-684
> URL: https://issues.apache.org/jira/browse/LANG-684
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Reporter: Eli Lindsey
>Priority: Minor
> Fix For: 3.0
>
> Attachments: LevenshteinDistanceWithThreshold.patch
>
>
> It'd be nice to have a function that calculates the Levenshtein distance only 
> if it's within some integer threshold.  
> Oftentimes you care less about the actual LD and more about it being within a 
> certain range.  This common, limited computation can be performed much faster 
> than the normal unbounded LD method; instead of O(nm), you can do it in O(km) 
> (n and m are string lengths, k is the threshold).
> Also, providing a function like this makes it easier for library users to 
> rewrite the unbounded Levenshtein function to run in O(dm) time (d is the 
> edit distance) if necessary.
> I'm attaching a patch that implements this function and adds appropriate test 
> cases.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (CONFIGURATION-451) commons-beanutils in two different version in dependency tree

2011-06-15 Thread Joerg Schaible (JIRA)

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050035#comment-13050035
 ] 

Joerg Schaible commented on CONFIGURATION-451:
--

You overlooked that two different artifacts are in use: commons-beanutils and 
commons-beanutils-core. And if commons-beanutils-core is first in classpath the 
rest of the classes are loaded from commons-beanutils. I can imagine that at 
some point problems may arise.

> commons-beanutils in two different version in dependency tree
> -
>
> Key: CONFIGURATION-451
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-451
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.6
>Reporter: Daniel Bimschas
>Priority: Minor
>  Labels: build, maven
>
> The Maven dependency tree (mvn dependency:tree) delivers:
> {quote}
> [INFO] | \- commons-configuration:commons-configuration:jar:1.6:compile
> [INFO] |+- commons-collections:commons-collections:jar:3.2.1:compile
> [INFO] |+- commons-logging:commons-logging:jar:1.1.1:compile
> [INFO] |+- commons-digester:commons-digester:jar:1.8:compile
> [INFO] ||  \- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] |\- commons-beanutils:commons-beanutils-core:jar:1.8.0:compile
> {quote}
> There is two times the commons-beanutils package with two different versions 
> which can potentially cause problems during runtime as it is not clear which 
> version is first in the classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (MATH-449) Storeless covariance

2011-06-15 Thread Patrick Meyer (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050013#comment-13050013
 ] 

Patrick Meyer commented on MATH-449:


I agree. A new class would be best. Now that I am more familiar with commons 
math, my code should be changed to use double primitive types instead of Double 
objects. That use seems more consistent with other descriptive statistics in 
math.

> Storeless covariance
> 
>
> Key: MATH-449
> URL: https://issues.apache.org/jira/browse/MATH-449
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Patrick Meyer
> Fix For: 3.0
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Currently there is no storeless version for computing the covariance. 
> However, Pebay (2008) describes algorithms for on-line covariance 
> computations, [http://infoserve.sandia.gov/sand_doc/2008/086212.pdf]. I have 
> provided a simple class for implementing this algorithm. It would be nice to 
> have this integrated into org.apache.commons.math.stat.correlation.Covariance.
> {code}
> //This code is granted for inclusion in the Apache Commons under the terms of 
> the ASL.
> public class StorelessCovariance{
> private double deltaX = 0.0;
> private double deltaY = 0.0;
> private double meanX = 0.0;
> private double meanY = 0.0;
> private double N=0;
> private Double covarianceNumerator=0.0;
> private boolean unbiased=true;
> public Covariance(boolean unbiased){
>   this.unbiased = unbiased;
> }
> public void increment(Double x, Double y){
> if(x!=null & y!=null){
> N++;
> deltaX = x - meanX;
> deltaY = y - meanY;
> meanX += deltaX/N;
> meanY += deltaY/N;
> covarianceNumerator += ((N-1.0)/N)*deltaX*deltaY;
> }
> 
> }
> public Double getResult(){
> if(unbiased){
> return covarianceNumerator/(N-1.0);
> }else{
> return covarianceNumerator/N;
> }
> }   
> }
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (MATH-592) Convenience Methods for Retrieving the Start and End Points of a SubLine

2011-06-15 Thread Luc Maisonobe (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049993#comment-13049993
 ] 

Luc Maisonobe commented on MATH-592:


I was considering the Segment class too. However, this class is really a 
speciliazed one for internal purposes in PolygonsSet (there is an horrible hack 
with OrderedTuple).

I guess I may simplify this class to hold only the start and end point, make it 
public (it is package protected) and use it in the new API, and add an internal 
OrderedSegment (and OrderedSegmentBuilder) inside PolygonsSet.

I'll resolve this issue when this will be ready. Please be aware that due to 
this change, you will have to slightly adapt your code.

> Convenience Methods for Retrieving the Start and End Points of a SubLine
> 
>
> Key: MATH-592
> URL: https://issues.apache.org/jira/browse/MATH-592
> Project: Commons Math
>  Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Curtis Jensen
>Priority: Minor
>  Labels: Geometry, math
> Fix For: 3.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> For convenience, it would be helpful to have methods in the SubLine class to 
> retrieve the start and end points of the SubLine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (CONFIGURATION-451) commons-beanutils in two different version in dependency tree

2011-06-15 Thread Oliver Heger (JIRA)

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049979#comment-13049979
 ] 

Oliver Heger commented on CONFIGURATION-451:


Not sure whether I understand your point. There is no need to have both 
versions of commons-beanutils in the classpath. The transitive dependency to 
version 1.7.0 is overridden by the one specified in the pom. So the maven 
classpath ends up with only version 1.8 included. Just do a {{mvn 
dependency:copy-dependencies}}. This command puts all dependencies currently 
used in a directory. There is only the newest version of beanutils contained.

In your project you also should have *only* version 1.8 of beanutils in the 
classpath. Commons Configuration is compatible with it. You can use all new 
features of this version in your project.

> commons-beanutils in two different version in dependency tree
> -
>
> Key: CONFIGURATION-451
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-451
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.6
>Reporter: Daniel Bimschas
>Priority: Minor
>  Labels: build, maven
>
> The Maven dependency tree (mvn dependency:tree) delivers:
> {quote}
> [INFO] | \- commons-configuration:commons-configuration:jar:1.6:compile
> [INFO] |+- commons-collections:commons-collections:jar:3.2.1:compile
> [INFO] |+- commons-logging:commons-logging:jar:1.1.1:compile
> [INFO] |+- commons-digester:commons-digester:jar:1.8:compile
> [INFO] ||  \- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] |\- commons-beanutils:commons-beanutils-core:jar:1.8.0:compile
> {quote}
> There is two times the commons-beanutils package with two different versions 
> which can potentially cause problems during runtime as it is not clear which 
> version is first in the classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (MATH-592) Convenience Methods for Retrieving the Start and End Points of a SubLine

2011-06-15 Thread Curtis Jensen (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049976#comment-13049976
 ] 

Curtis Jensen commented on MATH-592:


Works great for me.  Thanks for the new constructor too.

I'm not sure if it makes sense or not, but there is the 
org.apache.commons.math.geometry.euclidean.twod.Segment class that could be 
used instead of a two point array.  I'm happy the way it is, just offering the 
Segment class in response to previous comment.

> Convenience Methods for Retrieving the Start and End Points of a SubLine
> 
>
> Key: MATH-592
> URL: https://issues.apache.org/jira/browse/MATH-592
> Project: Commons Math
>  Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Curtis Jensen
>Priority: Minor
>  Labels: Geometry, math
> Fix For: 3.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> For convenience, it would be helpful to have methods in the SubLine class to 
> retrieve the start and end points of the SubLine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (MATH-592) Convenience Methods for Retrieving the Start and End Points of a SubLine

2011-06-15 Thread Luc Maisonobe (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049969#comment-13049969
 ] 

Luc Maisonobe commented on MATH-592:


Fixed in subversion as of r1136154.
A constructor using two endpoints has also been added.
Could you check if the API suits your needs ? The new method is called 
getSegments and returns a list of Vector2D arrays. Each element of the list 
correspond to one segment of the subline, and is contains exactly two points: a 
start point at index 0 and an endpoint at index 1. Perhaps a dedicated class 
with a getStart() and getEnd() methods would be better than a two points array.
Provisions have been taken for half-infinite or full lines (first and last 
points will have infinite coordinates with the right sign).

> Convenience Methods for Retrieving the Start and End Points of a SubLine
> 
>
> Key: MATH-592
> URL: https://issues.apache.org/jira/browse/MATH-592
> Project: Commons Math
>  Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Curtis Jensen
>Priority: Minor
>  Labels: Geometry, math
> Fix For: 3.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> For convenience, it would be helpful to have methods in the SubLine class to 
> retrieve the start and end points of the SubLine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (MATH-449) Storeless covariance

2011-06-15 Thread Phil Steitz (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049956#comment-13049956
 ] 

Phil Steitz commented on MATH-449:
--

I am leaning toward just adding a new class called StorelessCovariance and 
similar for StorelessPearsonsCorrelation that just provide bivariate 
statistics.  You will notice that in fact the PersoansCorrelation class 
delegates to SimpleRegression which does the bivariate computation 
"storelessly" already.

Thanks for adding the comment and for the contribution!

> Storeless covariance
> 
>
> Key: MATH-449
> URL: https://issues.apache.org/jira/browse/MATH-449
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Patrick Meyer
> Fix For: 3.0
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Currently there is no storeless version for computing the covariance. 
> However, Pebay (2008) describes algorithms for on-line covariance 
> computations, [http://infoserve.sandia.gov/sand_doc/2008/086212.pdf]. I have 
> provided a simple class for implementing this algorithm. It would be nice to 
> have this integrated into org.apache.commons.math.stat.correlation.Covariance.
> {code}
> //This code is granted for inclusion in the Apache Commons under the terms of 
> the ASL.
> public class StorelessCovariance{
> private double deltaX = 0.0;
> private double deltaY = 0.0;
> private double meanX = 0.0;
> private double meanY = 0.0;
> private double N=0;
> private Double covarianceNumerator=0.0;
> private boolean unbiased=true;
> public Covariance(boolean unbiased){
>   this.unbiased = unbiased;
> }
> public void increment(Double x, Double y){
> if(x!=null & y!=null){
> N++;
> deltaX = x - meanX;
> deltaY = y - meanY;
> meanX += deltaX/N;
> meanY += deltaY/N;
> covarianceNumerator += ((N-1.0)/N)*deltaX*deltaY;
> }
> 
> }
> public Double getResult(){
> if(unbiased){
> return covarianceNumerator/(N-1.0);
> }else{
> return covarianceNumerator/N;
> }
> }   
> }
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: in java apache.commons.io,how to avoid to read the old log messages.

2011-06-15 Thread sebb
Please don't send usage questions to the issues list.

Please subscribe to the user mailing list and post there.
Please also prefix the subject line with the Commons Component, i.e. [IO]
See: http://commons.apache.org/mail-lists.html


On 14 June 2011 10:01, santhoshp2...@gmail.com  wrote:
> i am using the java Tail-listener API to do the tailf function(in
> Linux).ie,whenever log messages are updated in log file, this API will print
> the messages.
>
> My code is given below.
>
>    public static void main(String[] args) {
>        // TODO code application logic here
>        File pcounter_log = new File("\vat\temp\test.log");
>
>        try {
>            TailerListener listener = new PCTailListener();
>            Tailer tailer = new Tailer(pcounter_log, listener, 5000, true);
>
>            Thread thread = new Thread(tailer);
>            thread.start();
>        } catch (Exception e) {
>            System.out.println(e);
>        }
>    }
>
> public class PCTailListener extends TailerListenerAdapter {
>    public void handle(String line) {
>        System.out.println(line);
>    }
> }
>
> Initially its working fine.After some time,its reading the old log messages
> (log messages which are generated at the time of log filr
> creation.ie,starting of the log file). also its reading new log messages
> too. how to avoid to read the already monitored log messages.How to do this
>
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/in-java-apache-commons-io-how-to-avoid-to-read-the-old-log-messages-tp3596022p3596022.html
> Sent from the Commons - Issues mailing list archive at Nabble.com.
>


[jira] [Commented] (MATH-449) Storeless covariance

2011-06-15 Thread Patrick Meyer (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049943#comment-13049943
 ] 

Patrick Meyer commented on MATH-449:


I've added the comment to the code. If you have better language for the 
comment, pleas send it to me and I will include it.

Do you have any suggestions for how to best integrate this code into the 
Covariance class? It's not so easy given that the class allows for computation 
of a covariance matrix.

> Storeless covariance
> 
>
> Key: MATH-449
> URL: https://issues.apache.org/jira/browse/MATH-449
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Patrick Meyer
> Fix For: 3.0
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Currently there is no storeless version for computing the covariance. 
> However, Pebay (2008) describes algorithms for on-line covariance 
> computations, [http://infoserve.sandia.gov/sand_doc/2008/086212.pdf]. I have 
> provided a simple class for implementing this algorithm. It would be nice to 
> have this integrated into org.apache.commons.math.stat.correlation.Covariance.
> {code}
> //This code is granted for inclusion in the Apache Commons under the terms of 
> the ASL.
> public class StorelessCovariance{
> private double deltaX = 0.0;
> private double deltaY = 0.0;
> private double meanX = 0.0;
> private double meanY = 0.0;
> private double N=0;
> private Double covarianceNumerator=0.0;
> private boolean unbiased=true;
> public Covariance(boolean unbiased){
>   this.unbiased = unbiased;
> }
> public void increment(Double x, Double y){
> if(x!=null & y!=null){
> N++;
> deltaX = x - meanX;
> deltaY = y - meanY;
> meanX += deltaX/N;
> meanY += deltaY/N;
> covarianceNumerator += ((N-1.0)/N)*deltaX*deltaY;
> }
> 
> }
> public Double getResult(){
> if(unbiased){
> return covarianceNumerator/(N-1.0);
> }else{
> return covarianceNumerator/N;
> }
> }   
> }
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (MATH-449) Storeless covariance

2011-06-15 Thread Patrick Meyer (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Meyer updated MATH-449:
---

Description: 
Currently there is no storeless version for computing the covariance. However, 
Pebay (2008) describes algorithms for on-line covariance computations, 
[http://infoserve.sandia.gov/sand_doc/2008/086212.pdf]. I have provided a 
simple class for implementing this algorithm. It would be nice to have this 
integrated into org.apache.commons.math.stat.correlation.Covariance.

{code}
//This code is granted for inclusion in the Apache Commons under the terms of 
the ASL.

public class StorelessCovariance{

private double deltaX = 0.0;
private double deltaY = 0.0;
private double meanX = 0.0;
private double meanY = 0.0;
private double N=0;
private Double covarianceNumerator=0.0;
private boolean unbiased=true;

public Covariance(boolean unbiased){
this.unbiased = unbiased;
}

public void increment(Double x, Double y){
if(x!=null & y!=null){
N++;
deltaX = x - meanX;
deltaY = y - meanY;
meanX += deltaX/N;
meanY += deltaY/N;
covarianceNumerator += ((N-1.0)/N)*deltaX*deltaY;
}

}

public Double getResult(){
if(unbiased){
return covarianceNumerator/(N-1.0);
}else{
return covarianceNumerator/N;
}
}   
}
{code}

  was:
Currently there is no storeless version for computing the covariance. However, 
Pebay (2008) describes algorithms for on-line covariance computations, 
[http://infoserve.sandia.gov/sand_doc/2008/086212.pdf]. I have provided a 
simple class for implementing this algorithm. It would be nice to have this 
integrated into org.apache.commons.math.stat.correlation.Covariance.

{code}
public class StorelessCovariance{

private double deltaX = 0.0;
private double deltaY = 0.0;
private double meanX = 0.0;
private double meanY = 0.0;
private double N=0;
private Double covarianceNumerator=0.0;
private boolean unbiased=true;

public Covariance(boolean unbiased){
this.unbiased = unbiased;
}

public void increment(Double x, Double y){
if(x!=null & y!=null){
N++;
deltaX = x - meanX;
deltaY = y - meanY;
meanX += deltaX/N;
meanY += deltaY/N;
covarianceNumerator += ((N-1.0)/N)*deltaX*deltaY;
}

}

public Double getResult(){
if(unbiased){
return covarianceNumerator/(N-1.0);
}else{
return covarianceNumerator/N;
}
}   
}
{code}


> Storeless covariance
> 
>
> Key: MATH-449
> URL: https://issues.apache.org/jira/browse/MATH-449
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Patrick Meyer
> Fix For: 3.0
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Currently there is no storeless version for computing the covariance. 
> However, Pebay (2008) describes algorithms for on-line covariance 
> computations, [http://infoserve.sandia.gov/sand_doc/2008/086212.pdf]. I have 
> provided a simple class for implementing this algorithm. It would be nice to 
> have this integrated into org.apache.commons.math.stat.correlation.Covariance.
> {code}
> //This code is granted for inclusion in the Apache Commons under the terms of 
> the ASL.
> public class StorelessCovariance{
> private double deltaX = 0.0;
> private double deltaY = 0.0;
> private double meanX = 0.0;
> private double meanY = 0.0;
> private double N=0;
> private Double covarianceNumerator=0.0;
> private boolean unbiased=true;
> public Covariance(boolean unbiased){
>   this.unbiased = unbiased;
> }
> public void increment(Double x, Double y){
> if(x!=null & y!=null){
> N++;
> deltaX = x - meanX;
> deltaY = y - meanY;
> meanX += deltaX/N;
> meanY += deltaY/N;
> covarianceNumerator += ((N-1.0)/N)*deltaX*deltaY;
> }
> 
> }
> public Double getResult(){
> if(unbiased){
> return covarianceNumerator/(N-1.0);
> }else{
> return covarianceNumerator/N;
> }
> }   
> }
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (MATH-589) JavaDoc error in OneWayAnovaImpl

2011-06-15 Thread Phil Steitz (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz resolved MATH-589.
--

   Resolution: Fixed
Fix Version/s: 3.0

Fixed in r1136112.  Thanks for reporting this.

> JavaDoc error in OneWayAnovaImpl
> 
>
> Key: MATH-589
> URL: https://issues.apache.org/jira/browse/MATH-589
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Lorenzo González
>Priority: Trivial
>  Labels: javadoc
> Fix For: 3.0
>
>
> JavaDoc por OneWayAnovaImpl say:
> Implements one-way ANOVA statistics defined in the OneWayAnovaImpl interface. 
> And the Javadoc must say:
> Implements one-way ANOVA statistics defined in the OneWayAnova interface. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (MATH-449) Storeless covariance

2011-06-15 Thread Phil Steitz (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049850#comment-13049850
 ] 

Phil Steitz commented on MATH-449:
--

Can you please either add a comment indicating the code pasted to the ticket is 
granted for inclusion under terms of the ASL or add it as an attachment and 
check the "for inclusion" box?  Also, some unit tests would be great, including 
validation tests against the stored data version.



> Storeless covariance
> 
>
> Key: MATH-449
> URL: https://issues.apache.org/jira/browse/MATH-449
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Patrick Meyer
> Fix For: 3.0
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Currently there is no storeless version for computing the covariance. 
> However, Pebay (2008) describes algorithms for on-line covariance 
> computations, [http://infoserve.sandia.gov/sand_doc/2008/086212.pdf]. I have 
> provided a simple class for implementing this algorithm. It would be nice to 
> have this integrated into org.apache.commons.math.stat.correlation.Covariance.
> {code}
> public class StorelessCovariance{
> private double deltaX = 0.0;
> private double deltaY = 0.0;
> private double meanX = 0.0;
> private double meanY = 0.0;
> private double N=0;
> private Double covarianceNumerator=0.0;
> private boolean unbiased=true;
> public Covariance(boolean unbiased){
>   this.unbiased = unbiased;
> }
> public void increment(Double x, Double y){
> if(x!=null & y!=null){
> N++;
> deltaX = x - meanX;
> deltaY = y - meanY;
> meanX += deltaX/N;
> meanY += deltaY/N;
> covarianceNumerator += ((N-1.0)/N)*deltaX*deltaY;
> }
> 
> }
> public Double getResult(){
> if(unbiased){
> return covarianceNumerator/(N-1.0);
> }else{
> return covarianceNumerator/N;
> }
> }   
> }
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Closed] (MATH-590) org.apache.commons.math.stats generated an error for OLSMultipleLinearRegression

2011-06-15 Thread Phil Steitz (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz closed MATH-590.


Resolution: Not A Problem

This is a question for the user list.  

>  org.apache.commons.math.stats generated an error for 
> OLSMultipleLinearRegression
> -
>
> Key: MATH-590
> URL: https://issues.apache.org/jira/browse/MATH-590
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: tran
>
> Hello, please be gentil since i am freshman student in statistics. I am 
> trying to use the org.apache.commons.math.stats library for my multiple 
> regression homework. The problem i am facing is that the error message 
> telling me that OLSMultipleLinearRegression could not be resolved when i try 
> to compile my java program; eventhough, i import 
> org.apache.commons.math.stats in my program, 
> and i have OLSMultipleLinearRegression reg = new 
> OLSMultipleLinearRegression() in my code.
> I would like to report this error and get your help.
> Many thanks.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (LANG-706) Create a MutableNumber interface with methods common to all the mutable numbers

2011-06-15 Thread Juan Carlos Estibariz (JIRA)

 [ 
https://issues.apache.org/jira/browse/LANG-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Juan Carlos Estibariz updated LANG-706:
---

Description: 
With this interface it would be possible to perform generic operations on 
mutable numbers without worrying about the specific type, e.g.

{code}
// these two could be created in a different methods
MutableNumber m = new MutableDouble();
Number n = ...;

// this would do the right thing
m.add(n);
{code}


  was:
With this interface it would be possible to perform generic operations on 
mutable numbers without worrying about the specific type, e.g.

{code}
// these two could be created in a different methods
MutableNumber m = new MutableDouble();
Number n = ...;

// this would do the right thing
m.add(n);
{code}

(I'm not just making this up, I have a real use case and I had to create all 
the classes myself)


> Create a MutableNumber interface with methods common to all the mutable 
> numbers
> ---
>
> Key: LANG-706
> URL: https://issues.apache.org/jira/browse/LANG-706
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.mutable.*
>Reporter: Juan Carlos Estibariz
>Priority: Minor
>
> With this interface it would be possible to perform generic operations on 
> mutable numbers without worrying about the specific type, e.g.
> {code}
> // these two could be created in a different methods
> MutableNumber m = new MutableDouble();
> Number n = ...;
> // this would do the right thing
> m.add(n);
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (MATH-594) AdamsMoultonIntegrator documentation whitespace fix

2011-06-15 Thread Luc Maisonobe (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049678#comment-13049678
 ] 

Luc Maisonobe commented on MATH-594:


Only the Adams integrators are experimental. There was another integrator (BDF, 
Backward Differential Formula) that was still more experimental but in fact it 
was not included in the library (it may be included once Adams integrators are 
OK, as it shares some code with them, as a multi-step integrator).

The good integrators I recommend are Dormand-Prince 8(5,3) and 
Gragg-Bulirsch-Stoer. They are very efficient and very accurate.

You are right, we should display the status of Adams integrators more 
prominently. The best thing however is really to remove this "experimental" 
status and have these integrators as suitable for production than the other 
ones. If we can't achieve this, we'll put a warning in the documentation.

> AdamsMoultonIntegrator documentation whitespace fix
> ---
>
> Key: MATH-594
> URL: https://issues.apache.org/jira/browse/MATH-594
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Dennis Hendriks
>Priority: Trivial
>  Labels: documentation, patch
> Fix For: 3.0
>
> Attachments: adams-moulton-integrator-docu-whitespace-fix.patch
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (MATH-594) AdamsMoultonIntegrator documentation whitespace fix

2011-06-15 Thread Dennis Hendriks (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049677#comment-13049677
 ] 

Dennis Hendriks commented on MATH-594:
--

Of the integrators listed at http://commons.apache.org/math/userguide/ode.html 
(13.4 Available Integrators), are more of them experimental?

And maybe it is a good idea to list the experimental status at the 
documentation page (user guide) as well?


> AdamsMoultonIntegrator documentation whitespace fix
> ---
>
> Key: MATH-594
> URL: https://issues.apache.org/jira/browse/MATH-594
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Dennis Hendriks
>Priority: Trivial
>  Labels: documentation, patch
> Fix For: 3.0
>
> Attachments: adams-moulton-integrator-docu-whitespace-fix.patch
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Closed] (NET-417) org.apache.commons.net.ftpFTPClient, file will not be totally transferred.

2011-06-15 Thread Sebb (JIRA)

 [ 
https://issues.apache.org/jira/browse/NET-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb closed NET-417.



> org.apache.commons.net.ftpFTPClient, file will not be totally transferred.
> --
>
> Key: NET-417
> URL: https://issues.apache.org/jira/browse/NET-417
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.0
> Environment: Windows XP FTPClient program sending file to Windows 
> 2003 IIS FTP Server
>Reporter: tom yang
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> If I use this ftp.storeFile(f.getName(), stream)  to transfer file to the FTP 
> Server. After the function returned the file will be partially sent. 
> E.g. If the file has 1025 bytes, only 1024 bytes will be sent while if the 
> file has 2050 bytes, only 2048 bytes will be sent.
> That's because the default buffer size is 1024, each time 1024 bytes of file 
> content will be sent to the FTP server. But stream.flush() is not called at 
> the end of each transfer. Finally, socket stream to FTP server will be closed 
> before the 
> last transmission and the last frame of data, which may be less than 1024, 
> will be left unsent.
> My way of fixing this BUG: Change the content of method 
> FtpClient.__storeFile(), change the last parameter for calling 
> Util.copyStream() to 'true'.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (NET-417) org.apache.commons.net.ftpFTPClient, file will not be totally transferred.

2011-06-15 Thread Sebb (JIRA)

 [ 
https://issues.apache.org/jira/browse/NET-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated NET-417:
-

Affects Version/s: (was: 3.0.1)
   3.0
   Labels:   (was: newbie)

> org.apache.commons.net.ftpFTPClient, file will not be totally transferred.
> --
>
> Key: NET-417
> URL: https://issues.apache.org/jira/browse/NET-417
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.0
> Environment: Windows XP FTPClient program sending file to Windows 
> 2003 IIS FTP Server
>Reporter: tom yang
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> If I use this ftp.storeFile(f.getName(), stream)  to transfer file to the FTP 
> Server. After the function returned the file will be partially sent. 
> E.g. If the file has 1025 bytes, only 1024 bytes will be sent while if the 
> file has 2050 bytes, only 2048 bytes will be sent.
> That's because the default buffer size is 1024, each time 1024 bytes of file 
> content will be sent to the FTP server. But stream.flush() is not called at 
> the end of each transfer. Finally, socket stream to FTP server will be closed 
> before the 
> last transmission and the last frame of data, which may be less than 1024, 
> will be left unsent.
> My way of fixing this BUG: Change the content of method 
> FtpClient.__storeFile(), change the last parameter for calling 
> Util.copyStream() to 'true'.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (NET-417) org.apache.commons.net.ftpFTPClient, file will not be totally transferred.

2011-06-15 Thread Sebb (JIRA)

 [ 
https://issues.apache.org/jira/browse/NET-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved NET-417.
--

Resolution: Duplicate

> org.apache.commons.net.ftpFTPClient, file will not be totally transferred.
> --
>
> Key: NET-417
> URL: https://issues.apache.org/jira/browse/NET-417
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.0
> Environment: Windows XP FTPClient program sending file to Windows 
> 2003 IIS FTP Server
>Reporter: tom yang
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> If I use this ftp.storeFile(f.getName(), stream)  to transfer file to the FTP 
> Server. After the function returned the file will be partially sent. 
> E.g. If the file has 1025 bytes, only 1024 bytes will be sent while if the 
> file has 2050 bytes, only 2048 bytes will be sent.
> That's because the default buffer size is 1024, each time 1024 bytes of file 
> content will be sent to the FTP server. But stream.flush() is not called at 
> the end of each transfer. Finally, socket stream to FTP server will be closed 
> before the 
> last transmission and the last frame of data, which may be less than 1024, 
> will be left unsent.
> My way of fixing this BUG: Change the content of method 
> FtpClient.__storeFile(), change the last parameter for calling 
> Util.copyStream() to 'true'.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (MATH-594) AdamsMoultonIntegrator documentation whitespace fix

2011-06-15 Thread Luc Maisonobe (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-594.


Resolution: Fixed

Fixed in subversion tree as of r1135946.

Thanks for the report and the patch.

Beware that the Adams integrators are still experimental one. I am working on 
them. They sometimes have a tendency to decrease the step down to zero 
regardless of the settings. I think this is a numeric issue but still have to 
solve it.

> AdamsMoultonIntegrator documentation whitespace fix
> ---
>
> Key: MATH-594
> URL: https://issues.apache.org/jira/browse/MATH-594
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Dennis Hendriks
>Priority: Trivial
>  Labels: documentation, patch
> Fix For: 3.0
>
> Attachments: adams-moulton-integrator-docu-whitespace-fix.patch
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (MATH-594) AdamsMoultonIntegrator documentation whitespace fix

2011-06-15 Thread Dennis Hendriks (JIRA)
AdamsMoultonIntegrator documentation whitespace fix
---

 Key: MATH-594
 URL: https://issues.apache.org/jira/browse/MATH-594
 Project: Commons Math
  Issue Type: Improvement
Reporter: Dennis Hendriks
Priority: Trivial
 Fix For: 3.0
 Attachments: adams-moulton-integrator-docu-whitespace-fix.patch



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (MATH-594) AdamsMoultonIntegrator documentation whitespace fix

2011-06-15 Thread Dennis Hendriks (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Hendriks updated MATH-594:
-

Attachment: adams-moulton-integrator-docu-whitespace-fix.patch

Proposed patch.

> AdamsMoultonIntegrator documentation whitespace fix
> ---
>
> Key: MATH-594
> URL: https://issues.apache.org/jira/browse/MATH-594
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Dennis Hendriks
>Priority: Trivial
>  Labels: documentation, patch
> Fix For: 3.0
>
> Attachments: adams-moulton-integrator-docu-whitespace-fix.patch
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira