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

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

C23 (C2x) changes

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

Contents

  C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-20 10:54 +0430
    Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 09:35 +0200
      Re: C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-21 11:01 +0430
    Re: C23 (C2x) changes John Bode <jfbode1029@gmail.com> - 2021-09-20 10:41 -0500
      Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 18:17 +0200
        Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 18:55 +0100
          Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-20 18:21 +0000
          Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 21:39 +0200
            Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 21:07 +0100
              Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 22:59 +0200
                Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 22:29 +0100
                  Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-20 17:43 -0700
                  Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-21 17:56 +0200
                    Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-21 18:05 +0100
                      Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-21 11:42 -0700
                      Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-22 11:37 +0200
                        Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 11:55 +0100
                          Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-22 14:21 +0200
                            Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 13:58 +0100
                    Re: C23 (C2x) changes Ian Pilcher <arequipeno@gmail.com> - 2021-09-22 12:02 -0500
                      Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-22 17:19 +0000
            Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 23:05 +0100
              Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-20 22:47 +0000
                Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-09-20 22:58 +0000
                Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 07:16 -0700
                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 15:15 +0000
              Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-20 17:45 -0700
          Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-09-27 17:15 +0200
            Re: C23 (C2x) changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-27 17:38 +0100
              Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-09-27 23:18 +0200
                Re: C23 (C2x) changes antispam@math.uni.wroc.pl - 2021-09-28 13:53 +0000
                Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 08:07 -0700
                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 15:18 +0000
                    Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-02 15:04 -0700
                      Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 01:58 +0000
                        Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-02 22:06 -0700
                          Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 10:43 +0000
                            Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 13:30 -0700
                              Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 05:04 +0000
                                Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 23:24 -0700
                                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 06:54 +0000
                                Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-04 09:58 +0200
                                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 15:52 +0000
                                    Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-04 10:45 -0700
                                      Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 20:30 +0000
                                      Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 03:57 -0700
                                        Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 12:27 +0000
            Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-29 03:38 +0000
        Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 11:35 +0100
          Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-10-15 18:27 +0000
            Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 20:08 +0100
            Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-10-15 19:20 +0000
              Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 21:50 +0100
      Re: C23 (C2x) changes Florian Weimer <fw@deneb.enyo.de> - 2021-10-03 09:43 +0200
        Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-03 18:53 +0200
        Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 13:55 -0700
    Re: C23 (C2x) changes William Ahern <william@25thandClement.com> - 2021-09-21 22:57 -0700
      Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 08:55 -0700
        Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 16:36 +0000
    Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-09-22 20:27 +0200
      Re: C23 (C2x) changes Philipp Klaus Krause <pkk@spth.de> - 2021-09-22 22:25 +0200
        Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-22 14:05 -0700
          Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 23:24 +0100
            Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-22 18:49 -0700
          Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-09-23 18:47 +0200
    Static bounds checking (was Re: C23 (C2x) changes) William Ahern <william@25thandClement.com> - 2021-09-23 21:11 -0700
      Re: Static bounds checking (was Re: C23 (C2x) changes) David Brown <david.brown@hesbynett.no> - 2021-09-24 08:51 +0200
        Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 09:30 +0200
      Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 07:52 +0000
        Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 12:32 +0200
          Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 10:49 +0000
            Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 14:46 +0200
        Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-24 18:14 +0200
          Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 01:00 +0000
            Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-25 07:44 +0200
              Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 11:28 +0000
              Re: Static bounds checking (was Re: C23 (C2x) changes) antispam@math.uni.wroc.pl - 2021-09-28 10:56 +0000
            Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 09:48 +0200
              Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 11:30 +0000
                Re: Static bounds checking (was Re: C23 (C2x) changes) Kaz Kylheku <480-992-1380@kylheku.com> - 2021-09-25 20:49 +0000
                  Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-26 00:04 +0000
                Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-26 06:56 +0200
    Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 10:15 -0700
      Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-27 11:15 -0700
        Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-27 22:11 +0200
        Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 14:20 -0700
          Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 14:31 -0700
        Re: C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-28 10:43 +0330
    Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 04:01 -0700
      Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-06 04:42 -0700
        Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 04:04 -0700
          Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-29 16:34 +0200
      Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-06 19:07 +0200
        Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-07 11:06 +0200
          Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-07 19:31 +0200
            Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-07 22:14 +0200
              Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 06:18 -0700
                Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 06:21 -0700
        Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 04:01 -0700
      Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-15 12:59 +0200
        Re: C23 (C2x) changes Jim Jackson <jj@franjam.org.uk> - 2021-10-15 16:50 +0000
          Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-16 07:51 +0200
            Re: C23 (C2x) changes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-16 11:50 -0700
              Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-16 21:28 +0200
                Re: C23 (C2x) changes Jim Jackson <jj@franjam.org.uk> - 2021-10-17 17:18 +0000
                  Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 20:00 +0200
                    Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-17 19:17 +0100
                      Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-18 06:49 +0200
                        Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-18 11:23 +0100
                          Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-18 14:09 +0200
                    Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:07 +0000
                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:02 +0000
            Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-16 21:28 +0200
              Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 06:04 +0200
                Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-10-17 19:35 +0200
                  Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 20:01 +0200
                    Re: C23 (C2x) changes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-17 14:15 -0700
                Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:02 +0000
                  Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-21 13:15 +0200

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

