Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Re: standard pragma's II (http://www.velocityreviews.com/forums/t735372-re-standard-pragmas-ii.html)

Joachim Schmitz 10-13-2010 01:04 PM

Re: standard pragma's II
 
Uno wrote:
<snip>
> I believe to have read that these pragmas address floating point,


Why not read the standard itself rather than guessing? Google for n1256.pdf.

> which in the open source movement might be called kaputt, verletzt, or
> verklagen. (I don't think verklagen's a word.)


"verklagen" is a word, but not in english and not at all applicable this
context.

bye, Jojo



Keith Thompson 10-14-2010 09:38 PM

Re: standard pragma's II
 
John Smith <john@example.invalid> writes:
> Joachim Schmitz wrote:
>> Uno wrote:
>> <snip>
>>> I believe to have read that these pragmas address floating point,

>>
>> Why not read the standard itself rather than guessing? Google for n1256.pdf.
>>

>
> When you're looking at something that changes from one standard to the
> next, then the one place you can't inform yourself well about it is the
> standard.
>
> It gets discussed in a thousand different meetings, and by the time it
> enters the standard, it's been stripped down to the bare bones. (I'm
> glad that we don't have to read all the wrangling that must attend even
> the smallest of changes.)


Reading the standard tells you what's in the standard. If you're
curious about the discussion that led to it, you need to consult other
sources.

> I did see that
> #pragma STDC FP_CONTRACT on-off-switch
> #pragma STDC FENV_ACCESS on-off-switch
> #pragma STDC CX_LIMITED_RANGE on-off-switch
> on-off-switch: one of
> ON OFF DEFAULT
>
> means
>
> #pragma STDC FP_CONTRACT OFF
> #pragma STDC FP_CONTRACT DEFAULT
> #pragma STDC FP_CONTRACT ON
>
> are standard pragma's (I don't think we should use "pragmata" for the
> plural to avoid ambiguity with perl.)
>
> Hence, there are 9 standard pragmas.


Well, it depends on how you count them; I'd say there are three, each of
which can take any of three arguments.

> 7.12.2 The FP_CONTRACT pragma
> Synopsis
> 1 #include <math.h>
> #pragma STDC FP_CONTRACT on-off-switch
> Description
> 2 The FP_CONTRACT pragma can be used to allow (if the state is "on")
> or disallow (if the state is "off") the implementation to contract
> expressions (6.5). Each pragma can occur either outside external
> declarations or preceding all explicit declarations and statements
> inside a compound statement. When outside external declarations, the
> pragma takes effect from its occurrence until another FP_CONTRACT
> pragma is encountered, or until the end of the translation unit. When
> inside a compound statement, the pragma takes effect from its
> occurrence until another FP_CONTRACT pragma is encountered (including
> within a nested compound statement), or until the end of the compound
> statement; at the end of a compound statement the state for the pragma
> is restored to its condition just before the compound statement. If
> this pragma is used in any other context, the behavior is
> undefined. The default state ("on" or "off") for the pragma is
> implementation-defined.
>
>
> //end excerpt
>
> So this this what is legal, conforming, etc., but it gives no inkling as
> to *why* one would want a standard pragma and what they are supposed to
> do for you.
>
> There are several examples that use this, but no indication how behavior
> changes when this is ON or OFF.


It refers to section 6.5; do you try reading the description there?
In particular, 6.5p8 says:

A floating expression may be contracted, that is, evaluated as
though it were an atomic operation, thereby omitting rounding
errors implied by the source code and the expression evaluation
method. The FP_CONTRACT pragma in <math.h> provides a way
to disallow contracted expressions. Otherwise, whether and how
expressions are contracted is implementation-defined.

That seems clear enough.

As for the more general question of "why* one would want a
standard pragma", it depends on the pragma. Different pragmas
do different things. It happens that the three (or nine, if you
insist) defined in C99 all affect floating-point arithmetic. I
wouldn't be surprised if future C standards add other standard
pragmas for other purposes, though the latest C201X draft I have
(N1494) still only has the same ones defined in C99.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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"

James Kuyper 10-16-2010 01:52 AM

Re: standard pragma's II
 
On 10/15/2010 07:02 PM, John Smith wrote:
> [also x-posted comp.std.c]
>
> Keith Thompson wrote:
>> John Smith <john@example.invalid> writes:

