473,324 Members | 2,511 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

Determine which sum is larger

Howdy,

I have four unsigned long longs a, b, c, d. I want to determine whether
a+b or c+d is larger, as if there were no overflow. That is, ULLONG_MAX
+ 5 should be considered larger than 10 + 20.

The best approach I have thought of so far is to check for overflow in
both sums; if exactly one overflows, that one is larger. Otherwise,
compare the sums normally. Is there a better way?

Thanks for any ideas!
-Peter
Nov 19 '07 #1
30 1860
Peter Ammon said:
Howdy,
Hi Peter, ltns.
>
I have four unsigned long longs a, b, c, d. I want to determine whether
a+b or c+d is larger, as if there were no overflow.
There isn't any overflow, of course, because unsigned types can't overflow.

Your question involves unsigned long long ints, but in fact we can ignore
that, and focus on the fact that they are unsigned types than which we
cannot guarantee having a wider type available.
That is, ULLONG_MAX
+ 5 should be considered larger than 10 + 20.

The best approach I have thought of so far is to check for overflow in
both sums; if exactly one overflows, that one is larger. Otherwise,
compare the sums normally. Is there a better way?
Apart from the nitpick about the word "overflow", I can see no problem with
your existing solution. Any other way is likely to be more complicated.

I did play around with reducing the values a bit - for example, if(a c) {
a -= c; c = 0; } else { c -= a; a = 0; } and the same for b, d - but I
couldn't see it leading anywhere useful. If a and c were known to share a
high value bit (that is, both were at least half the maximum possible
value for the type), and b and d likewise, it could conceivably have been
useful if you really needed to avoid value wrapping for some reason.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Nov 19 '07 #2
On Nov 19, 12:18 am, Peter Ammon <gersh...@splintermac.comwrote:
Howdy,

I have four unsigned long longs a, b, c, d. I want to determine whether
a+b or c+d is larger, as if there were no overflow. That is, ULLONG_MAX
+ 5 should be considered larger than 10 + 20.

The best approach I have thought of so far is to check for overflow in
both sums; if exactly one overflows, that one is larger. Otherwise,
compare the sums normally. Is there a better way?

Thanks for any ideas!
-Peter
Hi Peter!

We won't overflow if we check half the sum. Since we lose data, we
clarify unclear results by checking the remainders we snipped out.

int compareULLSums( unsigned long long a, unsigned long long b,
unsigned long long c, unsigned long long d )
{
unsigned long long s1 = (a/2+b/2), s2 = (c/2+d/2);
if( s1 s2 || ( s1 == s2 && ( (a%2+b%2) (c%2+d%2) ) ) )
return 1;
return 0;
}

Hope this helps!
- Sam
Nov 19 '07 #3
Richard Heathfield wrote:
Peter Ammon said:
>I have four unsigned long longs a, b, c, d. I want to determine whether
a+b or c+d is larger, as if there were no overflow.

Your question involves unsigned long long ints, but in fact we can ignore
that, and focus on the fact that they are unsigned types than which we
cannot guarantee having a wider type available.
>That is, ULLONG_MAX
+ 5 should be considered larger than 10 + 20.

The best approach I have thought of so far is to check for overflow in
both sums; if exactly one overflows, that one is larger. Otherwise,
compare the sums normally. Is there a better way?

Apart from the nitpick about the word "overflow", I can see no problem with
your existing solution. Any other way is likely to be more complicated.

I did play around with reducing the values a bit - for example, if(a c) {
a -= c; c = 0; } else { c -= a; a = 0; } and the same for b, d - but I
couldn't see it leading anywhere useful.
After that process, you have four possibilities:
a == b == 0, a == d == 0, c == b == 0, and c == d == 0.

If a == b == 0, then finding the smaller sum is trivial.
Otherwise if a == d == 0, then b c gives the comparison you want.
Other cases are handled similarly.

I agree that this is probably more complicated than the OP's original
idea though.

--
Philip Potter pgp <atdoc.ic.ac.uk
Nov 19 '07 #4
Philip Potter said:
Richard Heathfield wrote:
<snip>
>I did play around with reducing the values a bit - for example, if(a >
c) { a -= c; c = 0; } else { c -= a; a = 0; } and the same for b, d -
but I couldn't see it leading anywhere useful.