#162819

Ian Pilcher <arequipeno@gmail.com> writes:
>On 9/21/21 10:56, David Brown wrote:
>> What do you see as the practical uses of having wrapping in signed
>> integers?
>
>I haven't seen this mentioned, so ... after the fact overflow detection
>seems like a nice thing that we can't currently have.

     ADD ORDER-QUANTITY TO CUSTOMER-TOTAL-ORDERS ON OVERFLOW PERFORM HANDLE-QTY-OVERFLOW.

Sometimes the task defines the choice of language.

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

#162782

On 20/09/2021 20:39, David Brown wrote:
> On 20/09/2021 19:55, Bart wrote:
>> On 20/09/2021 17:17, David Brown wrote:

>>> For those that think it makes sense to have a pile of 2147483647 apples,
>>> add another apple to the pile, and end up with -2147483648 apples, gcc
>>> still has the "-fwrapv" option.
>>
>> Of course it makes perfect sense to have a pile of 4294967295 apples,
>> add another apple to the pile, and suddenly end up with 0 apples!
> 
> I don't think it does make sense - although it is a good deal less silly
> than wrapping signed integers.  Unsigned types in C model modulo
> arithmetic precisely - signed types model integer arithmetic with size
> limitations.  In integer arithmetic, and in C signed arithmetic, you
> can't add two positive numbers and get a negative number.  That seems
> pretty obvious and sensible to me.
> 
>>
>> Meanwhile, someone could remove that extra apple from the pile of
>> -2147483648, to restore the original 2147483647, however that's too
>> late: the overflow police have already been, and will do so again even
>> when it becomes legal.
>>
> 
> "Someone could remove an apple from a pile of -2147483648 apples" ?  Do
> you not see how nonsensical that is?

Try this program, where the number of applies is represented with an 
8-bit value:

     int8_t apples;

     apples = 127;
     printf("Initial pile of apples: %d\n",apples);
     apples += 1;
     printf("After adding one more apple: %d\n",apples);
     apples -= 1;
     printf("After removing an apple: %d\n",apples);

The number of apples goes from 127 to -128, and back to 127, just like 
my example using 32 bits.

Yet, this is not NOT undefined behaviour, and is suddenly sensible in 
the eyes of C?

Same with 16 bits. And same with 32 bits IF C had adopted a 64-bit int.

All I see is inconsistency if you say one is UB but not another.

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

#162784

Bart <bc@freeuk.com> writes:
>On 20/09/2021 20:39, David Brown wrote:
>> On 20/09/2021 19:55, Bart wrote:
>>> On 20/09/2021 17:17, David Brown wrote:
>
>>>> For those that think it makes sense to have a pile of 2147483647 apples,
>>>> add another apple to the pile, and end up with -2147483648 apples, gcc
>>>> still has the "-fwrapv" option.
>>>
>>> Of course it makes perfect sense to have a pile of 4294967295 apples,
>>> add another apple to the pile, and suddenly end up with 0 apples!
>> 
>> I don't think it does make sense - although it is a good deal less silly
>> than wrapping signed integers.  Unsigned types in C model modulo
>> arithmetic precisely - signed types model integer arithmetic with size
>> limitations.  In integer arithmetic, and in C signed arithmetic, you
>> can't add two positive numbers and get a negative number.  That seems
>> pretty obvious and sensible to me.
>> 
>>>
>>> Meanwhile, someone could remove that extra apple from the pile of
>>> -2147483648, to restore the original 2147483647, however that's too
>>> late: the overflow police have already been, and will do so again even
>>> when it becomes legal.
>>>
>> 
>> "Someone could remove an apple from a pile of -2147483648 apples" ?  Do
>> you not see how nonsensical that is?
>
>Try this program, where the number of applies is represented with an 
>8-bit value:
>
>     int8_t apples;
>
>     apples = 127;
>     printf("Initial pile of apples: %d\n",apples);
      if (apples < CHAR_MAX) {
>         apples += 1;
      } else {
          panic("Logic error by the unqualified C programmer\n");
      }

