date:20230716



[ 
https://issues.apache.org/jira/browse/GEOMETRY-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743605#comment-17743605
 ] 

Matt Juntunen commented on GEOMETRY-155:


This can be done by multiplying the vector by 0.5. There is no need for a 
separate method for this.
{code:java}
Vector3D v = ...
Vector3D midPoint = v.multiply(0.5);
{code}

> Implement getMidpoint(Vector x)
> ---
>
> Key: GEOMETRY-155
> URL: https://issues.apache.org/jira/browse/GEOMETRY-155
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector and returns the point that is in the middle of the vector



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-statistics] ani5rudh commented on a diff in pull request #49: [STATISTICS-76]: Max Implementation



ani5rudh commented on code in PR #49:
URL: https://github.com/apache/commons-statistics/pull/49#discussion_r1264800171


##
commons-statistics-descriptive/src/test/java/org/apache/commons/statistics/descriptive/MaxTest.java:
##
@@ -0,0 +1,187 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.statistics.descriptive;
+
+import java.util.Arrays;
+import java.util.function.DoubleSupplier;
+import java.util.stream.Stream;
+import org.apache.commons.rng.UniformRandomProvider;
+import org.junit.jupiter.api.Assertions;
+import org.junit.jupiter.api.Test;
+import org.junit.jupiter.params.ParameterizedTest;
+import org.junit.jupiter.params.provider.Arguments;
+import org.junit.jupiter.params.provider.MethodSource;
+
+/**
+ * Test for {@link Max}.
+ */
+final class MaxTest {
+
+@Test
+void testEmpty() {
+Max max = Max.create();
+Assertions.assertEquals(Double.NEGATIVE_INFINITY, max.getAsDouble());
+}
+
+@Test
+void testIncrement() {
+// Test the max after each incremental update
+// First parameter of testArray is the value that would be added
+// Second parameter of testArray is the max we expect after adding the 
value
+double[][] testArray = {
+{1729.22, 1729.22},
+{2520.35, 2520.35},
+{2010.87, 2520.35},
+{1.1, 1.1},
+{+0.0, 1.1},
+{-0.0, 1.1},
+{Double.MAX_VALUE, Double.MAX_VALUE},
+{Double.POSITIVE_INFINITY, Double.POSITIVE_INFINITY},
+{Double.NEGATIVE_INFINITY, Double.POSITIVE_INFINITY}
+};
+
+Max stat = Max.create();
+for (final double[] valueAndExpected: testArray) {
+final double value = valueAndExpected[0];
+final double expected = valueAndExpected[1];
+stat.accept(value);
+Assertions.assertEquals(expected, stat.getAsDouble());
+}
+}
+
+@Test
+void testNaN() {
+// Test non-nan values cannot revert a NaN
+double[] testArray = {Double.NaN, +0.0d, -0.0d, 
Double.POSITIVE_INFINITY, Double.NEGATIVE_INFINITY};
+Max stat = Max.create();
+for (final double x : testArray) {
+stat.accept(x);
+Assertions.assertEquals(Double.NaN, stat.getAsDouble());
+}
+}
+
+@ParameterizedTest
+@MethodSource
+void testMax(double[] values, double expected) {
+Max stat = Max.create();
+Arrays.stream(values).forEach(stat);
+double actual = stat.getAsDouble();
+Assertions.assertEquals(expected, actual, "max");
+Assertions.assertEquals(expected, Max.of(values).getAsDouble(), "max");
+}
+
+static Stream testMax() {
+return Stream.of(
+Arguments.of(new double[] {}, Double.NEGATIVE_INFINITY),
+Arguments.of(new double[] {3.14}, 3.14),
+Arguments.of(new double[] {12.34, 56.78, -2.0}, 56.78),
+Arguments.of(new double[] {Double.NaN, 3.14, Double.NaN, 
Double.NaN}, Double.NaN),
+Arguments.of(new double[] {-1d, 1d, Double.NaN}, Double.NaN),
+Arguments.of(new double[] {Double.NaN, Double.NaN, Double.NaN}, 
Double.NaN),
+Arguments.of(new double[] {0.0d, Double.NaN, +0.0d, -0.0d, 
Double.POSITIVE_INFINITY, Double.NEGATIVE_INFINITY}, Double.NaN),
+Arguments.of(new double[] {+0.0d, -0.0d, 1.0, 3.14}, 3.14),
+Arguments.of(new double[] {-0.0, +0.0}, 0.0),
+Arguments.of(new double[] {0.0, -0.0}, 0.0),
+Arguments.of(new double[] {0.0, +0.0}, 0.0),
+Arguments.of(new double[] {1.2, -34.56, 456.789, -5678.9012}, 
456.789),
+Arguments.of(new double[] {-23467824, 23648, 2368, 23749, -23424, 
-23492, -92397747}, 23749),
+Arguments.of(new double[] {0.0d, +0.0d, -0.0d, 
Double.POSITIVE_INFINITY, Double.MIN_VALUE}, Double.POSITIVE_INFINITY),
+Arguments.of(new double[] {0.0d, +0.0d, -0.0d, 
Double.POSITIVE_INFINITY, -Double.MIN_VALUE}, Double.POSITIVE_INFINITY),
+Arguments.of(new double[] {0.0d, +0.0d, -0.0d, 
Double.POSITIVE_INFINITY,

[jira] [Commented] (GEOMETRY-150) implement isCodirectionalTo(Vector y)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743601#comment-17743601
 ] 

Matt Juntunen commented on GEOMETRY-150:


I believe this method is general enough and useful enough to warrant adding it. 
Since we must maintain backwards compatibility with 1.0 for 1.1, we need to add 
it as a default method to the interface, which (as mentioned before) we can do. 
It may be that we can override the default implementation in some cases for 
better performance. I'm not sure on that yet.

> implement isCodirectionalTo(Vector y)
> -
>
> Key: GEOMETRY-150
> URL: https://issues.apache.org/jira/browse/GEOMETRY-150
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
> Fix For: 1.1
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> implement isCodirectionalTo(Vector y) method in the Vector interface. The 
> isCodirectionalTo() checks if the 2 vectors point at the same direction. This 
> means that each vector can be obtained from the other by multiplying by a 
> positive scalar.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743597#comment-17743597
 ] 

Matt Juntunen commented on GEOMETRY-154:


[~dimitrios.efthymiou], I'm not sold on the idea of adding this method based on 
these use cases. For the graphics use case, there is already the 
{{EuclideanVector.lerp}} method, which linearly interpolates between two 
vectors. For the other use cases, one can compute the desired length ratios and 
then use scalar multiplication to get the desired vectors. The computation of 
the length ratios will depend on what the caller is trying to do and so should 
not be part of this library, IMHO.

Ex:
{code:java}
// point between other points
Vector3D a = Vector3D.of(1, 2, 3);
Vector3D b = Vector3D.of(4, 5, 6);

Vector3D midPoint = a.lerp(b, 0.5);

// split the vector into two parts; in this case, we'll just do a simple 1/4, 
3/4 split
Vector3D oneQuarter = a.multiply(0.25);
Vector3D threeQuarters = a.multiply(0.75);
{code}

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IMAGING-358) "RationalNumber" class is "public"

2023-07-16 Thread Gary Lucas (Jira)



[ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743590#comment-17743590
 ] 

Gary Lucas commented on IMAGING-358:


It's been two years since I looked at this (Imaging-285), but as I recall the 
differences between the implementations in Commons Imaging and Commons Numbers 
were related to the way the two classes treated 32-bit unsigned integers 
(which, of course, don't exist in Java). So if we were going to consider adding 
a dependency on Commons Numbers, we would have to look at the problem very 
carefully.  While I believe that I saw potential problems back when I looked at 
Imaging-309, I do not recall what they were.  So I could be wrong. The idea 
might work.  Of course, it might work only if we added special-case 
modifications to Commons Numbers. If that were the case, then I don't think it 
would be appropriate to modify the more general purpose library (Numbers) to 
suit a special-case requirement for the more narrow application (Imaging).

Now, in answer to the question "where is the bloat?", I think the question is a 
bit disingenuous.  Commons Imaging started with no external dependencies except 
the Java standard API.  If we were to add a dependency to another library, and 
then that library added dependencies of its own, we would have bloat.  You may 
disagree with my reluctance to add more external dependencies. You may even be 
right. But do not pretend that doing so does not carry a cost.

> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
>  Issue Type: Wish
>  Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
>  Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class 
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
>  is tuned to the requirements of the TIFF format while its name purports that 
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting 
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction" 
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
>  as proposed in IMAGING-309) would avoid the issue, and also consolidate 
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be 
> moved to [Imaging]'s [{{internal}} 
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743585#comment-17743585
 ] 

Dimitrios Efthymiou edited comment on GEOMETRY-154 at 7/16/23 11:38 PM:


[~erans] Should I send it to dev@community or dev@commons?


was (Author: JIRAUSER301169):
[~erans] doing it now. Should I send it to dev or commons?

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743585#comment-17743585
 ] 

