[jira] [Commented] (RNG-106) XorShiRo generators require non-zero input seeds
[
https://issues.apache.org/jira/browse/RNG-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860389#comment-16860389
]
Alex D Herbert commented on RNG-106:
There are ignored tests in ProvidersCommonParametricTest that test zero-filled
array seeds. Re-instating these tests lead to failures of:
{noformat}
WELL_512_A
WELL_1024_A
WELL_19937_A
WELL_19937_C
WELL_44497_A
WELL_44497_B
MWC_256
{noformat}
These should be fixed too. Note that WELL_512_A has the smallest state of these
generators. It uses int[16] so the chance of a zero seed is 1 in (2^32)^16 = 1
in 2^512. So a zero seed is so unlikely this has never been a problem.
The WELL generators are based on xor and shift operations. With no 1-bits there
is nothing to xor and shift. The MWC generator uses multiplication of int
values and a carries the overflow to a long to add to the next multiplication.
So if initialised with zero there is never anything to multiply.
This results in 19 / 23 generators that accept an array seed to require it to
be non-zero. The simplest solution would be to change the NativeSeedType enum
that creates the seed arrays to always create a non zero seed.
> XorShiRo generators require non-zero input seeds
>
>
> Key: RNG-106
> URL: https://issues.apache.org/jira/browse/RNG-106
> Project: Commons RNG
> Issue Type: Improvement
> Components: core, simple
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Major
> Fix For: 1.3
>
>
> The following generators based on Xor shifts all require non-zero seeds:
> {noformat}
> XOR_SHIFT_1024_S
> XOR_SHIFT_1024_S_PHI
> XO_RO_SHI_RO_64_S
> XO_RO_SHI_RO_64_SS
> XO_SHI_RO_128_PLUS
> XO_SHI_RO_128_SS
> XO_RO_SHI_RO_128_PLUS
> XO_RO_SHI_RO_128_SS
> XO_SHI_RO_256_PLUS
> XO_SHI_RO_256_SS
> XO_SHI_RO_512_PLUS
> XO_SHI_RO_512_SS
> {noformat}
> A zero seed results in zero output for each call to the generator.
> Tests added to the rng-core module show that only a single bit is required to
> be set and the generator is able to generate non-zero output. These tests are
> simple and do not test the output for many cycles or do statistical analysis
> on the output randomness. However the authors of the generators state that
> they require a non-zero seed and are not any more specific so I assume that a
> single bit is enough to maintain the internal state capable of randomness.
> This can be fixed with the following methods:
> # Set the final bit in the seed to 1. This will be fast but loses 1 bit of
> seed entropy.
> # Check the seed array for zeros. If the entire array is zero then generate
> a single seed value until it is non-zero in a loop and set it into the seed
> array.
> # Check the seed array for zeros. If the entire array is zero then
> re-generate the seed using recursive method call.
> Note that this is an edge case. The smallest seed uses 64 bits, others use
> 128, 256, 512, 1024 (the number of bits in the seed is the state size and is
> the number in the enum). For the worst case this will occur 1 in 2^64 times.
> Here is the robust approach:
> {code:java}
> int[] seed;
> do {
> seed = createSeed(); // Appropriate seed array generation
> } while (SeedFactory.isZero(seed);
> return seed;
> {code}
> This would add new isZero(int[]) and isZero(long[]) methods to the seed
> factory. The entire method for creating a non-zero array seed could be added
> to the SeedFactory.
> Here is the compromise approach:
> {code:java}
> int[] seed = createSeed(); // Appropriate seed array generation
> if (SeedFactory.isZero(seed)) {
> do {
> seed[0] = SeedFactory.createInt();
> } while (seed[0] == 0);
> }
> {code}
> Given the loop will happen 1 in 2^64 times the speed of the two approaches
> will differ due to how the JVM produces the final code for the hot path (i.e.
> not the edge case).
> Here is the simple approach:
> {code:java}
> // Ensure non-zero (loses 1 bit of entropy)
> return createSeed() | 1;
> {code}
> Losing 1 bit of entropy is undesirable.
> A performance test of the approaches (and variants) should be done for
> reference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-rng] coveralls commented on issue #49: RNG-98: LongJumpableUniformRandomProvider
coveralls commented on issue #49: RNG-98: LongJumpableUniformRandomProvider URL: https://github.com/apache/commons-rng/pull/49#issuecomment-500614615 [](https://coveralls.io/builds/23908529) Coverage increased (+0.01%) to 98.906% when pulling **f7489bd00271216dd8fee4adb27288f993d096f2 on aherbert:feature-RNG-98** into **715451cea693e103c180c0599a201455d6673a12 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] aherbert opened a new pull request #49: RNG-98: LongJumpableUniformRandomProvider
aherbert opened a new pull request #49: RNG-98: LongJumpableUniformRandomProvider URL: https://github.com/apache/commons-rng/pull/49 Extend functionality of the JumpableUniformRandomProvider interface with a long jump. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (JEXL-306) Ternary operator ? protects also its branches from resolution errors
[
https://issues.apache.org/jira/browse/JEXL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-306.
Resolution: Fixed
https://github.com/apache/commons-jexl/commit/c6fa248e6c51c36a61be9d7bc6b6b15d4013875e
> Ternary operator ? protects also its branches from resolution errors
>
>
> Key: JEXL-306
> URL: https://issues.apache.org/jira/browse/JEXL-306
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> Consider the following test case (suppose its added to IfTest)
> {code:java}
> @Test
> public void testTernaryFail() throws Exception {
> JexlEvalContext jc = new JexlEvalContext();
> JexlExpression e = JEXL.createExpression("false ? bar : quux");
> Object o;
> jc.setStrict(true);
> jc.setSilent(false);
> try {
> o = e.evaluate(jc);
> Assert.fail("Should have failed");
> } catch (Exception ex) {
> // OK
> }
> }
> {code}
> The expected behavior is to fail with {{undefined variable...}} because
> neither {{bar}} nor {{quux}} is defined
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RNG-97) JumpableUniformRandomProvider
[
https://issues.apache.org/jira/browse/RNG-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex D Herbert resolved RNG-97.
---
Resolution: Implemented
In master.
> JumpableUniformRandomProvider
> -
>
> Key: RNG-97
> URL: https://issues.apache.org/jira/browse/RNG-97
> Project: Commons RNG
> Issue Type: New Feature
> Components: client-api, core
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Major
> Fix For: 1.3
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> A feature of random number generators is their internal state is updated for
> every generation of a new random number. This is a single step. Some
> generators have the ability to compute the update to the state that is
> required to advance *{{n}}* steps. This is a jump. This can be supported
> using a new interface:
> {code:java}
> /**
> * Applies to generators that can be advanced a large number of
> * steps of the output sequence in a single operation.
> */
> public interface JumpableUniformRandomProvider
> extends UniformRandomProvider {
> /**
> * Creates a copy of the UniformRandomProvider and advances the
> * state of the copy. The state of the current instance is not altered.
> * The state of the copy will be advanced an equivalent of {@code n}
> * sequential calls to a method that updates the state of the provider.
> *
> * @return the copy with an advanced state
> */
> JumpableUniformRandomProvider jump();
> }
> {code}
> A suggestion for how to document an implementation is:
> {code:java}
> public class JumpableRNG implements JumpableUniformRandomProvider {
> /**
> * {@inheritDoc}
> *
> * The jump size {@code n} is the equivalent of
> 232
> * calls to {@link UniformRandomProvider#nextLong() nextLong()}.
> */
> @Override
> public JumpableUniformRandomProvider jump() {
> return ...;
> }
> // etc.
> }
> {code}
> Notes on the interface:
> * A copy is returned
> * The original is not altered and so multiple calls to jump will return the
> same generator with an advanced state
> The intended use case is to create multiple copies of a RNG that will not
> overlap in sequence for use in parallel computations. A helper method can be
> added to {{RandomSource}} to facilitate this:
> {code:java}
> /**
> * Create a series of {@code n} generators by jumping from the source
> generator
> * {@code n} times. The resulting set of generators can be used in parallel
> * computations with a guarantee of no sequence overlap for at least the
> * length of the jump distance.
> *
> * Note: The source generator state is not affected. Reuse of this
> * generator may overlap with output from the jump series.
> *
> * @param source The source generator.
> * @param n The size of the series.
> */
> public static UniformRandomProvider[] createJumpSeries(
> JumpableUniformRandomProvider source, int n) {
> if (n <= 0) {
> throw new IllegalArgumentException("Size must be strictly positive");
> }
> final UniformRandomProvider[] rngs = new UniformRandomProvider[n];
> for (int i = 0; i < n; i++) {
> source = source.jump();
> // Option to wrap the JumpableUniformRandomProvider to
> // restrict to the functionality of UniformRandomProvider
> rngs[i] = source;
> }
> return rngs;
> }
> {code}
> Note: There is the possibility to wrap the jumped RNGs to restrict their
> functionality to UniformRandomProvider (or RestorableUniformRandomProvider).
> This prevents any of the series from being jumped again.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-rng] asfgit merged pull request #48: RNG-97: JumpableUniformRandomProvider
asfgit merged pull request #48: RNG-97: JumpableUniformRandomProvider URL: https://github.com/apache/commons-rng/pull/48 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (NUMBERS-110) Define Java Module Names for all modules
[
https://issues.apache.org/jira/browse/NUMBERS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise resolved NUMBERS-110.
-
Resolution: Resolved
> Define Java Module Names for all modules
>
>
> Key: NUMBERS-110
> URL: https://issues.apache.org/jira/browse/NUMBERS-110
> Project: Commons Numbers
> Issue Type: Improvement
> Components: combinatorics, complex, core, fraction, gamma, primes,
> quaternion
>Affects Versions: 1.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Problem*
> * For JDK9+ each component/artifact should have a valid Module name for the
> Java Module system.
> * It is not necessarily to have a {{module-info.java}} (only for JDK9+
> possible) file within the build but at least defining an
> {{Automatic-Module-Name}} manifest entry.
> like this:
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
>
> org.apache.commons.numbers.
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (NUMBERS-110) Define Java Module Names for all modules
[
https://issues.apache.org/jira/browse/NUMBERS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reopened NUMBERS-110:
-
> Define Java Module Names for all modules
>
>
> Key: NUMBERS-110
> URL: https://issues.apache.org/jira/browse/NUMBERS-110
> Project: Commons Numbers
> Issue Type: Improvement
> Components: combinatorics, complex, core, fraction, gamma, primes,
> quaternion
>Affects Versions: 1.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Problem*
> * For JDK9+ each component/artifact should have a valid Module name for the
> Java Module system.
> * It is not necessarily to have a {{module-info.java}} (only for JDK9+
> possible) file within the build but at least defining an
> {{Automatic-Module-Name}} manifest entry.
> like this:
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
>
> org.apache.commons.numbers.
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JEXL-306) Ternary operator ? protects also its branches from resolution errors
[
https://issues.apache.org/jira/browse/JEXL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860139#comment-16860139
]
Henri Biestro commented on JEXL-306:
Intermediate commit
https://github.com/apache/commons-jexl/commit/a69782bea469a766f71f12f76e9d5154b7415be4
> Ternary operator ? protects also its branches from resolution errors
>
>
> Key: JEXL-306
> URL: https://issues.apache.org/jira/browse/JEXL-306
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> Consider the following test case (suppose its added to IfTest)
> {code:java}
> @Test
> public void testTernaryFail() throws Exception {
> JexlEvalContext jc = new JexlEvalContext();
> JexlExpression e = JEXL.createExpression("false ? bar : quux");
> Object o;
> jc.setStrict(true);
> jc.setSilent(false);
> try {
> o = e.evaluate(jc);
> Assert.fail("Should have failed");
> } catch (Exception ex) {
> // OK
> }
> }
> {code}
> The expected behavior is to fail with {{undefined variable...}} because
> neither {{bar}} nor {{quux}} is defined
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEOMETRY-57) BigFraction Constructors are private
[
https://issues.apache.org/jira/browse/GEOMETRY-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed GEOMETRY-57.
---
Resolution: Fixed
> BigFraction Constructors are private
>
>
> Key: GEOMETRY-57
> URL: https://issues.apache.org/jira/browse/GEOMETRY-57
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 1.0
>
>
> *Problem*
> * The classes DiskGenerator/SphereGenerator are accessing a public
> constructor of class {{BigFraction}} which is not public in
> {{commons-numbers-fraction}}
> *Goal*
> * Use factory method instead of private constructor
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEOMETRY-57) BigFraction Constructors are private
[
https://issues.apache.org/jira/browse/GEOMETRY-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated GEOMETRY-57:
Affects Version/s: 1.0
> BigFraction Constructors are private
>
>
> Key: GEOMETRY-57
> URL: https://issues.apache.org/jira/browse/GEOMETRY-57
> Project: Apache Commons Geometry
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 1.0
>
>
> *Problem*
> * The classes DiskGenerator/SphereGenerator are accessing a public
> constructor of class {{BigFraction}} which is not public in
> {{commons-numbers-fraction}}
> *Goal*
> * Use factory method instead of private constructor
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEOMETRY-57) BigFraction Constructors are private
[
https://issues.apache.org/jira/browse/GEOMETRY-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned GEOMETRY-57:
---
Assignee: Karl Heinz Marbaise
> BigFraction Constructors are private
>
>
> Key: GEOMETRY-57
> URL: https://issues.apache.org/jira/browse/GEOMETRY-57
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 1.0
>
>
> *Problem*
> * The classes DiskGenerator/SphereGenerator are accessing a public
> constructor of class {{BigFraction}} which is not public in
> {{commons-numbers-fraction}}
> *Goal*
> * Use factory method instead of private constructor
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEOMETRY-56) Create distribution archive
[ https://issues.apache.org/jira/browse/GEOMETRY-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned GEOMETRY-56: --- Assignee: Karl Heinz Marbaise > 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.3#76005)
[jira] [Comment Edited] (JEXL-306) Ternary operator ? protects also its branches from resolution errors
[
https://issues.apache.org/jira/browse/JEXL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860093#comment-16860093
]
Dmitri Blinov edited comment on JEXL-306 at 6/10/19 3:43 PM:
-
Regarding the first part of the question.
Lets start with {{x?.y}}. My understanding is that this operator is simply an
inline for {code}if (x == null) return null else return x.y{code}
The {{else}} part of the {{if}} is an ordinary unprotected property access
operator that should behave just as simple {{x.y}}. So we can keep {{?.}} aside
and focus on {{??}} and {{?:}}.
I''l try to summarize what we have now for ternaries. The operator {{\??}} is
the most simple case because its only checks its left side for {{null}} or
undefined. The elvis operator {{?:}} is like {{??}} but checks its left side
not only for {{null}} or undefined, but also for the left side to be logically
{{false}}. Conventional ternary operator {{?:}} is like {{?:}} elvis operator
regarding its left-side operand, but allows to specify a value not only for
{{false}} but also for {{true}}. So, I think all ternaries differ only in their
result part, and should be equal in their treatment of the left part
was (Author: dmitri_blinov):
Regarding the first part of the question.
Lets start with {{x?.y}}. My understanding is that this operator is simply an
inline for {code}if (x == null) return null else return x.y{code}
The {{else}} part of the {{if}} is an ordinary unprotected property access
operator that should behave just as simple {{x.y}}. So we can keep {{?.} aside
and focus on {{??}}, {{?:}}.
I''l try to summarize what we have now for ternaries. The operator {{\??}} is
the most simple case because its only checks its left side for {{null}} or
undefined. The elvis operator {{?:}} is like {{??}} but checks its left side
not only for {{null}} or undefined, but also for the left side to be logically
{{false}}. Conventional ternary operator {{? : }} is like {{?:}} elvis operator
regarding its left-side operand, but allows to specify a value not only for
{{false}} but also for {{true}}. So, I think all ternaries differ only in their
result part, and should be equal in their treatment of the left part
> Ternary operator ? protects also its branches from resolution errors
>
>
> Key: JEXL-306
> URL: https://issues.apache.org/jira/browse/JEXL-306
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> Consider the following test case (suppose its added to IfTest)
> {code:java}
> @Test
> public void testTernaryFail() throws Exception {
> JexlEvalContext jc = new JexlEvalContext();
> JexlExpression e = JEXL.createExpression("false ? bar : quux");
> Object o;
> jc.setStrict(true);
> jc.setSilent(false);
> try {
> o = e.evaluate(jc);
> Assert.fail("Should have failed");
> } catch (Exception ex) {
> // OK
> }
> }
> {code}
> The expected behavior is to fail with {{undefined variable...}} because
> neither {{bar}} nor {{quux}} is defined
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JEXL-306) Ternary operator ? protects also its branches from resolution errors
[
https://issues.apache.org/jira/browse/JEXL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860093#comment-16860093
]
Dmitri Blinov commented on JEXL-306:
Regarding the first part of the question.
Lets start with {{x?.y}}. My understanding is that this operator is simply an
inline for {code}if (x == null) return null else return x.y{code}
The {{else}} part of the {{if}} is an ordinary unprotected property access
operator that should behave just as simple {{x.y}}. So we can keep {{?.} aside
and focus on {{??}}, {{?:}}.
I''l try to summarize what we have now for ternaries. The operator {{\??}} is
the most simple case because its only checks its left side for {{null}} or
undefined. The elvis operator {{?:}} is like {{??}} but checks its left side
not only for {{null}} or undefined, but also for the left side to be logically
{{false}}. Conventional ternary operator {{? : }} is like {{?:}} elvis operator
regarding its left-side operand, but allows to specify a value not only for
{{false}} but also for {{true}}. So, I think all ternaries differ only in their
result part, and should be equal in their treatment of the left part
> Ternary operator ? protects also its branches from resolution errors
>
>
> Key: JEXL-306
> URL: https://issues.apache.org/jira/browse/JEXL-306
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> Consider the following test case (suppose its added to IfTest)
> {code:java}
> @Test
> public void testTernaryFail() throws Exception {
> JexlEvalContext jc = new JexlEvalContext();
> JexlExpression e = JEXL.createExpression("false ? bar : quux");
> Object o;
> jc.setStrict(true);
> jc.setSilent(false);
> try {
> o = e.evaluate(jc);
> Assert.fail("Should have failed");
> } catch (Exception ex) {
> // OK
> }
> }
> {code}
> The expected behavior is to fail with {{undefined variable...}} because
> neither {{bar}} nor {{quux}} is defined
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-110) Define Java Module Names for all modules
[
https://issues.apache.org/jira/browse/NUMBERS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860054#comment-16860054
]
Gilles commented on NUMBERS-110:
It is generally better to "resolve" a report rather than "close" it (so that it
could be reopened if necessary).
All resolved issues are "bulk-closed" post-release.
> Define Java Module Names for all modules
>
>
> Key: NUMBERS-110
> URL: https://issues.apache.org/jira/browse/NUMBERS-110
> Project: Commons Numbers
> Issue Type: Improvement
> Components: combinatorics, complex, core, fraction, gamma, primes,
> quaternion
>Affects Versions: 1.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Problem*
> * For JDK9+ each component/artifact should have a valid Module name for the
> Java Module system.
> * It is not necessarily to have a {{module-info.java}} (only for JDK9+
> possible) file within the build but at least defining an
> {{Automatic-Module-Name}} manifest entry.
> like this:
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
>
> org.apache.commons.numbers.
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JEXL-306) Ternary operator ? protects also its branches from resolution errors
[
https://issues.apache.org/jira/browse/JEXL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860053#comment-16860053
]
Dmitri Blinov commented on JEXL-306:
Regarding second part of the question, consider the following example {code}x.y
? 1 : 2{code}
It returns 2 because x.y is undefined ant-ish variable. Another example that
returns 2 is {code}var x = {'a':1}; x.y ? 1 : 2{code}
My opinion is that we would expect predicted equal behaviour from syntactically
equal constructs. So yes - ternaries should protect from unsolvable properties.
> Ternary operator ? protects also its branches from resolution errors
>
>
> Key: JEXL-306
> URL: https://issues.apache.org/jira/browse/JEXL-306
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> Consider the following test case (suppose its added to IfTest)
> {code:java}
> @Test
> public void testTernaryFail() throws Exception {
> JexlEvalContext jc = new JexlEvalContext();
> JexlExpression e = JEXL.createExpression("false ? bar : quux");
> Object o;
> jc.setStrict(true);
> jc.setSilent(false);
> try {
> o = e.evaluate(jc);
> Assert.fail("Should have failed");
> } catch (Exception ex) {
> // OK
> }
> }
> {code}
> The expected behavior is to fail with {{undefined variable...}} because
> neither {{bar}} nor {{quux}} is defined
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (NUMBERS-110) Define Java Module Names for all modules
[
https://issues.apache.org/jira/browse/NUMBERS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed NUMBERS-110.
---
Resolution: Fixed
> Define Java Module Names for all modules
>
>
> Key: NUMBERS-110
> URL: https://issues.apache.org/jira/browse/NUMBERS-110
> Project: Commons Numbers
> Issue Type: Improvement
> Components: combinatorics, complex, core, fraction, gamma, primes,
> quaternion
>Affects Versions: 1.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Problem*
> * For JDK9+ each component/artifact should have a valid Module name for the
> Java Module system.
> * It is not necessarily to have a {{module-info.java}} (only for JDK9+
> possible) file within the build but at least defining an
> {{Automatic-Module-Name}} manifest entry.
> like this:
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
>
> org.apache.commons.numbers.
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (NUMBERS-110) Define Java Module Names for all modules
[
https://issues.apache.org/jira/browse/NUMBERS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reopened NUMBERS-110:
-
Assignee: Karl Heinz Marbaise
> Define Java Module Names for all modules
>
>
> Key: NUMBERS-110
> URL: https://issues.apache.org/jira/browse/NUMBERS-110
> Project: Commons Numbers
> Issue Type: Improvement
> Components: combinatorics, complex, core, fraction, gamma, primes,
> quaternion
>Affects Versions: 1.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Problem*
> * For JDK9+ each component/artifact should have a valid Module name for the
> Java Module system.
> * It is not necessarily to have a {{module-info.java}} (only for JDK9+
> possible) file within the build but at least defining an
> {{Automatic-Module-Name}} manifest entry.
> like this:
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
>
> org.apache.commons.numbers.
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JEXL-306) Ternary operator ? protects also its branches from resolution errors
[
https://issues.apache.org/jira/browse/JEXL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859823#comment-16859823
]
Henri Biestro edited comment on JEXL-306 at 6/10/19 2:33 PM:
-
Not a regression but the behaviour between '??', '?:' wrt '?.' and the 'safe'
mode seems inconsistent. The question is twofold:
* should all ternaries behave the same (aka ?: and ??) wrt to unsolvable
variables and properties?
* should the ternaries also protect from unsolvable properties - or only from
unsolvable variables - in non-safe mode?
was (Author: henrib):
Not a regression but the behaviour between '??', '?:' wrt '?.' and the 'safe'
mode seems inconsistent. The question is twofold:
* should all ternaries behave the same (aka ?: and ??) wrt to unsolvable
variables and properties?
* should the ternaries also protect from unsolvable properties - or only from
unsolvable variables) in non-safe mode?
> Ternary operator ? protects also its branches from resolution errors
>
>
> Key: JEXL-306
> URL: https://issues.apache.org/jira/browse/JEXL-306
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> Consider the following test case (suppose its added to IfTest)
> {code:java}
> @Test
> public void testTernaryFail() throws Exception {
> JexlEvalContext jc = new JexlEvalContext();
> JexlExpression e = JEXL.createExpression("false ? bar : quux");
> Object o;
> jc.setStrict(true);
> jc.setSilent(false);
> try {
> o = e.evaluate(jc);
> Assert.fail("Should have failed");
> } catch (Exception ex) {
> // OK
> }
> }
> {code}
> The expected behavior is to fail with {{undefined variable...}} because
> neither {{bar}} nor {{quux}} is defined
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JEXL-306) Ternary operator ? protects also its branches from resolution errors
[
https://issues.apache.org/jira/browse/JEXL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859823#comment-16859823
]
Henri Biestro edited comment on JEXL-306 at 6/10/19 2:32 PM:
-
Not a regression but the behaviour between '??', '?:' wrt '?.' and the 'safe'
mode seems inconsistent. The question is twofold:
* should all ternaries behave the same (aka ?: and ??) wrt to unsolvable
variables and properties?
* should the ternaries also protect from unsolvable properties - or only from
unsolvable variables) in non-safe mode?
was (Author: henrib):
Regression, reopen. Sorry
> Ternary operator ? protects also its branches from resolution errors
>
>
> Key: JEXL-306
> URL: https://issues.apache.org/jira/browse/JEXL-306
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> Consider the following test case (suppose its added to IfTest)
> {code:java}
> @Test
> public void testTernaryFail() throws Exception {
> JexlEvalContext jc = new JexlEvalContext();
> JexlExpression e = JEXL.createExpression("false ? bar : quux");
> Object o;
> jc.setStrict(true);
> jc.setSilent(false);
> try {
> o = e.evaluate(jc);
> Assert.fail("Should have failed");
> } catch (Exception ex) {
> // OK
> }
> }
> {code}
> The expected behavior is to fail with {{undefined variable...}} because
> neither {{bar}} nor {{quux}} is defined
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-57) BigFraction Constructors are private
[
https://issues.apache.org/jira/browse/GEOMETRY-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860018#comment-16860018
]
Karl Heinz Marbaise commented on GEOMETRY-57:
-
Done in
[928abf9c284ab66fd9469997cce42e040ba072ba|http://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=commitdiff;h=928abf9c284ab66fd9469997cce42e040ba072ba]
> BigFraction Constructors are private
>
>
> Key: GEOMETRY-57
> URL: https://issues.apache.org/jira/browse/GEOMETRY-57
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 1.0
>
>
> *Problem*
> * The classes DiskGenerator/SphereGenerator are accessing a public
> constructor of class {{BigFraction}} which is not public in
> {{commons-numbers-fraction}}
> *Goal*
> * Use factory method instead of private constructor
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEOMETRY-57) BigFraction Constructors are private
[
https://issues.apache.org/jira/browse/GEOMETRY-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated GEOMETRY-57:
Summary: BigFraction Constructors are private (was: WIP - BigFraction
Constructors are private)
> BigFraction Constructors are private
>
>
> Key: GEOMETRY-57
> URL: https://issues.apache.org/jira/browse/GEOMETRY-57
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 1.0
>
>
> *Problem*
> * The classes DiskGenerator/SphereGenerator are accessing a public
> constructor of class {{BigFraction}} which is not public in
> {{commons-numbers-fraction}}
> *Goal*
> * Use factory method instead of private constructor
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEOMETRY-57) WIP - BigFraction Constructors are private
[
https://issues.apache.org/jira/browse/GEOMETRY-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated GEOMETRY-57:
Description:
*Problem*
* The classes DiskGenerator/SphereGenerator are accessing a public constructor
of class {{BigFraction}} which is not public in {{commons-numbers-fraction}}
*Goal*
* Use factory method instead of private constructor
was:
*Problem*
* The class DiskGenerator is accessing a public constructor of class
{{BigFraction}} which is not public in {{commons-numbers-fraction}}
*Goal*
* Use factory method instead of private constructor
> WIP - BigFraction Constructors are private
> --
>
> Key: GEOMETRY-57
> URL: https://issues.apache.org/jira/browse/GEOMETRY-57
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 1.0
>
>
> *Problem*
> * The classes DiskGenerator/SphereGenerator are accessing a public
> constructor of class {{BigFraction}} which is not public in
> {{commons-numbers-fraction}}
> *Goal*
> * Use factory method instead of private constructor
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEOMETRY-57) WIP - BigFraction Constructors are private
[
https://issues.apache.org/jira/browse/GEOMETRY-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated GEOMETRY-57:
Summary: WIP - BigFraction Constructors are private (was: BigFraction
Constructors are private)
> WIP - BigFraction Constructors are private
> --
>
> Key: GEOMETRY-57
> URL: https://issues.apache.org/jira/browse/GEOMETRY-57
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 1.0
>
>
> *Problem*
> * The class DiskGenerator is accessing a public constructor of class
> {{BigFraction}} which is not public in {{commons-numbers-fraction}}
> *Goal*
> * Use factory method instead of private constructor
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEOMETRY-57) BigFraction Constructors are private
Karl Heinz Marbaise created GEOMETRY-57:
---
Summary: BigFraction Constructors are private
Key: GEOMETRY-57
URL: https://issues.apache.org/jira/browse/GEOMETRY-57
Project: Apache Commons Geometry
Issue Type: Bug
Reporter: Karl Heinz Marbaise
Fix For: 1.0
*Problem*
* The class DiskGenerator is accessing a public constructor of class
{{BigFraction}} which is not public in {{commons-numbers-fraction}}
*Goal*
* Use factory method instead of private constructor
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1394) Implementation of DIRECT global optimizer
[ https://issues.apache.org/jira/browse/MATH-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859971#comment-16859971 ] Gilles commented on MATH-1394: -- Sorry I somehow missed this report. As it is, the code cannot be imported into the "Commons Math" code base (because of divergence on what constitutes _free_ in the views of Apache vs GNU). I see that you are one of the authors of the referred sources. That functionality will be welcome in "Commons Math". Are you willing to port it (rebased on the current "master" branch) and provide it under ASL v2? > Implementation of DIRECT global optimizer > - > > Key: MATH-1394 > URL: https://issues.apache.org/jira/browse/MATH-1394 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.5, 3.6 >Reporter: Burton Patkau >Priority: Major > Fix For: 4.X > > > An open source implementation of the DIRECT global optimizer, described by > Jones, Perttunen and Stuckmann, implementing > math3.optim.nonlinear.scalar.MultivariateOptimizer, is available as > DIRECTOptimizer.java at > https://github.com/edwardkort/WWIDesigner/tree/optimizer/WWIDesigner/src/main/com/wwidesigner/math. > There are also three variants of the algorithm on that page: > DIRECT_L_Optimizer implements DIRECT-L by Gablonsky and Kelley, > DIRECT1Optimizer changes which sides are chosen for dividing, and > DIRECTCOptimizer adds alternative ways to select potentially-optimal > hyperrectangles. > DIRECT is not as fast as BOBYQA, but is better at finding a global minimum in > a field of many local minima. > JUnit tests for all of these, using standard optimizer test functions, are > available in > https://github.com/edwardkort/WWIDesigner/tree/optimizer/WWIDesigner/src/test/com/wwidesigner/math. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-beanutils] melloware removed a comment on issue #7: BEANUTILS-520: Mitigate CVE-2014-0114 by enabling SuppressPropertiesB…
melloware removed a comment on issue #7: BEANUTILS-520: Mitigate CVE-2014-0114 by enabling SuppressPropertiesB… URL: https://github.com/apache/commons-beanutils/pull/7#issuecomment-495029626 I am not sure why Travis is failing as all the tests and code is building with "mvn clean package" on my laptop. Any guidance or anything I need to fix? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] coveralls edited a comment on issue #48: RNG-97: JumpableUniformRandomProvider
coveralls edited a comment on issue #48: RNG-97: JumpableUniformRandomProvider URL: https://github.com/apache/commons-rng/pull/48#issuecomment-500252284 [](https://coveralls.io/builds/23895106) Coverage increased (+0.09%) to 98.896% when pulling **c030d858076cc106213831cb8361d1f342bf26a2 on aherbert:feature-RNG-97** into **9dee400502fbd1d6a39fc08fd63c2ceb21c0c990 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-numbers] Schamschi commented on issue #48: [WIP] perform the actual migration to JUnit 5
Schamschi commented on issue #48: [WIP] perform the actual migration to JUnit 5 URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-500389290 @grimreaper Why did you agree to wait for the pull request #36 to be merged (or closed unmerged) and then go ahead and refactor `FractionTest` anyway? Not only did I replace several `Assert.assertEquals` pairs comparing the numerator and denominator separately with a single call to the method `assertFraction`, which already reduces the number of `Assert` references drastically, but I also added anonymous blocks in the test methods to make them a little less messy, and resolving the conflicts arising from the introduction of these anonymous blocks in a merge or rebase is _very_ laborious – I already did it once yesterday when updating my pull request to be compatible with the changes introduced by the merge of fraction-dev, and the thought of doing it a second time is rather off-putting. Besides, I don't think `assertEquals(a, b)` and `assertTrue(a.equals(b))` are 100% interchangeable, because, the way I see it, they reflect different intentions, even if they may be functionally equivalent most of the time. Judging by its design and the names for the parameters, `assertEquals(a, b)` is meant for situations where you have a pre-computed (at compile- or runtime), "expected" value, against which an unknown, "actual" value computed at runtime is checked. But there may be situations where both values are unknown, and one is not necessarily more correct than the other, for example, when comparing two hash codes, or when testing the `equals` method itself. Speaking of testing the `equals` method: Although not done in this case as far as I am aware, I could imagine a scenario where one would want to test of the symmetry of the `equals` method by testing both `a.equals(b)` and `b.equals(a)`. `assertEquals` does not specify whose object's `equals` method is called, so replacing `assertTrue` constructs with `assertEquals` constructs here seems inappropriate. A situation related to this can be found in the class `BigFractionTest`, line 601, where the original code called the `equals` method of `BigFraction` with a `Double` argument: > `Assert.assertFalse(zero.equals(Double.valueOf(0)));` So in this case, it is crucial for the validity of the test that the `equals` method of the `BigFraction` instance `zero` is called, and not the `equals` method of the `Double`. However, in its current version, the `equals` method of `Double` is called: > `Assertions.assertNotEquals(0.0d, zero);` `0.0d` is implicitly boxed to `Double`, and since `assertNotEquals` calls the `equals` method of the first argument (which is an implementation detailed and not documented), the test becomes useless. By this logic, there are situations where I find your conversion from `assertTrue` to `assertEquals` absolutely beneficial, for example, the `testParse()` method in the class `ComplexTest` from the "complex" module, or `testMath843()` in `PrecisionTest` in the "Core" module, thank you. Also, the original parameter order for `assertEquals` in SmallPrimesTest was correct, and your change to the file `ArithmeticUtilsTest` in the commit "Simplify junit" also has the parameters in the wrong order, but I don't have time to fix it now, maybe you can tend to it if you get back here before I do. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (COMPRESS-489) Reading Central File Header and Archive extra data record, with out Skipping
[ https://issues.apache.org/jira/browse/COMPRESS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anvesh Mora updated COMPRESS-489: - Description: - Some Zip files store extra data in CFH and AED. Right now it seems that we are skipping the meta data instead of making it available to consumer and choose to use it or not. - It might sound small change but right now this kind of flexibility is not allowed with inheritance, due to lot of private and package access specifiers ( NOT open for extension) - If extension is not something we are looking, providing a method which allows to store CFH and AED data based on a flag, should make it work. I had similar requirement in my current development and I had to re-write the component and use below code-snippet in ZipArchieveInputStream#getNextZipEntry method: !image-2019-06-10-17-02-33-972.png! was: - Some Zip files store extra data in CFH and AED. Right now it seems that we are skipping the meta data instead of making it available to consumer and choose to use it or not. - It might sound small change but right now this kind of flexibility is not allowed with inheritance, due to lot of private and package access specifiers ( NOT open for extension) - If extension is not something we are looking, providing a method which allows to store CFH and AED data based on a flag, should make it work. > Reading Central File Header and Archive extra data record, with out Skipping > > > Key: COMPRESS-489 > URL: https://issues.apache.org/jira/browse/COMPRESS-489 > Project: Commons Compress > Issue Type: Improvement >Reporter: Anvesh Mora >Priority: Minor > Attachments: image-2019-06-10-17-02-33-972.png > > > - Some Zip files store extra data in CFH and AED. Right now it seems that we > are skipping the meta data instead of making it available to consumer and > choose to use it or not. > - It might sound small change but right now this kind of flexibility is not > allowed with inheritance, due to lot of private and package access specifiers > ( NOT open for extension) > - If extension is not something we are looking, providing a method which > allows to store CFH and AED data based on a flag, should make it work. > > I had similar requirement in my current development and I had to re-write the > component and use below code-snippet in > ZipArchieveInputStream#getNextZipEntry method: > !image-2019-06-10-17-02-33-972.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (COMPRESS-489) Reading Central File Header and Archive extra data record, with out Skipping
[ https://issues.apache.org/jira/browse/COMPRESS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anvesh Mora updated COMPRESS-489: - Attachment: image-2019-06-10-17-02-33-972.png > Reading Central File Header and Archive extra data record, with out Skipping > > > Key: COMPRESS-489 > URL: https://issues.apache.org/jira/browse/COMPRESS-489 > Project: Commons Compress > Issue Type: Improvement >Reporter: Anvesh Mora >Priority: Minor > Attachments: image-2019-06-10-17-02-33-972.png > > > - Some Zip files store extra data in CFH and AED. Right now it seems that we > are skipping the meta data instead of making it available to consumer and > choose to use it or not. > - It might sound small change but right now this kind of flexibility is not > allowed with inheritance, due to lot of private and package access specifiers > ( NOT open for extension) > - If extension is not something we are looking, providing a method which > allows to store CFH and AED data based on a flag, should make it work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COMPRESS-489) Reading Central File Header and Archive extra data record, with out Skipping
Anvesh Mora created COMPRESS-489: Summary: Reading Central File Header and Archive extra data record, with out Skipping Key: COMPRESS-489 URL: https://issues.apache.org/jira/browse/COMPRESS-489 Project: Commons Compress Issue Type: Improvement Reporter: Anvesh Mora - Some Zip files store extra data in CFH and AED. Right now it seems that we are skipping the meta data instead of making it available to consumer and choose to use it or not. - It might sound small change but right now this kind of flexibility is not allowed with inheritance, due to lot of private and package access specifiers ( NOT open for extension) - If extension is not something we are looking, providing a method which allows to store CFH and AED data based on a flag, should make it work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MATH-1487) MathInternalError - Kolmogorov Smirnov Test
[
https://issues.apache.org/jira/browse/MATH-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859938#comment-16859938
]
Gilles commented on MATH-1487:
--
Thanks for the report, but please check that the bug is still present in the
[development version of the
library|https://gitbox.apache.org/repos/asf?p=commons-math.git] (you can find
the latest snapshots
[here|https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-math4/4.0-SNAPSHOT/]).
> MathInternalError - Kolmogorov Smirnov Test
> ---
>
> Key: MATH-1487
> URL: https://issues.apache.org/jira/browse/MATH-1487
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Paweł Lipiński
>Priority: Critical
> Attachments: alpha.arr, beta.arr
>
>
> Hi,
> I spotted a pesky bug in KolmogorovSmirnovTest class, in the method
> kolmogorovSmirnovTest.
> In order to reproduce the error use arrays from attachments.
> Stacktrace:
> {noformat}
> org.apache.commons.math3.exception.MathInternalError: illegal state: internal
> error, please fill a bug report at https://issues.apache.org/jira/browse/MATH
> at
> org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.fixTies(KolmogorovSmirnovTest.java:1171)
> at
> org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.kolmogorovSmirnovTest(KolmogorovSmirnovTest.java:263)
> at
> org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.kolmogorovSmirnovTest(KolmogorovSmirnovTest.java:290)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEOMETRY-56) Create distribution archive
Karl Heinz Marbaise created GEOMETRY-56: --- Summary: 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 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.3#76005)
[jira] [Reopened] (JEXL-306) Ternary operator ? protects also its branches from resolution errors
[
https://issues.apache.org/jira/browse/JEXL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro reopened JEXL-306:
> Ternary operator ? protects also its branches from resolution errors
>
>
> Key: JEXL-306
> URL: https://issues.apache.org/jira/browse/JEXL-306
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> Consider the following test case (suppose its added to IfTest)
> {code:java}
> @Test
> public void testTernaryFail() throws Exception {
> JexlEvalContext jc = new JexlEvalContext();
> JexlExpression e = JEXL.createExpression("false ? bar : quux");
> Object o;
> jc.setStrict(true);
> jc.setSilent(false);
> try {
> o = e.evaluate(jc);
> Assert.fail("Should have failed");
> } catch (Exception ex) {
> // OK
> }
> }
> {code}
> The expected behavior is to fail with {{undefined variable...}} because
> neither {{bar}} nor {{quux}} is defined
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-135) Char escape doesn't work
[
https://issues.apache.org/jira/browse/CSV-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859836#comment-16859836
]
Opher Shachar commented on CSV-135:
---
I think this
{quote}The problem arises when both quoting and escaping are specified.
{quote}
is _never_ the case. {{CSVFormat}} will either do {{printWithQuotes}} _OR_
{{printWithEscapes}}, irrespective of setting both {{quoteCharacter}} and
{{escapeCharacter}}.
> Char escape doesn't work
>
>
> Key: CSV-135
> URL: https://issues.apache.org/jira/browse/CSV-135
> Project: Commons CSV
> Issue Type: Bug
> Components: Printer
>Affects Versions: 1.0
>Reporter: Mateusz Zakarczemny
>Priority: Major
> Fix For: Patch Needed
>
>
> Following code:
> {code}
> CSVFormat format = CSVFormat.DEFAULT
> .withRecordSeparator('\n')
> .withQuote('"')
> .withEscape('\\');
> CSVPrinter printer = new CSVPrinter(System.out, format);
> List l = new LinkedList();
> l.add("\"");
> l.add("\n");
> l.add("\\");
> printer.printRecord(l);
> {code}
> produces
> {code}
> ,"
> ","\"
> {code}
> instead of
> {code}
> "\"","\n","\\"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-io] rerewww closed pull request #71: [IO-592] Modified FileUtilsDirectoryContainsTestCase File
rerewww closed pull request #71: [IO-592] Modified FileUtilsDirectoryContainsTestCase File URL: https://github.com/apache/commons-io/pull/71 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (JEXL-306) Ternary operator ? protects also its branches from resolution errors
[
https://issues.apache.org/jira/browse/JEXL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859823#comment-16859823
]
Henri Biestro commented on JEXL-306:
Regression, reopen. Sorry
> Ternary operator ? protects also its branches from resolution errors
>
>
> Key: JEXL-306
> URL: https://issues.apache.org/jira/browse/JEXL-306
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> Consider the following test case (suppose its added to IfTest)
> {code:java}
> @Test
> public void testTernaryFail() throws Exception {
> JexlEvalContext jc = new JexlEvalContext();
> JexlExpression e = JEXL.createExpression("false ? bar : quux");
> Object o;
> jc.setStrict(true);
> jc.setSilent(false);
> try {
> o = e.evaluate(jc);
> Assert.fail("Should have failed");
> } catch (Exception ex) {
> // OK
> }
> }
> {code}
> The expected behavior is to fail with {{undefined variable...}} because
> neither {{bar}} nor {{quux}} is defined
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JEXL-306) Ternary operator ? protects also its branches from resolution errors
[
https://issues.apache.org/jira/browse/JEXL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859816#comment-16859816
]
Dmitri Blinov edited comment on JEXL-306 at 6/10/19 8:24 AM:
-
The following script throws an exception "Undefined property y"
{code:java}
var x = new ("java.lang.Object"); x.y ? 1 : 2{code}
I'm confused, is it a supposed behaviour? Shouldn't it return {{2}} just like in
{code:java}
x ? 1 : 2{code}?
was (Author: dmitri_blinov):
The following script throws an exception "Undefined property y"
{code:java}
var x = new ("java.lang.Object"); x.y ? 1 : 2{code}
I'm confused, is it a supposed behaviour? Should it return {{2}} just like in
{code:java}
x ? 1 : 2{code}
> Ternary operator ? protects also its branches from resolution errors
>
>
> Key: JEXL-306
> URL: https://issues.apache.org/jira/browse/JEXL-306
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> Consider the following test case (suppose its added to IfTest)
> {code:java}
> @Test
> public void testTernaryFail() throws Exception {
> JexlEvalContext jc = new JexlEvalContext();
> JexlExpression e = JEXL.createExpression("false ? bar : quux");
> Object o;
> jc.setStrict(true);
> jc.setSilent(false);
> try {
> o = e.evaluate(jc);
> Assert.fail("Should have failed");
> } catch (Exception ex) {
> // OK
> }
> }
> {code}
> The expected behavior is to fail with {{undefined variable...}} because
> neither {{bar}} nor {{quux}} is defined
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JEXL-306) Ternary operator ? protects also its branches from resolution errors
[
https://issues.apache.org/jira/browse/JEXL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859816#comment-16859816
]
Dmitri Blinov commented on JEXL-306:
The following script throws an exception "Undefined property y"
{code:java}
var x = new ("java.lang.Object"); x.y ? 1 : 2{code}
I'm confused, is it a supposed behaviour? Should it return {{2}} just like in
{code:java}
x ? 1 : 2{code}
> Ternary operator ? protects also its branches from resolution errors
>
>
> Key: JEXL-306
> URL: https://issues.apache.org/jira/browse/JEXL-306
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> Consider the following test case (suppose its added to IfTest)
> {code:java}
> @Test
> public void testTernaryFail() throws Exception {
> JexlEvalContext jc = new JexlEvalContext();
> JexlExpression e = JEXL.createExpression("false ? bar : quux");
> Object o;
> jc.setStrict(true);
> jc.setSilent(false);
> try {
> o = e.evaluate(jc);
> Assert.fail("Should have failed");
> } catch (Exception ex) {
> // OK
> }
> }
> {code}
> The expected behavior is to fail with {{undefined variable...}} because
> neither {{bar}} nor {{quux}} is defined
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MATH-1487) MathInternalError - Kolmogorov Smirnov Test
[
https://issues.apache.org/jira/browse/MATH-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paweł updated MATH-1487:
Description:
Hi,
I spotted a pesky bug in KolmogorovSmirnovTest class, in the method
kolmogorovSmirnovTest.
In order to reproduce the error use arrays from attachments.
Stacktrace:
{noformat}
org.apache.commons.math3.exception.MathInternalError: illegal state: internal
error, please fill a bug report at https://issues.apache.org/jira/browse/MATH
at
org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.fixTies(KolmogorovSmirnovTest.java:1171)
at
org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.kolmogorovSmirnovTest(KolmogorovSmirnovTest.java:263)
at
org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.kolmogorovSmirnovTest(KolmogorovSmirnovTest.java:290)
{noformat}
was:
Hi,
I spotted a pesky bug in KolmogorovSmirnovTest class, in the method
kolmogorovSmirnovTest.
In order to reproduce the error use arrays from attachments.
Stacktrace
{noformat}
org.apache.commons.math3.exception.MathInternalError: illegal state: internal
error, please fill a bug report at https://issues.apache.org/jira/browse/MATH
at
org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.fixTies(KolmogorovSmirnovTest.java:1171)
at
org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.kolmogorovSmirnovTest(KolmogorovSmirnovTest.java:263)
at
org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.kolmogorovSmirnovTest(KolmogorovSmirnovTest.java:290)
{noformat}
> MathInternalError - Kolmogorov Smirnov Test
> ---
>
> Key: MATH-1487
> URL: https://issues.apache.org/jira/browse/MATH-1487
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Paweł
>Priority: Critical
> Attachments: alpha.arr, beta.arr
>
>
> Hi,
> I spotted a pesky bug in KolmogorovSmirnovTest class, in the method
> kolmogorovSmirnovTest.
> In order to reproduce the error use arrays from attachments.
> Stacktrace:
> {noformat}
> org.apache.commons.math3.exception.MathInternalError: illegal state: internal
> error, please fill a bug report at https://issues.apache.org/jira/browse/MATH
> at
> org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.fixTies(KolmogorovSmirnovTest.java:1171)
> at
> org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.kolmogorovSmirnovTest(KolmogorovSmirnovTest.java:263)
> at
> org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.kolmogorovSmirnovTest(KolmogorovSmirnovTest.java:290)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MATH-1487) MathInternalError - Kolmogorov Smirnov Test
Paweł created MATH-1487:
---
Summary: MathInternalError - Kolmogorov Smirnov Test
Key: MATH-1487
URL: https://issues.apache.org/jira/browse/MATH-1487
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.6.1
Reporter: Paweł
Attachments: alpha.arr, beta.arr
Hi,
I spotted a pesky bug in KolmogorovSmirnovTest class, in the method
kolmogorovSmirnovTest.
In order to reproduce the error use arrays from attachments.
Stacktrace
{noformat}
org.apache.commons.math3.exception.MathInternalError: illegal state: internal
error, please fill a bug report at https://issues.apache.org/jira/browse/MATH
at
org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.fixTies(KolmogorovSmirnovTest.java:1171)
at
org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.kolmogorovSmirnovTest(KolmogorovSmirnovTest.java:263)
at
org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.kolmogorovSmirnovTest(KolmogorovSmirnovTest.java:290)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] grimreaper closed pull request #49: PlaneAngleTest: use simpler JUnit assertions
grimreaper closed pull request #49: PlaneAngleTest: use simpler JUnit assertions URL: https://github.com/apache/commons-numbers/pull/49 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
