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

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

Performance of signed vs unsigned types

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

Contents

  Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 14:21 +0100
    Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-20 09:49 -0400
      Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 15:21 +0100
      Re: Performance of signed vs unsigned types Peter Nilsson <airia@acay.com.au> - 2011-04-20 15:34 -0700
        Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-21 17:57 +0100
          Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-21 19:26 +0100
      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-20 21:45 -0700
        Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-21 06:20 -0400
          Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-21 13:54 -0700
            Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-21 18:50 -0400
              Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-21 16:16 -0700
                Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-21 19:27 -0400
                  Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-21 17:24 -0700
                    Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-21 21:00 -0400
                      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-21 21:33 -0700
                        Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-22 08:22 +0100
                          Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-22 14:25 -0700
                        Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-22 09:21 -0400
                          Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-22 14:22 -0700
                            Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-22 17:58 -0400
                              Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-22 17:33 -0700
                                Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-23 09:01 -0400
                                  Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-23 14:07 -0700
                                    Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-23 18:14 -0400
                                      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 11:42 -0700
                                        Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-25 22:34 -0400
                                        Re: Performance of signed vs unsigned types gordonb.nw63u@burditt.org (Gordon Burditt) - 2011-04-26 10:59 -0500
                        Re: Performance of signed vs unsigned types "madamemandm@yahoo.com" <madamemandm@yahoo.com> - 2011-04-22 07:55 -0700
                          Re: Performance of signed vs unsigned types Noob <root@127.0.0.1> - 2011-04-22 17:03 +0200
                            Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-22 08:42 -0700
                          Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-22 14:15 -0700
                            Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-22 15:23 -0700
                              Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-22 17:37 -0700
                                Re: Performance of signed vs unsigned types Seebs <usenet-nospam@seebs.net> - 2011-04-23 02:46 +0000
                                  Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-23 14:04 -0700
                                    Re: Performance of signed vs unsigned types Barry Schwarz <schwarzb@dqel.com> - 2011-04-23 14:28 -0700
                                      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 11:43 -0700
                                    Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-23 23:38 +0100
                                      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 11:46 -0700
                                        Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-25 22:43 +0100
                                    Re: Performance of signed vs unsigned types Seebs <usenet-nospam@seebs.net> - 2011-04-24 11:34 +0000
                                      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 11:47 -0700
                                        Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-25 12:32 -0700
                                          Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 20:25 -0700
                                            Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-26 07:45 -0700
                                    Re: Performance of signed vs unsigned types lawrence.jones@siemens.com - 2011-04-24 23:50 -0400
                                      Re: Performance of signed vs unsigned types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-04-25 02:13 -0700
                                        Re: Performance of signed vs unsigned types Ian Collins <ian-news@hotmail.com> - 2011-04-25 21:36 +1200
                                      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 11:48 -0700
                                        Re: Performance of signed vs unsigned types lawrence.jones@siemens.com - 2011-04-25 16:32 -0400
                                          Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-25 15:22 -0700
                                            Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 20:32 -0700
                                              Re: Performance of signed vs unsigned types "io_x" <a@b.c.invalid> - 2011-04-26 09:42 +0200
                                              Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-26 12:04 +0100
                                              Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-26 08:15 -0700
                                                Re: Performance of signed vs unsigned types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-04-26 08:35 -0700
                                                Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-26 08:52 -0700
                                                  Re: Performance of signed vs unsigned types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-04-26 09:15 -0700
                                                    Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-26 10:22 -0700
                                                Re: Performance of signed vs unsigned types gordonb.s68qo@burditt.org (Gordon Burditt) - 2011-04-26 19:59 -0500
                                                  Re: Performance of signed vs unsigned types "madamemandm@yahoo.com" <madamemandm@yahoo.com> - 2011-04-27 14:15 -0700
                                                  Re: Performance of signed vs unsigned types "io_x" <a@b.c.invalid> - 2011-04-28 12:15 +0200
                                                  Re: Performance of signed vs unsigned types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-04-28 03:26 -0700
                                                    Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-28 12:09 +0100
                                                    Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-28 08:03 -0400
                                                    Re: Performance of signed vs unsigned types Seebs <usenet-nospam@seebs.net> - 2011-04-28 16:44 +0000
                                                    Re: Performance of signed vs unsigned types Gordon Burditt <gordon@hammy.burditt.org> - 2011-04-29 05:42 -0500
                                          Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 20:27 -0700
                                            Re: Performance of signed vs unsigned types Ian Collins <ian-news@hotmail.com> - 2011-04-26 15:30 +1200
                                              Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-26 00:14 -0700
                                                Re: Performance of signed vs unsigned types Ian Collins <ian-news@hotmail.com> - 2011-04-26 20:23 +1200
                                                Re: Performance of signed vs unsigned types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-04-26 04:17 -0700
                      Re: Performance of signed vs unsigned types Ike Naar <ike@sverige.freeshell.org> - 2011-04-22 06:46 +0000
                        Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-22 09:37 -0400
                        Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 11:49 -0700
                Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-22 09:09 -0700
                  Re: Performance of signed vs unsigned types "madamemandm@yahoo.com" <madamemandm@yahoo.com> - 2011-04-22 09:46 -0700
                  Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-22 20:21 +0100
    Re: Performance of signed vs unsigned types "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2011-04-20 10:06 -0400
      Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 15:28 +0100
        Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-20 16:11 +0100
        Re: Performance of signed vs unsigned types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-04-20 08:14 -0700
          Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 16:24 +0100
            Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 17:09 +0100
              Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 17:19 +0100
                Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-20 12:09 -0700
                  Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 21:39 +0100
                    Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-20 15:01 -0700
                      Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-21 11:16 +0100
        Re: Performance of signed vs unsigned types "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2011-04-20 13:06 -0400
          Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 18:16 +0100
    Re: Performance of signed vs unsigned types gordonb.bfd7y@burditt.org (Gordon Burditt) - 2011-04-21 11:22 -0500
      Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-21 19:27 +0100
        Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-21 12:09 -0700

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