Dimitrios Efthymiou commented on GEOMETRY-154:
--

[~erans] doing it now. Should I send it to dev or commons?

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743582#comment-17743582
 ] 

Gilles Sadowski commented on GEOMETRY-154:
--

bq. One thing i would love to do is [...]

Please post to the ML.


> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743577#comment-17743577
 ] 

Dimitrios Efthymiou edited comment on GEOMETRY-154 at 7/16/23 11:01 PM:


[~mattjuntunen] for example, in graphics, you might want to place an object 
exactly two-thirds of the way between two points. Or in machine learning, 
dividing a vector that represents this dataset based on a ratio (such as 80:20 
or 70:30). Or in GIS.

One thing i would love to do is to go through the apache projects, see which 
ones already depend on the math library, and see if they implement some math 
stuff that could be replaced by a call to commons math or move that function to 
the math library. Would such cases be considered valid for implementing new 
math algorithms inside the math libraries? I don't think i have seen any ticket 
that wants to implement new math algorithms


was (Author: JIRAUSER301169):
[~mattjuntunen] for example, in graphics, you might want to place an object 
exactly two-thirds of the way between two points. Or in machine learning, 
dividing a vector that represents this dataset based on a ratio (such as 80:20 
or 70:30). Or in GIS.

One thing i would love to do is to go through the apache projects, see which 
ones already depend on the math library, and see if they implement some math 
stuff that could be replaced by a call to commons math or move that function to 
the math library. Would such cases be considered valid for implementing new 
math algorithms inside the math libraries?

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743577#comment-17743577
 ] 

Dimitrios Efthymiou edited comment on GEOMETRY-154 at 7/16/23 11:00 PM:


[~mattjuntunen] for example, in graphics, you might want to place an object 
exactly two-thirds of the way between two points. Or in machine learning, 
dividing a vector that represents this dataset based on a ratio (such as 80:20 
or 70:30). Or in GIS.

One thing i would love to do is to go through the apache projects, see which 
ones already depend on the math library, and see if they implement some math 
stuff that could be replaced by a call to commons math or move that function to 
the math library. Would such cases be considered valid for implementing new 
math algorithms inside the math libraries?


was (Author: JIRAUSER301169):
[~mattjuntunen] for example, in graphics, you might want to place an object 
exactly two-thirds of the way between two points. Or in machine learning, 
dividing a vector that represents this dataset based on a ratio (such as 80:20 
or 70:30). Or in GIS.

One thing i would love to do is to go through the apache projects, see which 
ones already depend on the math library, and see if they implement some math 
stuff that could be replaced by a call to commons math or move that function to 
the math library

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743577#comment-17743577
 ] 

Dimitrios Efthymiou edited comment on GEOMETRY-154 at 7/16/23 10:59 PM:


[~mattjuntunen] for example, in graphics, you might want to place an object 
exactly two-thirds of the way between two points. Or in machine learning, 
dividing a vector that represents this dataset based on a ratio (such as 80:20 
or 70:30). Or in GIS.

One thing i would love to do is to go through the apache projects, see which 
ones already depend on the math library, and see if they implement some math 
stuff that could be replaced by a call to commons math or move that function to 
the math library


was (Author: JIRAUSER301169):
[~mattjuntunen] for example, in graphics, you might want to place an object 
exactly two-thirds of the way between two points. Or in machine learning, 
dividing a vector that represents this dataset based on a ratio (such as 80:20 
or 70:30). Or in GIS.

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743577#comment-17743577
 ] 

Dimitrios Efthymiou commented on GEOMETRY-154:
--

[~mattjuntunen] for example, in graphics, you might want to place an object 
exactly two-thirds of the way between two points. Or in machine learning, 
dividing a vector that represents this dataset based on a ratio (such as 80:20 
or 70:30). Or in GIS.

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743573#comment-17743573
 ] 

