Hello, I didn't find in the standard, what should be the interpretation of 0**0, 0d0**0, etc. ? I ask because I just noticed with Absoft compiler (ver. 11.5.2), that 0d0**0 == 1d0, whereas 0q0**0 == 0q0 (q for quad precision numbers). Thus, porting some double precision code to quad precision gave me unexpected results. Jean-Claude Arbaut

0 |

10/6/2012 9:26:26 AM

In article <506ff947$0$18052$ba4acef3@reader.news.orange.fr>, Jean-Claude Arbaut <jeanclaudearbaut@orange.fr> writes: > I didn't find in the standard, what should be the interpretation > of 0**0, 0d0**0, etc. ? > > I ask because I just noticed with Absoft compiler (ver. 11.5.2), that > 0d0**0 == 1d0, whereas 0q0**0 == 0q0 (q for quad precision numbers). > Thus, porting some double precision code to quad precision gave me > unexpected results. My guess is that you shouldn't be relying on this at all. Both answers are probably "correct" in the sense that the compiler can do anything if the code is invalid, and these operations are probably not allowed, so the question of the "correct" value is moot.

0 |

10/6/2012 10:43:46 AM

Hi, > > I didn't find in the standard, what should be the interpretation > > of 0**0, 0d0**0, etc. ? > > > > I ask because I just noticed with Absoft compiler (ver. 11.5.2), that > > 0d0**0 == 1d0, whereas 0q0**0 == 0q0 (q for quad precision numbers). > > Thus, porting some double precision code to quad precision gave me > > unexpected results. > > My guess is that you shouldn't be relying on this at all. Both answers > are probably "correct" in the sense that the compiler can do anything if > the code is invalid, and these operations are probably not allowed, so > the question of the "correct" value is moot. how is the code invalid? I think the common mathematical definition is such that 0**0 equals 1 (which is also what I get from gfortran for all the variants given above). Btw, I don't think the Fortran standard contains contains a complete collection of mathematical axioms and definitions. It is supposed to define Fortran as a language, and not all of mathematics. Cheers, Janus

0 |

10/6/2012 1:14:17 PM

On 2012-10-06, Janus Weil <janus@gcc.gnu.org> wrote: > I think the common mathematical definition is such that 0**0 > equals 1 (which is also what I get from gfortran for all the > variants given above). It is generally regarded as undefined, because there are different limiting cases for lim[x->0] x**0 and lim[x->0] 0**x.

0 |

10/6/2012 1:54:20 PM

Jean-Claude Arbaut <jeanclaudearbaut@orange.fr> wrote: > Hello, > I didn't find in the standard, what should be the interpretation > of 0**0, 0d0**0, etc. ? > I ask because I just noticed with Absoft compiler (ver. 11.5.2), that > 0d0**0 == 1d0, whereas 0q0**0 == 0q0 (q for quad precision numbers). > Thus, porting some double precision code to quad precision gave me > unexpected results. Mathematically, both are right. The usual implementation of REAL or COMPLEX powers, including 0.0 and (0.0,0.0), is through LOG and EXP, and will fail for 0.0**0.0 or return NaN. The usual implementation of integer powers involves multiplication and squaring, and for negative powers a final reciprocal. I believe that can give either 0 or 1. -- glen

0 |

10/6/2012 3:09:14 PM

First, thanks to all who answered. Actually, I know 0**0 is mathematically undefined, but usually, in programming languages, there is a convention to set it to either 0 or 1. The latter seems to be the most usual, and it's nice when computing values of a polynomial with powers (which is what I did). I thought there were such conventions in Fortran, but if there is none, I guess I should not count on a value, even if a given compiler gives one. At least, it may be a compiler bug to get this inconsistency between double and quad precision - even though the notation 0q0 is undefined in fortran, it's perfectly admissible to get access to quad precision through selected_real_kind(30), the "q" is only syntactic sugar. It would seem natural to get the same value with all available real precisions. Anyway, it was not essential to my program, I just wanted to know whether it was in Fortran standard. Jean-Claude Arbaut Le 06/10/2012 17:09, glen herrmannsfeldt a �crit : > Jean-Claude Arbaut <jeanclaudearbaut@orange.fr> wrote: >> Hello, > >> I didn't find in the standard, what should be the interpretation >> of 0**0, 0d0**0, etc. ? > >> I ask because I just noticed with Absoft compiler (ver. 11.5.2), that >> 0d0**0 == 1d0, whereas 0q0**0 == 0q0 (q for quad precision numbers). >> Thus, porting some double precision code to quad precision gave me >> unexpected results. > > Mathematically, both are right. > > The usual implementation of REAL or COMPLEX powers, > including 0.0 and (0.0,0.0), is through LOG and EXP, > and will fail for 0.0**0.0 or return NaN. > > The usual implementation of integer powers involves > multiplication and squaring, and for negative powers > a final reciprocal. I believe that can give either 0 or 1. > > -- glen >

0 |

10/6/2012 3:35:14 PM

On 10/6/12 4:26 AM, Jean-Claude Arbaut wrote: > Hello, > > I didn't find in the standard, what should be the interpretation > of 0**0, 0d0**0, etc. ? > > I ask because I just noticed with Absoft compiler (ver. 11.5.2), that > 0d0**0 == 1d0, whereas 0q0**0 == 0q0 (q for quad precision numbers). > Thus, porting some double precision code to quad precision gave me > unexpected results. > > Jean-Claude Arbaut It's processor dependent. The section on Evaluation of Operations says "The execution of any numeric operation whose result is not defined by the arithmetic used by the processor is prohibited." You're stuck with reading the processor documentation. Trying to evaluate 0.0**0 won't give you any guaranteed useful information. If the processor supports that expression, then it will give you an answer. If the processor doesn't support that expression, then it can still give you an answer (or do anything else) because your program isn't standard conforming. Not a great situation. Dick Hendrickson

0 |