#2968

On Apr 26, 7:59 pm, gordonb.s6...@burditt.org (Gordon Burditt) wrote:
[snip]
> The code I'm including here is for signed multiplication only.
> Someone might find it useful.  Ok, try to break it.

Sure thing.

>  I'm not sure
> I have properly accounted for all the possible wierdities on a
> non-2's-complement machine, and I don't have one to test on.
>
> The main source file is pretty simple, for making the code type-generic:
> ______________________________________________________
> #include <limits.h>
>
> #define VALUE_T                 signed long
> #define VALUE_MIN               LONG_MIN
> #define VALUE_MAX               LONG_MAX
>
> #define mul_will_overflow       sl_mul_will_overflow
>
> #include "smul.inc"
> ______________________________________________________
>
> and it included the appropriate code, here for signed multiply:
>
> ______________________________________________________
> #include "libovflo.h" /* contains function prototypes for the library */
>
> int
> mul_will_overflow(VALUE_T a, VALUE_T b, VALUE_T * c)
> {
>     if (a == 0 || a == 1 || b == 0 || b == 1)
>     {
>         /* cannot overflow */
>     }
>     else
>     {
>         if (VALUE_MAX - 1 < -1 - VALUE_MIN)
>         {
>             /* -VALUE_MIN overflows */
>             if (a == VALUE_MIN || b == VALUE_MIN)
>             {
>                 /* -1 * VALUE_MIN overflows */
>                 /* 0 * VALUE_MIN and 1 * VALUE_MIN handled above */
>                 /* anything else overflows */
>                 return 1;
>             }
>         }
>         if (a > 0)
>         {
>             if (b > 0)
>             {
>                 /* a, b positive */
>                 if (VALUE_MAX / b < a)
>                 {
>                     return 1;
>                 }
>             }
>             else
>             {
>                 /* a positive, b negative */
>                 if ((((-b) - VALUE_MIN) / (-b)) - 1 < a)
>                 {
>                     return 1;
>                 }
>             }
>         }
>         else
>         {
>             if (b > 0)
>             {
>                 /* a negative, b positive */
>                 if (((b - VALUE_MIN) / b) - 1 < (-a))
>                 {
>                     return 1;
>                 }
>             }
>             else
>             {
>                 /* a, b negative */
>                 if (VALUE_MAX / (-b) < (-a))
>                 {
>                     return 1;
>                 }
>             }
>         }
>     }
>     if (c)
>     {
>         *c = a * b;
>     }
>
>     return 0;}

