[jira] [Resolved] (MATH-1284) Vector is-not-a Point
[ https://issues.apache.org/jira/browse/MATH-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond DeCampo resolved MATH-1284. --- Resolution: Fixed Assignee: Raymond DeCampo Resolution applied in commit 7a59c0af26177cf69e702eaac85471e54762f664 > Vector is-not-a Point > - > > Key: MATH-1284 > URL: https://issues.apache.org/jira/browse/MATH-1284 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Roman Werpachowski >Assignee: Raymond DeCampo >Priority: Minor > Fix For: 4.0 > > > The class hierarchy for geometry claims that Vector is-a Point: > https://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/geometry/Point.html > This is mathematically incorrect, see e.g. > http://math.stackexchange.com/a/645827 > Just because they share the same numerical representation, Point and Vector > shouldn't be crammed into a common class hierarchy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (NUMBERS-6) "fraction" module
[
https://issues.apache.org/jira/browse/NUMBERS-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond DeCampo resolved NUMBERS-6.
---
Resolution: Fixed
Assignee: Raymond DeCampo
Resovled in commit 39b5119cc153a910152c19addf6f2d750531da53
> "fraction" module
> -
>
> Key: NUMBERS-6
> URL: https://issues.apache.org/jira/browse/NUMBERS-6
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Gilles
>Assignee: Raymond DeCampo
>Priority: Minor
> Labels: maven, module
> Fix For: 1.0
>
>
> Create a {{commons-numbers-fraction}} module to contain the code from the
> {{o.a.c.math4.fraction}} package of "Commons Math" (master branch).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1284) Vector is-not-a Point
[
https://issues.apache.org/jira/browse/MATH-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999458#comment-15999458
]
Raymond DeCampo commented on MATH-1284:
---
OK, I have made the change to {{Cartesian?D}}. I have also restored the
{{Vector?D}} as abstract classes which {{Cartesian?D}} extend - I thought that
would be easier on existing client code.
I also made an attempt to update the javadoc and supporting files.
Please take another look at the {{feature-MATH-1284}} branch for review.
> Vector is-not-a Point
> -
>
> Key: MATH-1284
> URL: https://issues.apache.org/jira/browse/MATH-1284
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Roman Werpachowski
>Priority: Minor
> Fix For: 4.0
>
>
> The class hierarchy for geometry claims that Vector is-a Point:
> https://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/geometry/Point.html
> This is mathematically incorrect, see e.g.
> http://math.stackexchange.com/a/645827
> Just because they share the same numerical representation, Point and Vector
> shouldn't be crammed into a common class hierarchy.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1284) Vector is-not-a Point
[
https://issues.apache.org/jira/browse/MATH-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983793#comment-15983793
]
Raymond DeCampo commented on MATH-1284:
---
Please take a look at the {{feature-MATH-1284}} branch.
First, I made it so that {{Vector}} no longer extends {{Point}}. Then I added
the appropriate methods from the {{Point}} interface to the {{Vector}}
interface.
The only implementations which represented problems were the {{Vector?D}}
classes. I noticed that the existing code dealing with these implementations
relied pretty heavily on casting back and forth between {{Point}} and
{{Vector}}, so the most prudent thing seemed to be supplying a class which
implements both.
I decided on {{Coordinates?D}} for the "new" classes (these are really just
{{Vector?D}} renamed). Here I am using the fact that point a vector and a
point in finite dimensional Euclidean space can be represented by a set of
coordinates. (Keeping the classes with {{Vector?D}} name would feel like we
hadn't really addressed the issue.)
If it is a problem that the {{Vector?D}} classes are just dropped we could
introduce them as an intermediate interface (or even as a concrete class which
{{Coordinates?D}} extends but that feels less satisfying).
Having {{Coordinates?D}} implement both interfaces led to some method calls
being ambiguously defined. Here I just removed one of the methods. I am
thinking now it would have been better just to create an implementation
accepting the {{Coordinate?D}} class.
In any case, there would be more work in terms of cleaning up and
documentation, this is not meant to be a finished product but a basis for
discussion.
> Vector is-not-a Point
> -
>
> Key: MATH-1284
> URL: https://issues.apache.org/jira/browse/MATH-1284
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Roman Werpachowski
>Priority: Minor
> Fix For: 4.0
>
>
> The class hierarchy for geometry claims that Vector is-a Point:
> https://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/geometry/Point.html
> This is mathematically incorrect, see e.g.
> http://math.stackexchange.com/a/645827
> Just because they share the same numerical representation, Point and Vector
> shouldn't be crammed into a common class hierarchy.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-22) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/NUMBERS-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980515#comment-15980515
]
Raymond DeCampo commented on NUMBERS-22:
The argument for using {{Complex.INF}} is that then you end up with the Riemann
sphere, aka stereographic projection of the sphere onto the complex plane.
The alternate is to have eight infinities: (±Inf, 0), (0, ±Inf) and (±Inf,
±Inf). (In case whatever you are reading this comment with is mangling it,
that symbol is plus/minus.) There are probably other alternatives that escape
my imagination.
Eric Barnhill recently undertook an effort to make the Complex implementation
conform to IEEE and/or C99 standards, perhaps we should wait for his input.
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: NUMBERS-22
> URL: https://issues.apache.org/jira/browse/NUMBERS-22
> Project: Commons Numbers
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> I have been redirected here from the issue repository of Apache Commons Math,
> as the Complex class will likely be deprecated in favour of its equivalent in
> "Commons Numbers".
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> The suggested solutions after the discussion are either checking the equality
> to ZERO with some tolerance or to detect if one of the real or imaginary
> parts is going to be infinite or NaN and then return the proper result.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (NUMBERS-20) Copy prime related code from [math]
[
https://issues.apache.org/jira/browse/NUMBERS-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond DeCampo resolved NUMBERS-20.
Resolution: Fixed
Issue resolve with merge of feature-NUMBERS-20 branch into master.
> Copy prime related code from [math]
> ---
>
> Key: NUMBERS-20
> URL: https://issues.apache.org/jira/browse/NUMBERS-20
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Raymond DeCampo
>Priority: Minor
> Fix For: 1.0
>
>
> Port the classes implementation currently in master branch of Commons Math
> from package {{org.apache.commons.math4.primes}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (NUMBERS-20) Copy prime related code from [math]
[
https://issues.apache.org/jira/browse/NUMBERS-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980422#comment-15980422
]
Raymond DeCampo edited comment on NUMBERS-20 at 4/23/17 3:01 PM:
-
Issue resolved with merge of feature-NUMBERS-20 branch into master.
was (Author: raydecampo):
Issue resolve with merge of feature-NUMBERS-20 branch into master.
> Copy prime related code from [math]
> ---
>
> Key: NUMBERS-20
> URL: https://issues.apache.org/jira/browse/NUMBERS-20
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Raymond DeCampo
>Priority: Minor
> Fix For: 1.0
>
>
> Port the classes implementation currently in master branch of Commons Math
> from package {{org.apache.commons.math4.primes}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1284) Vector is-not-a Point
[
https://issues.apache.org/jira/browse/MATH-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980159#comment-15980159
]
Raymond DeCampo commented on MATH-1284:
---
I agree with the issue as reported; from a mathematical POV a vector is not a
point.
>From a CS POV I am having trouble seeing the value that having the interface
>{{Vector}} extending the interface {{Point}} brings. In fact, by having
>{{Vector}} extend {{Point}}, one ends up with a method in your {{Vector}}
>implementation where one is ostensibly calculating the "distance from a vector
>to a point". This isn't really satisfying to me from a mathematical or CS
>perspective. The implementations of the {{Point}} {{distance()}} method in
>{{Vector}} implementations all immediately cast the {{Point}} to a {{Vector}}
>implementation.
I will prepare a branch with a proposal for resolving this issue.
> Vector is-not-a Point
> -
>
> Key: MATH-1284
> URL: https://issues.apache.org/jira/browse/MATH-1284
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Roman Werpachowski
>Priority: Minor
> Fix For: 4.0
>
>
> The class hierarchy for geometry claims that Vector is-a Point:
> https://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/geometry/Point.html
> This is mathematically incorrect, see e.g.
> http://math.stackexchange.com/a/645827
> Just because they share the same numerical representation, Point and Vector
> shouldn't be crammed into a common class hierarchy.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-20) Copy prime related code from [math]
[
https://issues.apache.org/jira/browse/NUMBERS-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977729#comment-15977729
]
Raymond DeCampo commented on NUMBERS-20:
Proposed resolution available for review on branch {{feature-NUMBERS-20}}.
> Copy prime related code from [math]
> ---
>
> Key: NUMBERS-20
> URL: https://issues.apache.org/jira/browse/NUMBERS-20
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Raymond DeCampo
>Priority: Minor
> Fix For: 1.0
>
>
> Port the classes implementation currently in master branch of Commons Math
> from package {{org.apache.commons.math4.primes}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-12) Continued fraction
[
https://issues.apache.org/jira/browse/NUMBERS-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976483#comment-15976483
]
Raymond DeCampo commented on NUMBERS-12:
Feature branch has been moved, this issue should be marked as resolved.
> Continued fraction
> --
>
> Key: NUMBERS-12
> URL: https://issues.apache.org/jira/browse/NUMBERS-12
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Gilles
>Priority: Minor
> Labels: API, port
> Fix For: 1.0
>
>
> Port the implementation currently in master branch of Commons Math (in class
> {{o.a.c.math4.util.ContinuedFraction}}).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-12) Continued fraction
[
https://issues.apache.org/jira/browse/NUMBERS-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976418#comment-15976418
]
Raymond DeCampo commented on NUMBERS-12:
I went to merge this change today and I realized I mistakenly branched from a
branch instead of from master. I will delete the existing feature branch and
rebuild it before merging into master.
> Continued fraction
> --
>
> Key: NUMBERS-12
> URL: https://issues.apache.org/jira/browse/NUMBERS-12
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Gilles
>Priority: Minor
> Labels: API, port
> Fix For: 1.0
>
>
> Port the implementation currently in master branch of Commons Math (in class
> {{o.a.c.math4.util.ContinuedFraction}}).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15974486#comment-15974486
]
Raymond DeCampo commented on MATH-1414:
---
0.01 is way too large of a tolerance.
I think a better approach would be to detect if one of the real or imaginary
parts is going to be infinite or NaN and then return the proper result. We
need to determine what the desired result in this situation is, e.g. in the
example above one could make a case for {{Complex.INF}};
{{Double.NEGATIVE_INFINTITY}} or {{Double.POSITIVE_INFINITY}} (where the last
two have imaginary part zero).
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (NUMBERS-21) Target Java 7
Raymond DeCampo created NUMBERS-21: -- Summary: Target Java 7 Key: NUMBERS-21 URL: https://issues.apache.org/jira/browse/NUMBERS-21 Project: Commons Numbers Issue Type: Task Reporter: Raymond DeCampo Priority: Minor Numbers is being populated with code from [math], which targets Java 7. Currently Java 6 is targeted in the pom.xml. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NUMBERS-20) Copy prime related code from [math]
Raymond DeCampo created NUMBERS-20:
--
Summary: Copy prime related code from [math]
Key: NUMBERS-20
URL: https://issues.apache.org/jira/browse/NUMBERS-20
Project: Commons Numbers
Issue Type: Task
Reporter: Raymond DeCampo
Priority: Minor
Fix For: 1.0
Port the classes implementation currently in master branch of Commons Math from
package {{org.apache.commons.math4.primes}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-12) Continued fraction
[
https://issues.apache.org/jira/browse/NUMBERS-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15970369#comment-15970369
]
Raymond DeCampo commented on NUMBERS-12:
Proposed resolution available on branch {{feature-NUMBERS-12}}
> Continued fraction
> --
>
> Key: NUMBERS-12
> URL: https://issues.apache.org/jira/browse/NUMBERS-12
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Gilles
>Priority: Minor
> Labels: API, port
> Fix For: 1.0
>
>
> Port the implementation currently in master branch of Commons Math (in class
> {{o.a.c.math4.util.ContinuedFraction}}).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-12) Continued fraction
[
https://issues.apache.org/jira/browse/NUMBERS-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15970004#comment-15970004
]
Raymond DeCampo commented on NUMBERS-12:
I was going to start working on this, just letting people know since I can't
assign myself.
> Continued fraction
> --
>
> Key: NUMBERS-12
> URL: https://issues.apache.org/jira/browse/NUMBERS-12
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Gilles
>Priority: Minor
> Labels: API, port
> Fix For: 1.0
>
>
> Port the implementation currently in master branch of Commons Math (in class
> {{o.a.c.math4.util.ContinuedFraction}}).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-19) MATH-1400
[
https://issues.apache.org/jira/browse/NUMBERS-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15970003#comment-15970003
]
Raymond DeCampo commented on NUMBERS-19:
The way I see it {{mat2quat()}} contains a lot of domain knowledge about the
rotation and very little about quaternions, so I think it is in the right
place. Also currently it returns an array of double, not even a proper
{{Quaternion}} instance.
> MATH-1400
> -
>
> Key: NUMBERS-19
> URL: https://issues.apache.org/jira/browse/NUMBERS-19
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Gilles
> Fix For: 1.0
>
>
> Issue reported in MATH-1400 must be fixed in "Commons Numbers".
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-19) MATH-1400
[ https://issues.apache.org/jira/browse/NUMBERS-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15969948#comment-15969948 ] Raymond DeCampo commented on NUMBERS-19: It looks to me like the bug in question is in the CM org.apache.commons.math4.geometry.euclidean.threed.Rotation class in the mat2quat() method and not the Quaternion class. This code has not been moved to common-numbers. > MATH-1400 > - > > Key: NUMBERS-19 > URL: https://issues.apache.org/jira/browse/NUMBERS-19 > Project: Commons Numbers > Issue Type: Bug >Reporter: Gilles > Fix For: 1.0 > > > Issue reported in MATH-1400 must be fixed in "Commons Numbers". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MATH-1359) Function object for "expm1(x) / x"
[ https://issues.apache.org/jira/browse/MATH-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15822463#comment-15822463 ] Raymond DeCampo commented on MATH-1359: --- Created a PR for this issue. Not sure why it wasn't picked up automatically, maybe because I didn't use master as the base? https://github.com/apache/commons-math/pull/48 > Function object for "expm1(x) / x" > -- > > Key: MATH-1359 > URL: https://issues.apache.org/jira/browse/MATH-1359 > Project: Commons Math > Issue Type: Task >Reporter: Gilles >Assignee: Rob Tompkins >Priority: Minor > Fix For: 4.0 > > > Function object to be created in package o.a.c.m.analysis.function. > Rationale: see MATH-1344. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1358) Function object for "log1p(x) / x"
[
https://issues.apache.org/jira/browse/MATH-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15822460#comment-15822460
]
Raymond DeCampo commented on MATH-1358:
---
Created a PR for this issue. Not sure why it wasn't picked up automatically,
maybe because I didn't use master as the base?
https://github.com/apache/commons-math/pull/48
> Function object for "log1p(x) / x"
> --
>
> Key: MATH-1358
> URL: https://issues.apache.org/jira/browse/MATH-1358
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Assignee: Rob Tompkins
>Priority: Minor
> Fix For: 4.0
>
>
> Function object to be created in package {{o.a.c.m.analysis.function}}.
> Rationale: see MATH-1344.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COMPLEX-4) Complex.ZERO.pow(2.0) is NaN
Raymond DeCampo created COMPLEX-4:
-
Summary: Complex.ZERO.pow(2.0) is NaN
Key: COMPLEX-4
URL: https://issues.apache.org/jira/browse/COMPLEX-4
Project: Commons Complex
Issue Type: Bug
Environment: Linux, Java1.7/Java1.8
Reporter: Raymond DeCampo
Priority: Minor
Description copied from MATH-1397 as reported by Mario Wenzel:
{quote}
```
package complextest;
import org.apache.commons.math3.complex.Complex;
public class T \{
public static void main(String[] args)
\{ System.out.println(Complex.ZERO.pow(2.0)); }
}
```
This is the code and the readout is `(NaN, NaN)`. This surely isn't right. For
one, it should actually be zero
(https://www.wolframalpha.com/input/?i=(0%2B0i)%5E2) and second of all, the
documentation doesn't state that anything could go wrong from a Complex number
that has no NaNs and Infs.
The other definition states that it doesn't work when the base is Zero, but it
surely should. This strange corner case destroys any naive implementation of
stuff wrt the mandelbrot set.
It would be nice to not have to implement this exception myself.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COMPLEX-1) Testing fails due to poor null handling in newly created local equals() and equals-type methods
[ https://issues.apache.org/jira/browse/COMPLEX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15807820#comment-15807820 ] Raymond DeCampo commented on COMPLEX-1: --- I have a fix for ComplexUtilsTest now but it builds on the previous PR. So I am thinking it would be best to wait until the outstanding PR is resolved one way or another before generating another one. > Testing fails due to poor null handling in newly created local equals() and > equals-type methods > --- > > Key: COMPLEX-1 > URL: https://issues.apache.org/jira/browse/COMPLEX-1 > Project: Commons Complex > Issue Type: Bug >Reporter: Eric Barnhill > Labels: patch, test > Original Estimate: 48h > Remaining Estimate: 48h > > commons-complex currently compiles but fails tests. Patches are needed to > handle null in the testing methods. > Local equals() methods have been created to eliminate dependencies on other > Math packages, but these appear to not handle null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPLEX-1) Testing fails due to poor null handling in newly created local equals() and equals-type methods
[ https://issues.apache.org/jira/browse/COMPLEX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15806014#comment-15806014 ] Raymond DeCampo commented on COMPLEX-1: --- Created a pull request on github to replace the patches previously emailed directly to Eric: https://github.com/apache/commons-complex/pull/1 This fixes ComplexTest, QuaternionTest and RootsOfUnityTest. > Testing fails due to poor null handling in newly created local equals() and > equals-type methods > --- > > Key: COMPLEX-1 > URL: https://issues.apache.org/jira/browse/COMPLEX-1 > Project: Commons Complex > Issue Type: Bug >Reporter: Eric Barnhill > Labels: patch, test > Original Estimate: 48h > Remaining Estimate: 48h > > commons-complex currently compiles but fails tests. Patches are needed to > handle null in the testing methods. > Local equals() methods have been created to eliminate dependencies on other > Math packages, but these appear to not handle null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPLEX-1) Testing fails due to poor null handling in newly created local equals() and equals-type methods
[ https://issues.apache.org/jira/browse/COMPLEX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804972#comment-15804972 ] Raymond DeCampo commented on COMPLEX-1: --- We still need to remove the target/ directory (contains maven output including compiler output and test results) and the site-content/ directory (created by "mvn site"). > Testing fails due to poor null handling in newly created local equals() and > equals-type methods > --- > > Key: COMPLEX-1 > URL: https://issues.apache.org/jira/browse/COMPLEX-1 > Project: Commons Complex > Issue Type: Bug >Reporter: Eric Barnhill > Labels: patch, test > Original Estimate: 48h > Remaining Estimate: 48h > > commons-complex currently compiles but fails tests. Patches are needed to > handle null in the testing methods. > Local equals() methods have been created to eliminate dependencies on other > Math packages, but these appear to not handle null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPLEX-1) Testing fails due to poor null handling in newly created local equals() and equals-type methods
[ https://issues.apache.org/jira/browse/COMPLEX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804534#comment-15804534 ] Raymond DeCampo commented on COMPLEX-1: --- I think the first order of business is to remove any files/directory in the .gitignore from the repository. That will eliminate the spurious files that Gilles referred to on the mailing list. > Testing fails due to poor null handling in newly created local equals() and > equals-type methods > --- > > Key: COMPLEX-1 > URL: https://issues.apache.org/jira/browse/COMPLEX-1 > Project: Commons Complex > Issue Type: Bug >Reporter: Eric Barnhill > Labels: patch, test > Original Estimate: 48h > Remaining Estimate: 48h > > commons-complex currently compiles but fails tests. Patches are needed to > handle null in the testing methods. > Local equals() methods have been created to eliminate dependencies on other > Math packages, but these appear to not handle null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[
https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804394#comment-15804394
]
Raymond DeCampo commented on TEXT-36:
-
bq. Whether the feature is out-of-scope is a good question. For this issue, the
assumption was that the class is there already.
Understood.
bq. The "" tag would not impose a transitive dependency.
Yes, I missed this aspect, that would make it more palatable.
bq. You are welcome to implement it.
Pull request on github against the TEXT-51 branch:
https://github.com/apache/commons-text/pull/25
> Dependency on "Commons RNG"
> ---
>
> Key: TEXT-36
> URL: https://issues.apache.org/jira/browse/TEXT-36
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Gilles
> Labels: api
> Fix For: 1.1
>
>
> This is a follow-up of a
> [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15762623]
> held in TEXT-34.
> IMHO, there is no harm in depending on the ["commons-rng-client-api"
> module|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/javadocs/api-1.0/index.html]
> of Commons RNG; the "zero dependency" mantra does not hold here, since TEXT
> already depends on LANG.
> OTOH, I see that it is counter-productive (i.e. it harms the Commons project
> as a whole) to not advertize or use other Commons components, despite the
> "own dog food" phrase appearing recurrently on the "dev" ML.
> Rather than having people blindly use {{java.util.Random}}, we should allow
> them to choose wisely, based on full information.
> IMO, that means to indeed use {{UniformRandomProvider}} in order to raise
> awareness about alternatives to the sub-optimal algorithm used by the JDK.
> However, if some Commons developers do not trust that the
> {{UniformRandomProvider}} interface can be stable enough for TEXT, then we
> should follow Jochen Wiedemann's advice (cf. archive of the "dev" ML) and
> define TEXT's own interface to random numbers, with bridges to it from
> {{UniformRandomProvider}} and from {{java.util.Random}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[
https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15802286#comment-15802286
]
Raymond DeCampo commented on TEXT-36:
-
My 2 cents (not that anyone should care) - if I were including commons-text in
a project and wasn't interested in the class generating random strings (will
most of the commons-text users be in this scenario?) I would prefer there not
be a dependency on a random number generator library which seems like a strange
thing for a text library to depend on.
That said, if it were up to me, I would go with the TextRandomProvider
interface scheme EXCEPT that it should be eligible to be a functional
interface. Also it should have the same signature as the nextInt() method in
java.util.Random and UniformRandomProvider. This will make implementation easy
for Java 8 users. I am thinking something like:
{code}
public interface TextRandomProvider {
public int nextInt(int max);
}
// Then Java 8 users can do something like:
java.util.Random jur = new java.util.Random(1234L);
RandomStringGenerator gen = new RandomStringGenerator.Builder()
.usingRandom(jur::nextInt)
.build();
// or if they want commons-rng:
UniformRandomProvider rng = RandomSource.create(RandomSource.MT);
RandomStringGenerator gen = new RandomStringGenerator.Builder()
.usingRandom(rng::nextInt)
.build();
{code}
Then in the javadoc for the class put examples using commons-rng and that's
what 99% of the people will use anyway. Plus there's no dependency on
commons-rng unless you are actually using the functionality.
People still on Java 7 will have to implement the interface but the number of
users on 7 will be diminishing so I'm not too concerned about inconveniencing
them.
> Dependency on "Commons RNG"
> ---
>
> Key: TEXT-36
> URL: https://issues.apache.org/jira/browse/TEXT-36
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Gilles
> Labels: api
> Fix For: 1.1
>
>
> This is a follow-up of a
> [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15762623]
> held in TEXT-34.
> IMHO, there is no harm in depending on the ["commons-rng-client-api"
> module|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/javadocs/api-1.0/index.html]
> of Commons RNG; the "zero dependency" mantra does not hold here, since TEXT
> already depends on LANG.
> OTOH, I see that it is counter-productive (i.e. it harms the Commons project
> as a whole) to not advertize or use other Commons components, despite the
> "own dog food" phrase appearing recurrently on the "dev" ML.
> Rather than having people blindly use {{java.util.Random}}, we should allow
> them to choose wisely, based on full information.
> IMO, that means to indeed use {{UniformRandomProvider}} in order to raise
> awareness about alternatives to the sub-optimal algorithm used by the JDK.
> However, if some Commons developers do not trust that the
> {{UniformRandomProvider}} interface can be stable enough for TEXT, then we
> should follow Jochen Wiedemann's advice (cf. archive of the "dev" ML) and
> define TEXT's own interface to random numbers, with bridges to it from
> {{UniformRandomProvider}} and from {{java.util.Random}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1397) Complex.ZERO.pow(2.0) is NaN
[
https://issues.apache.org/jira/browse/MATH-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15793135#comment-15793135
]
Raymond DeCampo commented on MATH-1397:
---
Added a pull request to implement the case of 0 raised to a real positive
number:
https://github.com/apache/commons-math/pull/47
> Complex.ZERO.pow(2.0) is NaN
>
>
> Key: MATH-1397
> URL: https://issues.apache.org/jira/browse/MATH-1397
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: Linux, Java1.7/Java1.8
>Reporter: Mario Wenzel
>Priority: Minor
>
> ```
> package complextest;
> import org.apache.commons.math3.complex.Complex;
> public class T {
> public static void main(String[] args) {
> System.out.println(Complex.ZERO.pow(2.0));
> }
> }
> ```
> This is the code and the readout is `(NaN, NaN)`. This surely isn't right.
> For one, it should actually be zero
> (https://www.wolframalpha.com/input/?i=(0%2B0i)%5E2) and second of all, the
> documentation doesn't state that anything could go wrong from a Complex
> number that has no NaNs and Infs.
> The other definition states that it doesn't work when the base is Zero, but
> it surely should. This strange corner case destroys any naive implementation
> of stuff wrt the mandelbrot set.
> It would be nice to not have to implement this exception myself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DBUTILS-50) Support CallableStatement out parameters
[
https://issues.apache.org/jira/browse/DBUTILS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond DeCampo updated DBUTILS-50:
---
Attachment: DBUTILS-50.patch
Implementation of the desired functionality which (I hope) stays true to the
dbutils project as much as possible. Essentially adds a class representing OUT
parameters allowing users to intermix them with the list of parameters for the
SQL statement. Added execute() methods to QueryRunner, which use
CallableStatements and handle the OUT parameters; one flavor for procedures
returning one or more result sets and one for procedures returning update
counts. Unit tests are included.
Support CallableStatement out parameters
--
Key: DBUTILS-50
URL: https://issues.apache.org/jira/browse/DBUTILS-50
Project: Commons DbUtils
Issue Type: New Feature
Reporter: Dan Fabulich
Attachments: DBUTILS-50.patch
Using fillStatement and the new fillStatementWithBean, you can use a
CallableStatement like a PreparedStatement, retrieve its ResultSet and handle
it with a ResultSetHandler. But we don't yet support registering out
parameters on the CallableStatement in a convenient way and retrieving them
back into an object.
DBUTILS-28 requests stored procedure support and provides a patch, but I
don't like the patch. Regardless, we really should support a few helpers
like:
{code}
void registerOutParameters(CallableStatement stmt, int... sqlTypes)
Object[] getOutParameters(CallableStatement stmt)
void registerOutParameters(CallableStatement stmt, Class? beanClass)
T T getOutParameters(CallableStatement stmt, ClassT beanClass)
{code}
You should be able to write code like this:
{code}
CallableStatement stmt = runner.prepareCall(myString);
helper.registerOutParameters(stmt, MyBean.class);
queryRunner.fillStatement(stmt, foo, bar, baz);
stmt.executeUpdate();
MyBean bean = helper.getOutParameters(stmt, MyBean.class);
{code}
Or like this:
{code}
CallableStatement stmt = runner.prepareCall(myString);
helper.registerOutParameters(stmt, TINYINT, DECIMAL);
queryRunner.fillStatement(stmt, foo, bar, baz);
stmt.executeUpdate();
Object[] result = helper.getOutParameters(stmt);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
