Re: NetBSD math asinf() Issue

[Woodchuck <marmot%pennswoods.net@localhost>]

On Fri, Sep 18, 2009 at 2:46 AM, Channa <channa.kad%gmail.com@localhost> wrote:

>> Caution, this account is hosted by gmail.
>> Strangers scan the content of all mail transiting such accounts.
>
> Yes, in the NetBSD implementation if asinf(x) where x > 1 the function
> __kernel_standard is called which fills the return value as zero as
> below:
>
> $ cat lib/libm/src/k_standard.c
> :
> :
>            case 102:
>                /* asin(|x|>1) */
>                exc.type = DOMAIN;
>                exc.name = type < 100 ? "asin" : "asinf";
>                exc.retval = zero;                             <------- HERE
>                if(_LIB_VERSION == _POSIX_)
>                  errno = EDOM;
>                else if (!matherr(&exc)) {
>                  if(_LIB_VERSION == _SVID_) {
>                        (void) WRITE2("asin: DOMAIN error\n", 19);
>                  }
>                  errno = EDOM;
>                }
>                break;

Yes, identical code.
 :
>
> As mentioned in the label 'HERE'
>
> The behavior for sinf() is by specification i.e implementation defined.
> In GNU C libraries NAN is returned.

Are you certain these are at the same level of C standard ('89 vs '99)?

If the standards body (ISO/IEEE) say the return value is implementation
defined, then it is "free".  So *BSD is compliant.

> I am not sure if this is the correct behavior expected by applications.

Big smiley:  I'm not sure all applications have reasonable expectations.

> Let me know your views on this.

It looks like the right thing to do is check errno, not the return value.

My general view is that floating point is a mess and has been for as
long as I've used it (30+ years).   I "grew up" expecting my applications
to dump core for any fp error (/0, sqrt(<0), 0/0, asin(>1), and so on)
and for integer under and overflows, and to generate messages about
loss of precision.  (This would be on old IBM mainframes, and then Vaxes).
I liked this: it kept programmers honest and careful, and defensive.  Then
came this NaN and Inf stuff, and the loathsome possibility of treating
them, by default, as something fit for further computation.  I'm retired now,
but I see some recent scientific/engineering software from time to time, and
some of it just blithely ignores these events.  And I don't think there's a
good portable way (yet) to trap them.  Just setting up a signal catcher
on *BSD and then wanting to port to Linux (which, alas, is used on many
important sci-eng installations) generates headaches.  And sci-eng software
lives forever.... we are still running 40 year old fortran, and for good reason.

So I will keep hoping for a standard that makes sense, is portable, has no
more of these "implementation dependencies", and is enforced at gunpoint.

In the meantime, we are stuck with autoconf, and/or junk like
 "#ifdef SYSV" and related stuff; there seems to be no way around it.

In this case, I'd say, briefly: now that we've seen the source code, check
errno.  If you need the NaN behavior for some app, write a wrapper.   It's
pretty much a one liner/inliner:

float myasinf(float x) {return fabs(x)>1,? (x-x)/(x-x): asinf(x); }

sorry for the ranting, and I hope to have helped some.

Dave

> Thanks & Regards,
> Channa
>



-- 
Caution, this account is hosted by gmail.
Strangers scan the content of all mail transiting such accounts.