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

#16041 — Re: And

Markus Wichmann <nullplan@gmx.net> writes:
<snip>
> No-one ever said that A + B - A == B at all times. However, it should
> yoield at all times when you restrict yourself to using integers. But,
> as well, signed to unsigned conversion may ruin your day here.

C does not guarantee that A + B - A == B even when restricted to integer
types.  It does apply when the arithmetic is unsigned, but for signed
integer types, A + B can overflow before A is subtracted, and the
overflow of signed integers is undefined.

<snip>
-- 
Ben.

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

#16013 — Re: And

jacob navia <jacob@spamsink.net> writes:

> Computer arithmetic has nothing to do with maths. For instance:
>
> A+B is different from A for all B different than zero.

This is also true in C arithmetic, if A and B both have the same
unsigned integer type.
-- 
Just another C hacker.

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

#16108

Michael Press wrote:

>> Do you really believe that a%(long)b is so much more complicated than
>> a%b that a special library is called for?
>>
>> I would guess that you are probably thinking of this as just one issue
>> among many, the totality of which justifies use of a special library -
>> so what are those other issues? How would the behavior of that library
>> differ from that of ordinary C arithmetic?
> 
> I already said what I expect from the % operation.

Do you believe that replacing a standard tool with some ad-hoc solution 
represents a better option than simply taking the time to learn how the 
standard tool actually works?

And what will you do when the ad-hoc solution exhibits some behavour which 
goes against what you expected from it?


Rui Maciel

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

#15932

Michael Press <rubrum@pacbell.net> writes:

> In article 
> <0eb6c644-ac1e-4de6-8d8a-c1978a8ce255@b10g2000pbd.googlegroups.com>,
>  Peter Nilsson <airia@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.

I don't think it's reasonable to expect C to do arithmetic in the usual
sense of the word.  Very few programing languages even try, and those
that do are not C-like at all (Haskell and Lisp come to mind as examples
of those that make the effort).

Like the vast majority of languages, C has rules about expressions that
mix types and that produce seemingly unrepresentable results.  Some of
these are a little surprising, but I'm not confident I could come up
with a set of more reasonable rules without losing the essence of the
language.

-- 
Ben.

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

#15936

Michael Press <rubrum@pacbell.net> writes:

> In article 
> <0eb6c644-ac1e-4de6-8d8a-c1978a8ce255@b10g2000pbd.googlegroups.com>,
>  Peter Nilsson <airia@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.

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

#15937

In article <1bhazss041.fsf@pfeifferfamily.net>,
 Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:

> Michael Press <rubrum@pacbell.net> writes:
> 
> > In article 
> > <0eb6c644-ac1e-4de6-8d8a-c1978a8ce255@b10g2000pbd.googlegroups.com>,
> >  Peter Nilsson <airia@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.

-- 
Michael Press

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

#15944

On 2012-01-19, Michael Press <rubrum@pacbell.net> wrote:
> In article <1bhazss041.fsf@pfeifferfamily.net>,
>  Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
>
>> Michael Press <rubrum@pacbell.net> writes:
>> 
>> > In article 
>> > <0eb6c644-ac1e-4de6-8d8a-c1978a8ce255@b10g2000pbd.googlegroups.com>,
>> >  Peter Nilsson <airia@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.

The mod operator does not violate that law.
Your problem is not with the mod operator, it's
that the numbers that are given to the mod operator
are not what you think they are.

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

#15987

In article <slrn3vfsjhflpb.8kc.ike@sverige.freeshell.org>,
 Ike Naar <ike@sverige.freeshell.org> wrote:

> On 2012-01-19, Michael Press <rubrum@pacbell.net> wrote:
> > In article <1bhazss041.fsf@pfeifferfamily.net>,
> >  Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> >
> >> Michael Press <rubrum@pacbell.net> writes:
> >> 
> >> > In article 
> >> > <0eb6c644-ac1e-4de6-8d8a-c1978a8ce255@b10g2000pbd.googlegroups.com>,
> >> >  Peter Nilsson <airia@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.
> 
> The mod operator does not violate that law.
> Your problem is not with the mod operator, it's
> that the numbers that are given to the mod operator
> are not what you think they are.