10/6/2012 5:04:09 PM

Janus Weil <janus@gcc.gnu.org> wrote: > how is the code invalid? > > I think the common mathematical definition is such that 0**0 equals 1 > (which is also what I get from gfortran for all the variants given > above). > > Btw, I don't think the Fortran standard contains contains a complete > collection of mathematical axioms and definitions. It is supposed to > define Fortran as a language, and not all of mathematics. There are multiple "common mathematical definitions", which is exactly the problem. I actually wish the Fortran standard were a little more explicit about a few points of the math in some areas. I occasionally (well, quite a bit more than just ocasionally) run into people who don't realize that the particular rules they learned in their elementary school aren't actually universal ones; rounding is one area I have seen that, with some people being convinced that a rule they learned is the one and only correct way to do rounding (and it turns out to be a rule with poor numerical properties). The Fortran standard did actually used to mention the specific case of 0**0, though I can't find it in a quick skim of f2003. I think that rule might have dissappeared when IEEE stuff came into the language. But it at least used to be there. I did just find it in the f77 standard: "Any arithetic operation whose result is not mathematically defined is prohibitted in the execution of an executable program. Examples are dividing by zero and raising a zero-valued primary to a zero-valued or negative-valued power." I suppose this does show an example in the standard of the kind of narrow view of mathematics that I referred to above. That bit in the f77 standard reads as though the writer thought that there was one and only one mathematical system, and it was one in which 0**0 was not defined. Dick quoted a later version of the same prohibition, which acknowledges that there are multiple mathematical systems and leaves it up to the processor which system it is using, also deleting the implication that, of course, mathematics could not include things like dividing by zero. There still remain some places in the standard where what I might call the elementary-school version of mathematics shows through. One of those is the "mathematical equivalence" rule for evaluating expressions. There have been plenty of debates on the fine points of what counts as "mathematical equivalence", but I note that the use of that term and its contrast to "computational equivalence" imples that someone didn't think that what computers did with floatting point counted as mathematics. I beg to differ. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain

0 |

10/6/2012 7:22:50 PM

Jean-Claude Arbaut <jeanclaudearbaut@orange.fr> wrote: > At least, it may be a compiler bug to get this inconsistency between > double and quad precision - even though the notation 0q0 is > undefined in fortran, it's perfectly admissible to get access to quad > precision through selected_real_kind(30), the "q" is only syntactic > sugar. It would seem natural to get the same value with all available > real precisions. I don't think you can call it a bug. At least it isn't a bug in the sense of violating the standard. I'll buy that one might consider it a shortcomming in quaity of implementation. There are, of course, plenty of expressions where one will get dramatically different results depending on the precision. And by dramatically different, I mean up to and including the difference between giving any result at all versus aborting. Try dividing by something that underflows to zero with one precision, for example. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain

0 |

10/6/2012 7:30:30 PM

On 2012-10-06 12:35:14 -0300, Jean-Claude Arbaut said: > First, thanks to all who answered. > > Actually, I know 0**0 is mathematically undefined, but usually, > in programming languages, there is a convention to set it to either > 0 or 1. The latter seems to be the most usual, and it's nice when > computing values of a polynomial with powers (which is what I did). > I thought there were such conventions in Fortran, but if there is > none, I guess I should not count on a value, even if a given compiler > gives one. > > At least, it may be a compiler bug to get this inconsistency between > double and quad precision - even though the notation 0q0 is > undefined in fortran, it's perfectly admissible to get access to quad > precision through selected_real_kind(30), the "q" is only syntactic > sugar. It would seem natural to get the same value with all available > real precisions. > > Anyway, it was not essential to my program, I just wanted to know > whether it was in Fortran standard. > > Jean-Claude Arbaut What did the vendor say? They might think that the two answers should be the same even if the standard allows anything. This is usually called a quality of implementaion issue when there is a useful answer for many situations even if the standard does not supply one for all (or even any) situations. I have had mixed experiences with Absoft. They have different behaviours of some timers between the 32 and 64 bit versions. They blame it on maintaining a silly error in the C runtime that they use for much of their Fortran. Such an answer may have made them happy but it did not make me happy! > Le 06/10/2012 17:09, glen herrmannsfeldt a �crit : >> Jean-Claude Arbaut <jeanclaudearbaut@orange.fr> wrote: >>> Hello, >> >>> I didn't find in the standard, what should be the interpretation >>> of 0**0, 0d0**0, etc. ? >> >>> I ask because I just noticed with Absoft compiler (ver. 11.5.2), that >>> 0d0**0 == 1d0, whereas 0q0**0 == 0q0 (q for quad precision numbers). >>> Thus, porting some double precision code to quad precision gave me >>> unexpected results. >> >> Mathematically, both are right. >> >> The usual implementation of REAL or COMPLEX powers, >> including 0.0 and (0.0,0.0), is through LOG and EXP, >> and will fail for 0.0**0.0 or return NaN. >> >> The usual implementation of integer powers involves >> multiplication and squaring, and for negative powers >> a final reciprocal. I believe that can give either 0 or 1. >> >> -- glen

0 |

10/6/2012 7:48:58 PM

