P: n/a

Hi!
Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++?
Is this equivalence an IEEE/ANSI rule? Or is this machine/compiler
dependent?
Any references are welcome!
Thanks in advance, Humberto.  
Share this Question
P: n/a

<hj******@mat.pucrio.br> wrote in message
news:11*********************@g44g2000cwa.googlegro ups.com... Hi!
Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++? Is this equivalence an IEEE/ANSI rule? Or is this machine/compiler dependent?
Any references are welcome!
In C, consider what happens if e.g. b==MIN_INT .
In C++, consider that any operator could be overloaded, and that
different [set of] operators is called in each case.
 Risto   
P: n/a

It is not the same.
Consider (ab) is smaller than the smallest possible value.
A special case of this are unsigned types.
marc  
P: n/a

<hj******@mat.pucrio.br>: Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++? Is this equivalence an IEEE/ANSI rule? Or is this machine/compiler dependent?
If a and b are unsigned, then of course : No!
#include <stdio.h>
int main()
{
unsigned a = 1, b = 2;
printf("%d %c= %d\n", a >= b, "!="[(a >= b) == (a  b >= 0)], a  b >=
0);
}
and even if a and b are ints, the answer is: No!
#include <stdio.h>
#include <limits.h>
int main()
{
int a = INT_MIN, b = INT_MAX;
printf("%d %c= %d\n", a >= b, "!="[(a >= b) == (a  b >= 0)], a  b >=
0);
}
Jirka  
P: n/a
 hj******@mat.pucrio.br wrote: Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++?
There is no such thing as C/C++. And AFA C++ is concerned, no, the
expressions are not equivalent. 'a' and 'b' can be objects of some
UDT that either redefines operators >= or , or just doesn't have them
defined at all.
Is this equivalence an IEEE/ANSI rule? Or is this machine/compiler dependent?
Nope. Yep. I don't know. You didn't specify what 'a' and 'b' are.
V  
P: n/a
 hj******@mat.pucrio.br wrote: Hi!
Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++? Is this equivalence an IEEE/ANSI rule? Or is this machine/compiler dependent?
IEEE gradual underflow and infinity implementation is designed to
support this equivalence for floating point arithmetic, in case, for
example, (double)a  b < DBL_MIN. Several important platforms have
dropped support for gradual underflow; it is not assumed by C or C++. http://grouper.ieee.org/groups/754/faq.html#underflow
Still, compiler optimizers may act as if the equivalence were valid,
even on platforms where it is not.  
P: n/a

"Tim Prince" <tp*****@nospamcomputer.org> wrote in message
news:gE****************@newssvr29.news.prodigy.net ... hj******@mat.pucrio.br wrote: Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++? Is this equivalence an IEEE/ANSI rule? Or is this machine/compiler dependent? IEEE gradual underflow and infinity implementation is designed to support this equivalence for floating point arithmetic, in case, for example, (double)a  b < DBL_MIN. Several important platforms have dropped support for gradual underflow; it is not assumed by C or C++. http://grouper.ieee.org/groups/754/faq.html#underflow Still, compiler optimizers may act as if the equivalence were valid, even on platforms where it is not.
Well summarized. Note that for fixedpoint, the equivalence does
not necessarily hold. If (a  b) overflows, the test result can
easily be wrong. Having said that, I have to confess that the
Whitesmiths compiler generated code like this for the Intel 8080
family. Nobody ever complained.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com  
P: n/a