Matt Juntunen commented on GEOMETRY-154:


What would be a use case for this method? I'm not seeing one right off the bat.

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IMAGING-358) "RationalNumber" class is "public"

2023-07-16 Thread Gary D. Gregory (Jira)



[ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743568#comment-17743568
 ] 

Gary D. Gregory commented on IMAGING-358:
-

" of Imaging-309, it turned out that the rational number format used by TIFF"
[~gwlucas] How about calling the class TiffRationalNumber and updating the 
Javadoc if needed?

> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
>  Issue Type: Wish
>  Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
>  Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class 
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
>  is tuned to the requirements of the TIFF format while its name purports that 
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting 
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction" 
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
>  as proposed in IMAGING-309) would avoid the issue, and also consolidate 
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be 
> moved to [Imaging]'s [{{internal}} 
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IMAGING-358) "RationalNumber" class is "public"



[ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743564#comment-17743564
 ] 

Gilles Sadowski commented on IMAGING-358:
-

bq. [...] the rational number format used by TIFF just wasn't a perfect fit 
with that used in the math library.  Some of the rules were a little different.

That sounds a bit strange.  Is it a fraction, or not?  Is there something wrong 
in how the class in [Numbers] implements a fraction?

bq. the rules were defined as part of the TIFF format specification, [...]

Which rules?  Certainly not those that define what a fraction is.
Perhaps a specialized behaviour on top of a (plain) fraction is required in 
order to support the TIFF format, then why not focus on that, instead of taking 
advantage of the work done in [Math] and then in [Numbers] (where bugs were 
fixed and performance improved)?

bq. Adding unnecessary libraries adds bloat.

TIFF needs fraction, "commons-numbers-fraction" provides a JAR that only 
contains classes about fractions. Where is the bloat?


> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
>  Issue Type: Wish
>  Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
>  Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class 
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
>  is tuned to the requirements of the TIFF format while its name purports that 
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting 
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction" 
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
>  as proposed in IMAGING-309) would avoid the issue, and also consolidate 
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be 
> moved to [Imaging]'s [{{internal}} 
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (IMAGING-358) "RationalNumber" class is "public"

2023-07-16 Thread Gary Lucas (Jira)



[ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743563#comment-17743563
 ] 

Gary Lucas edited comment on IMAGING-358 at 7/16/23 8:11 PM:
-

Well, there always a trade off with this kind of thing.  In general, I really 
dislike the idea of adding new dependencies to Commons Imaging (or any other 
software package).  As a software developer, it makes my life more complicated 
when the library I want to use requires that I also include others I don't 
need.  However, if there is a module that is truly common, then it doesn't make 
sense to implement it different ways.  Adding unnecessary libraries adds bloat. 
 But implementing redundant classes also adds bloat.  Is there a Nash balance 
somewhere in this game? Finding it might be a challenge.

 

In the case of Imaging-309, it turned out that the rational number format used 
by TIFF just wasn't a perfect fit with that used in the math library.  Some of 
the rules were a little different.  And since the rules were defined as part of 
the TIFF format specification, it wasn't like we could change them.  And 
modifying the math libary's NumberFormat class struck me as a bit risky because 
we would be saddling a generic implementation with some ad hoc requirements to 
support a single edge case (the TIFF format).

 

Finally,  I'm not sure about the scoping.  As I recall, RationalNumber was used 
in multiple packages.  I will look at the code later.


was (Author: gwlucas):
Well, there always a trade off with this kind of thing.  In general, I really 
dislike the idea of adding new dependencies to Commons Imaging (or any other 
software package).  As a software developer, it makes my life more complicated 
when the library I want to use requires that I also include others I don't 
need.  However, if there is a module that is truly common, then it doesn't make 
sense to implement it different ways.  Adding unnecessary libraries adds bloat. 
 But implementing redundant classes also adds bloat.  Is there a Nash balance 
somewhere in this game? Finding it might be a challenge.

 

In the case of Imaging-309, it turned out that the rational number format used 
by TIFF just wasn't a perfect fit with that used in the math library.  Some of 
the rules were a little different.  And since the rules were defined as part of 
the TIFF format specification, it wasn't like we could change them.  I'm not 
sure about the scoping.  As I recall, RationalNumber was used in multiple 
packages.  I will look at the code later.

> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
>  Issue Type: Wish
>  Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
>  Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class 
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
>  is tuned to the requirements of the TIFF format while its name purports that 
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting 
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction" 
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
>  as proposed in IMAGING-309) would avoid the issue, and also consolidate 
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be 
> moved to [Imaging]'s [{{internal}} 
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IMAGING-358) "RationalNumber" class is "public"

2023-07-16 Thread Gary Lucas (Jira)



[ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743563#comment-17743563
 ] 

Gary Lucas commented on IMAGING-358:


Well, there always a trade off with this kind of thing.  In general, I really 
dislike the idea of adding new dependencies to Commons Imaging (or any other 
software package).  As a software developer, it makes my life more complicated 
when the library I want to use requires that I also include others I don't 
need.  However, if there is a module that is truly common, then it doesn't make 
sense to implement it different ways.  Adding unnecessary libraries adds bloat. 
 But implementing redundant classes also adds bloat.  Is there a Nash balance 
somewhere in this game? Finding it might be a challenge.

 

In the case of Imaging-309, it turned out that the rational number format used 
by TIFF just wasn't a perfect fit with that used in the math library.  Some of 
the rules were a little different.  And since the rules were defined as part of 
the TIFF format specification, it wasn't like we could change them.  I'm not 
sure about the scoping.  As I recall, RationalNumber was used in multiple 
packages.  I will look at the code later.

> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
>  Issue Type: Wish
>  Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
>  Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class 
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
>  is tuned to the requirements of the TIFF format while its name purports that 
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting 
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction" 
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
>  as proposed in IMAGING-309) would avoid the issue, and also consolidate 
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be 
> moved to [Imaging]'s [{{internal}} 
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-lang] garydgregory commented on a diff in pull request #786: Lang-1657: Diff Result Type Constraint



garydgregory commented on code in PR #786:
URL: https://github.com/apache/commons-lang/pull/786#discussion_r1264740474


##
src/test/java/org/apache/commons/lang3/builder/DiffBuilderTest.java:
##
@@ -495,4 +519,16 @@ public void testTriviallyEqualTestEnabled() {
 assertThat(explicitTestAndEqual.build().getNumberOfDiffs(), 
equalToZero);
 }
 
