[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814024#comment-16814024
]
Matt Juntunen commented on GEOMETRY-32:
---
Update:
I now have the general BSP/region code in place and tested in the
{{commons-geometry-core}} module (including transforms and boolean operations)
and I'm working on updating the concrete implementations in
{{commons-geometry-euclidean}}. I'm about halfway through {{oned}} so far.
Here's some example code for creating a region with two disjoint intervals:
{code:java}
DoublePrecisionContext precision = new EpsilonDoublePrecisionContext(1e-6);
Interval intervalA = Interval.of(1, 2, precision);
Interval intervalB = Interval.of(3, 4, precision);
intervalA.contains(Vector1D.of(1.5)); // true
intervalB.contains(Vector1D.of(3.5)); // true
RegionBSPTree1D tree = intervalA.toTree();
tree.union(intervalB.toTree());
tree.contains(Vector1D.of(1.5)); // true
tree.contains(Vector1D.of(3.5)); // true
tree.contains(Vector1D.of(2.5)); // false
{code}
> BSPTree Updates
> ---
>
> Key: GEOMETRY-32
> URL: https://issues.apache.org/jira/browse/GEOMETRY-32
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Components: core
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following updates should be made to the BSPTree class:
> - add an {{isLeaf()}} method to replace all of the {{node.getCut() == null}}
> expressions
> - add unit tests
> _Edit [2019-02-17]:_
> Additional goals:
> - Refactor the API to split the idea of a general BSPTree and a BSPTree used
> for defining in/out regions. This could result in a BSPTree interface and a
> RegionBSPTree interface. The goal here is to allow end-users to create their
> own extensions of these classes and specialize them for their own
> applications (for example, to implement spatial sorting or other algorithms).
> This will be one of the only planned extension points in the library.
> - Make the API easier to use and extend and reduce the necessity of casting
> (especially unchecked casting) as much as possible.
> - Add the idea of convex subhyperplanes to allow for more efficient tree
> construction.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-geometry] darkma773r commented on issue #29: GEOMETRY-32 adds BSPTree.isLeaf, applies method to node.getCut() == n…
darkma773r commented on issue #29: GEOMETRY-32 adds BSPTree.isLeaf, applies method to node.getCut() == n… URL: https://github.com/apache/commons-geometry/pull/29#issuecomment-481509585 This is now out of date. Can you close this? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-geometry] darkma773r commented on issue #28: GEOMETRY-43 adds some helper to plane: isOnPlane, isParallel, getOffs…
darkma773r commented on issue #28: GEOMETRY-43 adds some helper to plane: isOnPlane, isParallel, getOffs… URL: https://github.com/apache/commons-geometry/pull/28#issuecomment-481509615 This is now out of date. Can you close this? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (CSV-227) first column always quoting when multilingual language, when not on second column
[
https://issues.apache.org/jira/browse/CSV-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813984#comment-16813984
]
Jisun, Shin commented on CSV-227:
-
Sorry, I did not explain it enough.
I want to strip quotes.
So. set "QuoteMode.MINIMAL".
And after second column, i works. but first column doesn't.
> first column always quoting when multilingual language, when not on second
> column
> -
>
> Key: CSV-227
> URL: https://issues.apache.org/jira/browse/CSV-227
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.5
>Reporter: Jisun, Shin
>Priority: Major
>
> when including multilingual character (utf-8 encoding),
> CSVPrinter always quote only first column, not other columns.
>
> {code:java}
> // example code
> CSVFormat format = CSVFormat.DEFAULT.withQuoteMode(QuoteMode.MINIMAL);
> CSVPrinter printer = new CSVPrinter(System.out, format);
> List temp = new ArrayList();
> temp.add(new String[] { "ㅁㅎㄷㄹ", "ㅁㅎㄷㄹ", "", "test2" });
> temp.add(new String[] { "한글3", "hello3", "3한글3", "test3" });
> temp.add(new String[] { "", "hello4", "", "test4" });
> for (String[] temp1 : temp) {
> printer.printRecord(temp1);
> }
> printer.close();
> {code}
>
> result =>
> "ㅁㅎㄷㄹ",ㅁㅎㄷㄹ,,test2
> "한글3",hello3,3한글3,test3
> "",hello4,,test4
>
> i found the code.
> multilingual charaters are out of 0x7E. first record and multilinguage
> always print quotes.
>
> {code:java}
> // CSVFormat.class
> ...
> 1173: char c = value.charAt(pos);
> 1174:
> 1175: // RFC4180 (https://tools.ietf.org/html/rfc4180) TEXTDATA = %x20-21 /
> %x23-2B / %x2D-7E
> 1176: if (newRecord && (c < 0x20 || c > 0x21 && c < 0x23 || c > 0x2B && c <
> 0x2D || c > 0x7E)) {
> 1177: quote = true;
> 1178: } else if (c <= COMMENT) {
> ...{code}
>
> would you fix this bug?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-29) Plane API cleanup
[
https://issues.apache.org/jira/browse/GEOMETRY-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813974#comment-16813974
]
Matt Juntunen commented on GEOMETRY-29:
---
{quote}A user guide would be welcome...
{quote}
Is this a blocker?
> Plane API cleanup
> -
>
> Key: GEOMETRY-29
> URL: https://issues.apache.org/jira/browse/GEOMETRY-29
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> The following changes should be made to the
> {{o.a.c.g.euclidean.threed.Plane}} class:
> * make the class immutable
> * use well-named factory methods instead of constructor overloads
> * provide a factory method to create a plane with user-supplied {{u}} and
> {{v}} axes. The current implementation allows the normal to be provided but
> chooses its own planar axes (see {{setFrame}}).
> * add {{equals}}, {{hashCode}}, and {{toString}} methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-29) Plane API cleanup
[
https://issues.apache.org/jira/browse/GEOMETRY-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813965#comment-16813965
]
Gilles commented on GEOMETRY-29:
No. I'm looking from afar, and I mostly rely on you until I'll get a chance to
practically test some of this. ;-)
A user guide would be welcome...
> Plane API cleanup
> -
>
> Key: GEOMETRY-29
> URL: https://issues.apache.org/jira/browse/GEOMETRY-29
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> The following changes should be made to the
> {{o.a.c.g.euclidean.threed.Plane}} class:
> * make the class immutable
> * use well-named factory methods instead of constructor overloads
> * provide a factory method to create a plane with user-supplied {{u}} and
> {{v}} axes. The current implementation allows the normal to be provided but
> chooses its own planar axes (see {{setFrame}}).
> * add {{equals}}, {{hashCode}}, and {{toString}} methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-29) Plane API cleanup
[
https://issues.apache.org/jira/browse/GEOMETRY-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813961#comment-16813961
]
Matt Juntunen commented on GEOMETRY-29:
---
Sounds good. [~rathgeber], could you make those last changes?
- make {{origin}} computed instead of stored
- make {{areCoplanar}} a private helper method in {{Plane}} (The reasoning
behind this is to try to keep the public API small and maintainable as a
general rule and only add methods if required. It's easier by far to add things
later than to remove them.)
[~erans], is there anything that might prevent you from merging this after the
above items are complete?
> Plane API cleanup
> -
>
> Key: GEOMETRY-29
> URL: https://issues.apache.org/jira/browse/GEOMETRY-29
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> The following changes should be made to the
> {{o.a.c.g.euclidean.threed.Plane}} class:
> * make the class immutable
> * use well-named factory methods instead of constructor overloads
> * provide a factory method to create a plane with user-supplied {{u}} and
> {{v}} axes. The current implementation allows the normal to be provided but
> chooses its own planar axes (see {{setFrame}}).
> * add {{equals}}, {{hashCode}}, and {{toString}} methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (MATH-1477) MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with variablesToInclude parameter
[ https://issues.apache.org/jira/browse/MATH-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-1477. -- Resolution: Fixed Fix Version/s: 4.0 PR merged (commit 8694f8478bed676c9bb13a3a9a6e2eca56029c95 in "master"). Thanks. > MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with > variablesToInclude parameter > -- > > Key: MATH-1477 > URL: https://issues.apache.org/jira/browse/MATH-1477 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Chee Sing Lee >Priority: Major > Labels: easyfix, newbie, patch > Fix For: 4.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When performing a regression with a subset of predictors, an > ArrayIndexOutOfBounds exception will occur for certain subset selections. For > example, this appears to happen consistently for regressions without a > constant term when the predictor at index 0 is not selected. > I do not understand at all the algorithm used to reorder the predictors when > a subset is requested, but the fix appears to be a simple correction to the > indexing range in the for-loop in the regress method of > MillerUpdatingRegression.java. > > Patch with expanded unit test to follow shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (MATH-1477) MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with variablesToInclude parameter
[ https://issues.apache.org/jira/browse/MATH-1477?focusedWorklogId=225371=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-225371 ] ASF GitHub Bot logged work on MATH-1477: Author: ASF GitHub Bot Created on: 10/Apr/19 01:17 Start Date: 10/Apr/19 01:17 Worklog Time Spent: 10m Work Description: asfgit commented on pull request #104: MATH-1477: fix reordering check in MillerUpdatingRegression.regress URL: https://github.com/apache/commons-math/pull/104 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 225371) Time Spent: 0.5h (was: 20m) > MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with > variablesToInclude parameter > -- > > Key: MATH-1477 > URL: https://issues.apache.org/jira/browse/MATH-1477 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Chee Sing Lee >Priority: Major > Labels: easyfix, newbie, patch > Time Spent: 0.5h > Remaining Estimate: 0h > > When performing a regression with a subset of predictors, an > ArrayIndexOutOfBounds exception will occur for certain subset selections. For > example, this appears to happen consistently for regressions without a > constant term when the predictor at index 0 is not selected. > I do not understand at all the algorithm used to reorder the predictors when > a subset is requested, but the fix appears to be a simple correction to the > indexing range in the for-loop in the regress method of > MillerUpdatingRegression.java. > > Patch with expanded unit test to follow shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-math] asfgit merged pull request #104: MATH-1477: fix reordering check in MillerUpdatingRegression.regress
asfgit merged pull request #104: MATH-1477: fix reordering check in MillerUpdatingRegression.regress URL: https://github.com/apache/commons-math/pull/104 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MATH-1478) Overflow in Vector norm and distance
[
https://issues.apache.org/jira/browse/MATH-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813913#comment-16813913
]
Gilles commented on MATH-1478:
--
Thanks for the report!
However, package {{org.apache.commons.math4.geometry}} is in the process of
being ported and refactored into a [new to
component|http://commons.apache.org/proper/commons-geometry/].
Could you please report this issue to [its JIRA
project|https://issues.apache.org/jira/projects/GEOMETRY]?
A patch/PR to fix the problem [over
there|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=blob;f=commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/internal/Vectors.java;h=fa5cc8f089984887da36950962d34710ea91c60d;hb=HEAD#l98]
is most welcome.
> Overflow in Vector norm and distance
>
>
> Key: MATH-1478
> URL: https://issues.apache.org/jira/browse/MATH-1478
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: Baljit Singh
>Priority: Major
>
> In Euclidean Vector classes (Vector2D, Vector3D), getNorm() and distance()
> rely on FastMath.sqrt(), which can overflow if the components of the vectors
> are large. Instead, they should rely on FastMath.hypot(). For Vector3D, this
> would also mean developing FastMath.hypot(double, double, double), which is
> equivalent to FastMath.hypot(double, double), but with 3 (or N) arguments.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MATH-1478) Overflow in Vector norm and distance
[ https://issues.apache.org/jira/browse/MATH-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Baljit Singh updated MATH-1478: --- Description: In Euclidean Vector classes (Vector2D, Vector3D), getNorm() and distance() rely on FastMath.sqrt(), which can overflow if the components of the vectors are large. Instead, they should rely on FastMath.hypot(). For Vector3D, this would also mean developing FastMath.hypot(double, double, double), which is equivalent to FastMath.hypot(double, double), but with 3 (or N) arguments. (was: In Euclidean Vector classes (Vector2D, Vector3D), getNorm() and distance() rely on FastMath.sqrt(), which can overflow if the components of the vectors are large. Instead, they should rely on FastMath.hypot(double, double, double), which is equivalent to FastMath.hypot(double, double), but with 3 (or N) arguments.) > Overflow in Vector norm and distance > > > Key: MATH-1478 > URL: https://issues.apache.org/jira/browse/MATH-1478 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Baljit Singh >Priority: Minor > > In Euclidean Vector classes (Vector2D, Vector3D), getNorm() and distance() > rely on FastMath.sqrt(), which can overflow if the components of the vectors > are large. Instead, they should rely on FastMath.hypot(). For Vector3D, this > would also mean developing FastMath.hypot(double, double, double), which is > equivalent to FastMath.hypot(double, double), but with 3 (or N) arguments. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MATH-1478) Overflow in Vector norm and distance
[ https://issues.apache.org/jira/browse/MATH-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Baljit Singh updated MATH-1478: --- Priority: Major (was: Minor) > Overflow in Vector norm and distance > > > Key: MATH-1478 > URL: https://issues.apache.org/jira/browse/MATH-1478 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Baljit Singh >Priority: Major > > In Euclidean Vector classes (Vector2D, Vector3D), getNorm() and distance() > rely on FastMath.sqrt(), which can overflow if the components of the vectors > are large. Instead, they should rely on FastMath.hypot(). For Vector3D, this > would also mean developing FastMath.hypot(double, double, double), which is > equivalent to FastMath.hypot(double, double), but with 3 (or N) arguments. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MATH-1478) Overflow in Vector norm and distance
[ https://issues.apache.org/jira/browse/MATH-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Baljit Singh updated MATH-1478: --- Affects Version/s: 3.6.1 > Overflow in Vector norm and distance > > > Key: MATH-1478 > URL: https://issues.apache.org/jira/browse/MATH-1478 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Baljit Singh >Priority: Minor > > In Euclidean Vector classes (Vector2D, Vector3D), getNorm() and distance() > rely on FastMath.sqrt(), which can overflow if the components of the vectors > are large. Instead, they should rely on FastMath.hypot(double, double, > double), which is equivalent to FastMath.hypot(double, double), but with 3 > (or N) arguments. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MATH-1478) Overflow in Vector norm and distance
Baljit Singh created MATH-1478: -- Summary: Overflow in Vector norm and distance Key: MATH-1478 URL: https://issues.apache.org/jira/browse/MATH-1478 Project: Commons Math Issue Type: Improvement Reporter: Baljit Singh In Euclidean Vector classes (Vector2D, Vector3D), getNorm() and distance() rely on FastMath.sqrt(), which can overflow if the components of the vectors are large. Instead, they should rely on FastMath.hypot(double, double, double), which is equivalent to FastMath.hypot(double, double), but with 3 (or N) arguments. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (MATH-1477) MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with variablesToInclude parameter
[ https://issues.apache.org/jira/browse/MATH-1477?focusedWorklogId=225217=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-225217 ] ASF GitHub Bot logged work on MATH-1477: Author: ASF GitHub Bot Created on: 09/Apr/19 19:06 Start Date: 09/Apr/19 19:06 Worklog Time Spent: 10m Work Description: coveralls commented on issue #104: MATH-1477: fix reordering check in MillerUpdatingRegression.regress URL: https://github.com/apache/commons-math/pull/104#issuecomment-481394696 [](https://coveralls.io/builds/22703187) Coverage decreased (-0.002%) to 90.175% when pulling **55fbf2dc6e85c63fbfb8693789ec45d44f4976d5 on cheesinglee:bug-MATH-1477** into **286ab7c6dd4c4aae0b0290517ea3508487438d01 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 225217) Time Spent: 20m (was: 10m) > MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with > variablesToInclude parameter > -- > > Key: MATH-1477 > URL: https://issues.apache.org/jira/browse/MATH-1477 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Chee Sing Lee >Priority: Major > Labels: easyfix, newbie, patch > Time Spent: 20m > Remaining Estimate: 0h > > When performing a regression with a subset of predictors, an > ArrayIndexOutOfBounds exception will occur for certain subset selections. For > example, this appears to happen consistently for regressions without a > constant term when the predictor at index 0 is not selected. > I do not understand at all the algorithm used to reorder the predictors when > a subset is requested, but the fix appears to be a simple correction to the > indexing range in the for-loop in the regress method of > MillerUpdatingRegression.java. > > Patch with expanded unit test to follow shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-math] coveralls commented on issue #104: MATH-1477: fix reordering check in MillerUpdatingRegression.regress
coveralls commented on issue #104: MATH-1477: fix reordering check in MillerUpdatingRegression.regress URL: https://github.com/apache/commons-math/pull/104#issuecomment-481394696 [](https://coveralls.io/builds/22703187) Coverage decreased (-0.002%) to 90.175% when pulling **55fbf2dc6e85c63fbfb8693789ec45d44f4976d5 on cheesinglee:bug-MATH-1477** into **286ab7c6dd4c4aae0b0290517ea3508487438d01 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] Lysergid opened a new pull request #416: Add support of lazy default value evaluation for defaulting methods
Lysergid opened a new pull request #416: Add support of lazy default value evaluation for defaulting methods URL: https://github.com/apache/commons-lang/pull/416 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MATH-1477) MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with variablesToInclude parameter
[ https://issues.apache.org/jira/browse/MATH-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chee Sing Lee updated MATH-1477: Description: When performing a regression with a subset of predictors, an ArrayIndexOutOfBounds exception will occur for certain subset selections. For example, this appears to happen consistently for regressions without a constant term when the predictor at index 0 is not selected. I do not understand at all the algorithm used to reorder the predictors when a subset is requested, but the fix appears to be a simple correction to the indexing range in the for-loop in the regress method of MillerUpdatingRegression.java. Patch with expanded unit test to follow shortly. was: When performing a regression with a subset of predictors, an ArrayIndexOutOfBounds exception will occur for certain subset selections. For example, this appears to happen consistently for regressions without a constant term when the predictor at index 0 is not selected. I do not understand at all algorithm used to reorder the predictors when a subset is used, but the fix appears to be a simple correction to the indexing range in the for-loop at line 1059 of MillerUpdatingRegression.java. Patch with expanded unit test to follow shortly. > MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with > variablesToInclude parameter > -- > > Key: MATH-1477 > URL: https://issues.apache.org/jira/browse/MATH-1477 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Chee Sing Lee >Priority: Major > Labels: easyfix, newbie, patch > Time Spent: 10m > Remaining Estimate: 0h > > When performing a regression with a subset of predictors, an > ArrayIndexOutOfBounds exception will occur for certain subset selections. For > example, this appears to happen consistently for regressions without a > constant term when the predictor at index 0 is not selected. > I do not understand at all the algorithm used to reorder the predictors when > a subset is requested, but the fix appears to be a simple correction to the > indexing range in the for-loop in the regress method of > MillerUpdatingRegression.java. > > Patch with expanded unit test to follow shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (MATH-1477) MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with variablesToInclude parameter
[ https://issues.apache.org/jira/browse/MATH-1477?focusedWorklogId=225208=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-225208 ] ASF GitHub Bot logged work on MATH-1477: Author: ASF GitHub Bot Created on: 09/Apr/19 18:37 Start Date: 09/Apr/19 18:37 Worklog Time Spent: 10m Work Description: cheesinglee commented on pull request #104: MATH-1477: fix reordering check in MillerUpdatingRegression.regress URL: https://github.com/apache/commons-math/pull/104 Test and fix for MATH-1477 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 225208) Time Spent: 10m Remaining Estimate: 0h > MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with > variablesToInclude parameter > -- > > Key: MATH-1477 > URL: https://issues.apache.org/jira/browse/MATH-1477 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Chee Sing Lee >Priority: Major > Labels: easyfix, newbie, patch > Time Spent: 10m > Remaining Estimate: 0h > > When performing a regression with a subset of predictors, an > ArrayIndexOutOfBounds exception will occur for certain subset selections. For > example, this appears to happen consistently for regressions without a > constant term when the predictor at index 0 is not selected. > I do not understand at all algorithm used to reorder the predictors when a > subset is used, but the fix appears to be a simple correction to the indexing > range in the for-loop at line 1059 of MillerUpdatingRegression.java. > > Patch with expanded unit test to follow shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MATH-1477) MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with variablesToInclude parameter
[ https://issues.apache.org/jira/browse/MATH-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813700#comment-16813700 ] Chee Sing Lee commented on MATH-1477: - Link to PR: [https://github.com/apache/commons-math/pull/104] > MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with > variablesToInclude parameter > -- > > Key: MATH-1477 > URL: https://issues.apache.org/jira/browse/MATH-1477 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Chee Sing Lee >Priority: Major > Labels: easyfix, newbie, patch > Time Spent: 10m > Remaining Estimate: 0h > > When performing a regression with a subset of predictors, an > ArrayIndexOutOfBounds exception will occur for certain subset selections. For > example, this appears to happen consistently for regressions without a > constant term when the predictor at index 0 is not selected. > I do not understand at all algorithm used to reorder the predictors when a > subset is used, but the fix appears to be a simple correction to the indexing > range in the for-loop at line 1059 of MillerUpdatingRegression.java. > > Patch with expanded unit test to follow shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-math] cheesinglee opened a new pull request #104: MATH-1477: fix reordering check in MillerUpdatingRegression.regress
cheesinglee opened a new pull request #104: MATH-1477: fix reordering check in MillerUpdatingRegression.regress URL: https://github.com/apache/commons-math/pull/104 Test and fix for MATH-1477 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MATH-1477) MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with variablesToInclude parameter
Chee Sing Lee created MATH-1477: --- Summary: MillerUpdatingRegression: ArrayIndexOutOfBounds when calling regress with variablesToInclude parameter Key: MATH-1477 URL: https://issues.apache.org/jira/browse/MATH-1477 Project: Commons Math Issue Type: Bug Affects Versions: 3.6.1 Reporter: Chee Sing Lee When performing a regression with a subset of predictors, an ArrayIndexOutOfBounds exception will occur for certain subset selections. For example, this appears to happen consistently for regressions without a constant term when the predictor at index 0 is not selected. I do not understand at all algorithm used to reorder the predictors when a subset is used, but the fix appears to be a simple correction to the indexing range in the for-loop at line 1059 of MillerUpdatingRegression.java. Patch with expanded unit test to follow shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-rng] coveralls edited a comment on issue #20: RNG-70: Add new XoShiRo generators
coveralls edited a comment on issue #20: RNG-70: Add new XoShiRo generators URL: https://github.com/apache/commons-rng/pull/20#issuecomment-463829859 [](https://coveralls.io/builds/22700399) Coverage increased (+0.2%) to 98.473% when pulling **4cf998435c1d2ae690dd99c2d9b5c903eb7cda2d on aherbert:feature-RNG-70** into **ad1235d85520da517495ef95fc9295b6eac5827e on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (FILEUPLOAD-298) Don't use temp directory by default for storing uploaded files
[ https://issues.apache.org/jira/browse/FILEUPLOAD-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813585#comment-16813585 ] Jochen Wiedmann commented on FILEUPLOAD-298: Given the fact, that DiskFileItem creates the temp file with the name "upload_%s_%s.tmp" (See DiskFileItem.getTempFile), where the first %s is a UUID, and the second %s is, basically, an integer value (neither UUID, nor integer value, are visible to the client)), I fail to see the problem. > Don't use temp directory by default for storing uploaded files > -- > > Key: FILEUPLOAD-298 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-298 > Project: Commons FileUpload > Issue Type: Improvement >Reporter: Artem Smotrakov >Priority: Major > Attachments: use_app_work_directory_v1.patch > > > By default, DiskFileItem stores uploaded files in the directory defined by > java.io.tmpdir system property which creates a weakness described in > CVE-2013-0248. > [https://nvd.nist.gov/vuln/detail/CVE-2013-0248] > The patch for CVE-2013-0248 just updates the docs with a note that the > setRepository() method must be used in case of untrusted environment. > [https://github.com/apache/commons-fileupload/commit/f874563307c1159ac634df67509d9859bca6ddb9] > I am wondering if it would be better to use user.dir or user.home system > properties instead of java.io.tmpdir: > * Normally only the user which started the application can write to user.home > * It seems to be more likely that user.dir is not publicly writable > I am attaching a draft patch which updates DiskFileItem to use a subdirectory > under user.dir although user.home looks to be a better option from security > perspective. > If no objections, I will finalize the patch and create a pull request. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (RNG-80) Benchmark SplitMix64 to natively generate nextInt
[
https://issues.apache.org/jira/browse/RNG-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex D Herbert closed RNG-80.
-
Resolution: Done
> Benchmark SplitMix64 to natively generate nextInt
> -
>
> Key: RNG-80
> URL: https://issues.apache.org/jira/browse/RNG-80
> Project: Commons RNG
> Issue Type: Task
> Components: core
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Minor
>
> The {{SplitMix64}} currently uses the {{LongProvider}} implementation of
> {{nextInt}} to split the {{long}} into two {{int}} values.
> However it is possible to generate {{int}} values using a variant of the
> algorithm which uses a different mixing function:
> {code:java}
> /**
> * Computes Stafford variant 13 of 64bit mix function.
> *
> * @return the long
> */
> public final long nextLong() {
> long z = state += 0x9e3779b97f4a7c15L;
> z = (z ^ (z >>> 30)) * 0xbf58476d1ce4e5b9L;
> z = (z ^ (z >>> 27)) * 0x94d049bb133111ebL;
> return z ^ (z >>> 31);
> }
> /**
> * Returns the 32 high bits of Stafford variant 4 mix64 function as int.
> *
> * @return the int
> */
> public final int nextInt() {
> long z = state += 0x9e3779b97f4a7c15L;
> z = (z ^ (z >>> 33)) * 0x62a9d9ed799705f5L;
> return (int)(((z ^ (z >>> 28)) * 0xcb24d0a5c88c35b3L) >>> 32);
> }
> {code}
> This variant is used in {{java.util.SplittableRandom}}. It changes the second
> shift operation and omits a xor operation.
> A benchmark should be made to test if the variant is faster than the current
> method to cache the long and split it into two values.
> Note that the investigation of the speed of caching was performed in RNG-57.
> The first entry on this post shows the cache only marginally improves (5%)
> the speed of the {{SplitMix64}} generator. Updating the native generation
> using a faster algorithm with less mixing may outperform the cache.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RNG-88) Update the GenerationPerformance benchmark
[ https://issues.apache.org/jira/browse/RNG-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex D Herbert resolved RNG-88. --- Resolution: Implemented In master. > Update the GenerationPerformance benchmark > -- > > Key: RNG-88 > URL: https://issues.apache.org/jira/browse/RNG-88 > Project: Commons RNG > Issue Type: Improvement > Components: examples >Affects Versions: 1.3 >Reporter: Alex D Herbert >Assignee: Alex D Herbert >Priority: Minor > Attachments: baseline.jpg, next.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > The current GenerationPerformance benchmark runs all the generators to > collect timing data. However the act of running the test within JMH takes > some time (test overhead). This overhead should be measured and subtracted > from the timing data to create a time attributed only to the method exercised > in the RNG. > This can be done by creating a dummy RNG that returns a fixed value. The > implementation must be done in a manner where the JIT compiler is not able to > remove the dummy method from the execution path. This is achieved by > returning state variables from the dummy RNG (not final variables). > Testing can be done using a variable number of iterations and the run-times > assessed for linearity. If the run time scale with the number of iterations > then the JIT compiler has not removed it from execution. The dummy RNG then > serves as a baseline for comparison of true implementations. > This idea with examples is shown in > [RNG-87|https://issues.apache.org/jira/browse/RNG-87] which tested a variant > of the MWC_256 algorithm. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-rng] asfgit merged pull request #35: RNG-88: Baseline the generation performance benchmark.
asfgit merged pull request #35: RNG-88: Baseline the generation performance benchmark. URL: https://github.com/apache/commons-rng/pull/35 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (RNG-82) XorShift1024StarPhi generator
[
https://issues.apache.org/jira/browse/RNG-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex D Herbert resolved RNG-82.
---
Resolution: Implemented
In master
> XorShift1024StarPhi generator
> -
>
> Key: RNG-82
> URL: https://issues.apache.org/jira/browse/RNG-82
> Project: Commons RNG
> Issue Type: New Feature
> Components: core, simple
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Major
> Fix For: 1.3
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The authors of the algorithm implemented in
> {{org.apache.commons.rng.core.source64.XorShift1024Star}} have produced a new
> variant using a different multiplier. The source code is described here:
> [xorshift1024star.c|http://xorshift.di.unimi.it/xorshift1024star.c]
> For clarity the code states:
> {noformat}
>NOTE: as of 2017-10-08, this generator has a different multiplier (a
>fixed-point representation of the golden ratio), which eliminates
>linear dependencies from one of the lowest bits. The previous
>multiplier was 1181783497276652981 (M_8 in the paper). If you need to
>tell apart the two generators, you can refer to this generator as
>xorshift1024φ and to the previous one as xorshift1024*M_8.
> {noformat}
> This can be added as a variant of the current implementation:
> class = XorShift1024StarPhi
> RandomSource = XOR_SHIFT_1024_S_PHI
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (LANG-1446) Switch from Cobertura code coverage to Jacoco code coverage
[ https://issues.apache.org/jira/browse/LANG-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated LANG-1446: --- Assignee: Rob Tompkins > Switch from Cobertura code coverage to Jacoco code coverage > --- > > Key: LANG-1446 > URL: https://issues.apache.org/jira/browse/LANG-1446 > Project: Commons Lang > Issue Type: New Feature >Reporter: Rob Tompkins >Assignee: Rob Tompkins >Priority: Major > > We need to move the file `src/site/resources/profile.cobertura` to > `src/site/resources/profile.jacoco` to do this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (LANG-1446) Switch from Cobertura code coverage to Jacoco code coverage
[ https://issues.apache.org/jira/browse/LANG-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated LANG-1446: --- Issue Type: Task (was: New Feature) > Switch from Cobertura code coverage to Jacoco code coverage > --- > > Key: LANG-1446 > URL: https://issues.apache.org/jira/browse/LANG-1446 > Project: Commons Lang > Issue Type: Task >Reporter: Rob Tompkins >Priority: Major > > We need to move the file `src/site/resources/profile.cobertura` to > `src/site/resources/profile.jacoco` to do this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (LANG-1446) Switch from Cobertura code coverage to Jacoco code coverage
[ https://issues.apache.org/jira/browse/LANG-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated LANG-1446: --- Issue Type: New Feature (was: Task) > Switch from Cobertura code coverage to Jacoco code coverage > --- > > Key: LANG-1446 > URL: https://issues.apache.org/jira/browse/LANG-1446 > Project: Commons Lang > Issue Type: New Feature >Reporter: Rob Tompkins >Priority: Major > > We need to move the file `src/site/resources/profile.cobertura` to > `src/site/resources/profile.jacoco` to do this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (LANG-1446) Switch from Cobertura code coverage to Jacoco code coverage
Rob Tompkins created LANG-1446: -- Summary: Switch from Cobertura code coverage to Jacoco code coverage Key: LANG-1446 URL: https://issues.apache.org/jira/browse/LANG-1446 Project: Commons Lang Issue Type: New Feature Reporter: Rob Tompkins We need to move the file `src/site/resources/profile.cobertura` to `src/site/resources/profile.jacoco` to do this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DAEMON-399) apxStrUnQuoteInplaceA removes needed quotes
[
https://issues.apache.org/jira/browse/DAEMON-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813387#comment-16813387
]
Gary Gregory commented on DAEMON-399:
-
Hi [~spjoe],
It would be best if you could offer your change via a PR on GitHub.
Thank you!
Gary
> apxStrUnQuoteInplaceA removes needed quotes
> ---
>
> Key: DAEMON-399
> URL: https://issues.apache.org/jira/browse/DAEMON-399
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.1.0
>Reporter: Camillo Dell'mour
>Priority: Minor
>
> When trying to pass the following argument to the jvm
> {code:java}
> -Xlog:gc:file="d:\logs\gc.log"::filecount=5,filesize=2
> {code}
> the method apxStrUnQuoteInplaceA removes " from it and the resulting command
> looks like this:
> {code:java}
> -Xlog:gc:file=d:\logs\gc.log::filecount=5,filesize=2000
> {code}
> Which is an invalid jvm argument.
> Workaround for version 1.1.0 is to add a space into the log filename.
> IMHO the proper fix would be not too use apxStrUnQuoteInplaceA at all.
> Another possible fix would be to replace utils.c:571 with
> {code}
> else if (*p == ' ' || *p == ':') {
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DAEMON-399) apxStrUnQuoteInplaceA removes needed quotes
Camillo Dell'mour created DAEMON-399:
Summary: apxStrUnQuoteInplaceA removes needed quotes
Key: DAEMON-399
URL: https://issues.apache.org/jira/browse/DAEMON-399
Project: Commons Daemon
Issue Type: Bug
Components: Procrun
Affects Versions: 1.1.0
Reporter: Camillo Dell'mour
When trying to pass the following argument to the jvm
{code:java}
-Xlog:gc:file="d:\logs\gc.log"::filecount=5,filesize=2
{code}
the method apxStrUnQuoteInplaceA removes " from it and the resulting command
looks like this:
{code:java}
-Xlog:gc:file=d:\logs\gc.log::filecount=5,filesize=2000
{code}
Which is an invalid jvm argument.
Workaround for version 1.1.0 is to add a space into the log filename.
IMHO the proper fix would be not too use apxStrUnQuoteInplaceA at all.
Another possible fix would be to replace utils.c:571 with
{code}
else if (*p == ' ' || *p == ':') {
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-298) Don't use temp directory by default for storing uploaded files
[ https://issues.apache.org/jira/browse/FILEUPLOAD-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813363#comment-16813363 ] Jochen Wiedmann commented on FILEUPLOAD-298: [~asmotrakov]: Agreed. On the other hand, that's what we have setRepository() for. I won't enter the discussion, what's a sensible value for that, or not. In particular not, while we are discussing sensible default values. Because, that's quite a different story. > Don't use temp directory by default for storing uploaded files > -- > > Key: FILEUPLOAD-298 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-298 > Project: Commons FileUpload > Issue Type: Improvement >Reporter: Artem Smotrakov >Priority: Major > Attachments: use_app_work_directory_v1.patch > > > By default, DiskFileItem stores uploaded files in the directory defined by > java.io.tmpdir system property which creates a weakness described in > CVE-2013-0248. > [https://nvd.nist.gov/vuln/detail/CVE-2013-0248] > The patch for CVE-2013-0248 just updates the docs with a note that the > setRepository() method must be used in case of untrusted environment. > [https://github.com/apache/commons-fileupload/commit/f874563307c1159ac634df67509d9859bca6ddb9] > I am wondering if it would be better to use user.dir or user.home system > properties instead of java.io.tmpdir: > * Normally only the user which started the application can write to user.home > * It seems to be more likely that user.dir is not publicly writable > I am attaching a draft patch which updates DiskFileItem to use a subdirectory > under user.dir although user.home looks to be a better option from security > perspective. > If no objections, I will finalize the patch and create a pull request. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (EMAIL-186) Commons Email does not provide automatic module name
[ https://issues.apache.org/jira/browse/EMAIL-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813060#comment-16813060 ] Jochen Wiedmann commented on EMAIL-186: --- [~triceo85], [~garydgregory]: Could you please have a look at [https://lists.apache.org/thread.html/da6a77a154133da7b077d7070ebc9bd17ce0ded1dbf6ed1b80211c2e@%3Cdev.commons.apache.org%3E] > Commons Email does not provide automatic module name > > > Key: EMAIL-186 > URL: https://issues.apache.org/jira/browse/EMAIL-186 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Lukas Petrovicky >Priority: Critical > Fix For: 1.6 > > > At the moment, commons-email is a thorn in one's side when it comes to JPMS. > At the very least, it should give a [stable automatic module > name|http://branchandbound.net/blog/java/2017/12/automatic-module-name/] in > the JAR file's manifest. > I can provide a PR fixing this, but judging by the state of EMAIL-183, this > project looks like it is dead and people should instead be discouraged from > using it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (LANG-1445) NumberUtils.createNumber() incorrectly creates BigDecimal when a double type is specified
[
https://issues.apache.org/jira/browse/LANG-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Costa Theodosiou updated LANG-1445:
---
Description:
{{NumberUtils.createNumber(Double.valueOf(Double.MIN_VALUE).toString() + "D")}}
and
{{NumberUtils.createNumber(Double.valueOf(Double.MIN_VALUE).toString() + "F")}}
are incorrectly creating BigDecimals.
This is due to a bug:
{{if (!(d.isInfinite() || d.floatValue() == 0.0D && !allZeros)) {}}
which should be:
{{if (!(d.isInfinite() || d.doubleValue() == 0.0D && !allZeros)) {}}
A patch has been attached.
was:
{{NumberUtils.createNumber(Double.valueOf(Double.MIN_VALUE).toString() + "D")}}
and
{{NumberUtils.createNumber(Double.valueOf(Double.MIN_VALUE).toString() + "F")}}
are incorrectly creating BigDecimals.
This is due to a bug:
{{ if (!(d.isInfinite() || d.floatValue() == 0.0D && !allZeros)) {}}
which should be:
{{if (!(d.isInfinite() || d.doubleValue() == 0.0D && !allZeros)) {}}
A patch has been attached.
> NumberUtils.createNumber() incorrectly creates BigDecimal when a double type
> is specified
> -
>
> Key: LANG-1445
> URL: https://issues.apache.org/jira/browse/LANG-1445
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.8.1
>Reporter: Costa Theodosiou
>Priority: Major
> Attachments:
> NumberUtils_createNumber()_incorrectly_creates_BigDecimal_when_a_double_type_is_specified.patch
>
>
> {{NumberUtils.createNumber(Double.valueOf(Double.MIN_VALUE).toString() +
> "D")}}
> and
> {{NumberUtils.createNumber(Double.valueOf(Double.MIN_VALUE).toString() +
> "F")}}
> are incorrectly creating BigDecimals.
> This is due to a bug:
> {{if (!(d.isInfinite() || d.floatValue() == 0.0D && !allZeros)) {}}
> which should be:
> {{if (!(d.isInfinite() || d.doubleValue() == 0.0D && !allZeros)) {}}
> A patch has been attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (LANG-1445) NumberUtils.createNumber() incorrectly creates BigDecimal when a double type is specified
Costa Theodosiou created LANG-1445:
--
Summary: NumberUtils.createNumber() incorrectly creates BigDecimal
when a double type is specified
Key: LANG-1445
URL: https://issues.apache.org/jira/browse/LANG-1445
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.8.1
Reporter: Costa Theodosiou
Attachments:
NumberUtils_createNumber()_incorrectly_creates_BigDecimal_when_a_double_type_is_specified.patch
{{NumberUtils.createNumber(Double.valueOf(Double.MIN_VALUE).toString() + "D")}}
and
{{NumberUtils.createNumber(Double.valueOf(Double.MIN_VALUE).toString() + "F")}}
are incorrectly creating BigDecimals.
This is due to a bug:
{{ if (!(d.isInfinite() || d.floatValue() == 0.0D && !allZeros)) {}}
which should be:
{{if (!(d.isInfinite() || d.doubleValue() == 0.0D && !allZeros)) {}}
A patch has been attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-698) SFTP file attributes are fetched multiple times leading to very slow directory listing
[
https://issues.apache.org/jira/browse/VFS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
krishnan updated VFS-698:
-
Description:
getChildren() applied on SftpFileObject is very slow compared to JSCH
implementation. This is because, the SftpATTRS which is readily available for
the children after an "ls" call is again fetched for each child file since they
are independently resolved. So if a directory contains 10 files, it results in
1 (ls) + 10 (stat) calls to server.
For a folder with 100 files (AWS), it took about 35 secs instead of 1.5 secs to
getChildren().
*doListChildrenResolved:*
{{final FileObject fo =
getFileSystem().resolveFile(getFileSystem().getFileSystemManager()}}
\{{ .resolveName(getName(), UriParser.encode(name), NameScope.CHILD));}}
{{{color:#ff}((SftpFileObject)
FileObjectUtils.getAbstractFileObject(fo)).setStat(stat.getAttrs());{color}}}
The resolveFile call, creates a SftpFileObject and calls its resolve method,
which results in getting the (stats) SftpATTRS for each child file. This stat
is already available as part of the 'ls' call we made. The setStat call above
(highlighted is red) is redundant, since stat for each child file is already
fetched one at a time.
The solution would be to avoid getting the stat for each child file after an
'ls' call. May be, the framework makes it difficult to do this easily.
was:
getChildren() applied on SftpFileObject is very slow compared to JSCH
implementation since the SftpATTRS which is readily available for the children
after an "ls" call is again fetched for each child file since they are
independently resolved. So if a directory contains 10 files, it results in 1
(ls) + 10 (stat) calls to server.
For a folder with 100 files (AWS), it took about 35 secs instead of 1.5 secs to
getChildren().
*doListChildrenResolved:*
{{final FileObject fo =
getFileSystem().resolveFile(getFileSystem().getFileSystemManager()}}
{{ .resolveName(getName(), UriParser.encode(name), NameScope.CHILD));}}
{{{color:#FF}((SftpFileObject)
FileObjectUtils.getAbstractFileObject(fo)).setStat(stat.getAttrs());{color}}}
The resolveFile call, creates a SftpFileObject and calls its resolve method,
which results in getting the (stats) SftpATTRS for each child file. This stat
is already available as part of the 'ls' call we made. The setStat call above
(highlighted is red) is redundant, since stat for each child file is already
fetched one at a time.
The solution would be to avoid getting the stat for each child file after an
'ls' call. May be, the framework makes it difficult to do this easily.
> SFTP file attributes are fetched multiple times leading to very slow
> directory listing
> --
>
> Key: VFS-698
> URL: https://issues.apache.org/jira/browse/VFS-698
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: krishnan
>Priority: Major
>
> getChildren() applied on SftpFileObject is very slow compared to JSCH
> implementation. This is because, the SftpATTRS which is readily available for
> the children after an "ls" call is again fetched for each child file since
> they are independently resolved. So if a directory contains 10 files, it
> results in 1 (ls) + 10 (stat) calls to server.
> For a folder with 100 files (AWS), it took about 35 secs instead of 1.5 secs
> to getChildren().
>
> *doListChildrenResolved:*
> {{final FileObject fo =
> getFileSystem().resolveFile(getFileSystem().getFileSystemManager()}}
> \{{ .resolveName(getName(), UriParser.encode(name), NameScope.CHILD));}}
> {{{color:#ff}((SftpFileObject)
> FileObjectUtils.getAbstractFileObject(fo)).setStat(stat.getAttrs());{color}}}
>
> The resolveFile call, creates a SftpFileObject and calls its resolve method,
> which results in getting the (stats) SftpATTRS for each child file. This stat
> is already available as part of the 'ls' call we made. The setStat call above
> (highlighted is red) is redundant, since stat for each child file is already
> fetched one at a time.
> The solution would be to avoid getting the stat for each child file after an
> 'ls' call. May be, the framework makes it difficult to do this easily.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (VFS-698) SFTP file attributes are fetched multiple times leading to very slow directory listing
krishnan created VFS-698:
Summary: SFTP file attributes are fetched multiple times leading
to very slow directory listing
Key: VFS-698
URL: https://issues.apache.org/jira/browse/VFS-698
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.3
Reporter: krishnan
getChildren() applied on SftpFileObject is very slow compared to JSCH
implementation since the SftpATTRS which is readily available for the children
after an "ls" call is again fetched for each child file since they are
independently resolved. So if a directory contains 10 files, it results in 1
(ls) + 10 (stat) calls to server.
For a folder with 100 files (AWS), it took about 35 secs instead of 1.5 secs to
getChildren().
*doListChildrenResolved:*
{{final FileObject fo =
getFileSystem().resolveFile(getFileSystem().getFileSystemManager()}}
{{ .resolveName(getName(), UriParser.encode(name), NameScope.CHILD));}}
{{{color:#FF}((SftpFileObject)
FileObjectUtils.getAbstractFileObject(fo)).setStat(stat.getAttrs());{color}}}
The resolveFile call, creates a SftpFileObject and calls its resolve method,
which results in getting the (stats) SftpATTRS for each child file. This stat
is already available as part of the 'ls' call we made. The setStat call above
(highlighted is red) is redundant, since stat for each child file is already
fetched one at a time.
The solution would be to avoid getting the stat for each child file after an
'ls' call. May be, the framework makes it difficult to do this easily.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