....
>>> I did see that
>>> #pragma STDC FP_CONTRACT on-off-switch
>>> #pragma STDC FENV_ACCESS on-off-switch
>>> #pragma STDC CX_LIMITED_RANGE on-off-switch
>>> on-off-switch: one of
>>> ON OFF DEFAULT

....
>>> 7.12.2 The FP_CONTRACT pragma
>>> Synopsis
>>> 1 #include <math.h>
>>> #pragma STDC FP_CONTRACT on-off-switch
>>> Description
>>> 2 The FP_CONTRACT pragma can be used to allow (if the state is "on")
>>> or disallow (if the state is "off") the implementation to contract
>>> expressions (6.5). Each pragma can occur either outside external
>>> declarations or preceding all explicit declarations and statements
>>> inside a compound statement. When outside external declarations, the
>>> pragma takes effect from its occurrence until another FP_CONTRACT
>>> pragma is encountered, or until the end of the translation unit. When
>>> inside a compound statement, the pragma takes effect from its
>>> occurrence until another FP_CONTRACT pragma is encountered (including
>>> within a nested compound statement), or until the end of the compound
>>> statement; at the end of a compound statement the state for the pragma
>>> is restored to its condition just before the compound statement. If
>>> this pragma is used in any other context, the behavior is
>>> undefined. The default state ("on" or "off") for the pragma is
>>> implementation-defined.

....
>> It refers to section 6.5; do you try reading the description there?
>> In particular, 6.5p8 says:
>>
>> A floating expression may be contracted, that is, evaluated as
>> though it were an atomic operation, thereby omitting rounding
>> errors implied by the source code and the expression evaluation
>> method. The FP_CONTRACT pragma in <math.h> provides a way
>> to disallow contracted expressions. Otherwise, whether and how
>> expressions are contracted is implementation-defined.

....
> What has the standardization of these pragmas accomplished?


Relatively little, so far; fully conforming implementations of C99 are
still relatively uncommon, more than a decade after the standard was
approved. However, in principle they provide portable methods for
controlling some of the issues that are relevant to making reliable
programs that do lots of high precision floating point math.

FP_CONTRACT: allowing contraction can, in principle, produce more
accurate results. However, since contraction is optional even when
FP_CONTRACT is ON, you can't rely upon those answers. Forbidding
contraction therefore improves the reliability of the results (at the
expense of their accuracy).

FENV_ACCESS: This tells the compiler to avoid optimizations that could
render calls to the new functions for examining the floating point
environment meaningless. Now, the simple fact that a given piece of code
uses those new functions should imply the need for suppressing such
optimizations - but over what portion of the program? This pragma allows
precise specification of the region of the code in which those
optimizations must be disabled.

CX_LIMITED_RANGE: There's a fast way and a slow way to handle many
operations involving complex numbers; the slower method avoids some
problems that can occur with the fast way, if the magnitude of the
complex number is too big or too small. If a programmer has gone to the
trouble of ensuring that his program never performs any operations on
complex numbers that would trigger this problem, this pragma allows him
to inform the compiler of that fact, enabling use of the faster methods.

For people who need to do high precision floating point operations, or
very fast floating point operations (and especially for those who need
to do both), these are useful tools. They're not essential, and they
won't solve all possible problems, but they are useful. For everyone
else, they're pretty unimportant. You could say the same about many of
the other features of C or the C standard library. For example, in 35
years of programming C, I've never had any real need to use <locale.h>,
<setjmp.h>, <signal.h>, or <wchar.h>; but for those who actually need
them, those features are very useful.

James Kuyper 10-19-2010 02:00 AM

Re: standard pragma's II
 
On 10/18/2010 04:08 PM, John Smith wrote:
> James Kuyper wrote:
>> On 10/15/2010 07:02 PM, John Smith wrote:

>
>>> What has the standardization of these pragmas accomplished?