Hello,
My name is George Tsalamandris with Chase Winters Executive Search. I
am currently conducting a search for a Application/ Developer Architect
for a major global financial institution.
Below please find a position description for your review. Please
forward to anyone that miught be interested in disscussing this
opportunity. The position is located in Chicago. Look forward to
hearing from you.
George Tsalamandris gn*@chasewinters.com
3124219080
General Job Responsibilities:
Complete system development lifecycle (analysis, design, development,
test, release, and support) for Global Instrument Reference Data
platform.
Qualifications:
Experience:
510 as a developer / application architect in the financial industry;
5+ years with reference data
Technical Skills:
Object Oriented Analysis and Design
C++(including STL) Expertise
Sybase Database Expertise
ODBC Programming Expertise
Experience with the G3 Object Model
Technical Writing, Documentation
Code Generation Experience
Multithreaded Linux Server Development Experience
UML Knowledge
Persistence/ObjecttoRelational Mapping Tool Experience
GCC, GNUmake Experience
Linux Operating System Experience
Scripting Language Experience
Leadership / Project Management Skills:
5 Years experience as a technical team lead
Project scheduling and planning with Microsoft Project
Release Management
Defect Management using Clear Quest
Business Knowledge:
Broad product knowledge required including derivative, fixed income,
and equity products. Must have knowledge of the trade lifecycle and
corporate actions. hj******@mat.pucrio.br wrote: Hi!
Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++? Is this equivalence an IEEE/ANSI rule? Or is this machine/compiler dependent?
Any references are welcome!
Thanks in advance, Humberto.  
P: n/a

In article <gE****************@newssvr29.news.prodigy.net>,
Tim Prince <tp*****@nospamcomputer.org> wrote: hj******@mat.pucrio.br wrote: Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++? Is this equivalence an IEEE/ANSI rule? Or is this machine/compiler dependent?
IEEE gradual underflow and infinity implementation is designed to support this equivalence for floating point arithmetic, in case, for example, (double)a  b < DBL_MIN.
Going outside the C standard itself a little (since IEEE floating
point is not part of that standard anyhow): I recall that there
are some unusual rules having to do with comparison operators
and special values, especially NaN. I do not recall the
details, though.
a >= b would have information about two special values available
at the time of the comparison, whereas a  b >= 0 would only
have information about one special value available at the time
of the comparison. Are there perchance particular special values
for which that would make a difference? Or, for example,
in the case of a  b when one of the two values was a
signalling NaN, would the signal be taken due to the arithmetic
operator, but not taken in the a >= b case ?
ISTR that the general rule for NaN's is that the result of
any comparison with them is "false"  one of the standard ways
of detecting them is to detect the case where a >= b and b < a
are both false. I do not, though, recall the rules for the
other special values.

The rule of thumb for speed is:
1. If it doesn't work then speed doesn't matter.  Christian Bau  
P: n/a
 gn*@chasewinters.com wrote: Hello, My name is [...]
Job adverts are a gross violation of topicality in comp.lang.c++.  
P: n/a

Funny you should mention the Whitesmith compiler. In fact I think most
of us knew about the problem at the "extremes" and took that into
account. I know I dealt with it in writing some software for a nuclear
reactor system that was deployed in Georgia.
I remember as part of a CS degree having classes on interval analysis,
something that came into existence and out almost as fast. There was
only one machine I worked on that used it as part of the processor. It
was for a specialized project to bounce signals off of the surface of
clouds. Of course that and all the numerical analysis classes helped in
dealing with these issues.
I wonder what they teach now a days?
Chuck Wegrzyn
P.J. Plauger wrote: "Tim Prince" <tp*****@nospamcomputer.org> wrote in message news:gE****************@newssvr29.news.prodigy.ne t...
hj******@mat.pucrio.br wrote:
Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++? Is this equivalence an IEEE/ANSI rule? Or is this machine/compiler dependent? IEEE gradual underflow and infinity implementation is designed to support this equivalence for floating point arithmetic, in case, for example, (double)a  b < DBL_MIN. Several important platforms have dropped support for gradual underflow; it is not assumed by C or C++. http://grouper.ieee.org/groups/754/faq.html#underflow Still, compiler optimizers may act as if the equivalence were valid, even on platforms where it is not.
Well summarized. Note that for fixedpoint, the equivalence does not necessarily hold. If (a  b) overflows, the test result can easily be wrong. Having said that, I have to confess that the Whitesmiths compiler generated code like this for the Intel 8080 family. Nobody ever complained.
P.J. Plauger Dinkumware, Ltd. http://www.dinkumware.com  
P: n/a

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:Sc*******************@newsread1.mlpsca01.us.t o.verio.net... gn*@chasewinters.com wrote: Hello, My name is [...]
Job adverts are a gross violation of topicality in comp.lang.c++.
Not to mention the fact that, as a reply to the given question, it misses
the mark by a country mile! :)
Howard  
P: n/a
 gn*@chasewinters.com writes: Hello,