The mixed sign tests look wrong to me.  In both of them you are
subtracting VALUE_MIN from a postitive number.  This is gaurenteed to
produce a value greater than VALUE_MAX and is therefore undefined.
E.g. let a = 15, b = -2, VALUE_MIN = -2147483648, VALUE_MAX =
2147483647 then the test selected is

(((-b) - VALUE_MIN) / (-b)) - 1 < a

Substituting the values gets.

(((-(-2)) - (-2147483648)) / (-(-2))) - 1 < 15

Simplifying a bit.

((2 - (-2147483648)) / 2) < 15
(2147483650 / 2) < 15

And 2147483650 > 2147483647.


Even if it was correct, it would still be illustrative of the value of
adding the ability to check for overflow to the core language.
Overflow on multiplication can be detected in just a few assembly
instruction on quite a few processors.  I'd be impressed if a compiler
managed to convert that source into those instructions.

Martin Shobe

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

#2981

"Gordon Burditt" <gordonb.s68qo@burditt.org> ha scritto nel messaggio
news:ydudnWX_yc329yrQnZ2dnUVZ_oqdnZ2d@posted.internetamerica...
> #include "libovflo.h" /* contains function prototypes for the library */
>
> int
> mul_will_overflow(VALUE_T a, VALUE_T b, VALUE_T * c)
> {
>    if (a == 0 || a == 1 || b == 0 || b == 1)
>    {
> /* cannot overflow */
>    }
>    else
>    {
> if (VALUE_MAX - 1 < -1 - VALUE_MIN)
> {
>     /* -VALUE_MIN overflows */
>     if (a == VALUE_MIN || b == VALUE_MIN)
>     {
> /* -1 * VALUE_MIN overflows */
> /* 0 * VALUE_MIN and 1 * VALUE_MIN handled above */
> /* anything else overflows */
> return 1;
>     }
> }
> if (a > 0)
> {
>     if (b > 0)
>     {
> /* a, b positive */
> if (VALUE_MAX / b < a)
> {
>     return 1;
> }
>     }
>     else
>     {
> /* a positive, b negative */
> if ((((-b) - VALUE_MIN) / (-b)) - 1 < a)
> {
>     return 1;
> }
>     }
> }
> else
> {
>     if (b > 0)
>     {
> /* a negative, b positive */
> if (((b - VALUE_MIN) / b) - 1 < (-a))
> {
>     return 1;
> }
>     }
>     else
>     {
> /* a, b negative */
> if (VALUE_MAX / (-b) < (-a))
> {
>     return 1;
> }
>     }
> }
>    }
>    if (c)
>    {
> *c = a * b;
>    }
>
>    return 0;
> }

all above use too much vertical space
how many lines have your monitor?

i have the problem inverse, i want see too much
it is possible, nowdays i change the font of the ide i use
+ the font of notepad for to be very small only for that
--------
yes could be portable, can be ok for each type,
but for unsigned int in x86
one asm instruction could be suffient...

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

#2982

How about

if(fabs((double)x * double(y)) > INT_MAX)
  return 1;

It's a one-liner. You need a two liner to handle the special case of
INT_MIN, which probably isn't worth it.

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

#2983

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> if(fabs((double)x * double(y)) > INT_MAX)
>   return 1;

Typo: double(y) should be (double)y

> It's a one-liner. You need a two liner to handle the special case of
> INT_MIN, which probably isn't worth it.

Unless the campaign for 64-bit ints also demands more bits for double
this is likely to run into trouble.

-- 
Ben.

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

#2985