After that process, you have four possibilities:
a == b == 0, a == d == 0, c == b == 0, and c == d == 0.

If a == b == 0, then finding the smaller sum is trivial.
Otherwise if a == d == 0, then b c gives the comparison you want.
Other cases are handled similarly.
See, that's why we have Usenet - so one person can kickstart an idea, and
someone else can carry it on...
I agree that this is probably more complicated than the OP's original
idea though.
....and then consign it to the dustbin of history. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Nov 19 '07 #5
Catsby wrote:
On Nov 19, 12:18 am, Peter Ammon <gersh...@splintermac.comwrote:
>Howdy,

I have four unsigned long longs a, b, c, d. I want to determine whether
a+b or c+d is larger, as if there were no overflow. That is, ULLONG_MAX
+ 5 should be considered larger than 10 + 20.

The best approach I have thought of so far is to check for overflow in
both sums; if exactly one overflows, that one is larger. Otherwise,
compare the sums normally. Is there a better way?
We won't overflow if we check half the sum. Since we lose data, we
clarify unclear results by checking the remainders we snipped out.

int compareULLSums( unsigned long long a, unsigned long long b,
unsigned long long c, unsigned long long d )
{
unsigned long long s1 = (a/2+b/2), s2 = (c/2+d/2);
if( s1 s2 || ( s1 == s2 && ( (a%2+b%2) (c%2+d%2) ) ) )
return 1;
return 0;
}
What does this say about 5+3 compared with 4+4?

Shouldn't the result of a comparison have three states?

--
Thad
Nov 19 '07 #6
Thad Smith wrote:
Catsby wrote:
>On Nov 19, 12:18 am, Peter Ammon <gersh...@splintermac.comwrote:
>>Howdy,

I have four unsigned long longs a, b, c, d. I want to determine whether
a+b or c+d is larger, as if there were no overflow. That is, ULLONG_MAX
+ 5 should be considered larger than 10 + 20.

The best approach I have thought of so far is to check for overflow in
both sums; if exactly one overflows, that one is larger. Otherwise,
compare the sums normally. Is there a better way?
>We won't overflow if we check half the sum. Since we lose data, we
clarify unclear results by checking the remainders we snipped out.

int compareULLSums( unsigned long long a, unsigned long long b,
unsigned long long c, unsigned long long d )
{
unsigned long long s1 = (a/2+b/2), s2 = (c/2+d/2);
if( s1 s2 || ( s1 == s2 && ( (a%2+b%2) (c%2+d%2) ) ) )
return 1;
return 0;
}

What does this say about 5+3 compared with 4+4?
Exactly the same as for 4+4 compared with 4+4.
Shouldn't the result of a comparison have three states?
It depends. This function seems to emulate greater-than, rather than a
three-state strcmp()-style return value. This may be the correct thing,
though it's poorly named if so.
Nov 19 '07 #7
Philip Potter wrote:
Thad Smith wrote:
>Catsby wrote:
>>int compareULLSums( unsigned long long a, unsigned long long
b, unsigned long long c, unsigned long long d )
{
unsigned long long s1 = (a/2+b/2), s2 = (c/2+d/2);
if( s1 s2 || ( s1 == s2 && ( (a%2+b%2) (c%2+d%2) ) ) )
return 1;
return 0;
}

What does this say about 5+3 compared with 4+4?

Exactly the same as for 4+4 compared with 4+4.
OK, right so far (assuming the first expression corresponds
to the first function argument).
>Shouldn't the result of a comparison have three states?

It depends. This function seems to emulate greater-than,
rather than a three-state strcmp()-style return value. This
may be the correct thing, though it's poorly named if so.
So you would accept the function's claim "4+4 5+3"?

-- Ralf
Nov 20 '07 #8
Ralf Damaschke wrote:
Philip Potter wrote:
>Thad Smith wrote:
>>Catsby wrote:
int compareULLSums( unsigned long long a, unsigned long long
b, unsigned long long c, unsigned long long d )
{
unsigned long long s1 = (a/2+b/2), s2 = (c/2+d/2);
if( s1 s2 || ( s1 == s2 && ( (a%2+b%2) (c%2+d%2) ) ) )
return 1;
return 0;
}
What does this say about 5+3 compared with 4+4?
Exactly the same as for 4+4 compared with 4+4.
So you would accept the function's claim "4+4 5+3"?
Er... no! Good catch.
Nov 20 '07 #9
Peter Ammon wrote:
Howdy,

