RE: [5/7] [math] Fix "FastMath#round(..)" to comply to changed contract of "Math#round()" in Java 8

[Dennis E. Hamilton]

>From the peanut gallery, in-line.

> -Original Message-
> From: Gilles [mailto:gil...@harfang.homelinux.org]
> Sent: Monday, August 8, 2016 08:50
> To: dev@commons.apache.org
> Subject: Re: [5/7] [math] Fix "FastMath#round(..)" to comply to changed
> contract of "Math#round()" in Java 8
> 
> On Mon, 8 Aug 2016 16:40:04 +0200, Emmanuel Bourg wrote:
> > Le 8/08/2016 à 16:22, Gilles a écrit :
> >
> >> There are pro and contra; IMO, saving a few characters is not worth
> >> wondering upon reading whether "assertEquals" is from (JUnit)
> >> "Assert"
> >> or Commons Math "TestUtils".
> >
> > Seriously, there is little doubt that "assertEquals" comes from JUnit
> > in
> > a FooTest class. Everybody is used to that.
[orcmid] 

It is the presumption of tacit knowledge, in an ever-expanding ring, that 
complicates the on-ramp for newcomers, until they manage to gulp down all of 
the kool-aid and become perpetrators themselves.  

> 
> My point was that there exists "TestUtils.assertEquals": also for use
> in a unit test class!
> Someone might want to "import static" those too.  In some files
> "Assert"
> would be implied, and in others "TestUtils".  [No big deal: just what
> you gain somewhere you loose somewhere else.]
[orcmid] 

Except it is another dependency that someone has to be careful to check, and 
we're not talking about small test files here.

> 
> I have no problem deciding that static import of Junit's Assert methods
> is allowed.  But let's be clear that it does extend to other classes.
> 
> >> When people get accustomed to git, they won't see it as a
> >> constraint,
> >> rather as second nature.
> >
> > I'm accustomed to Git and I see this as a constraint that I don't
> > have
> > the time to deal with.
> 
> Hence, you assume that reviewers are either not necessary, or that
> they their time is worth less than yours.
> 
> We can (have to, actually) understand that long-time committers
> will take a short-cut sometimes, but whenever it happens it should
> not be a massive commit.  Otherwise anything goes.  I hope that you
> can agree that it should not be advertised as good practice.
[orcmid] 

+1 with regard to paying attention to sustainability and community.

> 
> 
> Regards,
> Gilles
> 
> >
> > Emmanuel Bourg
> >
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [5/7] [math] Fix "FastMath#round(..)" to comply to changed contract of "Math#round()" in Java 8

[Emmanuel Bourg]

Le 8/08/2016 à 17:50, Gilles a écrit :

> Hence, you assume that reviewers are either not necessary, or that
> they their time is worth less than yours.

>From my experience it doesn't take more time to review a one commit
change on a branch or on the trunk.

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [5/7] [math] Fix "FastMath#round(..)" to comply to changed contract of "Math#round()" in Java 8

[Gilles]

On Mon, 8 Aug 2016 16:40:04 +0200, Emmanuel Bourg wrote:

Le 8/08/2016 à 16:22, Gilles a écrit :


There are pro and contra; IMO, saving a few characters is not worth
wondering upon reading whether "assertEquals" is from (JUnit) 
"Assert"

or Commons Math "TestUtils".


Seriously, there is little doubt that "assertEquals" comes from JUnit 
in

a FooTest class. Everybody is used to that.


My point was that there exists "TestUtils.assertEquals": also for use
in a unit test class!
Someone might want to "import static" those too.  In some files 
"Assert"

would be implied, and in others "TestUtils".  [No big deal: just what
you gain somewhere you loose somewhere else.]

I have no problem deciding that static import of Junit's Assert methods
is allowed.  But let's be clear that it does extend to other classes.

When people get accustomed to git, they won't see it as a 
constraint,

rather as second nature.


I'm accustomed to Git and I see this as a constraint that I don't 
have

the time to deal with.


Hence, you assume that reviewers are either not necessary, or that
they their time is worth less than yours.

