[jira] [Commented] (COMPRESS-391) Zip entries alignment
[ https://issues.apache.org/jira/browse/COMPRESS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16004052#comment-16004052 ] Zbynek Vyskovsky commented on COMPRESS-391: --- [~bodewig] : Oh, I should be faster in implementing the patches if I don't want to wait for another release :-) Thanks for this! I think first the field can be removed completely and then only added if the alignment doesn't match. Although with approach you mentioned the copying of alignment would still work as long as the old files streams and structure remains exactly the same... which is kind of fragile though... I believe it would still make sense to write the requested alignment value (not padding value) as part of the payload, it's just two bytes anyway and it may be used later when someone implements both reading and writing part. Additionally, in such case this extra field should be written always, not only when alignment doesn't match, as it contains important information for re-zipping. About zipalign: As far as I remember, they simply add enough zeroes at the end of extra fields, they even don't create the id header, its size etc. So the result is not really correct zip stream but I assume the readers simply ignore it. So no "prior art" here... About Zip RFC: According to https://support.pkware.com/display/PKZIP/APPNOTE , there is an e-mail for proposing enhancements. I can write and update here. 0xalle (id), 0x0002 (size), short (alignment) sounds good? :-) > Zip entries alignment > - > > Key: COMPRESS-391 > URL: https://issues.apache.org/jira/browse/COMPRESS-391 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.13 >Reporter: Zbynek Vyskovsky > Labels: features, github-import, patch > Fix For: 1.14 > > > Similarly to COMPRESS-390, there are requirements of the zip content to be > mapped directly into memory and therefore may require special alignment on > the embedded files. E.g. libraries may be aligned to page (4096-bytes) > boundary, images on 4-bytes boundary etc. By alignment it's meant the offset > from the beginning of file where the actual data stream starts, not the > header. > One of the cases was (still is?) Android APK for which zipalign utility was > created. > It would be useful if commons-compress ZipArchiveOutputStream supports > something similar directly in its API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-391) Zip entries alignment
[
https://issues.apache.org/jira/browse/COMPRESS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16004029#comment-16004029
]
Stefan Bodewig commented on COMPRESS-391:
-
[~kvr] don't worry. I'm eager to get 1.14 out, that's why I started to
implenent something myself.
bq. I think it might make sense to take the length from extra once re-populated
True, but for a different reason. {{addExtraField}} replaces an existing extra
field using the same id, so if there has already been an extra field by that id
the length of extra would be different. It will be cleaner to try removing an
existing padding field (or adjusting, I'm bad at names :-), recalculate the
size, add one, and maybe recalculate the size again. I'll modify the patch
accordingly. This should address your concern about previously existing
alignment and having only one instance of the extra field.
The field is really only useful when writing the archive, so I don't think we
need to perform any special step when alignment changes. This should be
addressed when the entry with the changed alignment is written (again) -
something that should happen when I modify the existing code.
WRT the id I understood we would mimic "prior art" used by zipalign. We should
use the same id it uses. As for Zip RFC, I'm not sure about the process, or if
there is a process at all.
> Zip entries alignment
> -
>
> Key: COMPRESS-391
> URL: https://issues.apache.org/jira/browse/COMPRESS-391
> Project: Commons Compress
> Issue Type: New Feature
> Components: Archivers
>Affects Versions: 1.13
>Reporter: Zbynek Vyskovsky
> Labels: features, github-import, patch
> Fix For: 1.14
>
>
> Similarly to COMPRESS-390, there are requirements of the zip content to be
> mapped directly into memory and therefore may require special alignment on
> the embedded files. E.g. libraries may be aligned to page (4096-bytes)
> boundary, images on 4-bytes boundary etc. By alignment it's meant the offset
> from the beginning of file where the actual data stream starts, not the
> header.
> One of the cases was (still is?) Android APK for which zipalign utility was
> created.
> It would be useful if commons-compress ZipArchiveOutputStream supports
> something similar directly in its API.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16003376#comment-16003376
]
Gilles commented on MATH-1417:
--
Got it. :)
Please check that commit ed1ce82d822ffe185875b7b7d38352f20171c096 fixed the
problem.
> weird result in RRQR decomposition.
> ---
>
> Key: MATH-1417
> URL: https://issues.apache.org/jira/browse/MATH-1417
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: linux RH6
> netbeans 8.2
> java 1.8
>Reporter: Lecomte
>
> When using RRQRDecomposition on rank deficient matrix, results are wrong.
> double[][] Xi = {
> {0, 0, 0, 0, 0, 0, 0, 0, 0},
> {0, 1, 0, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 0, 1, 0, 0, 0, 0, 0},
> {0, 0, 0, 0, 0, 0, 1, 0, 0},
> {0, 0, 0, 0, 0, 0, 0, 0, 0},};
> With this matrix, i obtain:
> rank 6
> R:
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 1,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> Q:
> |0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000|
> Where Scipy (lapack) or ejml gives me:
> rank 4
> Type = dense real , numRows = 9 , numCols = 8
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 -1,000 0,000 -1,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> Type = dense real , numRows = 9 , numCols = 9
> 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000
> That are the results i expect.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002933#comment-16002933
]
Gilles edited comment on MATH-1417 at 5/9/17 7:35 PM:
--
Sorry, but i am searching a nullspace and so i work with Xi transposed, not Xi
by itself. And with this transposed matrix I should also obtain rank 4.
I didn't test master branch but the code seems the same.
was (Author: lecomtje):
Sorry, but i am searching a nullspace and so i work with Xi transposed, not Xi
by itself. And with this transposed matrix I should also obtain rank 4.
I didn't test master branch but the code seems the same.
-Message d'origine-
De : Gilles (JIRA) [mailto:j...@apache.org]
Envoyé : mardi 9 mai 2017 16:42
À : LECOMTE Jean-Francois
Objet : [jira] [Commented] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002798#comment-16002798
]
Gilles commented on MATH-1417:
--
Have you checked out the git "master" branch?
With your example (and no change to the source), I obtain 4 as the rank value.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
__
Avant d'imprimer, pensez à l'environnement ! Please consider the environment
before printing !
Ce message et toutes ses pièces jointes sont confidentiels et établis à
l'intention exclusive de ses destinataires. Toute utilisation non conforme à sa
destination, toute diffusion ou toute publication, totale ou partielle, est
interdite, sauf autorisation expresse. IFP Energies nouvelles décline toute
responsabilité au titre de ce message. This message and any attachments are
confidential and intended solely for the addressees. Any unauthorised use or
dissemination is prohibited. IFP Energies nouvelles should not be liable for
this message.
__
> weird result in RRQR decomposition.
> ---
>
> Key: MATH-1417
> URL: https://issues.apache.org/jira/browse/MATH-1417
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: linux RH6
> netbeans 8.2
> java 1.8
>Reporter: Lecomte
>
> When using RRQRDecomposition on rank deficient matrix, results are wrong.
> double[][] Xi = {
> {0, 0, 0, 0, 0, 0, 0, 0, 0},
> {0, 1, 0, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 0, 1, 0, 0, 0, 0, 0},
> {0, 0, 0, 0, 0, 0, 1, 0, 0},
> {0, 0, 0, 0, 0, 0, 0, 0, 0},};
> With this matrix, i obtain:
> rank 6
> R:
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 1,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> Q:
> |0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000|
> Where Scipy (lapack) or ejml gives me:
> rank 4
> Type = dense real , numRows = 9 , numCols = 8
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 -1,000 0,000 -1,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> Type = dense real , numRows = 9 , numCols = 9
> 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,0
[jira] [Created] (IO-536) 2.5 ExceptionInInitializerError
Mitch Sundt created IO-536: -- Summary: 2.5 ExceptionInInitializerError Key: IO-536 URL: https://issues.apache.org/jira/browse/IO-536 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.5 Environment: This occurs on Android devices. But I think it is a general issue. Reporter: Mitch Sundt In its static block, org.apache.commons.io.Java7Support executes: ClassLoader cl = Thread.currentThread().getContextClassLoader(); This can be null. In that case, I believe the class should fall back to using: Java7Support.class.getClassLoader(); But someone with a better understanding of the security implications should weigh in on that change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Re: [jira] [Resolved] (NUMBERS-36) mathjax CDN shutting down - will soon break javadoc
Would it be possible to host it somewhere on apache.org which would
eliminate the dependence on third parties?
On Tue, May 9, 2017 at 8:00 AM, Stian Soiland-Reyes (JIRA)
wrote:
>
> [ https://issues.apache.org/jira/browse/NUMBERS-36?page=
> com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Stian Soiland-Reyes resolved NUMBERS-36.
>
>Resolution: Fixed
> Fix Version/s: 1.0
>
> > mathjax CDN shutting down - will soon break javadoc
> > ---
> >
> > Key: NUMBERS-36
> > URL: https://issues.apache.org/jira/browse/NUMBERS-36
> > Project: Commons Numbers
> > Issue Type: Bug
> >Reporter: Stian Soiland-Reyes
> >Assignee: Stian Soiland-Reyes
> > Fix For: 1.0
> >
> >
> > Javadoc for Commons Math, Commons Numbers and friends use a the [MathJax|
> https://www.mathjax.org/] Javascript in order to render LaTeX equation
> within Javadoc. (See MATH-1006)
> > This used to be included as http://cdn.mathjax.org/
> mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML -- but now [
> cdn.mathjax.org is shutting down|https://www.mathjax.org/
> cdn-shutting-down/]. There is a temporary redirect.
> > There are several alternatives suggested, with the recommended being:
> > {code}
> > > src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/
> MathJax.js?...">
> >
> > {code}
> > Other alternatives include rawgit.com - e.g. https://cdn.rawgit.com/
> mathjax/MathJax/2.7.1/MathJax.js with a fixed version - which is probably
> a good thing. I've tried this approach for Commons Numbers, which seems to
> work -- not sure if adding {{?config=TeX-AMS-MML_HTMLorMML}} would make
> any difference there as rawgit caches the file directly from GitHub.
> > Of course the MathJax javascript is Apache-licensed, so we could easily
> embed it in the ASF source code - but then in multi-module projects I
> wonder if we would then need to share it across all modules.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
[jira] [Updated] (LANG-1330) EqualsBuilder should be able to call custom equals method for specified class
[
https://issues.apache.org/jira/browse/LANG-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Smiley updated LANG-1330:
---
Description:
As a tester, there are times I want to exclude certain fields (like ID) for my
parent object and its children.
For example:
{code}
class Parent {
public String id;
public NormalChild child1;
public SpecialChild child2;
//uses ReflectionEqualsBuilder for equals();
//has custom equalsWithoutID() method;
}
class NormalChild extend Child {
public String name;
//uses ReflectionEqualsBuilder equals();
//has custom equalsWithoutID() method via inheritance;
}
class SpecialChild extend Child {
public String id;
public String name;
//uses ReflectionEqualsBuilder for equals();
//has custom equalsWithoutID() method via inheritence;
}
{code}
If I am running a reflectionEquals with excluding field "id" on my parent
object, the excludedFields won't be used on my children classes (only excludes
fields of parent with name). I would like to be able to call the custom
equalsWithoutID() if its an instance of class Child.
Currently i need to do a workaround where my equals() checks to see which
method I was using before executing but its not an ideal solution.
was:
As a tester, there are times I want to exclude certain fields (like ID) for my
parent object and its children.
For example:
class Parent {
public String id;
public NormalChild child1;
public SpecialChild child2;
//uses ReflectionEqualsBuilder for equals();
//has custom equalsWithoutID() method;
}
class NormalChild extend Child {
public String name;
//uses ReflectionEqualsBuilder equals();
//has custom equalsWithoutID() method via inheritance;
}
class SpecialChild extend Child {
public String id;
public String name;
//uses ReflectionEqualsBuilder for equals();
//has custom equalsWithoutID() method via inheritence;
}
If I am running a reflectionEquals with excluding field "id" on my parent
object, the excludedFields won't be used on my children classes (only excludes
fields of parent with name). I would like to be able to call the custom
equalsWithoutID() if its an instance of class Child.
Currently i need to do a workaround where my equals() checks to see which
method I was using before executing but its not an ideal solution.
> EqualsBuilder should be able to call custom equals method for specified class
> -
>
> Key: LANG-1330
> URL: https://issues.apache.org/jira/browse/LANG-1330
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Jason Smiley
>
> As a tester, there are times I want to exclude certain fields (like ID) for
> my parent object and its children.
> For example:
> {code}
> class Parent {
> public String id;
> public NormalChild child1;
> public SpecialChild child2;
> //uses ReflectionEqualsBuilder for equals();
> //has custom equalsWithoutID() method;
> }
> class NormalChild extend Child {
> public String name;
> //uses ReflectionEqualsBuilder equals();
> //has custom equalsWithoutID() method via inheritance;
> }
> class SpecialChild extend Child {
> public String id;
> public String name;
> //uses ReflectionEqualsBuilder for equals();
> //has custom equalsWithoutID() method via inheritence;
> }
> {code}
> If I am running a reflectionEquals with excluding field "id" on my parent
> object, the excludedFields won't be used on my children classes (only
> excludes fields of parent with name). I would like to be able to call the
> custom equalsWithoutID() if its an instance of class Child.
> Currently i need to do a workaround where my equals() checks to see which
> method I was using before executing but its not an ideal solution.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (TEXT-41) WordUtils.abbreviate support
[ https://issues.apache.org/jira/browse/TEXT-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins resolved TEXT-41. -- Resolution: Implemented > WordUtils.abbreviate support > > > Key: TEXT-41 > URL: https://issues.apache.org/jira/browse/TEXT-41 > Project: Commons Text > Issue Type: New Feature >Reporter: Mirek Hankus >Assignee: Rob Tompkins > Fix For: 1.1 > > Attachments: LANG-766.patch > > > Commons Lang 2.x has method WordUtils.abbreviate(java.lang.String str, int > lower, int upper, java.lang.String appendToEnd), which > # operates on words not Strings as StringUtils.abbreviate > # it allows to specify what shoud be appended to string > (StringUtils.abbreviate always appends "...") > In 3.0 there is no such method, but it was very usefull. please add support > for WordUtils.abbreviate -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-41) WordUtils.abbreviate support
[ https://issues.apache.org/jira/browse/TEXT-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002986#comment-16002986 ] Rob Tompkins commented on TEXT-41: -- Thanks for that reminder. Completely overlooked on my part :-). > WordUtils.abbreviate support > > > Key: TEXT-41 > URL: https://issues.apache.org/jira/browse/TEXT-41 > Project: Commons Text > Issue Type: New Feature >Reporter: Mirek Hankus >Assignee: Rob Tompkins > Fix For: 1.1 > > Attachments: LANG-766.patch > > > Commons Lang 2.x has method WordUtils.abbreviate(java.lang.String str, int > lower, int upper, java.lang.String appendToEnd), which > # operates on words not Strings as StringUtils.abbreviate > # it allows to specify what shoud be appended to string > (StringUtils.abbreviate always appends "...") > In 3.0 there is no such method, but it was very usefull. please add support > for WordUtils.abbreviate -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (LANG-1330) EqualsBuilder should be able to call custom equals method for specified class
[
https://issues.apache.org/jira/browse/LANG-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Smiley updated LANG-1330:
---
Summary: EqualsBuilder should be able to call custom equals method for
specified class (was: EqualsBuilder can call custom equals method for class)
> EqualsBuilder should be able to call custom equals method for specified class
> -
>
> Key: LANG-1330
> URL: https://issues.apache.org/jira/browse/LANG-1330
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Jason Smiley
>
> As a tester, there are times I want to exclude certain fields (like ID) for
> my parent object and its children.
> For example:
> class Parent {
> public String id;
> public NormalChild child1;
> public SpecialChild child2;
> //uses ReflectionEqualsBuilder for equals();
> //has custom equalsWithoutID() method;
> }
> class NormalChild extend Child {
> public String name;
> //uses ReflectionEqualsBuilder equals();
> //has custom equalsWithoutID() method via inheritance;
> }
> class SpecialChild extend Child {
> public String id;
> public String name;
> //uses ReflectionEqualsBuilder for equals();
> //has custom equalsWithoutID() method via inheritence;
> }
> If I am running a reflectionEquals with excluding field "id" on my parent
> object, the excludedFields won't be used on my children classes (only
> excludes fields of parent with name). I would like to be able to call the
> custom equalsWithoutID() if its an instance of class Child.
> Currently i need to do a workaround where my equals() checks to see which
> method I was using before executing but its not an ideal solution.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (LANG-1330) EqualsBuilder can call custom equals method for class
Jason Smiley created LANG-1330:
--
Summary: EqualsBuilder can call custom equals method for class
Key: LANG-1330
URL: https://issues.apache.org/jira/browse/LANG-1330
Project: Commons Lang
Issue Type: New Feature
Reporter: Jason Smiley
As a tester, there are times I want to exclude certain fields (like ID) for my
parent object and its children.
For example:
class Parent {
public String id;
public NormalChild child1;
public SpecialChild child2;
//uses ReflectionEqualsBuilder for equals();
//has custom equalsWithoutID() method;
}
class NormalChild extend Child {
public String name;
//uses ReflectionEqualsBuilder equals();
//has custom equalsWithoutID() method via inheritance;
}
class SpecialChild extend Child {
public String id;
public String name;
//uses ReflectionEqualsBuilder for equals();
//has custom equalsWithoutID() method via inheritence;
}
If I am running a reflectionEquals with excluding field "id" on my parent
object, the excludedFields won't be used on my children classes (only excludes
fields of parent with name). I would like to be able to call the custom
equalsWithoutID() if its an instance of class Child.
Currently i need to do a workaround where my equals() checks to see which
method I was using before executing but its not an ideal solution.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TEXT-41) WordUtils.abbreviate support
[ https://issues.apache.org/jira/browse/TEXT-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002966#comment-16002966 ] Amey Jadiye commented on TEXT-41: - Hi [~chtompki], as PR already merged can we mark this to resolved ? > WordUtils.abbreviate support > > > Key: TEXT-41 > URL: https://issues.apache.org/jira/browse/TEXT-41 > Project: Commons Text > Issue Type: New Feature >Reporter: Mirek Hankus >Assignee: Rob Tompkins > Fix For: 1.1 > > Attachments: LANG-766.patch > > > Commons Lang 2.x has method WordUtils.abbreviate(java.lang.String str, int > lower, int upper, java.lang.String appendToEnd), which > # operates on words not Strings as StringUtils.abbreviate > # it allows to specify what shoud be appended to string > (StringUtils.abbreviate always appends "...") > In 3.0 there is no such method, but it was very usefull. please add support > for WordUtils.abbreviate -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lecomte updated MATH-1417:
--
Sorry, but i am searching a nullspace and so i work with Xi transposed, not Xi
by itself. And with this transposed matrix I should also obtain rank 4.
I didn't test master branch but the code seems the same.
-Message d'origine-
De : Gilles (JIRA) [mailto:j...@apache.org]
Envoyé : mardi 9 mai 2017 16:42
À : LECOMTE Jean-Francois
Objet : [jira] [Commented] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002798#comment-16002798
]
Gilles commented on MATH-1417:
--
Have you checked out the git "master" branch?
With your example (and no change to the source), I obtain 4 as the rank value.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
__
Avant d'imprimer, pensez à l'environnement ! Please consider the environment
before printing !
Ce message et toutes ses pièces jointes sont confidentiels et établis à
l'intention exclusive de ses destinataires. Toute utilisation non conforme à sa
destination, toute diffusion ou toute publication, totale ou partielle, est
interdite, sauf autorisation expresse. IFP Energies nouvelles décline toute
responsabilité au titre de ce message. This message and any attachments are
confidential and intended solely for the addressees. Any unauthorised use or
dissemination is prohibited. IFP Energies nouvelles should not be liable for
this message.
__
> weird result in RRQR decomposition.
> ---
>
> Key: MATH-1417
> URL: https://issues.apache.org/jira/browse/MATH-1417
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: linux RH6
> netbeans 8.2
> java 1.8
>Reporter: Lecomte
>
> When using RRQRDecomposition on rank deficient matrix, results are wrong.
> double[][] Xi = {
> {0, 0, 0, 0, 0, 0, 0, 0, 0},
> {0, 1, 0, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 0, 1, 0, 0, 0, 0, 0},
> {0, 0, 0, 0, 0, 0, 1, 0, 0},
> {0, 0, 0, 0, 0, 0, 0, 0, 0},};
> With this matrix, i obtain:
> rank 6
> R:
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 1,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> Q:
> |0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000|
> Where Scipy (lapack) or ejml gives me:
> rank 4
> Type = dense real , numRows = 9 , numCols = 8
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 -1,000 0,000 -1,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> Type = dense real , numRows = 9 , numCols = 9
> 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1
[jira] [Commented] (COMPRESS-391) Zip entries alignment
[ https://issues.apache.org/jira/browse/COMPRESS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002836#comment-16002836 ] Zbynek Vyskovsky commented on COMPRESS-391: --- [~bodewig] : Looks like it should work, I think it might make sense to take the length from extra once re-populated but that's fine. I'm also wondering what happens when someone copies the zip stream, it would copy this padding to the output (and potentially add new one if requested), right? That wouldn't make too much sense as the purpose of this field is not really padding but alignment of the stream. When you suggested it, I started thinking more about self-maintaining solution. First step is the same, i.e. creating extra field called FileAlignment (I prefer the name alignment because it better expresses its purpose). That would be encoded as variable length depending on the required padding but two bytes would be mandatory, containing the requested alignment. Therefore it would be possible to read the previously requested alignment from existing zip file and pass it to another one. It would also make sense to assign it some reasonable id as it got some meaning (and maybe send request to add to Zip RFC). The class would still require special handling as there should be just single instance and whenever setAlignment() is called we would have to replace the old instance (actually we wouldn't need setAlignment anymore really but maybe it could be useful if added to common interface and making it reusable across other implementations). As well as it would require special handling during serialization - it should be ignored first when constructing extra fields array, then padding should be added and only then should be appended to extra field. Because of this I feel the original code was actually better as it required special handling only at one place. What are your thoughts? And Sorry I haven't responded earlier, it's more complex and I haven't found time to look at this yet. > Zip entries alignment > - > > Key: COMPRESS-391 > URL: https://issues.apache.org/jira/browse/COMPRESS-391 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.13 >Reporter: Zbynek Vyskovsky > Labels: features, github-import, patch > Fix For: 1.14 > > > Similarly to COMPRESS-390, there are requirements of the zip content to be > mapped directly into memory and therefore may require special alignment on > the embedded files. E.g. libraries may be aligned to page (4096-bytes) > boundary, images on 4-bytes boundary etc. By alignment it's meant the offset > from the beginning of file where the actual data stream starts, not the > header. > One of the cases was (still is?) Android APK for which zipalign utility was > created. > It would be useful if commons-compress ZipArchiveOutputStream supports > something similar directly in its API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002798#comment-16002798
]
Gilles commented on MATH-1417:
--
Have you checked out the git "master" branch?
With your example (and no change to the source), I obtain 4 as the rank value.
> weird result in RRQR decomposition.
> ---
>
> Key: MATH-1417
> URL: https://issues.apache.org/jira/browse/MATH-1417
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: linux RH6
> netbeans 8.2
> java 1.8
>Reporter: Lecomte
>
> When using RRQRDecomposition on rank deficient matrix, results are wrong.
> double[][] Xi = {
> {0, 0, 0, 0, 0, 0, 0, 0, 0},
> {0, 1, 0, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 0, 1, 0, 0, 0, 0, 0},
> {0, 0, 0, 0, 0, 0, 1, 0, 0},
> {0, 0, 0, 0, 0, 0, 0, 0, 0},};
> With this matrix, i obtain:
> rank 6
> R:
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 1,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> Q:
> |0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000|
> Where Scipy (lapack) or ejml gives me:
> rank 4
> Type = dense real , numRows = 9 , numCols = 8
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 -1,000 0,000 -1,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> Type = dense real , numRows = 9 , numCols = 9
> 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000
> That are the results i expect.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002748#comment-16002748
]
Gilles edited comment on MATH-1417 at 5/9/17 2:30 PM:
--
Ok, i got the source.
I'm not a QR specialist. I took a look at the code and I've found what gave me
that weird result.
In performHouseholderReflection:(RRQRDecomposition.java:111), just change
for (int j = 0; j < qrt[i].length; j++) {
(Norm is computed against the whole column )
By
for (int j = minor; j < qrt[i].length; j++) {
(Norm is computed under the current pivot )
In performHouseholderReflection:(QRDecomposition.java:139-143) the norm is
calculated again using the column starting from minor pivot,
then in my case, I have a column whose values are before the diagonal ( then
before the pivot ). This gives a "full norm" that is not null but that is null
beside pivot.
This column is given for computing a reflector but this calculous failed ( a ==
0) because "restricted norm" is null.
If norms are computed always the same manner, the pivoting is ok and the result
is ok in my test case.
Further testing should be done but maybe it can be a quick fix.
Hope this can help.
I'm also surprised to see a test (a!=0) in QR Decomposition with double values.
was (Author: lecomtje):
Ok, i got the source.
I'm not a QR specialist. I took a look at the code and I've found what gave me
that weird result.
In performHouseholderReflection:(RRQRDecomposition.java:111), just change
for (int j = 0; j < qrt[i].length; j++) {
(Norm is computed against the whole column )
By
for (int j = minor; j < qrt[i].length; j++) {
(Norm is computed under the current pivot )
In performHouseholderReflection:(QRDecomposition.java:139-143) the norm is
calculated again using the column starting from minor pivot,
then in my case, I have a column whose values are before the diagonal ( then
before the pivot ). This gives a "full norm" that is not null but that is null
beside pivot.
This column is given for computing a reflector but this calculous failed ( a ==
0) because "restricted norm" is null.
If norms are computed always the same manner, the pivoting is ok and the result
is ok in my test case.
Further testing should be done but maybe it can be a quick fix.
Hope this can help.
I'm also surprised to see a test (a!=0) in QR Decomposition with double values.
-Message d'origine-
De : Gilles (JIRA) [mailto:j...@apache.org]
Envoyé : mardi 9 mai 2017 14:07
À : LECOMTE Jean-Francois
Objet : [jira] [Commented] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002571#comment-16002571
]
Gilles commented on MATH-1417:
--
bq. Is common math easily compiled once i checked it out from git ?
Asumimg that you have "maven" installed, it should just be a matter of running
this command:
{noformat}
mvn compile
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
__
Avant d'imprimer, pensez à l'environnement ! Please consider the environment
before printing !
Ce message et toutes ses pièces jointes sont confidentiels et établis à
l'intention exclusive de ses destinataires. Toute utilisation non conforme à sa
destination, toute diffusion ou toute publication, totale ou partielle, est
interdite, sauf autorisation expresse. IFP Energies nouvelles décline toute
responsabilité au titre de ce message. This message and any attachments are
confidential and intended solely for the addressees. Any unauthorised use or
dissemination is prohibited. IFP Energies nouvelles should not be liable for
this message.
__
> weird result in RRQR decomposition.
> ---
>
> Key: MATH-1417
> URL: https://issues.apache.org/jira/browse/MATH-1417
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: linux RH6
> netbeans 8.2
> java 1.8
>Reporter: Lecomte
>
> When using RRQRDecomposition on rank deficient matrix, results are wrong.
> double[][] Xi = {
> {0, 0, 0, 0, 0, 0, 0, 0, 0},
> {0, 1, 0, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 0, 1, 0, 0, 0, 0, 0},
> {0, 0, 0, 0, 0, 0, 1, 0, 0},
> {0, 0, 0, 0, 0, 0, 0, 0, 0},};
> With this matrix, i obtain:
> rank 6
> R:
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 1,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
>
[jira] [Updated] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lecomte updated MATH-1417:
--
Ok, i got the source.
I'm not a QR specialist. I took a look at the code and I've found what gave me
that weird result.
In performHouseholderReflection:(RRQRDecomposition.java:111), just change
for (int j = 0; j < qrt[i].length; j++) {
(Norm is computed against the whole column )
By
for (int j = minor; j < qrt[i].length; j++) {
(Norm is computed under the current pivot )
In performHouseholderReflection:(QRDecomposition.java:139-143) the norm is
calculated again using the column starting from minor pivot,
then in my case, I have a column whose values are before the diagonal ( then
before the pivot ). This gives a "full norm" that is not null but that is null
beside pivot.
This column is given for computing a reflector but this calculous failed ( a ==
0) because "restricted norm" is null.
If norms are computed always the same manner, the pivoting is ok and the result
is ok in my test case.
Further testing should be done but maybe it can be a quick fix.
Hope this can help.
I'm also surprised to see a test (a!=0) in QR Decomposition with double values.
-Message d'origine-
De : Gilles (JIRA) [mailto:j...@apache.org]
Envoyé : mardi 9 mai 2017 14:07
À : LECOMTE Jean-Francois
Objet : [jira] [Commented] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002571#comment-16002571
]
Gilles commented on MATH-1417:
--
bq. Is common math easily compiled once i checked it out from git ?
Asumimg that you have "maven" installed, it should just be a matter of running
this command:
{noformat}
mvn compile
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
__
Avant d'imprimer, pensez à l'environnement ! Please consider the environment
before printing !
Ce message et toutes ses pièces jointes sont confidentiels et établis à
l'intention exclusive de ses destinataires. Toute utilisation non conforme à sa
destination, toute diffusion ou toute publication, totale ou partielle, est
interdite, sauf autorisation expresse. IFP Energies nouvelles décline toute
responsabilité au titre de ce message. This message and any attachments are
confidential and intended solely for the addressees. Any unauthorised use or
dissemination is prohibited. IFP Energies nouvelles should not be liable for
this message.
__
> weird result in RRQR decomposition.
> ---
>
> Key: MATH-1417
> URL: https://issues.apache.org/jira/browse/MATH-1417
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: linux RH6
> netbeans 8.2
> java 1.8
>Reporter: Lecomte
>
> When using RRQRDecomposition on rank deficient matrix, results are wrong.
> double[][] Xi = {
> {0, 0, 0, 0, 0, 0, 0, 0, 0},
> {0, 1, 0, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 0, 1, 0, 0, 0, 0, 0},
> {0, 0, 0, 0, 0, 0, 1, 0, 0},
> {0, 0, 0, 0, 0, 0, 0, 0, 0},};
> With this matrix, i obtain:
> rank 6
> R:
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 1,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> Q:
> |0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000|
> Where Scipy (lapack) or ejml gives me:
> rank 4
> Type = dense real , numRows = 9 , numCols = 8
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 -1,000 0,000 -1,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000
[jira] [Commented] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002571#comment-16002571
]
Gilles commented on MATH-1417:
--
bq. Is common math easily compiled once i checked it out from git ?
Asumimg that you have "maven" installed, it should just be a matter of running
this command:
{noformat}
mvn compile
{noformat}
> weird result in RRQR decomposition.
> ---
>
> Key: MATH-1417
> URL: https://issues.apache.org/jira/browse/MATH-1417
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: linux RH6
> netbeans 8.2
> java 1.8
>Reporter: Lecomte
>
> When using RRQRDecomposition on rank deficient matrix, results are wrong.
> double[][] Xi = {
> {0, 0, 0, 0, 0, 0, 0, 0, 0},
> {0, 1, 0, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 0, 1, 0, 0, 0, 0, 0},
> {0, 0, 0, 0, 0, 0, 1, 0, 0},
> {0, 0, 0, 0, 0, 0, 0, 0, 0},};
> With this matrix, i obtain:
> rank 6
> R:
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 1,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> Q:
> |0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000|
> Where Scipy (lapack) or ejml gives me:
> rank 4
> Type = dense real , numRows = 9 , numCols = 8
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 -1,000 0,000 -1,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> Type = dense real , numRows = 9 , numCols = 9
> 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000
> That are the results i expect.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002565#comment-16002565
]
Gilles edited comment on MATH-1417 at 5/9/17 12:04 PM:
---
Hi Gilles,
Why not ?
Is common math easily compiled once i checked it out from git ?
Thanks.
Jef
was (Author: lecomtje):
Hi Gilles,
Why not ?
Is common math easily compiled once i checked it out from git ?
Thanks.
Jef
-Message d'origine-
De : Gilles (JIRA) [mailto:j...@apache.org]
Envoyé : mardi 9 mai 2017 12:52
À : LECOMTE Jean-Francois
Objet : [jira] [Commented] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002476#comment-16002476
]
Gilles commented on MATH-1417:
--
Thanks for the report!
Are you willing to dig into the code in order to locate the bug?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
__
Avant d'imprimer, pensez à l'environnement ! Please consider the environment
before printing !
Ce message et toutes ses pièces jointes sont confidentiels et établis à
l'intention exclusive de ses destinataires. Toute utilisation non conforme à sa
destination, toute diffusion ou toute publication, totale ou partielle, est
interdite, sauf autorisation expresse. IFP Energies nouvelles décline toute
responsabilité au titre de ce message. This message and any attachments are
confidential and intended solely for the addressees. Any unauthorised use or
dissemination is prohibited. IFP Energies nouvelles should not be liable for
this message.
__
> weird result in RRQR decomposition.
> ---
>
> Key: MATH-1417
> URL: https://issues.apache.org/jira/browse/MATH-1417
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: linux RH6
> netbeans 8.2
> java 1.8
>Reporter: Lecomte
>
> When using RRQRDecomposition on rank deficient matrix, results are wrong.
> double[][] Xi = {
> {0, 0, 0, 0, 0, 0, 0, 0, 0},
> {0, 1, 0, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 0, 1, 0, 0, 0, 0, 0},
> {0, 0, 0, 0, 0, 0, 1, 0, 0},
> {0, 0, 0, 0, 0, 0, 0, 0, 0},};
> With this matrix, i obtain:
> rank 6
> R:
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 1,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> Q:
> |0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000|
> Where Scipy (lapack) or ejml gives me:
> rank 4
> Type = dense real , numRows = 9 , numCols = 8
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 -1,000 0,000 -1,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> Type = dense real , numRows = 9 , numCols = 9
> 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,0
[jira] [Updated] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lecomte updated MATH-1417:
--
Hi Gilles,
Why not ?
Is common math easily compiled once i checked it out from git ?
Thanks.
Jef
-Message d'origine-
De : Gilles (JIRA) [mailto:j...@apache.org]
Envoyé : mardi 9 mai 2017 12:52
À : LECOMTE Jean-Francois
Objet : [jira] [Commented] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002476#comment-16002476
]
Gilles commented on MATH-1417:
--
Thanks for the report!
Are you willing to dig into the code in order to locate the bug?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
__
Avant d'imprimer, pensez à l'environnement ! Please consider the environment
before printing !
Ce message et toutes ses pièces jointes sont confidentiels et établis à
l'intention exclusive de ses destinataires. Toute utilisation non conforme à sa
destination, toute diffusion ou toute publication, totale ou partielle, est
interdite, sauf autorisation expresse. IFP Energies nouvelles décline toute
responsabilité au titre de ce message. This message and any attachments are
confidential and intended solely for the addressees. Any unauthorised use or
dissemination is prohibited. IFP Energies nouvelles should not be liable for
this message.
__
> weird result in RRQR decomposition.
> ---
>
> Key: MATH-1417
> URL: https://issues.apache.org/jira/browse/MATH-1417
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: linux RH6
> netbeans 8.2
> java 1.8
>Reporter: Lecomte
>
> When using RRQRDecomposition on rank deficient matrix, results are wrong.
> double[][] Xi = {
> {0, 0, 0, 0, 0, 0, 0, 0, 0},
> {0, 1, 0, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 0, 1, 0, 0, 0, 0, 0},
> {0, 0, 0, 0, 0, 0, 1, 0, 0},
> {0, 0, 0, 0, 0, 0, 0, 0, 0},};
> With this matrix, i obtain:
> rank 6
> R:
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 1,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> Q:
> |0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000|
> Where Scipy (lapack) or ejml gives me:
> rank 4
> Type = dense real , numRows = 9 , numCols = 8
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 -1,000 0,000 -1,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> Type = dense real , numRows = 9 , numCols = 9
> 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000
> That are the results i expect.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1401) Exception at IntervalUtils.getClopperPearsonInterval
[
https://issues.apache.org/jira/browse/MATH-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002564#comment-16002564
]
Bruno P. Kinoshita commented on MATH-1401:
--
Here are the results with R PropCIs:
{noformat}
data:
95 percent confidence interval:
0.000 0.975
> exactci(n=1, x=0, 0.95)
data:
95 percent confidence interval:
0.000 0.975
> exactci(n=1, x=1, 0.95)
data:
95 percent confidence interval:
0.025 1.000
>
{noformat}
> Exception at IntervalUtils.getClopperPearsonInterval
>
>
> Key: MATH-1401
> URL: https://issues.apache.org/jira/browse/MATH-1401
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Art
>Assignee: Bruno P. Kinoshita
> Fix For: 4.0
>
>
> IntervalUtils.getClopperPearsonInterval throws an exception when number of
> successes equals to zero or number of successes = number of trials.
> IntervalUtils.getClopperPearsonInterval(1, 0, 0.95) or
> IntervalUtils.getClopperPearsonInterval(1, 1, 0.95) throws
> org.apache.commons.math3.exception.NotStrictlyPositiveException despite that
> its input parameters are valid.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (NUMBERS-36) mathjax CDN shutting down - will soon break javadoc
[
https://issues.apache.org/jira/browse/NUMBERS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved NUMBERS-36.
Resolution: Fixed
Fix Version/s: 1.0
> mathjax CDN shutting down - will soon break javadoc
> ---
>
> Key: NUMBERS-36
> URL: https://issues.apache.org/jira/browse/NUMBERS-36
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
> Fix For: 1.0
>
>
> Javadoc for Commons Math, Commons Numbers and friends use a the
> [MathJax|https://www.mathjax.org/] Javascript in order to render LaTeX
> equation within Javadoc. (See MATH-1006)
> This used to be included as
> http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML
> -- but now [cdn.mathjax.org is shutting
> down|https://www.mathjax.org/cdn-shutting-down/]. There is a temporary
> redirect.
> There are several alternatives suggested, with the recommended being:
> {code}
>src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?...";>
>
> {code}
> Other alternatives include rawgit.com - e.g.
> https://cdn.rawgit.com/mathjax/MathJax/2.7.1/MathJax.js with a fixed version
> - which is probably a good thing. I've tried this approach for Commons
> Numbers, which seems to work -- not sure if adding
> {{?config=TeX-AMS-MML_HTMLorMML}} would make any difference there as rawgit
> caches the file directly from GitHub.
> Of course the MathJax javascript is Apache-licensed, so we could easily embed
> it in the ASF source code - but then in multi-module projects I wonder if we
> would then need to share it across all modules.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-36) mathjax CDN shutting down - will soon break javadoc
[
https://issues.apache.org/jira/browse/NUMBERS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002501#comment-16002501
]
Stian Soiland-Reyes commented on NUMBERS-36:
Sorry, it seems just {{MathJax.js}} is insufficient as it will try to load
various other resources by relative paths.
For reference, in theory we could include the whole MathJax distribution
repackaged into Maven artifacts from http://www.webjars.org/, by modifying
{{maven-javadoc-plugin}} to:
{code:xml}
org.apache.maven.plugins
maven-javadoc-plugin
-Xdoclint:all --allow-script-in-comments
-header ''
org.webjars.npm
mathjax
2.7.0
{code}
However this doesn't work, as for compatibility with WAR, webjars have folders
like {{META-INF/resources/webjars/mathjax/2.7.0}}, but {{maven-javadoc-plugin}}
sadly [ignores
META-INF|https://github.com/apache/maven-plugins/blob/a9566e14f980ff52f3ee3c89d64d6b98b03c0305/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java#L4234].
Another problem is that the mathjax JAR is 23 MB (it is also the complete git
source tree), which in our case would be embedded within each of the module's
Javadoc folders, and also within the javadoc.jar (if we add that javadoc config
to {{}})
So -- sorry for this disgression - I think I will change my opinion to go with
the new official CDN hosted at
https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js (as currently
committed on master).
> mathjax CDN shutting down - will soon break javadoc
> ---
>
> Key: NUMBERS-36
> URL: https://issues.apache.org/jira/browse/NUMBERS-36
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>
> Javadoc for Commons Math, Commons Numbers and friends use a the
> [MathJax|https://www.mathjax.org/] Javascript in order to render LaTeX
> equation within Javadoc. (See MATH-1006)
> This used to be included as
> http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML
> -- but now [cdn.mathjax.org is shutting
> down|https://www.mathjax.org/cdn-shutting-down/]. There is a temporary
> redirect.
> There are several alternatives suggested, with the recommended being:
> {code}
>src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?...";>
>
> {code}
> Other alternatives include rawgit.com - e.g.
> https://cdn.rawgit.com/mathjax/MathJax/2.7.1/MathJax.js with a fixed version
> - which is probably a good thing. I've tried this approach for Commons
> Numbers, which seems to work -- not sure if adding
> {{?config=TeX-AMS-MML_HTMLorMML}} would make any difference there as rawgit
> caches the file directly from GitHub.
> Of course the MathJax javascript is Apache-licensed, so we could easily embed
> it in the ASF source code - but then in multi-module projects I wonder if we
> would then need to share it across all modules.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1401) Exception at IntervalUtils.getClopperPearsonInterval
[
https://issues.apache.org/jira/browse/MATH-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002481#comment-16002481
]
Bruno P. Kinoshita commented on MATH-1401:
--
Found a better paper explaining it (A. Boomsma, "Confidence Intervals for a
Binomial Proportion" link: http://www.ppsw.rug.nl/~boomsma/confbin.pdf).
{quote}
For x = 0, the lower limit r1 = 0, because the upper limit ru satisfies the
equality (1 - ru) ^n = alpha / 2, from which it follows that ru = 1 - (alpha /
2) ^ 1/n.
For x = n, the upper limit ru = 1, because the lower limit satisfies r = alpha
/ 2, which makes r = (alpha / 2) ^ 1/n.
{quote}
Which matches exactly with the R implementation. I will update the code, and
run some codes for this Case #1. In case it works, will report back here and
focus on Case #2 (which could be automatically fixed by fixing Case#1 I
think...).
> Exception at IntervalUtils.getClopperPearsonInterval
>
>
> Key: MATH-1401
> URL: https://issues.apache.org/jira/browse/MATH-1401
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Art
>Assignee: Bruno P. Kinoshita
> Fix For: 4.0
>
>
> IntervalUtils.getClopperPearsonInterval throws an exception when number of
> successes equals to zero or number of successes = number of trials.
> IntervalUtils.getClopperPearsonInterval(1, 0, 0.95) or
> IntervalUtils.getClopperPearsonInterval(1, 1, 0.95) throws
> org.apache.commons.math3.exception.NotStrictlyPositiveException despite that
> its input parameters are valid.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1417) weird result in RRQR decomposition.
[
https://issues.apache.org/jira/browse/MATH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002476#comment-16002476
]
Gilles commented on MATH-1417:
--
Thanks for the report!
Are you willing to dig into the code in order to locate the bug?
> weird result in RRQR decomposition.
> ---
>
> Key: MATH-1417
> URL: https://issues.apache.org/jira/browse/MATH-1417
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: linux RH6
> netbeans 8.2
> java 1.8
>Reporter: Lecomte
>
> When using RRQRDecomposition on rank deficient matrix, results are wrong.
> double[][] Xi = {
> {0, 0, 0, 0, 0, 0, 0, 0, 0},
> {0, 1, 0, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 1, 0, 0, 0, 0, 0, 0},
> {0, 0, 0, 1, 0, 0, 0, 0, 0},
> {0, 0, 0, 0, 0, 0, 1, 0, 0},
> {0, 0, 0, 0, 0, 0, 0, 0, 0},};
> With this matrix, i obtain:
> rank 6
> R:
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 1,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> Q:
> |0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000|
> |0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000|
> Where Scipy (lapack) or ejml gives me:
> rank 4
> Type = dense real , numRows = 9 , numCols = 8
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 -1,000 0,000 -1,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> Type = dense real , numRows = 9 , numCols = 9
> 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000
> -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000
> 0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000
> 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000
> That are the results i expect.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-36) mathjax CDN shutting down - will soon break javadoc
[
https://issues.apache.org/jira/browse/NUMBERS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002467#comment-16002467
]
Gilles commented on NUMBERS-36:
---
bq. [install locally] Agreed?
Sure. Thanks for working on that.
What is {noformat}{@docRoot}{noformat}?
> mathjax CDN shutting down - will soon break javadoc
> ---
>
> Key: NUMBERS-36
> URL: https://issues.apache.org/jira/browse/NUMBERS-36
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>
> Javadoc for Commons Math, Commons Numbers and friends use a the
> [MathJax|https://www.mathjax.org/] Javascript in order to render LaTeX
> equation within Javadoc. (See MATH-1006)
> This used to be included as
> http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML
> -- but now [cdn.mathjax.org is shutting
> down|https://www.mathjax.org/cdn-shutting-down/]. There is a temporary
> redirect.
> There are several alternatives suggested, with the recommended being:
> {code}
>src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?...";>
>
> {code}
> Other alternatives include rawgit.com - e.g.
> https://cdn.rawgit.com/mathjax/MathJax/2.7.1/MathJax.js with a fixed version
> - which is probably a good thing. I've tried this approach for Commons
> Numbers, which seems to work -- not sure if adding
> {{?config=TeX-AMS-MML_HTMLorMML}} would make any difference there as rawgit
> caches the file directly from GitHub.
> Of course the MathJax javascript is Apache-licensed, so we could easily embed
> it in the ASF source code - but then in multi-module projects I wonder if we
> would then need to share it across all modules.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-36) mathjax CDN shutting down - will soon break javadoc
[
https://issues.apache.org/jira/browse/NUMBERS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002456#comment-16002456
]
Stian Soiland-Reyes commented on NUMBERS-36:
I guess ideally the MathJax.js should be included, that means we don't rely on
the third-party CDN and avoid any firewall/security concerns for anyone else
hosting the JavaDoc.
This seems to work across the modules:
{code:xml}
org.apache.maven.plugins
maven-javadoc-plugin
-Xdoclint:all --allow-script-in-comments
-header ''
${numbers.parent.dir}/src/main/javadoc
true
{code}
And then a single file {{src/main/javadoc/resources/MathJax.js}}
Agreed? It would have to be replaced from mathjax.org in{{src/main/javadoc}}
when a new MathJax is needed - but the CDN approach would also require version
within URL to be updated.
Another advantage is that if then the javascript will also be embedded in the
javadoc.jar (note however that Eclipse don't render with Javascript)
> mathjax CDN shutting down - will soon break javadoc
> ---
>
> Key: NUMBERS-36
> URL: https://issues.apache.org/jira/browse/NUMBERS-36
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>
> Javadoc for Commons Math, Commons Numbers and friends use a the
> [MathJax|https://www.mathjax.org/] Javascript in order to render LaTeX
> equation within Javadoc. (See MATH-1006)
> This used to be included as
> http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML
> -- but now [cdn.mathjax.org is shutting
> down|https://www.mathjax.org/cdn-shutting-down/]. There is a temporary
> redirect.
> There are several alternatives suggested, with the recommended being:
> {code}
>src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?...";>
>
> {code}
> Other alternatives include rawgit.com - e.g.
> https://cdn.rawgit.com/mathjax/MathJax/2.7.1/MathJax.js with a fixed version
> - which is probably a good thing. I've tried this approach for Commons
> Numbers, which seems to work -- not sure if adding
> {{?config=TeX-AMS-MML_HTMLorMML}} would make any difference there as rawgit
> caches the file directly from GitHub.
> Of course the MathJax javascript is Apache-licensed, so we could easily embed
> it in the ASF source code - but then in multi-module projects I wonder if we
> would then need to share it across all modules.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1401) Exception at IntervalUtils.getClopperPearsonInterval
[ https://issues.apache.org/jira/browse/MATH-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002454#comment-16002454 ] Bruno P. Kinoshita commented on MATH-1401: -- Continuing on case #1, [this PDF|http://www.lexjansen.com/phuse/2013/sp/SP05.pdf] mentions that "The lower bound is set to 0 when x = 0, and the upp er bound is set to 1 when x = n. ". These are exact variable names in the R library, and this is exactly what is happening. There is still the matter that the calculation is different when x >0 and x != n. > Exception at IntervalUtils.getClopperPearsonInterval > > > Key: MATH-1401 > URL: https://issues.apache.org/jira/browse/MATH-1401 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Art >Assignee: Bruno P. Kinoshita > Fix For: 4.0 > > > IntervalUtils.getClopperPearsonInterval throws an exception when number of > successes equals to zero or number of successes = number of trials. > IntervalUtils.getClopperPearsonInterval(1, 0, 0.95) or > IntervalUtils.getClopperPearsonInterval(1, 1, 0.95) throws > org.apache.commons.math3.exception.NotStrictlyPositiveException despite that > its input parameters are valid. > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MATH-1401) Exception at IntervalUtils.getClopperPearsonInterval
[
https://issues.apache.org/jira/browse/MATH-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002447#comment-16002447
]
Bruno P. Kinoshita commented on MATH-1401:
--
To make it easier, will start naming the two cases we have. Case #1 is the one
I had some time to study today, and is when **number of successes is equals
zero**. And Case #2 is where **number of successes is equal to the number of
trials".
The exception is raised
[here|https://github.com/apache/commons-math/blob/20403f09bfe6f06626cd1253042b848e38f038fd/src/main/java/org/apache/commons/math4/stat/interval/ConfidenceInterval.java#L101]:
{code}
# class: ConfidenceInterval
/**
* Verifies that (lower, upper) is a valid non-empty interval and confidence
* is strictly between 0 and 1.
*
* @param lower lower endpoint
* @param upper upper endpoint
* @param confidence confidence level
*/
private void checkParameters(double lower, double upper, double confidence)
{
if (lower >= upper) { <-- HERE, both are 0 <=> 0
throw new
MathIllegalArgumentException(LocalizedFormats.LOWER_BOUND_NOT_BELOW_UPPER_BOUND,
lower, upper);
}
if (confidence <= 0 || confidence >= 1) {
throw new
MathIllegalArgumentException(LocalizedFormats.OUT_OF_BOUNDS_CONFIDENCE_LEVEL,
confidence, 0, 1);
}
}
{code}
The code is checking if the confidence interval lower and upper bounds are
different. The [R
code|https://artax.karlin.mff.cuni.cz/r-help/library/PropCIs/html/exactci.html]
handles three cases, when the number of successes is zero, when the number of
successes and trials is the same, and the case where both previous constraints
are not true.
Our code in ClopperPearsonInterval checks if the number of successes is greater
than 0 only. Then returns a ConfidenceInterval object.
My current guess is that by understanding why the R code is treating these
three cases, we may be able to confirm if it makes sense adding some if/else
for these constraints in our Java code too.
> Exception at IntervalUtils.getClopperPearsonInterval
>
>
> Key: MATH-1401
> URL: https://issues.apache.org/jira/browse/MATH-1401
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Art
>Assignee: Bruno P. Kinoshita
> Fix For: 4.0
>
>
> IntervalUtils.getClopperPearsonInterval throws an exception when number of
> successes equals to zero or number of successes = number of trials.
> IntervalUtils.getClopperPearsonInterval(1, 0, 0.95) or
> IntervalUtils.getClopperPearsonInterval(1, 1, 0.95) throws
> org.apache.commons.math3.exception.NotStrictlyPositiveException despite that
> its input parameters are valid.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (NUMBERS-36) mathjax CDN shutting down - will soon break javadoc
Stian Soiland-Reyes created NUMBERS-36:
--
Summary: mathjax CDN shutting down - will soon break javadoc
Key: NUMBERS-36
URL: https://issues.apache.org/jira/browse/NUMBERS-36
Project: Commons Numbers
Issue Type: Bug
Reporter: Stian Soiland-Reyes
Assignee: Stian Soiland-Reyes
Javadoc for Commons Math, Commons Numbers and friends use a the
[MathJax|https://www.mathjax.org/] Javascript in order to render LaTeX equation
within Javadoc. (See MATH-1006)
This used to be included as
http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML
-- but now [cdn.mathjax.org is shutting
down|https://www.mathjax.org/cdn-shutting-down/]. There is a temporary redirect.
There are several alternatives suggested, with the recommended being:
{code}
https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?...";>
{code}
Other alternatives include rawgit.com - e.g.
https://cdn.rawgit.com/mathjax/MathJax/2.7.1/MathJax.js with a fixed version -
which is probably a good thing. I've tried this approach for Commons Numbers,
which seems to work -- not sure if adding {{?config=TeX-AMS-MML_HTMLorMML}}
would make any difference there as rawgit caches the file directly from GitHub.
Of course the MathJax javascript is Apache-licensed, so we could easily embed
it in the ASF source code - but then in multi-module projects I wonder if we
would then need to share it across all modules.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MATH-1417) weird result in RRQR decomposition.
Lecomte created MATH-1417:
-
Summary: weird result in RRQR decomposition.
Key: MATH-1417
URL: https://issues.apache.org/jira/browse/MATH-1417
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.6.1
Environment: linux RH6
netbeans 8.2
java 1.8
Reporter: Lecomte
When using RRQRDecomposition on rank deficient matrix, results are wrong.
double[][] Xi = {
{0, 0, 0, 0, 0, 0, 0, 0, 0},
{0, 1, 0, 0, 0, 0, 0, 0, 0},
{0, 0, 1, 0, 0, 0, 0, 0, 0},
{0, 0, 1, 0, 0, 0, 0, 0, 0},
{0, 0, 1, 0, 0, 0, 0, 0, 0},
{0, 0, 0, 1, 0, 0, 0, 0, 0},
{0, 0, 0, 0, 0, 0, 1, 0, 0},
{0, 0, 0, 0, 0, 0, 0, 0, 0},};
With this matrix, i obtain:
rank 6
R:
|1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
|0,000 1,000 1,000 1,000 0,000 0,000 0,000 0,000|
|0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
|0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
|0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
|0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
|0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
|0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
|0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
Q:
|0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000|
|1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
|0,000 1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000|
|0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000 0,000|
|0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000|
|0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000|
|0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000|
|0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000|
|0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000|
Where Scipy (lapack) or ejml gives me:
rank 4
Type = dense real , numRows = 9 , numCols = 8
-1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
0,000 -1,000 0,000 0,000 -1,000 0,000 -1,000 0,000
0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000
0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
Type = dense real , numRows = 9 , numCols = 9
0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000
-1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000
0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000 0,000
0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000 0,000
0,000 0,000 0,000 0,000 0,000 1,000 0,000 0,000 0,000
0,000 0,000 0,000 -1,000 0,000 0,000 0,000 0,000 0,000
0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000 0,000
0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 1,000
That are the results i expect.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-391) Zip entries alignment
[ https://issues.apache.org/jira/browse/COMPRESS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002215#comment-16002215 ] ASF GitHub Bot commented on COMPRESS-391: - Github user bodewig commented on the issue: https://github.com/apache/commons-compress/pull/24 @kvr000 what do you think about https://github.com/apache/commons-compress/commit/620196621e15a87cdd5e3382504bd8a9829f4698 ? > Zip entries alignment > - > > Key: COMPRESS-391 > URL: https://issues.apache.org/jira/browse/COMPRESS-391 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.13 >Reporter: Zbynek Vyskovsky > Labels: features, github-import, patch > Fix For: 1.14 > > > Similarly to COMPRESS-390, there are requirements of the zip content to be > mapped directly into memory and therefore may require special alignment on > the embedded files. E.g. libraries may be aligned to page (4096-bytes) > boundary, images on 4-bytes boundary etc. By alignment it's meant the offset > from the beginning of file where the actual data stream starts, not the > header. > One of the cases was (still is?) Android APK for which zipalign utility was > created. > It would be useful if commons-compress ZipArchiveOutputStream supports > something similar directly in its API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
