[jira] [Commented] (GEOMETRY-60) JDK 13 Build Fails
[ https://issues.apache.org/jira/browse/GEOMETRY-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937773#comment-16937773 ] Gilles commented on GEOMETRY-60: Fixed? > JDK 13 Build Fails > -- > > Key: GEOMETRY-60 > URL: https://issues.apache.org/jira/browse/GEOMETRY-60 > Project: Apache Commons Geometry > Issue Type: Bug >Reporter: Matt Juntunen >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The build for JDK 13 is failing on Travis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-46) Additional UnitVector methods
[
https://issues.apache.org/jira/browse/GEOMETRY-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937584#comment-16937584
]
Gilles commented on GEOMETRY-46:
Surprised by this use of {{super}}, I couldn't find any link on the web about
this access to private _instance_ fields (from a _static_ nested class); yet it
works...
However, while looking at that, it occurred to me that there could be some
improvement around the "normalize" functionality. Please comment on the patch
which I've just attached (diff is against PR #39, not master).
> Additional UnitVector methods
> -
>
> Key: GEOMETRY-46
> URL: https://issues.apache.org/jira/browse/GEOMETRY-46
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Minor
> Labels: easyfix, pull-request-available, starter
> Attachments: GEOMETRY-46.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following methods should be overridden in the {{UnitVector}} private
> subclasses of the {{Vector?D}} classes:
> * {{normSq}} -- should return {{1}} for consistency with {{norm}}
> * {{negate}} -- should be overridden to also return a {{UnitVector}} instance
> instead of a regular {{Vector?D}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEOMETRY-46) Additional UnitVector methods
[
https://issues.apache.org/jira/browse/GEOMETRY-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated GEOMETRY-46:
---
Attachment: GEOMETRY-46.patch
> Additional UnitVector methods
> -
>
> Key: GEOMETRY-46
> URL: https://issues.apache.org/jira/browse/GEOMETRY-46
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Minor
> Labels: easyfix, pull-request-available, starter
> Attachments: GEOMETRY-46.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following methods should be overridden in the {{UnitVector}} private
> subclasses of the {{Vector?D}} classes:
> * {{normSq}} -- should return {{1}} for consistency with {{norm}}
> * {{negate}} -- should be overridden to also return a {{UnitVector}} instance
> instead of a regular {{Vector?D}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-46) Additional UnitVector methods
[
https://issues.apache.org/jira/browse/GEOMETRY-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937556#comment-16937556
]
Gilles commented on GEOMETRY-46:
In the unit tests, the tolerance should be set to 0 (since the purpose of that
specialized class is to return exactly 1 for the norm).
Nit-pick: Spurious (trailing) white-space characters.
> Additional UnitVector methods
> -
>
> Key: GEOMETRY-46
> URL: https://issues.apache.org/jira/browse/GEOMETRY-46
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Minor
> Labels: easyfix, pull-request-available, starter
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following methods should be overridden in the {{UnitVector}} private
> subclasses of the {{Vector?D}} classes:
> * {{normSq}} -- should return {{1}} for consistency with {{norm}}
> * {{negate}} -- should be overridden to also return a {{UnitVector}} instance
> instead of a regular {{Vector?D}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (VALIDATOR-459) Allow UrlValidator/DomainValidator to skip the TLD validation
[ https://issues.apache.org/jira/browse/VALIDATOR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936568#comment-16936568 ] Gilles commented on VALIDATOR-459: -- Feature request and discussion should be posted on the "dev" ML. > Allow UrlValidator/DomainValidator to skip the TLD validation > - > > Key: VALIDATOR-459 > URL: https://issues.apache.org/jira/browse/VALIDATOR-459 > Project: Commons Validator > Issue Type: Improvement >Reporter: Christophe Lé >Priority: Minor > > Hello there, > One of my applications is validating URLs which can be on the internet OR in > the same network. Those from the same network are ending with *.local*. > Unfortunately, *.local* is not referenced anywhere in DomainValidator. > Besides, whenever new TLDs are out, the library has to be updated with those. > I was wondering if adding a flag to skip the TLD validation would be an > interesting feature to have? > # Whatever exotic internal TLD an application is using, if an URL points to > nothing it doesn't matter since ultimately, the component which is going to > initiate a network call will fail. > # If people doesn't bother about the legitimacy of a TLD, they should not be > _forced_ to update to the latest version of the library whenever a new TLD is > out. Such action should be motivated for feature or security reasons. > This flag would only be meaningful if you don't really care about the > legitimacy of a TLD. > What do you think? > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935087#comment-16935087
]
Gilles commented on GEOMETRY-32:
The previous examples look nice. ;)
> 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: 20m
> 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
(v8.3.4#803005)
[jira] [Comment Edited] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935038#comment-16935038
]
Gilles edited comment on GEOMETRY-32 at 9/21/19 4:54 PM:
-
Here is another useful link for this discussion:
[https://en.wikipedia.org/wiki/Orientation_(vector_space)|https://en.wikipedia.org/wiki/Orientation_(vector_space)]
was (Author: mattjuntunen):
Here is another useful link for this discussion:
https://en.wikipedia.org/wiki/Orientation_(vector_space)
> 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: 20m
> 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
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934983#comment-16934983
]
Gilles commented on GEOMETRY-32:
bq. see here
Wrong link.
bq. [...] just a requirement of how we're implementing the region inclusion
test, and not a property of the region itself.
Hence, shouldn't we hide this _implementation detail_ from the public API (in
the sense that application developers would/should never have any reason to set
the {{preserveHandedness}}, IIUC)?
> 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: 20m
> 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
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932844#comment-16932844
]
Gilles commented on GEOMETRY-32:
bq. This is not just a matter of intuition, but also of the properties of the
region. The points that are in the interior of the region must remain in the
interior when everything is transformed.
Really? This is actually a question: I don't know why it is a requirement (nor
where it is defined). :-)
Pending your answer, I could imagine that in the same way that a reflection
transforms "left" to "right", it could also transform "in" to "out".
bq. What do you mean here?
I'm not sure! ;-)
An interface to transform coordinates, and an interface to transform oriented
shapes (?).
Maybe that does not make any sense, and I'm missing some basics about all of
this (I couldn't find an opportunity to study the code, despite having some
potential use-case...).
> 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: 20m
> 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
(v8.3.4#803005)
[jira] [Commented] (RNG-111) Jenkins Small Fast generator
[ https://issues.apache.org/jira/browse/RNG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932818#comment-16932818 ] Gilles commented on RNG-111: Actually, I thought that your proposal implied that it's unlikely that name clashes will occur later. Besides trying to anticipatively minimize the possibility of a name clash, I have no strong argument. > Jenkins Small Fast generator > > > Key: RNG-111 > URL: https://issues.apache.org/jira/browse/RNG-111 > Project: Commons RNG > Issue Type: Improvement > Components: core >Affects Versions: 1.3 >Reporter: Alex D Herbert >Assignee: Alex D Herbert >Priority: Minor > Fix For: 1.3 > > > Implement Bob Jenkins' Small/Fast Chaotic PRNG. > [A small noncryptographic > PRNG|http://burtleburtle.net/bob/rand/smallprng.html] > Variants are provided for 32-bit and 64-bit output. The generators use bit > shifts to avalanche state and many variants are provided for different shift > combinations. However there is a recommended variant that has been more > extensively tested. A seeding routine is provided to ensure that generators > with short cycles are avoided. > This generator has no name but appears in PractRand as JSF (Jenkins Small > Fast). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RNG-111) Jenkins Small Fast generator
[ https://issues.apache.org/jira/browse/RNG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932725#comment-16932725 ] Gilles commented on RNG-111: bq. deal with name clashes in the future. OK. > Jenkins Small Fast generator > > > Key: RNG-111 > URL: https://issues.apache.org/jira/browse/RNG-111 > Project: Commons RNG > Issue Type: Improvement > Components: core >Affects Versions: 1.3 >Reporter: Alex D Herbert >Assignee: Alex D Herbert >Priority: Minor > Fix For: 1.3 > > > Implement Bob Jenkins' Small/Fast Chaotic PRNG. > [A small noncryptographic > PRNG|http://burtleburtle.net/bob/rand/smallprng.html] > Variants are provided for 32-bit and 64-bit output. The generators use bit > shifts to avalanche state and many variants are provided for different shift > combinations. However there is a recommended variant that has been more > extensively tested. A seeding routine is provided to ensure that generators > with short cycles are avoided. > This generator has no name but appears in PractRand as JSF (Jenkins Small > Fast). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RNG-111) Jenkins Small Fast generator
[
https://issues.apache.org/jira/browse/RNG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931518#comment-16931518
]
Gilles commented on RNG-111:
The same "inconsistency" (long class name, shorter enum name) applies for
{{MersenneTwister}}, {{MultiplywithCarry}}, ... So I think that's fine.
Or perhaps separate the part that refers to the author (in case another
generator would be specified with the same initials):
* {{DH_SFC_32}}
* {{DH_SFC_64}}
* {{J_SF_32}}
* {{J_SF_64}}
WDYT?
> Jenkins Small Fast generator
>
>
> Key: RNG-111
> URL: https://issues.apache.org/jira/browse/RNG-111
> Project: Commons RNG
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Minor
> Fix For: 1.3
>
>
> Implement Bob Jenkins' Small/Fast Chaotic PRNG.
> [A small noncryptographic
> PRNG|http://burtleburtle.net/bob/rand/smallprng.html]
> Variants are provided for 32-bit and 64-bit output. The generators use bit
> shifts to avalanche state and many variants are provided for different shift
> combinations. However there is a recommended variant that has been more
> extensively tested. A seeding routine is provided to ensure that generators
> with short cycles are avoided.
> This generator has no name but appears in PractRand as JSF (Jenkins Small
> Fast).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-111) Jenkins Small Fast generator
[
https://issues.apache.org/jira/browse/RNG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931335#comment-16931335
]
Gilles commented on RNG-111:
I think that whenever possible it is better to have a readable class name for
the core implementation:
* {{JSF32}} -> {{JenkinsSmallFast32}}
* {{JSF64}} -> {{JenkinsSmallFast64}}
Same remark for {{SFC}}:
* {{SFC32}} -> {{DotyHumphreySmallFastCounting32}}
* {{SFC64}} -> {{DotyHumphreySmallFastCounting64}}
> Jenkins Small Fast generator
>
>
> Key: RNG-111
> URL: https://issues.apache.org/jira/browse/RNG-111
> Project: Commons RNG
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Minor
> Fix For: 1.3
>
>
> Implement Bob Jenkins' Small/Fast Chaotic PRNG.
> [A small noncryptographic
> PRNG|http://burtleburtle.net/bob/rand/smallprng.html]
> Variants are provided for 32-bit and 64-bit output. The generators use bit
> shifts to avalanche state and many variants are provided for different shift
> combinations. However there is a recommended variant that has been more
> extensively tested. A seeding routine is provided to ensure that generators
> with short cycles are avoided.
> This generator has no name but appears in PractRand as JSF (Jenkins Small
> Fast).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-111) Jenkins Small Fast generator
[ https://issues.apache.org/jira/browse/RNG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931278#comment-16931278 ] Gilles commented on RNG-111: Status? > Jenkins Small Fast generator > > > Key: RNG-111 > URL: https://issues.apache.org/jira/browse/RNG-111 > Project: Commons RNG > Issue Type: Improvement > Components: core >Affects Versions: 1.3 >Reporter: Alex D Herbert >Priority: Minor > > Implement Bob Jenkins' Small/Fast Chaotic PRNG. > [A small noncryptographic > PRNG|http://burtleburtle.net/bob/rand/smallprng.html] > Variants are provided for 32-bit and 64-bit output. The generators use bit > shifts to avalanche state and many variants are provided for different shift > combinations. However there is a recommended variant that has been more > extensively tested. A seeding routine is provided to ensure that generators > with short cycles are avoided. > This generator has no name but appears in PractRand as JSF (Jenkins Small > Fast). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931256#comment-16931256
]
Gilles commented on GEOMETRY-32:
bq. We would expect the inside of the reflected region to be simply the second
quadrant, but since the orientation of the bounding lines is significant, the
inside of the region is now actually all quadrants except for the second.
My impression is that what we "intuitively" expect contradicts what is
"naturally" provided by the framework.
>From the above, I'd feel that the clean way out of the contradiction is to
>_change the orientation of the bounding lines_ rather than _flip the
>interior/exterior_.
I get that the result would be the same when the POV is on the intuitive
meaning of the transforms being discussed here, but I wonder if the decoupling
of transformation and orientation would not lead to a better design (and
ultimately more flexibility?).
> 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: 20m
> 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
(v8.3.2#803003)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926644#comment-16926644
]
Gilles commented on GEOMETRY-32:
bq. when the transform represents a reflection [...] the interior and exterior
of the region must be flipped
Why?
> 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: 20m
> 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
(v8.3.2#803003)
[jira] [Resolved] (RNG-19) System generator (/dev/random)
[ https://issues.apache.org/jira/browse/RNG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved RNG-19. --- Fix Version/s: 1.3 Resolution: Delivered > System generator (/dev/random) > -- > > Key: RNG-19 > URL: https://issues.apache.org/jira/browse/RNG-19 > Project: Commons RNG > Issue Type: Wish >Reporter: Emmanuel Bourg >Priority: Minor > Fix For: 1.3 > > Time Spent: 40m > Remaining Estimate: 0h > > Commons RNG could include a random number generator based on the output of > /dev/random or /dev/urandom on Unix systems. > Commons Crypto has an implementation that could be used as a starting point: > https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/random/OsCryptoRandom.java -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MATH-1497) Performance issue with SVD calculation
[ https://issues.apache.org/jira/browse/MATH-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922435#comment-16922435 ] Gilles commented on MATH-1497: -- Hi. Is this a bug report or a usage question? In the latter case, you should post to the [user mailing list|http://commons.apache.org/mail-lists.html]. Also, be sure to report issues using the latest version of the library (at least v3.6.1 or even better the developement version). Thanks. > Performance issue with SVD calculation > -- > > Key: MATH-1497 > URL: https://issues.apache.org/jira/browse/MATH-1497 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Sudheer >Priority: Major > Attachments: Snapshot.jpg > > > We use SingularValueDecomposition(RealMatrix) and getSolver() methods. > This seems to be taking time for large matrices, refer to attached picture. > Example:925*161 > I have referred to release notes of the library, It seems there are no major > changes related to SVD. > > Is there any way to improve performance, -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (RNG-115) JDKRandom to allow restore state when saved from a different instance
[
https://issues.apache.org/jira/browse/RNG-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921058#comment-16921058
]
Gilles commented on RNG-115:
bq. An alternative is the simple fix to change the private stateSize field to
static
I prefer the robust solution. ;-)
> JDKRandom to allow restore state when saved from a different instance
> -
>
> Key: RNG-115
> URL: https://issues.apache.org/jira/browse/RNG-115
> Project: Commons RNG
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the size of the serialized state of the java.util.Random used by
> JDKRandom is saved to the instance when the state is saved. Thus the state
> cannot be used to restore a different instance of the same class. This breaks
> the contract of the RestorableUniformRandomProvider as the state should be
> applicable to a different instance of the same class.
> Fix this test to work:
> {code:java}
> @Test
> public void testRestoreToNewInstance() {
> final long seed = 8796746234L;
> final JDKRandom rng1 = new JDKRandom(seed);
> final JDKRandom rng2 = new JDKRandom(seed + 1);
> final RandomProviderState state = rng1.saveState();
> rng2.restoreState(state);
> final int numRepeats = 1000;
> for (int r = 0; r < numRepeats; r++) {
> Assert.assertEquals(r + " nextInt", rng1.nextInt(), rng2.nextInt());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-19) System generator (/dev/random)
[
https://issues.apache.org/jira/browse/RNG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921057#comment-16921057
]
Gilles commented on RNG-19:
---
bq. wrapper essentially the same as JDKRandom
The intention was that {{JDKRandom}} is "safe" because the delegate is
encapsulated.
While the wrapper is error-prone (interface can be bypassed).
I agree about code duplication but that was not the main point...
bq. {{next(int bits)}} [vs] {{nextBytes}}
I had missed that.
IMHO, it makes the API/implementation of {{Random}} even more confusing.
bq. state function of a SecureRandom configured to read from /dev/urandom would
not function as I would expect
Right. This was noted by the OP, and not considered a problem. But I agree
with you that it is from an API consistency POV.
So let's go with the initial idea: a simple wrapper (as in the current PR).
bq. error [...] can be fixed by also saving the state size to the state
Thanks.
> System generator (/dev/random)
> --
>
> Key: RNG-19
> URL: https://issues.apache.org/jira/browse/RNG-19
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Emmanuel Bourg
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Commons RNG could include a random number generator based on the output of
> /dev/random or /dev/urandom on Unix systems.
> Commons Crypto has an implementation that could be used as a starting point:
> https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/random/OsCryptoRandom.java
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-19) System generator (/dev/random)
[
https://issues.apache.org/jira/browse/RNG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921011#comment-16921011
]
Gilles commented on RNG-19:
---
bq. pass all output from Random
Can be; but what is the added value?
bq. [...] the only new methods are [...]
The proposed alternative avoids code duplication.
bq. [...] only pass through the 32-bit int output. This may not be the primary
output.
The {{Random}} API
[requires|https://docs.oracle.com/javase/8/docs/api/java/util/Random.html#next-int-]
subclasses to implement
{code}
protected int next(int)
{code}
which generates at most (exactly?) 32-bits per call.
bq. not be able to support save/restore without knowing how the input Random
was created.
Why? State can be recovered from the serialized form.
Wrt synchronization, inheriting from {{BaseProvider}} does not change your
conclusion (depends on the delegate's implementation.
Anyways, {{UniformRandomProvider}} being an interface, it cannot make such a
promise to callers.
> System generator (/dev/random)
> --
>
> Key: RNG-19
> URL: https://issues.apache.org/jira/browse/RNG-19
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Emmanuel Bourg
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Commons RNG could include a random number generator based on the output of
> /dev/random or /dev/urandom on Unix systems.
> Commons Crypto has an implementation that could be used as a starting point:
> https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/random/OsCryptoRandom.java
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (MATH-1496) An error in Gamma.java
[
https://issues.apache.org/jira/browse/MATH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-1496.
--
Resolution: Won't Fix
Class does not exist anymore in the development version (4.0-SNAPSHOT) of
Commons Math.
Fix was applied in the replacement code that is now in the Commons Numbers
project (see previous comment).
> An error in Gamma.java
> --
>
> Key: MATH-1496
> URL: https://issues.apache.org/jira/browse/MATH-1496
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Xi Chen
>Priority: Major
>
> {noformat}
> if (x >= C_LIMIT) {
> // use method 4 (accurate to O(1/x^8)
> double inv = 1 / (x * x);
> // ...
> return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 / 120
> - inv / 252));
> }
> {noformat}
> Line 463:
> {code}
> return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 / 120 -
> inv / 252));
> {code}
> Is it should be:
> {code}
> return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) - inv * (1.0 / 120 -
> inv / 252));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (MATH-1496) An error in Gamma.java
[
https://issues.apache.org/jira/browse/MATH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-1496:
-
Description:
{noformat}
if (x >= C_LIMIT) {
// use method 4 (accurate to O(1/x^8)
double inv = 1 / (x * x);
// ...
return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 / 120 -
inv / 252));
}
{noformat}
Line 463:
{code}
return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 / 120 - inv
/ 252));
{code}
Is it should be:
{code}
return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) - inv * (1.0 / 120 - inv
/ 252));
{code}
was:
{noformat}
457 if (x >= C_LIMIT) {
458 // use method 4 (accurate to O(1/x^8)
459 double inv = 1 / (x * x);
460 // 1 1 1
1 461 // log(x) - - - -- + -
462 // 2 x 12 x^2 120 x^4 252 x^6
463 return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 /
120 - inv / 252));
464 }
{noformat}
Line 463:
return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 / 120 - inv
/ 252));
Is it should be:
return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) - inv * (1.0 / 120 - inv
/ 252));
> An error in Gamma.java
> --
>
> Key: MATH-1496
> URL: https://issues.apache.org/jira/browse/MATH-1496
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Xi Chen
>Priority: Major
>
> {noformat}
> if (x >= C_LIMIT) {
> // use method 4 (accurate to O(1/x^8)
> double inv = 1 / (x * x);
> // ...
> return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 / 120
> - inv / 252));
> }
> {noformat}
> Line 463:
> {code}
> return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 / 120 -
> inv / 252));
> {code}
> Is it should be:
> {code}
> return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) - inv * (1.0 / 120 -
> inv / 252));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (MATH-1496) An error in Gamma.java
[
https://issues.apache.org/jira/browse/MATH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-1496:
-
Description:
{noformat}
457 if (x >= C_LIMIT) {
458 // use method 4 (accurate to O(1/x^8)
459 double inv = 1 / (x * x);
460 // 1 1 1
1 461 // log(x) - - - -- + -
462 // 2 x 12 x^2 120 x^4 252 x^6
463 return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 /
120 - inv / 252));
464 }
{noformat}
Line 463:
return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 / 120 - inv
/ 252));
Is it should be:
return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) - inv * (1.0 / 120 - inv
/ 252));
was:
457 if (x >= C_LIMIT) {
458 // use method 4 (accurate to O(1/x^8)
459 double inv = 1 / (x * x);
460 // 1 1 1
1
461 // log(x) - - - -- + -
462 // 2 x 12 x^2 120 x^4 252 x^6
463 return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 /
120 - inv / 252));
464 }
Line 463:
return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 / 120 - inv /
252));
Is it should be:
return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) - inv * (1.0 / 120 - inv /
252));
> An error in Gamma.java
> --
>
> Key: MATH-1496
> URL: https://issues.apache.org/jira/browse/MATH-1496
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Xi Chen
>Priority: Major
>
> {noformat}
> 457 if (x >= C_LIMIT) {
> 458 // use method 4 (accurate to O(1/x^8)
> 459 double inv = 1 / (x * x);
> 460 // 1 1 1
> 1 461 // log(x) - - - -- + -
>
> 462 // 2 x 12 x^2 120 x^4 252 x^6
> 463 return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 /
> 120 - inv / 252));
> 464 }
> {noformat}
> Line 463:
> return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 / 120 -
> inv / 252));
> Is it should be:
> return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) - inv * (1.0 / 120 -
> inv / 252));
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MATH-1496) An error in Gamma.java
[
https://issues.apache.org/jira/browse/MATH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920769#comment-16920769
]
Gilles commented on MATH-1496:
--
Thanks for th report.
You are quite right; but this has already been
[fixed|https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=commit;h=14f6f851b179249cb74b6dfa5b3c8d193e607186]
in the new ["Commons
Numbers"|http://commons.apache.org/proper/commons-numbers/] project into which
the [Gamma functionality has been
moved|https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=tree;f=commons-numbers-gamma].
> An error in Gamma.java
> --
>
> Key: MATH-1496
> URL: https://issues.apache.org/jira/browse/MATH-1496
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Xi Chen
>Priority: Major
>
> 457 if (x >= C_LIMIT) {
> 458 // use method 4 (accurate to O(1/x^8)
> 459 double inv = 1 / (x * x);
> 460 // 1 1 1
> 1
> 461 // log(x) - - - -- + -
> 462 // 2 x 12 x^2 120 x^4 252 x^6
> 463 return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 /
> 120 - inv / 252));
> 464 }
> Line 463:
> return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) + inv * (1.0 / 120 - inv
> / 252));
> Is it should be:
> return FastMath.log(x) - 0.5 / x - inv * ((1.0 / 12) - inv * (1.0 / 120 - inv
> / 252));
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-19) System generator (/dev/random)
[
https://issues.apache.org/jira/browse/RNG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920545#comment-16920545
]
Gilles commented on RNG-19:
---
I'm now wondering whether we should prefer this:
{code:java}
public final class JDKRandomWrapper extends IntProvider {
// ...
}
{code}
with the same implementation as
[{{JDKRandom}}|https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=blob;f=commons-rng-core/src/main/java/org/apache/commons/rng/core/source32/JDKRandom.java].
This entails fuller integration within the "Commons RNG" framework (derived
types generation, cache, save/restore) and would make it the complement of
[{{JDKRandomBridge}}|https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=blob;f=commons-rng-simple/src/main/java/org/apache/commons/rng/simple/JDKRandomBridge.java]:
* {{JDKRandomBridge}}:
** Source of randomness = Commons RNG
** API (and functionality) = JDK
* {{JDKRandomWrapper}}:
** Source of randomness = JDK
** API (and functionality) = Commons RNG
Of course, in that case, some of the tested expectations will not pass, e.g. a
"wrapped" instance will not produce the same derived types as a non-wrapped
one. [Maybe "Wrapper" is not the appropriate name.]
Also, users should be warned that the wrapped object should not be accessed
otherwise (e.g. after restore, the "delegate" will be a different object);
recommended usage pattern would be, for example:
{code:java}
UniformRandomProvider rng = new
JDKRandomWrapper(SecureRandom.getInstance("NativePRNGNonBlocking"));
{code}
> System generator (/dev/random)
> --
>
> Key: RNG-19
> URL: https://issues.apache.org/jira/browse/RNG-19
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Emmanuel Bourg
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Commons RNG could include a random number generator based on the output of
> /dev/random or /dev/urandom on Unix systems.
> Commons Crypto has an implementation that could be used as a starting point:
> https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/random/OsCryptoRandom.java
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-19) System generator (/dev/random)
[
https://issues.apache.org/jira/browse/RNG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920076#comment-16920076
]
Gilles commented on RNG-19:
---
{quote}{{Wrapper}} [vs] {{Adaptor}}
{quote}
I have the impression that the former is a somewhat clearer (wrt the direction
of adaptation).
{quote}factory class [...] for conversions
{quote}
The conversion cannot be seamless (a.o. due the different approaches of
restoring state); my impression is that only the application developer is able
to decide which API can be missing (e.g. {{setSeed}}) without breaking his
application. Otherwise, I fear that we embark on a mission to support all the
issues with
[{{java.util.Random}}|http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html]
which I wished to avoid in the first place in "Commons RNG".
{quote}{{Collections.shuffle(List, Random)}}
{quote}
The JDK methods can be called directly using an instance of
[{{JDKRandomBridge}}|http://commons.apache.org/proper/commons-rng/commons-rng-simple/javadocs/api-1.0/org/apache/commons/rng/simple/JDKRandomBridge.html]
(here the issues evoked above are sidelined because the source of randomness
is encapsulated in the instance, so that the behaviour of {{Random}} can be
completely emulated).
Note that the issue is on the JDK's side (by {{Random}} not being an
interface) and IMO we shouldn't try to make it look that back-and-forth
conversion is transparent when it's likely to cause trouble.
{quote}Without adding the commons-sampling dependency for ListSampler::shuffle
{quote}
On the contrary, better to make it clear that {{ListSampler.shuffle}} is to be
preferred over {{Collections.shuffle}}. :)
{quote}3rd party libraries would likely use Random as the common API.
{quote}
IMHO, we should not promote usage of {{Random}} in any way.
[Quoting|https://bugs.openjdk.java.net/browse/JDK-8154225] a JDK developer:
"There are many things about the design of Random and its subclasses that we
regret, but it's too late to fix them now. It's always possible for third
parties to provide their own PRNG classes."
So, that's what we do.
> System generator (/dev/random)
> --
>
> Key: RNG-19
> URL: https://issues.apache.org/jira/browse/RNG-19
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Emmanuel Bourg
>Priority: Minor
>
> Commons RNG could include a random number generator based on the output of
> /dev/random or /dev/urandom on Unix systems.
> Commons Crypto has an implementation that could be used as a starting point:
> https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/random/OsCryptoRandom.java
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-19) System generator (/dev/random)
[
https://issues.apache.org/jira/browse/RNG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919723#comment-16919723
]
Gilles commented on RNG-19:
---
{quote}{{RandomUtils}}
{quote}
"Utils" classes are out of favour these days...
{quote}{{RandomSource}}
{quote}
Doesn't feel quite right as it is unrelated to the main purpose of that class
(which is to hold a list of the algorithms implemented within this library).
How about a new {{JDKRandomWrapper}} class ([along the {{JDKRandomBridge}}
class|https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=tree;f=commons-rng-simple/src/main/java/org/apache/commons/rng/simple])?
> System generator (/dev/random)
> --
>
> Key: RNG-19
> URL: https://issues.apache.org/jira/browse/RNG-19
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Emmanuel Bourg
>Priority: Minor
>
> Commons RNG could include a random number generator based on the output of
> /dev/random or /dev/urandom on Unix systems.
> Commons Crypto has an implementation that could be used as a starting point:
> https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/random/OsCryptoRandom.java
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-19) System generator (/dev/random)
[
https://issues.apache.org/jira/browse/RNG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919677#comment-16919677
]
Gilles commented on RNG-19:
---
{quote}Should it be ported over to the RNG component
{quote}
+1
{quote}deprecated from math4
{quote}
I can just be removed (code was never released).
{quote}it makes more sense to have it in RNG.
{quote}
I had put it in CM there on the rationale that it was a bad suggestion for
continued usage of {{java.util.Random}} (not taking into account the case for
{{SecureRandom}}).
> System generator (/dev/random)
> --
>
> Key: RNG-19
> URL: https://issues.apache.org/jira/browse/RNG-19
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Emmanuel Bourg
>Priority: Minor
>
> Commons RNG could include a random number generator based on the output of
> /dev/random or /dev/urandom on Unix systems.
> Commons Crypto has an implementation that could be used as a starting point:
> https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/random/OsCryptoRandom.java
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-19) System generator (/dev/random)
[ https://issues.apache.org/jira/browse/RNG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919615#comment-16919615 ] Gilles commented on RNG-19: --- bq. It may be better to add a helper class/method Like [this|http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math4/random/RandomUtils.html#asUniformRandomProvider-java.util.Random-]? ;-) > System generator (/dev/random) > -- > > Key: RNG-19 > URL: https://issues.apache.org/jira/browse/RNG-19 > Project: Commons RNG > Issue Type: Wish >Reporter: Emmanuel Bourg >Priority: Minor > > Commons RNG could include a random number generator based on the output of > /dev/random or /dev/urandom on Unix systems. > Commons Crypto has an implementation that could be used as a starting point: > https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/random/OsCryptoRandom.java -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (RNG-19) System generator (/dev/random)
[
https://issues.apache.org/jira/browse/RNG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919499#comment-16919499
]
Gilles edited comment on RNG-19 at 8/30/19 12:34 PM:
-
If the aim is to be able to use the "native" generator through the
{{UniformRandomProvider}} API, we could implement a wrapper similar to
[{{JDKRandom}}|https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=blob;f=commons-rng-core/src/main/java/org/apache/commons/rng/core/source32/JDKRandom.java]:
{code:java}
public class JDKSecureRandom extends IntProvider {
private SecureRandom delegate;
public class JDKSecureRandom(long[] seed) {
final byte[] s = NumberFactory.makeByteArray(seed);
delegate = new SecureRandom(s);
}
// ... (same as in "JDKRandom")
}
{code}
where we'd use the constructor that builds the [default
instance|https://docs.oracle.com/javase/8/docs/api/java/security/SecureRandom.html#SecureRandom-byte:A-]
so that the wrapper is usable on all OSes that support the JDK.
was (Author: erans):
If the aim is to be able to use the "native" generator through the
{{UniformRandomProvider}} API, we could implement a wrapper similar to
[{{JDKRandom}}|https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=blob;f=commons-rng-core/src/main/java/org/apache/commons/rng/core/source32/JDKRandom.java]:
{code:java}
public class JDKSecureRandom extends IntProvider {
private SecureRandom delegate;
public class JDKSecureRandom(Long[] seed) {
final byte[] s = NumberFactory.makeByteArray(seed);
delegate = new SecureRandom(s);
}
// ... (same as in "JDKRandom")
}
{code}
where we'd use the constructor that builds the [default
instance|https://docs.oracle.com/javase/8/docs/api/java/security/SecureRandom.html#SecureRandom-byte:A-]
so that the wrapper is usable on all OSes that support the JDK.
> System generator (/dev/random)
> --
>
> Key: RNG-19
> URL: https://issues.apache.org/jira/browse/RNG-19
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Emmanuel Bourg
>Priority: Minor
>
> Commons RNG could include a random number generator based on the output of
> /dev/random or /dev/urandom on Unix systems.
> Commons Crypto has an implementation that could be used as a starting point:
> https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/random/OsCryptoRandom.java
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-19) System generator (/dev/random)
[
https://issues.apache.org/jira/browse/RNG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919499#comment-16919499
]
Gilles commented on RNG-19:
---
If the aim is to be able to use the "native" generator through the
{{UniformRandomProvider}} API, we could implement a wrapper similar to
[{{JDKRandom}}|https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=blob;f=commons-rng-core/src/main/java/org/apache/commons/rng/core/source32/JDKRandom.java]:
{code:java}
public class JDKSecureRandom extends IntProvider {
private SecureRandom delegate;
public class JDKSecureRandom(Long[] seed) {
final byte[] s = NumberFactory.makeByteArray(seed);
delegate = new SecureRandom(s);
}
// ... (same as in "JDKRandom")
}
{code}
where we'd use the constructor that builds the [default
instance|https://docs.oracle.com/javase/8/docs/api/java/security/SecureRandom.html#SecureRandom-byte:A-]
so that the wrapper is usable on all OSes that support the JDK.
> System generator (/dev/random)
> --
>
> Key: RNG-19
> URL: https://issues.apache.org/jira/browse/RNG-19
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Emmanuel Bourg
>Priority: Minor
>
> Commons RNG could include a random number generator based on the output of
> /dev/random or /dev/urandom on Unix systems.
> Commons Crypto has an implementation that could be used as a starting point:
> https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/random/OsCryptoRandom.java
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MATH-1494) Find exponential curve fit to data using Jacquelin method
[ https://issues.apache.org/jira/browse/MATH-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916627#comment-16916627 ] Gilles commented on MATH-1494: -- Discussion is taking place on the [ML|https://markmail.org/message/y33xtunkmoc3rges]. > Find exponential curve fit to data using Jacquelin method > - > > Key: MATH-1494 > URL: https://issues.apache.org/jira/browse/MATH-1494 > Project: Commons Math > Issue Type: New Feature >Reporter: Tom Prodehl >Priority: Major > Labels: curvefitter, exponential, fitting > Fix For: 4.0 > > Original Estimate: 336h > Time Spent: 10m > Remaining Estimate: 335h 50m > > Function to fit an exponential decay (negarive beta) or positive beta without > initial guessing > Based on [https://stackoverflow.com/a/39436209/545346] > Original source: Regressions et Equations integrales, Jean Jacquelin > [https://www.scribd.com/doc/14674814/Regressions-et-equations-integrales] > The class will allow for the usual variety of providing inputs of x and y. > Once computed the instance can be queried for Amplitude, Beta, and Constant, > defining a curve for y= Amplitude * exp(Beta * x) + Constant -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEOMETRY-60) JDK 13 Build Fails
[ https://issues.apache.org/jira/browse/GEOMETRY-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915767#comment-16915767 ] Gilles commented on GEOMETRY-60: I'd prefer that we [follow this proposal on the ML|https://markmail.org/message/obiklp3oeuu7y2fc]. Then we also need to fix the project so that it build on the [Jenkins Apache CI system|https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry/]. An alternative [Jenkins project|https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry-fix/] seems to have fixed it. > JDK 13 Build Fails > -- > > Key: GEOMETRY-60 > URL: https://issues.apache.org/jira/browse/GEOMETRY-60 > Project: Apache Commons Geometry > Issue Type: Bug >Reporter: Matt Juntunen >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The build for JDK 13 is failing on Travis. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MATH-1490) Percentile computational accuracy issue
[
https://issues.apache.org/jira/browse/MATH-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914937#comment-16914937
]
Gilles commented on MATH-1490:
--
I've done it. So:
{noformat}
$ git diff MATH_3_3 MATH_3_4 --
src/main/java/org/apache/commons/math3/stat/descriptive/rank/Percentile.java
{noformat}
displays a large number of changes between v3.3 and v3.4 (in order to add new
features).
I'm not too surprised that this could entail a 1e-15 relative change of the
output. Moreover, the unit tests show an expected level of precision much lower
than that (although I admit that it's not clear why).
{quote}it breaks my existing code. I got an incompatible error.
{quote}
Could you elaborate a little?
> Percentile computational accuracy issue
> ---
>
> Key: MATH-1490
> URL: https://issues.apache.org/jira/browse/MATH-1490
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.4, 3.4.1, 3.5, 3.6, 3.6.1
> Environment: System: Linux testinglab 4.4.0-131-generic
> #157~14.04.1-Ubuntu
> Java version "1.8.0_191"
> Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
>
>
>Reporter: xia0c
>Assignee: Rob Tompkins
>Priority: Major
> Labels: performance
> Attachments: BugDemo.java
>
>
> The percentile method works well on the older versions, e.g., the version
> before 3.4. However, when I update commons-math to the newer version, there
> produces a computational accuracy issue. There is a backward compatibility
> bug behind it.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MATH-1490) Percentile computational accuracy issue
[ https://issues.apache.org/jira/browse/MATH-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914729#comment-16914729 ] Gilles commented on MATH-1490: -- I'm asking that you please check whether the _Commons_ _Math_ (CM) code was modified by the developers team, i.e. the code which you _call_ (to get the number "68.95"). > Percentile computational accuracy issue > --- > > Key: MATH-1490 > URL: https://issues.apache.org/jira/browse/MATH-1490 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.4, 3.4.1, 3.5, 3.6, 3.6.1 > Environment: System: Linux testinglab 4.4.0-131-generic > #157~14.04.1-Ubuntu > Java version "1.8.0_191" > Java(TM) SE Runtime Environment (build 1.8.0_191-b12) > Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) > > >Reporter: xia0c >Assignee: Rob Tompkins >Priority: Major > Labels: performance > Attachments: BugDemo.java > > > The percentile method works well on the older versions, e.g., the version > before 3.4. However, when I update commons-math to the newer version, there > produces a computational accuracy issue. There is a backward compatibility > bug behind it. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MATH-1490) Percentile computational accuracy issue
[ https://issues.apache.org/jira/browse/MATH-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914717#comment-16914717 ] Gilles commented on MATH-1490: -- Did the CM code change (from when it produced your expected to when it doesn't anymore)? > Percentile computational accuracy issue > --- > > Key: MATH-1490 > URL: https://issues.apache.org/jira/browse/MATH-1490 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.4, 3.4.1, 3.5, 3.6, 3.6.1 > Environment: System: Linux testinglab 4.4.0-131-generic > #157~14.04.1-Ubuntu > Java version "1.8.0_191" > Java(TM) SE Runtime Environment (build 1.8.0_191-b12) > Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) > > >Reporter: xia0c >Assignee: Rob Tompkins >Priority: Major > Labels: performance > Attachments: BugDemo.java > > > The percentile method works well on the older versions, e.g., the version > before 3.4. However, when I update commons-math to the newer version, there > produces a computational accuracy issue. There is a backward compatibility > bug behind it. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (RNG-76) Add a primitive constructor to SplitMix64
[
https://issues.apache.org/jira/browse/RNG-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913306#comment-16913306
]
Gilles commented on RNG-76:
---
Is it necessary to change the other constructor (with a {{Long}} argument)?
For that non performance-critical constructor, I'd rather keep the uniformity
of the design (using {{setSeedInternal}}).
And to make it clear why the other constructor is added, that method could be
modified to avoid implicit unboxing:
{code}
private void setSeedInternal(Long seed) {
state = seed.longValue();
}
{code}
> Add a primitive constructor to SplitMix64
> -
>
> Key: RNG-76
> URL: https://issues.apache.org/jira/browse/RNG-76
> Project: Commons RNG
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The constructor for {{SplitMix64}} uses a {{Long}} for the seed. If
> constructed using a primitive {{long}} then auto-boxing will occur.
> I added a {{long}} version of the constructor to SplitMix64:
> {code:java}
> SplitMix64(Long seed);
> SplitMix64(long seed);
> {code}
> I modified the {{ConstructionPerformance}} benchmark to generate 5000 random
> seeds as {{Long}} or {{long}} then tested:
> {code:java}
> // Pre-generated Long
> new SplitMix64(Long seed);
> // Pre-generated long that is boxed to Long
> new SplitMix64(Long.valueOf(long seed));
> // Pre-generated long
> new SplitMix64(long seed);
> {code}
> Results:
> ||Method||Score||Error||Median||
> |newSplitMix64Long|34.70|0.85|34.57|
> |newSplitMix64LongValueOf|55.84|5.38|55.91|
> |newSplitMix64long|32.66|1.49|32.46|
> Given that the {{SplitMix64}} is the preferred RNG for seeding from a single
> {{long}} value it makes sense to add the constructor version that accepts a
> {{long}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MATH-1494) Find exponential curve fit to data using Jacquelin method
[
https://issues.apache.org/jira/browse/MATH-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911228#comment-16911228
]
Gilles commented on MATH-1494:
--
Thanks for your interest in contributing.
There are however several issues with the
[PR|https://github.com/apache/commons-math/pull/112]:
* the unit test file is missing a license header (hence the [Travis
failure|https://travis-ci.org/apache/commons-math/builds/574043415?utm_source=github_status_medium=notification]),
* the code is missing Javadoc (everything, including {{private}} fields and
methods, must commented; see other files in the library)
* non-trivial functionality should be commented with code comments (for future
maintenance),
* source must follow a common code style (e.g. no "_" in identifiers).
* instantiation of exceptions, e.g.:
{code:java}
throw new DimensionMismatchException(new DummyLocalizable("Array lengths must
be equal"), x.length, y.length);
{code}
should rather just be
{code:java}
throw new DimensionMismatchException(x.length, y.length);
{code}
In general, prior to open of PR, you should run
{noformat}
$ mvn clean site
{noformat}
Then, web pages are generated (in the "target/site" directory), and a "Project
Reports" link will list many issues that can potentially prevent merging into
the "master" branch (look especially at the "CheckStyle" and "FindBugs"
reports).
About unit tests:
* there should be one test method per tested functionality, e.g.:
{{testEvaluate()}}, {{testEvaluateUnsorted()}},
{{testEvaluateUnsortedArray()}}, and so on,
* exceptions (e.g. preconditions) should be tested too (see other files).
All these can be easily fixed; however, as I indicated previously, your
proposed contribution does not fit within the current design of the
{{o.a.c.m.fitting}} package.
The radically different approach to estimate the parameters makes it unsuitable
to simply drop it there. [Design
decisions|http://www.apache.org/foundation/governance/pmcs.html#communication]
must happen on the ["dev" ML|http://commons.apache.org/mail-lists.html]; so a
discussion _must_ be started there.
Does a reference paper exist in English?
> Find exponential curve fit to data using Jacquelin method
> -
>
> Key: MATH-1494
> URL: https://issues.apache.org/jira/browse/MATH-1494
> Project: Commons Math
> Issue Type: New Feature
>Reporter: Tom Prodehl
>Priority: Major
> Labels: curvefitter, exponential, fitting
> Fix For: 4.0
>
> Original Estimate: 336h
> Time Spent: 10m
> Remaining Estimate: 335h 50m
>
> Function to fit an exponential decay (negarive beta) or positive beta without
> initial guessing
> Based on [https://stackoverflow.com/a/39436209/545346]
> Original source: Regressions et Equations integrales, Jean Jacquelin
> [https://www.scribd.com/doc/14674814/Regressions-et-equations-integrales]
> The class will allow for the usual variety of providing inputs of x and y.
> Once computed the instance can be queried for Amplitude, Beta, and Constant,
> defining a curve for y= Amplitude * exp(Beta * x) + Constant
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-113) Speed improvement to PCG 32 Xsh-Rs implementation
[
https://issues.apache.org/jira/browse/RNG-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909757#comment-16909757
]
Gilles commented on RNG-113:
bq. It is an IntProvider because it outputs 32-bits of randomness per cycle.
Isn't it producing more than 32 bits, but less than 64 bits?
bq. require that the private state member and bump() method of the parent
AbstractPcg6432 are made accessible.
I'm reluctant to break encapsulation.
Enabling this kind of optimization also breaks the relative simplicity of the
framework's design; IIUC this case would (perhaps) have benefited from an
interface like
{code}
/**
* @param n Number of random bits.
* @return a number where the {@code n} higher bits are random.
* No promise on the quality of the {@code 64 - n} lower bits.
*/
long next(int n);
{code}
(perhaps) at the cost of a less optimal performance for other algorithms.
Being based on {{IntProvider}} and {{LongProvider}}, the framework requires
"tweaking" here.
IMHO it's not worth it, even if the performance boost is noticeable. Could it
be that the 5% ~ 10% improvement is reflecting the difference in the number of
method calls (4 for the base implementation vs 1 for your optimized one)?
If a user needs so many {{long}} and {{double}} values that a 10% boost would
be significant, won't he be better off anyways using one of the
{{LongProvider}} implementations?
> Speed improvement to PCG 32 Xsh-Rs implementation
> -
>
> Key: RNG-113
> URL: https://issues.apache.org/jira/browse/RNG-113
> Project: Commons RNG
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Priority: Minor
>
> Investigate a possible speed increase for the PCG 32 Xsh-Rs generator for the
> methods nextLong and nextDouble.
> The default implementation for nextLong() and nextDouble() for IntProvider is:
> {code:java}
> public long nextLong() {
> return NumberFactory.makeLong(nextInt(), nextInt());
> }
> public double nextDouble() {
> return NumberFactory.makeDouble(nextInt(), nextInt());
> }
> {code}
> Each of these methods composes a long from two int values converted to long.
> The Pcg32 implementation of nextInt() creates the int from a primitive cast
> conversion of a long. *Thus the current default implementation for nextLong
> and nextDouble is performing a round trip of a long to an int to a long twice
> over.* The same logic can be implemented by a special implementation of the
> methods that work only using long types.
> {code:java}
> public long nextLong() {
> // Get two values from the LCG
> final long x = state;
> final long y = bump(state);
> state = bump(y);
> // Perform mix function.
> // For a 32-bit output the x bits should be shifted down (22 + (int) (x
> >>> 61)).
> // Leave in the upper bits by shift up 32 - (22 + (int) (x >>> 61))
> final long upper = (x ^ (x >>> 22)) << (10 - (int) (x >>> 61));
> final long lower = (y ^ (y >>> 22)) >>> (22 + (int) (y >>> 61));
> return (upper & 0xL) | (lower & 0xL);
> }
> /** Upper mask for top 26 bits shifted by 27 bits. */
> private static final long MASK1 = ((long) (0x >>> 6)) << 27;
> /** Lower mask shifted by 5 for 27 bits. */
> private static final long MASK2 = 0xL >>> 5;
> public double nextDouble() {
> // Get two values from the LCG
> final long x = state;
> final long y = bump(state);
> state = bump(y);
> // Perform mix function.
> // For a 32-bit output the x bits should be shifted down (22 + (int) (x
> >>> 61)).
> // To match nextDouble requires 26-bits from int 1 and 27 bits from int 2.
> // Int 1 is stored in the upper 32-bits as per nextLong() but shifted
> down 11 and
> // then masked to keep the upper 26-bits. Discard an extra 5 from int 2.
> final long upper = (x ^ (x >>> 22)) >>> (1 + (int) (x >>> 61));
> final long lower = (y ^ (y >>> 22)) >>> (27 + (int) (y >>> 61));
> return ((upper & MASK1) | (lower & MASK2)) * 0x1.0p-53;
> }
> {code}
> These implementations require that the private {{state}} member and
> {{bump()}} method of the parent AbstractPcg6432 are made accessible.
> The change should be tested to determine if there is a performance increase
> with a custom implementation.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909458#comment-16909458
]
Gilles commented on GEOMETRY-32:
bq. draft PR
If this is potentially ready to go into "master", could you make a new PR with
a single commit?
> 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: 20m
> 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.14#76016)
[jira] [Commented] (RNG-113) Speed improvement to PCG 32 Xsh-Rs implementation
[
https://issues.apache.org/jira/browse/RNG-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909455#comment-16909455
]
Gilles commented on RNG-113:
bq. The Pcg32 implementation of nextInt() creates the int from a primitive cast
conversion of a long.
Why isn't Pcg32 a {{LongProvider}}?
> Speed improvement to PCG 32 Xsh-Rs implementation
> -
>
> Key: RNG-113
> URL: https://issues.apache.org/jira/browse/RNG-113
> Project: Commons RNG
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Priority: Minor
>
> Investigate a possible speed increase for the PCG 32 Xsh-Rs generator for the
> methods nextLong and nextDouble.
> The default implementation for nextLong() and nextDouble() for IntProvider is:
> {code:java}
> public long nextLong() {
> return NumberFactory.makeLong(nextInt(), nextInt());
> }
> public double nextDouble() {
> return NumberFactory.makeDouble(nextInt(), nextInt());
> }
> {code}
> Each of these methods composes a long from two int values converted to long.
> The Pcg32 implementation of nextInt() creates the int from a primitive cast
> conversion of a long. *Thus the current default implementation for nextLong
> and nextDouble is performing a round trip of a long to an int to a long twice
> over.* The same logic can be implemented by a special implementation of the
> methods that work only using long types.
> {code:java}
> public long nextLong() {
> // Get two values from the LCG
> final long x = state;
> final long y = bump(state);
> state = bump(y);
> // Perform mix function.
> // For a 32-bit output the x bits should be shifted down (22 + (int) (x
> >>> 61)).
> // Leave in the upper bits by shift up 32 - (22 + (int) (x >>> 61))
> final long upper = (x ^ (x >>> 22)) << (10 - (int) (x >>> 61));
> final long lower = (y ^ (y >>> 22)) >>> (22 + (int) (y >>> 61));
> return (upper & 0xL) | (lower & 0xL);
> }
> /** Upper mask for top 26 bits shifted by 27 bits. */
> private static final long MASK1 = ((long) (0x >>> 6)) << 27;
> /** Lower mask shifted by 5 for 27 bits. */
> private static final long MASK2 = 0xL >>> 5;
> public double nextDouble() {
> // Get two values from the LCG
> final long x = state;
> final long y = bump(state);
> state = bump(y);
> // Perform mix function.
> // For a 32-bit output the x bits should be shifted down (22 + (int) (x
> >>> 61)).
> // To match nextDouble requires 26-bits from int 1 and 27 bits from int 2.
> // Int 1 is stored in the upper 32-bits as per nextLong() but shifted
> down 11 and
> // then masked to keep the upper 26-bits. Discard an extra 5 from int 2.
> final long upper = (x ^ (x >>> 22)) >>> (1 + (int) (x >>> 61));
> final long lower = (y ^ (y >>> 22)) >>> (27 + (int) (y >>> 61));
> return ((upper & MASK1) | (lower & MASK2)) * 0x1.0p-53;
> }
> {code}
> These implementations require that the private {{state}} member and
> {{bump()}} method of the parent AbstractPcg6432 are made accessible.
> The change should be tested to determine if there is a performance increase
> with a custom implementation.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MATH-1495) Calling NaturalRanking#rank() on an array of all NaNs throws a misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
[
https://issues.apache.org/jira/browse/MATH-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907134#comment-16907134
]
Gilles commented on MATH-1495:
--
Thanks for pursuing this.
bq. development version also has the same problem
Then please submit a PR (and provide the link here). Note that the PR should be
a single commit.
But before that, please post a message to the "dev" ML to ensure that nobody
objects to your proposed fix.
Remarks about the [unit test
code|https://github.com/apache/commons-math/compare/master...Kakarot-SSJ4:out-of-bounds]:
* Field {{naturalranking}} should rather be a local variable,
* method {{AllNaNArray}} should be renamed {{allNaNs}}.
> Calling NaturalRanking#rank() on an array of all NaNs throws a misleading
> ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
>
>
> Key: MATH-1495
> URL: https://issues.apache.org/jira/browse/MATH-1495
> Project: Commons Math
> Issue Type: Bug
>Reporter: Akash Srivastava
>Priority: Major
>
> Consider the following code:
> {code:java}
> import org.apache.commons.math3.stat.ranking.NaNStrategy;
> import org.apache.commons.math3.stat.ranking.NaturalRanking;
> import org.apache.commons.math3.stat.ranking.TiesStrategy;
> class AllNaNException{
> public NaturalRanking naturalranking;
> public double[] AllNaNArray(){
> naturalranking = new NaturalRanking(NaNStrategy.REMOVED,
> TiesStrategy.AVERAGE);
> double[] x = {Double.NaN, Double.NaN};
> double[] y = naturalranking.rank(x);
> return y;
> }
> public static void main(String[] args) {
> AllNaNException a = new AllNaNException();
> double[] res = a.bug();
> System.out.println(res[0] + "," + res[1]);
> }
> }
> {code}
> Compiled it by: javac -cp /usr/share/java/commons-math3-3.6.1.jar tryit.java
> Executed it by: java -cp /usr/share/java/commons-math3-3.6.1.jar:. tryit
>
> Output:
> {code:java}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.commons.math3.stat.ranking.NaturalRanking.rank(NaturalRanking.java:231)
> at tryit.bug(tryit.java:9)
> at tryit.main(tryit.java:14)
> {code}
>
> Currently, calling NaturalRanking#rank() on an array of all NaNs throws a
> misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED. I
> am unsure what outcome the user should expect in code like the test case I
> have provided below. Can you shed some light on this? I am happy to write a
> pull request once I know what fix would be best. I think throwing an
> IllegalArgumentException or returning an empty array would be more apt in
> this case.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MATH-1495) Calling NaturalRanking#rank() on an array of all NaNs throws a misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
[
https://issues.apache.org/jira/browse/MATH-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906336#comment-16906336
]
Gilles commented on MATH-1495:
--
{quote}I'm using [...] commons-math4-4.0-SNAPSHOT.jar
{quote}
I suspect a usage problem: That file contains the "Commons Math" library but
_not_ the "Commons RNG" library. I guess (?) that you still use the command
{noformat}
java -cp /usr/share/java/commons-math3-3.6.1.jar:. tryit
{noformat}
If so, it is your responsibility to provide a "classpath" with *all* the
dependencies.
The simpler alternative which I suggested was to modify your copy of the
repository by adding your test along the [other unit
tests|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/test/java/org/apache/commons/math4/stat/ranking/NaturalRankingTest.java].
> Calling NaturalRanking#rank() on an array of all NaNs throws a misleading
> ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
>
>
> Key: MATH-1495
> URL: https://issues.apache.org/jira/browse/MATH-1495
> Project: Commons Math
> Issue Type: Bug
>Reporter: Akash Srivastava
>Priority: Major
>
> Consider the following code:
> {code:java}
> import org.apache.commons.math3.stat.ranking.NaNStrategy;
> import org.apache.commons.math3.stat.ranking.NaturalRanking;
> import org.apache.commons.math3.stat.ranking.TiesStrategy;
> class AllNaNException{
> public NaturalRanking naturalranking;
> public double[] AllNaNArray(){
> naturalranking = new NaturalRanking(NaNStrategy.REMOVED,
> TiesStrategy.AVERAGE);
> double[] x = {Double.NaN, Double.NaN};
> double[] y = naturalranking.rank(x);
> return y;
> }
> public static void main(String[] args) {
> AllNaNException a = new AllNaNException();
> double[] res = a.bug();
> System.out.println(res[0] + "," + res[1]);
> }
> }
> {code}
> Compiled it by: javac -cp /usr/share/java/commons-math3-3.6.1.jar tryit.java
> Executed it by: java -cp /usr/share/java/commons-math3-3.6.1.jar:. tryit
>
> Output:
> {code:java}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.commons.math3.stat.ranking.NaturalRanking.rank(NaturalRanking.java:231)
> at tryit.bug(tryit.java:9)
> at tryit.main(tryit.java:14)
> {code}
>
> Currently, calling NaturalRanking#rank() on an array of all NaNs throws a
> misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED. I
> am unsure what outcome the user should expect in code like the test case I
> have provided below. Can you shed some light on this? I am happy to write a
> pull request once I know what fix would be best. I think throwing an
> IllegalArgumentException or returning an empty array would be more apt in
> this case.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MATH-1495) Calling NaturalRanking#rank() on an array of all NaNs throws a misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
[
https://issues.apache.org/jira/browse/MATH-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906069#comment-16906069
]
Gilles commented on MATH-1495:
--
Do you have a publicly visible repository?
> Calling NaturalRanking#rank() on an array of all NaNs throws a misleading
> ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
>
>
> Key: MATH-1495
> URL: https://issues.apache.org/jira/browse/MATH-1495
> Project: Commons Math
> Issue Type: Bug
>Reporter: Akash Srivastava
>Priority: Major
>
> Consider the following code:
> {code:java}
> import org.apache.commons.math3.stat.ranking.NaNStrategy;
> import org.apache.commons.math3.stat.ranking.NaturalRanking;
> import org.apache.commons.math3.stat.ranking.TiesStrategy;
> class AllNaNException{
> public NaturalRanking naturalranking;
> public double[] AllNaNArray(){
> naturalranking = new NaturalRanking(NaNStrategy.REMOVED,
> TiesStrategy.AVERAGE);
> double[] x = {Double.NaN, Double.NaN};
> double[] y = naturalranking.rank(x);
> return y;
> }
> public static void main(String[] args) {
> AllNaNException a = new AllNaNException();
> double[] res = a.bug();
> System.out.println(res[0] + "," + res[1]);
> }
> }
> {code}
> Compiled it by: javac -cp /usr/share/java/commons-math3-3.6.1.jar tryit.java
> Executed it by: java -cp /usr/share/java/commons-math3-3.6.1.jar:. tryit
>
> Output:
> {code:java}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.commons.math3.stat.ranking.NaturalRanking.rank(NaturalRanking.java:231)
> at tryit.bug(tryit.java:9)
> at tryit.main(tryit.java:14)
> {code}
>
> Currently, calling NaturalRanking#rank() on an array of all NaNs throws a
> misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED. I
> am unsure what outcome the user should expect in code like the test case I
> have provided below. Can you shed some light on this? I am happy to write a
> pull request once I know what fix would be best. I think throwing an
> IllegalArgumentException or returning an empty array would be more apt in
> this case.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MATH-1495) Calling NaturalRanking#rank() on an array of all NaNs throws a misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
[
https://issues.apache.org/jira/browse/MATH-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904604#comment-16904604
]
Gilles edited comment on MATH-1495 at 8/11/19 9:48 AM:
---
{quote}class file for org.apache.commons.rng.UniformRandomProvider not found
{quote}
You are missing new dependencies (e.g. ["Commons
RNG"|https://mvnrepository.com/artifact/org.apache.commons/commons-rng-simple],
for the above error)
Simplest would be to clone/fork the [project's
repository|https://gitbox.apache.org/repos/asf?p=commons-math.git] and create a
unit test.
Then, you should just run
{noformat}
mvn test
{noformat}
and "maven" would take care of downloading the dependencies.
Also possible is to check [which dependencies are
needed|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=pom.xml]
and download them manually (note that some of them are
[snapshots|https://repository.apache.org/content/repositories/snapshots/org/apache/commons/]).
was (Author: erans):
bq. class file for org.apache.commons.rng.UniformRandomProvider not found
You are missing new dependencies.
Simplest would be to clone/fork the [project's
repository|https://gitbox.apache.org/repos/asf?p=commons-math.git] and create a
unit test.
Then, you should just run
{noformat}
mvn test
{noformat}
and "maven" would take care of downloading the dependencies.
> Calling NaturalRanking#rank() on an array of all NaNs throws a misleading
> ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
>
>
> Key: MATH-1495
> URL: https://issues.apache.org/jira/browse/MATH-1495
> Project: Commons Math
> Issue Type: Bug
>Reporter: Akash Srivastava
>Priority: Major
>
> Consider the following code:
> {code:java}
> import org.apache.commons.math3.stat.ranking.NaNStrategy;
> import org.apache.commons.math3.stat.ranking.NaturalRanking;
> import org.apache.commons.math3.stat.ranking.TiesStrategy;
> class AllNaNException{
> public NaturalRanking naturalranking;
> public double[] AllNaNArray(){
> naturalranking = new NaturalRanking(NaNStrategy.REMOVED,
> TiesStrategy.AVERAGE);
> double[] x = {Double.NaN, Double.NaN};
> double[] y = naturalranking.rank(x);
> return y;
> }
> public static void main(String[] args) {
> AllNaNException a = new AllNaNException();
> double[] res = a.bug();
> System.out.println(res[0] + "," + res[1]);
> }
> }
> {code}
> Compiled it by: javac -cp /usr/share/java/commons-math3-3.6.1.jar tryit.java
> Executed it by: java -cp /usr/share/java/commons-math3-3.6.1.jar:. tryit
>
> Output:
> {code:java}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.commons.math3.stat.ranking.NaturalRanking.rank(NaturalRanking.java:231)
> at tryit.bug(tryit.java:9)
> at tryit.main(tryit.java:14)
> {code}
>
> Currently, calling NaturalRanking#rank() on an array of all NaNs throws a
> misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED. I
> am unsure what outcome the user should expect in code like the test case I
> have provided below. Can you shed some light on this? I am happy to write a
> pull request once I know what fix would be best. I think throwing an
> IllegalArgumentException or returning an empty array would be more apt in
> this case.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MATH-1495) Calling NaturalRanking#rank() on an array of all NaNs throws a misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
[
https://issues.apache.org/jira/browse/MATH-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904604#comment-16904604
]
Gilles edited comment on MATH-1495 at 8/11/19 9:31 AM:
---
bq. class file for org.apache.commons.rng.UniformRandomProvider not found
You are missing new dependencies.
Simplest would be to clone/fork the [project's
repository|https://gitbox.apache.org/repos/asf?p=commons-math.git] and create a
unit test.
Then, you should just run
{noformat}
mvn test
{noformat}
and "maven" would take care of downloading the dependencies.
was (Author: erans):
bq. class file for org.apache.commons.rng.UniformRandomProvider not found
You are missing new dependencies.
Simplest would be to clone/fork the [project's
repository|https://gitbox.apache.org/repos/asf?p=commons-math.git] and create a
unit test.
Then, you should just run
{norformat}
mvn test
{noformat}
and "maven" would take care of downloading the dependencies.
> Calling NaturalRanking#rank() on an array of all NaNs throws a misleading
> ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
>
>
> Key: MATH-1495
> URL: https://issues.apache.org/jira/browse/MATH-1495
> Project: Commons Math
> Issue Type: Bug
>Reporter: Akash Srivastava
>Priority: Major
>
> Consider the following code:
> {code:java}
> import org.apache.commons.math3.stat.ranking.NaNStrategy;
> import org.apache.commons.math3.stat.ranking.NaturalRanking;
> import org.apache.commons.math3.stat.ranking.TiesStrategy;
> class AllNaNException{
> public NaturalRanking naturalranking;
> public double[] AllNaNArray(){
> naturalranking = new NaturalRanking(NaNStrategy.REMOVED,
> TiesStrategy.AVERAGE);
> double[] x = {Double.NaN, Double.NaN};
> double[] y = naturalranking.rank(x);
> return y;
> }
> public static void main(String[] args) {
> AllNaNException a = new AllNaNException();
> double[] res = a.bug();
> System.out.println(res[0] + "," + res[1]);
> }
> }
> {code}
> Compiled it by: javac -cp /usr/share/java/commons-math3-3.6.1.jar tryit.java
> Executed it by: java -cp /usr/share/java/commons-math3-3.6.1.jar:. tryit
>
> Output:
> {code:java}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.commons.math3.stat.ranking.NaturalRanking.rank(NaturalRanking.java:231)
> at tryit.bug(tryit.java:9)
> at tryit.main(tryit.java:14)
> {code}
>
> Currently, calling NaturalRanking#rank() on an array of all NaNs throws a
> misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED. I
> am unsure what outcome the user should expect in code like the test case I
> have provided below. Can you shed some light on this? I am happy to write a
> pull request once I know what fix would be best. I think throwing an
> IllegalArgumentException or returning an empty array would be more apt in
> this case.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MATH-1495) Calling NaturalRanking#rank() on an array of all NaNs throws a misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
[
https://issues.apache.org/jira/browse/MATH-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904604#comment-16904604
]
Gilles commented on MATH-1495:
--
bq. class file for org.apache.commons.rng.UniformRandomProvider not found
You are missing new dependencies.
Simplest would be to clone/fork the [project's
repository|https://gitbox.apache.org/repos/asf?p=commons-math.git] and create a
unit test.
Then, you should just run
{norformat}
mvn test
{noformat}
and "maven" would take care of downloading the dependencies.
> Calling NaturalRanking#rank() on an array of all NaNs throws a misleading
> ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
>
>
> Key: MATH-1495
> URL: https://issues.apache.org/jira/browse/MATH-1495
> Project: Commons Math
> Issue Type: Bug
>Reporter: Akash Srivastava
>Priority: Major
>
> Consider the following code:
> {code:java}
> import org.apache.commons.math3.stat.ranking.NaNStrategy;
> import org.apache.commons.math3.stat.ranking.NaturalRanking;
> import org.apache.commons.math3.stat.ranking.TiesStrategy;
> class AllNaNException{
> public NaturalRanking naturalranking;
> public double[] AllNaNArray(){
> naturalranking = new NaturalRanking(NaNStrategy.REMOVED,
> TiesStrategy.AVERAGE);
> double[] x = {Double.NaN, Double.NaN};
> double[] y = naturalranking.rank(x);
> return y;
> }
> public static void main(String[] args) {
> AllNaNException a = new AllNaNException();
> double[] res = a.bug();
> System.out.println(res[0] + "," + res[1]);
> }
> }
> {code}
> Compiled it by: javac -cp /usr/share/java/commons-math3-3.6.1.jar tryit.java
> Executed it by: java -cp /usr/share/java/commons-math3-3.6.1.jar:. tryit
>
> Output:
> {code:java}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.commons.math3.stat.ranking.NaturalRanking.rank(NaturalRanking.java:231)
> at tryit.bug(tryit.java:9)
> at tryit.main(tryit.java:14)
> {code}
>
> Currently, calling NaturalRanking#rank() on an array of all NaNs throws a
> misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED. I
> am unsure what outcome the user should expect in code like the test case I
> have provided below. Can you shed some light on this? I am happy to write a
> pull request once I know what fix would be best. I think throwing an
> IllegalArgumentException or returning an empty array would be more apt in
> this case.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MATH-1495) Calling NaturalRanking#rank() on an array of all NaNs throws a misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
[
https://issues.apache.org/jira/browse/MATH-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903818#comment-16903818
]
Gilles commented on MATH-1495:
--
bq. ArrayIndexOutOfBoundsException
I agree that it should not be the expected outcome.
Is the behaviour the same in the development version?
> Calling NaturalRanking#rank() on an array of all NaNs throws a misleading
> ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
>
>
> Key: MATH-1495
> URL: https://issues.apache.org/jira/browse/MATH-1495
> Project: Commons Math
> Issue Type: Bug
>Reporter: Akash Srivastava
>Priority: Major
>
> Consider the following code:
> {code:java}
> import org.apache.commons.math3.stat.ranking.NaNStrategy;
> import org.apache.commons.math3.stat.ranking.NaturalRanking;
> import org.apache.commons.math3.stat.ranking.TiesStrategy;
> class AllNaNException{
> public NaturalRanking naturalranking;
> public double[] AllNaNArray(){
> naturalranking = new NaturalRanking(NaNStrategy.REMOVED,
> TiesStrategy.AVERAGE);
> double[] x = {Double.NaN, Double.NaN};
> double[] y = naturalranking.rank(x);
> return y;
> }
> public static void main(String[] args) {
> AllNaNException a = new AllNaNException();
> double[] res = a.bug();
> System.out.println(res[0] + "," + res[1]);
> }
> }
> {code}
> Compiled it by: javac -cp /usr/share/java/commons-math3-3.6.1.jar tryit.java
> Executed it by: java -cp /usr/share/java/commons-math3-3.6.1.jar:. tryit
>
> Output:
> {code:java}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.commons.math3.stat.ranking.NaturalRanking.rank(NaturalRanking.java:231)
> at tryit.bug(tryit.java:9)
> at tryit.main(tryit.java:14)
> {code}
>
> Currently, calling NaturalRanking#rank() on an array of all NaNs throws a
> misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED. I
> am unsure what outcome the user should expect in code like the test case I
> have provided below. Can you shed some light on this? I am happy to write a
> pull request once I know what fix would be best. I think throwing an
> IllegalArgumentException or returning an empty array would be more apt in
> this case.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (NUMBERS-99) Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
[
https://issues.apache.org/jira/browse/NUMBERS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903809#comment-16903809
]
Gilles commented on NUMBERS-99:
---
bq. simply not requiring the stored denominator to be positive, but this would
probably break a lot of functionality
Internal functionality? That should be fixable; otherwise, "simply" is not the
right word ;-)
As far as external is concerned, there is no requirement to stick with a
decision implicitly made when those classes were in "Commons Math", especially
if they entail a bug.
> Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
>
>
> Key: NUMBERS-99
> URL: https://issues.apache.org/jira/browse/NUMBERS-99
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The methods {{add(int)}} and {{subtract(int)}} in the class
> {{org.apache.commons.numbers.fraction.Fraction}} do not take into account the
> risk of an integer overflow. For example, (2^31^ - 1)/2 + 1 = (2^31^ +
> 1)/2, so the numerator overflows an {{int}}, but when calculated with
> {{Fraction.add(int)}}, the method still returns normally.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (NUMBERS-123) "BigFraction(double)" is unnecessary
[
https://issues.apache.org/jira/browse/NUMBERS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved NUMBERS-123.
Resolution: Done
> "BigFraction(double)" is unnecessary
>
>
> Key: NUMBERS-123
> URL: https://issues.apache.org/jira/browse/NUMBERS-123
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 1.0
>
> Attachments: NUMBERS-123__Javadoc.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Constructor {{BigFraction(double value)}} is only called from the
> {{from(double value)}} method.
> Actually, this constructor is misleading as it is indeed primarily a
> conversion from which appropriate {{numerator}} and {{denominator}} fields
> are computed; those could be set by
> the "direct" constructor {{BigFraction(BigInteger num, BigInteger den)}}.
> Moreover, the private field {{ZERO}} goes through this conversion code
> whereas it could constructed "directly", e.g. using {{of(0)}}. Similarly for
> field {{ONE}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (NUMBERS-133) Speed up Primes.nextPrime(int)
[
https://issues.apache.org/jira/browse/NUMBERS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903804#comment-16903804
]
Gilles commented on NUMBERS-133:
The other advantage of MathJaX/LaTeX (vs Unicode characters?) is that some
(text-based) softwares (e.g. "git diff") do not show the glyphs and display
rather "cryptic" sequences of characters. Which makes it fairly annoying to
review...
> Speed up Primes.nextPrime(int)
> --
>
> Key: NUMBERS-133
> URL: https://issues.apache.org/jira/browse/NUMBERS-133
> Project: Commons Numbers
> Issue Type: Improvement
> Components: primes
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The method {{Primes.nextPrime(int)}} can use the same algorithm to skip
> multiples of certain primes as {{SmallPrimes.boundedTrialDivision(int, int,
> List)}} uses, instead of hard-coding the alternating increment of
> the trial candidate into a loop.
> Also, if the argument of the method is smaller than or equal to the 512th
> prime number, the method can just infer the next higher prime number directly
> from the array {{SmallPrimes.PRIMES}} without performing any calculations.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (NUMBERS-133) Speed up Primes.nextPrime(int)
[
https://issues.apache.org/jira/browse/NUMBERS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903803#comment-16903803
]
Gilles commented on NUMBERS-133:
The rule of thumb would to use MathJaX for any formula that would make it
easier to read (rendered or not).
The bar is quite low since even exponents and indices read better in LaTeX:
{noformat}
N_i^k
{noformat}
vs
{noformat}
Ni^k
{noformat}
bq. documentation of private or package-private elements? \[...\] IDEs
generally don't render the MathJax \[...\]
Even so, it's clearer IMO. :-)
When referring to code elements (e.g. variable names), I generally use the
Javadoc "@code" tag:
{code}
/**
* @throws IllegalArgumentException if {@code x <= 0}.
*/
{code}
and the LaTeX syntax for mostly everything else (math-related).
Perhaps we should also provide rendered Javadoc for internal development, where
the private elements are shown (?).
> Speed up Primes.nextPrime(int)
> --
>
> Key: NUMBERS-133
> URL: https://issues.apache.org/jira/browse/NUMBERS-133
> Project: Commons Numbers
> Issue Type: Improvement
> Components: primes
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The method {{Primes.nextPrime(int)}} can use the same algorithm to skip
> multiples of certain primes as {{SmallPrimes.boundedTrialDivision(int, int,
> List)}} uses, instead of hard-coding the alternating increment of
> the trial candidate into a loop.
> Also, if the argument of the method is smaller than or equal to the 512th
> prime number, the method can just infer the next higher prime number directly
> from the array {{SmallPrimes.PRIMES}} without performing any calculations.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (NUMBERS-123) "BigFraction(double)" is unnecessary
[
https://issues.apache.org/jira/browse/NUMBERS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903361#comment-16903361
]
Gilles commented on NUMBERS-123:
bq. then no
As in "This issue must stay open"?
bq. open a separate JIRA ticket
Thus, as in "This issue can be resolved"?
> "BigFraction(double)" is unnecessary
>
>
> Key: NUMBERS-123
> URL: https://issues.apache.org/jira/browse/NUMBERS-123
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 1.0
>
> Attachments: NUMBERS-123__Javadoc.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Constructor {{BigFraction(double value)}} is only called from the
> {{from(double value)}} method.
> Actually, this constructor is misleading as it is indeed primarily a
> conversion from which appropriate {{numerator}} and {{denominator}} fields
> are computed; those could be set by
> the "direct" constructor {{BigFraction(BigInteger num, BigInteger den)}}.
> Moreover, the private field {{ZERO}} goes through this conversion code
> whereas it could constructed "directly", e.g. using {{of(0)}}. Similarly for
> field {{ONE}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (NUMBERS-103) Travis build fails every time based on usage of oraclejdk8
[
https://issues.apache.org/jira/browse/NUMBERS-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903171#comment-16903171
]
Gilles commented on NUMBERS-103:
PR was merged. Can the issue be "resolved"?
> Travis build fails every time based on usage of oraclejdk8
> --
>
> Key: NUMBERS-103
> URL: https://issues.apache.org/jira/browse/NUMBERS-103
> Project: Commons Numbers
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Problem*
> * The Travis build uses {{oraclejdk8}} which is not available on Travis.
> * Remove also {{sudo: false}} which is not supported anymore on Travis.
> *Goal*
> * Replace {{oraclejdk8}} with {{openjdk8}} which will succeed the build.
> * Remove {{sudo: false}}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (NUMBERS-92) Rename AbstractFormat to AbstractFractionFormat
[ https://issues.apache.org/jira/browse/NUMBERS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903169#comment-16903169 ] Gilles commented on NUMBERS-92: --- Seems obsoleted by NUMBERS-97. > Rename AbstractFormat to AbstractFractionFormat > --- > > Key: NUMBERS-92 > URL: https://issues.apache.org/jira/browse/NUMBERS-92 > Project: Commons Numbers > Issue Type: Improvement >Reporter: Eric Barnhill >Assignee: Eric Barnhill >Priority: Minor > > FractionFormat and BigFractionFormat have an abstract class. It is named > AbstractFormat which is too general. Better to call it AbstractFractionFormat > I think. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (NUMBERS-97) Remove commons-numbers-fraction *Format classes
[ https://issues.apache.org/jira/browse/NUMBERS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903165#comment-16903165 ] Gilles commented on NUMBERS-97: --- bq. Remove standalone Format classes This seems to have been done. Can this issue be "resolved"? > Remove commons-numbers-fraction *Format classes > --- > > Key: NUMBERS-97 > URL: https://issues.apache.org/jira/browse/NUMBERS-97 > Project: Commons Numbers > Issue Type: Task >Reporter: Eric Barnhill >Assignee: Eric Barnhill >Priority: Minor > > Remove standalone Format classes in commons-numbers-fraction . > Replace this functionality with VALJO-related parse() and toString() methods > within Fraction and BigFraction -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (NUMBERS-99) Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
[
https://issues.apache.org/jira/browse/NUMBERS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903161#comment-16903161
]
Gilles commented on NUMBERS-99:
---
PR #34 was closed; will you provide another?
> Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
>
>
> Key: NUMBERS-99
> URL: https://issues.apache.org/jira/browse/NUMBERS-99
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The methods {{add(int)}} and {{subtract(int)}} in the class
> {{org.apache.commons.numbers.fraction.Fraction}} do not take into account the
> risk of an integer overflow. For example, (2^31^ - 1)/2 + 1 = (2^31^ +
> 1)/2, so the numerator overflows an {{int}}, but when calculated with
> {{Fraction.add(int)}}, the method still returns normally.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (NUMBERS-133) Speed up Primes.nextPrime(int)
[
https://issues.apache.org/jira/browse/NUMBERS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903106#comment-16903106
]
Gilles commented on NUMBERS-133:
Could please replace special characters (in the Javadoc) by MathJax? Thanks.
> Speed up Primes.nextPrime(int)
> --
>
> Key: NUMBERS-133
> URL: https://issues.apache.org/jira/browse/NUMBERS-133
> Project: Commons Numbers
> Issue Type: Improvement
> Components: primes
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The method {{Primes.nextPrime(int)}} can use the same algorithm to skip
> multiples of certain primes as {{SmallPrimes.boundedTrialDivision(int, int,
> List)}} uses, instead of hard-coding the alternating increment of
> the trial candidate into a loop.
> Also, if the argument of the method is smaller than or equal to the 512th
> prime number, the method can just infer the next higher prime number directly
> from the array {{SmallPrimes.PRIMES}} without performing any calculations.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (NUMBERS-107) Cleanup build configuration - remove not used configurations
[
https://issues.apache.org/jira/browse/NUMBERS-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902995#comment-16902995
]
Gilles commented on NUMBERS-107:
The PR seems to only remove the Clirr config, and not add anything to replace
it. If I'm correct, it cannot be merged as is...
> Cleanup build configuration - remove not used configurations
>
>
> Key: NUMBERS-107
> URL: https://issues.apache.org/jira/browse/NUMBERS-107
> Project: Commons Numbers
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Karl Heinz Marbaise
>Priority: Trivial
> Fix For: 1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Problem*
> * There are entries in {{pom.xml}} and resources directories which are not
> used.
> ** Clirr configuration {{src/main/resources/clirr}}
> ** References in {{doc/release/release.howto.txt}}
> ** {{true}}
> *Goal*
> * Remove the configuration parts which are not used at all
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (NUMBERS-123) "BigFraction(double)" is unnecessary
[
https://issues.apache.org/jira/browse/NUMBERS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902990#comment-16902990
]
Gilles commented on NUMBERS-123:
Can this issue be considered "resolved"?
> "BigFraction(double)" is unnecessary
>
>
> Key: NUMBERS-123
> URL: https://issues.apache.org/jira/browse/NUMBERS-123
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 1.0
>
> Attachments: NUMBERS-123__Javadoc.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Constructor {{BigFraction(double value)}} is only called from the
> {{from(double value)}} method.
> Actually, this constructor is misleading as it is indeed primarily a
> conversion from which appropriate {{numerator}} and {{denominator}} fields
> are computed; those could be set by
> the "direct" constructor {{BigFraction(BigInteger num, BigInteger den)}}.
> Moreover, the private field {{ZERO}} goes through this conversion code
> whereas it could constructed "directly", e.g. using {{of(0)}}. Similarly for
> field {{ONE}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MATH-1494) Find exponential curve fit to data using Jacquelin method
[
https://issues.apache.org/jira/browse/MATH-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902865#comment-16902865
]
Gilles commented on MATH-1494:
--
{quote}pointers
{quote}
Do you intend to contribute via [GitHub|https://github.com/apache/commons-math]?
If not, [here is the repository at
Apache|https://gitbox.apache.org/repos/asf?p=commons-math.git] from which you
can provide patches (to be attached to this JIRA issue).
Associated functionality is in the ["o.a.c.m.fitting"
package|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/fitting]
but IIUC, the implementation would not need the [boiler-plate code currently
assumed by the
design|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math4/fitting/AbstractCurveFitter.java].
That will probably require discussing on the ["dev"
ML|http://commons.apache.org/mail-lists.html].
Please note that "Commons Math" is being refactored into more manageable
chunks: namely new modular components on which the next version will depend:
* [Commons RNG|http://commons.apache.org/proper/commons-rng/]
* [Commons Numbers|http://commons.apache.org/proper/commons-numbers/]
* [Commons Geometry|http://commons.apache.org/proper/commons-geometry/]
* [Commons Statistics|http://commons.apache.org/proper/commons-statistics/]
In particular, we need all the help we can get in order to provide official
releases for the latter three.
"Commons Numbers" would welcome an additional module for function fitting. That
would mean porting the code currently in the ["o.a.c.m.fitting"
package|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/fitting]
package (albeit with a new design targeted at the [Java 8 function
API|https://docs.oracle.com/javase/8/docs/api/java/util/function/DoubleUnaryOperator.html]);
or at least, design the new module towards that goal.
bq. How do I get this assigned to me?
No problem; consider it assigned to you. ;-)
> Find exponential curve fit to data using Jacquelin method
> -
>
> Key: MATH-1494
> URL: https://issues.apache.org/jira/browse/MATH-1494
> Project: Commons Math
> Issue Type: New Feature
>Reporter: Tom Prodehl
>Priority: Major
> Labels: curvefitter, exponential, fitting
> Fix For: 4.0
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> Function to fit an exponential decay (negarive beta) or positive beta without
> initial guessing
> Based on [https://stackoverflow.com/a/39436209/545346]
> Original source: Regressions et Equations integrales, Jean Jacquelin
> [https://www.scribd.com/doc/14674814/Regressions-et-equations-integrales]
> The class will allow for the usual variety of providing inputs of x and y.
> Once computed the instance can be queried for Amplitude, Beta, and Constant,
> defining a curve for y= Amplitude * exp(Beta * x) + Constant
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (RNG-84) PCG
[ https://issues.apache.org/jira/browse/RNG-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896254#comment-16896254 ] Gilles commented on RNG-84: --- [PR #56|https://github.com/apache/commons-rng/pull/56] merged to "master" (commit 070d5637f44230bff1c3f3cd675b8fc5bf3748ab). > PCG > --- > > Key: RNG-84 > URL: https://issues.apache.org/jira/browse/RNG-84 > Project: Commons RNG > Issue Type: Sub-task > Components: core >Reporter: Gilles >Priority: Minor > Labels: gsoc2019 > > From the [author's web page|http://www.pcg-random.org]: > PCG is a family of simple fast space-efficient statistically good algorithms > for random number generation. Unlike many general-purpose RNGs, they are also > hard to predict. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (RNG-84) PCG
[ https://issues.apache.org/jira/browse/RNG-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896050#comment-16896050 ] Gilles commented on RNG-84: --- bq. Where are you looking? I did not read the report correctly (misinterpreting "0 files" as "no file was checked" where it actually means "no file has any error") Sorry for the noise. Will you commit the PR? > PCG > --- > > Key: RNG-84 > URL: https://issues.apache.org/jira/browse/RNG-84 > Project: Commons RNG > Issue Type: Sub-task > Components: core >Reporter: Gilles >Priority: Minor > Labels: gsoc2019 > > From the [author's web page|http://www.pcg-random.org]: > PCG is a family of simple fast space-efficient statistically good algorithms > for random number generation. Unlike many general-purpose RNGs, they are also > hard to predict. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (RNG-84) PCG
[
https://issues.apache.org/jira/browse/RNG-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894747#comment-16894747
]
Gilles commented on RNG-84:
---
Alex,
Running
{noformat}
mvn site site:stage
{noformat}
(with {{JAVA_HOME}} set to the JDK 8 directory), I seem to get an empty
"CheckStyle" report.
> PCG
> ---
>
> Key: RNG-84
> URL: https://issues.apache.org/jira/browse/RNG-84
> Project: Commons RNG
> Issue Type: Sub-task
> Components: core
>Reporter: Gilles
>Priority: Minor
> Labels: gsoc2019
>
> From the [author's web page|http://www.pcg-random.org]:
> PCG is a family of simple fast space-efficient statistically good algorithms
> for random number generation. Unlike many general-purpose RNGs, they are also
> hard to predict.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (RNG-84) PCG
[ https://issues.apache.org/jira/browse/RNG-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894735#comment-16894735 ] Gilles commented on RNG-84: --- bq. Gilles, which changes are you seeing? I just did "git pull" to get the latest "master"; then "git fetch ..." this PR, and there are differences e.g. in ".travis.yml" and others. For example, latest changes by Gary Gregory are not in the history of the PR (e.g. commit 7b2c0a9118e996c12d0e1facca0ff7984b196d58). > PCG > --- > > Key: RNG-84 > URL: https://issues.apache.org/jira/browse/RNG-84 > Project: Commons RNG > Issue Type: Sub-task > Components: core >Reporter: Gilles >Priority: Minor > Labels: gsoc2019 > > From the [author's web page|http://www.pcg-random.org]: > PCG is a family of simple fast space-efficient statistically good algorithms > for random number generation. Unlike many general-purpose RNGs, they are also > hard to predict. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (RNG-84) PCG
[
https://issues.apache.org/jira/browse/RNG-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894730#comment-16894730
]
Gilles commented on RNG-84:
---
In order that your work contains that latest changes in "master", you should run
{noformat}
git rebase master
{noformat}
on your local branch.
> PCG
> ---
>
> Key: RNG-84
> URL: https://issues.apache.org/jira/browse/RNG-84
> Project: Commons RNG
> Issue Type: Sub-task
> Components: core
>Reporter: Gilles
>Priority: Minor
> Labels: gsoc2019
>
> From the [author's web page|http://www.pcg-random.org]:
> PCG is a family of simple fast space-efficient statistically good algorithms
> for random number generation. Unlike many general-purpose RNGs, they are also
> hard to predict.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (RNG-84) PCG
[ https://issues.apache.org/jira/browse/RNG-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894726#comment-16894726 ] Gilles commented on RNG-84: --- Thanks for the PR. However there are several differences with branch "master". Did you "rebase"? > PCG > --- > > Key: RNG-84 > URL: https://issues.apache.org/jira/browse/RNG-84 > Project: Commons RNG > Issue Type: Sub-task > Components: core >Reporter: Gilles >Priority: Minor > Labels: gsoc2019 > > From the [author's web page|http://www.pcg-random.org]: > PCG is a family of simple fast space-efficient statistically good algorithms > for random number generation. Unlike many general-purpose RNGs, they are also > hard to predict. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (RNG-84) PCG
[ https://issues.apache.org/jira/browse/RNG-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894712#comment-16894712 ] Gilles edited comment on RNG-84 at 7/28/19 3:36 PM: Hi [~erans], I'd like to undertake this subtask. The PR pertaining to the request is : https://github.com/apache/commons-rng/pull/56 was (Author: abhi1507): Hi [~erans], I'd like to undertake this subtask. The PR pertaining to the request is : [https://github.com/apache/commons-rng/pull/56|https://github.com/apache/commons-rng/pull/5] > PCG > --- > > Key: RNG-84 > URL: https://issues.apache.org/jira/browse/RNG-84 > Project: Commons RNG > Issue Type: Sub-task > Components: core >Reporter: Gilles >Priority: Minor > Labels: gsoc2019 > > From the [author's web page|http://www.pcg-random.org]: > PCG is a family of simple fast space-efficient statistically good algorithms > for random number generation. Unlike many general-purpose RNGs, they are also > hard to predict. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEOMETRY-59) unexpected output from PolyhedronsSet::checkPoint
[ https://issues.apache.org/jira/browse/GEOMETRY-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890163#comment-16890163 ] Gilles commented on GEOMETRY-59: Hi [~bonastos]. Thanks for your help in this investigation. Just a nit-pick remark: Please follow the project's code convention in your PRs. It will make merging more expedite once you and [~mattjuntunen] agree on the fix. > unexpected output from PolyhedronsSet::checkPoint > - > > Key: GEOMETRY-59 > URL: https://issues.apache.org/jira/browse/GEOMETRY-59 > Project: Apache Commons Geometry > Issue Type: Bug > Components: Euclidean 3D >Reporter: Dirk Bonekämper >Priority: Major > Labels: pull-request-available > Attachments: InsideProblemTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > In my project I'm working with 3D Regions modeled as prisms. The base > polygons are mostly concave. I got wrong results and boiled it down to the > attached unit test. It creates a prism with a concave base. A point that is > above the prism gets classified as INSIDE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEOMETRY-59) unexpected output from PolyhedronsSet::checkPoint
[ https://issues.apache.org/jira/browse/GEOMETRY-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889038#comment-16889038 ] Gilles commented on GEOMETRY-59: Thanks a lot for the report, and your interest in "Commons Geometry". I've confirmed that the unit test fails; as a user of the code, you are surely more knowledgeable than I for fixing it. I think that our main developer ([~mattjuntunen]) has been quite busy recently, refactoring the code that could cause the issue (see GEOMETRY-32). If you could review his work, that would be a tremendous help, and a step towards releasing the new component. I'd also suggest performing the same test with the code still in ["Commons Math" (4.0-snapshot)|https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-math4/4.0-SNAPSHOT/] as that would give a hint whether this bug is due to the current overhaul. > unexpected output from PolyhedronsSet::checkPoint > - > > Key: GEOMETRY-59 > URL: https://issues.apache.org/jira/browse/GEOMETRY-59 > Project: Apache Commons Geometry > Issue Type: Bug > Components: Euclidean 3D >Reporter: Dirk Bonekämper >Priority: Major > Attachments: InsideProblemTest.java > > > In my project I'm working with 3D Regions modeled as prisms. The base > polygons are mostly concave. I got wrong results and boiled it down to the > attached unit test. It creates a prism with a concave base. A point that is > above the prism gets classified as INSIDE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (RNG-70) xoshiro generators
[
https://issues.apache.org/jira/browse/RNG-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886338#comment-16886338
]
Gilles commented on RNG-70:
---
FTR: https://www.sciencedirect.com/science/article/pii/S0377042718306265
> xoshiro generators
> --
>
> Key: RNG-70
> URL: https://issues.apache.org/jira/browse/RNG-70
> Project: Commons RNG
> Issue Type: New Feature
> Components: core, simple
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Major
> Fix For: 1.3
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The authors of the algorithm implemented in
> {{org.apache.commons.rng.core.source64.XorShift1024Star}} have produced new
> generators as described here:
> [xorshiro / xoroshiro generators|http://xoshiro.di.unimi.it]
> I propose to implement the *all purpose* algorithms using the following
> classnames:
> {code:java}
> source32.XoShiRo128StarStar
> source64.XoRoShiRo128StarStar
> source64.XoShiRo256StarStar
> source64.XoShiRo512StarStar
> source64.XorShift1024Phi
> {code}
> The algorithms are simple to adapt from the c source code and I have created
> working versions with units tests (analogous to the {{XorShift1024Star}}
> test).
> Each generator must have a corresponding name in the {{RandomSource}} enum. I
> propose:
> {code:java}
> XO_SHI_RO_128_SS,
> XO_RO_SHI_RO_128_SS,
> XO_SHI_RO_256_SS,
> XO_SHI_RO_512_SS,
> XOR_SHIFT_1024_PHI,
> {code}
> Note: XorShift1024Phi is an updated implementation of XorShift1024Star using
> a different multiplier. To share code this could be implemented by moving the
> implementation to an abstract base class for both XorShift1024Phi and
> XorShift1024Star which accepts the multiplier in the constructor.
> The authors also provide code for *faster generators* for use in creating
> floating-point random numbers where the lower order bits are discarded. These
> could be named:
> {code:java}
> source32.XoShiRo128Plus
> source64.XoRoShiRo128Plus
> source64.XoShiRo256Plus
> source64.XoShiRo512Plus
> XO_SHI_RO_128_PLUS,
> XO_RO_SHI_RO_128_PLUS,
> XO_SHI_RO_256_PLUS,
> XO_SHI_RO_512_PLUS,
> {code}
> For discussion:
> * The names of the generators.
> * Should the small state 64-bit generator XoRoShiRo128StarStar be
> implemented? It has a potentially confusing name clash with the 32-bit
> generator XoShiRo128StarStar. Speed is expected to be the same as
> XoShiRo256Star but using only half the memory footprint.
> * Should the faster floating-point generators be implemented?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (GEOMETRY-56) Create distribution archive
[ https://issues.apache.org/jira/browse/GEOMETRY-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886017#comment-16886017 ] Gilles edited comment on GEOMETRY-56 at 7/16/19 10:24 AM: -- There are now two configurations on Jenkins: * [https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry-fix/] * [https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry/] The latter has been hanging for more than 6 days. I guess that the former is supposed to replace it (?). Note that it seems that snapshots are created at the wrong place: [https://repository.apache.org/content/repositories/snapshots/org/apache/commons/dist-archive] was (Author: erans): There are now two configurations on Jenkins: * https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry-fix/ * https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry/ The latter has been hanging for more than 6 days. I guess that the former is supposed to replace it (?). Note that it seems that snapshots seems to be created at the wrong place: https://repository.apache.org/content/repositories/snapshots/org/apache/commons/dist-archive > Create distribution archive > --- > > Key: GEOMETRY-56 > URL: https://issues.apache.org/jira/browse/GEOMETRY-56 > Project: Apache Commons Geometry > Issue Type: Improvement >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Labels: Maven, jenkins > Fix For: 1.0 > > > *Problem* > * Currently the configuration for building a distribution archive does not > exist > * The current configuration for creating archives is wrong > *Goal* > * Create separate distribution archive module > * Create correct configuration for maven-assembly-plugin -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEOMETRY-56) Create distribution archive
[ https://issues.apache.org/jira/browse/GEOMETRY-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886017#comment-16886017 ] Gilles commented on GEOMETRY-56: There are now two configurations on Jenkins: * https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry-fix/ * https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry/ The latter has been hanging for more than 6 days. I guess that the former is supposed to replace it (?). Note that it seems that snapshots seems to be created at the wrong place: https://repository.apache.org/content/repositories/snapshots/org/apache/commons/dist-archive > Create distribution archive > --- > > Key: GEOMETRY-56 > URL: https://issues.apache.org/jira/browse/GEOMETRY-56 > Project: Apache Commons Geometry > Issue Type: Improvement >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Labels: Maven, jenkins > Fix For: 1.0 > > > *Problem* > * Currently the configuration for building a distribution archive does not > exist > * The current configuration for creating archives is wrong > *Goal* > * Create separate distribution archive module > * Create correct configuration for maven-assembly-plugin -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEOMETRY-58) WelzlEncloser throws GeometryInternalError
[
https://issues.apache.org/jira/browse/GEOMETRY-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved GEOMETRY-58.
Resolution: Fixed
Fix Version/s: 1.0
Yes. Done.
> WelzlEncloser throws GeometryInternalError
> --
>
> Key: GEOMETRY-58
> URL: https://issues.apache.org/jira/browse/GEOMETRY-58
> Project: Apache Commons Geometry
> Issue Type: Bug
> Components: Euclidean 2D
>Reporter: Benjamin Krogh
>Priority: Critical
> Fix For: 1.0
>
>
> The following code snippet throws a GeometryInternalError exception:
> {noformat}
> @Test
> public void testEnclosingWithPrecision() {
> final List points = Arrays.asList(
> Vector2D.of(271.59, 57.282),
> Vector2D.of(269.145, 57.063),
> Vector2D.of(309.117, 77.187),
> Vector2D.of(316.989, 34.835),
> Vector2D.of(323.101, 53.972)
> );
> double precision = 1;
> DoublePrecisionContext precisionContext = new
> EpsilonDoublePrecisionContext(precision);
> WelzlEncloser< Vector2D> encloser = new WelzlEncloser<>(precisionContext,
> new DiskGenerator());
> encloser.enclose(points);
> }{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-129) Waste of functionality in Fraction.addSub(Fraction, boolean)
[
https://issues.apache.org/jira/browse/NUMBERS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879545#comment-16879545
]
Gilles commented on NUMBERS-129:
Merged into "master" with slight changes. Please check.
> Waste of functionality in Fraction.addSub(Fraction, boolean)
>
>
> Key: NUMBERS-129
> URL: https://issues.apache.org/jira/browse/NUMBERS-129
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [NUMBERS-79|https://issues.apache.org/jira/browse/NUMBERS-79], which has been
> marked as resolved by now, suggested to replace the usage of {{BigInteger}}
> in the method {{Fraction.addSub(Fraction, boolean)}} with primitive {{long}}
> values for the sake of performance. However, the ticket's
> "[resolution|https://github.com/apache/commons-numbers/commit/7c2486362b64201fd8dc19b2df12aefba2a4165a];
> does not use {{long}}, but {{int}} variables (as I hinted at in a comment in
> the ticket about a month ago, when the code was still in the branch
> fraction-dev and not merged into master yet), although the method's
> documentation was changed to state that the method uses the {{long}} datatype.
> So for one thing, the method's documentation makes claims about the method's
> implementation that are simply not true, and for another, the usage of
> {{int}}s can cause the method to fail, while using {{long}}s would _always_
> produce the correct result because an overflow would never occur (which I
> also explained in the aforementioned comment in the ticket).
> As for performance: I doubt that three {{int}}\-to\-{{long}} conversions
> and subsequent multiplications and one {{Math.toIntExact(long)}} invocation
> are significantly less performant than three {{Math.multiplyExact(int, int)}}
> and one {{Math.addExact(int, int)}} invocation (if at all), so using
> {{int}}s rather than {{long}}s sacrifices functionality for practically
> nothing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-123) "BigFraction(double)" is unnecessary
[
https://issues.apache.org/jira/browse/NUMBERS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877323#comment-16877323
]
Gilles commented on NUMBERS-123:
OK; thanks. We can always revisit this part (since it is private) of the design
at any later time, with the backing of more use-cases/bugs.
> "BigFraction(double)" is unnecessary
>
>
> Key: NUMBERS-123
> URL: https://issues.apache.org/jira/browse/NUMBERS-123
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 1.0
>
> Attachments: NUMBERS-123__Javadoc.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Constructor {{BigFraction(double value)}} is only called from the
> {{from(double value)}} method.
> Actually, this constructor is misleading as it is indeed primarily a
> conversion from which appropriate {{numerator}} and {{denominator}} fields
> are computed; those could be set by
> the "direct" constructor {{BigFraction(BigInteger num, BigInteger den)}}.
> Moreover, the private field {{ZERO}} goes through this conversion code
> whereas it could constructed "directly", e.g. using {{of(0)}}. Similarly for
> field {{ONE}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1493) Eigendecomposition Float comparison with ==; this is bad
[
https://issues.apache.org/jira/browse/MATH-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877306#comment-16877306
]
Gilles commented on MATH-1493:
--
You might be pointing to bugs, but the construct could also be intentional.
This is very old code, and it would be dangerous to change it without a
demonstrated failure.
Unit tests are most welcome.
> Eigendecomposition Float comparison with ==; this is bad
>
>
> Key: MATH-1493
> URL: https://issues.apache.org/jira/browse/MATH-1493
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: I use very small and very big float numbers and number
> which are very near to 0.0 like -10^30;
> so this effect me.
>Reporter: Nietzsche
>Priority: Major
>
> If you compare two float numbers you should not use ==. I think this lead to
> some arithmetik mistakes. Maybe you should use epsilon comparison so not x ==
> 0 but
> x < 0.01
>
>
> Effected methods:
> findEigenVectors;
> row 671
> if (e[i + 1] == 0.0) {
> row 687
> if (t == 0.0 && i >= j)
>
> isNonSingular(); row 522
> largestEigenvalueNorm == 0.0
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-123) "BigFraction(double)" is unnecessary
[
https://issues.apache.org/jira/browse/NUMBERS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877301#comment-16877301
]
Gilles commented on NUMBERS-123:
The point about whether or not to put that code in a constructor is IMHO quite
moot since we adopted the ValJO convention (i.e. define factory methods and
make any and all constructors private). Then following that ValJO path, a
distinction is made between direct assignment ("of") and conversion ("from").
IMO, a single constructor is clearer because we can say *once* that either the
constructor will do the reduction, or that the caller (i.e. one of the
conversion methods) is responsible for doing it (and can thus set the flag to
{{false}}).
If you are still convinced that your viewpoint is more sensible, please post to
the ML, asking for more opinions.
> "BigFraction(double)" is unnecessary
>
>
> Key: NUMBERS-123
> URL: https://issues.apache.org/jira/browse/NUMBERS-123
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 1.0
>
> Attachments: NUMBERS-123__Javadoc.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Constructor {{BigFraction(double value)}} is only called from the
> {{from(double value)}} method.
> Actually, this constructor is misleading as it is indeed primarily a
> conversion from which appropriate {{numerator}} and {{denominator}} fields
> are computed; those could be set by
> the "direct" constructor {{BigFraction(BigInteger num, BigInteger den)}}.
> Moreover, the private field {{ZERO}} goes through this conversion code
> whereas it could constructed "directly", e.g. using {{of(0)}}. Similarly for
> field {{ONE}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-123) "BigFraction(double)" is unnecessary
[
https://issues.apache.org/jira/browse/NUMBERS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876767#comment-16876767
]
Gilles commented on NUMBERS-123:
I understand your reluctance.
However, this discussion also is a hint that the initial setup was not clear
(and it was hiding a bug in that the fields ONE and ZERO were initialized in an
awkward way).
Since the constructor is private, its correct usage only depends on the
components' developers: The sole purpose of the flag is efficiency, when we
*know* that the call will result in an instance that fulfills the requirements
for further use of the object.
IOW, the constructor is the lowest-level (flexible) factory whose usage is
controlled by higher-level factory methods ("of" and "from").
> "BigFraction(double)" is unnecessary
>
>
> Key: NUMBERS-123
> URL: https://issues.apache.org/jira/browse/NUMBERS-123
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 1.0
>
> Attachments: NUMBERS-123__Javadoc.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Constructor {{BigFraction(double value)}} is only called from the
> {{from(double value)}} method.
> Actually, this constructor is misleading as it is indeed primarily a
> conversion from which appropriate {{numerator}} and {{denominator}} fields
> are computed; those could be set by
> the "direct" constructor {{BigFraction(BigInteger num, BigInteger den)}}.
> Moreover, the private field {{ZERO}} goes through this conversion code
> whereas it could constructed "directly", e.g. using {{of(0)}}. Similarly for
> field {{ONE}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-123) "BigFraction(double)" is unnecessary
[
https://issues.apache.org/jira/browse/NUMBERS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876526#comment-16876526
]
Gilles commented on NUMBERS-123:
bq. All of these conditions are already fulfilled by the values passed to this
constructor from the method {{from(double)}}
What about adding a flag to the constructor? I.e.
{code}
private BigFraction(BigInteger num, BigInteger denom, boolean reduce)
{code}
?
> "BigFraction(double)" is unnecessary
>
>
> Key: NUMBERS-123
> URL: https://issues.apache.org/jira/browse/NUMBERS-123
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 1.0
>
> Attachments: NUMBERS-123__Javadoc.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Constructor {{BigFraction(double value)}} is only called from the
> {{from(double value)}} method.
> Actually, this constructor is misleading as it is indeed primarily a
> conversion from which appropriate {{numerator}} and {{denominator}} fields
> are computed; those could be set by
> the "direct" constructor {{BigFraction(BigInteger num, BigInteger den)}}.
> Moreover, the private field {{ZERO}} goes through this conversion code
> whereas it could constructed "directly", e.g. using {{of(0)}}. Similarly for
> field {{ONE}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-125) BigFraction.reduce() and Fraction.getReducedFraction(int, int) are unnecessary
[
https://issues.apache.org/jira/browse/NUMBERS-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875990#comment-16875990
]
Gilles commented on NUMBERS-125:
+1
> BigFraction.reduce() and Fraction.getReducedFraction(int, int) are unnecessary
> --
>
> Key: NUMBERS-125
> URL: https://issues.apache.org/jira/browse/NUMBERS-125
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
>
> The instance method {{BigFraction.reduce()}} is unnecessary, because the only
> constructor in this class already reduces the fraction to lowest terms.
> Likewise, the static factory method {{Fraction.getReducedFraction(int, int)}}
> is unnecessary, because it is functionally completely equivalent to the
> factory method {{Fraction.of(int, int)}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (NUMBERS-126) Null checks are redundant
Gilles created NUMBERS-126:
--
Summary: Null checks are redundant
Key: NUMBERS-126
URL: https://issues.apache.org/jira/browse/NUMBERS-126
Project: Commons Numbers
Issue Type: Improvement
Components: fraction
Reporter: Gilles
Fix For: 1.0
Not checking for {{null}} will result in NPE anyways, as soon as the fraction
is used.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-119) BigFraction(double) constructor does not treat subnormal numbers correctly
[
https://issues.apache.org/jira/browse/NUMBERS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875969#comment-16875969
]
Gilles commented on NUMBERS-119:
bq. I found one missed Javadoc update
Thanks for the review.
bq. is a patch preferable for such trivial changes?
Either is fine.
> BigFraction(double) constructor does not treat subnormal numbers correctly
> --
>
> Key: NUMBERS-119
> URL: https://issues.apache.org/jira/browse/NUMBERS-119
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Fix For: 1.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The constructor {{BigFraction(double)}} does not take into account the fact
> that, when the biased exponent of a {{double}} value is {{0}} and the
> mantissa is not {{0}} (i.e. when the value represents a subnormal number),
> the actual exponent in effect is not {{-1023}} but {{-1022}} (or, in other
> words, the effective exponent bias is not {{1023}} but {{1022}}).
> The value of the created {{BigFraction}} is therefore not equal to the value
> of the passed {{double}} argument.
> Also, since the constructor does not handle the case of zero separately, it
> creates a fraction with a numerator of 0 and a denominator of 2^1075^, which
> is not very memory-efficient.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-123) "BigFraction(double)" is unnecessary
[
https://issues.apache.org/jira/browse/NUMBERS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875968#comment-16875968
]
Gilles commented on NUMBERS-123:
Done.
> "BigFraction(double)" is unnecessary
>
>
> Key: NUMBERS-123
> URL: https://issues.apache.org/jira/browse/NUMBERS-123
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 1.0
>
> Attachments: NUMBERS-123__Javadoc.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Constructor {{BigFraction(double value)}} is only called from the
> {{from(double value)}} method.
> Actually, this constructor is misleading as it is indeed primarily a
> conversion from which appropriate {{numerator}} and {{denominator}} fields
> are computed; those could be set by
> the "direct" constructor {{BigFraction(BigInteger num, BigInteger den)}}.
> Moreover, the private field {{ZERO}} goes through this conversion code
> whereas it could constructed "directly", e.g. using {{of(0)}}. Similarly for
> field {{ONE}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-119) BigFraction(double) constructor does not treat subnormal numbers correctly
[
https://issues.apache.org/jira/browse/NUMBERS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875875#comment-16875875
]
Gilles commented on NUMBERS-119:
Done.
Please review the additional changes I've made, also as part of NUMBERS-123
and NUMBERS-124.
> BigFraction(double) constructor does not treat subnormal numbers correctly
> --
>
> Key: NUMBERS-119
> URL: https://issues.apache.org/jira/browse/NUMBERS-119
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The constructor {{BigFraction(double)}} does not take into account the fact
> that, when the biased exponent of a {{double}} value is {{0}} and the
> mantissa is not {{0}} (i.e. when the value represents a subnormal number),
> the actual exponent in effect is not {{-1023}} but {{-1022}} (or, in other
> words, the effective exponent bias is not {{1023}} but {{1022}}).
> The value of the created {{BigFraction}} is therefore not equal to the value
> of the passed {{double}} argument.
> Also, since the constructor does not handle the case of zero separately, it
> creates a fraction with a numerator of 0 and a denominator of 2^1075^, which
> is not very memory-efficient.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (NUMBERS-124) "BigFraction(double,double,int,int)" is unnecessary
Gilles created NUMBERS-124:
--
Summary: "BigFraction(double,double,int,int)" is unnecessary
Key: NUMBERS-124
URL: https://issues.apache.org/jira/browse/NUMBERS-124
Project: Commons Numbers
Issue Type: Improvement
Reporter: Gilles
Assignee: Gilles
Fix For: 1.0
Code in that constructor should be moved to a conversion method:
{code}
private static BigFraction from(double v, double eps, int mexDenom, int maxIter)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (NUMBERS-123) "BigFraction(double)" is unnecessary
Gilles created NUMBERS-123:
--
Summary: "BigFraction(double)" is unnecessary
Key: NUMBERS-123
URL: https://issues.apache.org/jira/browse/NUMBERS-123
Project: Commons Numbers
Issue Type: Improvement
Components: fraction
Reporter: Gilles
Assignee: Gilles
Fix For: 1.0
Constructor {{BigFraction(double value)}} is only called from the {{from(double
value)}} method.
Actually, this constructor is misleading as it is indeed primarily a
conversion from which appropriate {{numerator}} and {{denominator}} fields are
computed; those could be set by
the "direct" constructor {{BigFraction(BigInteger num, BigInteger den)}}.
Moreover, the private field {{ZERO}} goes through this conversion code whereas
it could constructed "directly", e.g. using {{of(0)}}. Similarly for field
{{ONE}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-121) Deprecated HTML tag in BigFraction
[
https://issues.apache.org/jira/browse/NUMBERS-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873748#comment-16873748
]
Gilles commented on NUMBERS-121:
{quote}
{noformat}
@return \( k^e \)
@return ke
{noformat}
This is not consistent.
{quote}
No, and the former reads better IMO.
{quote}Jira ticket
{quote}
Usual Javadoc clean-up, but could be useful to collect PRs.
> Deprecated HTML tag in BigFraction
> --
>
> Key: NUMBERS-121
> URL: https://issues.apache.org/jira/browse/NUMBERS-121
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The deprecated HTML tag {{}} occurs multiple times in the Javadoc of the
> class {{BigFraction}}, which causes the execution of the Maven Javadoc Plugin
> to fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-121) Deprecated HTML tag in BigFraction
[
https://issues.apache.org/jira/browse/NUMBERS-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873415#comment-16873415
]
Gilles commented on NUMBERS-121:
Hi Heinrich.
Thanks for the PR but I'd prefer that we consistently use MathJax for this kind
of formulae.
> Deprecated HTML tag in BigFraction
> --
>
> Key: NUMBERS-121
> URL: https://issues.apache.org/jira/browse/NUMBERS-121
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The deprecated HTML tag {{}} occurs multiple times in the Javadoc of the
> class {{BigFraction}}, which causes the execution of the Maven Javadoc Plugin
> to fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-119) BigFraction(double) constructor does not treat subnormal numbers correctly
[
https://issues.apache.org/jira/browse/NUMBERS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872280#comment-16872280
]
Gilles commented on NUMBERS-119:
bq. reduce() method obsolete anyway, which could be the target of a new JIRA
ticket.
+1
> BigFraction(double) constructor does not treat subnormal numbers correctly
> --
>
> Key: NUMBERS-119
> URL: https://issues.apache.org/jira/browse/NUMBERS-119
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The constructor {{BigFraction(double)}} does not take into account the fact
> that, when the biased exponent of a {{double}} value is {{0}} and the
> mantissa is not {{0}} (i.e. when the value represents a subnormal number),
> the actual exponent in effect is not {{-1023}} but {{-1022}} (or, in other
> words, the effective exponent bias is not {{1023}} but {{1022}}).
> The value of the created {{BigFraction}} is therefore not equal to the value
> of the passed {{double}} argument.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MATH-1490) Percentile computational accuracy issue
[ https://issues.apache.org/jira/browse/MATH-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16871892#comment-16871892 ] Gilles edited comment on MATH-1490 at 6/25/19 12:25 AM: bq. my expected output is 68.95. With what precision? was (Author: erans): bq. 68.95 With what precision? > Percentile computational accuracy issue > --- > > Key: MATH-1490 > URL: https://issues.apache.org/jira/browse/MATH-1490 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.4, 3.4.1, 3.5, 3.6, 3.6.1 > Environment: System: Linux testinglab 4.4.0-131-generic > #157~14.04.1-Ubuntu > Java version "1.8.0_191" > Java(TM) SE Runtime Environment (build 1.8.0_191-b12) > Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) > > >Reporter: Lingchao Chen >Assignee: Rob Tompkins >Priority: Major > Labels: performance > Attachments: BugDemo.java > > > The percentile method works well on the older versions, e.g., the version > before 3.4. However, when I update commons-math to the newer version, there > produces a computational accuracy issue. There is a backward compatibility > bug behind it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MATH-1490) Percentile computational accuracy issue
[ https://issues.apache.org/jira/browse/MATH-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16871892#comment-16871892 ] Gilles commented on MATH-1490: -- bq. 68.95 With what precision? > Percentile computational accuracy issue > --- > > Key: MATH-1490 > URL: https://issues.apache.org/jira/browse/MATH-1490 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.4, 3.4.1, 3.5, 3.6, 3.6.1 > Environment: System: Linux testinglab 4.4.0-131-generic > #157~14.04.1-Ubuntu > Java version "1.8.0_191" > Java(TM) SE Runtime Environment (build 1.8.0_191-b12) > Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) > > >Reporter: Lingchao Chen >Assignee: Rob Tompkins >Priority: Major > Labels: performance > Attachments: BugDemo.java > > > The percentile method works well on the older versions, e.g., the version > before 3.4. However, when I update commons-math to the newer version, there > produces a computational accuracy issue. There is a backward compatibility > bug behind it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-118) Reduce code duplication between BigFractionTest and FractionTest
[
https://issues.apache.org/jira/browse/NUMBERS-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870276#comment-16870276
]
Gilles commented on NUMBERS-118:
Merged in commit 860adcdb865842f673ba5010ebcbfd501abcff8b ("master").
> Reduce code duplication between BigFractionTest and FractionTest
>
>
> Key: NUMBERS-118
> URL: https://issues.apache.org/jira/browse/NUMBERS-118
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Apparently, the class {{BigFractionTest}} has been created mainly by
> copy-pasting {{FractionTest}}, resulting in a lot of duplicate test cases.
> This code duplication can be mitigated by extracting some of the test cases
> that are used by both classes to a single location.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-116) Remove redundant methods in ArithmeticUtils
[
https://issues.apache.org/jira/browse/NUMBERS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870269#comment-16870269
]
Gilles commented on NUMBERS-116:
Merged in commit 7b36cbf23bf5c9cfa9ad29832ae57b99093a55ac ("master").
> Remove redundant methods in ArithmeticUtils
> ---
>
> Key: NUMBERS-116
> URL: https://issues.apache.org/jira/browse/NUMBERS-116
> Project: Commons Numbers
> Issue Type: Improvement
> Components: core
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As has been
> [discussed|http://mail-archives.apache.org/mod_mbox/commons-dev/201906.mbox/%3C940f9ff0-0b25-cd31-ddb3-a95ca777ba06%40gmx.at%3E]
> on the developers' mailing list, the following methods from the class
> {{ArithmeticUtils}} can be removed:
> {{addAndCheck(int, int)}}
> {{addAndCheck(long, long)}}
> {{mulAndCheck(int, int)}}
> {{mulAndCheck(long, long)}}
> {{subAndCheck(int, int)}}
> {{subAndCheck(long, long)}}
> And their usages replaced with the following equivalent methods from
> {{java.lang.Math}}:
> {{addExact(int, int)}}
> {{addExact(long, long)}}
> {{multiplyExact(int, int)}}
> {{multiplyExact(long, long)}}
> {{subtractExact(int, int)}}
> {{subtractExact(long, long)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1490) Percentile computational accuracy issue
[ https://issues.apache.org/jira/browse/MATH-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869985#comment-16869985 ] Gilles commented on MATH-1490: -- bq. There is a backward compatibility bug behind it. Could you please be more explicit? What is the expected output? > Percentile computational accuracy issue > --- > > Key: MATH-1490 > URL: https://issues.apache.org/jira/browse/MATH-1490 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.4, 3.4.1, 3.5, 3.6, 3.6.1 > Environment: System: Linux testinglab 4.4.0-131-generic > #157~14.04.1-Ubuntu > Java version "1.8.0_191" > Java(TM) SE Runtime Environment (build 1.8.0_191-b12) > Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) > > >Reporter: Lingchao Chen >Assignee: Rob Tompkins >Priority: Major > Labels: performance > Attachments: BugDemo.java > > > The percentile method works well on the older versions, e.g., the version > before 3.4. However, when I update commons-math to the newer version, there > produces a computational accuracy issue. There is a backward compatibility > bug behind it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MATH-1492) Replace usages of commons-numbers-core methods with equivalent methods from java.lang.Math
[
https://issues.apache.org/jira/browse/MATH-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868512#comment-16868512
]
Gilles commented on MATH-1492:
--
Please do not *close* issues.
This is done (in bulk) _after_ release.
> Replace usages of commons-numbers-core methods with equivalent methods from
> java.lang.Math
> --
>
> Key: MATH-1492
> URL: https://issues.apache.org/jira/browse/MATH-1492
> Project: Commons Math
> Issue Type: Task
>Reporter: Heinrich Bohne
>Priority: Minor
> Fix For: 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The usages of the following methods from
> {{org.apache.commons.numbers.core.ArithmeticUtils}}:
> {{addAndCheck(int, int)}}
> {{addAndCheck(long, long)}}
> {{mulAndCheck(int, int)}}
> {{mulAndCheck(long, long)}}
> {{subAndCheck(int, int)}}
> {{subAndCheck(long, long)}}
> Can be replaced with the following equivalent methods from {{java.lang.Math}}:
> {{addExact(int, int)}}
> {{addExact(long, long)}}
> {{multiplyExact(int, int)}}
> {{multiplyExact(long, long)}}
> {{subtractExact(int, int)}}
> {{subtractExact(long, long)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-104) SeedFactory seed creation performance analysis
[ https://issues.apache.org/jira/browse/RNG-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868507#comment-16868507 ] Gilles commented on RNG-104: 0.1 ns -> 15 ns 2^969 years -> 145,350 years (?) > SeedFactory seed creation performance analysis > -- > > Key: RNG-104 > URL: https://issues.apache.org/jira/browse/RNG-104 > Project: Commons RNG > Issue Type: Task > Components: simple >Affects Versions: 1.3 >Reporter: Alex D Herbert >Assignee: Alex D Herbert >Priority: Minor > Attachments: t1.jpg, t4.jpg, well_lock_vs_sync1.png, > well_lock_vs_sync4.jpg, well_sync_performance.jpg, > well_unfair_performance.jpg, well_unfair_vs_fair.jpg, xor_unfair_int1.png, > xor_unfair_long1.png > > > The SeedFactory is used to create seeds for the random generators. To ensure > thread safety this uses synchronized blocks around a single generator. The > current method only generates a single int or long per synchronisation. > Analyze the performance of this approach. The analysis will investigate > generating multiple values inside each synchronisation around the generator. > This analysis will also investigate methods to supplement the SeedFactory > with fast methods to create seeds. This will use a fast seeding method to > generate a single long value. This can be a seed for a SplitMix generator > used to create a seed of any length. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MATH-1492) Replace usages of commons-numbers-core methods with equivalent methods from java.lang.Math
[
https://issues.apache.org/jira/browse/MATH-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-1492.
--
Resolution: Fixed
Commit ea44a229dad115a14f0fa76a7597ecdfb8de1367 ("master").
> Replace usages of commons-numbers-core methods with equivalent methods from
> java.lang.Math
> --
>
> Key: MATH-1492
> URL: https://issues.apache.org/jira/browse/MATH-1492
> Project: Commons Math
> Issue Type: Task
>Reporter: Heinrich Bohne
>Priority: Minor
> Fix For: 4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The usages of the following methods from
> {{org.apache.commons.numbers.core.ArithmeticUtils}}:
> {{addAndCheck(int, int)}}
> {{addAndCheck(long, long)}}
> {{mulAndCheck(int, int)}}
> {{mulAndCheck(long, long)}}
> {{subAndCheck(int, int)}}
> {{subAndCheck(long, long)}}
> Can be replaced with the following equivalent methods from {{java.lang.Math}}:
> {{addExact(int, int)}}
> {{addExact(long, long)}}
> {{multiplyExact(int, int)}}
> {{multiplyExact(long, long)}}
> {{subtractExact(int, int)}}
> {{subtractExact(long, long)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-104) SeedFactory seed creation performance analysis
[ https://issues.apache.org/jira/browse/RNG-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868436#comment-16868436 ] Gilles commented on RNG-104: bq. how long before the 2^1024 period repeats? Yes. But in the above code, there is no unneeded generation; so your original estimate is valid (IIUC). I don't understand why you changed it (just curious). > SeedFactory seed creation performance analysis > -- > > Key: RNG-104 > URL: https://issues.apache.org/jira/browse/RNG-104 > Project: Commons RNG > Issue Type: Task > Components: simple >Affects Versions: 1.3 >Reporter: Alex D Herbert >Assignee: Alex D Herbert >Priority: Minor > Attachments: t1.jpg, t4.jpg, well_lock_vs_sync1.png, > well_lock_vs_sync4.jpg, well_sync_performance.jpg, > well_unfair_performance.jpg, well_unfair_vs_fair.jpg, xor_unfair_int1.png, > xor_unfair_long1.png > > > The SeedFactory is used to create seeds for the random generators. To ensure > thread safety this uses synchronized blocks around a single generator. The > current method only generates a single int or long per synchronisation. > Analyze the performance of this approach. The analysis will investigate > generating multiple values inside each synchronisation around the generator. > This analysis will also investigate methods to supplement the SeedFactory > with fast methods to create seeds. This will use a fast seeding method to > generate a single long value. This can be a seed for a SplitMix generator > used to create a seed of any length. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
