Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15914 > unrolled thread

C arithmetic question.

Back to article view | Back to comp.lang.c

Contents

  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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#16053

On 01/23/2012 06:06 AM, Ben Bacarisse wrote:
...
> On a related note.  What's the point of requiring a common type for the
> operands of %?  It makes sense for * and / (and for + and - when the
> operands are arithmetic) but % is not symmetric and I can't see any
> cases where saying

The key reason is that the definitions of *, / and % are all tied
together. If they didn't all handle their operands the same way, the
requirement that (a/b)*b + (a%b) == a wouldn't work.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#16065

James Kuyper <jameskuyper@verizon.net> writes:

> On 01/23/2012 06:06 AM, Ben Bacarisse wrote:
> ...
>> On a related note.  What's the point of requiring a common type for the
>> operands of %?  It makes sense for * and / (and for + and - when the
>> operands are arithmetic) but % is not symmetric and I can't see any
>> cases where saying
>
> The key reason is that the definitions of *, / and % are all tied
> together. If they didn't all handle their operands the same way, the
> requirement that (a/b)*b + (a%b) == a wouldn't work.

Right.

There's no practical reason to continue this (that equality has been
fixed since ANSI C so it won't change) but if % behaved as I suggested,
I think that expression would be mathematically true, rather than 'C'
true (if you see what I mean).  It's not clear to me that that
expression needs to be a true C expression rather than a true
mathematical expression.

There may be C programs that rely on (a/b)*b + (a%b) == a remaining true
when a and b are of mixed signed/unsigned types, but I'd bet that there
are more programs that have had to be fixed because it's not
mathematically true.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#15945

Michael Press <rubrum@pacbell.net> writes:
[...]
> There is nothing to gain by learning C's idiosyncratic
> rules on integer types for the purpose of doing arithmetic.

You could gain the ability to write C code that does arithmetic.  The
vast majority of people have chosen not to learn it, but your presence
in this newsgroup suggests that you might find it useful.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15972

Keith Thompson <kst-u@mib.org> writes:

> Michael Press <rubrum@pacbell.net> writes:
> [...]
>> There is nothing to gain by learning C's idiosyncratic
>> rules on integer types for the purpose of doing arithmetic.
>
> You could gain the ability to write C code that does arithmetic.  The
> vast majority of people have chosen not to learn it, but your presence
> in this newsgroup suggests that you might find it useful.

The main thing is that there aren't that many occasions when you need to
mix signed and unsigned numbers, and that's when unexpected -  to the
naive programmer - things can happen.

The rest of the time there's nothing special going on.

I tend to use the odd (probably) superfluous cast in those
circumstances: it makes it clear to me what I wanted to happen and to
anyone else reading the code.  I'd need to double check what I wanted,
and document it with a comment anyway.

But even in programs using both signed and unsigned numbers the two mix
only infrequently.  GCC is pretty good at warning when you've written
something that doesn't do what you might have thought it would.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#15948

Michael Press <rubrum@pacbell.net> wrote:

> > Of course, there are several lessons possible from any example.  But I
> > think "understand how unsigneds work" might be a better one in this
> > case.
> 
> I prefer mine. C does not have a consistent approach to arithmetic.
> The soi disant mod operator violates the fundamental law:
> 
> x = y (mod m) if and only if x - y  is divisible by m.

I don't think it violates any law. You need to understand your tools and how
computers work, or you should probably quit programming.

> There is nothing to gain by learning C's idiosyncratic
> rules on integer types for the purpose of doing arithmetic.

It has nothing to do with C, it has to do with your lack of understanding of
signed and unsigned values and how hardware and software work with them.

[toc] | [prev] | [next] | [standalone]

#15988

In article <87ed03f5182b3b9ccbd92531e5da3bd3@dizum.com>,
 Nomen Nescio <nobody@dizum.com> wrote:

> Michael Press <rubrum@pacbell.net> wrote:
> 
> > > Of course, there are several lessons possible from any example.  But I
> > > think "understand how unsigneds work" might be a better one in this
> > > case.
> > 
> > I prefer mine. C does not have a consistent approach to arithmetic.
> > The soi disant mod operator violates the fundamental law:
> > 
> > x = y (mod m) if and only if x - y  is divisible by m.
> 
> I don't think it violates any law. 

It does.

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#15989

Why do we have to condemn some novice kid writing c codes less than 10 times  and can't understand even two positive integers "added" in c can become a negative integer for signed 
integer representations in c programming?

Of course if that is from a c programmer in some company for a joke. 
Just take it easy.  

[toc] | [prev] | [next] | [standalone]

#15952