Goodbye.
My name is George Tsalamandris with Chase Winters Executive Search. I am currently conducting a search for a Application/ Developer Architect for a major global financial institution.
This is not the place to post job offers.

Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.  
P: n/a

C Wegrzyn wrote
(in article <43************@hotmail.com>): I remember as part of a CS degree having classes on interval analysis, something that came into existence and out almost as fast.
.....
I wonder what they teach now a days?
Chuck Wegrzyn
How to customize websites with music and animation.
*sigh*

Randy Howard (2reply remove FOOBAR)  
P: n/a

"P.J. Plauger" <pj*@dinkumware.com> wrote in message
news:Sp********************@giganews.com... "Tim Prince" <tp*****@nospamcomputer.org> wrote in message
Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++? Is this equivalence an IEEE/ANSI rule? Or is this machine/compiler dependent?
IEEE gradual underflow and infinity implementation is designed to support this equivalence for floating point arithmetic, in case, for example, (double)a  b < DBL_MIN. Several important platforms have dropped support for gradual underflow; it is not assumed by C or C++. http://grouper.ieee.org/groups/754/faq.html#underflow Still, compiler optimizers may act as if the equivalence were valid, even on platforms where it is not.
Well summarized. Note that for fixedpoint, the equivalence does not necessarily hold. If (a  b) overflows, the test result can easily be wrong. Having said that, I have to confess that the Whitesmiths compiler generated code like this for the Intel 8080 family. Nobody ever complained.
Unfortunately, the equivalence doesn't always hold for floatingpoint
either.
Consider the case where a is a very large positive number and b is a very
large negative number. Then a >= b will presumably yield true, but a  b
might overflow.
I think I agree with PJP that in the presence of IEEE gradual underflow,
it's not an issue that a and b might be small (or not close to the limits,
anyway) and very nearly equal.  
P: n/a

In article <df**********@canopus.cc.umanitoba.ca> ro******@ibd.nrccnrc.gc.ca (Walter Roberson) writes:
.... Going outside the C standard itself a little (since IEEE floating point is not part of that standard anyhow): I recall that there are some unusual rules having to do with comparison operators and special values, especially NaN. I do not recall the details, though.
Yup, all standard comparisons with NaNs yield false. This means, for
instance, that when a and b ara NaNs, a >= b == a <= b == FALSE.

dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/  
P: n/a

In article <u5*******************@bgtnsc04news.ops.worldnet.att.net> "Andrew Koenig" <ar*@acm.org> writes:
.... Unfortunately, the equivalence doesn't always hold for floatingpoint either.
Consider the case where a is a very large positive number and b is a very large negative number. Then a >= b will presumably yield true, but a  b might overflow.
In that case a  b yields +inf, and +inf >= 0.

dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/  
P: n/a

In article <IM********@cwi.nl>, Dik T. Winter <Di********@cwi.nl> wrote:
In article <df**********@canopus.cc.umanitoba.ca> ro******@ibd.nrccnrc.gc.ca (Walter Roberson) writes: ... > Going outside the C standard itself a little (since IEEE floating > point is not part of that standard anyhow): I recall that there > are some unusual rules having to do with comparison operators > and special values, especially NaN. I do not recall the > details, though.
Yup, all standard comparisons with NaNs yield false. This means, for instance, that when a and b ara NaNs, a >= b == a <= b == FALSE.
Pedantic nitpick: "!=" is a comparison but yields true for NaNs.  
P: n/a

