> 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.
glen herrmannsfeldt wrote: > I am not sure anymore where this one started. The mix of optimizing > compilers and actual hardware sometimes gives unexpected results.
This one started when I got the news that there were, as of C99, standard pragmas. alternatively it began with my fascination for the uncertain.
> Most physical scientists, used to computing with uncertainty, > don't expect exact results from floating point. If the computational > errors are smaller than the physical uncertainty, all is well. > When exact results are desired, use fixed point. (More generally, > for quantities with absolute uncertainty use fixed point, for > relative uncertainty use floating point.)
Right. But you can't pass it to C without knowing that the representation is faithful. "Tochno" is what russians say.
> 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.
>> This kind of attitude seriously reduces the damage that ambiguities >> in the Standard can cause.
> Well, the ambiguities are different in Fortran and C, often > stretched when optimization is involved.
The ambiguities have a local pole when lack of precision speaks of "the Standard." And I know that from a lot of Poles with differing norms and conventions. When the subject of Fortran-C interop is given to be relevant, then one must speak of "the C Standard," and/or "the fortran standard."
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? -- John Smith
Mark Wooding wrote: > John Smith <j...@example.invalid> writes:
>> Thomas Rachel wrote: >>> 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... >> Nay, Thomas, das waere Korrekt.
> No, it really wasn't.
>> The specific intent was to create the plural without ambiguity. >> Nobody would think that 'pragma' posseses the paernethetical statement >> that describes its disambiguation.
> Indeed, true. But the obvious alternative interpretation is, alas, that > the author is illiterate.
I would claim to read you, but that would violate your conclusion. Tja. -- john Smith
>>> [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.
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 modaps...@sigmaspace.com or call 1-866-506-6347; questions that fall within my domain will be redirected to me.
James Kuyper wrote: > 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.
It doesn't have really anything to do with a programming language. That's what makes it OT. I've corresponded with you before and found your projects fascinating.
I don't have the time right now to delve into something; indeed I'm just listening to the gas heater that I made a repair on and reading usenet for the sake of distraction.
One won't regret firing up those links, if you're wired to be interested in something like this excerpt:
"Physical oceanographer Jae-Hun Park helped steady a pumpkin-sized, plastic-encased glass ball on the deck of the Research Vessel Melville. The ball contained scientific sensors and had been moored to the sea floor off the eastern coast of Japan for two years, collecting data about the rapidly flowing ocean current above it. Forty-two other such glass balls either had been retrieved or were still moored underwater. Park would spend almost a month at sea with other researchers, retrieving these instruments. But he was very excited about the data they would be getting on the eddies, gyres, and meanders that make up the most active region of the Kuroshio Current."
The reason I quote is that the writer evokes Richard Feynman from _Surely You're Joking, Mr. Feynman_. He was talking about an english essay he wrote where he named the same notion in hydrodynamics. One of the words he used was "vortices." What were the others?
> 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.
Correct or not, I conflate you with the people who take very precise measurements of things that involve the shape of the earth. The question I've been ruminating on is how much of Russia just went up in smoke. Cold war relics like me wonder how we're doing in the warm war.
Does anyone know of a methodology or data to calculate the mass of consumed tree/brush/anything that burns in places that have never been burned like this before in the same way.
Can the satellite that now photographs the venting I've made for my heaters also take the guesswork out of this datum?
For comparision purposes, I was thinking one could use this:
, which was probably not a good thing for the people of tuva in 1908. In the images one sees landscapes filled with slain deciduous plants.
I would think that data for forests in Alaska would be a good start for a napkin calculation.
> 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 modaps...@sigmaspace.com > or call 1-866-506-6347; questions that fall within my domain will be > redirected to me.
You're always authorized to talk to me; my Standards aren't high.:-) -- John Smiths
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:
> 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.
> 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:
>> 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.
>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:
>>> 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.
> 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?
> 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) ks...@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"
Keith Thompson wrote: > n...@cam.ac.uk 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?
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. -- John Smith
Dick Hendrickson wrote: > It's got one big implication from the Fortran side. Fortran has an "as > if" rule that, loosely speaking, says that once the interpretation of > the program has been determined (by applying the standard) the compiler > is free to do any optimizations it likes. The big optimizations include > keeping things in registers for long times (typically the execution life > of a subroutine for integer scalars), rearranging calculations (often > overlapping computations from several statements), and ignoring > side-effects of functions.
> To make that work, Fortran effectively disallows hidden associations > between different variables. The big one here is that two subprogram > arguments must not be "associated" if either one has its value changed > in the subprogram or in any routine called from the subprogram. This is > a restriction on the programmer and catches lots of people with a C > background. Given a subroutine like > subroutine silly (a,b) > a = a/27.0 > b = 1.0 > end > an optimizing compiler is free to start the slow divide by 27, store 1.0 > into b, and then store the divide result into a. As I understand C, the > store into a must take place before the store into b. If a and b are > different variables, it doesn't matter. If they are the same variable > on the call side, it matters.
> Pointers are used less frequently in Fortran and things that are pointed > to must have an explicit TARGET attribute and the optimizer is then > effectively limited in what it can do.
> The other one that sometimes catches C programmers is function > references. Fortran disallows functions from having side-effects that > affect the statement the function is in. So, in something like > a(i) = b + f(c,i) + d + g(c,d) > the function f and g are forbidden from changing the values of their > arguments or of b or d (which might be in COMMON). It's particularly > interesting in something like > x /= 0 .AND. 1.0/x == 137.0 .AND. f(z) == 42.0 > The compiler is free to evaluate the logical sub-expressions in any > order and is free to short-circuit the evaluation if one of them is > false. So, the 1.0/x might produce a divide by zero fault or f(z) might > not be evaluated (and might not have do its side-effect things).
> Dick Hendrickson
I've been sporadic on newsreading lately and simply wanted to thank you for the good read. (also the selfish motivation to want to serialize your comments.) Cheers, -- John Smith
John Smith <j...@example.invalid> writes: > Keith Thompson wrote: >> n...@cam.ac.uk 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) ks...@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"