On 01/19/2012 02:14 AM, Michael Press wrote:
> In article <1bhazss041.fsf@pfeifferfamily.net>,
>  Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> 
>> Michael Press <rubrum@pacbell.net> writes:
...
>>> The lesson is to use a library designed to
>>> do arithmetic rather than expecting it from C.
>>
>> Of course, there are several lessons possible from any example.  But I
>> think "understand how unsigneds work" might be a better one in this
>> case.
> 
> I prefer mine. C does not have a consistent approach to arithmetic.
> The soi disant mod operator violates the fundamental law:
> 
> x = y (mod m) if and only if x - y  is divisible by m.

No, it does not. The C standard mandates that if a/b is representable in
the appropriate type, then (a/b)*b + (a%b) = a, from which it can easily
be shown that a-(a%b) == (a/b)*b, a number divisible by b.

Insert the following line in your program:
	printf("%lu\n", a - (a%b));
You should find that it prints out a number exactly divisible by 37.

Your problem has nothing to do with the modulus operator, but only with
your failure to realize that your code involved an implicit conversion
to unsigned long before the modulus operator was even applied.

> There is nothing to gain by learning C's idiosyncratic
> rules on integer types for the purpose of doing arithmetic.

Other than the ability to write C code making use of those rules. That
might not be of any interest to you.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#16098

On Jan 18, 11:14 pm, Michael Press <rub...@pacbell.net> wrote:
> In article <1bhazss041....@pfeifferfamily.net>,
>  Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
>
>
>
>
>
> > Michael Press <rub...@pacbell.net> writes:
>
> > > In article
> > > <0eb6c644-ac1e-4de6-8d8a-c1978a8ce...@b10g2000pbd.googlegroups.com>,
> > >  Peter Nilsson <ai...@acay.com.au> 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!
>
> > > I am not embarrassed; the pain is slight.
> > > The lesson is to use a library designed to
> > > do arithmetic rather than expecting it from C.
>
> > Of course, there are several lessons possible from any example.  But I
> > think "understand how unsigneds work" might be a better one in this
> > case.
>
> I prefer mine. C does not have a consistent approach to arithmetic.
> The soi disant mod operator violates the fundamental law:
>
> x = y (mod m) if and only if x - y  is divisible by m.
>
> There is nothing to gain by learning C's idiosyncratic
> rules on integer types for the purpose of doing arithmetic.
>

I've seen some Math definitions that place the additional restriction
that the remainder r and divisor d is such that

0 <=r < d

It looks like the mod operator in this case accounting for such a
restriction.

[toc] | [prev] | [next] | [standalone]

#16100

On 01/24/2012 11:14 AM, Chad wrote:
> On Jan 18, 11:14 pm, Michael Press <rub...@pacbell.net> wrote:
...
>> I prefer mine. C does not have a consistent approach to arithmetic.
>> The soi disant mod operator violates the fundamental law:
>>
>> x = y (mod m) if and only if x - y  is divisible by m.
>>
>> There is nothing to gain by learning C's idiosyncratic
>> rules on integer types for the purpose of doing arithmetic.
>>
> 
> I've seen some Math definitions that place the additional restriction
> that the remainder r and divisor d is such that
> 
> 0 <=r < d
> 
> It looks like the mod operator in this case accounting for such a
> restriction.

No, that's not what's going on. C's definition for the modulus operator
contains no such restriction. In fact, it requires that a%b be negative
if a and b are both signed, and a is negative, unless 'a' is a multiple
of b.

What's causing this C code to correctly produce a value other than the
one Michael was expecting is the fact that 'a' has the type 'long',
while 'b' has the type 'unsigned long', with the result that 'a' is
converted to the 'unsigned long' before evaluating the modulus. The
conversion produces the value ULONG_MAX-57, which is positive, so that
a%b produces a value of 21.  Michael's assertion to the contrary
notwithstanding, a - a%b is in fact divisible by b (because the same
conversion occurs to both occurrences of 'a'). If Michael had written

	a %= (long)b;

b would have been converted to long, without change of value, and he
would have gotten a result of -21, which violates the requirement you
mention, but satisfies the one he mentions. Whether that's the value he
was expecting is unclear; he might have been expecting 16.cd

[toc] | [prev] | [next] | [standalone]

#16101