On 04/28/2011 06:26 AM, Malcolm McLean wrote:
> How about
> 
> if(fabs((double)x * double(y)) > INT_MAX)
>   return 1;
> 
> It's a one-liner. You need a two liner to handle the special case of
> INT_MIN, which probably isn't worth it.

That is a conceptually simple solution, which is a real advantage.

However, it assumes that DBL_MAX > INT_MAX, which is an extremely
plausible assumption, but technically not guaranteed. It's more
plausible for larger integer types, especially intmax_t.

With 64-bit integers, there's another potential problem that's much more
likely to occur: most 64-bit integer values cannot be converted to a
64-bit double type without change of value. As a result, the calculated
product might not be correct. In many cases where the product is
sufficiently close to INT64_MAX, the calculated product will be larger
than the limit, even though the mathematical product is not (and
vice-versa).

Finally, I'd expect the conversions to double, the double precision
multiplication, and the fabs() call to collectively take much longer to
execute than appropriately written code relying solely on integer
operations. This is less important than the correctness issues, but
still can be important.

-- 
James Kuyper

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

#2986

On 2011-04-28, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> How about
>
> if(fabs((double)x * double(y)) > INT_MAX)
>   return 1;
>
> It's a one-liner. You need a two liner to handle the special case of
> INT_MIN, which probably isn't worth it.

On at least some systems, double does not have enough bits to accurately
represent all possible values of int; in particular, past a certain point,
you stop having odd numbers.  About twice that point, you stop having numbers
which are not multiples of 4...

One can conceive of a pair of numbers which have the interesting property
that x * y is an overflow operation on int, but that this calculation
does not detect it.  (Well, assuming we fix the typo on the second cast.)

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

#3031

> if(fabs((double)x * double(y)) > INT_MAX)
>  return 1;

The code is supposed to be type-generic for signed integer types
(and what I posted used LONG_MAX).  It probably won't work for long
long, which is 64 bits and double typically has less than 64 bits
of mantissa.  It's also supposted to work for intmax_t, which someone
might make 128Kbits on a processor used for RSA encryption.

If the advocates of 64-bit ints have their way, the code above as
written will have roundoff errors converting int to double, and
give wrong answers under certain circumstances.

> It's a one-liner. You need a two liner to handle the special case of
> INT_MIN, which probably isn't worth it.

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

#2899

In article <db2h88-t8c.ln1@jones.homeip.net>,
 lawrence.jones@siemens.com wrote:

> Michael Press <rubrum@pacbell.net> wrote:
> > 
> > People writing safety-critical code do not 
> > range check arguments, and examine return values?
> 
> Of course they do, but that isn't sufficient to prevent overflow.

In the field? Are you serious?
I can see overflow traps for development, 
but not in the field where failure is costly.

-- 
Michael Press

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

#2900

On 04/26/11 03:27 PM, Michael Press wrote:
> In article<db2h88-t8c.ln1@jones.homeip.net>,
>   lawrence.jones@siemens.com wrote:
>
>> Michael Press<rubrum@pacbell.net>  wrote:
>>>
>>> People writing safety-critical code do not
>>> range check arguments, and examine return values?
>>
>> Of course they do, but that isn't sufficient to prevent overflow.
>
> In the field? Are you serious?
> I can see overflow traps for development,
> but not in the field where failure is costly.

The real world is where problems are more likely to be found.  Failure 
may be costly, but errors can be disastrous.

-- 
Ian Collins

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

#2905

In article <91msjgFq9bU3@mid.individual.net>,
 Ian Collins <ian-news@hotmail.com> wrote:

> On 04/26/11 03:27 PM, Michael Press wrote:
> > In article<db2h88-t8c.ln1@jones.homeip.net>,
> >   lawrence.jones@siemens.com wrote:
> >
> >> Michael Press<rubrum@pacbell.net>  wrote:
> >>>
> >>> People writing safety-critical code do not
> >>> range check arguments, and examine return values?
> >>
> >> Of course they do, but that isn't sufficient to prevent overflow.
> >
> > In the field? Are you serious?
> > I can see overflow traps for development,
> > but not in the field where failure is costly.
> 
> The real world is where problems are more likely to be found.  Failure 
> may be costly, but errors can be disastrous.