In article <dwLTe.6013$mH.5072@fed1read07>,
Anonymous 7843 <an******@example.com> wrote: In article <IM********@cwi.nl>, Dik T. Winter <Di********@cwi.nl> wrote:
In article <df**********@canopus.cc.umanitoba.ca> ro******@ibd.nrccnrc.gc.ca (Walter Roberson) writes: ... > Going outside the C standard itself a little (since IEEE floating > point is not part of that standard anyhow): I recall that there > are some unusual rules having to do with comparison operators > and special values, especially NaN. I do not recall the > details, though.
Yup, all standard comparisons with NaNs yield false. This means, for instance, that when a and b ara NaNs, a >= b == a <= b == FALSE.
Pedantic nitpick: "!=" is a comparison but yields true for NaNs.
Me again. I felt the urge for a pretty picture, so here it
is, as seen from an IEEE854ish machine:
compare NaN Inf 1e+10 1 1e10 0 1e10 1e+10 Inf NaN
          
NaN != != != != != != != != != !=
Inf != == < < < < < < < !=
1e+10 != > == < < < < < < !=
1 != > > == < < < < < !=
1e10 != > > > == < < < < !=
0 != > > > > == < < < !=
1e10 != > > > > > == < < !=
1e+10 != > > > > > > == < !=
Inf != > > > > > > > == !=
NaN != != != != != != != != != !=
quickie code
#include <stdio.h>
int main(void)
{
double inf, nan;
double sample[] = {0, 0, 1E+10, 1, 1E10, 0, +1E10, +1E+10, 0, 0};
size_t i, j, len;
sscanf("Inf", "%lf", &inf);
sscanf("NaN", "%lf", &nan);
sample[0] = nan;
sample[1] = inf;
sample[8] = inf;
sample[9] = nan;
len = sizeof(sample) / sizeof(sample[0]);
printf("compare ");
for (j = 0; j < len; j++)
printf(" %6g", sample[j]);
printf("\n");
printf(" ");
for (j = 0; j < len; j++)
printf(" ");
printf("\n");
for (i = 0; i < len; i++)
{
printf("%6g ", sample[i]);
for (j = 0; j < len; j++)
{
if (sample[i] == sample[j]) printf(" == ");
else if (sample[i] > sample[j]) printf(" > ");
else if (sample[i] < sample[j]) printf(" < ");
else if (sample[i] >= sample[j]) printf(" >= ");
else if (sample[i] <= sample[j]) printf(" <= ");
else if (sample[i] != sample[j]) printf(" != ");
}
printf("\n");
}
return 0;
}  
P: n/a

In article <dwLTe.6013$mH.5072@fed1read07> an******@example.com writes: In article <IM********@cwi.nl>, Dik T. Winter <Di********@cwi.nl> wrote:
.... Yup, all standard comparisons with NaNs yield false. This means, for instance, that when a and b ara NaNs, a >= b == a <= b == FALSE.
Pedantic nitpick: "!=" is a comparison but yields true for NaNs.
Indeed, forgot that one. The pleasure of having a != a.

dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/  
P: n/a

"Dik T. Winter" <Di********@cwi.nl> wrote in message
news:IM********@cwi.nl... In article <u5*******************@bgtnsc04news.ops.worldnet.att.net> "Andrew Koenig" <ar*@acm.org> writes:
Consider the case where a is a very large positive number and b is a very large negative number. Then a >= b will presumably yield true, but a  b might overflow.
In that case a  b yields +inf, and +inf >= 0.
Unless the implementation is set to trap. If it's not an IEEE
implementation, it might even trap by default.  
P: n/a

<hj******@mat.pucrio.br> wrote in message
news:11*********************@g44g2000cwa.googlegro ups.com... Hi!
Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++? Is this equivalence an IEEE/ANSI rule? Or is this machine/compiler dependent?
Any references are welcome!
Thanks in advance, Humberto.
Read the replies, but am not positive if this was covered yet. Consider the
case where a is a very large double and b a very small value. With doubles
(and floates) and precision it could be the case where a  b does not
actually change a, even when b != 0.
so in that case (a >= b) != (a  b > 0) would wield true.  
P: n/a