Op 06-10-12 21:48, Gordon Sande schreef: > On 2012-10-06 12:35:14 -0300, Jean-Claude Arbaut said: > >> First, thanks to all who answered. >> >> Actually, I know 0**0 is mathematically undefined, but usually, >> in programming languages, there is a convention to set it to either >> 0 or 1. The latter seems to be the most usual, and it's nice when >> computing values of a polynomial with powers (which is what I did). >> I thought there were such conventions in Fortran, but if there is >> none, I guess I should not count on a value, even if a given compiler >> gives one. >> >> At least, it may be a compiler bug to get this inconsistency between >> double and quad precision - even though the notation 0q0 is >> undefined in fortran, it's perfectly admissible to get access to quad >> precision through selected_real_kind(30), the "q" is only syntactic >> sugar. It would seem natural to get the same value with all available >> real precisions. >> >> Anyway, it was not essential to my program, I just wanted to know >> whether it was in Fortran standard. >> >> Jean-Claude Arbaut > > What did the vendor say? They might think that the two answers should b= e > the > same even if the standard allows anything. This is usually called a > quality of > implementaion issue when there is a useful answer for many situations > even if > the standard does not supply one for all (or even any) situations. > > I have had mixed experiences with Absoft. They have different behaviour= s of > some timers between the 32 and 64 bit versions. They blame it on > maintaining > a silly error in the C runtime that they use for much of their Fortran.= > Such an answer may have made them happy but it did not make me happy! > >> Le 06/10/2012 17:09, glen herrmannsfeldt a =E9crit : >>> Jean-Claude Arbaut <jeanclaudearbaut@orange.fr> wrote: >>>> Hello, >>> >>>> I didn't find in the standard, what should be the interpretation >>>> of 0**0, 0d0**0, etc. ? >>> >>>> I ask because I just noticed with Absoft compiler (ver. 11.5.2), tha= t >>>> 0d0**0 =3D=3D 1d0, whereas 0q0**0 =3D=3D 0q0 (q for quad precision n= umbers). >>>> Thus, porting some double precision code to quad precision gave me >>>> unexpected results. >>> >>> Mathematically, both are right. >>> >>> The usual implementation of REAL or COMPLEX powers, >>> including 0.0 and (0.0,0.0), is through LOG and EXP, >>> and will fail for 0.0**0.0 or return NaN. >>> >>> The usual implementation of integer powers involves >>> multiplication and squaring, and for negative powers >>> a final reciprocal. I believe that can give either 0 or 1. >>> >>> -- glen > > All, As there is no mathematical unique answer the standard nor any vendor=20 should force a unique answer. Only the limits that are mentioned sometimes can determine whether or=20 not there is an answer at all. Kind regards, Jan Gerrit Kootstra

0 |

10/6/2012 8:17:52 PM

On 10/6/2012 3:17 PM, Jan Gerrit Kootstra wrote: .... > As there is no mathematical unique answer the standard nor any vendor > should force a unique answer. .... A vendor _has_ to provide a solution for an implementation; that it should at least be self-consistent is all OP asked for... --

0 |

10/6/2012 8:33:11 PM

In article <k4q4i3$rt2$1@speranza.aioe.org>, dpb <none@non.net> wrote: > On 10/6/2012 3:17 PM, Jan Gerrit Kootstra wrote: > ... > > > As there is no mathematical unique answer the standard nor any vendor > > should force a unique answer. > ... > > A vendor _has_ to provide a solution for an implementation; that it > should at least be self-consistent is all OP asked for... There are some situations, including this one, where the best solution might not be to return an answer at all, but rather abort with an error message. As far as evaluating polynomials, doing so with exponentiation is almost never the best way in any language, including fortran. In the general case there is horner's rule to consider, and in other specific cases there are often recursion expressions that can be used. In addition to being more efficient, these approaches often can avoid problems such as subtracting quantities with nearly equal values, or trying to add large and small values, that occur with the exponentiation expressions. I don't know if these considerations apply to the underlying code being discussed in this case, but it is not unlikely. In any case, as a practical matter I would suggest changing the code at least to avoid the x**0 expression evaluation, not only for portability reasons, but also for efficiency reasons. I can imagine what the code probably looks like from the discussion so far, but we can't be certain. If the OP posts the code, then we can make more concrete suggestions. $.02 -Ron Shepard

0 |

10/6/2012 9:32:21 PM

On 10/6/2012 4:32 PM, Ron Shepard wrote: > In article<k4q4i3$rt2$1@speranza.aioe.org>, dpb<none@non.net> > wrote: > >> On 10/6/2012 3:17 PM, Jan Gerrit Kootstra wrote: >> ... >> >>> As there is no mathematical unique answer the standard nor any vendor >>> should force a unique answer. >> ... >> >> A vendor _has_ to provide a solution for an implementation; that it >> should at least be self-consistent is all OP asked for... > > There are some situations, including this one, where the best > solution might not be to return an answer at all, but rather abort > with an error message. .... "Might" is an operative word here... :) And, if there were the chosen path I'd still expect consistency in an implementation. --

0 |

10/6/2012 9:51:39 PM

On 10/6/2012 4:26 AM, Jean-Claude Arbaut wrote: > Hello, > > I didn't find in the standard, what should be the interpretation > of 0**0, 0d0**0, etc. ? > > I ask because I just noticed with Absoft compiler (ver. 11.5.2), that > 0d0**0 == 1d0, whereas 0q0**0 == 0q0 (q for quad precision numbers). > Thus, porting some double precision code to quad precision gave me > unexpected results. > > Jean-Claude Arbaut > FYI --------------------- Matlab EDU>> 0^0 1 ---------------------- -------------------- Mathematica In[174]:= 0^0 Out[174]= Indeterminate -------------------- -------------- Maple 16 > 0^0; 1 --------------------- ------------------- Python In [6]: 0^0 Out[6]: 0 -------------------- --Nasser

0 |

10/7/2012 1:44:35 PM

On 10/7/2012 8:44 AM, Nasser M. Abbasi wrote: opps, had mistake in the Python example, I should use ** not ^ here is the correct one -------------------- Python In [9]: 0**0 Out[9]: 1 ------------------- --Nasser

0 |

10/7/2012 1:47:10 PM

