using System;
|
using System.Collections.Generic;
|
using System.Text;
|
using HH.WMS.Utils.NPOI.Util;
|
|
namespace HH.WMS.Utils.NPOI.SS.Util
|
{
|
public class NumberComparer
|
{
|
/**
|
* This class attempts to reproduce Excel's behaviour for comparing numbers. Results are
|
* mostly the same as those from {@link Double#compare(double, double)} but with some
|
* rounding. For numbers that are very close, this code converts to a format having 15
|
* decimal digits of precision and a decimal exponent, before completing the comparison.
|
* <p/>
|
* In Excel formula evaluation, expressions like "(0.06-0.01)=0.05" evaluate to "TRUE" even
|
* though the equivalent java expression is <c>false</c>. In examples like this,
|
* Excel achieves the effect by having additional logic for comparison operations.
|
* <p/>
|
* <p/>
|
* Note - Excel also gives special treatment to expressions like "0.06-0.01-0.05" which
|
* evaluates to "0" (in java, rounding anomalies give a result of 6.9E-18). The special
|
* behaviour here is for different reasons to the example above: If the last operator in a
|
* cell formula is '+' or '-' and the result is less than 2<sup>50</sup> times smaller than
|
* first operand, the result is rounded to zero.
|
* Needless to say, the two rules are not consistent and it is relatively easy to find
|
* examples that satisfy<br/>
|
* "A=B" is "TRUE" but "A-B" is not "0"<br/>
|
* and<br/>
|
* "A=B" is "FALSE" but "A-B" is "0"<br/>
|
* <br/>
|
* This rule (for rounding the result of a final addition or subtraction), has not been
|
* implemented in POI (as of Jul-2009).
|
*
|
* @return <code>negative, 0, or positive</code> according to the standard Excel comparison
|
* of values <c>a</c> and <c>b</c>.
|
*/
|
public static int Compare(double a, double b)
|
{
|
long rawBitsA = BitConverter.DoubleToInt64Bits(a);
|
long rawBitsB = BitConverter.DoubleToInt64Bits(b);
|
|
int biasedExponentA = IEEEDouble.GetBiasedExponent(rawBitsA);
|
int biasedExponentB = IEEEDouble.GetBiasedExponent(rawBitsB);
|
|
if (biasedExponentA == IEEEDouble.BIASED_EXPONENT_SPECIAL_VALUE)
|
{
|
throw new ArgumentException("Special double values are not allowed: " + ToHex(a));
|
}
|
if (biasedExponentB == IEEEDouble.BIASED_EXPONENT_SPECIAL_VALUE)
|
{
|
throw new ArgumentException("Special double values are not allowed: " + ToHex(a));
|
}
|
|
int cmp;
|
|
// sign bit is in the same place for long and double:
|
bool aIsNegative = rawBitsA < 0;
|
bool bIsNegative = rawBitsB < 0;
|
|
// compare signs
|
if (aIsNegative != bIsNegative)
|
{
|
// Excel seems to have 'normal' comparison behaviour around zero (no rounding)
|
// even -0.0 < +0.0 (which is not quite the initial conclusion of bug 47198)
|
return aIsNegative ? -1 : +1;
|
}
|
|
// then compare magnitudes (IEEE 754 has exponent bias specifically to allow this)
|
cmp = biasedExponentA - biasedExponentB;
|
int absExpDiff = Math.Abs(cmp);
|
if (absExpDiff > 1)
|
{
|
return aIsNegative ? -cmp : cmp;
|
}
|
|
if (absExpDiff == 1)
|
{
|
// special case exponent differs by 1. There is still a chance that with rounding the two quantities could end up the same
|
|
}
|
else
|
{
|
// else - sign and exponents equal
|
if (rawBitsA == rawBitsB)
|
{
|
// fully equal - exit here
|
return 0;
|
}
|
}
|
if (biasedExponentA == 0)
|
{
|
if (biasedExponentB == 0)
|
{
|
return CompareSubnormalNumbers(rawBitsA & IEEEDouble.FRAC_MASK, rawBitsB & IEEEDouble.FRAC_MASK, aIsNegative);
|
}
|
// else biasedExponentB is 1
|
return -CompareAcrossSubnormalThreshold(rawBitsB, rawBitsA, aIsNegative);
|
}
|
if (biasedExponentB == 0)
|
{
|
// else biasedExponentA is 1
|
return +CompareAcrossSubnormalThreshold(rawBitsA, rawBitsB, aIsNegative);
|
}
|
|
// sign and exponents same, but fractional bits are different
|
|
ExpandedDouble edA = ExpandedDouble.FromRawBitsAndExponent(rawBitsA, biasedExponentA - IEEEDouble.EXPONENT_BIAS);
|
ExpandedDouble edB = ExpandedDouble.FromRawBitsAndExponent(rawBitsB, biasedExponentB - IEEEDouble.EXPONENT_BIAS);
|
NormalisedDecimal ndA = edA.NormaliseBaseTen().RoundUnits();
|
NormalisedDecimal ndB = edB.NormaliseBaseTen().RoundUnits();
|
cmp = ndA.CompareNormalised(ndB);
|
if (aIsNegative)
|
{
|
return -cmp;
|
}
|
return cmp;
|
}
|
|
/**
|
* If both numbers are subnormal, Excel seems to use standard comparison rules
|
*/
|
private static int CompareSubnormalNumbers(long fracA, long fracB, bool isNegative)
|
{
|
int cmp = fracA > fracB ? +1 : fracA < fracB ? -1 : 0;
|
|
return isNegative ? -cmp : cmp;
|
}
|
|
|
|
/**
|
* Usually any normal number is greater (in magnitude) than any subnormal number.
|
* However there are some anomalous cases around the threshold where Excel produces screwy results
|
* @param isNegative both values are either negative or positive. This parameter affects the sign of the comparison result
|
* @return usually <code>isNegative ? -1 : +1</code>
|
*/
|
private static int CompareAcrossSubnormalThreshold(long normalRawBitsA, long subnormalRawBitsB, bool isNegative)
|
{
|
long fracB = subnormalRawBitsB & IEEEDouble.FRAC_MASK;
|
if (fracB == 0)
|
{
|
// B is zero, so A is definitely greater than B
|
return isNegative ? -1 : +1;
|
}
|
long fracA = normalRawBitsA & IEEEDouble.FRAC_MASK;
|
if (fracA <= 0x0000000000000007L && fracB >= 0x000FFFFFFFFFFFFAL)
|
{
|
// Both A and B close to threshold - weird results
|
if (fracA == 0x0000000000000007L && fracB == 0x000FFFFFFFFFFFFAL)
|
{
|
// special case
|
return 0;
|
}
|
// exactly the opposite
|
return isNegative ? +1 : -1;
|
}
|
// else - typical case A and B is not close to threshold
|
return isNegative ? -1 : +1;
|
}
|
|
|
|
/**
|
* for formatting double values in error messages
|
*/
|
private static String ToHex(double a)
|
{
|
return "0x" + StringUtil.ToHexString(BitConverter.DoubleToInt64Bits(a)).ToUpper();
|
}
|
}
|
}
|
