«

On 11/01/2010 08:46 PM, Keith Thompson wrote:
> James Kuyper<> writes:
>> On 10/30/2010 05:04 PM, Scouser wrote:
....
>>> They do that though, don't they?
>>
>> As I indicated above, their own "Further notes" say explicitly that they
>> do not. Those notes might be incorrect, but that is what they say.
>
> This "Scouser" has posted numerous followups in comp.lang.c with the
> same one-line comment. I don't think it means anything.

Thanks for the info. I hadn't seen those messages, so I didn't realize
that he was pointless.

writes:

>[snip]
>
> 5) Setting the floating-point flags is a side-effect, so it is
> undefined behaviour if it happens twice without an intervening
> sequence point.

Bad reasoning. It is undefined behavior to modify the stored
value of an object more than once between sequence points, but
that conclusion doesn't hold for side effects in general. The
floating-point flags are not objects; multiple modifications
may (or may not) be unspecified behavior, but as far as I know
there is nothing that causes it to be undefined behavior.

On 11/05/2010 01:50 AM, John Smith wrote:
> John Smith wrote:
>> James Kuyper wrote:
>
>>> [OT]
>>>> Cheers, james. I would ask you of your satellites.
>>>
>>> They're still flying, 5 and 3 years, respectively, after the end of
>>> their planned 5 year lifetimes, and with only minor degradation of
>>> their instruments.
>
>
> Can you provide a link again along with new data?

I don't know what this has to do with any of the newsgroups this is
being distributed to. Since you don't use a real e-mail address, the
only way I can reply is by usenet. In the future, please send any
similar inquiries via e-mail, not usenet.

General information: <http://terra.nasa.gov/>, <http://aqua.nasa.gov/>
Data (new and old): <http://terra.nasa.gov/Gallery/>,
<http://aqua.nasa.gov/science/images_data.php>

My particular responsibility is for the L1A, L1B, and geolocation
products from the MODIS <http://modis.gsfc.nasa.gov/> instruments on
those spacecraft. Those products may be obtained from LAADS
<http://ladsweb.nascom.nasa.gov/>, a fact which is mentioned on the
Terra data site listed above, but not on the Aqua data site.

I am not authorized to speak officially for my employer, nor for our
client, NASA. However, if you have any questions about any products
distributed through LAADS, you may send them to
or call 1-866-506-6347; questions that fall within my domain will be
redirected to me.

On 11/07/2010 03:26 AM, John Smith wrote:
> James Kuyper wrote:
>> On 10/28/2010 04:38 PM, glen herrmannsfeldt wrote:
>> ...
>>> Otherwise, it seems that one of the causes of unexpected floating
>>> point results is extended precision intermediate values in the x87.
>>> Keeping more precision for intermediate results should, in the
>>> end, give more accurate answers. The combination of optimizing
>>> compilers (common subexpression elimination, and keeping results
>>> in registers as long as possible) and x87 results in uncertain
>>> precision in intermediate values.
>>
>> Which is precisely the point of the following new features in C99:
>>
>> FLT_EVAL_METHOD macro
>> float_t, double_t types
>> STDC FP_CONTRACT pragma
>>
>> The macro allows you to find out whether the results of intermediate
>> operations might be evaluated at higher precision. The types
>> correspond to the intermediate types that might be used, and the
>> pragma makes it possible to disallow such optimizations, if your need
>> for more consistent results is greater than your need for improved
>> accuracy.
>
> How is the middle one a macro?

The phrase "the middle one" could have several possible meanings, but I
can't figure out how to interpret it as applying to FLT_EVAL_METHOD,
which was the only thing that I identified as being a macro. However, I
believe that it's possible to implement float_t and double_t either as
typedefs or macros. Or, for that matter, as macros that expand to
typedef names, though that would be pointlessly complicated.

In article <ib619n$2dv$>,
James Kuyper <> wrote:
>On 11/07/2010 03:26 AM, John Smith wrote:
>> James Kuyper wrote:
>>> On 10/28/2010 04:38 PM, glen herrmannsfeldt wrote:
>>> ...
>>>> Otherwise, it seems that one of the causes of unexpected floating
>>>> point results is extended precision intermediate values in the x87.
>>>> Keeping more precision for intermediate results should, in the
>>>> end, give more accurate answers. The combination of optimizing
>>>> compilers (common subexpression elimination, and keeping results
>>>> in registers as long as possible) and x87 results in uncertain
>>>> precision in intermediate values.
>>>
>>> Which is precisely the point of the following new features in C99:
>>>
>>> FLT_EVAL_METHOD macro
>>> float_t, double_t types
>>> STDC FP_CONTRACT pragma
>>>
>>> The macro allows you to find out whether the results of intermediate
>>> operations might be evaluated at higher precision. The types
>>> correspond to the intermediate types that might be used, and the
>>> pragma makes it possible to disallow such optimizations, if your need
>>> for more consistent results is greater than your need for improved
>>> accuracy.
>>
>> How is the middle one a macro?
>
>The phrase "the middle one" could have several possible meanings, but I
>can't figure out how to interpret it as applying to FLT_EVAL_METHOD,
>which was the only thing that I identified as being a macro. However, I
>believe that it's possible to implement float_t and double_t either as
>typedefs or macros. Or, for that matter, as macros that expand to
>typedef names, though that would be pointlessly complicated.