+@Test
+public void testNestedDiffable() {

Review Comment:
   This test needs to be different: It compiles just fine AND without warnings 
without the change to `main`. What am I missing?



-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (COLLECTIONS-844) Counting Bloom filter expects counts (cells) to be ints

2023-07-16 Thread Claude Warren (Jira)



 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claude Warren updated COLLECTIONS-844:
--
Summary: Counting Bloom filter expects counts (cells) to be ints  (was: 
Counting Bloomfilter tests expect counts to be ints)

> Counting Bloom filter expects counts (cells) to be ints
> ---
>
> Key: COLLECTIONS-844
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-844
> Project: Commons Collections
>  Issue Type: Improvement
>Affects Versions: 4.5
>Reporter: Claude Warren
>Priority: Minor
>
> The AbstractCountingBloomFilterTest assumes that the Bloom filter is using an 
> int to track the counts.  Any implementation using a smaller storage size 
> will not be able to pass the test.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-lang] garydgregory commented on pull request #786: Lang-1657: Diff Result Type Constraint



garydgregory commented on PR #786:
URL: https://github.com/apache/commons-lang/pull/786#issuecomment-1637177513

   @greatmastermario 
   Hm, I'm having trouble apply the patch locally on master with `git apply`. 
Would you rebase on master please?


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] greatmastermario commented on pull request #786: Lang-1657: Diff Result Type Constraint



greatmastermario commented on PR #786:
URL: https://github.com/apache/commons-lang/pull/786#issuecomment-1637176458

   Since it has been a bit since I opened this PR, let me know if any edits
   are required.
   
   On Sun, Jul 16, 2023, 12:39 PM Gary Gregory ***@***.***>
   wrote:
   
   > Looking...
   >
   > —
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   > You are receiving this because you were mentioned.Message ID:
   > ***@***.***>
   >
   


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] garydgregory commented on pull request #786: Lang-1657: Diff Result Type Constraint



garydgregory commented on PR #786:
URL: https://github.com/apache/commons-lang/pull/786#issuecomment-1637173471

   Looking...


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] Osdel commented on pull request #786: Lang-1657: Diff Result Type Constraint



Osdel commented on PR #786:
URL: https://github.com/apache/commons-lang/pull/786#issuecomment-1637170747

   What happened to this pull request? This change is really needed. Having the 
`DiffBuilder.append()` constraint on passing a `DiffResult` is not ideal. 
Ideally you want to recursively call on nested attributes that implement the 
`Diffable` interface. I am not getting build errors but a lot of `Uncheck` 
warnings  which are unpleasant. 


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory closed pull request #27: Bump junit from 4.13 to 4.13.1 in /core



garydgregory closed pull request #27: Bump junit from 4.13 to 4.13.1 in /core
URL: https://github.com/apache/commons-digester/pull/27


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory commented on pull request #27: Bump junit from 4.13 to 4.13.1 in /core



garydgregory commented on PR #27:
URL: https://github.com/apache/commons-digester/pull/27#issuecomment-1637168427

   Done elsewhere. 


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-statistics] kinow commented on a diff in pull request #49: [STATISTICS-76]: Max Implementation



kinow commented on code in PR #49:
URL: https://github.com/apache/commons-statistics/pull/49#discussion_r1264731414