On Jan 24, 9:15 am, James Kuyper <jameskuy...@verizon.net> wrote:
> On 01/24/2012 11:14 AM, Chad wrote:
>
>
>
>
>
> > On Jan 18, 11:14 pm, Michael Press <rub...@pacbell.net> wrote:
> ...
> >> I prefer mine. C does not have a consistent approach to arithmetic.
> >> The soi disant mod operator violates the fundamental law:
>
> >> x = y (mod m) if and only if x - y  is divisible by m.
>
> >> There is nothing to gain by learning C's idiosyncratic
> >> rules on integer types for the purpose of doing arithmetic.
>
> > I've seen some Math definitions that place the additional restriction
> > that the remainder r and divisor d is such that
>
> > 0 <=r < d
>
> > It looks like the mod operator in this case accounting for such a
> > restriction.
>
> No, that's not what's going on. C's definition for the modulus operator
> contains no such restriction. In fact, it requires that a%b be negative
> if a and b are both signed, and a is negative, unless 'a' is a multiple
> of b.
>
> What's causing this C code to correctly produce a value other than the
> one Michael was expecting is the fact that 'a' has the type 'long',
> while 'b' has the type 'unsigned long', with the result that 'a' is
> converted to the 'unsigned long' before evaluating the modulus. The
> conversion produces the value ULONG_MAX-57, which is positive, so that
> a%b produces a value of 21.  Michael's assertion to the contrary
> notwithstanding, a - a%b is in fact divisible by b (because the same
> conversion occurs to both occurrences of 'a'). If Michael had written
>
>         a %= (long)b;
>
> b would have been converted to long, without change of value, and he
> would have gotten a result of -21, which violates the requirement you
> mention, but satisfies the one he mentions. Whether that's the value he
> was expecting is unclear; he might have been expecting 16.cd- Hide quoted text -
>

Maybe I'm being a bit daft, but your explanation sort of mirrors how
you would go about dividing something like -11 by 3 when the remainder
can't be negative.

[toc] | [prev] | [next] | [standalone]

#16103

On 01/24/2012 12:26 PM, Chad wrote:
> On Jan 24, 9:15 am, James Kuyper <jameskuy...@verizon.net> wrote:
...
>> What's causing this C code to correctly produce a value other than the
>> one Michael was expecting is the fact that 'a' has the type 'long',
>> while 'b' has the type 'unsigned long', with the result that 'a' is
>> converted to the 'unsigned long' before evaluating the modulus. The
>> conversion produces the value ULONG_MAX-57, which is positive, so that
>> a%b produces a value of 21.  Michael's assertion to the contrary
>> notwithstanding, a - a%b is in fact divisible by b (because the same
>> conversion occurs to both occurrences of 'a'). If Michael had written
>>
>>         a %= (long)b;
>>
>> b would have been converted to long, without change of value, and he
>> would have gotten a result of -21, which violates the requirement you
>> mention, but satisfies the one he mentions. Whether that's the value he
>> was expecting is unclear; he might have been expecting 16.cd- Hide quoted text -
>>
> 
> Maybe I'm being a bit daft, but your explanation sort of mirrors how
> you would go about dividing something like -11 by 3 when the remainder
> can't be negative.

I'm not sure exactly what you're saying. The C standard requires
a) (-11)/3 == -3
b) ((-11)/3)*3 + (-11)%3 == -11

which means that (-11)%3 == -2.

It also requires that, on a system where ULONG_MAX == 4294967295, that
a) (-11UL)/3 == 1431655761
b) ((-11UL)/3)*3 + (-11UL)%3 == -11UL
which means that (-11UL)%3 == 2.

That's because the expression -11UL has a value of 4294967285. Michael
didn't realize that he was writing the equivalent of such an expression,
because he wasn't paying attention to the usual arithmetic conversions.

[toc] | [prev] | [next] | [standalone]

#16104

On Jan 24, 9:39 am, James Kuyper <jameskuy...@verizon.net> wrote:
> On 01/24/2012 12:26 PM, Chad wrote:
>
>
>
>
>
> > On Jan 24, 9:15 am, James Kuyper <jameskuy...@verizon.net> wrote:
> ...
> >> What's causing this C code to correctly produce a value other than the
> >> one Michael was expecting is the fact that 'a' has the type 'long',
> >> while 'b' has the type 'unsigned long', with the result that 'a' is
> >> converted to the 'unsigned long' before evaluating the modulus. The
> >> conversion produces the value ULONG_MAX-57, which is positive, so that
> >> a%b produces a value of 21.  Michael's assertion to the contrary
> >> notwithstanding, a - a%b is in fact divisible by b (because the same
> >> conversion occurs to both occurrences of 'a'). If Michael had written
>
> >>         a %= (long)b;
>
> >> b would have been converted to long, without change of value, and he
> >> would have gotten a result of -21, which violates the requirement you
> >> mention, but satisfies the one he mentions. Whether that's the value he
> >> was expecting is unclear; he might have been expecting 16.cd- Hide quoted text -
>
> > Maybe I'm being a bit daft, but your explanation sort of mirrors how
> > you would go about dividing something like -11 by 3 when the remainder
> > can't be negative.
>
> I'm not sure exactly what you're saying. The C standard requires
> a) (-11)/3 == -3
> b) ((-11)/3)*3 + (-11)%3 == -11
>
> which means that (-11)%3 == -2.
>
> It also requires that, on a system where ULONG_MAX == 4294967295, that
> a) (-11UL)/3 == 1431655761
> b) ((-11UL)/3)*3 + (-11UL)%3 == -11UL
> which means that (-11UL)%3 == 2.
>
> That's because the expression -11UL has a value of 4294967285. Michael
> didn't realize that he was writing the equivalent of such an expression,
> because he wasn't paying attention to the usual arithmetic conversions.- Hide quoted text -
>

