Re: [xml] XPath fix

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

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