##
commons-statistics-descriptive/src/test/java/org/apache/commons/statistics/descriptive/MaxTest.java:
##
@@ -0,0 +1,187 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.statistics.descriptive;
+
+import java.util.Arrays;
+import java.util.function.DoubleSupplier;
+import java.util.stream.Stream;
+import org.apache.commons.rng.UniformRandomProvider;
+import org.junit.jupiter.api.Assertions;
+import org.junit.jupiter.api.Test;
+import org.junit.jupiter.params.ParameterizedTest;
+import org.junit.jupiter.params.provider.Arguments;
+import org.junit.jupiter.params.provider.MethodSource;
+
+/**
+ * Test for {@link Max}.
+ */
+final class MaxTest {
+
+@Test
+void testEmpty() {
+Max max = Max.create();
+Assertions.assertEquals(Double.NEGATIVE_INFINITY, max.getAsDouble());
+}
+
+@Test
+void testIncrement() {
+// Test the max after each incremental update
+// First parameter of testArray is the value that would be added
+// Second parameter of testArray is the max we expect after adding the 
value
+double[][] testArray = {
+{1729.22, 1729.22},
+{2520.35, 2520.35},
+{2010.87, 2520.35},
+{1.1, 1.1},
+{+0.0, 1.1},
+{-0.0, 1.1},
+{Double.MAX_VALUE, Double.MAX_VALUE},
+{Double.POSITIVE_INFINITY, Double.POSITIVE_INFINITY},
+{Double.NEGATIVE_INFINITY, Double.POSITIVE_INFINITY}
+};
+
+Max stat = Max.create();
+for (final double[] valueAndExpected: testArray) {
+final double value = valueAndExpected[0];
+final double expected = valueAndExpected[1];
+stat.accept(value);
+Assertions.assertEquals(expected, stat.getAsDouble());
+}
+}
+
+@Test
+void testNaN() {
+// Test non-nan values cannot revert a NaN
+double[] testArray = {Double.NaN, +0.0d, -0.0d, 
Double.POSITIVE_INFINITY, Double.NEGATIVE_INFINITY};
+Max stat = Max.create();
+for (final double x : testArray) {
+stat.accept(x);
+Assertions.assertEquals(Double.NaN, stat.getAsDouble());
+}
+}
+
+@ParameterizedTest
+@MethodSource
+void testMax(double[] values, double expected) {
+Max stat = Max.create();
+Arrays.stream(values).forEach(stat);
+double actual = stat.getAsDouble();
+Assertions.assertEquals(expected, actual, "max");
+Assertions.assertEquals(expected, Max.of(values).getAsDouble(), "max");
+}
+
+static Stream testMax() {
+return Stream.of(
+Arguments.of(new double[] {}, Double.NEGATIVE_INFINITY),
+Arguments.of(new double[] {3.14}, 3.14),
+Arguments.of(new double[] {12.34, 56.78, -2.0}, 56.78),
+Arguments.of(new double[] {Double.NaN, 3.14, Double.NaN, 
Double.NaN}, Double.NaN),
+Arguments.of(new double[] {-1d, 1d, Double.NaN}, Double.NaN),
+Arguments.of(new double[] {Double.NaN, Double.NaN, Double.NaN}, 
Double.NaN),
+Arguments.of(new double[] {0.0d, Double.NaN, +0.0d, -0.0d, 
Double.POSITIVE_INFINITY, Double.NEGATIVE_INFINITY}, Double.NaN),
+Arguments.of(new double[] {+0.0d, -0.0d, 1.0, 3.14}, 3.14),
+Arguments.of(new double[] {-0.0, +0.0}, 0.0),
+Arguments.of(new double[] {0.0, -0.0}, 0.0),
+Arguments.of(new double[] {0.0, +0.0}, 0.0),
+Arguments.of(new double[] {1.2, -34.56, 456.789, -5678.9012}, 
456.789),
+Arguments.of(new double[] {-23467824, 23648, 2368, 23749, -23424, 
-23492, -92397747}, 23749),
+Arguments.of(new double[] {0.0d, +0.0d, -0.0d, 
Double.POSITIVE_INFINITY, Double.MIN_VALUE}, Double.POSITIVE_INFINITY),
+Arguments.of(new double[] {0.0d, +0.0d, -0.0d, 
Double.POSITIVE_INFINITY, -Double.MIN_VALUE}, Double.POSITIVE_INFINITY),
+Arguments.of(new double[] {0.0d, +0.0d, -0.0d, 
Double.POSITIVE_INFINITY,

[jira] [Commented] (POOL-410) EHN Max Concurrent Connections in Stats

2023-07-16 Thread Phil Steitz (Jira)



[ 
https://issues.apache.org/jira/browse/POOL-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743558#comment-17743558
 ] 

Phil Steitz commented on POOL-410:
--

Moving a comment from PR to here.  I think I now understand at least the stats 
/ reporting ask here.  We currently provide stats caching and reporting for 
timing metrics.  I think it is reasonable to ask for that for active and idle 
counts.  I would be happy to review a PR to add activeCounts and idleCounts to 
go along with activeTimes and the other latency StatsStore instances now in 
BaseGenericObjectPool. I would approach that by creating activeCounts and 
idleCounts as StatsStore instances in BGOP and updating them in 
updateStatsOnReturn and updateStatsOnBorrow, using current active and idle 
counts from the pool.  Then include these stats in reports. And tests.  It is 
maybe a slippery slope to add more and more stats caching and It might actually 
be better to move in 3.0 to stats logging or listeners, but I think idle/active 
counts are important enough to be added to what is currently being cached.   
Another thing that is missing is control over the cache window / resetting the 
caches.  For the OPs use case, some way to set the cache size or time to live 
would be needed.  As of 2.11 it is hard-coded to the 100 most recent 
measurements.  Adding cache size confguration and a method to clear the cache 
would be helpful here.

> EHN Max Concurrent Connections in Stats
> ---
>
> Key: POOL-410
> URL: https://issues.apache.org/jira/browse/POOL-410
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Thomas Freller
>Priority: Major
>
> For tuning the Database the max concurrent used connections wold be relay 
> great.
>  
> So I could monitor the max concurrent connections of my pool and could see if 
> I have to size up/down the max database connections (that can me memory 
> intensive) or if I could downsize the Pool and also the Database i could save 
> Memory and costs.  At the Moment the only Indicator is 
> maxBorrowWaitDuration=PT3.016S,
>  
> But this can only tell me hat at the Moment the pool reached its max (because 
> I set maxTotal to 1) my normal Case is to have up to 20 Pools of different 
> Applications that connect to one instance of MariaDB and the output of 
> maxBorrowWaitDuration is 0. So I only know I would be able to downsize the 
> pool but I have no hint how to size the pool best.
> This Statistical Data should be also printed in the toString() Method.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-collections] aherbert commented on pull request #406: COLLECTIONS-844 - allow counting Bloom filters with cell size other than Integer.SIZE



aherbert commented on PR #406:
URL: 
https://github.com/apache/commons-collections/pull/406#issuecomment-1637156007

   Some extra checkstyle files were added. I hope to have time to review in the 
next few days.


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-collections] Claudenw opened a new pull request, #406: COLLECTIONS-844 added maxValue() to CountingBloomFilter



Claudenw opened a new pull request, #406:
URL: https://github.com/apache/commons-collections/pull/406

   Counting bloom filter tests are dependant upon the maximum value that can be 
stored in a cell in a Bloom filter.
   
   This patch adds a `maxValue()` method to the CountingBloomFilter interface.  
This is to indicate the maximum value that can be stored in a single cell of 
the counting filter.  A cell is the counter that replaces the bit in the 
counting filter.
   
   Changes to tests


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-statistics] ani5rudh opened a new pull request, #49: [STATISTICS-76]: Max Implementation



ani5rudh opened a new pull request, #49:
URL: https://github.com/apache/commons-statistics/pull/49

   (no comment)


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (COLLECTIONS-844) Counting Bloomfilter tests expect counts to be ints

2023-07-16 Thread Claude Warren (Jira)

Claude Warren created COLLECTIONS-844:
-

 Summary: Counting Bloomfilter tests expect counts to be ints
 Key: COLLECTIONS-844
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-844
 Project: Commons Collections
  Issue Type: Improvement
Affects Versions: 4.5
Reporter: Claude Warren


The AbstractCountingBloomFilterTest assumes that the Bloom filter is using an 
int to track the counts.  Any implementation using a smaller storage size will 
not be able to pass the test.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-digester] garydgregory commented on pull request #4: refine travis-ci scripts



garydgregory commented on PR #4:
URL: https://github.com/apache/commons-digester/pull/4#issuecomment-1637133010

   Closing:  we no longer use Travis CI.


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory closed pull request #4: refine travis-ci scripts



garydgregory closed pull request #4: refine travis-ci scripts
URL: https://github.com/apache/commons-digester/pull/4


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory commented on pull request #46: JUnit5 assertThrows IncludeTest



garydgregory commented on PR #46:
URL: https://github.com/apache/commons-digester/pull/46#issuecomment-1637132832

   Hi @nhojpatrick 
   I've fixed and modernized the build and it is now green. Would you please 
rebase your PRs?


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory merged pull request #81: [StepSecurity] ci: Harden GitHub Actions



garydgregory merged PR #81:
URL: https://github.com/apache/commons-digester/pull/81


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] step-security-bot opened a new pull request, #81: [StepSecurity] ci: Harden GitHub Actions

