Arithmetic properties of HUGE_VAL and errno

[pete]

On my system, the following five expressions are true:

(HUGE_VAL == HUGE_VAL / 2)
(1 / HUGE_VAL == 0)
(sqrt(HUGE_VAL) == HUGE_VAL)
(sqrt(-1) == HUGE_VAL)
(sqrt(-HUGE_VAL) == HUGE_VAL)

and

sqrt(HUGE_VAL) doesn't set errno, but sqrt(-1) and sqrt(-HUGE_VAL) do.

Does that all seem right?

--
pete

[robertwessel2]

pete wrote:

On my system, the following five expressions are true:

(HUGE_VAL == HUGE_VAL / 2)
(1 / HUGE_VAL == 0)
(sqrt(HUGE_VAL) == HUGE_VAL)
(sqrt(-1) == HUGE_VAL)
(sqrt(-HUGE_VAL) == HUGE_VAL)

and

sqrt(HUGE_VAL) doesn't set errno, but sqrt(-1) and sqrt(-HUGE_VAL) do.

Does that all seem right?

Your implementation apparently defines HUGE_VAL as a positive infinity,
which is legitimate. All the rest flows pretty obviously from there.

[Martin Ambuhl]

pete wrote:

On my system, the following five expressions are true:

(HUGE_VAL == HUGE_VAL / 2)
(1 / HUGE_VAL == 0)
(sqrt(HUGE_VAL) == HUGE_VAL)
(sqrt(-1) == HUGE_VAL)
(sqrt(-HUGE_VAL) == HUGE_VAL)

and

sqrt(HUGE_VAL) doesn't set errno, but sqrt(-1) and sqrt(-HUGE_VAL) do.

Does that all seem right?

If HUGE_VAL and HUGE_VALF are INFINITY, as they are in my
implementation, that would explain much. Your question has led me to
discover that HUGE_VALL is broken on my implementation (it is an
unnormalized NaN).

[Eric Sosman]

Martin Ambuhl wrote:

If HUGE_VAL and HUGE_VALF are INFINITY, as they are in my
implementation, that would explain much. Your question has led me to
discover that HUGE_VALL is broken on my implementation (it is an
unnormalized NaN).

An "unnormaliz ed" NaN? I'm having trouble with
the concept; can you explain in more detail?

--
Eric Sosman
es*****@acm-dot-org.invalid

[pete]

ro***********@y ahoo.com wrote:

pete wrote:

On my system, the following five expressions are true:

(HUGE_VAL == HUGE_VAL / 2)
(1 / HUGE_VAL == 0)
(sqrt(HUGE_VAL) == HUGE_VAL)
(sqrt(-1) == HUGE_VAL)
(sqrt(-HUGE_VAL) == HUGE_VAL)

and

sqrt(HUGE_VAL) doesn't set errno,
but sqrt(-1) and sqrt(-HUGE_VAL) do.

Does that all seem right?

Your implementation apparently
defines HUGE_VAL as a positive infinity,
which is legitimate. All the rest flows pretty obviously from there.

Thank you. I have more questions.
What other options are there besides positive infinity?
Could sqrt(HUGE_VAL) be undefined?
Is it allowed for sqrt(HUGE_VAL) to set errno to errange
if it returns HUGE_VAL?
Are any of the above 5 expressions
guaranteed to be true by the standard,
or is it merely the case that they are allowed to be true?

Suppose I want to write a 100% portable function for C89 and C99
that does exactly what log2 does. Could it be written this way?:

double l_og2(double x)
{
return log(x) / log(2);
}

The point being, Can I really on any funky values like HUGE_VAL,
which might be returned by log(x),
to not be altered by being divided by log(2)?
Or would this be more portable?:

double l_og2(double x)
{
return x > 0 && DBL_MAX >= x ? log(x) / log(2) : log(x);
}
It seems that most settings of errno to ERANGE are optional,
but for exp, it says that you do get them when the magnitude of x
is too large, not x, but the magnitude of x.
Is setting errno to ERANGE optional or mandatory for exp(-DBL_MAX)?
I think it would be a case of underflow.
On a system like mine, where HUGE_VAL is an infinity,
Is setting errno to ERANGE optional or mandatory for exp(-HUGE_VAL)?

--
pete

[pete]

pete wrote:

errange

I meant ERANGE.

--
pete

[kuyper]

pete wrote:

ro***********@y ahoo.com wrote:

pete wrote:

On my system, the following five expressions are true:

(HUGE_VAL == HUGE_VAL / 2)
(1 / HUGE_VAL == 0)
(sqrt(HUGE_VAL) == HUGE_VAL)
(sqrt(-1) == HUGE_VAL)
(sqrt(-HUGE_VAL) == HUGE_VAL)

and

sqrt(HUGE_VAL) doesn't set errno,
but sqrt(-1) and sqrt(-HUGE_VAL) do.

Does that all seem right?
Your implementation apparently
defines HUGE_VAL as a positive infinity,
which is legitimate. All the rest flows pretty obviously from there.

Thank you. I have more questions.
What other options are there besides positive infinity?

HUGE_VAL is required to expand into a positive double constant
expression (7.12p3). However, the C standard places no other
requirements on it, unless __STDC_IEC_559_ _ is #defined by the
implementation, in which case it's required to expand into an
expression with a value of positive infinity (F.9p2). As far as I can
see, if __STDC_IEC_559_ _ is not #defined, then it would be perfectly
legal to #define HUGE_VAL as DBL_MIN.
Could sqrt(HUGE_VAL) be undefined?
HUGE_VAL must be positive, and there's no positive number for which
sqrt() is undefined.
Is it allowed for sqrt(HUGE_VAL) to set errno to errange
if it returns HUGE_VAL?
According to 7.5p3, "The value of errno may be set to nonzero by a
library function call whether or not there is an error, provided the
use of errno is not documented in the description of the function in
this International Standard."