You consider that more important than
the mod operator being consistent. I do not.

-- 
Michael Press

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

#15992

On 2012-01-20, Michael Press <rubrum@pacbell.net> wrote:
> In article <slrn3vfsjhflpb.8kc.ike@sverige.freeshell.org>,
>  Ike Naar <ike@sverige.freeshell.org> wrote:
>
>> > x = y (mod m) if and only if x - y  is divisible by m.
>> 
>> The mod operator does not violate that law.
>> Your problem is not with the mod operator, it's
>> that the numbers that are given to the mod operator
>> are not what you think they are.
>
> You consider that more important than
> the mod operator being consistent. I do not.

what do you want % to do?

3 % 4 == 3      /* everyone agrees, hopefully */
3 % -4 == ?
-3 % 4 == ?
-3 % -4 == ?

Common Lisp has two functions: mod and rem. (mod 3 4) and (rem 3 4) is 3.
But:

[1]> (mod -3 -4)
-3
[2]> (mod -3 4)
1
[3]> (mod 3 -4)
-1
[4]> (rem -3 -4)
-3
[5]> (rem -3 4)
-3
[6]> (rem 3 -4)

In some languages, there is a mod which always returns the least positive
residue. (But does that even mean when the modulus is negative?)
Note that the Lisp mod does give you a positive least residue value if the
modulus is positive.

Would you want the C % operator to be like Lisp's mod?

But note that in Lisp, there are two divisions too: mod pairs with floor (which
truncates toward minus infinity), and rem pairs with truncate (which truncates
toward zero).

Just like in C we have "(a/b)*b + a%b shall equal a", in Lisp we have
a similar relationship between floor and mod, and truncate and rem:

  (defun mod-test (a b)
    (values (= a (+ (* b (floor a b)) (mod a b)))
            (= a (+ (* b (truncate a b)) (rem a b)))))

 (mod-test 3 -4) -> T ; T
 (mod-test 3 4) -> T ; T
 (mod-test -3 -4) -> T ; T
 (mod-test 3 4) -> T ; T

As of C99, it appears that C's operators are like truncate and rem.

I think, IMO, that if you're only going to have one kind of truncating division
and one kind of mod, it's best to have a division which truncates toward zero,
and a modulus which is like the Lisp mod: the sign is always positive if the
modulus is positive, giving you a least positive residue.

Does the equality  (a/b)*b + a%b  == a  have any practical value?

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

#16005

In article <20120120135417.595@kylheku.com>,
 Kaz Kylheku <kaz@kylheku.com> wrote:

> On 2012-01-20, Michael Press <rubrum@pacbell.net> wrote:
> > In article <slrn3vfsjhflpb.8kc.ike@sverige.freeshell.org>,
> >  Ike Naar <ike@sverige.freeshell.org> wrote:
> >
> >> > x = y (mod m) if and only if x - y  is divisible by m.
> >> 
> >> The mod operator does not violate that law.
> >> Your problem is not with the mod operator, it's
> >> that the numbers that are given to the mod operator
> >> are not what you think they are.
> >
> > You consider that more important than
> > the mod operator being consistent. I do not.
> 
> what do you want % to do?

x % y gives an element of x + yZ. 

> 
> 3 % 4 == 3      /* everyone agrees, hopefully */
> 3 % -4 == ?
> -3 % 4 == ?
> -3 % -4 == ?
> 
> Common Lisp has two functions: mod and rem. (mod 3 4) and (rem 3 4) is 3.
> But:
> 
> [1]> (mod -3 -4)
> -3

-4 | -3 - (-3)

> [2]> (mod -3 4)
> 1

4 | -3 - 1

> [3]> (mod 3 -4)
> -1

-4 | 3 - (-1)

> [4]> (rem -3 -4)
> -3

-4 | -3 - (-3)

> [5]> (rem -3 4)
> -3

4 | -3 - (3)

> [6]> (rem 3 -4)
> 
> In some languages, there is a mod which always returns the least positive
> residue. (But does that even mean when the modulus is negative?)
> Note that the Lisp mod does give you a positive least residue value if the
> modulus is positive.
> 
> Would you want the C % operator to be like Lisp's mod?

I do not know.

> But note that in Lisp, there are two divisions too: mod pairs with floor (which
> truncates toward minus infinity), and rem pairs with truncate (which truncates
> toward zero).

There could be a third truncating to +oo. 

> Just like in C we have "(a/b)*b + a%b shall equal a", in Lisp we have
> a similar relationship between floor and mod, and truncate and rem:
> 
>   (defun mod-test (a b)
>     (values (= a (+ (* b (floor a b)) (mod a b)))
>             (= a (+ (* b (truncate a b)) (rem a b)))))
> 
>  (mod-test 3 -4) -> T ; T
>  (mod-test 3 4) -> T ; T
>  (mod-test -3 -4) -> T ; T
>  (mod-test 3 4) -> T ; T
> 
> As of C99, it appears that C's operators are like truncate and rem.
> 
> I think, IMO, that if you're only going to have one kind of truncating division
> and one kind of mod, it's best to have a division which truncates toward zero,
> and a modulus which is like the Lisp mod: the sign is always positive if the
> modulus is positive, giving you a least positive residue.
> 
> Does the equality  (a/b)*b + a%b  == a  have any practical value?

The practical value is that y | (x - (x % y)).

-- 
Michael Press

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

#16021

On 2012-01-20, Michael Press <rubrum@pacbell.net> wrote:
> In article <slrn3vfsjhflpb.8kc.ike@sverige.freeshell.org>,
>  Ike Naar <ike@sverige.freeshell.org> wrote:
>> The mod operator does not violate that law.
>> Your problem is not with the mod operator, it's
>> that the numbers that are given to the mod operator
>> are not what you think they are.

> You consider that more important than
> the mod operator being consistent. I do not.

I am really wondering if you are hearing what people are saying.

The mod operator is absolutely consistent with that law.  There are no
cases in which the mod operator does not produce the behavior so described...
*BUT*, in some cases the numbers it operates on are not the numbers you see
in the source.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#16027

Seebs <usenet-nospam@seebs.net> writes:

> On 2012-01-20, Michael Press <rubrum@pacbell.net> wrote:
>> In article <slrn3vfsjhflpb.8kc.ike@sverige.freeshell.org>,
>>  Ike Naar <ike@sverige.freeshell.org> wrote:
>>> The mod operator does not violate that law.
>>> Your problem is not with the mod operator, it's
>>> that the numbers that are given to the mod operator
>>> are not what you think they are.
>
>> You consider that more important than
>> the mod operator being consistent. I do not.
>
> I am really wondering if you are hearing what people are saying.
>
> The mod operator is absolutely consistent with that law.  There are no
> cases in which the mod operator does not produce the behavior so described...
> *BUT*, in some cases the numbers it operates on are not the numbers you see
> in the source.

I don't think this is true.  The problematic conversions are part of the
definition of the % operator.  Not all operators include it in their
definition (for example, << and >> only do integer promotions) and %
could have been defined differently.  That would have been odd, to say
the least, but it's the C definition of % that was causing the OP's
surprise, arithmetic conversions and all.

-- 
Ben.

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

#16031