step-security-bot opened a new pull request, #81:
URL: https://github.com/apache/commons-digester/pull/81

## Summary

This pull request is created by [Secure
Repo](https://app.stepsecurity.io/securerepo) at the request of @garydgregory.
Please merge the Pull Request to incorporate the requested changes. Please tag
@garydgregory on your message if you have any questions related to the PR. You
can also engage with the [StepSecurity](https://github.com/step-security) team
by tagging @step-security-bot.

## Security Fixes

### Pinned Dependencies

GitHub Action tags and Docker tags are mutatble. This poses a security risk.
GitHub's Security Hardening guide recommends pinning actions to full length
commit.

- [GitHub Security
Guide](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)
- [The Open Source Security Foundation (OpenSSF) Security
Guide](https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies)

## Feedback
For bug reports, feature requests, and general feedback; please create an
issue in
[step-security/secure-repo](https://github.com/step-security/secure-repo). To
create such PRs, please visit https://app.stepsecurity.io/securerepo.

Signed-off-by: StepSecurity Bot

--
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory merged pull request #32: Bump exec-maven-plugin from 1.1 to 3.1.0



garydgregory merged PR #32:
URL: https://github.com/apache/commons-digester/pull/32


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory merged pull request #78: Bump junit from 4.13.1 to 4.13.2



garydgregory merged PR #78:
URL: https://github.com/apache/commons-digester/pull/78


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory merged pull request #79: Bump jarjar-maven-plugin from 1.5 to 1.9



garydgregory merged PR #79:
URL: https://github.com/apache/commons-digester/pull/79


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory merged pull request #80: Bump findbugs-maven-plugin from 2.3.2 to 3.0.5



garydgregory merged PR #80:
URL: https://github.com/apache/commons-digester/pull/80


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory commented on pull request #32: Bump exec-maven-plugin from 1.1 to 3.1.0



garydgregory commented on PR #32:
URL: https://github.com/apache/commons-digester/pull/32#issuecomment-1637120479

   @dependabot rebase


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory merged pull request #9: Bump cglib from 3.2.5 to 3.3.0



garydgregory merged PR #9:
URL: https://github.com/apache/commons-digester/pull/9


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory closed pull request #64: Bump maven-javadoc-plugin from 2.8 to 3.5.0



garydgregory closed pull request #64: Bump maven-javadoc-plugin from 2.8 to 
3.5.0
URL: https://github.com/apache/commons-digester/pull/64


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory merged pull request #63: Bump actions/upload-artifact from 3.1.0 to 3.1.2



garydgregory merged PR #63:
URL: https://github.com/apache/commons-digester/pull/63


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory merged pull request #68: Bump actions/cache from 3.0.8 to 3.3.1



garydgregory merged PR #68:
URL: https://github.com/apache/commons-digester/pull/68


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory merged pull request #69: Bump actions/setup-java from 3.5.1 to 3.11.0



garydgregory merged PR #69:
URL: https://github.com/apache/commons-digester/pull/69


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory commented on pull request #69: Bump actions/setup-java from 3.5.1 to 3.11.0



garydgregory commented on PR #69:
URL: https://github.com/apache/commons-digester/pull/69#issuecomment-1637117074

   @dependabot rebase


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory merged pull request #75: Bump actions/checkout from 3.0.2 to 3.5.3



garydgregory merged PR #75:
URL: https://github.com/apache/commons-digester/pull/75


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory merged pull request #77: Bump junit from 4.13 to 4.13.1 in /commons-digester3-core



garydgregory merged PR #77:
URL: https://github.com/apache/commons-digester/pull/77


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-digester] garydgregory commented on pull request #72: Bump maven-scm-publish-plugin from 1.0-beta-2 to 3.2.1



garydgregory commented on PR #72:
URL: https://github.com/apache/commons-digester/pull/72#issuecomment-1637116567

   @dependabot rebase


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (IMAGING-358) "RationalNumber" class is "public"

2023-07-16 Thread Gary D. Gregory (Jira)



[ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743539#comment-17743539
 ] 

Gary D. Gregory commented on IMAGING-358:
-

IMO and in general, I would move all of Imaging's "common" package to its 
"internal" package, at least for now (upcoming 1.0.0-M1"). Then we can see if 
some of these internals really should be (more) public in some way. 

> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
>  Issue Type: Wish
>  Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
>  Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class 
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
>  is tuned to the requirements of the TIFF format while its name purports that 
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting 
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction" 
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
>  as proposed in IMAGING-309) would avoid the issue, and also consolidate 
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be 
> moved to [Imaging]'s [{{internal}} 
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-exec] garydgregory merged pull request #112: EXEC-105: fix documentation



garydgregory merged PR #112:
URL: https://github.com/apache/commons-exec/pull/112


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Comment Edited] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743530#comment-17743530
 ] 

Dimitrios Efthymiou edited comment on GEOMETRY-154 at 7/16/23 1:57 PM:
---

[~erans] In a sense yes. the way I expressed it in the description was "take a 
vector AB and divide it into 2, based on a ratio. This video instead of saying 
it this way, it said take 2 points with position vectors OA and OB and find the 
position vector OP of a point P that divides AB into a ratio bla bla. It is the 
same thing, yes.


was (Author: JIRAUSER301169):
[~erans] In a sense yes. the way I expressed it in the description was "take a 
vector AB and divide it into 2 based on a ratio. This video instead of saying 
it this way, it said take 2 points with position vectors OA and OB and find the 
opsition vector of a point OP that divides AB into a ratio bla bla. It is the 
same thing, yes.

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743536#comment-17743536
 ] 

Gilles Sadowski commented on GEOMETRY-154:
--

IIUC, this says that there are at least 2 ways a user might want to access this 
functionality:  In your example,
* one call would pass the ratio as 1/2
* the other would pass the ratio as 1/3

Not knowing which is more "standard", I'd (a priori) conclude that the API 
should serve both needs while minimizing the risk of confusion.  IMHO, the 
current name of the method does not pass that test.  And also, it's an 
"isolated" method: You should either tell where it fits in the code base, or 
suggest a new class/package (i.e. a place where other similar utilities could 
be used together for some purpose).