Are you playing word games now? Error---Failure. 
If it traps in the field it is disaster whether 
it called error or failure.

-- 
Michael Press

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

#2909

On 04/26/11 07:14 PM, Michael Press wrote:
> In article<91msjgFq9bU3@mid.individual.net>,
>   Ian Collins<ian-news@hotmail.com>  wrote:
>
>> On 04/26/11 03:27 PM, Michael Press wrote:
>>> In article<db2h88-t8c.ln1@jones.homeip.net>,
>>>    lawrence.jones@siemens.com wrote:
>>>
>>>> Michael Press<rubrum@pacbell.net>   wrote:
>>>>>
>>>>> People writing safety-critical code do not
>>>>> range check arguments, and examine return values?
>>>>
>>>> Of course they do, but that isn't sufficient to prevent overflow.
>>>
>>> In the field? Are you serious?
>>> I can see overflow traps for development,
>>> but not in the field where failure is costly.
>>
>> The real world is where problems are more likely to be found.  Failure
>> may be costly, but errors can be disastrous.
>
> Are you playing word games now? Error---Failure.
> If it traps in the field it is disaster whether
> it called error or failure.

No at all.  What would you rather do, reset the X-ray machine, or 
overdose the patient?

The  controllers I used to work on, while not safety critical did power 
lots of expensive and often remote equipment.  The wrong voltage at the 
wrong time could kill it.  The system would carry on on default settings 
if the controller went away, so a reset was the safest failure mode.

-- 
Ian Collins

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

#2918

On Apr 26, 10:14 am, Michael Press <rub...@pacbell.net> wrote:
>
> Are you playing word games now? Error---Failure.
> If it traps in the field it is disaster whether
> it called error or failure.
>
No, errors are usually worse (unless you are programming video games).

The reason is that "inject 500ml of saline" (instead of 500ul) will
kill the patient, "arithmetic overflow at line 1000" is no different
to the needle breaking or the bag bursting. Mechanical failures
happen, the system as a whole is usually robust to them.

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

#2766

On 2011-04-22, James Kuyper <jameskuyper@verizon.net> wrote:
> [...] However, that leaves me with
> no idea why you thought it would work. Would you care to explain what
> assumptions you were making about the results of signed integer overflow
> when you wrote that code?
>
> It did work, on the machines where I tested it, and it worked precisely
> because x+step did produce a negative value.

Perhaps he's hinting at saturating arithmetic.

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

#2772

On 04/22/2011 02:46 AM, Ike Naar wrote:
> On 2011-04-22, James Kuyper <jameskuyper@verizon.net> wrote:
>> [...] However, that leaves me with
>> no idea why you thought it would work. Would you care to explain what
>> assumptions you were making about the results of signed integer overflow
>> when you wrote that code?
>>
>> It did work, on the machines where I tested it, and it worked precisely
>> because x+step did produce a negative value.
> 
> Perhaps he's hinting at saturating arithmetic.

He's stated that he's assuming that "Multiplication is  distributive
over addition". Saturating arithmetic violates that assumption:

	int x = 2;
	int y = INT_MAX - 1;
	int z = INT_MIN + 3;

The expression x*(y+z) has the value of 2 * (INT_MAX + INT_MIN + 2), but
under saturating arithmetic, x*y + x*z has the value INT_MAX + INT_MIN,
which is generally not the same value.

-- 
James Kuyper

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

#2881

In article <slrn3vfsir2930.6ul.ike@sverige.freeshell.org>,
 Ike Naar <ike@sverige.freeshell.org> wrote:

> On 2011-04-22, James Kuyper <jameskuyper@verizon.net> wrote:
> > [...] However, that leaves me with
> > no idea why you thought it would work. Would you care to explain what
> > assumptions you were making about the results of signed integer overflow
> > when you wrote that code?
> >
> > It did work, on the machines where I tested it, and it worked precisely
> > because x+step did produce a negative value.
> 
> Perhaps he's hinting at saturating arithmetic.

No, I never was.

-- 
Michael Press

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

#2778

Michael Press <rubrum@pacbell.net> writes:
> In article <ioqcbo$irj$1@dont-email.me>,
>  James Kuyper <jameskuyper@verizon.net> wrote:
>> On 04/21/2011 04:54 PM, Michael Press wrote:
>> > In article <iop0dp$ivo$1@dont-email.me>,
>> >  James Kuyper <jameskuyper@verizon.net> wrote:
>> > 
>> >> On 04/21/2011 12:45 AM, Michael Press wrote:
>> >>> In article <iomoa5$vfr$1@dont-email.me>,
>> ...
>> >>> $ cat try.c
>> >>> #include <stdio.h>
>> >>>
>> >>> int
>> >>> main(void)
>> >>> {
>> >>>     int             x;
>> >>>     int             y;
>> >>>     int             step;
>> >>>
>> >>>     x = step = 1;
>> >>>     for (; step != 0;)
>> >>>     {
>> >>>         if ((y = x + step) > x)
>> >>>         {
>> >>>             x = y;
>> >>>             if ((y = 2 * step) > step)
>> >>>             step = y;
>> >>>         }
>> >>>         else
>> >>>         {
>> >>>             step /= 2;
>> >>>         }
>> >>>     }
>> >>>     printf("Maximum int = %d = %#x.\n", x, x);
>> >>>     return 0;
>> >>> }
>> >>
>> >> That's one example of precisely what I was talking about. As soon as x >
>> >> INT_MAX - step, the expression x+step has undefined behavior; as soon as
>> >> step > INT_MAX/2, the expression 2*step has undefined behavior. The
>> >> above code seems to rely upon the unportable assumption that the actual
>> >> behavior in each of those cases will be to produce a result that is
>> >> negative. That's very common behavior, but it's not guaranteed by the
>> >> standard. That's what I meant by "serious portability issues".
>> > 
>> > Does not assume it goes negative.
>> 
>> By assuming that adding two positive ints, or multiplying a positive int
>> by 2, will produce a negative result when the operation overflows
>
> No, it does not.

It certainly makes *some* assumption(s) not guaranteed by the standard.

Specifically, it appears to assume that, where step is a positive
int value, evaluating (x + step) will yield a value less than x if
and only if the mathematical result of (x + step) exceeds INT_MAX.

Again, as James wrote in text that you snipped, there are probably
other sets of assumptions that would also make the program work.
But there is no set of assumptions that make the program work that
cannot be violated by a conforming implementation.  In other words,
there can be conforming C implementation on which your program does
*not* print "Maxmum int = " followed by the correct value of INT_MAX.

For example, if signed integer overflow causes the program to terminate,
then your program won't print anything.

Another example: Suppose a CPU provides 64-bit integer registers,
with addition and comparison working correctly for all 64-bit values,
but with multiplication and division working correctly only for
up to, say, 48-bit values.  The C implementation chooses to store
ints in 64 bits, but to make INT_MAX 2**47-1 -- i.e., an int has
16 padding bits.  It doesn't generate additional code to check for
overflow, since the behavior is undefined anyway.  For operands and
results in the range INT_MIN..INT_MAX, all operations work correctly.
But the conditions
    INT_MAX + 1 > INT_MAX
and
    INT_MAX + INT_MAX > INT_MAX
will both be true.

The above is based on my very faulty recollection of the Cray T90 and
similar machines.  It's probably incorrect in some significant ways,
but it is, I believe, a conforming hypothetical implementation.  As I
recall, long was also stored  in 64 bits, but without the padding
bits, making multiplication and division more expensive because
the compiler had to generate extra code to get correct results.

In general, without either access to <limits.h> or assumptions
about operations whose behavior is undefined, I don't believe it's
possible to determine the correct value for INT_MAX in portable C.

A contrived example: You could take a conforming implementation
with, say, 32-bit 2's-complement ints with no padding bits or
trap representations, and INT_MAX==2**31-1, and create a second
implementation that's identical *except* that INT_MAX==2**30-1 and
INT_MIN==-2**30.  Arithmetic on int values would continue to work
exactly the same way, but the implementation woud simply choose
not to define the behavior of any int operations that yield values
exceeding the new tighter bounds.

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

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

#2781

On Apr 22, 11:09 am, Keith Thompson <ks...@mib.org> wrote:
> Michael Press <rub...@pacbell.net> writes:
> > In article <ioqcbo$ir...@dont-email.me>,
> >  James Kuyper <jameskuy...@verizon.net> wrote:
> >> On 04/21/2011 04:54 PM, Michael Press wrote:
> >> > In article <iop0dp$iv...@dont-email.me>,
> >> >  James Kuyper <jameskuy...@verizon.net> wrote:
>
> >> >> On 04/21/2011 12:45 AM, Michael Press wrote:
> >> >>> $ cat try.c
> >> >>> #include <stdio.h>
>
> >> >>> int
> >> >>> main(void)
> >> >>> {
> >> >>>     int             x;
> >> >>>     int             y;
> >> >>>     int             step;
>
> >> >>>     x = step = 1;
> >> >>>     for (; step != 0;)
> >> >>>     {
> >> >>>         if ((y = x + step) > x)
> >> >>>         {
> >> >>>             x = y;
> >> >>>             if ((y = 2 * step) > step)
> >> >>>             step = y;
> >> >>>         }
> >> >>>         else
> >> >>>         {
> >> >>>             step /= 2;
> >> >>>         }
> >> >>>     }
> >> >>>     printf("Maximum int = %d = %#x.\n", x, x);
> >> >>>     return 0;
> >> >>> }
[snip]
>
> A contrived example: You could take a conforming implementation
> with, say, 32-bit 2's-complement ints with no padding bits or
> trap representations, and INT_MAX==2**31-1, and create a second
> implementation that's identical *except* that INT_MAX==2**30-1 and
> INT_MIN==-2**30.  Arithmetic on int values would continue to work
> exactly the same way, but the implementation woud simply choose
> not to define the behavior of any int operations that yield values
> exceeding the new tighter bounds.
>

We don't even need to come up with contrived representations for
signed int to have it fail in some implementations.  A compiler could
notice that the value of step is either >= 0 or undefined.  This would
mean that x + step > x is false only if step = 0, which can't happen
because of the condition in the for loop.  Similarly, the test for 2 *
step > step would also always succeed.  The compiler then converts it
into something more like this...

int main (void)
{
    int x = 1;
    int y;
    int step = 1;

    while (step != 0)
    {
        x += step;
        step *= 2;
    }

    printf("Maximum int = %d = %#x.\n", x, x);
    return 0;
}

At this point, the compiler notices that step > 0 or undefined and the
final result is.

int main(void)
{
    while (1)
        ;

    return 0;
}

Martin Shobe

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

#2785

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

