avr-libc-dev
[Top][All Lists]

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

 From: Paul Schlie Subject: Re: [avr-libc-dev] Bug in math library Date: Sun, 09 Jan 2005 00:11:14 -0500 User-agent: Microsoft-Entourage/11.1.0.040913

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

> Date: Sun, 09 Jan 2005 00:01:53 -0500
> 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.)
>
>
>> Organization: NewAE
>> Date: Sat, 8 Jan 2005 17:46:14 -0400
>> Subject: Re: [avr-libc-dev] Bug in math library
>>
>>
>> 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
>> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

```