On Fri, 19 Oct 2001, Mark A. Belonga wrote:
> Looking into it a bit more, this is only part of the problem. There's also
> the implicit representation of numbers. For example:
>
> 4 < 12.0
>
> Will throw a ClassCastException too, since the 4 is made into an Integer and
> 12.0 into a double.
>
> But if we convert everything to Doubles all the time, then we get messiness
> like:
>
> 1 + 1 = 2.0
>
> Which isn't what we want.
Technically, this is all that is required by the XPath spec:
| A number represents a floating-point number. A number can have any
| double-precision 64-bit format IEEE 754 value [IEEE 754]. These include
| a special "Not-a-Number" (NaN) value, positive and negative infinity,
| and positive and negative zero. See Section 4.2.3 of [JLS] for a summary
| of the key rules of the IEEE 754 standard.
You could store it as a Long (Integer is tricky since it doesn't have a
big-enough range; and even if Long is used, it must only be used for
Long.MIN_VALUE <= number <= Long.MAX_VALUE. Smaller or bigger numbers
can't be precisely represented as a double either, but it should be
possible to parse them -- very tricky to get exactly right)
But when in numeric operations, one operand should be promoted to
double if the other is a double, and also when the result of the operation
would be out-of-range for a Long (if you want to be compliant)
> I'm beginning to think that we should just wrap the numbers into Doubles
> when we do the compareTo, and leave everything as it was all other times. Is
> that more acceptable?
It's probably acceptable in most cases. But out-of-range cases are also
possible with addition, division and the other math operations. It could
lead to surprising results.
- Erwin
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