I have four unsigned long longs a, b, c, d. I want to determine whether
a+b or c+d is larger, as if there were no overflow. That is, ULLONG_MAX
+ 5 should be considered larger than 10 + 20.

The best approach I have thought of so far is to check for overflow in
both sums; if exactly one overflows, that one is larger. Otherwise,
compare the sums normally. Is there a better way?
Not only will your approach work, but it looks simple and require little
overhead too, so I can't really come up with something "better"...

However, let say you find the two smallest numbers of the set {a,b,c,d},
if it's {a,b} or {c,d} you have the answer. If not, those two numbers
can be subtracted from the LHS and RHS, the biggest sum is then given by
max(LHS, RHS).

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
Nov 21 '07 #10
On Nov 19, 8:38 am, Richard Heathfield <r...@see.sig.invalidwrote:
There isn't any overflow, of course, because unsigned types can't overflow.
Are you sure? That would be a very useful property.
Nov 21 '07 #11
Bart <bc@freeuk.comwrites:
On Nov 19, 8:38 am, Richard Heathfield <r...@see.sig.invalidwrote:
>There isn't any overflow, of course, because unsigned types can't overflow.

Are you sure? That would be a very useful property.
Yes. Well I am, and I am pretty sure Richard Heathfield is sure too!

6.2.5 p9 says (in part):

... A computation involving unsigned operands can never overflow,
because a result that cannot be represented by the resulting
unsigned integer type is reduced modulo the number that is one
greater than the largest value that can be represented by the
resulting type.

Outside of the context of standard C, the term overflow is sometimes
used to refer to the warp-around that sometimes happens in both signed
and unsigned arithmetic but, when talking about C, it is better to
stick to the standard terminology.

--
Ben.
Nov 21 '07 #12
On Nov 21, 2:07 am, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
Bart <b...@freeuk.comwrites:
On Nov 19, 8:38 am, Richard Heathfield <r...@see.sig.invalidwrote:
There isn't any overflow, of course, because unsigned types can't overflow.
Are you sure? That would be a very useful property.

Yes. Well I am, and I am pretty sure Richard Heathfield is sure too!

6.2.5 p9 says (in part):

... A computation involving unsigned operands can never overflow,
because a result that cannot be represented by the resulting
unsigned integer type is reduced modulo the number that is one
greater than the largest value that can be represented by the
resulting type.

Outside of the context of standard C, the term overflow is sometimes
used to refer to the warp-around that sometimes happens in both signed
and unsigned arithmetic but, when talking about C, it is better to
stick to the standard terminology.
That's interesting. So the reason why the following program produces
some 700 million on a 32-bit system instead of 5 billion is nothing to
do with overflow of A+B? It 'wraps' instead?

#include <stdio.h>

void main()
{
unsigned int a,b;

a=3000000000;
b=2000000000;

printf("A = %u\n",a);
printf("B = %u\n",b);
printf("A+B = %u\n",a+b);

}

// Bart
Nov 21 '07 #13
Bart said:

<snip>
So the reason why the following program produces
some 700 million on a 32-bit system instead of 5 billion is nothing to
do with overflow of A+B? It 'wraps' instead?
Since unsigned types can't overflow, the behaviour of your program cannot
be due to overflow of unsigned types as far as the rules of C are
concerned...
>
#include <stdio.h>

void main()
....but this line means that your program's behaviour is not governed by the
rules of C.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Nov 21 '07 #14
Ben Bacarisse wrote:
Bart <bc@freeuk.comwrites:
>Richard Heathfield <r...@see.sig.invalidwrote:
>>There isn't any overflow, of course, because unsigned types
can't overflow.

Are you sure? That would be a very useful property.

Yes. Well I am, and I am pretty sure Richard Heathfield is sure too!

6.2.5 p9 says (in part):

... A computation involving unsigned operands can never overflow,
because a result that cannot be represented by the resulting
unsigned integer type is reduced modulo the number that is one
greater than the largest value that can be represented by the
resulting type.