In Michael's example, the conversion of unsigned long before
evaluating the modulus operator is ULONG_MAX-57. What I noticed was
that -57 was converted to a positive number. This in turn reminded me
of a definition of division that I saw a long time agon. This
definition was

Let a be an integer and d be a positive integer. Then there are unique
integers q and r, with 0 <= r < d such that a = dq + r.

Using the above definition, one can't divide something like -11 by 3
because it would produce a negative remainder. So what happens is the
remainder would get converted to a positive number. In other words,
something like

-11 = 3 * (-3) - 2

would become

-11 = 3 * (-4) + 1

And for whatever reasons, it just appeared to me that this math
definition applied to this particular situation.

[toc] | [prev] | [next] | [standalone]

#16105

On 01/24/2012 01:03 PM, Chad wrote:
...
> In Michael's example, the conversion of unsigned long before
> evaluating the modulus operator is ULONG_MAX-57. What I noticed was
> that -57 was converted to a positive number. This in turn reminded me

Actually, it's a value of -58L that gets converted to ULONG_MAX - 57.
The number that gets added to negative values, as many times as needed
to produce a value in range for the new type, is "one more than the
maximum value that can be represented in the new type" (6.3.1.3p2).

> of a definition of division that I saw a long time agon. This
> definition was
> 
> Let a be an integer and d be a positive integer. Then there are unique
> integers q and r, with 0 <= r < d such that a = dq + r.
> 
> Using the above definition, one can't divide something like -11 by 3
> because it would produce a negative remainder. So what happens is the
> remainder would get converted to a positive number. In other words,
> something like
> 
> -11 = 3 * (-3) - 2
> 
> would become
> 
> -11 = 3 * (-4) + 1
> 
> 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.

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.

[toc] | [prev] | [next] | [standalone]

#16106

On Jan 24, 10:23 am, James Kuyper <jameskuy...@verizon.net> wrote:
> On 01/24/2012 01:03 PM, Chad wrote:
> ...
>
> > In Michael's example, the conversion of unsigned long before
> > evaluating the modulus operator is ULONG_MAX-57. What I noticed was
> > that -57 was converted to a positive number. This in turn reminded me
>
> Actually, it's a value of -58L that gets converted to ULONG_MAX - 57.
> The number that gets added to negative values, as many times as needed
> to produce a value in range for the new type, is "one more than the
> maximum value that can be represented in the new type" (6.3.1.3p2).
>
>
>
>
>
> > of a definition of division that I saw a long time agon. This
> > definition was
>
> > Let a be an integer and d be a positive integer. Then there are unique
> > integers q and r, with 0 <= r < d such that a = dq + r.
>
> > Using the above definition, one can't divide something like -11 by 3
> > because it would produce a negative remainder. So what happens is the
> > remainder would get converted to a positive number. In other words,
> > something like
>
> > -11 = 3 * (-3) - 2
>
> > would become
>
> > -11 = 3 * (-4) + 1
>
> > 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.

> 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.

[toc] | [prev] | [next] | [standalone]

#16109

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.

[toc] | [prev] | [next] | [standalone]

#16110

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 think I just hit the wrong reply button.

[toc] | [prev] | [next] | [standalone]

#16112

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

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.

[toc] | [prev] | [next] | [standalone]

#16116

On Tue, 24 Jan 2012 12:02:29 -0800, Chad saw fit to publish the following:

> 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
> 
> 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.

Problem is here are several definitions of the modulo operation. They all
agree on what happens when operands are positive, but disagree what
happens when one of the operands is negative.

I'm not a standards-jockey, but i'd be interested what the experts have
to say.

See also http://en.wikipedia.org/wiki/Modulo_operator



-- 
No problem is insoluble.
		-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4

[toc] | [prev] | [next] | [standalone]

#16129

On Jan 24, 12:26 pm, Kleuske <kleu...@nowhere.net> wrote:
> On Tue, 24 Jan 2012 12:02:29 -0800, Chad saw fit to publish the following:
>
>
>
>
>
> > 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
>
> > 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.
>
> Problem is here are several definitions of the modulo operation. They all
> agree on what happens when operands are positive, but disagree what
> happens when one of the operands is negative.
>
> I'm not a standards-jockey, but i'd be interested what the experts have
> to say.
>

Despite what some might claim on here, it just appears to me that the
C Standard isn't really (that far) out of sync with the "regular math".

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web