Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #15914 > unrolled thread
| Started by | Michael Press <rubrum@pacbell.net> |
|---|---|
| First post | 2012-01-18 10:32 -0800 |
| Last post | 2012-01-27 13:37 -0800 |
| Articles | 7 on this page of 67 — 25 participants |
Back to article view | Back to comp.lang.c
C arithmetic question. Michael Press <rubrum@pacbell.net> - 2012-01-18 10:32 -0800
Re: C arithmetic question. James Kuyper <jameskuyper@verizon.net> - 2012-01-18 14:03 -0500
Re: C arithmetic question. TheGunslinger <mikiesrunsbaal.sec@sbcglobal.net> - 2012-01-18 19:30 -0800
Re: C arithmetic question. James Kuyper <jameskuyper@verizon.net> - 2012-01-19 08:10 -0500
Re: C arithmetic question. Markus Wichmann <nullplan@gmx.net> - 2012-01-18 21:14 +0100
Re: C arithmetic question. "BartC" <bc@freeuk.com> - 2012-01-19 10:44 +0000
Re: C arithmetic question. Seebs <usenet-nospam@seebs.net> - 2012-01-21 21:32 +0000
Re: C arithmetic question. Peter Nilsson <airia@acay.com.au> - 2012-01-18 13:51 -0800
Re: C arithmetic question. Michael Press <rubrum@pacbell.net> - 2012-01-18 15:51 -0800
Re: C arithmetic question. James Kuyper <jameskuyper@verizon.net> - 2012-01-18 20:50 -0500
Re: C arithmetic question. Michael Press <rubrum@pacbell.net> - 2012-01-20 12:41 -0800
Re: C arithmetic question. Keith Thompson <kst-u@mib.org> - 2012-01-20 14:11 -0800
Re: C arithmetic question. gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-20 22:43 +0000
Re: C arithmetic question. James Kuyper <jameskuyper@verizon.net> - 2012-01-20 17:19 -0500
Re: C arithmetic question. James Kuyper <jameskuyper@verizon.net> - 2012-01-20 17:32 -0500
And jacob navia <jacob@spamsink.net> - 2012-01-20 23:52 +0100
Re: And Markus Wichmann <nullplan@gmx.net> - 2012-01-21 19:23 +0100
Re: And Keith Thompson <kst-u@mib.org> - 2012-01-21 13:20 -0800
Re: And jacob navia <jacob@spamsink.net> - 2012-01-21 23:02 +0100
Re: And Markus Wichmann <nullplan@gmx.net> - 2012-01-22 15:24 +0100
Re: And Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-22 15:40 +0000
Re: And blp@cs.stanford.edu (Ben Pfaff) - 2012-01-21 11:02 -0800
Re: C arithmetic question. Rui Maciel <rui.maciel@gmail.com> - 2012-01-24 18:53 +0000
Re: C arithmetic question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-19 02:09 +0000
Re: C arithmetic question. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-18 23:00 -0700
Re: C arithmetic question. Michael Press <rubrum@pacbell.net> - 2012-01-18 23:14 -0800
Re: C arithmetic question. Ike Naar <ike@sverige.freeshell.org> - 2012-01-19 08:41 +0000
Re: C arithmetic question. Michael Press <rubrum@pacbell.net> - 2012-01-20 12:43 -0800
Re: C arithmetic question. Kaz Kylheku <kaz@kylheku.com> - 2012-01-20 22:17 +0000
Re: C arithmetic question. Michael Press <rubrum@pacbell.net> - 2012-01-21 00:12 -0800
Re: C arithmetic question. Seebs <usenet-nospam@seebs.net> - 2012-01-21 21:32 +0000
Re: C arithmetic question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-21 23:21 +0000
Re: C arithmetic question. Robert Wessel <robertwessel2@yahoo.com> - 2012-01-22 00:48 -0600
Re: C arithmetic question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-22 11:45 +0000
Re: C arithmetic question. Robert Wessel <robertwessel2@yahoo.com> - 2012-01-22 21:46 -0600
Re: C arithmetic question. Kaz Kylheku <kaz@kylheku.com> - 2012-01-23 04:17 +0000
Re: C arithmetic question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-23 11:19 +0000
Re: C arithmetic question. Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-26 10:41 -0800
Re: C arithmetic question. Seebs <usenet-nospam@seebs.net> - 2012-01-23 07:58 +0000
Re: C arithmetic question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-23 11:06 +0000
Re: C arithmetic question. James Kuyper <jameskuyper@verizon.net> - 2012-01-23 07:03 -0500
Re: C arithmetic question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-23 17:27 +0000
Re: C arithmetic question. Keith Thompson <kst-u@mib.org> - 2012-01-19 02:38 -0800
Re: C arithmetic question. Dr Nick <3-nospam@temporary-address.org.uk> - 2012-01-20 07:30 +0000
Re: C arithmetic question. Nomen Nescio <nobody@dizum.com> - 2012-01-19 12:28 +0100
Re: C arithmetic question. Michael Press <rubrum@pacbell.net> - 2012-01-20 12:44 -0800
Re: C arithmetic question. 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-20 13:14 -0800
Re: C arithmetic question. James Kuyper <jameskuyper@verizon.net> - 2012-01-19 08:45 -0500
Re: C arithmetic question. Chad <cdalten@gmail.com> - 2012-01-24 08:14 -0800
Re: C arithmetic question. James Kuyper <jameskuyper@verizon.net> - 2012-01-24 12:15 -0500
Re: C arithmetic question. Chad <cdalten@gmail.com> - 2012-01-24 09:26 -0800
Re: C arithmetic question. James Kuyper <jameskuyper@verizon.net> - 2012-01-24 12:39 -0500
Re: C arithmetic question. Chad <cdalten@gmail.com> - 2012-01-24 10:03 -0800
Re: C arithmetic question. James Kuyper <jameskuyper@verizon.net> - 2012-01-24 13:23 -0500
Re: C arithmetic question. Chad <cdalten@gmail.com> - 2012-01-24 10:40 -0800
Re: C arithmetic question. James Kuyper <jameskuyper@verizon.net> - 2012-01-24 14:35 -0500
Re: C arithmetic question. Chad <cdalten@gmail.com> - 2012-01-24 12:04 -0800
Re: C arithmetic question. Chad <cdalten@gmail.com> - 2012-01-24 12:02 -0800
Re: C arithmetic question. Kleuske <kleuske@nowhere.net> - 2012-01-24 20:26 +0000
Re: C arithmetic question. Chad <cdalten@gmail.com> - 2012-01-24 13:45 -0800
Re: C arithmetic question. James Kuyper <jameskuyper@verizon.net> - 2012-01-24 15:40 -0500
Re: C arithmetic question. Chad <cdalten@gmail.com> - 2012-01-24 12:09 -0800
Re: C arithmetic question. Rui Maciel <rui.maciel@gmail.com> - 2012-01-24 18:48 +0000
Re: C arithmetic question. "osmium" <r124c4u102@comcast.net> - 2012-01-19 08:12 -0600
Re: C arithmetic question. Geoff <geoff@invalid.invalid> - 2012-01-20 15:33 -0800
Re: C arithmetic question. Kleuske <kleuske@nowhere.net> - 2012-01-27 08:17 +0000
Re: C arithmetic question. Geoff <geoff@invalid.invalid> - 2012-01-27 13:37 -0800
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-01-24 15:40 -0500 |
| Message-ID | <4F1F1734.2020509@verizon.net> |
| In reply to | #16112 |
On 01/24/2012 03:02 PM, Chad wrote: > On Jan 24, 11:35 am, James Kuyper <jameskuy...@verizon.net> wrote: ... >> OK - I'm confused. What do you think Michael's case is? I thought it was >> (ULONG_MAX-57)%37. >> >> Alternatively, you could be referring to the case he mistakenly thought >> was relevant, (-58)%37? C requires a value of -21 for that case, while >> the rule you describe requires 16. However, both of those values satisfy >> the criterion he complained about being violated: >> >>> x = y (mod m) if and only if x - y is divisible by m. >> >> -58 - (-21) = -37 == -1*37 >> -58 - (16) = -74 == -2*37 >> >> So the issue you raise is irrelevant to his complaint. > > I'm going to sidestep your question for a minute... > > I interpret something like a = mq + r as being equivalent to > > a mod m = r > > This means that Michael's example becomes > > -58 % 37 = r > > -58 = 37q + r > > if the remainder is allowed to be negative, this expression could > become something like > > -58 = 37 * (-1) + (-21) > > > However, you clearly showed that the correct answer is.. > > 4294967238 = 116081095*37 + 23. > > This in turn would lead me to believe there is the additional > restriction to the math forumla (definition) that the remainder has to > be positive. In so far as there's an official "math definition" of the modulus operator, what I "clearly showed" doesn't tell you anything about that definition. I was using C rules for the % operator, not "math" rules for the modulus operator. Those C rules specified that, in this context, -58 gets converted to ULONG_MAX-57. The C result is non-negative only because ULONG_MAX-57 is positive, it has nothing to do with any general requirement that a%b be non-negative. a%b is not merely allowed to be negative; If a is negative, larger than b and not a multiple of b, a%b is required to be negative. However, because 'a' was ULONG_MAX-57, that doesn't apply
[toc] | [prev] | [next] | [standalone]
| From | Chad <cdalten@gmail.com> |
|---|---|
| Date | 2012-01-24 12:09 -0800 |
| Message-ID | <473626c0-93d0-4802-bf35-cf7410eaf05f@o4g2000pbc.googlegroups.com> |
| In reply to | #16109 |
On Jan 24, 11:35 am, James Kuyper <jameskuy...@verizon.net> wrote: > On 01/24/2012 01:40 PM, Chad wrote: > > > On Jan 24, 10:23 am, James Kuyper <jameskuy...@verizon.net> wrote: > >> On 01/24/2012 01:03 PM, Chad wrote: > ... > >>> And for whatever reasons, it just appeared to me that this math > >>> definition applied to this particular situation. > > >> Well, it doesn't. ULONG_MAX-57 is positive, so rules covering negative > >> numbers aren't relevant. > > > Yes. This is why I said for this particular case. > > Which is "this particular case" if it doesn't involve ULONG_MAX-57? > > >> More importantly, the C standard mandates that integer division must > >> truncate the value, removing the fractional part, so (-11)/3 must be > >> truncated to -3, not rounded downward to -4. In combination with the > >> requirement that (a/b)*b+a%b == a, that means that (-11)%3 must give a > >> value of -2, not 1.- Hide quoted text - > > > What I'm trying to get at is that this math defintion seems to apply > > to Michael's case and not the case in general. > > OK - I'm confused. What do you think Michael's case is? I thought it was > (ULONG_MAX-57)%37. > > Alternatively, you could be referring to the case he mistakenly thought > was relevant, (-58)%37? C requires a value of -21 for that case, while > the rule you describe requires 16. However, both of those values satisfy > the criterion he complained about being violated: > > > x = y (mod m) if and only if x - y is divisible by m. > > -58 - (-21) = -37 == -1*37 > -58 - (16) = -74 == -2*37 > > So the issue you raise is irrelevant to his complaint. I'm going to sidestep your question for a minute..... I interpret something like a = mq +r as being equivalent to a mod m = r Going on this definition, something like -58 % 37 becomes -58 mod 37 = r -58 = 37 *q + r Now if I allow for the possiblity of a negative remainder, the above expression could possibly reduce to something like -58 = 37 * (-1) + (-21) However, you showed that in fact the result was 4294967238 = 116081095*37 + 23. This would lead to me to believe that there is the additional restriction to the math definition that the remainder has to be positive.
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-01-24 18:48 +0000 |
| Message-ID | <jfmue6$v9l$1@speranza.aioe.org> |
| In reply to | #15929 |
Michael Press wrote: > The lesson is to use a library designed to > do arithmetic rather than expecting it from C. What leads you to believe that using such a library would eliminate any problem which the user might have regarding his understanding of how a computer program (or even a computer) operates? Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | "osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2012-01-19 08:12 -0600 |
| Message-ID | <9nqmmsFlb4U1@mid.individual.net> |
| In reply to | #15923 |
"Peter Nilsson" wrote: > Michael Press <rub...@pacbell.net> wrote: >> [-58ul % 37 == 23] >> ... >> 23 cannot be the right answer because >> 37 does not divide -58 - 23 = -81. > > You have the explanation in the other posts. I just wanted to say... > >> Is this a bug in the compiler or a problem with the C standard? > > From experience, I can tell you that you're in for a lifetime of pain > and embarrassment if these continue to be your first thoughts every > time you encounter unexplained output! This post seems to have triggered a hornet's nest of issues. How to design a computer language, when the use of a "raw" computer language is advisable, some fundamentals of number theory, and on and on and on. The message I got was "If you think there is a compiler bug, you are probably wrong". Some of the rules imposed by the standard are, IMO, esoteric and might violate your notion of what makes sense. The moral is most likely there is a bug in your program than the two options given by the OP; keep in mind that the compiler designers get to decide what a bug *is*.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2012-01-20 15:33 -0800 |
| Message-ID | <9qtjh7hv3j6d9ev0jov75dus2iq5grla46@4ax.com> |
| In reply to | #15914 |
On Wed, 18 Jan 2012 10:32:57 -0800, Michael Press <rubrum@pacbell.net>
wrote:
>$cat hunh.c
>#include <stdio.h>
>
>int
>main(void)
>{
> long int a = -58;
> unsigned long int b = 37;
>
> a %= b;
> printf("%ld\n", a);
> return 0;
>}
>$cc -std=c99 -Wall -pedantic -o hunh hunh.c
>$./hunh
>23
>$ cc -v
>Using built-in specs.
>Target: i686-apple-darwin9
>Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
>Thread model: posix
>gcc version 4.0.1 (Apple Inc. build 5465)
>
>---
>
>23 cannot be the right answer because
>37 does not divide -58 - 23 = -81.
>
>Is this a bug in the compiler or a problem with the C standard?
Neither. Your program has a bug. Your program output changes depending
on the implementation. In 32-bit mode where you are compiling on OS X
Tiger, the result is 23. In 64-bit mode on OS X Lion, the result is
28. Neither answer is correct for reasons that others have explained.
The obligation of the programmer is to understand and consider the
rules of the language and the implementation and to code accordingly.
This is the contract between the language and the programmer. The
programmer breaks the contract at his own peril.
[toc] | [prev] | [next] | [standalone]
| From | Kleuske <kleuske@nowhere.net> |
|---|---|
| Date | 2012-01-27 08:17 +0000 |
| Message-ID | <jftmio$peq$2@dont-email.me> |
| In reply to | #16000 |
On Fri, 20 Jan 2012 15:33:00 -0800, Geoff saw fit to publish the following: <snip> > The obligation of the programmer is to understand and consider the rules > of the language and the implementation and to code accordingly. This is > the contract between the language and the programmer. The programmer > breaks the contract at his own peril. Good advice. Usually the peril is for the end user, though. -- "Beauty is transitory." "Beauty survives." -- Spock and Kirk, "That Which Survives", stardate unknown
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2012-01-27 13:37 -0800 |
| Message-ID | <1866i79aoeoqv2j65esod7l8ljlejgjei0@4ax.com> |
| In reply to | #16282 |
On Fri, 27 Jan 2012 08:17:28 +0000 (UTC), Kleuske <kleuske@nowhere.net> wrote: >On Fri, 20 Jan 2012 15:33:00 -0800, Geoff saw fit to publish the >following: > ><snip> > >> The obligation of the programmer is to understand and consider the rules >> of the language and the implementation and to code accordingly. This is >> the contract between the language and the programmer. The programmer >> breaks the contract at his own peril. > >Good advice. Usually the peril is for the end user, though. True, but the user's suffering and curses will ultimately determine the programmer's karma.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web