Outside of the context of standard C, the term overflow is sometimes
used to refer to the warp-around that sometimes happens in both signed
and unsigned arithmetic but, when talking about C, it is better to
stick to the standard terminology.
However it is extremely easy to detect that 'modulo reduction' and
to signal or return the effect of an overflow (in unsigned
arithmetic). Signed is another matter.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Nov 21 '07 #15
Bart <bc@freeuk.comwrites:
On Nov 21, 2:07 am, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
>Bart <b...@freeuk.comwrites:
On Nov 19, 8:38 am, Richard Heathfield <r...@see.sig.invalidwrote:
>There isn't any overflow, of course, because unsigned types
can't overflow.
Are you sure? That would be a very useful property.

Yes. Well I am, and I am pretty sure Richard Heathfield is sure too!

6.2.5 p9 says (in part):

... A computation involving unsigned operands can never overflow,
<snip>
That's interesting. So the reason why the following program produces
some 700 million on a 32-bit system instead of 5 billion is nothing to
do with overflow of A+B? It 'wraps' instead?
It's a matter of terminology, nothing else. The C standard wants to
keep the term "overflow" for those bad cases where the result does not
fit and a signal might have to be raised.

C's arithmetic on unsigned types is arithmetic modulo a power of 2
(determined by the number of values bits in the particular type) and
thus the result always fits. Nothin bad can happen. I don't think of
it as wrapping, I just think of it as modulo arithmetic.

The closer you are to people who the C standard for fun, the more
likely it is that you will be told that unsigned arithmetic can not
overflow. Return to the water-cooler, and you can probably talk about
unsigned overflow without any confusion.

--
Ben.
Nov 21 '07 #16
Richard Heathfield wrote:
Bart said:

<snip>
>So the reason why the following program produces
some 700 million on a 32-bit system instead of 5 billion is nothing to
do with overflow of A+B? It 'wraps' instead?

Since unsigned types can't overflow, the behaviour of your program cannot
be due to overflow of unsigned types as far as the rules of C are
concerned...
>#include <stdio.h>

void main()

...but this line means that your program's behaviour is not governed by the
rules of C.
Except in the unlikely case that his implementation specifies void
main() as an acceptable prototype.
Nov 21 '07 #17
On Nov 21, 4:38 am, Richard Heathfield <r...@see.sig.invalidwrote:
Bart said:
void main()

...but this line means that your program's behaviour is not governed by the
rules of C.
Sorry I tried hard to remember how to declare the main() entry point
properly, but even after several years of lurking in this newgroup, I
don't actually know.

After trying a few arbitrary combinations I find that int main(void)
gives no compiler warnings (even though I don't explicitly return an
int).

My program still gives the wrong result however.

Bart

#include <stdio.h>

int main(void)
{
unsigned int a,b;

a=3000000000;
b=2000000000;

printf("A = %u\n",a);
printf("B = %u\n",b);
printf("A+B = %u\n",a+b);
}
Nov 21 '07 #18
In article
<7c**********************************@l22g2000hsc. googlegroups.com>,
Bart <bc@freeuk.comwrote on Wednesday 21 Nov 2007 6:52 pm:
On Nov 21, 4:38 am, Richard Heathfield <r...@see.sig.invalidwrote:
>Bart said:
void main()

...but this line means that your program's behaviour is not governed
by the rules of C.

Sorry I tried hard to remember how to declare the main() entry point
properly, but even after several years of lurking in this newgroup, I
don't actually know.
The Standard requires hosted implementations to define the following two
signatures for main():

int main(void) { ... }

int main(int argc, char *argv[]) { ... }

Obviously 'argc' and 'argv' can have any legal name, though these two
are the canonical ones. Also '**argv' is an alternative for '*argv[]'.
After trying a few arbitrary combinations I find that int main(void)
gives no compiler warnings (even though I don't explicitly return an
int).
You should return an int value from main() for your program to be
conforming. To be strictly conforming the return value has to be one
among the set: 0, EXIT_SUCCESS, EXIT_FAILURE. The two macros are
defined in stdlib.h.
My program still gives the wrong result however.

Bart

#include <stdio.h>