I am changing the followup line to remove comp.lang.fortran,
which is the only one of the groups I am following, but am going to
respond.

What you have posted was, indeed, the intent of the committee. It
is not, however, what the C99 standard says. Like so much else of
C99 (and a lot of C90), none of those facilities are usable in even
remotely portable code because only their syntax and intent is
defined by the standard - their semantics are, at most, implementation-
defined and more often unspecified or even undefined. And, yes, I
DO mean that using them is arguably undefined behaviour.

FLT_EVAL_METHOD is unclear which operations it controls, and exactly
when it applies (given that constant and dynamic evaluation are not
required to be identical). It is also permitted to be set to -1,
and there are no specified constraints involving __STDC_IEC_559__
or FP_CONTRACT or CX_LIMITED_RANGE.

The float_t and double_t types are likely to be macros, because
7.12#2 states that they ARE built-in types for some values of
FLT_EVAL_METHOD. That is incompatible with using typedefs for them
in those cases. Also, unless FLT_EVAL_METHOD is 0, 1 or 2, they
have no connexion with expression evaluation.

God alone knows what FP_CONTRACT means (let alone CX_LIMITED_RANGE)
because there is no specification of how expressions are evaluated
other than the "as if" rule, though many people will read Annex F
to imply that there is. But, in any case, that applies only if
both __STDC_IEC_559__ is 1 and pragma FENV_ACCESS is on.

As someone who has a lot of experience with numerical portability and
reliability, stretching over four decades and dozens of very different
systems, my advice to anyone concerned with those is not to touch
the new features of C99 with a bargepole. Write clean, portable
code and don't rely on compiler-, hardware- and system-dependent
facilities.


Regards,
Nick Maclaren.

On 11/07/2010 06:57 AM, wrote:
....
> I am changing the followup line to remove comp.lang.fortran,
> which is the only one of the groups I am following, but am going to
> respond.
>
> What you have posted was, indeed, the intent of the committee. It
> is not, however, what the C99 standard says. Like so much else of
> C99 (and a lot of C90), none of those facilities are usable in even
> remotely portable code because only their syntax and intent is
> defined by the standard - their semantics are, at most, implementation-
> defined and more often unspecified or even undefined. And, yes, I
> DO mean that using them is arguably undefined behaviour.
>
> FLT_EVAL_METHOD is unclear which operations it controls,

5.2.4.2.2p8 seems pretty clear: "operations with floating operands and
values". Can you come up with any argument, from the text of the
standard, why it should not apply to every "operation with floating
operands and values", or why it should apply to any operations that
don't fit that description? It doesn't have to be a great argument; just
good enough to justify your asserting that there's a lack of clarity.
Alternatively, identify a case where it's unclear whether or not that
description applies. I'm not saying that there are no such cases; only
that I can't think of any, and it would clarify the nature of your
complaint if I had an example to think about.

> ... and exactly
> when it applies (given that constant and dynamic evaluation are not
> required to be identical). ...

Nonetheless, 5.2.4.2.2p8 makes it quite clear that values 0, 1 and 2 all
identify behavior which covers constants as well as operations.

> ... It is also permitted to be set to -1,

So? Are you worse off having a way of knowing that the float evaluation
method is indeterminable than you would be if you didn't have any way to
determine that fact?

> and there are no specified constraints involving __STDC_IEC_559__
> or FP_CONTRACT or CX_LIMITED_RANGE.

> The float_t and double_t types are likely to be macros, because
> 7.12#2 states that they ARE built-in types for some values of
> FLT_EVAL_METHOD. That is incompatible with using typedefs for them
> in those cases. Also, unless FLT_EVAL_METHOD is 0, 1 or 2, they
> have no connexion with expression evaluation.

So? If FLT_EVAL_METHOD is 0, 1, or 2, there is a connection, which seems
somewhat useful to me. Having that connection, and being able to
determine what that connection is and whether it even exists, all seem
fairly useful. I don't see how having those features makes things worse
than when they didn't exist. At worst, FLT_EVAL_METHOD == 1, and you
have a way of finding out that out; which is slightly better than
knowing nothing at all about such issues.