On 10/6/12 4:51 PM, dpb wrote: > On 10/6/2012 4:32 PM, Ron Shepard wrote: >> In article<k4q4i3$rt2$1@speranza.aioe.org>, dpb<none@non.net> >> wrote: >> >>> On 10/6/2012 3:17 PM, Jan Gerrit Kootstra wrote: >>> ... >>> >>>> As there is no mathematical unique answer the standard nor any vendor >>>> should force a unique answer. >>> ... >>> >>> A vendor _has_ to provide a solution for an implementation; that it >>> should at least be self-consistent is all OP asked for... >> >> There are some situations, including this one, where the best >> solution might not be to return an answer at all, but rather abort >> with an error message. > ... > > "Might" is an operative word here... :) > > And, if there were the chosen path I'd still expect consistency in an > implementation. > > -- The problem is that exponentiation is common and testing every exponentiation for special cases is likely to be a time waster. Or at least people will perceive it to be. And, consistency in an implementation isn't very useful if there isn't also portability. Dick Hendrickson

0 |

10/7/2012 2:10:41 PM

On 10/7/2012 9:10 AM, Dick Hendrickson wrote: .... > And, consistency in an implementation isn't very useful if there isn't > also portability. .... But I contend inconsistency in an implementation whether it's portable or not isn't very useful, either (or is at least error-inducing-prone). There's a reason these areas are left as implementation-dependent...but imo a quality implementation would strive to be self-consistent. Now, there _may_ be sufficient reason a vendor may decide the vagaries of a particular hardware platform or other considerations make them choose to not be so. Nowhere in anything I've written before is there a statement denying that; only that I think ideally consistency within an implementation is a reasonable expectation of the user. --

0 |

10/7/2012 2:34:31 PM

On 10/7/2012 9:10 AM, Dick Hendrickson wrote: .... > And, consistency in an implementation isn't very useful if there isn't > also portability. .... But I contend inconsistency in an implementation whether it's portable or not isn't very useful, either (or is at least error-inducing-prone). .... That is, error-inducing on the part of writing code w/ only a modicum of testing, relying on the "expected" behavior of the compiler one is using. The OP's example works (again, w/o addressing the question of whether should have written his particular example as did but similar things could be envisioned that aren't all that unreasonable) -- you know a particular construct is implementation-dependent so as OP you test for a given condition and discover it's behavior and rely on that for your code logic (making dutiful notes/comments and even, perhaps, isolating it as a system dependency). Now, simply changing the precision as did OP gives one a different behavior--while strictly speaking, yes, it's your fault; you shoulda' either not made the reliance to begin with and found another workaround or tested every possible behavior, it's still imo not as good a quality implementation as would desire. And again, yes, there's the caveat of the vendor has the right and perhaps even a good justification... This kinda' reminds me of discussions years and years and years ago w/ NRC over the introduction of digital systems into reactor safety systems--some wanted to not allow them at all because there was, in their mind, no way to ever fully verify proper operation because fundamentally one could traceback to the point of there being some branch under which even the processor itself might error. This was a nonproductive since carried to its conclusion meant we couldn't use computers for numerical design work, either. --

0 |

10/7/2012 3:03:33 PM

In article <k4s3tm$188$1@speranza.aioe.org>, dpb <none@non.net> wrote: > There's a reason these areas are left as implementation-dependent...but > imo a quality implementation would strive to be self-consistent. I don't know if this is one if these situations, but this is the kind of expression that might change with optimization levels or with compiler options. And there might be some compiler options or optimizations levels that would result in a program abort and an error message, and that might also depend on the KIND values. This would make self-consistency (between different KIND values) difficult or impossible to achieve. Will the expression X**0 be evaluated the same as X**I when I==0? Maybe not. It is common at some optimization levels for the compiler to replace expressions like X**0, X**1, X**2, X**3 and so on with the appropriate multiplications and never call the power operator, whereas an expression like X**I where the compiler does not know the value of I would generally use it. Should the compiler treat the X==0.0 case special, and if so, is that the same as the special treatment within the general power function. On the other hand, what about 0.0**I, should the compiler try to simplify this or pass it on to the power function? If X==0.0 is not treated as a special case, then almost certainly X**0 is going to end up with a different value than 0.0**I when the compiler tries to simplify these expressions inline and avoid the power function. For different KIND values for X and I, it also would not be unusual to return different results. Some KIND values are going to map directly to the hardware, while others are going to involve software emulation. In this case, the same compiler software will return different results when installed on slightly different hardware. And for the integer cases, 0**0, I**0, 0**I, I**J, it is easy to see that a compiler optimization might do something entirely different than it does for the floating point cases. And, it might do different things for different integer KIND values in these cases too. So in situations like this, I don't think that any kind of self-consistency should be expected. The OP has not yet posted the actual code, so we do no know which of these situations apply. We can imagine what the code might look like, but we don't really know, so all we can do is talk about these generalities. $.02 -Ron Shepard

0 |

10/7/2012 4:03:29 PM

On 10/7/2012 11:03 AM, Ron Shepard wrote: > In article<k4s3tm$188$1@speranza.aioe.org>, dpb<none@non.net> > wrote: > >> There's a reason these areas are left as implementation-dependent...but >> imo a quality implementation would strive to be self-consistent. > > I don't know if this is one if these situations, but this is the > kind of expression that might change with optimization levels or > with compiler options. And there might be some compiler options or > optimizations levels that would result in a program abort and an > error message, and that might also depend on the KIND values. This > would make self-consistency (between different KIND values) > difficult or impossible to achieve. ....[list of possibilities elided for brevity]... > So in situations like this, I don't think that any kind of > self-consistency should be expected. > > The OP has not yet posted the actual code, so we do no know which of > these situations apply. We can imagine what the code might look > like, but we don't really know, so all we can do is talk about these > generalities. > > $.02 -Ron Shepard True but one would presume in this case the code is the same except for the KIND value and therefore eliminates the differences spoken of above about integer vis a vis fp exponents, written constants vis a vis variables, etc., etc., etc., ... and reduces to simply the same expression w/ two differing KINDs. Under those circumstances I _STILL_ think consistency would be _a_good_thing_ (tm) I thought I had put in enough caveats several times previously that if there's a real reason the vendor doesn't do so they have the leeway to do so and still be compliant so again I'm speaking of what I think a "quality implementation" should strive for if feasible. Again, yes, if one gets bit it's not possible to blame anybody else but oneself but then again, vendors shouldn't go out of their way to try to ensure that one does get bitten, either... :) -- --

