[jira] [Comment Edited] (JEXL-252) Allow for interpolated strings to be used in property access operators

2018-01-27 Thread Henri Biestro (JIRA)

[ 
https://issues.apache.org/jira/browse/JEXL-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342246#comment-16342246
 ] 

Henri Biestro edited comment on JEXL-252 at 1/28/18 7:08 AM:
-

The idea behind {code:java}x.'y z'{code} syntax is to allow using constant 
property names that contain spaces/special characters. The constant part is 
important here; we have a syntax when a property is dynamic, the 
{code:java}x[y]{code} notation.
The different access operators overloads allow managing the difference between 
{code:java}map.length{code} and {code:java}map['length']{code}.
What you propose is currently addressed using {code:java}x[`y`]{code}.


was (Author: henrib):
The idea behind {code:java}x.'y z'{code} syntax is to allow using constant 
property names that contain spaces/special characters. The constant part is 
important here; we have a syntax when a property is dynamic, the 
{code:java}x.[y]{code} notation.
The different access operators overloads allow managing the difference between 
{code:java}map.length{code} and {code:java}map['length']{code}.
What you propose is currently solved using {code:java}x.[`y`]{code}.

> Allow for interpolated strings to be used in property access operators
> --
>
> Key: JEXL-252
> URL: https://issues.apache.org/jira/browse/JEXL-252
> Project: Commons JEXL
>  Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> Now we have a possibility to access an object property by specifying either 
> {code}object.property{code} or {code}object."property"{code} expression, but 
> not {code}object.`property`{code} expression. Since interpolated strings can 
> be used anywhere in scripts as ordinal strings, it would be logical to allow 
> them to be used in property access operators too. It would allow to have the 
> property name not necessarily to be a constant, but to be evaluated without 
> using the array access operator, since property access operator and array 
> access operator could be implemented (overloaded) differently for the object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (JEXL-253) Permissions by super type in JexlSandbox

2018-01-27 Thread Henri Biestro (JIRA)

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

Henri Biestro updated JEXL-253:
---
Assignee: Henri Biestro