Note that I'm not precluding other's opinion on whether it should be included 
at all...
If there are no strong opinions in favour or against, the balance might be 
tilted by your finding a use-case (e.g. an example of use could perhaps be 
added to the 
[tutorial|https://commons.apache.org/proper/commons-geometry/tutorials/teapot.html]
 created by [~mattjuntunen]).

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-exec] garydgregory commented on a diff in pull request #112: EXEC-105: fixed documentation



garydgregory commented on code in PR #112:
URL: https://github.com/apache/commons-exec/pull/112#discussion_r1264685302


##
src/site/apt/tutorial.apt:
##
@@ -169,7 +169,7 @@ executor.execute(cmdLine, resultHandler);
 
 // some time later the result handler callback was invoked so we
 // can safely request the exit value
-int exitValue = resultHandler.waitFor();
+resultHandler.waitFor();

Review Comment:
   In general, don't update changes.xml, if every PR did that, they would all 
create merge problems. Note that "dev" is for Apache IDs and "due-to" is for 
contributor IDs that can be tied so _something_, like a GitHub account.



-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-exec] garydgregory commented on a diff in pull request #112: EXEC-105: fixed documentation



garydgregory commented on code in PR #112:
URL: https://github.com/apache/commons-exec/pull/112#discussion_r1264685302


##
src/site/apt/tutorial.apt:
##
@@ -169,7 +169,7 @@ executor.execute(cmdLine, resultHandler);
 
 // some time later the result handler callback was invoked so we
 // can safely request the exit value
-int exitValue = resultHandler.waitFor();
+resultHandler.waitFor();

Review Comment:
   In general, don't update changes.xml, if every PR did that, they would all 
create merge problems.



-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743530#comment-17743530
 ] 

Dimitrios Efthymiou commented on GEOMETRY-154:
--

[~erans] In a sense yes. the way I expressed it in the description was "take a 
vector AB and divide it into 2 based on a ratio. This video instead of saying 
it this way, it said take 2 points with position vectors OA and OB and find the 
opsition vector of a point OP that divides AB into a ratio bla bla. It is the 
same thing, yes.

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-exec] ecki commented on a diff in pull request #112: EXEC-105: fixed documentation



ecki commented on code in PR #112:
URL: https://github.com/apache/commons-exec/pull/112#discussion_r1264679931


##
src/site/apt/tutorial.apt:
##
@@ -169,7 +169,7 @@ executor.execute(cmdLine, resultHandler);
 
 // some time later the result handler callback was invoked so we
 // can safely request the exit value
-int exitValue = resultHandler.waitFor();
+resultHandler.waitFor();

Review Comment:
   Looks good - maybe in the future we should use snippets or at least have a 
copy in a test class.
   
   you might need to add the changes.xml entry?



-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-text] kinow commented on a diff in pull request #430: TEXT-227: removed unnecessary IF statement



kinow commented on code in PR #430:
URL: https://github.com/apache/commons-text/pull/430#discussion_r1264679028