0 |

10/7/2012 6:08:11 PM

Ron Shepard <ron-shepard@nospam.comcast.net> wrote: (snip, someone wrote) >> There's a reason these areas are left as implementation-dependent...but >> imo a quality implementation would strive to be self-consistent. > I don't know if this is one if these situations, but this is the > kind of expression that might change with optimization levels or > with compiler options. And there might be some compiler options or > optimizations levels that would result in a program abort and an > error message, and that might also depend on the KIND values. This > would make self-consistency (between different KIND values) > difficult or impossible to achieve. > Will the expression X**0 be evaluated the same as X**I when I==0? This is iteresting. Given the different mathematical limits for I**0 and 0**I as I goes to zero, one might imagine a compiler optimizing the two differently. > Maybe not. It is common at some optimization levels for the > compiler to replace expressions like X**0, X**1, X**2, X**3 and so > on with the appropriate multiplications and never call the power > operator, whereas an expression like X**I where the compiler does > not know the value of I would generally use it. Should the compiler > treat the X==0.0 case special, and if so, is that the same as the > special treatment within the general power function. The usual real power (including 2.0, 1.0, and 0.0) is done with LOG and EXP. The usual integer power is done through multiplications. The I**J case still leaves some uncertainty: do you start with 1, and multiply it by I, or do you start with I? (Similarly for X**J.) The implementations that I know about start with I or X, and either square or multiply by I or X depending on the bits of the exponent. Most will test for 0 as a special case, but maybe not all. (snip) > And for the integer cases, 0**0, I**0, 0**I, I**J, it is easy to see > that a compiler optimization might do something entirely different > than it does for the floating point cases. And, it might do > different things for different integer KIND values in these cases > too. > So in situations like this, I don't think that any kind of > self-consistency should be expected. > The OP has not yet posted the actual code, so we do no know which of > these situations apply. We can imagine what the code might look > like, but we don't really know, so all we can do is talk about these > generalities. -- glen

0 |

10/7/2012 9:46:56 PM

dpb <none@non.net> wrote: > On 10/7/2012 9:10 AM, Dick Hendrickson wrote: > ... >> And, consistency in an implementation isn't very useful if there isn't >> also portability. > ... > But I contend inconsistency in an implementation whether it's portable > or not isn't very useful, either (or is at least error-inducing-prone). > ... > That is, error-inducing on the part of writing code w/ only a modicum of > testing, relying on the "expected" behavior of the compiler one is using. This is true, but it has a long history. One has been the variable precision resulting from the x87 stack, and the uncertainty of a value staying in a register or being stored with precision loss. That can very easily be optimized differently. Add that to the variations, (at least pre-IEEE) in floating point implementations, and the rearrangements that optimizers are allowed, and this one should pretty much go into the noise. > The OP's example works (again, w/o addressing the question of whether > should have written his particular example as did but similar things > could be envisioned that aren't all that unreasonable) -- you know a > particular construct is implementation-dependent so as OP you test for a > given condition and discover it's behavior and rely on that for your > code logic (making dutiful notes/comments and even, perhaps, isolating > it as a system dependency). Well, in this case it is easy to test and treat as needed. If one wants a specific result from something the standard allows to be implementation dependent, then one should test for it and do it right. > Now, simply changing the precision as did OP gives one a different > behavior--while strictly speaking, yes, it's your fault; you shoulda' > either not made the reliance to begin with and found another workaround > or tested every possible behavior, it's still imo not as good a quality > implementation as would desire. And again, yes, there's the caveat of > the vendor has the right and perhaps even a good justification... Quad precision, at least with the Q exponent, is an extension, and one often implemented in software emulation. It is not unusual for software emulation to give different results from the hardware. > This kinda' reminds me of discussions years and years and years ago w/ > NRC over the introduction of digital systems into reactor safety > systems--some wanted to not allow them at all because there was, in > their mind, no way to ever fully verify proper operation because > fundamentally one could traceback to the point of there being some > branch under which even the processor itself might error. This was a > nonproductive since carried to its conclusion meant we couldn't use > computers for numerical design work, either. Not to mention the large number of errors from wetware, and that more of those can't be tested for than for computational hardware. As far as I know it, TMI was mostly a wetware error, and Chernobyl pretty much completely a wetware error. -- glen

0 |

10/7/2012 9:58:38 PM

Hi, On 2012-10-07 15:03:33 +0000, dpb said: > But I contend inconsistency in an implementation whether it's portable > or not isn't very useful, either (or is at least error-inducing-prone). But it is useful if it causes the programmer to be alert to the issue early in the process. -- Cheers! Dan Nagle

0 |

10/7/2012 10:02:39 PM

On 10/7/2012 4:58 PM, glen herrmannsfeldt wrote: .... >> This kinda' reminds me of discussions years and years and years ago w/ >> NRC over the introduction of digital systems into reactor safety >> systems--some wanted to not allow them at all because there was, in >> their mind, no way to ever fully verify proper operation because >> fundamentally one could traceback to the point of there being some >> branch under which even the processor itself might error. This was a >> nonproductive since carried to its conclusion meant we couldn't use >> computers for numerical design work, either. > > Not to mention the large number of errors from wetware, and that > more of those can't be tested for than for computational hardware. > As far as I know it, TMI was mostly a wetware error, ... End result entirely, yes, after the initial turbine trip and PORV reseat failure if had simply left safety systems alone all would have ended well. When initial operators failed to recognize the symptoms and stopped the RCPs that instigated the worst of the result that wasn't cured until next shift SRO recognized the issue and restarted RCPs to reestablish core circulation... > ... and Chernobyl pretty much completely a wetware error. Indeed, it was a tragedy of error from conception to inception...compounded by the design lacking a containment building to help mitigate result-- <http://www.world-nuclear.org/info/chernobyl/inf07app.html> --

