Re: [xml] XPath fix

[Daniel Veillard <veillard redhat com>]

On Fri, Mar 22, 2002 at 04:34:25PM -0000, Cyberthymia wrote:
> >   Apparently I got burned by a problem with floor() as a comment
> > indicates : "floor(0.999999999999) => 1.0 !!!!!!!!!!!"
> > and decided to bypass it using direct cast to implement the right
> > semantic.
> >
> > The enclosed patch tries to fix this, could you build a test file
> > like the others in test/XPath/expr/ testings those 3 functions and
> > raise errors if there is still some to fix,
> >
> 
> The patch does fix the problem as specified, but doesn't handle the wierd
> +0 / -0 numbers properly.
> e.g. round(-0.4) returns (+)0 instead of -0
> It might just be safer to try using the proper functions if poss. Failing

  Unfortunately, no. Sometime this will work, but on platform X Y or Z
it's gonna die horriby.

> that I'll dust off my maths course notes and knock up a corrected hand-coded
> alternative on Monday.

  That's really the path I prefer, I would agree it's bloat if I didn't
targetted to be very portable, but unfortunately each time one trust 
the underlying libc to do the right thing it just break a few month later
on a differnt platorm in a different case (last time it was snprintf
which bite me).

> On a similar note: (Sorry for opening this can of worms... What kind of
> number is -0 anyway? ;-) )

  An exageration ? From a mathematical point of view it shall be the
limit of 0 - epsilon when epsilon -> 0 , but unfortunately this converges
to 0 and it should be 0 :-( . Yo me it sounds the IEEE guys had a bit 
to flip and decided to give a different meaning to both value in a context
where it should not have.
  Okay people doing math probably hates me by now. Not a big deal, XPath
is not designed to do maths.

> The XPath spec section 4.2 says that Positive Infinity should be "Infinity"
> not "+Infinity"
>   Easy enough change - Lines 586, 1117, 1118, 3134

  Okay, I let you produce the patch ?

> The div function ( xmlXPathDivValues() ) doesn't handle -0 correctly -
> 1 div -0 should return -Infinity, not Infinity
> -1 div -0 should return Infinity, not -Infinity
> The best fix I could come up with is as follows:
> In xmlXPathDivValues(), remove the "if (val==0) {...} else" [lines 4683 -
> 4690],
> so that the division happens in all cases, and let the C compiler handle it
> correctly.

  No it breaks each time the libc support fails one div by 0

> build (using gcc2.95.3), we haven't had any problems so far. I'll look into
> reworking the if statement later.

  I have no idea how to distinguish -0 from +0 at the C level, someone has
an idea ?

> Another one I'm investigating is NaN comparisons, e.g.
> 0 div 0 = 0 div 0 (returns true, expected false)
> 0 div 0 != 0 div 0 (returns false, expected true)
> 0 div 0 > 0 div 0 (returns false)
> 0 div 0 < 0 div 0 (returns true, expected false)
> 0 div 0 >= 0 div 0 (returns false)
> 0 div 0 <= 0 div 0 (returns true, expected false)
> 'a' = 0.0 (returns true, expected false)
> 'a' != 0.0 (returns true, expected false)
> 0.0 = 'a' (returns true, expected false)
> 0.0 != 'a' (returns true, expected false)
> It's getting a little too close to home time to start doing much with this
> one tonight, so I'll report back on Monday.
> 
> I've made up a couple of test files containing some of the tests I've been
> running in our product to cover the special cases uncovered so far. Do I
> need to do anything with them, or do you just want the plain text files sent
> to you?

  Well if you simply run testXPath on them and check the result
It should generate results like in result/XPath/expr

> One last thing, wrt the mod problem (5.46 mod 2.6), is fmod() a standard
> POSIX C function / one you'd be happy using, or shall I do a hand-coded one
> for this as well?

  <grin/> I would like to be able to trust it ... it's dangerous.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/