##
src/main/java/org/apache/commons/text/AlphabetConverter.java:
##
@@ -87,9 +87,6 @@ public final class AlphabetConverter {
  * @see 
"http://www.oracle.com/us/technologies/java/supplementary-142654.html;
  */
 private static String codePointToString(final int i) {
-if (Character.charCount(i) == 1) {

Review Comment:
   Sorry, Gay, I missed the previous message and only saw the notification 
after Alex's comment above.
   
   I don't recall about `charCount`, but Alex's explanation sounds solid. And 
+1 to
   
   >Either variation of this method therefore has possible minor advantages. I 
would be reluctant to change this without a JMH test of performance across the 
LTS JDK releases for the two variations.
   
   At least so we understand pros & cons of this change.
   
   Also, for performance issues text/imaging/pool, I find it easier to accept 
changes like this when users have experienced the performance issues or the JMH 
tests give a clear indication that the change won't bring issues to users with 
different use cases, different JVM's, different garbage collectors, etc. (i.e. 
if the change is being recommended by static analyzers and there are pros & 
cons in JMH test, then I would probably move it to the bottom of the backlog 
for now.)
   
   Cheers
   
   -Bruno



-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (IMAGING-358) "RationalNumber" class is "public"



 [ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles Sadowski updated IMAGING-358:

Summary: "RationalNumber" class is "public"  (was: "RationalNumer" class is 
"public")

> "RationalNumber" class is "public"
> --
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
>  Issue Type: Wish
>  Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: Gilles Sadowski
>Priority: Major
>  Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class 
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
>  is tuned to the requirements of the TIFF format while its name purports that 
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting 
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction" 
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
>  as proposed in IMAGING-309) would avoid the issue, and also consolidate 
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be 
> moved to [Imaging]'s [{{internal}} 
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (IMAGING-358) "RationalNumer" class is "public"

Gilles Sadowski created IMAGING-358:
---

 Summary: "RationalNumer" class is "public"
 Key: IMAGING-358
 URL: https://issues.apache.org/jira/browse/IMAGING-358
 Project: Commons Imaging
  Issue Type: Wish
  Components: imaging.common.*
Affects Versions: 1.0-alpha2
Reporter: Gilles Sadowski
 Fix For: 1.0, 1.0-alpha3


As per its Javadoc, class 
[{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
 is tuned to the requirements of the TIFF format while its name purports that 
it's a general implementation of the "fraction" concept.
Which is it?

Do we want that utility to be part of [Imaging]'s public API (thus eliciting 
support to application developers who might use it beyond its intended scope)?
A dependency on [[Numbers]'s "fraction" 
module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
 as proposed in IMAGING-309) would avoid the issue, and also consolidate 
(and/or help find potential bugs in) [Numbers]'s implementation.

If that proposal is not accepted, {{RationalNumber}} should preferably be moved 
to [Imaging]'s [{{internal}} 
package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-text] aherbert commented on a diff in pull request #430: TEXT-227: removed unnecessary IF statement



aherbert commented on code in PR #430:
URL: https://github.com/apache/commons-text/pull/430#discussion_r1264670367


##
src/main/java/org/apache/commons/text/AlphabetConverter.java:
##
@@ -87,9 +87,6 @@ public final class AlphabetConverter {
  * @see 
"http://www.oracle.com/us/technologies/java/supplementary-142654.html;
  */
 private static String codePointToString(final int i) {
-if (Character.charCount(i) == 1) {

Review Comment:
   Looking at the JDK source for `Character.charCount(int)`, it checks the int 
has no bits set in the upper 16-bits and returns 1 or 2. This check is also 
done in `Character.toChars(int)`. If a single char is found that method will 
immediately return an array with 1 character to use for the String constructor. 
However in recent JDKs the `String.valueOf(char)` constructor has optimisations 
for compact strings by storing LATIN1 charsets using 1 byte per character. 
These look more involved that just using a `char[]` array of size 1.
   
   So the current code could save 1 byte of storage on modern JDK 
implementations. I would guess it would be slower due to additional checks for 
LATIN1 chars but that would have to be verified with a speed test.
   
   Note that the `String.valueOf(char)` method may be internally optimised to 
intern LATIN1 single character strings for reuse. You could cache the ASCII 
alphabet for example. I cannot see this in my JDK source but it would be an 
option for a JDK to implement.
   
   Either variation of this method therefore has possible minor advantages. I 
would be reluctant to change this without a JMH test of performance across the 
LTS JDK releases for the two variations. 



-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)



[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743517#comment-17743517
 ] 

Gilles Sadowski commented on GEOMETRY-154:
--

[~dimitrios.efthymiou],

Is this [tutorial|https://www.youtube.com/watch?v=Sc7UMc-CQjQ] showing a (more 
general) variant of the proposed function?


> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (TEXT-227) Remove unnecessary IF statement in AlphabetConverter



[ 
https://issues.apache.org/jira/browse/TEXT-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743508#comment-17743508
 ] 

Dimitrios Efthymiou commented on TEXT-227:
--

[~aherbert] PR on GitHub https://github.com/apache/commons-text/pull/430

> Remove unnecessary IF statement in AlphabetConverter
> 
>
> Key: TEXT-227
> URL: https://issues.apache.org/jira/browse/TEXT-227
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Removed unnecessary IF statement in AlphabetConverter, because the 
> Character::toChars can handle both single and double-width characters



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (TEXT-227) Remove unnecessary IF statement in AlphabetConverter



 [ 
https://issues.apache.org/jira/browse/TEXT-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dimitrios Efthymiou updated TEXT-227:
-
Description: Removed unnecessary IF statement in AlphabetConverter, because 
the Character::toChars can handle both single and double-width characters  
(was: Removed unnecessary IF statement in AlphabetConverter, because the 
Character.toChars(i) can handle both single and double-width characters)

> Remove unnecessary IF statement in AlphabetConverter
> 
>
> Key: TEXT-227
> URL: https://issues.apache.org/jira/browse/TEXT-227
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Removed unnecessary IF statement in AlphabetConverter, because the 
> Character::toChars can handle both single and double-width characters



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (STATISTICS-76) Implement Max

2023-07-16 Thread Anirudh Joshi (Jira)

Anirudh Joshi created STATISTICS-76:
---

 Summary: Implement Max
 Key: STATISTICS-76
 URL: https://issues.apache.org/jira/browse/STATISTICS-76
 Project: Commons Statistics
  Issue Type: Sub-task
  Components: descriptive
Reporter: Anirudh Joshi


Logic to compute the maximum of all the input values.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (STATISTICS-72) Implement Min

2023-07-16 Thread Alex Herbert (Jira)



 [ 
https://issues.apache.org/jira/browse/STATISTICS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Herbert resolved STATISTICS-72.

Resolution: Implemented

Added in commit:

c9ed0a61e16e8083dc0e4b1f8afa33086d195f40

> Implement Min
> -
>
> Key: STATISTICS-72
> URL: https://issues.apache.org/jira/browse/STATISTICS-72
> Project: Commons Statistics
>  Issue Type: Sub-task
>  Components: descriptive
>Reporter: Anirudh Joshi
>Assignee: Anirudh Joshi
>Priority: Minor
>  Labels: gsoc, gsoc2023
>
> Logic to compute the minimum of all values seen so far.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-statistics] asfgit closed pull request #46: [STATISTICS-71]: Add base interfaces for all statistic implementations.



asfgit closed pull request #46: [STATISTICS-71]: Add base interfaces for all 
statistic implementations.
URL: https://github.com/apache/commons-statistics/pull/46


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (TEXT-227) Remove unnecessary IF statement in AlphabetConverter

2023-07-16 Thread Alex Herbert (Jira)



[ 
https://issues.apache.org/jira/browse/TEXT-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743499#comment-17743499
 ] 

Alex Herbert commented on TEXT-227:
---

Some more context would be useful here. I presume the current code was written 
for a reason (maybe performance). Can you highlight the particular code section?

> Remove unnecessary IF statement in AlphabetConverter
> 
>
> Key: TEXT-227
> URL: https://issues.apache.org/jira/browse/TEXT-227
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Removed unnecessary IF statement in AlphabetConverter, because the 
> Character.toChars(i) can handle both single and double-width characters



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-email] aherbert commented on a diff in pull request #153: EMAIL-205: removed dead code



aherbert commented on code in PR #153:
URL: https://github.com/apache/commons-email/pull/153#discussion_r1264625263


##
src/main/java/org/apache/commons/mail/EmailUtils.java:
##
@@ -295,10 +295,6 @@ static String encodeUrl(final String input) throws 
UnsupportedEncodingException
 for (final byte c : input.getBytes(US_ASCII))
 {
 int b = c;
-if (b < 0)

Review Comment:
   This is not dead code. It converts a signed 8-bit number (byte) to an 
unsigned 8-bit number, stored in an integer. It could be replaced with:
   ```Java
   int b = c & 0xff;
   ```



-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-statistics] aherbert commented on pull request #46: [STATISTICS-71]: Add base interfaces for all statistic implementations.



aherbert commented on PR #46:
URL: 
https://github.com/apache/commons-statistics/pull/46#issuecomment-1637001699

   The `foundation` branch requires more commits to reopen this PR


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-statistics] aherbert closed pull request #48: [STATISTICS-71]: Add base interfaces for all statistic implementations.



aherbert closed pull request #48: [STATISTICS-71]: Add base interfaces for all 
statistic implementations.
URL: https://github.com/apache/commons-statistics/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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-statistics] aherbert commented on pull request #48: [STATISTICS-71]: Add base interfaces for all statistic implementations.



aherbert commented on PR #48:
URL: 
https://github.com/apache/commons-statistics/pull/48#issuecomment-1637001364

   See #46 


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-statistics] kinow commented on pull request #46: [STATISTICS-71]: Add base interfaces for all statistic implementations.