Re: [avr-libc-dev] Bug in math library

[Paul Schlie]

Sorry, (now with corrected range limits, for what it may be worth):

  1 = (+0 -> +inf)*(+inf -> +0) = (+2^-127 -> +2^+127)*(+2^+127 -> +2^-127)

    = (+0 -> +inf)/(+0 -> +inf) = (+2^-127 -> +2^+127)/(+2^-127 -> +2^+127)


> From: Paul Schlie <address@hidden>
> Date: Sun, 09 Jan 2005 00:01:53 -0500
> To: <address@hidden>, Marek Michalkiewicz <address@hidden>
> Cc: <address@hidden>
> Subject: Re: [avr-libc-dev] Bug in math library
> 
> exp = 0 is a sufficient zero test if demoralized numbers aren't supported,
> (which seem like a reasonable simplifying assumption for avr applications)
> 
> As an aside, it may be worth considering that it's likely beneficial to
> further simplify avr's implementation by simply treating +/- 0, +/- inf
> more simply and consistently as the non-accumulating bounds of otherwise
> normally represented values, thereby eliminating the arithmetic and algebraic
> anomalies otherwise introduced, which typically then require
> checking to transform the computed results into useful values, which as
> it's often never done comprehensively, often results in latent bugs in
> embedded applications, which typically don't simply print out results for
> a human to read, and typically never expect sticky +/-inf, or NAN behaviors or
> results.
> 
> Alternatively by defining: +/-0 = +/-2^-127, +/-inf = +/-2^-127
> 
>   (+inf -> +0 -> -0 -> -inf) =  1/(+0 -> +inf -> -inf -> -0)
> 
>   x = x + +/-0, +inf = +inf + (x : x >= -0), -inf = -inf - (x : x >= -0)
> 
> Some interesting simplifying useful properties result:
> 
>   1 = (+0 -> +inf)*(+inf -> +0) = (+2^-127 -> +2^+127)*(+2^-127 -> +2^+127)
> 
>     = (+0 -> +inf)/(+0 -> +inf) = (+2^-127 -> +2^+127)/(+2^+127 -> +2^-127)
> 
> Thereby 0/0 = 1, not NAN, as although 0/X is thought of as being 0, as 0
> becomes divided by an increasingly smaller, or multiplied by an increasingly
> larger value, the result approaches 1 as the value reaches it's respective
> reciprocal bounds.  Finally by defining that functions returning a float will
> return the real component of the result value, all operations on floats become
> well defined, and never yield NAN. (including typical examples of square-root
> of a negative number, which would then more conveniently yield 0, not NAN; as
> it there was an interest in checking for negative square roots for example, it
> should be done prior to it's call, not afterward, etc.)
> 
> 
>> From: Colin O'Flynn <address@hidden>
>> Organization: NewAE
>> Reply-To: <address@hidden>
>> Date: Sat, 8 Jan 2005 17:46:14 -0400
>> To: Marek Michalkiewicz <address@hidden>
>> Cc: <address@hidden>
>> Subject: Re: [avr-libc-dev] Bug in math library
>> 
>>> Not necessary - already sent there (see Cc: in headers).
>> 
>> Oh - guess my mail client screwed up, don't see the CC's.
>> 
>> Anyway the other thing I thought of - if the hidden bit is set when zero
>> detected, it might be easier to just check for 0x01 being present in that
>> register.
>> 
>> However it is that sort of thing that will probably get broken in the
>> future... to be completely safe I would need to do this:
>> 
>>     clr     __tmp_reg__
>>     OR      __tmp_reg__, rB2
>>     OR      __tmp_reg__, rB1
>>     OR      __tmp_reg__, rB0
>> 
>> Then the Z flag would be set if all those registers are zero. It is an
>> increase from 1 to 4 instructions.
>> 
>> Regards,
>> 
>>  -Colin
>> 
>> _______________________________________________
>> AVR-libc-dev mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev