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

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

Which operation is more expensive?(a <= b and a != 0)

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

Contents

  Which operation is more expensive?(a <= b and a != 0) Ping Cheu <nospam@nospam.com> - 2012-02-27 21:24 +0000
    Re: Which operation is more expensive?(a <= b and a != 0) James Kuyper <jameskuyper@verizon.net> - 2012-02-27 16:47 -0500
      Re: Which operation is more expensive?(a <= b and a != 0) Michael Angelo Ravera <maravera@prodigy.net> - 2012-03-07 04:23 -0800
    Re: Which operation is more expensive?(a <= b and a != 0) Keith Thompson <kst-u@mib.org> - 2012-02-27 13:54 -0800
      Re: Which operation is more expensive?(a <= b and a != 0) falk@rahul.net (Edward A. Falk) - 2012-02-27 23:47 +0000
    Re: Which operation is more expensive?(a <= b and a != 0) Shao Miller <sha0.miller@gmail.com> - 2012-02-27 16:57 -0500
      Re: Which operation is more expensive?(a <= b and a != 0) Stephen Sprunk <stephen@sprunk.org> - 2012-02-28 13:43 -0600
    Re: Which operation is more expensive?(a <= b and a != 0) Richard Damon <news.x.richarddamon@xoxy.net> - 2012-02-27 16:58 -0500
    Re: Which operation is more expensive?(a <= b and a != 0) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-27 13:55 -0800
      Re: Which operation is more expensive?(a <= b and a != 0) Kenneth Brody <kenbrody@spamcop.net> - 2012-03-03 15:58 -0500
    Re: Which operation is more expensive?(a <= b and a != 0) Keith Thompson <kst-u@mib.org> - 2012-02-27 14:17 -0800
    Re: Which operation is more expensive?(a <= b and a != 0) Barry Schwarz <schwarz45@yahoo.com> - 2012-02-27 14:52 -0800
      Re: Which operation is more expensive?(a <= b and a != 0) Peter Nilsson <airia@acay.com.au> - 2012-02-27 18:16 -0800
        Re: Which operation is more expensive?(a <= b and a != 0) qarnos <darrencubitt@gmail.com> - 2012-02-29 12:20 -0800
        Re: Which operation is more expensive?(a <= b and a != 0) Barry Schwarz <schwarzb@dqel.com> - 2012-03-13 22:07 -0700
    Re: Which operation is more expensive?(a <= b and a != 0) Kaz Kylheku <kaz@kylheku.com> - 2012-02-28 00:56 +0000
    Re: Which operation is more expensive?(a <= b and a != 0) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-02-27 19:18 -0700
      Re: Which operation is more expensive?(a <= b and a != 0) China Blue Sea <chine.bleu@yahoo.com> - 2012-02-27 18:30 -0800
    Re: Which operation is more expensive?(a <= b and a != 0) "BartC" <bc@freeuk.com> - 2012-02-28 13:22 +0000
    Re: Which operation is more expensive?(a <= b and a != 0) Stephen Sprunk <stephen@sprunk.org> - 2012-02-28 13:38 -0600
    Re: Which operation is more expensive?(a <= b and a != 0) jgk@panix.com (Joe keane) - 2012-02-28 22:35 +0000
      Re: Which operation is more expensive?(a <= b and a != 0) Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-03-03 01:36 +0200
        Re: Which operation is more expensive?(a <= b and a != 0) jgk@panix.com (Joe keane) - 2012-03-05 20:03 +0000
          Re: Which operation is more expensive?(a <= b and a != 0) Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-03-12 01:08 +0200
            Re: Which operation is more expensive?(a <= b and a != 0) Harald van Dijk <haraldvdijk@gmail.com> - 2012-03-12 00:05 -0700
              Re: Which operation is more expensive?(a <= b and a != 0) James Kuyper <jameskuyper@verizon.net> - 2012-03-12 08:59 -0400
                Re: Which operation is more expensive?(a <= b and a != 0) gwowen <gwowen@gmail.com> - 2012-03-12 06:24 -0700
                  Re: Which operation is more expensive?(a <= b and a != 0) James Kuyper <jameskuyper@verizon.net> - 2012-03-12 10:13 -0400
                    Re: Which operation is more expensive?(a <= b and a != 0) Keith Thompson <kst-u@mib.org> - 2012-03-12 10:44 -0700
                    Re: Which operation is more expensive?(a <= b and a != 0) Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-03-13 17:12 +0200
            Re: Which operation is more expensive?(a <= b and a != 0) Keith Thompson <kst-u@mib.org> - 2012-03-12 11:20 -0700

Page 2 of 2 — ← Prev page 1 [2]

#18046

In article <jigsb4$rdc$1@speranza.aioe.org>,
Ping Cheu  <nospam@nospam.com> wrote:
>Can anyone tell me? 

I prefer the count-down method.

    ct = len;
    zp = bas;

    while (--ct >= 0)
    {
	...(*zp)
	zp++;
    }

Think about it.  You need a finite-state machine that outputs "0" ten
times then "1" one time.  How much state do you need?  About four bits,
certainly not two registers.

For complicated code, register allocation is always an issue (doubly so
for old x86).

If your compiler disdecides that loop control should be in registers,
and kicks out some other value that is really more important, it may be
an issue.

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

#18128

jgk@panix.com (Joe keane) writes:
> In article <jigsb4$rdc$1@speranza.aioe.org>,
> Ping Cheu  <nospam@nospam.com> wrote:
> >Can anyone tell me? 
> 
> I prefer the count-down method.
> 
>     ct = len;
>     zp = bas;
> 
>     while (--ct >= 0)

So you don't like unsigned types for counters then?

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

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

#18239

In article <87ipimmv7t.fsf@bazspaz.fatphil.org>,
Phil Carmody  <thefatphil_demunged@yahoo.co.uk> wrote:
>So you don't like unsigned types for counters then?

It's typical C to use 'int' unless something else is needed.

It's probably an error if the counter comes in negative [or negative if
it were signed if it's unsigned], but maybe running zero times is fine.

    beg = 8;
    end = 6;
    for (j = beg; j < end; j++)
	...

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

#18562

jgk@panix.com (Joe keane) writes:
> In article <87ipimmv7t.fsf@bazspaz.fatphil.org>,
> Phil Carmody  <thefatphil_demunged@yahoo.co.uk> wrote:
> >So you don't like unsigned types for counters then?
> 
> It's typical C to use 'int' unless something else is needed.

Sloppiness is typical too.

Possibly without exception, when the standard library provides an
interface for a function that implies operating over an array of
objects, the number of objects is specified as an unsigned type. 
The sanest internal behaviour for those functions is to have the
same unsigned type as the index controlling the loop.  So there 
are plenty of very common examples of at least implicit unsigned 
counters.

> It's probably an error if the counter comes in negative [or negative if
> it were signed if it's unsigned]

can't parse that, sorry

>, but maybe running zero times is fine.
> 
>     beg = 8;
>     end = 6;
>     for (j = beg; j < end; j++)
> 	...

Ewwwww, integer overflow. Were you attemting to put forward a case
*for* the use of unsigned integers, as at least you'd know that you'd
wrap.

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

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

#18569

On Mar 12, 12:08 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
> j...@panix.com (Joe keane) writes:
> >, but maybe running zero times is fine.
>
> >     beg = 8;
> >     end = 6;
> >     for (j = beg; j < end; j++)
> >    ...
>
> Ewwwww, integer overflow. Were you attemting to put forward a case
> *for* the use of unsigned integers, as at least you'd know that you'd
> wrap.

Maybe I'm being daft, but when does this overflow?

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

#18578

On 03/12/2012 03:05 AM, Harald van Dijk wrote:
> On Mar 12, 12:08�am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> wrote:
>> j...@panix.com (Joe keane) writes:
>>> , but maybe running zero times is fine.
>>
>>> � � beg = 8;
>>> � � end = 6;
>>> � � for (j = beg; j < end; j++)
>>> � �...
>>
>> Ewwwww, integer overflow. Were you attemting to put forward a case
>> *for* the use of unsigned integers, as at least you'd know that you'd
>> wrap.
> 
> Maybe I'm being daft, but when does this overflow?

When the j++ expression is executed with j==INT_MAX, which will happen
unless something is done inside the loop to prevent it from happening.
Were you perhaps thinking of beg=6, end=8?
-- 
James Kuyper

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

#18579

On Mar 12, 12:59 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 03/12/2012 03:05 AM, Harald van Dijk wrote:
>
> > On Mar 12, 12:08 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> > wrote:
> >> j...@panix.com (Joe keane) writes:
> >>> , but maybe running zero times is fine.
>
> >>> beg = 8;
> >>> end = 6;
> >>> for (j = beg; j < end; j++)
> >>> ...
>
> >> Ewwwww, integer overflow. Were you attemting to put forward a case
> >> *for* the use of unsigned integers, as at least you'd know that you'd
> >> wrap.
>
> > Maybe I'm being daft, but when does this overflow?
>
> When the j++ expression is executed with j==INT_MAX, which will happen
> unless something is done inside the loop to prevent it from happening.
> Were you perhaps thinking of beg=6, end=8?

It says "j < end" not "j != end"

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

#18581

On 03/12/2012 09:24 AM, gwowen wrote:
> On Mar 12, 12:59 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> On 03/12/2012 03:05 AM, Harald van Dijk wrote:
>>
>>> On Mar 12, 12:08 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
>>> wrote:
>>>> j...@panix.com (Joe keane) writes:
>>>>> , but maybe running zero times is fine.
>>
>>>>> beg = 8;
>>>>> end = 6;
>>>>> for (j = beg; j < end; j++)
>>>>> ...
>>
>>>> Ewwwww, integer overflow. Were you attemting to put forward a case
>>>> *for* the use of unsigned integers, as at least you'd know that you'd
>>>> wrap.
>>
>>> Maybe I'm being daft, but when does this overflow?
>>
>> When the j++ expression is executed with j==INT_MAX, which will happen
>> unless something is done inside the loop to prevent it from happening.
>> Were you perhaps thinking of beg=6, end=8?
> 
> It says "j < end" not "j != end"

No, my misreading of that code was more complicated than that - but it's
not worth going into. Harald was right, and Phil and I were both wrong -
the code shown does not result in overflow.

The code shown is probably defective; as written either beg and end are
reversed, or the loop was meant to go downward. However, if beg=8 and
end=6 are simplifications for more complicated statements that,
depending upon the values of the other variables, sometimes result in
beg < end, the more complicated statements could be part of a reasonable
program.

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

#18596

James Kuyper <jameskuyper@verizon.net> writes:
[...]
>>>>> j...@panix.com (Joe keane) writes:
>>>>>> , but maybe running zero times is fine.
>>>
>>>>>> beg = 8;
>>>>>> end = 6;
>>>>>> for (j = beg; j < end; j++)
>>>>>> ...
[...]
> The code shown is probably defective; as written either beg and end are
> reversed, or the loop was meant to go downward. However, if beg=8 and
> end=6 are simplifications for more complicated statements that,
> depending upon the values of the other variables, sometimes result in
> beg < end, the more complicated statements could be part of a reasonable
> program.

I think the code was intended to demonstrate a loop that executes 0
times, as implied by the preceding "but maybe running zero times is
fine".

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

#18678

James Kuyper <jameskuyper@verizon.net> writes:

> On 03/12/2012 09:24 AM, gwowen wrote:
> > On Mar 12, 12:59 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> >> On 03/12/2012 03:05 AM, Harald van Dijk wrote:
> >>
> >>> On Mar 12, 12:08 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> >>> wrote:
> >>>> j...@panix.com (Joe keane) writes:
> >>>>> , but maybe running zero times is fine.
> >>
> >>>>> beg = 8;
> >>>>> end = 6;
> >>>>> for (j = beg; j < end; j++)
> >>>>> ...
> >>
> >>>> Ewwwww, integer overflow. Were you attemting to put forward a case
> >>>> *for* the use of unsigned integers, as at least you'd know that you'd
> >>>> wrap.
> >>
> >>> Maybe I'm being daft, but when does this overflow?
> >>
> >> When the j++ expression is executed with j==INT_MAX, which will happen
> >> unless something is done inside the loop to prevent it from happening.
> >> Were you perhaps thinking of beg=6, end=8?
> > 
> > It says "j < end" not "j != end"
> 
> No, my misreading of that code was more complicated than that - but it's
> not worth going into. Harald was right, and Phil and I were both wrong -
> the code shown does not result in overflow.

Me more than you - I started it!


-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

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

#18599

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
[...]
> Possibly without exception, when the standard library provides an
> interface for a function that implies operating over an array of
> objects, the number of objects is specified as an unsigned type. 
[...]

And that unsigned type is almost always size_t.

The only exception I can find is the "%n" printf format, which expects a
pointer to an int (or you use "%ln" for long, or "%lln" for long long).

-- 
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] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web