int main(void)
{
unsigned int a,b;

a=3000000000;
b=2000000000;
An unsigned int is guaranteed to hold values in the range 0... 65535
only. That's because they need not be more than two bytes.

Use unsigned long to hold values till 4294967295 and (with C99 support)
unsigned long long for values upto 18446744073709551615.
printf("A = %u\n",a);
printf("B = %u\n",b);
printf("A+B = %u\n",a+b);
}
Nov 21 '07 #19
Bart said:

<snip>
My program still gives the wrong result however.

Bart

#include <stdio.h>

int main(void)
{
unsigned int a,b;

a=3000000000;
b=2000000000;

printf("A = %u\n",a);
printf("B = %u\n",b);
printf("A+B = %u\n",a+b);
return 0;
}
What is your implementation's value of UINT_MAX? And what result are you
getting? For instance, if UINT_MAX is 4294967295 on your implementation,
you should expect the result of the addition to be 705032704 (which is
5000000000 modulo 4294967296, which - as someone has already explained to
you in this thread - is how unsigned integer arithmetic is done in C). If
your program displays some other result (for that value of UINT_MAX), then
you do indeed have a problem.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Nov 21 '07 #20
santosh said:

<snip>
An unsigned int is guaranteed to hold values in the range 0... 65535
only. That's because they need not be more than two bytes.
No, it is because they need not be more than sixteen bits.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Nov 21 '07 #21
In article <9L******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrote on Wednesday 21 Nov 2007 7:09 pm:
santosh said:

<snip>
>An unsigned int is guaranteed to hold values in the range 0... 65535
only. That's because they need not be more than two bytes.

No, it is because they need not be more than sixteen bits.
Oops. I stand corrected. For a moment I forgot that C's conception
of "byte" is not the same as the widely held one.

Nov 21 '07 #22
santosh said:
In article <9L******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrote on Wednesday 21 Nov 2007 7:09 pm:
>santosh said:

<snip>
>>An unsigned int is guaranteed to hold values in the range 0... 65535
only. That's because they need not be more than two bytes.

No, it is because they need not be more than sixteen bits.

Oops. I stand corrected. For a moment I forgot that C's conception
of "byte" is not the same as the widely held one.
Which widely held one? There are several, but most share the common feature
that a byte is the smallest addressable unit of storage, and this is very
close to C's conception of "byte".

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Nov 21 '07 #23
In article <Ea******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrote on Wednesday 21 Nov 2007 7:21 pm:
santosh said:
>In article <9L******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrote on Wednesday 21 Nov 2007 7:09
pm:
>>santosh said:

<snip>

An unsigned int is guaranteed to hold values in the range 0...
65535 only. That's because they need not be more than two bytes.

No, it is because they need not be more than sixteen bits.

Oops. I stand corrected. For a moment I forgot that C's conception
of "byte" is not the same as the widely held one.

Which widely held one?
Specifically, the one that believes that a byte is eight bits.
There are several, but most share the common
feature that a byte is the smallest addressable unit of storage, and
this is very close to C's conception of "byte".
This too, but I think that the eight bits bytes conception is a very
common one with programmers only exposed to recent micro and mini
computer systems. The fact that TCP/IP defines bytes as eight bits wide
also contributes to this view.

Nov 21 '07 #24
On Nov 21, 1:37 pm, Richard Heathfield <r...@see.sig.invalidwrote:
What is your implementation's value of UINT_MAX? And what result are you
getting? For instance, if UINT_MAX is 4294967295 on your implementation,
you should expect the result of the addition to be 705032704 (which is
5000000000 modulo 4294967296, which - as someone has already explained to
you in this thread - is how unsigned integer arithmetic is done in C). If
your program displays some other result (for that value of UINT_MAX), then
you do indeed have a problem.
UINT_MAX is as expected. And the result 705032704 is exactly what I
would have expected last week. And what I would expect to happen
anywhere else I was using 32-bit unsigned arithmetic.

I just have a problem with this slightly chaotic result (705,032,704
is somewhat different from 5,000,000,000) not being due to 'Overflow'.
5 billion needs 33 bits, it overflows 32 bits.

Truncating such results to 32 bits and ignoring CPU flags seems
perfectly reasonable for a compiler to do with integer arithmetic. But
it is clearly an overflow.