We can (have to, actually) understand that long-time committers
will take a short-cut sometimes, but whenever it happens it should
not be a massive commit.  Otherwise anything goes.  I hope that you
can agree that it should not be advertised as good practice.


Regards,
Gilles



Emmanuel Bourg




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [5/7] [math] Fix "FastMath#round(..)" to comply to changed contract of "Math#round()" in Java 8

[Rob Tompkins]

> On Aug 8, 2016, at 10:40 AM, Emmanuel Bourg  wrote:
> 
> Le 8/08/2016 à 16:22, Gilles a écrit :
> 
>> There are pro and contra; IMO, saving a few characters is not worth
>> wondering upon reading whether "assertEquals" is from (JUnit) "Assert"
>> or Commons Math "TestUtils".
> 
> Seriously, there is little doubt that "assertEquals" comes from JUnit in
> a FooTest class. Everybody is used to that.

Emmanuel has a point here that generally when one comes across 
“assertEquals(…);” in an arbitrary test class, one concludes that it stems from 
JUnit. 

If we were going to indeed require assertEquals to be sufficiently generalized, 
then might we consider creating a class “org.apache.commons.math*.Assert” that 
extends JUnit’s Assert so that we can simply have one yet retain our math 
specific generalizations for assertions? It feels like in doing this we could 
reasonably cover both sides of the argument.

Thoughts?

-Rob

> 
> 
>> When people get accustomed to git, they won't see it as a constraint,
>> rather as second nature.
> 
> I'm accustomed to Git and I see this as a constraint that I don't have
> the time to deal with.
> 
> Emmanuel Bourg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [5/7] [math] Fix "FastMath#round(..)" to comply to changed contract of "Math#round()" in Java 8

[Emmanuel Bourg]

Le 8/08/2016 à 16:22, Gilles a écrit :

> There are pro and contra; IMO, saving a few characters is not worth
> wondering upon reading whether "assertEquals" is from (JUnit) "Assert"
> or Commons Math "TestUtils".

Seriously, there is little doubt that "assertEquals" comes from JUnit in
a FooTest class. Everybody is used to that.


> When people get accustomed to git, they won't see it as a constraint,
> rather as second nature.

I'm accustomed to Git and I see this as a constraint that I don't have
the time to deal with.

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [5/7] [math] Fix "FastMath#round(..)" to comply to changed contract of "Math#round()" in Java 8

[Gilles]

On Mon, 8 Aug 2016 13:14:18 +0200, Emmanuel Bourg wrote:

Le 8/08/2016 à 00:42, Gilles a écrit :


In CM, the usage was to not use "import static".


You should make an exception for the unit tests, otherwise the JUnit 
4
syntax is too verbose (and JUnit 4 was designed with static imports 
in

mind).


There are pro and contra; IMO, saving a few characters is not worth
wondering upon reading whether "assertEquals" is from (JUnit) "Assert"
or Commons Math "TestUtils".


Excerpts from "CONTRIBUTING.md":
+ Create a topic branch from where you want to base your work (this 
is

usually the develop/trunk branch).


This is too complicated for simple changes. Topic branches are
interesting for long lived branches involving many modifications 
needing

review. Forcing a topic branch for any modification is a hassle.


YMMV.
One big advantage of a branch is that reviewers can examine different
"topics" at their will (e.g. out of order).

"Simple" changes are those that do not involve any build risks (such as
a Jenkins failure).  So, mostly: documentation upgrades.

If you want Commons Math to be welcoming to new contributors you 
should

consider relaxing the workflow constraints.


When people get accustomed to git, they won't see it as a constraint,
rather as second nature.

Much better to discuss and modify code when it is in a topic branch
rather than after it was merged into the main one.

I think that it is also much easier to review (by making a diff between
branches rather than search for the appropriate commit ids).

If there is a JIRA report, the log must indeed make it 
straightforward

to find it.


I agree, but is this case I noticed the issue in JIRA after pushing 
the

changes.


If performed in a topic branch, the questions prompted by the changes
would have offered the opportunity to add the information in the merge
message.

QED. ;-)


Gilles



Emmanuel Bourg




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [5/7] [math] Fix "FastMath#round(..)" to comply to changed contract of "Math#round()" in Java 8

