Re: [xml] XPath fix



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/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]