[ODE] dInfinity

[Russ Smith]

> 1) How do we properly integrate the bizarreness of configure.exe
> into the premake process?  Its noodling goes beyond the usual
> endianness checking and whatnot into realms that can't really be
> justified as belonging in Premake, such as the wacky dInfinity
> detection

speaking of dInfinity ... i think it was a bad idea to make dInfitity
equal to the real infinity. i think that it could probably just be set
to ReallyLargeNumber. here's my reasoning:

  * it's only really used inside the LCP solver as a way of specifying
    that a constraint force should not be limited. the only property
    that infinity is required to have is that its bigger than the other
    numbers.

  * it's a constant source of build hassles: it's hard to put the
    infinity constant into a header file in a portable way, so i exposed
    a public variable that contains the value - this must be exported,
    and when you start using DLLs or .sos it's annoying.

  * similarly, the configurator must detect how to represent the
    infinity on each platform ... you're right, this is a bizzare
    process and a total mess IMO.

  * some IEEE754 platforms raise exceptions when dealing with infinity,
    and this behavior might be hard to configure out.

  * some platforms have floating point arithmetic that is only partially
    IEE754 compliant. such platforms might not have infinity anyway.
    this is not a problem now (at least not for me), but it could be in
    the future.

so here's what i'll do: change the value of dInfinity to be the largest
representable IEEE754 number for the current dReal, and i'll remove all
the configure and make oddities that surround it.

one consequence is that now dInfinity will be subject to arithmetic, so
for example dInfinity/2 will be different from dInfinity ... but it your
program relies on arithmetic on infinity then you're probably doing
something wrong anyway.

any objections or other thoughts?

russ.

-- 
Russell Smith
http://www.q12.org