>>
>> Relatively little, so far; fully conforming implementations of C99 are
>> still relatively uncommon, more than a decade after the standard was
>> approved. However, in principle they provide portable methods for
>> controlling some of the issues that are relevant to making reliable
>> programs that do lots of high precision floating point math.
>>
>> FP_CONTRACT: allowing contraction can, in principle, produce more
>> accurate results. However, since contraction is optional even when
>> FP_CONTRACT is ON, you can't rely upon those answers. Forbidding
>> contraction therefore improves the reliability of the results (at the
>> expense of their accuracy).
>>
>> FENV_ACCESS: This tells the compiler to avoid optimizations that could
>> render calls to the new functions for examining the floating point
>> environment meaningless. Now, the simple fact that a given piece of
>> code uses those new functions should imply the need for suppressing
>> such optimizations - but over what portion of the program? This pragma
>> allows precise specification of the region of the code in which those
>> optimizations must be disabled.
>>
>> CX_LIMITED_RANGE: There's a fast way and a slow way to handle many
>> operations involving complex numbers; the slower method avoids some
>> problems that can occur with the fast way, if the magnitude of the
>> complex number is too big or too small. If a programmer has gone to
>> the trouble of ensuring that his program never performs any operations
>> on complex numbers that would trigger this problem, this pragma allows
>> him to inform the compiler of that fact, enabling use of the faster
>> methods.
>>
>> For people who need to do high precision floating point operations, or
>> very fast floating point operations (and especially for those who need
>> to do both), these are useful tools. They're not essential, and they
>> won't solve all possible problems, but they are useful. For everyone
>> else, they're pretty unimportant. You could say the same about many of
>> the other features of C or the C standard library. For example, in 35
>> years of programming C, I've never had any real need to use
>> <locale.h>, <setjmp.h>, <signal.h>, or <wchar.h>; but for those who
>> actually need them, those features are very useful.

>
> I agree that there are huge parts of C that any given person doesn't
> use; indeed, I think a programming language's "size" is proportional to
> its literature. I have no need to program a clicker, although I have a
> system of fans in my hallway that I want to control through embedded
> systems. (I'm gonna get paint on it first, tho)
>
> For anything like what you describe, I'm gonna use my better syntax,
> fortran, the common C extension. ...


You're within your rights to feel that way and to express that opinion;
but it is a little confrontational to crosspost to three different C
forums, and proclaim that Fortran is the better language.

C99 includes a lot of changes to make it a more attractive language for
hard-core numerical processing than C90; these pragmas are just a few of
the features that were added. VLAs allow multi-dimensional arrays to be
handled in a more Fortran-like manner. The math library has been
substantially expanded, there's language-level support for complex
numbers, and if __STDC_IEC_559__ is pre-defined, there's substantial
support for IEC 60559 (IEEE 754). If you were unfamiliar with those
changes, you might want to re-examine the issue of Fortran vs. C.

> ... However, I don't think I'm "done,"
> until I can pass it to C. All of C's floating point types can be called
> through fortran's ISO_C_BINDING.
>
> So there's a fortran side to it and C side. C is the caller.
>
> My question is this:
>
> In such circumstances, would differing values in these pragmas matter?


I'm no Fortran expert, but it seems to me that these pragmas all have
effects that are limited to the bodies of C functions; I'd be surprised
if they have any effect across the C/Fortran interfaces other than to
change the values calculated by the C code.

The behavior of the interface between Fortran and C is defined, if at
all, by the Fortran standard, not by the C standard. Therefore, you
might get a better answer to that question in a Fortran forum than in
this one.

William Hughes 10-19-2010 06:18 PM

Re: standard pragma's II
 
On Oct 19, 7:57*am, Uno <merrilljen...@q.com> wrote:

> ... still on the search to find why C shits its pants with floating point..
>


It does not of course. However, historically, floating point was of
secondary
importance to C implementations, nor was exact agreement valued above
speed and
ease of implementation in the standardization process (this does not
apply
only to floating point, condsider % and negative values). Thus if
exact agreement
and/or corner cases matter, C floating point support (at least
portable support)
is generally insufficient. C99 has gone a long way to correcting
this,

- William Hughes


Ian Collins 10-20-2010 05:07 AM

Re: standard pragma's II
 
On 10/20/10 06:02 PM, John Smith wrote:
> William Hughes wrote:
>
>> It does not of course. However, historically, floating point was of
>> secondary
>> importance to C implementations, nor was exact agreement valued above
>> speed and
>> ease of implementation in the standardization process (this does not
>> apply
>> only to floating point, condsider % and negative values). Thus if
>> exact agreement
>> and/or corner cases matter, C floating point support (at least
>> portable support)
>> is generally insufficient. C99 has gone a long way to correcting
>> this,

>
> If that's true, then I don't understand why the word "Broken" occurs so
> much here:
>
> http://gcc.gnu.org/gcc-3.1/c99status.html


Because it's an old branch of the compiler.

--
Ian Collins

James Kuyper 10-20-2010 10:00 AM

Re: standard pragma's II
 
On 10/20/2010 01:02 AM, John Smith wrote:
> William Hughes wrote:
>
>> It does not of course. However, historically, floating point was of
>> secondary
>> importance to C implementations, nor was exact agreement valued above
>> speed and
>> ease of implementation in the standardization process (this does not
>> apply
>> only to floating point, condsider % and negative values). Thus if
>> exact agreement
>> and/or corner cases matter, C floating point support (at least
>> portable support)
>> is generally insufficient. C99 has gone a long way to correcting
>> this,

>
> If that's true, then I don't understand why the word "Broken" occurs so
> much here:
>
> http://gcc.gnu.org/gcc-3.1/c99status.html


Why are you looking at an old version of gcc? That same page contains a
prominent link to the status page for mainline gcc
<http://gcc.gnu.org/c99status.html>. There are version-specific status
pages for versions up to 4.5, so 3.1 is pretty old.

There's not a single Feature marked as "Broken" in mainline gcc.

Only a few features remain that are completely missing; two of which are
relevant to floating point: the very same standard pragmas that are the
subject of this thread, and math_errhandling.

There's a number of library issues remaining, but the only ones that
affect floating point involve <tgmath.h>, math_errhandling, and printing
of floating point values with "%lf".

If I understand the "Further notes" correctly, gcc conforms to IEC
60559, if the hardware it's compiling for does so, but it chooses not to
predefine __STDC_IEC_559__. It seems to me that gcc could predefine it,
only when compiling for such hardware, but maybe that's more difficult
to do than I naively imagine?

James Kuyper 10-20-2010 10:04 AM

Re: standard pragma's II
 
On 10/20/2010 06:00 AM, James Kuyper wrote:
....
> There's not a single Feature marked as "Broken" in mainline gcc.


I just noticed that I missed one item that is marked as "Broken": IEC
60559 compliance - I don't know how I missed it the first three times I
looked at that list. While I didn't notice that it was marked as
"Broken", I did address that issue:

> If I understand the "Further notes" correctly, gcc conforms to IEC
> 60559, if the hardware it's compiling for does so, but it chooses not to
> predefine __STDC_IEC_559__. It seems to me that gcc could predefine it,
> only when compiling for such hardware, but maybe that's more difficult
> to do than I naively imagine?



Thomas Rachel 10-20-2010 11:53 AM

Re: standard pragma's II
 
Am 14.10.2010 22:54, schrieb John Smith:

> are standard pragma's (I don't think we should use "pragmata" for the
> plural to avoid ambiguity with perl.)