[Emmanuel Bourg]

Le 8/08/2016 à 00:42, Gilles a écrit :

> In CM, the usage was to not use "import static".

You should make an exception for the unit tests, otherwise the JUnit 4
syntax is too verbose (and JUnit 4 was designed with static imports in
mind).


> Excerpts from "CONTRIBUTING.md":
> + Create a topic branch from where you want to base your work (this is
> usually the develop/trunk branch).

This is too complicated for simple changes. Topic branches are
interesting for long lived branches involving many modifications needing
review. Forcing a topic branch for any modification is a hassle.

If you want Commons Math to be welcoming to new contributors you should
consider relaxing the workflow constraints.


> If there is a JIRA report, the log must indeed make it straightforward
> to find it.

I agree, but is this case I noticed the issue in JIRA after pushing the
changes.

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [5/7] [math] Fix "FastMath#round(..)" to comply to changed contract of "Math#round()" in Java 8

[Gilles]

On Sat, 6 Aug 2016 11:46:01 -0700, Dennis E. Hamilton wrote:

-Original Message-
From: Gilles [mailto:gil...@harfang.homelinux.org]
Sent: Friday, August 5, 2016 09:11
To: Commons Developers List 
Subject: Re: [5/7] [math] Fix "FastMath#round(..)" to comply to 
changed

contract of "Math#round()" in Java 8

Hi.

Changes in this file seem unrelated to the commit message.

Gilles

[orcmid]

Yes, this appears to be a massive change involving what may largely
be stylistic matters (if that is what Assert.assertMumble <<
assertMumble is all about).


In CM, the usage was to not use "import static".


On first glance, it makes an excessive
change that is extremely difficult to comprehend and review.

What are the practices around expecting small focused single-purpose
changes and, in this case, a small change that addresses the stated
purpose of the commit with regard to the contract for 
FastMath.round()

and its testing?

Is this [VETO] territory, and would the committer be asked to revert
the change and break it down?


Excerpts from "CONTRIBUTING.md":
+ Create a topic branch from where you want to base your work (this is 
usually the develop/trunk branch).

+ Make commits of logical units.
+ Respect the original code style:
  + Create minimal diffs - disable on save actions like reformat source 
code or organize imports.
If you feel the source code should be reformatted create a separate 
PR for this change.
+ Make sure your commit messages are in the proper format. Your commit 
message should contain

  the key of the JIRA issue.
  + For example, a commit message might look like `MATH-852: Adding 
documentation for development`



I ask this because I don't understand the Commons culture and
practices in order to know.

Oh, and is there a JIRA about this (the Math.round contract) or some
other way to tie in whatever scholarship and traceability is involved
in the specialized case of [MATH] software?  (I may have missed this 
-

sorry for asking if already answered.)


If there is a JIRA report, the log must indeed make it straightforward
to find it.

Gilles


 - Dennis




On Fri, 05 Aug 2016 15:06:53 -, ebo...@apache.org wrote:
>
> http://git-wip-us.apache.org/repos/asf/commons-

math/blob/83b70a37/src/test/java/org/apache/commons/math4/util/FastMathT
est.java
>
> 
--

> diff --git
> a/src/test/java/org/apache/commons/math4/util/FastMathTest.java
> b/src/test/java/org/apache/commons/math4/util/FastMathTest.java
> index cc95c9c..1f94352 100644
> --- 
a/src/test/java/org/apache/commons/math4/util/FastMathTest.java
> +++ 
b/src/test/java/org/apache/commons/math4/util/FastMathTest.java

> @@ -16,6 +16,10 @@
>   */
>  package org.apache.commons.math4.util;
>
> +import static org.junit.Assert.assertEquals;
> +import static org.junit.Assert.assertTrue;
> +import static org.junit.Assert.fail;
> +
>  import java.lang.reflect.Method;
>  import java.lang.reflect.Modifier;
>  import java.lang.reflect.Type;
> @@ -30,8 +34,6 @@ import org.apache.commons.math4.dfp.DfpMath;
>  import 
org.apache.commons.math4.exception.MathArithmeticException;