> Michael Press <rubrum@pacbell.net> writes:
>> In article <ioqcbo$irj$1@dont-email.me>,
>>  James Kuyper <jameskuyper@verizon.net> wrote:
>>> On 04/21/2011 04:54 PM, Michael Press wrote:
>>> > In article <iop0dp$ivo$1@dont-email.me>,
>>> >  James Kuyper <jameskuyper@verizon.net> wrote:
>>> > 
>>> >> On 04/21/2011 12:45 AM, Michael Press wrote:
>>> >>> In article <iomoa5$vfr$1@dont-email.me>,
>>> ...
>>> >>> $ cat try.c
>>> >>> #include <stdio.h>
>>> >>>
>>> >>> int
>>> >>> main(void)
>>> >>> {
>>> >>>     int             x;
>>> >>>     int             y;
>>> >>>     int             step;
>>> >>>
>>> >>>     x = step = 1;
>>> >>>     for (; step != 0;)
>>> >>>     {
>>> >>>         if ((y = x + step) > x)
>>> >>>         {
>>> >>>             x = y;
>>> >>>             if ((y = 2 * step) > step)
>>> >>>             step = y;
>>> >>>         }
>>> >>>         else
>>> >>>         {
>>> >>>             step /= 2;
>>> >>>         }
>>> >>>     }
>>> >>>     printf("Maximum int = %d = %#x.\n", x, x);
>>> >>>     return 0;
>>> >>> }
>>> >>
>>> >> That's one example of precisely what I was talking about. As soon as x >
>>> >> INT_MAX - step, the expression x+step has undefined behavior; as soon as
>>> >> step > INT_MAX/2, the expression 2*step has undefined behavior. The
>>> >> above code seems to rely upon the unportable assumption that the actual
>>> >> behavior in each of those cases will be to produce a result that is
>>> >> negative. That's very common behavior, but it's not guaranteed by the
>>> >> standard. That's what I meant by "serious portability issues".
>>> > 
>>> > Does not assume it goes negative.
>>> 
>>> By assuming that adding two positive ints, or multiplying a positive int
>>> by 2, will produce a negative result when the operation overflows
>>
>> No, it does not.
>
> It certainly makes *some* assumption(s) not guaranteed by the standard.
>
> Specifically, it appears to assume that, where step is a positive
> int value, evaluating (x + step) will yield a value less than x if
> and only if the mathematical result of (x + step) exceeds INT_MAX.

s/less than/less then or equal to/.  It would be a nit-pick except that
I think the possibility of integer overflow latching on INT_MAX was
consciously included to reduce the assumptions being made.

<snip>
-- 
Ben.

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

#2685

"Thomas Scrace" <tom@scrace.org> wrote in message 
news:alpine.LFD.2.02.1104201414030.21950@bowman...
> Hi all,
>
> In K&R there is an exercise to compute the range of possible values for 
> each C type. In doing this I have written two functions that are 
> identical, except for the fact that one uses signed long ints, and the 
> other uses unsigned long ints. I have found that the function that uses 
> the unsigned ints completes in a few seconds, while the signed version 
> takes so long that I have never had the patience to wait for it to end. 
> The only operators I am using on the variables are increment and 
> decrement.

There is some sort of comparison operator in there, one would assume.  If 
not, how did your code know it went through the entire range?

>
> Is there a difference in performance between these types? Is this 
> restricted to long ints, or is there a general difference between all 
> signed/non-signed C types? Could this be something compiler or processor 
> specific?

Questions about performance are *always* 
compiler/processor/phase-of-the-moon specific.

On the other hand, on most platforms, signed longs and unsigned longs 
generally perform fairly similarly.  My guess (given that I haven't seen 
your code) is that your code had a bug in it which caused it to infinite 
loop on a signed type, but not an unsigned type.

> I am using GCC on the x86 platform (intel core i5).
>
> Thanks,
>
> Tom
>
>
> -- 
> Thomas Scrace <tom@scrace.org> 

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

#2687

On Wed, 20 Apr 2011, Scott Fluhrer wrote:

>
> "Thomas Scrace" <tom@scrace.org> wrote in message
> news:alpine.LFD.2.02.1104201414030.21950@bowman...
>
> There is some sort of comparison operator in there, one would assume.  If
> not, how did your code know it went through the entire range?

Yes, sorry. I do use >/< operators.

The code is as follows:

signed long slmax()
{
         signed long s;
         signed long temp;
         for (s = 0, temp = -1; s > temp; ++s, ++temp) {
                 ;
         }
         return temp;
}

It's the same for all the other types, the only difference is the types.

As you can see (and as I now see) in the case of an signed long it will cycle 
around and around infinitely. For the unsigned long this was of course not a 
problem. For signed shorts and signed ints it was not a problem because I could 
use a larger type (long) for the temp variable.

I did not realise that signed types behaved this way.

Thomas Scrace <tom@scrace.org>

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

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

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

csiph-web