Sanford Whiteman created VELTOOLS-182:
-----------------------------------------
Summary: MathTool.max longtime bug with args (0,0)
Key: VELTOOLS-182
URL: https://issues.apache.org/jira/browse/VELTOOLS-182
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 2.0
Reporter: Sanford Whiteman
It appears that {{$math.max}} has had a bug since at least 2.0, or at least I'm
at a loss as to why the observed behavior would be expected, and it doesn't
appear to be documented.
{code:java}
$math.max(0,0) {code}
returns
{code:java}
4.9E-324{code}
that is, Double.MIN_VALUE.
It's easy to see why in the source. Using
[3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
here, we see:
{code:java}
public Number max(Object... nums)
{
double value = Double.MIN_VALUE;
Number[] ns = new Number[nums.length];
for (int i=0; i<nums.length; i++)
{
Number n = toNumber(nums[i]);
if (n == null)
{
return null;
}
value = Math.max(value, n.doubleValue());
ns[i] = n;
}
return matchType(value, ns);
}
{code}
So rather than delegating to {{Java.lang.Math.max}} directly, each iter takes
the {{Math.max}} of the current value and Double.MIN_VALUE. Ergo, if the
arguments are 0, that's always < Double.MIN_VALUE, so the result is in turn
Double.MIN_VALUE.
The same goes for {{$math.min(0)}} (just one arg) but at least that could be
considered a usage error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
