[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362671#comment-17362671
]
Gilles Sadowski commented on NUMBERS-163:
-
bq. performance impact should be checked.
I've adapted {{LinearCombinationPerformance.java}}. E.g.
{code}
@Benchmark
public void twoDStatic(Factors factors, Blackhole bh) {
for (int i = 0; i < factors.getSize(); i++) {
final double[] a = factors.getA(i);
final double[] b = factors.getB(i);
bh.consume(LinearCombination.value(a[0], b[0], a[1], b[1]));
}
}
@Benchmark
public void twoDInstance(Factors factors, Blackhole bh) {
for (int i = 0; i < factors.getSize(); i++) {
final double[] a = factors.getA(i);
final double[] b = factors.getB(i);
bh.consume(LinearCombinationInstance.of(a[0], b[0], a[1],
b[1]).getAsDouble());
}
}
{code}
Benchmark (c) (length) (size) Mode Cnt Score Error Units
StaticVsInstancePerfTest.fourDInstance 1e20 N/A 1000 avgt 5 31512.374 ± 62.728
ns/op
StaticVsInstancePerfTest.fourDStatic 1e20 N/A 1000 avgt 5 31614.226 ± 9.056
ns/op
StaticVsInstancePerfTest.nDInstance 1e20 2 1000 avgt 5 20752.786 ± 133.433
ns/op
StaticVsInstancePerfTest.nDInstance 1e20 3 1000 avgt 5 27923.824 ± 64.643 ns/op
StaticVsInstancePerfTest.nDInstance 1e20 4 1000 avgt 5 35315.521 ± 63.024 ns/op
StaticVsInstancePerfTest.nDInstance 1e20 8 1000 avgt 5 64917.926 ± 7542.116
ns/op
StaticVsInstancePerfTest.nDInstance 1e20 16 1000 avgt 5 119683.016 ± 108.595
ns/op
StaticVsInstancePerfTest.nDInstance 1e20 32 1000 avgt 5 235226.364 ± 82.889
ns/op
StaticVsInstancePerfTest.nDInstance 1e20 64 1000 avgt 5 454769.978 ± 4762.963
ns/op
StaticVsInstancePerfTest.nDStatic 1e20 2 1000 avgt 5 20615.813 ± 55.909 ns/op
StaticVsInstancePerfTest.nDStatic 1e20 3 1000 avgt 5 27732.619 ± 11.160 ns/op
StaticVsInstancePerfTest.nDStatic 1e20 4 1000 avgt 5 35240.831 ± 32.135 ns/op
StaticVsInstancePerfTest.nDStatic 1e20 8 1000 avgt 5 64602.804 ± 7745.583 ns/op
StaticVsInstancePerfTest.nDStatic 1e20 16 1000 avgt 5 119715.009 ± 116.848
ns/op
StaticVsInstancePerfTest.nDStatic 1e20 32 1000 avgt 5 235239.053 ± 1996.640
ns/op
StaticVsInstancePerfTest.nDStatic 1e20 64 1000 avgt 5 453945.774 ± 312.060
ns/op
StaticVsInstancePerfTest.threeDInstance 1e20 N/A 1000 avgt 5 24793.222 ±
30.967 ns/op
StaticVsInstancePerfTest.threeDStatic 1e20 N/A 1000 avgt 5 25110.065 ± 162.728
ns/op
StaticVsInstancePerfTest.twoDInstance 1e20 N/A 1000 avgt 5 18087.386 ± 6.255
ns/op
StaticVsInstancePerfTest.twoDStatic 1e20 N/A 1000 avgt 5 18447.334 ± 15.277
ns/op
bq. There is no need to instantiate an object to perform the computation in the
simple cases.
There is (surprisingly perhaps) no performance loss (on the contrary, for the
simple cases).
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-155) About modules "arrays" and "rootfinder"
[
https://issues.apache.org/jira/browse/NUMBERS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362665#comment-17362665
]
Gilles Sadowski commented on NUMBERS-155:
-
bq. What type of API do you want?
I'm not sure. The use-case is to store a symmetric matrix as a one-dimensional
array; but nothing urgent.
> About modules "arrays" and "rootfinder"
> ---
>
> Key: NUMBERS-155
> URL: https://issues.apache.org/jira/browse/NUMBERS-155
> Project: Commons Numbers
> Issue Type: Task
> Components: arrays, core
>Affects Versions: 1.0-beta1
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: refactoring
> Fix For: 1.0
>
>
> Shouldn't some functionality currently in module {{commons-numbers-arrays}}
> be moved to {{commons-number-core}}?
> Rationale is that the utilities focus on extended precision of some
> computations (on numbers that happen to be stored in an array).
> Wouldn't the Brent solver (in module {{commons-numbers-rootfinder}}) benefit
> from a version based on the new {{ExtendedPrecision}} class?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TEXT-207) Include DoubleFormats utility from commons-geometry
[
https://issues.apache.org/jira/browse/TEXT-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362616#comment-17362616
]
Bruno P. Kinoshita commented on TEXT-207:
-
Thanks for creating the issue [~mattjuntunen] !
> Include DoubleFormats utility from commons-geometry
> ---
>
> Key: TEXT-207
> URL: https://issues.apache.org/jira/browse/TEXT-207
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> commons-geometry currently contains a
> [DoubleFormats|https://github.com/apache/commons-geometry/blob/master/commons-geometry-io-core/src/main/java/org/apache/commons/geometry/io/core/utils/DoubleFormats.java]
> utility class in the {{commons-geometry-io-core}} module that produces
> standardized string representations of doubles for use in text-based data
> formats. It has the following features:
> - It is completely thread-safe.
> - It produces string in scientific, engineering, plain, or mixed (plain or
> scientific depending on value) formats.
> - Performance is comparable to {{DecimalFormat}} and {{BigDecimal}}.
> As mentioned on the dev mailing list, I believe that this class has broader
> applicability than just geometric data formats and would be a good fit for
> commons-text.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-568) AutoCloseInputStream sometimes breaks mark/reset contract
[
https://issues.apache.org/jira/browse/IO-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-568:
---
Fix Version/s: (was: 2.10.0)
2.10.1
> AutoCloseInputStream sometimes breaks mark/reset contract
> -
>
> Key: IO-568
> URL: https://issues.apache.org/jira/browse/IO-568
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Thomas Mortagne
>Priority: Minor
> Fix For: 2.10.1
>
>
> If the the inputstream support mark it should switch back from
> ClosedInputStream to initial InputStream and call reset on it.
> To reproduce:
> {code}
> AutoCloseInputStream stream = new AutoCloseInputStream(new
> ByteArrayInputStream("toto".getBytes()));
> stream.mark("toto".length());
> while (stream.read(new byte[1]) != -1);
> stream.reset();
> {code}
> Among other things it's causing TIKA-2395.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-555) Add a FileSystem enum to provide legal file names
[
https://issues.apache.org/jira/browse/IO-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-555:
---
Fix Version/s: (was: 2.10.0)
2.10.1
> Add a FileSystem enum to provide legal file names
> -
>
> Key: IO-555
> URL: https://issues.apache.org/jira/browse/IO-555
> Project: Commons IO
> Issue Type: Improvement
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.10.1
>
>
> Add {{org.apache.commons.io.FilenameUtils.isIllegalWindowsFileName(char)}}.
> {code:java}
> /**
> * Checks whether the given character is illegal in a Windows file names.
> *
> * The illegal character are:
> *
> *
> * < (less than
> * > (greater than
> * : (colon
> * " (double quote
> * / (forward slash
> * \ (backslash
> * | (vertical bar or pipe
> * ? (question mark
> * * (asterisk
> * ASCII NUL (0)
> * Integer characters 1 through 31
> * There may be other characters that the file name does not allow.
> Please see
> * href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx">Naming
> Files, Paths,
> * and Namespaces
> *
> *
> * @see href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx">Naming
> Files,
> * Paths, and Namespaces
> * @param c
> *the character to check
> * @return whether the give character is legal
> * @since 2.7
> */
> {code}
> I use this method as a building block to create file names based on Strings
> from other sources.
> A further contribution could be: {{String toLegalWindowsFileName(String
> input, char replacementChar)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-726) Add MemoryMappedInputStream
[
https://issues.apache.org/jira/browse/IO-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-726:
---
Fix Version/s: (was: 2.10.0)
2.10.1
> Add MemoryMappedInputStream
> ---
>
> Key: IO-726
> URL: https://issues.apache.org/jira/browse/IO-726
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Affects Versions: 2.8.0
>Reporter: S Hollander
>Priority: Major
> Fix For: 2.10.1
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> A very useful tool for improving performance with disk-based IO is the use of
> memory mapped files. I propose an {{InputStream}} that provides a bridge
> between memory mapped files and the {{InputStream}} ecosystem.
> In my limited performance tests, the use of the MemoryMappedInputStream
> provided a 25% increase in throughput.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-592) Modified FileUtilsDirectoryContainsTestCase File
[ https://issues.apache.org/jira/browse/IO-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-592: --- Fix Version/s: (was: 2.10.0) 2.10.1 > Modified FileUtilsDirectoryContainsTestCase File > > > Key: IO-592 > URL: https://issues.apache.org/jira/browse/IO-592 > Project: Commons IO > Issue Type: Task > Components: Utilities >Reporter: sangwoo son >Priority: Minor > Fix For: 2.10.1 > > Time Spent: 10m > Remaining Estimate: 0h > > * no test code for when directory is null in directoryContains method > * I think the validation phase of the test case that generates the exception > is not correct > send > I'll send pull request > please review > thanks :) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IO-584) Add a module info descriptor
[ https://issues.apache.org/jira/browse/IO-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-584: --- Fix Version/s: (was: 2.10.0) 2.10.1 > Add a module info descriptor > > > Key: IO-584 > URL: https://issues.apache.org/jira/browse/IO-584 > Project: Commons IO > Issue Type: Improvement > Components: Filters, Streams/Writers, Utilities >Affects Versions: 2.6 >Reporter: Jeff Gullett >Priority: Minor > Fix For: 2.10.1 > > > Since commons-io is an automatic module, clients are unable to run jlink > against anything that is dependent upon it. Add a module-info.java file, in > order enable using jlink with commons-io. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IO-678) FileUtils.copyFile does not maintain file permissions
[ https://issues.apache.org/jira/browse/IO-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-678: --- Fix Version/s: (was: 2.10.0) 2.10.1 > FileUtils.copyFile does not maintain file permissions > - > > Key: IO-678 > URL: https://issues.apache.org/jira/browse/IO-678 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.7 >Reporter: Jorge >Priority: Major > Fix For: 2.10.1 > > Attachments: FileUtilsCopyDirectoryToDirectoryTestCase.java > > > I found that permissions (specifically, execute) are not maintained when > using FileUtils.copyFile. The attached test demonstrates the behavior. > > With version 2.6 the following permissions are obtained: > [OTHERS_READ, OWNER_READ, OWNER_WRITE, GROUP_READ, GROUP_WRITE] > > while with version 2.7: > [OWNER_READ, OWNER_WRITE] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362563#comment-17362563
]
Gilles Sadowski commented on NUMBERS-163:
-
{quote}it accumulates them
{quote}
Isn't there a possible loss (depending on the order of accumulation)?
{quote}LinearCombination would be similar.
{quote}
It's indeed what I had understood; hence my point that the additional class is
not strictly necessary (unless the performance cost of creating an instance
that stores two {{double}} values is significant).
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362559#comment-17362559
]
Matt Juntunen commented on NUMBERS-163:
---
{{LinearCombination}} would be similar.
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362558#comment-17362558
]
Matt Juntunen commented on NUMBERS-163:
---
No, it accumulates them. The basic structure should look like below. I have a
specific idea for the API, I just haven't had time yet to write it.
{code:java}
static class Accumulator {
private double sum;
private double comp;
public Accumulator add(double d) {
double t = sum + d;
comp += ExtendedPrecision.twoSumLow();
sum = t;
return this;
}
public double get() {
return summationResult(sum, comp);
}
}
{code}
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362557#comment-17362557
]
Gilles Sadowski commented on NUMBERS-163:
-
Do you actually mean that {{Accumulator}} will store the coordinates (in an
array?) and perform the {{Summation}} in one go when {{get()}} is called?
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362556#comment-17362556
]
Gilles Sadowski commented on NUMBERS-163:
-
{quote}no need to instantiate an object to perform the computation in the
simple cases.
{quote}
Sure; performance impact should be checked.
{quote}I don't see how this addresses my use cases.
{quote}
I showed extended usage of {{LinearCombination}} for which I understood that
intermediate values should be kept (i.e. "p + s" should only be computed when
the "double" result is requested). I didn't look at {{Summation}}.
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TEXT-207) Include DoubleFormats utility from commons-geometry
Matt Juntunen created TEXT-207:
--
Summary: Include DoubleFormats utility from commons-geometry
Key: TEXT-207
URL: https://issues.apache.org/jira/browse/TEXT-207
Project: Commons Text
Issue Type: New Feature
Reporter: Matt Juntunen
commons-geometry currently contains a
[DoubleFormats|https://github.com/apache/commons-geometry/blob/master/commons-geometry-io-core/src/main/java/org/apache/commons/geometry/io/core/utils/DoubleFormats.java]
utility class in the {{commons-geometry-io-core}} module that produces
standardized string representations of doubles for use in text-based data
formats. It has the following features:
- It is completely thread-safe.
- It produces string in scientific, engineering, plain, or mixed (plain or
scientific depending on value) formats.
- Performance is comparable to {{DecimalFormat}} and {{BigDecimal}}.
As mentioned on the dev mailing list, I believe that this class has broader
applicability than just geometric data formats and would be a good fit for
commons-text.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362551#comment-17362551
]
Gilles Sadowski edited comment on NUMBERS-163 at 6/13/21, 2:29 PM:
---
{quote}I don't think the static method should be replaced.
{quote}
What's the problem with writing
{code:java}
double r = LinearCombination.of(a, b, c, d).getAsDouble();
{code}
in place of
{code:java}
double = LinearCombination.value(a, b, c, d);
{code}
?
I'd be more wary about creating a supplementary {{Accumulator}} class in order
to hold the state required to provide Matt's feature, whereas it could be
readily stored within a {{LinearCombination}} instance (IIUC).
was (Author: erans):
bq. I don't think the static method should be replaced.
What's the problem with writing
{code}
double r = LinearCombination.of(a, b, c, d).getAsDouble();
{code}
in place of
{code}
double = LinearCombination.value(a, b, c, d);
{code}
?
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362553#comment-17362553
]
Matt Juntunen commented on NUMBERS-163:
---
I agree that we should keep the static methods. There is no need to instantiate
an object to perform the computation in the simple cases.
Additionally, I don't see how this addresses my use cases. Specifically, I want
to replace the use of {{double}} accumulators
[here|https://github.com/apache/commons-geometry/blob/master/commons-geometry-spherical/src/main/java/org/apache/commons/geometry/spherical/twod/RegionBSPTree2S.java#L173]
(technically a {{Vector3D}} accumulator) with extended precision accumulators.
The result would look something like this:
{code:java}
Summation.Accumulator xacc = Summation.accumulator();
Summation.Accumulator yacc = Summation.accumulator();
Summation.Accumulator zacc = Summation.accumulator();
for (final ConvexArea2S area : areas) {
// ...
xacc.add(centroidVector.getX());
yacc.add(centroidVector.getY());
zacc.add(centroidVector.getZ());
}
Vector3D centroidVectorSum = Vector3D.of(
xacc.get(),
yacc.get(),
zacc.get());
{code}
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362551#comment-17362551
]
Gilles Sadowski commented on NUMBERS-163:
-
bq. I don't think the static method should be replaced.
What's the problem with writing
{code}
double r = LinearCombination.of(a, b, c, d).getAsDouble();
{code}
in place of
{code}
double = LinearCombination.value(a, b, c, d);
{code}
?
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MATH-1576) Reinstate "checkstyle"
[ https://issues.apache.org/jira/browse/MATH-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362546#comment-17362546 ] Gilles Sadowski commented on MATH-1576: --- Ah, OK. Sorry for the noise. :-} > Reinstate "checkstyle" > -- > > Key: MATH-1576 > URL: https://issues.apache.org/jira/browse/MATH-1576 > Project: Commons Math > Issue Type: Sub-task >Reporter: Gilles Sadowski >Priority: Critical > Labels: checkstyle > Fix For: 4.0 > > > Modularization configuration was copied from Commons Numbers that used a > newer Checkstyle with a different syntax. The checks trigger more than 31000 > errors in Commons Math; so all checks have been disabled. :( > The syntax of the configuration that worked before modularization should be > adapted to the new syntax... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362541#comment-17362541
]
Alex Herbert commented on NUMBERS-163:
--
I don't think the static method should be replaced. They can be supplemented by
a builder type pattern. I see use cases for both, and advantages to keeping
both.
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MATH-1576) Reinstate "checkstyle"
[ https://issues.apache.org/jira/browse/MATH-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362540#comment-17362540 ] Alex Herbert commented on MATH-1576: There is also a checkstyle suppressions file that suppresses everything that you put in place 4 weeks ago. So nothing has changed since then. I should have some time to get checkstyle working in the coming weeks. > Reinstate "checkstyle" > -- > > Key: MATH-1576 > URL: https://issues.apache.org/jira/browse/MATH-1576 > Project: Commons Math > Issue Type: Sub-task >Reporter: Gilles Sadowski >Priority: Critical > Labels: checkstyle > Fix For: 4.0 > > > Modularization configuration was copied from Commons Numbers that used a > newer Checkstyle with a different syntax. The checks trigger more than 31000 > errors in Commons Math; so all checks have been disabled. :( > The syntax of the configuration that worked before modularization should be > adapted to the new syntax... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362477#comment-17362477
]
Gilles Sadowski edited comment on NUMBERS-163 at 6/13/21, 1:27 PM:
---
{code:java}
public class LinearCombination implements DoubleSupplier { /* ... */ }
LinearCombination t = LinearCombination.of(a1, y1, b1, z1);
LinearCombination u = LinearCombination.of(t, b2, z2);
double result = u.getAsDouble();
{code}
I have a commit ready for factory methods to replace the static functions, and
the "DoubleSupplier" (with updated unit tests). OK to "git push" to "master"?
was (Author: erans):
{code}
public class LinearCombination implements DoubleSupplier { /* ... */ }
LinearCombination t = LinearCombination.of(a1, y1, b1, z1);
LinearCombination u = LinearCombination.of(t, b2, z2);
double result = u.get();
{code}
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IO-724) FileUtils.deleteDirectory javadoc is inaccurate for nonexistent directory
[
https://issues.apache.org/jira/browse/IO-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362539#comment-17362539
]
Liran Mendelovich commented on IO-724:
--
Opened [PR|https://github.com/apache/commons-io/pull/245]
> FileUtils.deleteDirectory javadoc is inaccurate for nonexistent directory
> -
>
> Key: IO-724
> URL: https://issues.apache.org/jira/browse/IO-724
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Henry Tung
>Priority: Minor
>
> FileUtils.deleteDirectory javadoc claims:
> {code:java}
> @throws IllegalArgumentException if {@code directory} does not exist or is
> not a directory{code}
> but the first two lines of the code are:
> {code:java}
> Objects.requireNonNull(directory, "directory");
> if (!directory.exists()) {
> return;
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MATH-1576) Reinstate "checkstyle"
[
https://issues.apache.org/jira/browse/MATH-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362534#comment-17362534
]
Gilles Sadowski commented on MATH-1576:
---
{quote}I did not forget.
{quote}
There is a CheckStyle config in place; it reports no error, so I thought that
it was all done. The "ping" was for setting the report to "resolved".
> Reinstate "checkstyle"
> --
>
> Key: MATH-1576
> URL: https://issues.apache.org/jira/browse/MATH-1576
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Priority: Critical
> Labels: checkstyle
> Fix For: 4.0
>
>
> Modularization configuration was copied from Commons Numbers that used a
> newer Checkstyle with a different syntax. The checks trigger more than 31000
> errors in Commons Math; so all checks have been disabled. :(
> The syntax of the configuration that worked before modularization should be
> adapted to the new syntax...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362477#comment-17362477
]
Gilles Sadowski commented on NUMBERS-163:
-
{code}
public class LinearCombination implements DoubleSupplier { /* ... */ }
LinearCombination t = LinearCombination.of(a1, y1, b1, z1);
LinearCombination u = LinearCombination.of(t, b2, z2);
double result = u.get();
{code}
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