0 |

10/8/2012 4:43:21 AM

On Oct 8, 8:58=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > It is not unusual > for software emulation to give different results from the hardware. Especially when the hardware is in error, as it was in the case of the KDF9 hardware multiplier!

0 |

10/8/2012 10:01:13 AM

On Oct 8, 1:10=A0am, Dick Hendrickson <dick.hendrick...@att.net> wrote: > The problem is that exponentiation is common and testing every > exponentiation for special cases is likely to be a time waster. =A0Or at > least people will perceive it to be. Testing for 0.0 is scarcely going to waste much time. It's an important special case, and it should be included in generated code.

0 |

10/8/2012 10:24:23 AM

In article <d21aaea7-57d3-4c92-985b-1dd5cff49a2c@r8g2000pbs.googlegroups.com>, Robin Vowels <robin.vowels@gmail.com> wrote: > On Oct 8, 1:10�am, Dick Hendrickson <dick.hendrick...@att.net> wrote: > > > The problem is that exponentiation is common and testing every > > exponentiation for special cases is likely to be a time waster. �Or at > > least people will perceive it to be. > > Testing for 0.0 is scarcely going to waste much time. > It's an important special case, and it should be included > in generated code. An exception to this would be using SIMD hardware or pipelining to evaluate several results simultaneously. Here, the same operations must be performed on a full set of values, so special cases cannot be singled out. These kinds of considerations have been important in scientific computing since the early 1980's, this is not recent. $.02 -Ron Shepard

0 |

10/8/2012 3:37:57 PM

The following 4-lines source fragment test.c (fourth line empty) #if 0?0?0:0:0 #endif int main(void){return 0?0?0:0:0;} cause: test.c(1) : fatal error C1017: invalid integer constant expression when compiled by cl.exe aka "Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86". On the other hand this compile and runs fine. #if 0?(0?0:0):0 #endif int main(void){return 0?0?0:0:0;} Did I hit a but it this compiler's preprocessor? Francois Grieu On 3/30/2010 12:47 PM, Francois Grieu wrote: > The following 4-lines source fr...

hi all, i have 2 drawings - ground floor and first floor. when i do an ID on a point on the grid i get the same readings for both drawings however, when i xref one into the other or both into a new drawing they come in in different locations. i've checked they're both using world UCS and the same units. any ideas? i thought with autocad 0,0 was always 0,0? cheers rob "Coro, Rob" <RE-Coro@bdp.co.uk> schrieb: >hi all, > >i have 2 drawings - ground floor and first floor. when i do an ID on a >point on the grid i get the same readings for both drawings however, >when i xref one into the other or both into a new drawing they come in >in different locations. i've checked they're both using world UCS and >the same units. any ideas? i thought with autocad 0,0 was always 0,0? UCS? INSBASE? Tom Berger -- ArchTools: Architektur-Werkzeuge f�r AutoCAD (TM) ArchDIM - architekturgerechte Bema�ung und H�henkoten ArchAREA - Fl�chenermittlung und Raumbuch nach DIN 277 Info und Demo unter http://www.archtools.de insbase, that's the bugger. thanks tom rob -----Original Message----- From: Tom Berger [mailto:berger@archtools.de] Posted At: 13 July 2004 12:24 Posted To: autocad Conversation: 0,0 not 0,0 Subject: Re: 0,0 not 0,0 "Coro, Rob" <RE-Coro@bdp.co.uk> schrieb: >hi all, > >i have 2 drawings - ground floor and first floor. wh...

Hi, shouldn't > (= 0/0 0/0) => NIL or > (= 0/0 0/0) => T instead of giving out division by zero? 0/0 is different from 1/0, which is the non-existent number n such that 1 x n = 0. The actual result of that expression depends of what you think 0/0 is. I personally feel that 0/0 is any number n such that 0 x n = 0, that is all numbers. hal9@cyberspace.org (Hal Niner) writes: > Hi, > > shouldn't > > > (= 0/0 0/0) => NIL > > or > > > (= 0/0 0/0) => T > > instead of giving out division by zero? 0/0 is different fro...

Hi Any useful link that explains this IP address range in details, please? Thanks in advance! The Dude In article <Jp6Hg.458762$IK3.24918@pd7tw1no>, The Dude <The Dude@thedu.de> wrote: >Any useful link that explains this IP address range in details, please? Urrr -- 0.0.0.0/0 is the *entire* IPv4 address range, and 0.0.0.0/32 is just the single IPv4 address 0.0.0.0. For any given network, the lowest address in the network is reserved. Historically, the lowest address was one of the two allowed choices for the broadcast address; later, the broadcast a...

I'm wondering if 0.0**0 (as opposed to 0.0**0.0) has the value 1 as per fortran standard or if this is left to the compiler vendors (different vendors do different things, unhappily). Thanks, Joost Joost VandeVondele wrote: > I'm wondering if 0.0**0 (as opposed to 0.0**0.0) has the value 1 as > per fortran standard or if this is left to the compiler vendors > (different vendors do different things, unhappily). > > Thanks, > > Joost Surely, 0.0**0.0 is mathematically undefined? Therefore, I wouldn't expect the standard to make any pronouncement about the ...

Hello, In brief: Is there a way that I can specify that "X" is a matrix and will resolve to zero when dot multiplied with a vector of zeros? I'm constructing a swathe of expressions that contain things like (when expanded): {0,0,0}.X.{0,0,0}, where X is an arbitrary (well, positive definite) square matrix of obvious size, and I'd like to be able to have mathematica simplify that for me without much intervention. My only option at the moment is to manually perform the replacements {{0, 0, 0}.X._ -> 0, _.X.{0, 0, 0} -> 0} (the left and right vectors won...

can i use such form of adding zeros to the strings/literals to 'pad' them with zeros ? or this is not guwranteed to work? need that for assuring that strings for example arepadded to some amount of bytes thus using fast compare which only checks some amount of data and do not bother for checking ends, etc 9you know what i mean) On Thu, 13 Aug 2015 12:30:19 -0700, fir saw fit to publish the following: > can i use such form of adding zeros to the strings/literals to 'pad' > them with zeros ? Yes you can. (I feel SOOO presidential right now) > or this is n...

