After finding that same bit in the XPath spec, I'm now thinking that
everything should be stored as a Double. As suggested in the XSLT book by
Michael Kay, there's always round(), trim(), and ceiling() to be able to
convert to an Integer if you need one. But internally if we use Double
everywhere I think we'd be all set with all the comparisons. This means that
even when we round(), trim(), or ceiling(), we do that conversion and then
store it as a Double.
As far as the string() representation... I tested some conversions with
xalan, and they have the following conversion rules:
string( 1 ) = '1'
string( 1.0 ) = '1'
string( 1.1 ) = '1.1'
These seem reasonable to me.
Thoughts?
-Mark
----- Original Message -----
From: "Erwin Bolwidt" <[EMAIL PROTECTED]>
To: "Mark A. Belonga" <[EMAIL PROTECTED]>
Cc: "jaxen" <[EMAIL PROTECTED]>
Sent: Friday, October 19, 2001 12:42 PM
Subject: Re: Fw: [Jaxen] number()
>
>
> 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
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