In article <f0*************@fe07.lga>,
Jim Langston <ta*******@rocketmail.com> wrote: <hj******@mat.pucrio.br> wrote in message news:11*********************@g44g2000cwa.googlegr oups.com... Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++?
Read the replies, but am not positive if this was covered yet. Consider the case where a is a very large double and b a very small value. With doubles (and floates) and precision it could be the case where a  b does not actually change a, even when b != 0.
so in that case (a >= b) != (a  b > 0) would wield true.
Hmmm, perhaps I am missing something in your answer:
If a  b does not change a then a  b is (to the precision of the
machine) equivilent to a, and the latter part of your logical expression
would become (a > 0) . You are postulating the case where a is a large
double, so a is either large and positive or large and negative.
(a > 0) will be true for the large and positive case, and false for the
large and negative case.
If we look at the large and positive case, with [under your conditions]
b as a very small value, then no matter which side of zero b happens to be,
the large and positive a is going to be greater than the small b, so
(a >= b) will be true, and thus (a >= b) == (a  b > 0) for this case.
If we look at the large and negative case, with [under your conditions]
b as a very small value,l then again no matter which side of zero b happens
to be, the large and negative a is going to be less than the small b,
so (a >= b) will be false, and thus (a >= b) == (a  b > 0) for this case.
Hence, under the conditions you indicate, with a large and b very small,
(a >= b) == (a  b > 0)

"Who Leads?" / "The men who must... driven men, compelled men."
"Freak men."
"You're all freaks, sir. But you always have been freaks.
Life is a freak. That's its hope and glory."  Alfred Bester, TSMD  
P: n/a

"Walter Roberson" <ro******@ibd.nrccnrc.gc.ca> wrote in message
news:df**********@canopus.cc.umanitoba.ca... In article <f0*************@fe07.lga>, Jim Langston <ta*******@rocketmail.com> wrote:<hj******@mat.pucrio.br> wrote in message news:11*********************@g44g2000cwa.googleg roups.com... Is the expression "a >= b" equivalent to "a  b >= 0" in C/C++?
Read the replies, but am not positive if this was covered yet. Consider the case where a is a very large double and b a very small value. With doubles (and floates) and precision it could be the case where a  b does not actually change a, even when b != 0.
so in that case (a >= b) != (a  b > 0) would wield true.
Hmmm, perhaps I am missing something in your answer:
If a  b does not change a then a  b is (to the precision of the machine) equivilent to a, and the latter part of your logical expression would become (a > 0) . You are postulating the case where a is a large double, so a is either large and positive or large and negative. (a > 0) will be true for the large and positive case, and false for the large and negative case.
If we look at the large and positive case, with [under your conditions] b as a very small value, then no matter which side of zero b happens to be, the large and positive a is going to be greater than the small b, so (a >= b) will be true, and thus (a >= b) == (a  b > 0) for this case.
If we look at the large and negative case, with [under your conditions] b as a very small value,l then again no matter which side of zero b happens to be, the large and negative a is going to be less than the small b, so (a >= b) will be false, and thus (a >= b) == (a  b > 0) for this case.
Hence, under the conditions you indicate, with a large and b very small, (a >= b) == (a  b > 0)
Hmmm... true.
Ignore everything I said after... umm.. ignore everything I said.  
P: n/a

In article <IM********@cwi.nl>, Dik T. Winter <Di********@cwi.nl> wrote: In article <dwLTe.6013$mH.5072@fed1read07> an******@example.com writes: > In article <IM********@cwi.nl>, Dik T. Winter <Di********@cwi.nl> wrote: ... > > Yup, all standard comparisons with NaNs yield false. This means, for > > instance, that when a and b ara NaNs, a >= b == a <= b == FALSE. > > Pedantic nitpick: "!=" is a comparison but yields true for NaNs.
Indeed, forgot that one. The pleasure of having a != a.
Antiobjectivism?   This discussion thread is closed Replies have been disabled for this discussion.   Question stats  viewed: 3048
 replies: 24
 date asked: Sep 7 '05
