Re: [xml] XPath fix

[Bjorn Reese <breese mail1 stofanet dk>]

Daniel Veillard wrote:
> On Fri, Mar 22, 2002 at 04:34:25PM -0000, Cyberthymia wrote:

> > 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.

Right, let's not vade through that mire again.

> > 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.

Actually, the IEEE committee did put a considerable amount of thought
into this topic. There are pros and cons. For example a signed zero
will uphold the identity 1/(1/x) = x, even when x is positive or
negative infinity, but it will break relation x = y <=> 1/x = 1/y
when x = +0 and y = -0.

A signed zero is advantageous for discontinuous functions and for
complex numbers. The logarithm is a good example of the former.
Usually we define log(x) to be NaN for x < 0, and negative infinity
for x = 0. If x is an expression which is negative, but due to
underflow becomes zero, then we get negative infinity instead of NaN.

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

This is a bit (pun intended) difficult as -0 equals +0. The best
solution may be to examine the sign bit directly if IEEE 754 is used
(trio_nan.c can give you an idea about how this can be done -- in
fact, it may be a good candidate function for trio_nan).

> > 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

Even better, fmod() is ANSI C90 (possibly even C89, but I don't have
that lying around).