For C to state that unsigned values can't overflow (because the
Standard defines unsigned arithmetic in a certain way) seems
misleading.

And it is clearly an issue in the original problem, (a+b)>(c+d). C has
just redefined the problem to be modulo arithmetic rather than
overflow.

Bart
Nov 21 '07 #25
santosh said:
In article <Ea******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrote on Wednesday 21 Nov 2007 7:21 pm:
>santosh said:
>>Oops. I stand corrected. For a moment I forgot that C's conception
of "byte" is not the same as the widely held one.

Which widely held one?

Specifically, the one that believes that a byte is eight bits.
Oh, that one. (There are others, of course.)
>There are several, but most share the common
feature that a byte is the smallest addressable unit of storage, and
this is very close to C's conception of "byte".

This too, but I think that the eight bits bytes conception is a very
common one with programmers only exposed to recent micro and mini
computer systems.
Yes, it is - but of course there are lots of common misconceptions, of
which that is but one.
The fact that TCP/IP defines bytes as eight bits wide
also contributes to this view.
Do you have a cite? I thought it defined eight-bit objects as octets.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Nov 21 '07 #26
santosh <sa*********@gmail.comwrites:
In article <Ea******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrote on Wednesday 21 Nov 2007 7:21 pm:
>santosh said:
>>In article <9L******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrote on Wednesday 21 Nov 2007 7:09
pm:

santosh said:

<snip>

An unsigned int is guaranteed to hold values in the range 0...
65535 only. That's because they need not be more than two bytes.

No, it is because they need not be more than sixteen bits.

Oops. I stand corrected. For a moment I forgot that C's conception
of "byte" is not the same as the widely held one.

Which widely held one?

Specifically, the one that believes that a byte is eight bits.
>There are several, but most share the common
feature that a byte is the smallest addressable unit of storage, and
this is very close to C's conception of "byte".

This too, but I think that the eight bits bytes conception is a very
common one with programmers only exposed to recent micro and mini
computer systems. The fact that TCP/IP defines bytes as eight bits wide
also contributes to this view.
Of course it is. A "byte" is synonymous with 8 bits in most
instances. Sure, other sizes have and do exist but the "widely held"
belief is indeed that a byte is 8 bits.

The wikipedia page has a reasonable discourse on its usage and its
history over the years which is well written and easy to follow.

http://en.wikipedia.org/wiki/Byte
Nov 21 '07 #27
Bart wrote:
On Nov 21, 1:37 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>What is your implementation's value of UINT_MAX? And what result are you
getting? For instance, if UINT_MAX is 4294967295 on your implementation,
you should expect the result of the addition to be 705032704 (which is
5000000000 modulo 4294967296, which - as someone has already explained to
you in this thread - is how unsigned integer arithmetic is done in C). If
your program displays some other result (for that value of UINT_MAX), then
you do indeed have a problem.

UINT_MAX is as expected. And the result 705032704 is exactly what I
would have expected last week. And what I would expect to happen
anywhere else I was using 32-bit unsigned arithmetic.

I just have a problem with this slightly chaotic result (705,032,704
is somewhat different from 5,000,000,000) not being due to 'Overflow'.
5 billion needs 33 bits, it overflows 32 bits.

Truncating such results to 32 bits and ignoring CPU flags seems
perfectly reasonable for a compiler to do with integer arithmetic. But
it is clearly an overflow.

For C to state that unsigned values can't overflow (because the
Standard defines unsigned arithmetic in a certain way) seems
misleading.

And it is clearly an issue in the original problem, (a+b)>(c+d). C has
just redefined the problem to be modulo arithmetic rather than
overflow.
You've hit the nail on the head here. It is (arguably) misleading to
state that it is not overflow, but this is what the Standard says. It is
even more misleading to deviate from the Standard's usage of language
when talking about C.
Nov 21 '07 #28
Bart said:

<snip>
I just have a problem with this slightly chaotic result
Understandable.
(705,032,704 is somewhat different from 5,000,000,000)
Not mod 4294967296, it isn't.
not being due to 'Overflow'.
Nevertheless, it is not due to overflow.
5 billion needs 33 bits, it overflows 32 bits.
But you weren't calculating 5 billion. You were calculating 705032704. You
just didn't realise it.
Truncating such results to 32 bits and ignoring CPU flags seems
perfectly reasonable for a compiler to do with integer arithmetic. But
it is clearly an overflow.
Not according to the C Standard, which states in 6.2.5(9):