I could find no mention of errno in 7.12.7.5, which describes sqrt(),
so errno can be set to anything it wants. I'm not sure if that's the
intent; other parts of 7.12 describe the setting of errno in contexts
that apply to sqrt() - but that's not "in the description of the
function".

In particular, errno must be set to ERANGE if sqrt(HUGE_VAL) overflows
and math_errhandlin g & MATH_ERRNO is true. sqrt(HUGE_VAL) will
overflow, if and only HUGE_VAL is positive infinity.
Are any of the above 5 expressions
guaranteed to be true by the standard,
or is it merely the case that they are allowed to be true?
None of them are required by the standard unless __STDC_IEC_559_ _ is
#defined, in which case they are required in order to conform with IEC
559.
Suppose I want to write a 100% portable function for C89 and C99
that does exactly what log2 does. Could it be written this way?:

double l_og2(double x)
{
return log(x) / log(2);
}

The point being, Can I really on any funky values like HUGE_VAL,
which might be returned by log(x),
to not be altered by being divided by log(2)?
No.
Or would this be more portable?:

double l_og2(double x)
{
return x > 0 && DBL_MAX >= x ? log(x) / log(2) : log(x);
}
That looks good to me; but I might have missed some tricky detail.
It seems that most settings of errno to ERANGE are optional,
As, for instance, whenever 7.12p3 applies.
but for exp, it says that you do get them when the magnitude of x
is too large, not x, but the magnitude of x.
Is setting errno to ERANGE optional or mandatory for exp(-DBL_MAX)?
I think it would be a case of underflow.
On a system like mine, where HUGE_VAL is an infinity,
Is setting errno to ERANGE optional or mandatory for exp(-HUGE_VAL)?

If math_errhandlin g & MATH_ERRNO is true, then setting ERANGE is
mandatory for overflows and for cases where the exact value of a
function is infinite (7.12.1p4).

[Fred J. Tydeman]

pete wrote:

On my system, the following five expressions are true:

(HUGE_VAL == HUGE_VAL / 2)
(1 / HUGE_VAL == 0)
(sqrt(HUGE_VAL) == HUGE_VAL)
Those are true if HUGE_VAL is +infinity (which it will be if IEEE-754
floating-point is being used).
(sqrt(-1) == HUGE_VAL)
(sqrt(-HUGE_VAL) == HUGE_VAL)
Those should be false. sqrt(negative) should be a NaN (Not-a-Number)
if IEEE-754 style floating-point is supported. And a NaN does not
compare equal to anything. In the general case, a domain error can
return any value, so +infinity is allowed.
and

sqrt(HUGE_VAL) doesn't set errno, but sqrt(-1) and sqrt(-HUGE_VAL) do.

Those are correct.
---
Fred J. Tydeman Tydeman Consulting
ty*****@tybor.c om Testing, numerics, programming
[phone] Vice-chair of J11 (ANSI "C")
Sample C99+FPCE tests: http://www.tybor.com
Savers sleep well, investors eat well, spenders work forever.

[pete]

ro***********@y ahoo.com wrote:

pete wrote:

On my system, the following five expressions are true:

(HUGE_VAL == HUGE_VAL / 2)
(1 / HUGE_VAL == 0)
(sqrt(HUGE_VAL) == HUGE_VAL)
(sqrt(-1) == HUGE_VAL)
(sqrt(-HUGE_VAL) == HUGE_VAL)

and

sqrt(HUGE_VAL) doesn't set errno,
but sqrt(-1) and sqrt(-HUGE_VAL) do.

Does that all seem right?

Your implementation apparently
defines HUGE_VAL as a positive infinity,
which is legitimate. All the rest flows pretty obviously from there.

Thank you.

--
pete

[pete]

Fred J. Tydeman wrote:

pete wrote:

On my system, the following five expressions are true:

(HUGE_VAL == HUGE_VAL / 2)
(1 / HUGE_VAL == 0)
(sqrt(HUGE_VAL) == HUGE_VAL)

Those are true if HUGE_VAL is +infinity (which it will be if IEEE-754
floating-point is being used).

(sqrt(-1) == HUGE_VAL)
(sqrt(-HUGE_VAL) == HUGE_VAL)

Those should be false. sqrt(negative) should be a NaN (Not-a-Number)
if IEEE-754 style floating-point is supported. And a NaN does not
compare equal to anything. In the general case, a domain error can
return any value, so +infinity is allowed.

and

sqrt(HUGE_VAL) doesn't set errno,
but sqrt(-1) and sqrt(-HUGE_VAL) do.

Those are correct.

Thank you.

For academic purposes,
I was hoping to be able to write a source code for a function sq_rt,
that would do exactly sqrt was supposed to do,
and have it be portable for C89 and C99.
Some standard functions like are easy to write like that,
like isdigit:

int is_digit(int c)
{
return c >= '0' && '9' >= c;
}

But, the math functions seem more complicated to write
portably because of the various macros in C99 which may
or may not be defined.

This is what I have so far:

double sq_rt(double x)
{
if (DBL_MAX >= x) {
if (x > 0) {
x = sqrt(x);
/*
** I've replaced my sqrt algortihm with the call to sqrt
** to simplify the appearence of the code
*/
} else {
if (0 > x) {
errno = EDOM;

#ifdef __STDC_IEC_559_ _
x = NAN;
#else
x = HUGE_VAL;
#endif

}
}
} else {
errno = ERANGE;
}
return x;
}

Does that seem about right?
Is this complicated enough enough
that I should try to acquire the standard for IEEE-754
if I want to do it right?
Followup set to c.l.c

--
pete