Under kerio Admin screen,local Address I get: 0:0:0:0:phone where "phone" is the local port number. What the hell is that supposed to mean? MikeStevens.invalid@spamtrap.org wrote: > Under kerio Admin screen,local Address I get: 0:0:0:0:phone > > where "phone" is the local port number. What the hell is that supposed to > mean? That's illegal -- there should be nothing coming from 0.0.0.0 at all, on ANY port. Block that IP outright. -- Cinemuck, n.: The combination of popcorn, soda, and melted chocolate which covers the floors of movie thea...

is this the default gateway of whole internet. or is this the default gateway of a whole class A ip addresses. or is this a network address of a particular sub-net. please explain it pragmatically with regards novice wrote: > is this the default gateway of whole internet. > or is this the default gateway of a whole class A ip addresses. > > or is this a network address of a particular sub-net. > please explain it pragmatically > with regards Written that way, it's nothing more than an IP address. On 10/04/2010 02:53 PM, novice wrote: > is this the default gatewa...

I noticed so many extensions in the /usr/lib directory of my Linux system. .so stands for shared object but also there are other extensions can anyone please explain or atleast give pointers to where I can find information about these extensions in details. regards, Onkar onkar <onkar.n.m@gmail.com> wrote: > I noticed so many extensions in the /usr/lib directory of my Linux > system. .so stands for shared object but also there are other > extensions can anyone please explain or atleast give pointers to where > I can find information about these extensions in details. Sorry, but you're in the wrong group with this. This group is about the C programming language, but what you want to know is something concerning the naming conventions for some types of files under Linux which is completely unrelated to C. You probably will find much more help in a newsgroup dedicated to programming under Linux, e.g. comp.os.linux.development.apps, or a group for programming under Unix, comp.unix.programmer (since your question is actually not Linux specific). Regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de onkar wrote: > I noticed so many extensions in the /usr/lib directory of my Linux > system. .so stands for shared object but also there are other > extensions can anyone please explain or atleast give pointers to where > I can find informati...