"A computation involving unsigned operands can never overflow, because a
result that cannot be represented by the resulting unsigned integer type
is reduced modulo the number that is one greater than the largest value
that can be represented by the resulting type."
For C to state that unsigned values can't overflow (because the
Standard defines unsigned arithmetic in a certain way) seems
misleading.
I can see why you might think so. Nevertheless, that is how C defines
unsigned integer arithmetic, whether we like it or not.
And it is clearly an issue in the original problem, (a+b)>(c+d). C has
just redefined the problem to be modulo arithmetic rather than
overflow.
If you like, yes. But you can think of modulo arithmetic as being not so
much a problem as an opportunity.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Nov 21 '07 #29
santosh wrote:
In article <Ea******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrote on Wednesday 21 Nov 2007 7:21 pm:
>santosh said:
>>...
Oops. I stand corrected. For a moment I forgot that C's conception
of "byte" is not the same as the widely held one.
Which widely held one?

Specifically, the one that believes that a byte is eight bits.
...
The fact that TCP/IP defines bytes as eight bits wide
also contributes to this view.
But TCP/IP definitely doesn't define bytes as eight bits wide; it avoids
using 'byte' when the number of bits matter. In common with most things
which talk about things which are explicitly 8 bits wide, it uses
'octet'. It defines 'octet' as 'an eight bit byte'.
Nov 21 '07 #30
santosh <santosh....@gmail.comwrote:
Bart <b...@freeuk.comwrote on Wednesday 21 Nov 2007 6:52 pm:
After trying a few arbitrary combinations I find that
int main(void) gives no compiler warnings (even though
I don't explicitly return an int).

You should return an int value from main() for your program
to be conforming.
Even a FORTRAN program is conforming.
To be strictly conforming the return value has to be one
among the set: 0, EXIT_SUCCESS, EXIT_FAILURE.
That's if you bother returning a value.

Unless the program uses the return value from a recursive call
to main, you won't break strict conformance by not returning
a value.

Unlike C++, C does not require a non void function to return
a value, unless that value is used in the expression that
invoked the function.

In the case of the original call to main(), the worst that
happens is that (in C90) an undefined status will be returned
to the host.

You can argue that such a status might format your harddisk,
but there's nothing in the C standards that precludes a host
from doing that on receipt of a successful termination.

--
Peter
Nov 22 '07 #31

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

17
by: John Bentley | last post by:
John Bentley: INTRO The phrase "decimal number" within a programming context is ambiguous. It could refer to the decimal datatype or the related but separate concept of a generic decimal number....
18
by: Christopher W. Douglas | last post by:
I am writing a VB.NET application in Visual Studio 2003. I have written a method that handles several events, such as closing a form and changing the visible status of a form. I have some code...
5
by: David C. Barber | last post by:
I'm trying to determine which user has locked a given record from VB6. I know I can use sp_lock and sp_who, and match up the data to determine which users have locked records in my database,...
3
by: David | last post by:
I want to develop a single web app that will be run in three environments: development, test, and production. The test and prodc. will be on the same machine under different directories. I wish...
3
by: Jules Winfield | last post by:
I've developed a WinForms application that allows users to create a number of child forms within a larger parent form. The child forms can be dragged around within the bounds of the parent. They...
7
by: Doru Roman | last post by:
Hi, What is the fastest way to evaluate manually the result in this case: int a, b, c; a = 255; b = 122; c = a & b; The only way I know is transforming each number into the binary value...
8
by: Joe | last post by:
Hi trying to write some code to determine if user has large/small fonts set on PC thought this would work but it didn't Any suggestions??? Thanks Graphics g = Graphics.FromHwnd(this.Handle);
6
by: Mike | last post by:
I have a textbox were users can enter data, then they can delete it all and enter in new data again and click submit. Is there a way to determine if the user deleted the text they entered in? I'm...
36
by: James Harris | last post by:
Initial issue: read in an arbitrary-length piece of text. Perceived issue: handle variable-length data The code below is a suggestion for implementing a variable length buffer that could be used...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.