Re: [xml] XPath fix



I've found another couple of problems with float, round and ceil.
floor(-5.2) returns -5 instead of -6
ceiling(-5.2) returns -4 instead of -5
round(-5.6) returns -5 instead of -6
I've had a look at the code in xpath.c that does this maths
(xmlXPathFloorFunction(), etc) and what I thought would have been the
correct fix (by using the real C functions) in all 3 cases has been "#if
0"'d out and replaced by approximations doing wierd things with casts.
This is probably a silly question, but was there a specific issue caused
by
using the C functions that stopped them from working?

  Looked at it, I wonder if I didn't do this to avoid using the
functions from the math library when avoidable. Weird casts are
a sign of ownership ... it seems I forgot about negative values though :-)

  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
that I'll dust off my maths course notes and knock up a corrected hand-coded
alternative on Monday.

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

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

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.
Obviously, I only know that this works on VC6, but where we've done similar
things on our own Linux
build (using gcc2.95.3), we haven't had any problems so far. I'll look into
reworking the if statement later.

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?

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?

Thanks,
Richard


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com




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