On Sat, 21 Jan 2012 23:21:52 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>Seebs <usenet-nospam@seebs.net> writes:
>
>> On 2012-01-20, Michael Press <rubrum@pacbell.net> wrote:
>>> In article <slrn3vfsjhflpb.8kc.ike@sverige.freeshell.org>,
>>>  Ike Naar <ike@sverige.freeshell.org> wrote:
>>>> The mod operator does not violate that law.
>>>> Your problem is not with the mod operator, it's
>>>> that the numbers that are given to the mod operator
>>>> are not what you think they are.
>>
>>> You consider that more important than
>>> the mod operator being consistent. I do not.
>>
>> I am really wondering if you are hearing what people are saying.
>>
>> The mod operator is absolutely consistent with that law.  There are no
>> cases in which the mod operator does not produce the behavior so described...
>> *BUT*, in some cases the numbers it operates on are not the numbers you see
>> in the source.
>
>I don't think this is true.  The problematic conversions are part of the
>definition of the % operator.  Not all operators include it in their
>definition (for example, << and >> only do integer promotions) and %
>could have been defined differently.  That would have been odd, to say
>the least, but it's the C definition of % that was causing the OP's
>surprise, arithmetic conversions and all.


I don't know.  The conversion rules are not different so much, as
they're subsetted based on the fact that the shift (and some other)
operators only take integral arguments.

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

#16033

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Sat, 21 Jan 2012 23:21:52 +0000, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>Seebs <usenet-nospam@seebs.net> writes:
>>
>>> On 2012-01-20, Michael Press <rubrum@pacbell.net> wrote:
>>>> In article <slrn3vfsjhflpb.8kc.ike@sverige.freeshell.org>,
>>>>  Ike Naar <ike@sverige.freeshell.org> wrote:
>>>>> The mod operator does not violate that law.
>>>>> Your problem is not with the mod operator, it's
>>>>> that the numbers that are given to the mod operator
>>>>> are not what you think they are.
>>>
>>>> You consider that more important than
>>>> the mod operator being consistent. I do not.
>>>
>>> I am really wondering if you are hearing what people are saying.
>>>
>>> The mod operator is absolutely consistent with that law.  There are no
>>> cases in which the mod operator does not produce the behavior so described...
>>> *BUT*, in some cases the numbers it operates on are not the numbers you see
>>> in the source.
>>
>>I don't think this is true.  The problematic conversions are part of the
>>definition of the % operator.  Not all operators include it in their
>>definition (for example, << and >> only do integer promotions) and %
>>could have been defined differently.  That would have been odd, to say
>>the least, but it's the C definition of % that was causing the OP's
>>surprise, arithmetic conversions and all.
>
> I don't know.  The conversion rules are not different so much, as
> they're subsetted based on the fact that the shift (and some other)
> operators only take integral arguments.

I'm not sure what you mean.  % is odd in that it takes only integer
arguments yet it performs the usual arithmetic conversions designed to
establish "a common real type" for the operands.

The more I think about it, the odder % looks.  It could be defined like
the shift operators to do only integer promotions and to yield a value
whose type is that of the promoted left operand.  That would give it
more natural semantics, and, contrary to what I said above, would not be
odd at all.

-- 
Ben.

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

#16046

On Sun, 22 Jan 2012 11:45:22 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Sat, 21 Jan 2012 23:21:52 +0000, Ben Bacarisse
>> <ben.usenet@bsb.me.uk> wrote:
>>
>>>Seebs <usenet-nospam@seebs.net> writes:
>>>
>>>> On 2012-01-20, Michael Press <rubrum@pacbell.net> wrote:
>>>>> In article <slrn3vfsjhflpb.8kc.ike@sverige.freeshell.org>,
>>>>>  Ike Naar <ike@sverige.freeshell.org> wrote:
>>>>>> The mod operator does not violate that law.
>>>>>> Your problem is not with the mod operator, it's
>>>>>> that the numbers that are given to the mod operator
>>>>>> are not what you think they are.
>>>>
>>>>> You consider that more important than
>>>>> the mod operator being consistent. I do not.
>>>>
>>>> I am really wondering if you are hearing what people are saying.
>>>>
>>>> The mod operator is absolutely consistent with that law.  There are no
>>>> cases in which the mod operator does not produce the behavior so described...
>>>> *BUT*, in some cases the numbers it operates on are not the numbers you see
>>>> in the source.
>>>
>>>I don't think this is true.  The problematic conversions are part of the
>>>definition of the % operator.  Not all operators include it in their
>>>definition (for example, << and >> only do integer promotions) and %
>>>could have been defined differently.  That would have been odd, to say
>>>the least, but it's the C definition of % that was causing the OP's
>>>surprise, arithmetic conversions and all.
>>
>> I don't know.  The conversion rules are not different so much, as
>> they're subsetted based on the fact that the shift (and some other)
>> operators only take integral arguments.
>
>I'm not sure what you mean.  % is odd in that it takes only integer
>arguments yet it performs the usual arithmetic conversions designed to
>establish "a common real type" for the operands.
>
>The more I think about it, the odder % looks.  It could be defined like
>the shift operators to do only integer promotions and to yield a value
>whose type is that of the promoted left operand.  That would give it
>more natural semantics, and, contrary to what I said above, would not be
>odd at all.