> God alone knows what FP_CONTRACT means (let alone CX_LIMITED_RANGE)
> because there is no specification of how expressions are evaluated
> other than the "as if" rule, though many people will read Annex F
> to imply that there is. But, in any case, that applies only if
> both __STDC_IEC_559__ is 1 and pragma FENV_ACCESS is on.

So, it does have a meaning when __STDC_IEC_559__ is 1 and FENV_ACCESS is
on? How does the existence of the FP_CONTRACT, __STDC_IEC_559__ and
FENV_ACCESS features make the situation worse than when you had no way
of ever determining, from within your code, whether or not that meaning
applied?

> As someone who has a lot of experience with numerical portability and
> reliability, stretching over four decades and dozens of very different
> systems, my advice to anyone concerned with those is not to touch
> the new features of C99 with a bargepole. Write clean, portable
> code and don't rely on compiler-, hardware- and system-dependent
> facilities.

C99 provides ways of determining whether certain compiler-, hardware-,
and system-dependent facilities are supported. Why shouldn't code use
those facilities when they are supported, and choose an appropriate
fall-back method when they aren't (which might be to refuse to attempt
the calculation)? Granted, in many cases, it may be appropriate to
simply always use the fall-back, so there's no need to even check.
However, that's not always the case, and the new facilities allow you to
do something other than the fall back, if you want to. How does the
presence of those facilities make the situation any worse then it was
without them?

writes:
[...]
> The float_t and double_t types are likely to be macros, because
> 7.12#2 states that they ARE built-in types for some values of
> FLT_EVAL_METHOD. That is incompatible with using typedefs for them
> in those cases. Also, unless FLT_EVAL_METHOD is 0, 1 or 2, they
> have no connexion with expression evaluation.
[...]

float_t and double_t are almost certainly typedefs. The standard
doesn't say or imply that they're macros. If they were, then this:

#include <math.h>
int main(void) {
int float_t;
return 0;
}

would be invalid, which I believe would violate 7.1.3.

The statement that they *are* built-in types is entirely consistent
with them being typedefs. A typedef does not introduce a new type,
just an alias for an existing one (6.7.7p3).

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

John Smith <> writes:
> Keith Thompson wrote:
>> writes:
>> [...]
>>> The float_t and double_t types are likely to be macros, because
>>> 7.12#2 states that they ARE built-in types for some values of
>>> FLT_EVAL_METHOD. That is incompatible with using typedefs for them
>>> in those cases. Also, unless FLT_EVAL_METHOD is 0, 1 or 2, they
>>> have no connexion with expression evaluation.
>> [...]
>>
>> float_t and double_t are almost certainly typedefs. The standard
>> doesn't say or imply that they're macros. If they were, then this:
>>
>> #include <math.h>
>> int main(void) {
>> int float_t;
>> return 0;
>> }
>>
>> would be invalid, which I believe would violate 7.1.3.
>>
>> The statement that they *are* built-in types is entirely consistent
>> with them being typedefs. A typedef does not introduce a new type,
>> just an alias for an existing one (6.7.7p3).
>
> Interesting, Keith. If your logic is good to this point, why isn't it
> correct to say they can't be macros?

It probably is. I was being cautious, in case there's something
I've missed that implies they can be macros. But I presented an
argument that they can't be: they're identifiers with file scope,
so they're reserved for use as macro names and as identifiers with
file scope in the same name space <math.h> is included (C99 7.1.3p1)
-- which implies that they're *not* reserved for use as identifiers
with block scope.

On the other hand, that's a bit of a circular argument. The standard
doesn't explicitly say they have file scope; I'm assuming they
are because it makes sense for them to be typedefs. Then again,
they certainly *can* be typedefs.

On the other other other hand, C99 7.12p1 says that "The header
<math.h> declares two types ..."; a macro definition doesn't declare
a type.

I'm about 98% sure that the standard intends for them to be
typedefs, about 99% sure that the standard at least permits them
to be typedefs, and about 95% sure that it forbids them to be macros.
(Don't read too much into the specific percentages.)

> What I think the case is that they aren't macros for folks writing
> portable, sane, functional C code but somehow they can be in a low
> level and meaningless manner.

I'm not sure what that means. Whether they're macros or not (if the
standard permitted them to be) would depend on the implementation,
not on any user-written code. And there's no ambiguity whether
they're macros or not for a given implementation:

#include <math.h>
#include <stdio.h>
int main(void)
{
#ifdef float_t
puts("float_t is a macro");
#else
puts("float_t is not a macro");
#endif
return 0;
}

(I believe that this program cannot print "float_t is a macro"
under a conforming implementation.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"