> Permissions by super type in JexlSandbox
> 
>
> Key: JEXL-253
> URL: https://issues.apache.org/jira/browse/JEXL-253
> Project: Commons JEXL
>  Issue Type: New Feature
>Reporter: Woonsan Ko
>Assignee: Henri Biestro
>Priority: Major
>
> At the moment, the permissions in {{JexlSandbox}} takes the object's class 
> name only into the consideration. So, if someone adds {{java.util.Set}} into 
> the white list, but if the real object is an empty set 
> ({{Collections.emptySet()}}), then it cannot allow invocations on 
> {{#contains(Object)}} operation, for instance.
> I think it would be very convenient if it optionally allows to set whites or 
> blacks based on super type (interfaces or base classes).
> To minimize the effort, I'd suggest adding 
> {{JexlSandbox#permissionsByType(Class type, ...)}}, where the {{type}} 
> means the object type or any super types.
> So, if {{JexlSandbox#permissionsByType(java.util.Set.class, ...)}}, then any 
> invocations on any concrete {{java.util.Set}} objects will be affected by 
> that.
> Related e-mail thread: "[JEXL] white list classes, not by interfaces?" 
> (10/19/17).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

2018-01-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342359#comment-16342359
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user ottobackwards commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/311#discussion_r164283889
  
--- Diff: src/main/java/org/apache/commons/lang3/time/TimingRecordNode.java 
---
@@ -0,0 +1,222 @@
+/*
+ * 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.lang3.time;
+
+import java.util.LinkedList;
+import java.util.List;
+import org.apache.commons.lang3.ArrayUtils;
+import org.apache.commons.lang3.StringUtils;
+
+/**
+ * The tree node to track time and children.
+ * The {@code StopWatch} class is used for timings
+ */
+public class TimingRecordNode {
+
+/**
+ * The format String for creating paths.
+ */
+private static final String PATH_FMT = "%s/%s";
+
+/**
+ * This nodes parent's path.
+ */
+private String parentTimingPath;
+
+/**
+ * The name of this node.
+ */
+private String timingName;
+
+/**
+ * The tags associated with this timing.
+ */
+private String[] tags;
+
+/**
+ * The child nodes of this node.
+ */
+private List children = new LinkedList<>();
--- End diff --

good point


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Priority: Major
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

2018-01-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342358#comment-16342358
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user ottobackwards commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/311#discussion_r164283887
  
--- Diff: src/main/java/org/apache/commons/lang3/time/TimingRecordNode.java 
---
@@ -0,0 +1,222 @@
+/*
+ * 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.lang3.time;
+
+import java.util.LinkedList;
+import java.util.List;
+import org.apache.commons.lang3.ArrayUtils;
+import org.apache.commons.lang3.StringUtils;
+
+/**
+ * The tree node to track time and children.
+ * The {@code StopWatch} class is used for timings
+ */
+public class TimingRecordNode {
+
+/**
+ * The format String for creating paths.
+ */
+private static final String PATH_FMT = "%s/%s";
+
+/**
+ * This nodes parent's path.
+ */
+private String parentTimingPath;
+
+/**
+ * The name of this node.
+ */
+private String timingName;
+
+/**
+ * The tags associated with this timing.
+ */
+private String[] tags;
+
+/**
+ * The child nodes of this node.
+ */
+private List children = new LinkedList<>();
+
+/**
+ * The {@code StopWatch} for this node.
+ */
+private StopWatch stopWatch = new StopWatch();
+
+/**
+ * 
+ * Constructor.
+ * 
+ * 
+ * Creates a new TimingRecordNode for a given parent name, with a 
given name.
+ * 
+ *
+ * @param parentTimingPath the path of the parent, may be null
+ * @param timingName the name of the timing
+ * @param tags the tags to associate with this timing
+ * @throws IllegalArgumentException if the timingName is null or empty.
+ */
+public TimingRecordNode(String parentTimingPath, String timingName, 
String... tags) {
+if (StringUtils.isEmpty(timingName)) {
+throw new IllegalArgumentException("Argument name is missing");
+}
+this.timingName = timingName;
+
+if (StringUtils.isNotEmpty(parentTimingPath)) {
+this.parentTimingPath = parentTimingPath;
+}
+
+this.tags = tags;
+}
+
+/**
+ * Returns the node's parent's path.
+ * The parent node path may be null
+ *
+ * @return the parent node path
+ */
+public String getParentPath() {
+return parentTimingPath;
+}
+
+/**
+ * Returns the node's timing name.
+ *
+ * @return the node timing name
+ */
+public String getTimingName() {
+return timingName;
+}
+
+/**
+ * Return if the node's StopWatch is running.
+ *
+ * @return true if it is running, false if not
+ */
+public boolean isRunning() {
+return stopWatch.isStarted();
+}
+
+/**
+ * Starts the StopWatch.
+ */
+public void start() {
+if (!stopWatch.isStarted()) {
+stopWatch.start();
+}
+}
+
+/**
+ * 
+ * Stops the StopWatch.
+ * 
+ * 
+ * If this node has running children, an {@code IllegalStateException} 
will result.
+ * 
+ *
+ * @throws IllegalStateException if stop is called on a node with 
running children
+ */
+public void stop() {
+for (TimingRecordNode child : children) {
+if (child.isRunning()) {
+throw new IllegalStateException("Cannot stop a timing with 
running children");
+}
+}
+stopWatch.stop();
+}
+

[GitHub] commons-lang pull request #311: LANG-1373 Stopwatch based capability for nes...

2018-01-27 Thread ottobackwards
Github user ottobackwards commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/311#discussion_r164283887
  
--- Diff: src/main/java/org/apache/commons/lang3/time/TimingRecordNode.java 
---
@@ -0,0 +1,222 @@
+/*
+ * 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.lang3.time;
+
+import java.util.LinkedList;
+import java.util.List;
+import org.apache.commons.lang3.ArrayUtils;
+import org.apache.commons.lang3.StringUtils;
+
+/**
+ * The tree node to track time and children.
+ * The {@code StopWatch} class is used for timings
+ */
+public class TimingRecordNode {
+
+/**
+ * The format String for creating paths.
+ */
+private static final String PATH_FMT = "%s/%s";
+
+/**
+ * This nodes parent's path.
+ */
+private String parentTimingPath;
+
+/**
+ * The name of this node.
+ */
+private String timingName;
+
+/**
+ * The tags associated with this timing.
+ */
+private String[] tags;
+
+/**
+ * The child nodes of this node.
+ */
+private List children = new LinkedList<>();
+
+/**
+ * The {@code StopWatch} for this node.
+ */
+private StopWatch stopWatch = new StopWatch();
+
+/**
+ * 
+ * Constructor.
+ * 
+ * 
+ * Creates a new TimingRecordNode for a given parent name, with a 
given name.
+ * 
+ *
+ * @param parentTimingPath the path of the parent, may be null
+ * @param timingName the name of the timing
+ * @param tags the tags to associate with this timing
+ * @throws IllegalArgumentException if the timingName is null or empty.
+ */
+public TimingRecordNode(String parentTimingPath, String timingName, 
String... tags) {
+if (StringUtils.isEmpty(timingName)) {
+throw new IllegalArgumentException("Argument name is missing");
+}
+this.timingName = timingName;
+
+if (StringUtils.isNotEmpty(parentTimingPath)) {
+this.parentTimingPath = parentTimingPath;
+}
+
+this.tags = tags;
+}
+
+/**
+ * Returns the node's parent's path.
+ * The parent node path may be null
+ *
+ * @return the parent node path
+ */
+public String getParentPath() {
+return parentTimingPath;
+}
+
+/**
+ * Returns the node's timing name.
+ *
+ * @return the node timing name
+ */
+public String getTimingName() {
+return timingName;
+}
+
+/**
+ * Return if the node's StopWatch is running.
+ *
+ * @return true if it is running, false if not
+ */
+public boolean isRunning() {
+return stopWatch.isStarted();
+}
+
+/**
+ * Starts the StopWatch.
+ */
+public void start() {
+if (!stopWatch.isStarted()) {
+stopWatch.start();
+}
+}
+
+/**
+ * 
+ * Stops the StopWatch.
+ * 
+ * 
+ * If this node has running children, an {@code IllegalStateException} 
will result.
+ * 
+ *
+ * @throws IllegalStateException if stop is called on a node with 
running children
+ */
+public void stop() {
+for (TimingRecordNode child : children) {
+if (child.isRunning()) {
+throw new IllegalStateException("Cannot stop a timing with 
running children");
+}
+}
+stopWatch.stop();
+}
+
+/**
+ * Returns the {@code StopWatch} for this node.
+ *
+ * @return {@code StopWatch}
+ */
+public StopWatch getStopWatch() {
+return stopWatch;
+}
+
+/**
   

[GitHub] commons-lang pull request #311: LANG-1373 Stopwatch based capability for nes...

2018-01-27 Thread ottobackwards
Github user ottobackwards commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/311#discussion_r164283889
  
--- Diff: src/main/java/org/apache/commons/lang3/time/TimingRecordNode.java 
---
@@ -0,0 +1,222 @@
+/*
+ * 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.lang3.time;
+
+import java.util.LinkedList;
+import java.util.List;
+import org.apache.commons.lang3.ArrayUtils;
+import org.apache.commons.lang3.StringUtils;
+
+/**
+ * The tree node to track time and children.
+ * The {@code StopWatch} class is used for timings
+ */
+public class TimingRecordNode {
+
+/**
+ * The format String for creating paths.
+ */
+private static final String PATH_FMT = "%s/%s";
+
+/**
+ * This nodes parent's path.
+ */
+private String parentTimingPath;
+
+/**
+ * The name of this node.
+ */
+private String timingName;
+
+/**
+ * The tags associated with this timing.
+ */
+private String[] tags;
+
+/**
+ * The child nodes of this node.
+ */
+private List children = new LinkedList<>();
--- End diff --

good point


---


[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

2018-01-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342349#comment-16342349
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/311#discussion_r164283366
  
--- Diff: src/main/java/org/apache/commons/lang3/time/TimingRecordNode.java 
---
@@ -0,0 +1,222 @@
+/*
+ * 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.lang3.time;
+
+import java.util.LinkedList;
+import java.util.List;
+import org.apache.commons.lang3.ArrayUtils;
+import org.apache.commons.lang3.StringUtils;
+
+/**
+ * The tree node to track time and children.
+ * The {@code StopWatch} class is used for timings
+ */
+public class TimingRecordNode {
+
+/**
+ * The format String for creating paths.
+ */
+private static final String PATH_FMT = "%s/%s";
+
+/**
+ * This nodes parent's path.
+ */
+private String parentTimingPath;
+
+/**
+ * The name of this node.
+ */
+private String timingName;
+
+/**
+ * The tags associated with this timing.
+ */
+private String[] tags;
+
+/**
+ * The child nodes of this node.
+ */
+private List children = new LinkedList<>();
--- End diff --

Would it make much difference if we used an `ArrayList` here? We seem to 
`#add` only in `createChild()`, and not sure if we are using any head/tail 
operation, nor inserting with indexes. So maybe having an `ArrayList` would 
give us the same functionality for less memory?


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Priority: Major
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

2018-01-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342350#comment-16342350
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/311#discussion_r164283339
  
--- Diff: src/main/java/org/apache/commons/lang3/time/TimingRecordNode.java 
---
@@ -0,0 +1,222 @@
+/*
+ * 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.lang3.time;
+
+import java.util.LinkedList;
+import java.util.List;
+import org.apache.commons.lang3.ArrayUtils;
+import org.apache.commons.lang3.StringUtils;
+
+/**
+ * The tree node to track time and children.
+ * The {@code StopWatch} class is used for timings
+ */
+public class TimingRecordNode {
+
+/**
+ * The format String for creating paths.
+ */
+private static final String PATH_FMT = "%s/%s";
+
+/**
+ * This nodes parent's path.
+ */
+private String parentTimingPath;
+
+/**
+ * The name of this node.
+ */
+private String timingName;
+
+/**
+ * The tags associated with this timing.
+ */
+private String[] tags;
+
+/**
+ * The child nodes of this node.
+ */
+private List children = new LinkedList<>();
+
+/**
+ * The {@code StopWatch} for this node.
+ */
+private StopWatch stopWatch = new StopWatch();
+
+/**
+ * 
+ * Constructor.
+ * 
+ * 
+ * Creates a new TimingRecordNode for a given parent name, with a 
given name.
+ * 
+ *
+ * @param parentTimingPath the path of the parent, may be null
+ * @param timingName the name of the timing
+ * @param tags the tags to associate with this timing
+ * @throws IllegalArgumentException if the timingName is null or empty.
+ */
+public TimingRecordNode(String parentTimingPath, String timingName, 
String... tags) {
+if (StringUtils.isEmpty(timingName)) {
+throw new IllegalArgumentException("Argument name is missing");
+}
+this.timingName = timingName;
+
+if (StringUtils.isNotEmpty(parentTimingPath)) {
+this.parentTimingPath = parentTimingPath;
+}
+
+this.tags = tags;
+}
+
+/**
+ * Returns the node's parent's path.
+ * The parent node path may be null
+ *
+ * @return the parent node path
+ */
+public String getParentPath() {
+return parentTimingPath;
+}
+
+/**
+ * Returns the node's timing name.
+ *
+ * @return the node timing name
+ */
+public String getTimingName() {
+return timingName;
+}
+
+/**
+ * Return if the node's StopWatch is running.
+ *
+ * @return true if it is running, false if not
+ */
+public boolean isRunning() {
+return stopWatch.isStarted();
+}
+
+/**
+ * Starts the StopWatch.
+ */
+public void start() {
+if (!stopWatch.isStarted()) {
+stopWatch.start();
+}
+}
+
+/**
+ * 
+ * Stops the StopWatch.
+ * 
+ * 
+ * If this node has running children, an {@code IllegalStateException} 
will result.
+ * 
+ *
+ * @throws IllegalStateException if stop is called on a node with 
running children
+ */
+public void stop() {
+for (TimingRecordNode child : children) {
+if (child.isRunning()) {
+throw new IllegalStateException("Cannot stop a timing with 
running children");
+}
+}
+stopWatch.stop();
+}
+
+

[GitHub] commons-lang pull request #311: LANG-1373 Stopwatch based capability for nes...

2018-01-27 Thread kinow
Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/311#discussion_r164283339
  
--- Diff: src/main/java/org/apache/commons/lang3/time/TimingRecordNode.java 
---
@@ -0,0 +1,222 @@
+/*
+ * 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.lang3.time;
+
+import java.util.LinkedList;
+import java.util.List;
+import org.apache.commons.lang3.ArrayUtils;
+import org.apache.commons.lang3.StringUtils;
+
+/**
+ * The tree node to track time and children.
+ * The {@code StopWatch} class is used for timings
+ */
+public class TimingRecordNode {
+
+/**
+ * The format String for creating paths.
+ */
+private static final String PATH_FMT = "%s/%s";
+
+/**
+ * This nodes parent's path.
+ */
+private String parentTimingPath;
+
+/**
+ * The name of this node.
+ */
+private String timingName;
+
+/**
+ * The tags associated with this timing.
+ */
+private String[] tags;
+
+/**
+ * The child nodes of this node.
+ */
+private List children = new LinkedList<>();
+
+/**
+ * The {@code StopWatch} for this node.
+ */
+private StopWatch stopWatch = new StopWatch();
+
+/**
+ * 
+ * Constructor.
+ * 
+ * 
+ * Creates a new TimingRecordNode for a given parent name, with a 
given name.
+ * 
+ *
+ * @param parentTimingPath the path of the parent, may be null
+ * @param timingName the name of the timing
+ * @param tags the tags to associate with this timing
+ * @throws IllegalArgumentException if the timingName is null or empty.
+ */
+public TimingRecordNode(String parentTimingPath, String timingName, 
String... tags) {
+if (StringUtils.isEmpty(timingName)) {
+throw new IllegalArgumentException("Argument name is missing");
+}
+this.timingName = timingName;
+
+if (StringUtils.isNotEmpty(parentTimingPath)) {
+this.parentTimingPath = parentTimingPath;
+}
+
+this.tags = tags;
+}
+
+/**
+ * Returns the node's parent's path.
+ * The parent node path may be null
+ *
+ * @return the parent node path
+ */
+public String getParentPath() {
+return parentTimingPath;
+}
+
+/**
+ * Returns the node's timing name.
+ *
+ * @return the node timing name
+ */
+public String getTimingName() {
+return timingName;
+}
+
+/**
+ * Return if the node's StopWatch is running.
+ *
+ * @return true if it is running, false if not
+ */
+public boolean isRunning() {
+return stopWatch.isStarted();
+}
+
+/**
+ * Starts the StopWatch.
+ */
+public void start() {
+if (!stopWatch.isStarted()) {
+stopWatch.start();
+}
+}
+
+/**
+ * 
+ * Stops the StopWatch.
+ * 
+ * 
+ * If this node has running children, an {@code IllegalStateException} 
will result.
+ * 
+ *
+ * @throws IllegalStateException if stop is called on a node with 
running children
+ */
+public void stop() {
+for (TimingRecordNode child : children) {
+if (child.isRunning()) {
+throw new IllegalStateException("Cannot stop a timing with 
running children");
+}
+}
+stopWatch.stop();
+}
+
+/**
+ * Returns the {@code StopWatch} for this node.
+ *
+ * @return {@code StopWatch}
+ */
+public StopWatch getStopWatch() {
+return stopWatch;
+}
+
+/**
+ 

[GitHub] commons-lang pull request #311: LANG-1373 Stopwatch based capability for nes...

2018-01-27 Thread kinow
Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/311#discussion_r164283366
  
--- Diff: src/main/java/org/apache/commons/lang3/time/TimingRecordNode.java 
---
@@ -0,0 +1,222 @@
+/*
+ * 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.lang3.time;
+
+import java.util.LinkedList;
+import java.util.List;
+import org.apache.commons.lang3.ArrayUtils;
+import org.apache.commons.lang3.StringUtils;
+
+/**
+ * The tree node to track time and children.
+ * The {@code StopWatch} class is used for timings
+ */
+public class TimingRecordNode {
+
+/**
+ * The format String for creating paths.
+ */
+private static final String PATH_FMT = "%s/%s";
+
+/**
+ * This nodes parent's path.
+ */
+private String parentTimingPath;
+
+/**
+ * The name of this node.
+ */
+private String timingName;
+
+/**
+ * The tags associated with this timing.
+ */
+private String[] tags;
+
+/**
+ * The child nodes of this node.
+ */
+private List children = new LinkedList<>();
--- End diff --

Would it make much difference if we used an `ArrayList` here? We seem to 
`#add` only in `createChild()`, and not sure if we are using any head/tail 
operation, nor inserting with indexes. So maybe having an `ArrayList` would 
give us the same functionality for less memory?


---


[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

2018-01-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342337#comment-16342337
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
I was the one who was not clear enough :-) sorry


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Priority: Major
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...

2018-01-27 Thread kinow
Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
I was the one who was not clear enough :-) sorry


---


[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

2018-01-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342336#comment-16342336
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user ottobackwards commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
I am so sorry, I'll take care of it. 


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Priority: Major
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...

2018-01-27 Thread ottobackwards
Github user ottobackwards commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
I am so sorry, I'll take care of it. 


---


[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

2018-01-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342332#comment-16342332
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
Sorry, what I meant was that indentation in the lang is done with 4 spaces. 
Added an example to another class. Hope that makes sense.


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Priority: Major
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...

2018-01-27 Thread kinow
Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
Sorry, what I meant was that indentation in the lang is done with 4 spaces. 
Added an example to another class. Hope that makes sense.


---


[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

2018-01-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342330#comment-16342330
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/311#discussion_r164282304
  
--- Diff: src/main/java/org/apache/commons/lang3/time/StackWatch.java ---
@@ -0,0 +1,329 @@
+/*
+ * 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.lang3.time;
+
+import java.util.Deque;
+import java.util.LinkedList;
+import org.apache.commons.lang3.StringUtils;
+
+/**
+ * 
+ * The {@code StackWatch}, provides a wrapper around the {@code StopWatch} 
for creating multiple and
+ * possibly nested named timings.
+ * 
+ * 
+ * While the {@code StopWatch} provides functionality to time the length 
of operations, there is no
+ * context or name to go with the time tracked. It is also not possible to 
time nested calls with
+ * the {@code StopWatch}.
+ * 
+ * 
+ * {@code StackWatch} provides that functionality, allowing successive 
calls to {@link StackWatch#startTiming(String, String...)} to track
+ * nested calls.
+ * 
+ * 
+ * Each start provides a timing name and a parent timing name, thus 
providing context to the timing.
+ * 
+ * 
+ * At the end of a timing 'run', a visitor interface provides the ability 
to visit all the timing
+ * 'nodes' and capture their output, including the level of the call if 
nested.
+ * 
+ * 
+ * The {@code TimeRecordNodes} provide a tree structure in support of 
nesting.
+ * A {@code Deque} is use to track the current time node.
+ * 
+ *
+ * 
+ *   {@code
+ *private void outerFunction() {
+ *  try {
+ *StackWatch watch = new StackWatch("OuterFunction");
+ *watch.start();
+ *functionOne();
+ *watch.stop();
+ *watch.visit(new TimingRecordNodeVisitor() {
+ *  {@literal @}Override
+ *  public void visitRecord(int level, TimingRecordNode node) {
+ *...
+ *  }
+ *});
+ *  } catch (Exception e){}
+ *}
+ *private void functionOne(StackWatch watch) throws Exception {
+ *  watch.startTiming("One", "OneFunc");
+ *  functionOneOne(watch);
+ *  watch.stopTiming();
+ *}
+ *
+ *private void functionOneOne(StackWatch watch) throws Exception {
+ *  watch.startTiming("OneOne", "OneFunc");
+ *  functionOneTwo(watch);
+ *  watch.stopTiming();
+ *}
+ *
+ *private void functionOneTwo(StackWatch watch) throws Exception {
+ *  watch.startTiming("OneTwo", "OneFunc");
+ *  watch.stopTiming();
+ *}
+ *   }
+ * 
+ *
+ *
+ * 
+ * This class is not thread safe, and is meant to track timings across 
multiple calls on the same
+ * thread
+ * 
+ */
+public class StackWatch {
+
+  /**
+   * The default name for the root level timing if not provided
+   */
+  public static final String DEFAULT_ROOT_NAME = "ROOT_TIMING";
--- End diff --

Here is needs to be four spaced as well. You can look at another file and 
compare that (e.g. 
https://github.com/apache/commons-lang/blob/f50ec5e608286b0c48d6b9b4c792352de8353804/src/main/java/org/apache/commons/lang3/concurrent/AtomicSafeInitializer.java#L58).


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Priority: Major
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, 

[GitHub] commons-lang pull request #311: LANG-1373 Stopwatch based capability for nes...

2018-01-27 Thread kinow
Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/311#discussion_r164282304
  
--- Diff: src/main/java/org/apache/commons/lang3/time/StackWatch.java ---
@@ -0,0 +1,329 @@
+/*
+ * 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.lang3.time;
+
+import java.util.Deque;
+import java.util.LinkedList;
+import org.apache.commons.lang3.StringUtils;
+
+/**
+ * 
+ * The {@code StackWatch}, provides a wrapper around the {@code StopWatch} 
for creating multiple and
+ * possibly nested named timings.
+ * 
+ * 
+ * While the {@code StopWatch} provides functionality to time the length 
of operations, there is no
+ * context or name to go with the time tracked. It is also not possible to 
time nested calls with
+ * the {@code StopWatch}.
+ * 
+ * 
+ * {@code StackWatch} provides that functionality, allowing successive 
calls to {@link StackWatch#startTiming(String, String...)} to track
+ * nested calls.
+ * 
+ * 
+ * Each start provides a timing name and a parent timing name, thus 
providing context to the timing.
+ * 
+ * 
+ * At the end of a timing 'run', a visitor interface provides the ability 
to visit all the timing
+ * 'nodes' and capture their output, including the level of the call if 
nested.
+ * 
+ * 
+ * The {@code TimeRecordNodes} provide a tree structure in support of 
nesting.
+ * A {@code Deque} is use to track the current time node.
+ * 
+ *
+ * 
+ *   {@code
+ *private void outerFunction() {
+ *  try {
+ *StackWatch watch = new StackWatch("OuterFunction");
+ *watch.start();
+ *functionOne();
+ *watch.stop();
+ *watch.visit(new TimingRecordNodeVisitor() {
+ *  {@literal @}Override
+ *  public void visitRecord(int level, TimingRecordNode node) {
+ *...
+ *  }
+ *});
+ *  } catch (Exception e){}
+ *}
+ *private void functionOne(StackWatch watch) throws Exception {
+ *  watch.startTiming("One", "OneFunc");
+ *  functionOneOne(watch);
+ *  watch.stopTiming();
+ *}
+ *
+ *private void functionOneOne(StackWatch watch) throws Exception {
+ *  watch.startTiming("OneOne", "OneFunc");
+ *  functionOneTwo(watch);
+ *  watch.stopTiming();
+ *}
+ *
+ *private void functionOneTwo(StackWatch watch) throws Exception {
+ *  watch.startTiming("OneTwo", "OneFunc");
+ *  watch.stopTiming();
+ *}
+ *   }
+ * 
+ *
+ *
+ * 
+ * This class is not thread safe, and is meant to track timings across 
multiple calls on the same
+ * thread
+ * 
+ */
+public class StackWatch {
+
+  /**
+   * The default name for the root level timing if not provided
+   */
+  public static final String DEFAULT_ROOT_NAME = "ROOT_TIMING";
--- End diff --

Here is needs to be four spaced as well. You can look at another file and 
compare that (e.g. 
https://github.com/apache/commons-lang/blob/f50ec5e608286b0c48d6b9b4c792352de8353804/src/main/java/org/apache/commons/lang3/concurrent/AtomicSafeInitializer.java#L58).


---


[jira] [Commented] (MATH-1437) Add/extend unit tests for o.a.c.m.geometry.partitioning and related packages

2018-01-27 Thread Matt Juntunen (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342274#comment-16342274
 ] 

Matt Juntunen commented on MATH-1437:
-

Thanks! I am planning on adding some more updates. Here's what I have in mind 
so far (time-willing):
 # Finish adding unit tests for the other packages mentioned in this issue in 
order to flush out any remaining bugs (I know there are at least a couple left) 
and provide a good base for refactoring later on.
 # Create a separate commons-geometry project like you have mentioned earlier.
 # Update/clean up the API to make it easier to use. It's kind of a beast right 
now. One of the biggest things I'd like to change is all of the type casts 
necessary in order to perform any kind of meaningful operation. There are 
general interfaces for all of the types, but in many places the code has to 
assume a particular concrete implementation and cast to it in order to do 
useful work.
 # Look into improving performance, especially for bsp tree creation from 
boundaries. Right now, the code  takes over a minute to create a PolyhedronsSet 
for the utah teapot (~1500 facets). Other libraries I've used could do 
approximately the same thing in a few milliseconds. Admittedly, these other 
libraries don't have the features that commons-math does, but still, a minute 
is way too long here.

I would like to add classes for reading and writing geometry data from other 
file formats but I think the core functionality needs polishing first.

> Add/extend unit tests for o.a.c.m.geometry.partitioning and related packages
> 
>
> Key: MATH-1437
> URL: https://issues.apache.org/jira/browse/MATH-1437
> Project: Commons Math
>  Issue Type: Test
>Affects Versions: 4.X
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 4.X
>
>
> Additional unit tests should be added for the following packages:
>  * o.a.c.m.geometry.partitioning
>  * o.a.c.m.geometry.euclidean.oned
>  * o.a.c.m.geometry.euclidean.twod
>  * o.a.c.m.geometry.euclidean.threed
> The current tests provide adequate code coverage but don't seem to thoroughly 
> exercise the code base and check edge cases.
>  
> Pull request: https://github.com/apache/commons-math/pull/77



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (JEXL-252) Allow for interpolated strings to be used in property access operators

2018-01-27 Thread Henri Biestro (JIRA)

[ 
https://issues.apache.org/jira/browse/JEXL-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342246#comment-16342246
 ] 

Henri Biestro commented on JEXL-252:


The idea behind {code:java}x.'y z'{code} syntax is to allow using constant 
property names that contain spaces/special characters. The constant part is 
important here; we have a syntax when a property is dynamic, the 
{code:java}x.[y]{code} notation.
The different access operators overloads allow managing the difference between 
{code:java}map.length{code} and {code:java}map['length']{code}.
What you propose is currently solved using {code:java}x.[`y`]{code}.

> Allow for interpolated strings to be used in property access operators
> --
>
> Key: JEXL-252
> URL: https://issues.apache.org/jira/browse/JEXL-252
> Project: Commons JEXL
>  Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> Now we have a possibility to access an object property by specifying either 
> {code}object.property{code} or {code}object."property"{code} expression, but 
> not {code}object.`property`{code} expression. Since interpolated strings can 
> be used anywhere in scripts as ordinal strings, it would be logical to allow 
> them to be used in property access operators too. It would allow to have the 
> property name not necessarily to be a constant, but to be evaluated without 
> using the array access operator, since property access operator and array 
> access operator could be implemented (overloaded) differently for the object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (JEXL-250) Safe navigation operator

2018-01-27 Thread Henri Biestro (JIRA)

[ 
https://issues.apache.org/jira/browse/JEXL-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342241#comment-16342241
 ] 

Henri Biestro commented on JEXL-250:


The 'null coalescing' operator '??' has been implemented and is not equivalent 
to the 'elvis' operator '?:'. 

Are you sure you need a 3rd behavior ?

> Safe navigation operator
> 
>
> Key: JEXL-250
> URL: https://issues.apache.org/jira/browse/JEXL-250
> Project: Commons JEXL
>  Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> It would be more convenient for a script writer to have a kind of safe 
> navigation operator, in the form of, for example, ({{object?.property),}} for 
> null pointer dereferences. I think its quite a common feature of many 
> scripting (and compiled languages) now. The safe operator should work like 
> basic navigation operator for non null values and should short-circuit the 
> entire expression evaluation after encountering null value.
> I see the difference of new operator from the existing lenient mode 
> evaluation in ability to explicitly define places in an expression where 
> {{null}} deference is allowed, for example the expression 
> {code}Order.Customer?.Name{code} defines that each {{Order}} should have a 
> {{Customer}} and only the {{Name}} of the {{Customer}} is optional.
> The difference of new operator from the existing null coalescing {{??}} 
> operator is in its ability to short-circuit evaluation.
> So, safe navigation operator would be a helpful syntaxic sugar which in my 
> opinion does not overlap with an existing functionality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (NUMBERS-21) Target Java 7

2018-01-27 Thread Gilles (JIRA)

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

Gilles updated NUMBERS-21:
--
Fix Version/s: 1.0

6, 7, 8 ?

Should be decided before the first release.

> Target Java 7
> -
>
> Key: NUMBERS-21
> URL: https://issues.apache.org/jira/browse/NUMBERS-21
> Project: Commons Numbers
>  Issue Type: Task
>Reporter: Raymond DeCampo
>Priority: Minor
>  Labels: maven
> Fix For: 1.0
>
>
> Numbers is being populated with code from [math], which targets Java 7.  
> Currently Java 6 is targeted in the pom.xml.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (NUMBERS-54) Stream-based utilities

2018-01-27 Thread Gilles (JIRA)
Gilles created NUMBERS-54:
-

 Summary: Stream-based utilities
 Key: NUMBERS-54
 URL: https://issues.apache.org/jira/browse/NUMBERS-54
 Project: Commons Numbers
  Issue Type: New Feature
  Components: complex
Reporter: Gilles
 Fix For: 1.0


Since it is possible to release different modules with different language level 
requirements, we could consider creating a {{commons-numbers-complex-stream}} 
module to hold the utilities currently in class {{ComplexUtils}}.

>From a management POV, it would avoid keeping the maintenance burden of an 
>outdated API once the whole component switches to Java 8.

Release 1.0 should *not* ship with {{ComplexUtils}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NUMBERS-42) Factory methods

2018-01-27 Thread Gilles (JIRA)

[ 
https://issues.apache.org/jira/browse/NUMBERS-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342230#comment-16342230
 ] 

Gilles commented on NUMBERS-42:
---

Choose a naming in line with current JDK:
 * polar(x, y) -> ofPolar(x, y)
 * etc.

> Factory methods
> ---
>
> Key: NUMBERS-42
> URL: https://issues.apache.org/jira/browse/NUMBERS-42
> Project: Commons Numbers
>  Issue Type: New Feature
>Reporter: Gilles
>Priority: Trivial
>  Labels: api
> Fix For: 1.0
>
>
> Wherever applicable, provide {{of}} factory methods.
> For example, in "complex.java":
> {code}
> public static Complex ofCartesian(double re, double im) { /*... */ }
> public static Complex ofPolar(double r, double theta) { /*... */ }
> public static Complex ofCis(double theta) { /*... */ }
> {code}
> To be considered: make the constructors private (or protected).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (NUMBERS-42) Factory methods

2018-01-27 Thread Gilles (JIRA)

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

Gilles updated NUMBERS-42:
--
Description: 
Wherever applicable, provide {{of}} factory methods.
For example, in "complex.java":
{code}
public static Complex ofCartesian(double re, double im) { /*... */ }
public static Complex ofPolar(double r, double theta) { /*... */ }
public static Complex ofCis(double theta) { /*... */ }
{code}

To be considered: make the constructors private (or protected).

  was:
Wherever applicable, provide {{of}} factory methods.
For example, in "complex.java":
{code}
public Complex ofCartesian(double re, double im) { /*... */ }
public Complex ofPolar(double r, double theta) { /*... */ }
{code}

To be considered: make the constructors private (or protected).


> Factory methods
> ---
>
> Key: NUMBERS-42
> URL: https://issues.apache.org/jira/browse/NUMBERS-42
> Project: Commons Numbers
>  Issue Type: New Feature
>Reporter: Gilles
>Priority: Trivial
>  Labels: api
> Fix For: 1.0
>
>
> Wherever applicable, provide {{of}} factory methods.
> For example, in "complex.java":
> {code}
> public static Complex ofCartesian(double re, double im) { /*... */ }
> public static Complex ofPolar(double r, double theta) { /*... */ }
> public static Complex ofCis(double theta) { /*... */ }
> {code}
> To be considered: make the constructors private (or protected).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NUMBERS-42) Factory methods

2018-01-27 Thread Gilles (JIRA)

[ 
https://issues.apache.org/jira/browse/NUMBERS-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342228#comment-16342228
 ] 

Gilles commented on NUMBERS-42:
---

bq. make the constructors private

+1


> Factory methods
> ---
>
> Key: NUMBERS-42
> URL: https://issues.apache.org/jira/browse/NUMBERS-42
> Project: Commons Numbers
>  Issue Type: New Feature
>Reporter: Gilles
>Priority: Trivial
>  Labels: api
> Fix For: 1.0
>
>
> Wherever applicable, provide {{of}} factory methods.
> For example, in "complex.java":
> {code}
> public Complex ofCartesian(double re, double im) { /*... */ }
> public Complex ofPolar(double r, double theta) { /*... */ }
> {code}
> To be considered: make the constructors private (or protected).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (NUMBERS-53) Factory methods are not "static"

2018-01-27 Thread Gilles (JIRA)
Gilles created NUMBERS-53:
-

 Summary: Factory methods are not "static"
 Key: NUMBERS-53
 URL: https://issues.apache.org/jira/browse/NUMBERS-53
 Project: Commons Numbers
  Issue Type: Bug
  Components: complex
Reporter: Gilles
 Fix For: 1.0


* {{polar(x,y)}}
 * cis(x)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (NUMBERS-25) Check list for first release

2018-01-27 Thread Gilles (JIRA)

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

Gilles updated NUMBERS-25:
--
Description: 
List of tasks to complete before considering a first release.
* (x) Review public API
* Ensure clean project reports
** (x) JIRA
** (x) Surefire
** (x) RAT
** (x) Jacoco
** (x) FindBugs
** (x) Checkstyle
** (x) PMD
** (x) CPD
* Ensure that "Commons Math" ("master" branch) compiles and pass all unit tests 
when
** (x) dependencies to "Commons Numbers" modules are added and
** (x) all classes that have an equivalent in "Commons Numbers" are deleted 
(MATH-1416).
* (x) User guide
* (/) 
[Jenkins|https://builds.apache.org/view/Apache%20Commons/job/Commons_Numbers]
* (/) [Web site|http://commons.apache.org/numbers]
* (/) [GitHub|https://github.com/apache/commons-numbers]
* (/) [Travis|https://travis-ci.org/apache/commons-numbers]
* (/) [Coveralls|https://coveralls.io/github/apache/commons-numbers]
* (x) Remove "@since" Javadoc tags


  was:
List of tasks to complete before considering a first release.
* (x) Review public API
* Ensure clean project reports
** (x) JIRA
** (x) Surefire
** (x) RAT
** (x) Jacoco
** (x) FindBugs
** (x) Checkstyle
** (x) PMD
** (x) CPD
* Ensure that "Commons Math" ("master" branch) compiles and pass all unit tests 
when
** (x) dependencies to "Commons Numbers" modules are added and
** (x) all classes that have an equivalent in "Commons Numbers" are deleted 
(MATH-1416).
* (x) User guide
* (/) 
[Jenkins|https://builds.apache.org/view/Apache%20Commons/job/Commons_Numbers]
* (/) [Web site|http://commons.apache.org/numbers]
* (/) [GitHub|https://github.com/apache/commons-numbers]
* (/) [Travis|https://travis-ci.org/apache/commons-numbers]
* (/) [Coveralls|https://coveralls.io/github/apache/commons-numbers]




> Check list for first release
> 
>
> Key: NUMBERS-25
> URL: https://issues.apache.org/jira/browse/NUMBERS-25
> Project: Commons Numbers
>  Issue Type: Task
>Reporter: Gilles
>Priority: Major
>  Labels: release, tasks
> Fix For: 1.0
>
>
> List of tasks to complete before considering a first release.
> * (x) Review public API
> * Ensure clean project reports
> ** (x) JIRA
> ** (x) Surefire
> ** (x) RAT
> ** (x) Jacoco
> ** (x) FindBugs
> ** (x) Checkstyle
> ** (x) PMD
> ** (x) CPD
> * Ensure that "Commons Math" ("master" branch) compiles and pass all unit 
> tests when
> ** (x) dependencies to "Commons Numbers" modules are added and
> ** (x) all classes that have an equivalent in "Commons Numbers" are deleted 
> (MATH-1416).
> * (x) User guide
> * (/) 
> [Jenkins|https://builds.apache.org/view/Apache%20Commons/job/Commons_Numbers]
> * (/) [Web site|http://commons.apache.org/numbers]
> * (/) [GitHub|https://github.com/apache/commons-numbers]
> * (/) [Travis|https://travis-ci.org/apache/commons-numbers]
> * (/) [Coveralls|https://coveralls.io/github/apache/commons-numbers]
> * (x) Remove "@since" Javadoc tags



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (NUMBERS-22) Method reciprocal() in Complex for complex numbers with parts very close to 0.0

2018-01-27 Thread Gilles (JIRA)

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

Gilles resolved NUMBERS-22.
---
Resolution: Fixed

commit fc70d935fdadc5d5a7862cf9a929da91b72b00d6

> Method reciprocal() in Complex for complex numbers with parts very close to 
> 0.0
> ---
>
> Key: NUMBERS-22
> URL: https://issues.apache.org/jira/browse/NUMBERS-22
> Project: Commons Numbers
>  Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
> Fix For: 1.0
>
>
> I have been redirected here from the issue repository of Apache Commons Math, 
> as the Complex class will likely be deprecated in favour of its equivalent in 
> "Commons Numbers".
> In class Complex method reciprocal() returns INF only if the real and 
> imaginary parts are exactly equal to 0.0. In the cases when real and 
> imaginary parts are double numbers very close to 0.0, it does not hold. For 
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of 
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> The suggested solutions after the discussion are either checking the equality 
> to ZERO with some tolerance or to detect if one of the real or imaginary 
> parts is going to be infinite or NaN and then return the proper result. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (NUMBERS-48) Unreachable statements in Complex.abs()

2018-01-27 Thread Gilles (JIRA)

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

Gilles resolved NUMBERS-48.
---
Resolution: Fixed

commit 16322d83ab3092e93a1e2d7f576b185682c16f69

> Unreachable statements in Complex.abs()
> ---
>
> Key: NUMBERS-48
> URL: https://issues.apache.org/jira/browse/NUMBERS-48
> Project: Commons Numbers
>  Issue Type: Bug
>Reporter: David Nickerson
>Priority: Minor
>  Labels: easyfix, newbie, patch
> Fix For: 1.0
>
> Attachments: complex_abs.patch
>
>
> This return statement in Complex.abs() is unreachable:
> {code:java}
> if (FastMath.abs(real) < FastMath.abs(imaginary)) {
>   if (imaginary == 0.0) {
> return FastMath.abs(real);
>   }
> {code}
> If imaginary == 0, then there's no way that the preceding condition would be 
> true. There are two similar inner 'if' statements that were accidentally 
> switched. Returned values are still correct, but performance suffers.
> The attached patch switches these back. Note that we're still protected from 
> dividing by zero.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (NUMBERS-46) ContinuedFraction: "maxIterations" argument

2018-01-27 Thread Gilles (JIRA)

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

Gilles resolved NUMBERS-46.
---
Resolution: Fixed

> ContinuedFraction: "maxIterations" argument
> ---
>
> Key: NUMBERS-46
> URL: https://issues.apache.org/jira/browse/NUMBERS-46
> Project: Commons Numbers
>  Issue Type: Bug
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Fix For: 1.0
>
>
> In class {{o.a.c.numbers.fraction.ContinuedFraction}}, method {{evaluate}} is 
> declared as
> {code}
> public double evaluate(double x, double epsilon, int maxIterations)
> {code}
> Calling
> {code}
> cf.evaluate(x, eps, 1)
> {code}
> will raise an exception:
> {noformat}
> org.apache.commons.numbers.fraction.FractionException: maximal count (1) 
> exceeded
> {noformat}
> At first sight, the check
> {code}
> if (n >= maxIterations) {
> {code}
> should rather be
> {code}
> if (n > maxIterations) {
> {code}
> However, it would also seem that the loop counter is wrong:
> {code}
> while (n < maxIterations) {
> {code}
> since setting {{maxIterations}} to 1 will in effect execute _zero_ 
> iteration...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (NUMBERS-43) Remove "round(float)" methods?

2018-01-27 Thread Gilles (JIRA)

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

Gilles resolved NUMBERS-43.
---
Resolution: Done

commit bf05e066c816245609e0315b27103192906b2d17

> Remove "round(float)" methods?
> --
>
> Key: NUMBERS-43
> URL: https://issues.apache.org/jira/browse/NUMBERS-43
> Project: Commons Numbers
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Major
>  Labels: api, float
> Fix For: 1.0
>
>
> In class {{Precision}}, there are methods for rounding {{float}} values, e.g.
> {code:java}
> public static float round(float x, int scale, int roundingMethod) { /* ... */ 
> }
> {code}
> Is there any use for supporting specific handling of floats (in these times 
> where memory is not a scarce resources anymore)?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

2018-01-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342177#comment-16342177
 ] 

ASF GitHub Bot commented on LANG-1373:
--

Github user ottobackwards commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
I will take care of it :)


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Priority: Major
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...

2018-01-27 Thread ottobackwards
Github user ottobackwards commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
I will take care of it :)


---


[jira] [Commented] (MATH-1441) SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on every call

2018-01-27 Thread Gilles (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342131#comment-16342131
 ] 

Gilles commented on MATH-1441:
--

{quote}it's the `inverseCumulativeProbability` calculation immediately after 
that's expensive.
{quote}
In your case, the use of a fixed "alpha" (0.05 by default) makes all those call 
always compute the same value; so it seems that both "n" and "alpha" (and their 
expensive dependents) must be cached.
{quote}I might be interested in contributing something like that if you're 
interested
{quote}
Sure.
{quote}what's the minimum JVM version you're targeting in Commons Math 4.0?
{quote}
24.3 ;)
 As it is we should rather focus on the new "Commons Statistics" component 
which I referred to above. As a new project, it is targeted at Java 8.

It would be great if you could post on the ML with a proposal on how to move 
that code to the new repository. If you intend to work on that, I can create a 
new module: {{commons-statistics-regression}} (?).
{quote}sometimes a pleasant surprise, to work with people who care about their 
open-source software.
{quote}
Some would say that I care too much. See ML archive for details...

Actually, we are looking for developers who'd like to care too (in the longer 
term).
 And "Commons Math" is too broad for that. As an example, I'm not a direct user 
of anything in {{o.a.c.math4.stat}}, so I should not be the one to dig into 
unknown code figuring out why things are the way they are (with the consequence 
that a review could uncover design problems – cf. other JIRA reports about it).

In the new module, we should take the time to define a stable API.

> SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on 
> every call
> -
>
> Key: MATH-1441
> URL: https://issues.apache.org/jira/browse/MATH-1441
> Project: Commons Math
>  Issue Type: Improvement
>Affects Versions: 3.6.1
> Environment: Java 8, Linux x64.
>Reporter: Max Aller
>Priority: Minor
>  Labels: performance
> Attachments: visualvm screenshot.png
>
>
> SimpleRegression#getSlopeConfidenceInterval, when called a lot (on the other 
> of 100k or 1M times), is surprisingly slow - 3M calls, on my 3rd gen i7 
> machine, takes *75 seconds*. This is primarily because recalculating the 
> inverse cumulative probability, and reconstructing the TDistribution object 
> itself, is somewhat expensive, entailing a lot of `log` and `sqrt` and 
> iteration and all that stuff.
> The confidence interval is based on two values - *n* and *alpha*. I'd posit 
> that alpha will _usually_ be one of a very small set of values, and n, well, 
> at least in my case, I'm always calling this method with the same number of 
> data points - a moving window of time-series data. But I recognize n might be 
> all over the place for some users.
> In any event, I strongly believe some level of caching would greatly benefit 
> the users of Commons Math. I've forked my own version of 
> getSlopeConfidenceInterval that uses caching. Here's a test case 
> demonstrating that:
> {code:java}
> class SlowRegressionsTest {
> @Test
> void slow() {
> SimpleRegression simpleRegression = new SimpleRegression();
> simpleRegression.addData(0.0, 0.0);
> simpleRegression.addData(1.0, 1.0);
> simpleRegression.addData(2.0, 2.0);
> long start = System.currentTimeMillis();
> for (int i = 0; i < 3_000_000; i++) {
> simpleRegression.getSlopeConfidenceInterval();
> }
> long duration = System.currentTimeMillis() - start;
> System.out.printf("`slow` took %dms%n", duration);
> }
> @Test
> void fast() {
> SimpleRegression simpleRegression = new SimpleRegression();
> simpleRegression.addData(0.0, 0.0);
> simpleRegression.addData(1.0, 1.0);
> simpleRegression.addData(2.0, 2.0);
> long start = System.currentTimeMillis();
> for (int i = 0; i < 3_000_000; i++) {
> 
> SimpleRegressionUtilsKt.fastGetSlopeConfidenceInterval(simpleRegression);
> }
> long duration = System.currentTimeMillis() - start;
> System.out.printf("`fast` took %dms%n", duration);
> }
> }{code}
> which prints out
> {noformat}
> `fast` took 159ms
> `slow` took 75304ms{noformat}
> Nearly 500x faster - 53ns/call. My particular solution is written in Kotlin 
> for Java 8, so not of direct relevance to you, but here it is:
> {code:java}
> package math
> import org.apache.commons.math3.distribution.TDistribution
> import org.apache.commons.math3.exception.OutOfRangeException
> import org.apache.commons.math3.exception.util.LocalizedFormats
> import org.apache.commons.math3.stat.regression.SimpleRegression
> import