Perhaps I'm missing something, but other than the modest difference in
wording, how are:

"Each of the operands shall have integer type / integer promotions are
performed on each of the operands" (shift operators)

"Each of the operands shall have integer type / The usual arithmetic
conversions are performed on the operands" (and/or/xor)

and "The operands of the % operator shall have integer type / The
usual arithmetic conversions are performed on the operands" ( % )

any different in result?

As there is no "usual" promotion from any non-integer type
(pointers/floats) *to* an integer type, these would appear to be the
same in all cases.

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

#16047

On 2012-01-23, Robert Wessel <robertwessel2@yahoo.com> wrote:
> and "The operands of the % operator shall have integer type / The
> usual arithmetic conversions are performed on the operands" ( % )
>
> any different in result?
>
> As there is no "usual" promotion from any non-integer type
> (pointers/floats) *to* an integer type, these would appear to be the
> same in all cases.

The usual arithmetic conversions can convert one argument to the type
of the other.

Promotions happen in isolation: e.g. char turns to int (or, on
rare implementations, unsigned int).

Consider:

  (unsigned long) OP (char)

promotions call for:

  (unsigned long) OP (int)

usual conversions:

  (unsigned long) OP (unsigned long)

And now a -ive int value becomes a positive operand.

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

#16052

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Sun, 22 Jan 2012 11:45:22 +0000, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
<snip>
>>The more I think about it, the odder % looks.  It could be defined like
>>the shift operators to do only integer promotions and to yield a value
>>whose type is that of the promoted left operand.  That would give it
>>more natural semantics, and, contrary to what I said above, would not be
>>odd at all.
>
> Perhaps I'm missing something, but other than the modest difference in
> wording, how are:
>
> "Each of the operands shall have integer type / integer promotions are
> performed on each of the operands" (shift operators)
>
> "Each of the operands shall have integer type / The usual arithmetic
> conversions are performed on the operands" (and/or/xor)
>
> and "The operands of the % operator shall have integer type / The
> usual arithmetic conversions are performed on the operands" ( % )
>
> any different in result?

Yes, the usual arithmetic conversions determine (and convert to) a
*common* type after doing the integer promotions.  As a result, you
can't tell what -1 % x is unless you know the type of x.

If % did only arithmetic promotions, the result would be calculated from
the original values of the operands.  The usual arithmetic conversions
can change the sign of one or other operand and thus also change the
result.

<snip>
-- 
Ben.

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

