[jira] [Commented] (COMPRESS-133) Mention Debian/Ubuntu packages in AR format documentation
[
https://issues.apache.org/jira/browse/COMPRESS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808647#comment-13808647
]
BELUGA BEHR commented on COMPRESS-133:
--
Has this been resolved?
> 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: Documentation
>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 was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (COMPRESS-186) The example should be much easier to read
[ https://issues.apache.org/jira/browse/COMPRESS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808643#comment-13808643 ] BELUGA BEHR commented on COMPRESS-186: -- What example is this in reference to? > The example should be much easier to read > - > > Key: COMPRESS-186 > URL: https://issues.apache.org/jira/browse/COMPRESS-186 > Project: Commons Compress > Issue Type: Improvement > Components: Documentation >Reporter: Yang Hua Jie > Labels: examples > Original Estimate: 504h > Remaining Estimate: 504h > > The example should be much easier to read。 I read it for a long time and copy > the code to my favorite IDE. But no lucky, I can not make it work. > There should have a quick start page, and the page should be very easy -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (COMPRESS-238) Add RAR archive support
[ https://issues.apache.org/jira/browse/COMPRESS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808642#comment-13808642 ] BELUGA BEHR edited comment on COMPRESS-238 at 10/30/13 1:15 AM: I'm confused by some of my initial research... is the format proprietary? Or is only the compression algorithm covered, but not the inflating of the files. was (Author: belugabehr): I'm confused by some of my initial research... is the format proprietary? Or is only the compression algorithm covered, but not the un-compression? > Add RAR archive support > --- > > Key: COMPRESS-238 > URL: https://issues.apache.org/jira/browse/COMPRESS-238 > Project: Commons Compress > Issue Type: Wish > Components: Archivers >Reporter: Stefan Bodewig > > Creating a new ticket for RAR so I can close COMPRESS-54 > There is an Unrar library with a license that has been deemed acceptable for > use in Apache projects - I think TIKA already uses it. > https://github.com/edmund-wagner/junrar -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COMPRESS-238) Add RAR archive support
[ https://issues.apache.org/jira/browse/COMPRESS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808642#comment-13808642 ] BELUGA BEHR commented on COMPRESS-238: -- I'm confused by some of my initial research... is the format proprietary? Or is only the compression algorithm covered, but not the un-compression? > Add RAR archive support > --- > > Key: COMPRESS-238 > URL: https://issues.apache.org/jira/browse/COMPRESS-238 > Project: Commons Compress > Issue Type: Wish > Components: Archivers >Reporter: Stefan Bodewig > > Creating a new ticket for RAR so I can close COMPRESS-54 > There is an Unrar library with a license that has been deemed acceptable for > use in Apache projects - I think TIKA already uses it. > https://github.com/edmund-wagner/junrar -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-814) Kendalls Tau Implementation
[ https://issues.apache.org/jira/browse/MATH-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808595#comment-13808595 ] Matt Adereth commented on MATH-814: --- Apologies in advance for not being consistent with SpearmansCorrelation. I couldn't bring myself to make these methods non-static or to use the approach of having the constructor take the data. If this is a problem, I have no issue making the requisite change. Another consideration that I didn't do, but would be willing to try, would be to make a new Correlation interface that exposes the methods that should be common to Spearmans, Kendalls, and Pearsons. It would probably make sense to then have an AbstractCorrelation base class that handles the sheparding of data between Matrix, double[][], and double[], double[]. Finally, if you do think a Correlation interface makes sense, I'd also like to propose a NonParametricCorrelation interface for Spearmans and Kendalls which would have an additional method for computing the Correlation between two List objects. > Kendalls Tau Implementation > --- > > Key: MATH-814 > URL: https://issues.apache.org/jira/browse/MATH-814 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 4.0 > Environment: All >Reporter: devl >Assignee: Phil Steitz > Labels: correlation, rank > Fix For: 4.0 > > Attachments: kendalls-tau.patch > > Original Estimate: 840h > Remaining Estimate: 840h > > Implement the Kendall's Tau which is a measure of Association/Correlation > between ranked ordinal data. > A basic description is available at > http://en.wikipedia.org/wiki/Kendall_tau_rank_correlation_coefficient however > the test implementation will follow that defined by "Handbook of Parametric > and Nonparametric Statistical Procedures, Fifth Edition, Page 1393 Test 30, > ISBN-10: 1439858012 | ISBN-13: 978-1439858011." > The algorithm is proposed as follows. > Given two rankings or permutations represented by a 2D matrix; columns > indicate rankings (e.g. by an individual) and row are observations of each > rank. The algorithm is to calculate the total number of concordant pairs of > ranks (between columns), discordant pairs of ranks (between columns) and > calculate the Tau defined as > tau= (Number of concordant - number of discordant)/(n(n-1)/2) > where n(n-1)/2 is the total number of possible pairs of ranks. > The method will then output the tau value between -1 and 1 where 1 signifies > a "perfect" correlation between the two ranked lists. > Where ties exist within a ranking it is marked as neither concordant nor > discordant in the calculation. An optional merge sort can be used to speed up > the implementation. Details are in the wiki page. > Although this implementation is not particularly complex it would be useful > to have it in a consistent format in the commons math package in addition to > existing correlation tests. Kendall's Tau is used effectively in comparing > ranks for products, rankings from search engines or measurements from > engineering equipment. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808455#comment-13808455 ] Thomas Neidhart commented on MATH-1045: --- We need to change the behavior for non-symmetric matrices as the eigenvalues are not sorted in this case. This patch relies on a descending sort order to determine if the decomposed matrix is singular, so this may fail in such a case. I will create a separate issue for this as it makes sense to always sort the eigenvalues imho. > EigenDecomposition.Solver should consider tiny values 0 for purposes of > determining singularity > --- > > Key: MATH-1045 > URL: https://issues.apache.org/jira/browse/MATH-1045 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: eigenvalue, singular > Fix For: 3.3 > > Attachments: MATH-1045.patch, MATH-1045.patch > > > EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 > for exact equality. Elsewhere in the class and in the code, of course, very > small values are considered 0. This causes the solver to consider some > singular matrices as non-singular. > The patch here includes a test as well showing the behavior -- the matrix is > clearly singular but isn't considered as such since one eigenvalue are ~1e-14 > rather than exactly 0. > (What I am not sure of is whether we should really be evaluating the *norm* > of the imaginary eigenvalues rather than real/imag components separately. But > the javadoc says the solver only supports real eigenvalues anyhow, so it's > kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-1045. -- Resolution: Fixed Fix Version/s: 3.3 Applied in revision 1536766. I created MATH-1049 for discussing further improvements. > EigenDecomposition.Solver should consider tiny values 0 for purposes of > determining singularity > --- > > Key: MATH-1045 > URL: https://issues.apache.org/jira/browse/MATH-1045 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: eigenvalue, singular > Fix For: 3.3 > > Attachments: MATH-1045.patch, MATH-1045.patch > > > EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 > for exact equality. Elsewhere in the class and in the code, of course, very > small values are considered 0. This causes the solver to consider some > singular matrices as non-singular. > The patch here includes a test as well showing the behavior -- the matrix is > clearly singular but isn't considered as such since one eigenvalue are ~1e-14 > rather than exactly 0. > (What I am not sure of is whether we should really be evaluating the *norm* > of the imaginary eigenvalues rather than real/imag components separately. But > the javadoc says the solver only supports real eigenvalues anyhow, so it's > kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1049) Matrix decomposition and solver
Gilles created MATH-1049: Summary: Matrix decomposition and solver Key: MATH-1049 URL: https://issues.apache.org/jira/browse/MATH-1049 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Gilles Priority: Minor Fix For: 4.0 The discussion about issue MATH-1045 has uncovered some room for improvement in the API and implementation of the matrix decomposition algorithms. See also [this thread|http://markmail.org/message/orgt3fqgnqips5pq] on the "dev" ML. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1047) No check for overflow in "ArithmeticUtils.pow"
[ https://issues.apache.org/jira/browse/MATH-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807909#comment-13807909 ] Gilles commented on MATH-1047: -- Method "pow(int,int)" modified in revision 1536683 (using "mulAndCheck"). > No check for overflow in "ArithmeticUtils.pow" > -- > > Key: MATH-1047 > URL: https://issues.apache.org/jira/browse/MATH-1047 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Gilles > Labels: safety > Fix For: 3.3 > > Attachments: MATH-1047.patch > > > The "pow" methods in "o.a.c.m.util.ArithmeticUtils" do not check for overflow. > They will happily return nonsensical results. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (JEXL-143) Huge numbers are rounded
[
https://issues.apache.org/jira/browse/JEXL-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-143.
Resolution: Not A Problem
Per his last comment, customer is OK with provided answer and behavior.
> Huge numbers are rounded
> -
>
> Key: JEXL-143
> URL: https://issues.apache.org/jira/browse/JEXL-143
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 2.1.1
> Environment: Ubunu 12.04, android studio 0.2.10
>Reporter: Frank
>
> When calculating huge numbers, which are still in the long range the result
> is wrong (or getting rounded somehow), e.g.
> Expression e = jexl.createExpression("math:pow(2, 62)"); //also tried
> `pow(2.0, 62.0)` and pow(2L, 62L)`
> JexlContext context = new MapContext();
> String res = String.valueOf(e.evaluate(context));
> returns `4611686018427388000` but it should be `4611686018427387904`
--
This message was sent by Atlassian JIRA
(v6.1#6144)
