Re: [xml] XPath fix

[Bjorn Reese <breese mail1 stofanet dk>]

Cyberthymia wrote:
> Daniel wrote:
> > > As a heads up, I'm working on a fix for one of the number expressions -
> > > libxml returns 1 for the expression "5.46 mod 2.6". Apparently, according
> to
> > > the xsl-list, it should return "0.26" (Something to do with Java doing
> > > floating point mods, C only doing integer mods).

The C % operator uses integer arithmetic, the C fmod() function uses
floating-point (and yields 0.26 in the above example).

> >  Section 3.5 of the XPath spec states:
> >    "This is the same as the % operator in Java and ECMAScript."
> >    "This is not the same as the IEEE 754 remainder operation,
> >     which returns the remainder from a rounding division."
> >
> > So they may be right, I hate those parts where XPath/XSLT relies on Java
> > for the semantic of operations, it is usually a mess.

Especially when they require IEEE 754 complicancy in some situations
(e.g. NaN) but not in others.

> That bit confused the heck out of me - so does that imply that Java doesn't
> do IEEE 754 floating point numbers properly?

According to the Java Language Specification (section 15.17.3)

<quote>
  The result of a floating-point remainder operation as computed by
  the % operator is not the same as that produced by the remainder
  operation defined by IEEE 754. The IEEE 754 remainder operation
  computes the remainder from a rounding division, not a truncating
  division, and so its behavior is not analogous to that of the usual
  integer remainder operator. Instead, the Java programming language
  defines % on floating-point operations to behave in a manner
  analogous to that of the integer remainder operator; this may be
  compared with the C library function fmod. The IEEE 754 remainder
  operation may be computed by the library routine Math.IEEEremainder.
</quote>