#16216

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Sat, 21 Jan 2012 23:21:52 +0000, Ben Bacarisse
>> <ben.usenet@bsb.me.uk> wrote:
>>
>>>Seebs <usenet-nospam@seebs.net> writes:
>>>
>>>> On 2012-01-20, Michael Press <rubrum@pacbell.net> wrote:
>>>>> In article <slrn3vfsjhflpb.8kc.ike@sverige.freeshell.org>,
>>>>>  Ike Naar <ike@sverige.freeshell.org> wrote:
>>>>>> The mod operator does not violate that law.
>>>>>> Your problem is not with the mod operator, it's
>>>>>> that the numbers that are given to the mod operator
>>>>>> are not what you think they are.
>>>>
>>>>> You consider that more important than
>>>>> the mod operator being consistent. I do not.
>>>>
>>>> I am really wondering if you are hearing what people are saying.
>>>>
>>>> The mod operator is absolutely consistent with that law.  There are no
>>>> cases in which the mod operator does not produce the behavior so described...
>>>> *BUT*, in some cases the numbers it operates on are not the numbers you see
>>>> in the source.
>>>
>>>I don't think this is true.  The problematic conversions are part of the
>>>definition of the % operator.  Not all operators include it in their
>>>definition (for example, << and >> only do integer promotions) and %
>>>could have been defined differently.  That would have been odd, to say
>>>the least, but it's the C definition of % that was causing the OP's
>>>surprise, arithmetic conversions and all.
>>
>> I don't know.  The conversion rules are not different so much, as
>> they're subsetted based on the fact that the shift (and some other)
>> operators only take integral arguments.
>
> I'm not sure what you mean.  % is odd in that it takes only integer
> arguments yet it performs the usual arithmetic conversions designed to
> establish "a common real type" for the operands.
>
> The more I think about it, the odder % looks.  It could be defined like
> the shift operators to do only integer promotions and to yield a value
> whose type is that of the promoted left operand.  That would give it
> more natural semantics, and, contrary to what I said above, would not be
> odd at all.

The argument I would make (that is, defending the status quo) is
that % is an operation whose operand values come from the same
"field" or set of values, kind of a derived operation from
multiplication and addition.  Shift operations, on the other
hand, have operands that come from very different domains;  it
happens that in C both of those domains are (subsets of)
integers, but at some level that's just coincidence.

An example analogy:  suppose our "field" were polynomials (over
a single variable) rather than integers.  If P1 and P2 are
polynomials, it still makes sense to say

   P1 % P2

but no sense to say

   P1 << P2

whereas

   P1 << N

could quite plausibly be defined, for example as P1 * X^N.

Considering the above, it makes sense for % to have the
same promotion rules as * and /.

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

#16048

On 2012-01-21, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> The mod operator is absolutely consistent with that law.  There are no
>> cases in which the mod operator does not produce the behavior so described...
>> *BUT*, in some cases the numbers it operates on are not the numbers you see
>> in the source.

> I don't think this is true.  The problematic conversions are part of the
> definition of the % operator.  Not all operators include it in their
> definition (for example, << and >> only do integer promotions) and %
> could have been defined differently.  That would have been odd, to say
> the least, but it's the C definition of % that was causing the OP's
> surprise, arithmetic conversions and all.

Hmm.  See, I distinguish between the definition of the operation, and the
way in which it gets its operands.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#16051

Seebs <usenet-nospam@seebs.net> writes:

> On 2012-01-21, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Seebs <usenet-nospam@seebs.net> writes:
>>> The mod operator is absolutely consistent with that law.  There are no
>>> cases in which the mod operator does not produce the behavior so described...
>>> *BUT*, in some cases the numbers it operates on are not the numbers you see
>>> in the source.
>
>> I don't think this is true.  The problematic conversions are part of the
>> definition of the % operator.  Not all operators include it in their
>> definition (for example, << and >> only do integer promotions) and %
>> could have been defined differently.  That would have been odd, to say
>> the least, but it's the C definition of % that was causing the OP's
>> surprise, arithmetic conversions and all.
>
> Hmm.  See, I distinguish between the definition of the operation, and the
> way in which it gets its operands.

That would be more reasonable if there were more consistency between
operators, but since some do integer promotions and some do arithmetic
conversions you have to know the rules, and those rule are, at the very
least, "attached" to the definitions of the operators.  Some operators
(+ and - for example) have very complex rules depending on the operand
types.

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 integer promotions are performed on the operands.  The type of
  the result is that of the promoted left operand."

would be complicated to implement, but I am not knowledgeable about
the semantics of machine "remainder" operations.

-- 
Ben.

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

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

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

csiph-web