dear friends, i have t vector; t=linspace(0,.00007,76); k vector is [0 0 0 1......1 0 0 ..], its like all zeros except two 1`s, on a different time instants. when i apply this command ; k=interp1(tau,k,t); tau is also the same as t. one question is that,do we need to interpolate the vector k from one time vector to another of the same length? as here length(t)=length(tau). second question is that when i apply this command, the vector k is returned as a single entry???? please help me on this one. thanks "salman " <salmanabdullah9@gmail.com> wrote in message <iujd42$s...

Hi Jens, and others, On Mar 7, 6:10 pm, Jens-Peer Kuska <k...@informatik.uni-leipzig.de> wrote: > Hi, > > X /: Dot[X, a : {0 ..}] := a > > will help. Ah! TagSet, I get it; very useful. Mathematica is rather amazing. Its syntax is more flexible than I can imagine, coming from another system & TeX. Thanks all, Will ...

I've read over and over that Python leaves floating point issues up to the underlying platform. This seems to be largely true, but not always. My underlying platform (IA32 Linux) correctly handles 1.0/0.0 and 0.0/0.0 according to the IEEE 754 standard, but Python goes out of its way to do the wrong thing. 1/0 is defined by the standard as +Inf and 0/0 is NaN. That's what my platform does for programs written in C. Python apparently checks for division by zero and throws and exception rather than returning the correct value calculated by the underlying platform. Is there any way...

Does anybody know what this ip is ? TCP 0.0.0.0.3965 Please reply, thank you "Mike Xu" <mxu@emscan.com> wrote in message news:41A7778C.7B95B9EB@emscan.com... > Does anybody know what this ip is ? > TCP 0.0.0.0.3965 I beleive this is IP 0.0.0.0 port 3965. AFAIK IP 0.0.0.0 is an invalid IP address, usually an unassigned one. > Please reply, thank you > ...

NIS2004 told me a remote computer at ip 0.0.0.0 is trying to access my computer, and asked if it should allow it. I'm thinking that is probably just the dsl modem and I should allow it. Can anyone confirm or instruct? "Adam Russell" <REMOVE_THIS_adamrussell@sbcglobal.net> wrote in message news:<bro2a6$5lbqu$1@ID-122512.news.uni-berlin.de>... > NIS2004 told me a remote computer at ip 0.0.0.0 is trying to access my > computer, and asked if it should allow it. I'm thinking that is probably > just the dsl modem and I should allow it. Can anyone confirm...

hi, OS: FreeBSD 4.9-Release im starting the dhclient at bootup from the rc.conf file. in the process list it shows as: /sbin/dhclient -pf /var/run/dhclient.ed1.pid ed1 the ipaddress leased shows: # ifconfig -a .... faith0: flags=8002<BROADCAST,MULTICAST> mtu 1500 ed1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:02:dd:1f:10:89 after killing the dhclient process and starting it again with: # dhclient everything is fine and i get a working ipaddress. my dhcp config parameters in rc.conf are standard (sysinstall generated). Since my rc.firewall script automatically finds the ipaddress i will have to restart the firewall as well. Does someone have a clue how to persuade dhclient to find the right ip-address at bootup? Also there is no logentry leading to any problems with dhclient. Thanks in advance, sake. sake@snafu.de (sake) writes: > im starting the dhclient at bootup from the rc.conf file. > in the process list it shows as: > /sbin/dhclient -pf /var/run/dhclient.ed1.pid ed1 > the ipaddress leased shows: > # ifconfig -a > ... > faith0: flags=8002<BROADCAST,MULTICAST> mtu 1500 > ed1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > ether 00:02:dd:1f:10:89 > > after killing the dh...

Hi all. on windows it seems to be an illegal address, on solaris/linux it gives you a login on the localhost. could someone point to some more info on 0.0.0.0 ? yes, I already googled. On Jul 30, 7:08=A0am, adirtymindisajoyforever <getridofthes...@yahoo.com> wrote: > Hi all. > > on windows it seems to be an illegal address, on solaris/linux it > gives you > a login on the localhost. > > could someone point to some more info on 0.0.0.0 ? In principle, if you mean 0.0.0.0 as a destination address, it could just as well be illegal. I don't t...

Hi, I some doubts question regarding a Cisco config. In the config I can see the following two lines: ip route 0.0.0.0 0.0.0.0 192.168.1.1 ip route 0.0.0.0 0.0.0.0 192.168.1.2 I know that these addresses are active in two interfaces. We had a 2Mbit connection that was upgraded to 4 Mbit. Our ISP told us to add the routes and that with those two routes we would be able to use the two links as one. Is this true with Cisco's CEF? My question is: 1. what's the route selected by the packets? Thanks, NC Nuno Cristelo wrote: > Hi, > > I some doubts question regarding a C...

I have a cable router/firewall for my small LAN, and it allows several computers to access the internet. It is a Linksys BEFSX41DS. My LAN is wired, FWIW. I have looked at the routing table within the router: Routing Table Entry List Destination Mask Gateway Hops Interface 0.0.0.0 0.0.0.0 x.x.x.x 1 WAN x.x.x.x 255.255.252.0 0.0.0.0 1 WAN 192.168.1.0 255.255.255.0 0.0.0.0 1 LAN I've obscured my cable modem's unique IP address wi...

When redistributing a default route learned via EIGRP into BGP it seems the route will not propagate into the BGP table unless you have network 0.0.0.0 configured under BGP. Does anyone know why this is necessary? A safety measure perhaps? Thanks! You can also do this with a "neighbor x.x.x.x default-originate" command under "router bgp" BGP was designed for the Internet, where there is no default-route. Scott "Paul Thompson" <shinobi2@sympatico.ca> wrote in message news:v5o2t2dpq2653k37q2ki830dsae2728n5q@4ax.com... > When redistributing a default...

So my program has the following function at the moment to replace -0.0 with +0.0 in a function argument: static inline double sign_flat(double v) { if (v == 0.0) return 0.0; return v; } But when compiling with the Intel Compiler icc at optimization level -O2 or higher the above still produces -0.0. This raises two questions: 1. is the compiler free to convert above function into a NOP? 2. does anyone know a work-around or even more suitable formulation to achieve the same? Preferably not some integer operations using signbit since our main system is a Power6 which...

Hello, Problem: Input: k=[k1 k2 k3 k4 k5..kn], n<=15, for example k=[1 2 3 4 5] z=zeros(1, m), 30<=m <= 100, for example z =[0 0 0 0 0 ...0] , a vector with 40 0-valued components. Output: (Questions) (1) Is it possible to efficiently unique permute [k z]? (2) how to use sparse matrix property in this case for the purpose of saving memory? Matllab's prems() function can't handle it, since the numbre of components is >> 10. John D'Errico posed his uniqueperms function in FEx which uses recursive algorithm, but I tested and found my problem being too large fo...

Hi, all. This question came up in a code review: are null pointers legal as arguments to memcpy? That is, is the program at the end of this article strictly conforming? (Of course, I check the FAQ first and could not find an answer on point.) I don't have C89 or C99 handy, so I checked draft N869 from here: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/n869.txt.gz I note the following: 7.21.1 String function conventions Where an argument declared as "size_t n" specifies the length of the array for a function, "n" can have the value z...

Why is there a 224.0.0.0 in all systems and why do I need it? seems to me it wastes good system overhead. Carl ...

#include "callFirst.hpp" //contain iostream, namespace, and basic operations int main() { int x[10]; int Ops; for(int i = 0; i < 10; i++){ x[i] = i * 2; } int k = 0; while( k < 10){ int j = 0; cout << x[j]; cout << " "; j++; k++; } int dummy; cin >> dummy; return 0; } why I get output as 0 0 0 0 0 0 0 ... suppose it should be 0 2 4 6 ... how do I fix this? m2k_stp@hotmail.com 写道: > #include "callFirst.h...

Puerto Rico residents are heading to the polling stations Sunday to vote in the U.S. Republican primary, in San Juan, Puerto Rico. While Puerto ...

Despite losing, Conor McGregor and Holly Holm both partied in Vegas after their UFC matches – TMZ Farrah Abraham says she was almost assaulted ...

After former first lady Nancy Reagan died on Sunday, it didn’t take long for tributes from the political world to start pouring in. Reagan died ...

CBSSports.com Peyton Manning to retire Monday after 18 NFL seasons: 7 things to know CBSSports.com Peyton Manning is retiring. He informed ...

Maintenance workers shut off the power supply to the elevator after failing to properly check if anyone was inside, state media reported Sunday. ...

Huffington Post Suicide Truck Bomb Kills At Least 60 South Of Baghdad Huffington Post Iraqi emergency responders clear debris from the site ...

Starpulse.com 'Girls' Star Lena Dunham Hospitalized, The Latest On Her Health Starpulse.com "Girls" star Lena Dunham has been hospitalized. ...

Coast Guard Continues Search for Missing Cruise Ship Passenger

National Geographic Scientists discover 'ghostlike' octopus that appears to belong to a previously unknown species Economic Times WASHINGTON: ...

One dog apparently has learnt a new trick: how to drive a semi-truck.

Resources last updated: 3/6/2016 7:11:37 PM