>  import org.apache.commons.math4.rng.UniformRandomProvider;
>  import org.apache.commons.math4.rng.RandomSource;
> -import org.apache.commons.math4.util.FastMath;
> -import org.apache.commons.math4.util.Precision;
>  import org.junit.Assert;
>  import org.junit.Before;
>  import org.junit.Ignore;
> @@ -42,7 +44,6 @@ public class FastMathTest {
>  private static final double MAX_ERROR_ULP = 0.51;
>  private static final int NUMBER_OF_TRIALS = 1000;
>
> -
>  private DfpField field;
>  private UniformRandomProvider generator;
>
> @@ -67,22 +68,22 @@ public class FastMathTest {
>  { Precision.SAFE_MIN, Precision.EPSILON }
>  };
>  for (double[] pair : pairs) {
> -Assert.assertEquals("min(" + pair[0] + ", " + pair[1] 
+

> ")",
> -Math.min(pair[0], pair[1]),
> -FastMath.min(pair[0], pair[1]),
> -Precision.EPSILON);
> -Assert.assertEquals("min(" + pair[1] + ", " + pair[0] 
+

> ")",
> -Math.min(pair[1], pair[0]),
> -FastMath.min(pair[1], pair[0]),
> -Precision.EPSILON);
> -Assert.assertEquals("max(" + pair[0] + ", " + pair[1] 
+

> ")",
> -Math.max(pair[0], pair[1]),
> -FastMath.max(pair[0], pair[1]),
> -Precision.EPSILON);
> -Assert.assertEquals("max(" + pair[1] + ", " + pair[0] 
+

> ")",
> -Math.max(pair[1], pair[0]),
> -FastMath.max(pair[1], pair[0]),
> -Precision.EPSILON);
> +assertEquals("min(" 

Re: [5/7] [math] Fix "FastMath#round(..)" to comply to changed contract of "Math#round()" in Java 8

[Emmanuel Bourg]

Le 6/08/2016 à 20:46, Dennis E. Hamilton a écrit :

> Oh, and is there a JIRA about this (the Math.round contract) or some other 
> way to tie in whatever scholarship and traceability is involved in the 
> specialized case of [MATH] software?  (I may have missed this - sorry for 
> asking if already answered.)

https://issues.apache.org/jira/browse/MATH-1196


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

RE: [5/7] [math] Fix "FastMath#round(..)" to comply to changed contract of "Math#round()" in Java 8

[Dennis E. Hamilton]

> -Original Message-
> From: Gilles [mailto:gil...@harfang.homelinux.org]
> Sent: Friday, August 5, 2016 09:11
> To: Commons Developers List 
> Subject: Re: [5/7] [math] Fix "FastMath#round(..)" to comply to changed
> contract of "Math#round()" in Java 8
> 
> Hi.
> 
> Changes in this file seem unrelated to the commit message.
> 
> Gilles
[orcmid] 

Yes, this appears to be a massive change involving what may largely be 
stylistic matters (if that is what Assert.assertMumble << assertMumble is all 
about).  On first glance, it makes an excessive change that is extremely 
difficult to comprehend and review.

What are the practices around expecting small focused single-purpose changes 
and, in this case, a small change that addresses the stated purpose of the 
commit with regard to the contract for FastMath.round() and its testing?

Is this [VETO] territory, and would the committer be asked to revert the change 
and break it down?

I ask this because I don't understand the Commons culture and practices in 
order to know.

Oh, and is there a JIRA about this (the Math.round contract) or some other way 
to tie in whatever scholarship and traceability is involved in the specialized 
case of [MATH] software?  (I may have missed this - sorry for asking if already 
answered.)

 - Dennis


> 
> On Fri, 05 Aug 2016 15:06:53 -, ebo...@apache.org wrote:
> >
> > http://git-wip-us.apache.org/repos/asf/commons-
> math/blob/83b70a37/src/test/java/org/apache/commons/math4/util/FastMathT
> est.java
> >
> > --
> > diff --git
> > a/src/test/java/org/apache/commons/math4/util/FastMathTest.java
> > b/src/test/java/org/apache/commons/math4/util/FastMathTest.java
> > index cc95c9c..1f94352 100644
> > --- a/src/test/java/org/apache/commons/math4/util/FastMathTest.java
> > +++ b/src/test/java/org/apache/commons/math4/util/FastMathTest.java
> > @@ -16,6 +16,10 @@
> >   */
> >  package org.apache.commons.math4.util;
> >
> > +import static org.junit.Assert.assertEquals;
> > +import static org.junit.Assert.assertTrue;
> > +import static org.junit.Assert.fail;
> > +
> >  import java.lang.reflect.Method;
> >  import java.lang.reflect.Modifier;
> >  import java.lang.reflect.Type;
> > @@ -30,8 +34,6 @@ import org.apache.commons.math4.dfp.DfpMath;
> >  import org.apache.commons.math4.exception.MathArithmeticException;
> >  import org.apache.commons.math4.rng.UniformRandomProvider;
> >  import org.apache.commons.math4.rng.RandomSource;
> > -import org.apache.commons.math4.util.FastMath;
> > -import org.apache.commons.math4.util.Precision;
> >  import org.junit.Assert;
> >  import org.junit.Before;
> >  import org.junit.Ignore;
> > @@ -42,7 +44,6 @@ public class FastMathTest {
> >  private static final double MAX_ERROR_ULP = 0.51;
> >  private static final int NUMBER_OF_TRIALS = 1000;
> >
> > -
> >  private DfpField field;
> >  private UniformRandomProvider generator;
> >
> > @@ -67,22 +68,22 @@ public class FastMathTest {
> >  { Precision.SAFE_MIN, Precision.EPSILON }
> >  };
> >  for (double[] pair : pairs) {
> > -Assert.assertEquals("min(" + pair[0] + ", " + pair[1] +
> > ")",
> > -Math.min(pair[0], pair[1]),
> > -FastMath.min(pair[0], pair[1]),
> > -Precision.EPSILON);
> > -Assert.assertEquals("min(" + pair[1] + ", " + pair[0] +
> > ")",
> > -Math.min(pair[1], pair[0]),
> > -FastMath.min(pair[1], pair[0]),
> > -Precision.EPSILON);
> > -Assert.assertEquals("max(" + pair[0] + ", " + pair[1] +
> > ")",
> > -Math.max(pair[0], pair[1]),
> > -FastMath.max(pair[0], pair[1]),
> > -Precision.EPSILON);
> > -Assert.assertEquals("max(" + pair[1] + ", " + pair[0] +
> > ")",
> > -Math.max(pair[1], pair[0]),
> > -FastMath.max(pair[1], pair[0]),
> > -Precision.EPSILON);
> > +assertEquals("min(" + pair[0] + ", " + pair[1] + ")",
> > + Math.min(pair[0], pair[1]),
> > + FastMath.min(pair[0], pair[1]),
> > + Precision.EPSILON);
> > +assertEquals("min(" + pair[1] + ", " + pair[0] + ")",
> > + Math.min(pair[1], pair[0]),
> > + FastMath.min(pair[1], pair[0]),
> > + Precision.EPSILON);
> > +assertEquals("max(" + pair[0] + ", " + pair[1] + ")",
> > + Math.max(pair[0], pair[1]),
> > + FastMath.max(pair[0], pair[1]),
> > + Precision.EPSILON);
> > +  

Re: [5/7] [math] Fix "FastMath#round(..)" to comply to changed contract of "Math#round()" in Java 8

[Gilles]

Hi.

Changes in this file seem unrelated to the commit message.

Gilles

On Fri, 05 Aug 2016 15:06:53 -, ebo...@apache.org wrote:


http://git-wip-us.apache.org/repos/asf/commons-math/blob/83b70a37/src/test/java/org/apache/commons/math4/util/FastMathTest.java

--
diff --git
a/src/test/java/org/apache/commons/math4/util/FastMathTest.java
b/src/test/java/org/apache/commons/math4/util/FastMathTest.java
index cc95c9c..1f94352 100644
--- a/src/test/java/org/apache/commons/math4/util/FastMathTest.java
+++ b/src/test/java/org/apache/commons/math4/util/FastMathTest.java
@@ -16,6 +16,10 @@
  */
 package org.apache.commons.math4.util;

+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertTrue;
+import static org.junit.Assert.fail;
+
 import java.lang.reflect.Method;
 import java.lang.reflect.Modifier;
 import java.lang.reflect.Type;
@@ -30,8 +34,6 @@ import org.apache.commons.math4.dfp.DfpMath;
 import org.apache.commons.math4.exception.MathArithmeticException;
 import org.apache.commons.math4.rng.UniformRandomProvider;
 import org.apache.commons.math4.rng.RandomSource;
-import org.apache.commons.math4.util.FastMath;
-import org.apache.commons.math4.util.Precision;
 import org.junit.Assert;
 import org.junit.Before;
 import org.junit.Ignore;
@@ -42,7 +44,6 @@ public class FastMathTest {
 private static final double MAX_ERROR_ULP = 0.51;
 private static final int NUMBER_OF_TRIALS = 1000;

-
 private DfpField field;
 private UniformRandomProvider generator;

@@ -67,22 +68,22 @@ public class FastMathTest {
 { Precision.SAFE_MIN, Precision.EPSILON }
 };
 for (double[] pair : pairs) {
-Assert.assertEquals("min(" + pair[0] + ", " + pair[1] + 
")",

-Math.min(pair[0], pair[1]),
-FastMath.min(pair[0], pair[1]),
-Precision.EPSILON);
-Assert.assertEquals("min(" + pair[1] + ", " + pair[0] + 
")",

-Math.min(pair[1], pair[0]),
-FastMath.min(pair[1], pair[0]),
-Precision.EPSILON);
-Assert.assertEquals("max(" + pair[0] + ", " + pair[1] + 
")",

-Math.max(pair[0], pair[1]),
-FastMath.max(pair[0], pair[1]),
-Precision.EPSILON);
-Assert.assertEquals("max(" + pair[1] + ", " + pair[0] + 
")",

-Math.max(pair[1], pair[0]),
-FastMath.max(pair[1], pair[0]),
-Precision.EPSILON);
+assertEquals("min(" + pair[0] + ", " + pair[1] + ")",
+ Math.min(pair[0], pair[1]),
+ FastMath.min(pair[0], pair[1]),
+ Precision.EPSILON);
+assertEquals("min(" + pair[1] + ", " + pair[0] + ")",
+ Math.min(pair[1], pair[0]),
+ FastMath.min(pair[1], pair[0]),
+ Precision.EPSILON);
+assertEquals("max(" + pair[0] + ", " + pair[1] + ")",
+ Math.max(pair[0], pair[1]),
+ FastMath.max(pair[0], pair[1]),
+ Precision.EPSILON);
+assertEquals("max(" + pair[1] + ", " + pair[0] + ")",
+ Math.max(pair[1], pair[0]),
+ FastMath.max(pair[1], pair[0]),
+ Precision.EPSILON);
 }
 }

@@ -100,39 +101,39 @@ public class FastMathTest {
 {  Float.NaN, Float.POSITIVE_INFINITY }
 };
 for (float[] pair : pairs) {
-Assert.assertEquals("min(" + pair[0] + ", " + pair[1] + 
")",

-Math.min(pair[0], pair[1]),
-FastMath.min(pair[0], pair[1]),
-Precision.EPSILON);
-Assert.assertEquals("min(" + pair[1] + ", " + pair[0] + 
")",

-Math.min(pair[1], pair[0]),
-FastMath.min(pair[1], pair[0]),
-Precision.EPSILON);
-Assert.assertEquals("max(" + pair[0] + ", " + pair[1] + 
")",

-Math.max(pair[0], pair[1]),
-FastMath.max(pair[0], pair[1]),
-Precision.EPSILON);
-Assert.assertEquals("max(" + pair[1] + ", " + pair[0] + 
")",

-Math.max(pair[1], pair[0]),
-FastMath.max(pair[1], pair[0]),
-Precision.EPSILON);
+assertEquals("min(" + pair[0] + ", " + pair[1] + ")",
+Math.min(pair[0], pair[1]),
+