fixed it for you.

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

#162785

On Mon, 20 Sep 2021 22:47:23 +0000, Scott Lurndal wrote:

> Bart <bc@freeuk.com> writes:
[snip]
>>Try this program, where the number of applies is represented with an 
>>8-bit value:
>>
>>     int8_t apples;
>>
>>     apples = 127;
>>     printf("Initial pile of apples: %d\n",apples);
>       if (apples < CHAR_MAX) {
>>         apples += 1;
>       } else {
>           panic("Logic error by the unqualified C programmer\n");
>       }
> 
> fixed it for you.

Oh, snap!

-- 
Lew Pitcher
"In Skills, We Trust"

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

#162936

scott@slp53.sl.home (Scott Lurndal) writes:

> Bart <bc@freeuk.com> writes:
>
>> [...]
>>
>> Try this program, where the number of applies is represented with
>> an 8-bit value:
>>
>>     int8_t apples;
>>
>>     apples = 127;
>>     printf("Initial pile of apples: %d\n",apples);
>
>       if (apples < CHAR_MAX) {
>
>>         apples += 1;
>
>       } else {
>           panic("Logic error by the unqualified C programmer\n");
>       }
>
> fixed it for you.

    if (apples < SCHAR_MAX) {

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

#162939

On 2021-10-02, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> [...]
>>>
>>> Try this program, where the number of applies is represented with
>>> an 8-bit value:
>>>
>>>     int8_t apples;
>>>
>>>     apples = 127;
>>>     printf("Initial pile of apples: %d\n",apples);
>>
>>       if (apples < CHAR_MAX) {
>>
>>>         apples += 1;
>>
>>       } else {
>>           panic("Logic error by the unqualified C programmer\n");
>>       }
>>
>> fixed it for you.
>
>     if (apples < SCHAR_MAX) {
>
if (apples < sizeof(char)*CHAR_MAX) /** :P */

-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

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

#162787

Bart <bc@freeuk.com> writes:
[...]
> All I see is inconsistency if you say one is UB but not another.

That's all you want to see.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#162845

On 9/20/2021 7:55 PM, Bart wrote:
> On 20/09/2021 17:17, David Brown wrote:
>> On 20/09/2021 17:41, John Bode wrote:
> 
>>> If signed integer representations other than two's complement will
>>> no longer be supported, does this mean signed integer overflow can
>>> have a well-defined behavior?  Or will it still be left undefined
>>> to allow for optimizations?  Or could that be controlled with one
>>> of these newfangled attribute thingies?
>>
>>
>> No, signed integer overflow is still undefined behaviour - for which I
>> am very glad.  Defining it is terrible, IMHO, since any definition you
>> give will be the wrong answer.  Some would want it defined as wrapping
>> ($DEITY knows why, since it is the silliest of all definitions despite
>> being fairly efficient to implement), some would want it as an error or
>> a trap, some would want saturation, some would want a NaN, some would
>> want errno to be set.
>>
>> For those that think it makes sense to have a pile of 2147483647 apples,
>> add another apple to the pile, and end up with -2147483648 apples, gcc
>> still has the "-fwrapv" option.
> 
> Of course it makes perfect sense to have a pile of 4294967295 apples, 
> add another apple to the pile, and suddenly end up with 0 apples!
> 
> Meanwhile, someone could remove that extra apple from the pile of 
> -2147483648, to restore the original 2147483647, however that's too 
> late: the overflow police have already been, and will do so again even 
> when it becomes legal.
> 

It's all about modeling a problem domain.
In mathematics, /integer/ arithmetic (the one you use a.o. to add and 
subtract things) is /signed/ (for any serious work, at least).
The tool that C offers to model this domain is signed integers - with 
the unavoidable limitations of limited size.

Unsigned integers are the tool that C offers for /binary/ arithmetic. In 
this context wrapping is one of the features that makes them useful.

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

#162846

Manfred <noname@add.invalid> writes:

> On 9/20/2021 7:55 PM, Bart wrote:

>> Of course it makes perfect sense to have a pile of 4294967295 apples,
>> add another apple to the pile, and suddenly end up with 0 apples!
>> Meanwhile, someone could remove that extra apple from the pile of
>> -2147483648, to restore the original 2147483647, however that's too
>> late: the overflow police have already been, and will do so again
>> even when it becomes legal.
>> 
>
> It's all about modeling a problem domain.
> In mathematics, /integer/ arithmetic (the one you use a.o. to add and
> subtract things) is /signed/ (for any serious work, at least).  The
> tool that C offers to model this domain is signed integers - with the
> unavoidable limitations of limited size.
>
> Unsigned integers are the tool that C offers for /binary/
> arithmetic. In this context wrapping is one of the features that makes
> them useful.

Some mathematics concerns the natural numbers.  Unsigned integer types
would be an entirely natural (no pun intended) choice for these cases.

-- 
Ben.

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

#162852

On 9/27/2021 6:38 PM, Ben Bacarisse wrote:
> Manfred <noname@add.invalid> writes:
> 
>> On 9/20/2021 7:55 PM, Bart wrote:
> 
>>> Of course it makes perfect sense to have a pile of 4294967295 apples,
>>> add another apple to the pile, and suddenly end up with 0 apples!
>>> Meanwhile, someone could remove that extra apple from the pile of
>>> -2147483648, to restore the original 2147483647, however that's too
>>> late: the overflow police have already been, and will do so again
>>> even when it becomes legal.
>>>
>>
>> It's all about modeling a problem domain.
>> In mathematics, /integer/ arithmetic (the one you use a.o. to add and
>> subtract things) is /signed/ (for any serious work, at least).  The
>> tool that C offers to model this domain is signed integers - with the
>> unavoidable limitations of limited size.
>>
>> Unsigned integers are the tool that C offers for /binary/
>> arithmetic. In this context wrapping is one of the features that makes
>> them useful.
> 
> Some mathematics concerns the natural numbers.  Unsigned integer types
> would be an entirely natural (no pun intended) choice for these cases.
> 

True, and in fact, while writing the post natural numbers came to mind 
as well; for example, in a simple counter unsigned int makes perfect sense.

However, I was following up at Bart's post about what's the point of 
adding an apple to a pile of 4294967295 apples and end up with nothing, 
which is understandably disappointing, since stocking up that pile of 
apples probably took a considerable amount of work...

A couple of considerations:
- How common is the need to model math that is strictly about natural 
numbers compared to the need for integer math? (this is not a rhetorical 
question, I'm genuinely curious).
It could also be argued that after all natural numbers can be handled 
using signed integers, as long as in the transition from theoretical 
analysis to practical analysis, the limitation of (2^31-1) is not that 
different from the limitation of (2^32-1)

- more relevant, IMO: the main difference between signed and unsigned 
types is that in the latter case all bits are digits, i.e. they 
constitute a homogeneous set, which makes them specifically useful for 
binary arithmetic (which justifies the difference in semantics, in my view).

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

#162857

Manfred <noname@add.invalid> wrote:
> On 9/27/2021 6:38 PM, Ben Bacarisse wrote:
> > Manfred <noname@add.invalid> writes:
> > 
> >> On 9/20/2021 7:55 PM, Bart wrote:
> > 
> >>> Of course it makes perfect sense to have a pile of 4294967295 apples,
> >>> add another apple to the pile, and suddenly end up with 0 apples!
> >>> Meanwhile, someone could remove that extra apple from the pile of
> >>> -2147483648, to restore the original 2147483647, however that's too
> >>> late: the overflow police have already been, and will do so again
> >>> even when it becomes legal.
> >>>
> >>
> >> It's all about modeling a problem domain.
> >> In mathematics, /integer/ arithmetic (the one you use a.o. to add and
> >> subtract things) is /signed/ (for any serious work, at least).  The
> >> tool that C offers to model this domain is signed integers - with the
> >> unavoidable limitations of limited size.
> >>
> >> Unsigned integers are the tool that C offers for /binary/
> >> arithmetic. In this context wrapping is one of the features that makes
> >> them useful.
> > 
> > Some mathematics concerns the natural numbers.  Unsigned integer types
> > would be an entirely natural (no pun intended) choice for these cases.
> > 
> 
> True, and in fact, while writing the post natural numbers came to mind 
> as well; for example, in a simple counter unsigned int makes perfect sense.
> 
> However, I was following up at Bart's post about what's the point of 
> adding an apple to a pile of 4294967295 apples and end up with nothing, 
> which is understandably disappointing, since stocking up that pile of 
> apples probably took a considerable amount of work...
> 
> A couple of considerations:
> - How common is the need to model math that is strictly about natural 
> numbers compared to the need for integer math? (this is not a rhetorical 
> question, I'm genuinely curious).

AFAICS typically in theoretical setting one considers integers
with possibly added assertion that they are nonnegative.  But
there may be also assertion that numbers are bigger than 0,
or bigger than 1.  And there are other popular assertions.
So IMHO need to specifically model nonnegative integers is
limited.

> It could also be argued that after all natural numbers can be handled 
> using signed integers, as long as in the transition from theoretical 
> analysis to practical analysis, the limitation of (2^31-1) is not that 
> different from the limitation of (2^32-1)
> 
> - more relevant, IMO: the main difference between signed and unsigned 
> types is that in the latter case all bits are digits, i.e. they 
> constitute a homogeneous set, which makes them specifically useful for 
> binary arithmetic (which justifies the difference in semantics, in my view).

Actually, signed numbers works very well in base 3 (or other odd
bases).  Difference compared to unsigned is that for signed numbers
it is natural to use signed digits.  Signed digits means that
re-interpering string of digits as unsigend number changes value
in less regular way, so in new C3 (ternary C) language one
would have to decide if cast work by re-interpeting digist or
tries to preseve value.

-- 
                              Waldek Hebisch

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

#162938

Manfred <noname@add.invalid> writes:

> [...]

> - How common is the need to model math that is strictly about
> natural numbers compared to the need for integer math?  (this is
> not a rhetorical question, I'm genuinely curious).

Combinatorics and number theory routinely concern themselves with
domains limited to the non-negative integers.  The celebrated
prime number theorem, for example, counts primes less than a
given upper bound, but considers only non-negative numbers as
primes.  Is -3 a prime?  In a sense yes, but it's easier just to
avoid the question by admitting only non-negative integers as
candidates.

> It could also be argued that after all natural numbers can be
> handled using signed integers, as long as in the transition from
> theoretical analysis to practical analysis, the limitation of
> (2^31-1) is not that different from the limitation of (2^32-1)

Considering practical aspects of writing code, if the domain of
interest is confined to non-negative values, using an unsigned
type (for function parameters, etc) makes for an easier fit, as
otherwise input values would have to be tested for being negative,
and something done to handle the offending situation.  If unsigned
types are used the problem doesn't come up.

Also, when working in code related to those theoretical domains,
I can say from first hand experience that we _always_ want that
last bit, no matter how wide the data type in question.  An extra
bit means a larger range of applicability, and that's always
useful.

> - more relevant, IMO: the main difference between signed and
> unsigned types is that in the latter case all bits are digits,
> i.e. they constitute a homogeneous set, which makes them
> specifically useful for binary arithmetic (which justifies the
> difference in semantics, in my view).

Speaking for myself a more important difference is that signed
types have various pesky undefined and implementation-defined
behaviors, whereas unsigned types do not.  In most cases it's
easier to reason about code that uses unsigned types if the range
of possible values is even remotely close to the limits of the
type in question.  I routinely use unsigned types for variables
unless the variable in question must be able to hold a negative
value.

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

#162940

On 2021-10-02, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Manfred <noname@add.invalid> writes:
>
>> [...]
>
>> - How common is the need to model math that is strictly about
>> natural numbers compared to the need for integer math?  (this is
>> not a rhetorical question, I'm genuinely curious).
>
> Combinatorics and number theory routinely concern themselves with
> domains limited to the non-negative integers.  The celebrated
> prime number theorem, for example, counts primes less than a
> given upper bound, but considers only non-negative numbers as
> primes.  Is -3 a prime?

Please take a look at this video carefully:
https://youtu.be/094y1Z2wpJg




-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

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

#162947

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-02, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Manfred <noname@add.invalid> writes:
>>
>>> [...]
>>
>>> - How common is the need to model math that is strictly about
>>> natural numbers compared to the need for integer math?  (this is
>>> not a rhetorical question, I'm genuinely curious).
>>
>> Combinatorics and number theory routinely concern themselves with
>> domains limited to the non-negative integers.  The celebrated
>> prime number theorem, for example, counts primes less than a
>> given upper bound, but considers only non-negative numbers as
>> primes.  Is -3 a prime?
>
> Please take a look at this video carefully:
> https://youtu.be/094y1Z2wpJg

Why?

(It's about the Collatz Conjecture, and it's more than 20 minutes long.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#162954

On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>> On 2021-10-02, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> Manfred <noname@add.invalid> writes:
>>>
>>>> [...]
>>>
>>>> - How common is the need to model math that is strictly about
>>>> natural numbers compared to the need for integer math?  (this is
>>>> not a rhetorical question, I'm genuinely curious).
>>>
>>> Combinatorics and number theory routinely concern themselves with
>>> domains limited to the non-negative integers.  The celebrated
>>> prime number theorem, for example, counts primes less than a
>>> given upper bound, but considers only non-negative numbers as
>>> primes.  Is -3 a prime?
>>
>> Please take a look at this video carefully:
>> https://youtu.be/094y1Z2wpJg
>
> Why?
>
> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>
So do you have *explanation*?
Why do you ask about negative primes?

-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

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

#162957

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
[...]
>>> Please take a look at this video carefully:
>>> https://youtu.be/094y1Z2wpJg
>>
>> Why?
>>
>> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>>
> So do you have *explanation*?

For what?

> Why do you ask about negative primes?

I didn't.

Is there anything in the video that's relevant either to this newsgroup
or to this thread?  If so, what?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#162959

On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>> On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> [...]
>>>> Please take a look at this video carefully:
>>>> https://youtu.be/094y1Z2wpJg
>>>
>>> Why?
>>>
>>> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>>>
>> So do you have *explanation*?
>
> For what?
>
>> Why do you ask about negative primes?
>
> I didn't.
>
> Is there anything in the video that's relevant either to this newsgroup
> or to this thread?  If so, what?
>
Sorry, that was Ttim Rensch i replied, you just replied
on something wasn't you asked for :P

-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

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

#162968

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>> On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>> [...]
>>>>> Please take a look at this video carefully:
>>>>> https://youtu.be/094y1Z2wpJg
>>>>
>>>> Why?
>>>>
>>>> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>>>>
>>> So do you have *explanation*?
>>
>> For what?
>>
>>> Why do you ask about negative primes?
>>
>> I didn't.
>>
>> Is there anything in the video that's relevant either to this newsgroup
>> or to this thread?  If so, what?
>>
> Sorry, that was Ttim Rensch i replied, you just replied
> on something wasn't you asked for :P

So you posted a link to a 20-minute video with no explanation, and
you're still unwilling to explain how or whether it's relevant.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#162972

On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>> On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>> On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>> [...]
>>>>>> Please take a look at this video carefully:
>>>>>> https://youtu.be/094y1Z2wpJg
>>>>>
>>>>> Why?
>>>>>
>>>>> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>>>>>
>>>> So do you have *explanation*?
>>>
>>> For what?
>>>
>>>> Why do you ask about negative primes?
>>>
>>> I didn't.
>>>
>>> Is there anything in the video that's relevant either to this newsgroup
>>> or to this thread?  If so, what?
>>>
>> Sorry, that was Ttim Rensch i replied, you just replied
>> on something wasn't you asked for :P
>
> So you posted a link to a 20-minute video with no explanation, and
> you're still unwilling to explain how or whether it's relevant.
>
It shows two things: math is connected to reality,
and second, explains why strong AI is impossible :P

-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

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

#162973

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>> On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>>> On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>> [...]
>>>>>>> Please take a look at this video carefully:
>>>>>>> https://youtu.be/094y1Z2wpJg
>>>>>>
>>>>>> Why?
>>>>>>
>>>>>> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>>>>>>
>>>>> So do you have *explanation*?
>>>>
>>>> For what?
>>>>
>>>>> Why do you ask about negative primes?
>>>>
>>>> I didn't.
>>>>
>>>> Is there anything in the video that's relevant either to this newsgroup
>>>> or to this thread?  If so, what?
>>>>
>>> Sorry, that was Ttim Rensch i replied, you just replied
>>> on something wasn't you asked for :P
>>
>> So you posted a link to a 20-minute video with no explanation, and
>> you're still unwilling to explain how or whether it's relevant.
>>
> It shows two things: math is connected to reality,
> and second, explains why strong AI is impossible :P

So it's not relevant to this thread or to this newsgroup.

This newsgroup discusses the C programming language.  If you want to
discuss something unrelated to that, please find another place to do so.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

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

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

csiph-web