If you try to use plural, you should avoid the ' in order to be correct...


HTH,

Thomas

James Kuyper 10-21-2010 11:00 AM

Re: standard pragma's II
 
As a point of Netiquette, it's considered polite to mention the fact
that you've changing which newsgroups a thread is being posted to.
Welcome to our new listeners in comp.lang.fortran!

On 10/20/2010 10:53 PM, John Smith wrote:
> James Kuyper wrote:

....
> You asked me earlier about the crosspost to d.c.l.c. It's the language I
> read C in. I hope that doesn't offend.


The only comment I made about your cross-posting was to point out that
criticizing C as inferior to Fortran in a message posted to several
different C newsgroups is a bit ... confrontational. What you've just
told me doesn't make it any less so.

....
> But with floating point, C and fortran would seem to end up in the same
> place: IEC:60559.
>
> "Wir sind in yemeinsam Boot."


Is your point that, with these new features in C99, C is only catching
up to Fortran, and has nothing to recommend it as better than Fortran
for numerical processing? Keep in mind that for many people (including
most of the people you've been talking to on this thread, though
probably not our new listeners in c.l.f), C is generally preferred over
Fortran for many reasons that have nothing to do with floating point
operations.

In any real-world program, even those which are primarily about number
crunching, there's always a fair amount of auxiliary code that has
nothing to do with floating point operations. For those who prefer C in
general, being able to get greater speed, accuracy and reliability with
floating point operations opens up the possibility of using C for both
parts of such code, avoiding the need to write anything in Fortran. This
argument will probably not be persuasive for Fortran partisans.


All times are GMT. The time now is 02:33 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.