Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69548 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2019-11-04 20:48 +0100 |
| Last post | 2020-02-26 02:22 +0000 |
| Articles | 20 on this page of 219 — 25 participants |
Back to article view | Back to comp.lang.c++
two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-04 20:48 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-04 21:19 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-04 14:39 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 10:31 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 11:23 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 15:43 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 16:58 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-05 21:45 +0200
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 13:33 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 13:51 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 14:37 +0100
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 15:38 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 15:53 +0100
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-06 10:06 -0500
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-06 17:00 +0100
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 17:47 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 17:54 +0100
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2019-11-06 20:00 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 20:13 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 20:44 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 20:36 +0100
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 22:54 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-07 00:52 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-06 17:54 +0200
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 18:15 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 18:33 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-06 10:55 -0800
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 20:15 +0100
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 20:53 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-06 22:25 +0200
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 23:05 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-07 10:23 +0200
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 22:20 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-06 22:12 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-09 06:24 -0800
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2019-11-09 07:14 -0700
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-10 11:52 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-10 16:31 +0200
Re: two's complement idea Manfred <noname@invalid.add> - 2019-11-10 19:02 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-11 12:08 +0200
Re: two's complement idea scott@slp53.sl.home (Scott Lurndal) - 2019-11-11 13:59 +0000
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-11 17:09 +0200
Re: two's complement idea Richard Damon <Richard@Damon-Family.org> - 2019-11-18 07:40 -0500
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:27 -0800
Re: two's complement idea cdalten@gmail.com - 2020-01-24 05:39 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 17:53 +0200
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 17:31 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 21:48 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 07:08 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 09:30 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 09:57 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-05 09:02 -0800
Re: two's complement idea scott@slp53.sl.home (Scott Lurndal) - 2019-11-05 17:15 +0000
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-05 10:19 -0800
Re: two's complement idea Manfred <noname@invalid.add> - 2019-11-05 19:31 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-05 11:55 -0800
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-05 22:48 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-05 15:49 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-09 06:13 -0800
Re: two's complement idea Manfred <noname@invalid.add> - 2019-11-10 18:37 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 23:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 23:00 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-06 05:26 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 21:50 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-08 02:01 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-08 14:03 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-08 12:08 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-10 13:17 +0100
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-10 14:37 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-10 17:08 +0100
Re: two's complement idea Manfred <noname@invalid.add> - 2019-11-10 18:34 +0100
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2019-11-11 07:48 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-10 21:31 +0100
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2019-11-04 23:55 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 10:32 +0100
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2019-11-04 19:55 -0700
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-05 05:52 +0100
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2019-11-05 18:17 +1300
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-09 05:55 -0800
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2019-11-09 06:33 -0700
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-09 07:46 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-09 06:46 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:19 -0800
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-29 00:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-29 09:15 +0100
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2019-11-29 10:58 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-29 12:49 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-12-07 07:53 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-12-07 08:22 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 20:44 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-10 23:44 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:08 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-14 08:42 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 02:09 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 05:14 -0800
Re: two's complement idea Daniel <danielaparker@gmail.com> - 2020-01-21 13:08 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-22 00:07 -0500
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-21 23:21 -0800
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-22 01:51 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-22 11:28 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 11:52 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-22 04:47 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:19 -0700
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:07 -0700
Re: two's complement idea boltar@nowhere.org - 2020-01-21 16:44 +0000
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-21 20:01 +0000
Re: two's complement idea boltar@nowhere.org - 2020-01-22 11:26 +0000
Re: two's complement idea Christian Gollwitzer <auriocus@gmx.de> - 2020-01-22 20:04 +0100
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-22 11:30 -0800
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-22 19:57 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-23 10:03 +1300
Re: two's complement idea boltar@nowhere.org - 2020-01-23 09:24 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-24 07:29 +1300
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-23 10:03 +1300
Re: two's complement idea "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2020-01-23 10:09 +0100
Re: two's complement idea boltar@nowhere.org - 2020-01-23 09:29 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 01:08 +0000
Re: two's complement idea boltar@nowhere.org - 2020-01-24 12:27 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 01:06 +0000
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2020-01-24 10:07 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 11:36 +0200
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-24 17:34 -0800
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2020-01-24 17:57 -0800
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 12:19 +0000
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2020-01-24 14:19 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 14:11 +0000
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 17:26 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 17:35 +0000
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 22:27 +0200
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-24 23:21 -0500
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-25 11:06 +1300
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 22:12 +0000
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-24 23:24 -0500
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-25 09:04 +0000
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-25 04:15 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 19:55 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 00:05 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 01:19 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-25 19:50 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 11:57 +0000
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-25 13:42 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 14:58 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 07:58 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:34 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-25 12:41 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-26 16:08 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 02:20 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-27 15:03 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-15 06:44 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-03-06 10:18 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:05 -0700
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-04-02 20:03 +0300
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 12:37 -0700
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 07:45 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 19:56 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 09:49 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 21:33 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 11:00 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 22:23 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 11:46 +1300
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-26 10:55 +0200
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-26 03:47 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:28 -0800
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-25 22:22 +0000
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-25 18:24 -0500
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 12:54 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 12:44 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 14:58 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 14:53 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 19:10 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 13:20 -0600
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 20:51 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 21:02 -0600
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-26 19:06 -0800
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-27 18:50 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 14:18 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-27 22:13 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-27 21:38 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 19:37 -0600
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-27 19:15 -0800
Re: two's complement idea "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2020-01-28 11:45 +0100
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-27 16:31 +1300
Re: two's complement idea Manfred <noname@add.invalid> - 2020-01-26 18:50 +0100
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-26 18:57 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 20:46 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 13:14 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 22:15 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 21:06 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-28 13:08 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:50 -0800
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-27 08:21 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:12 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 07:48 -0800
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-18 18:46 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 17:03 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 06:56 +0100
Re: two's complement idea Christian Gollwitzer <auriocus@gmx.de> - 2019-11-05 08:24 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 08:35 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-04 23:36 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-05 09:19 -0500
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 08:32 +0100
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-01-22 09:23 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 14:20 +0100
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-22 13:37 +0000
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:17 -0800
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-01-27 12:35 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-15 05:56 -0800
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-02-16 09:17 +0100
Re: two's complement idea Richard Damon <Richard@Damon-Family.org> - 2020-02-21 19:35 -0500
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-02-22 07:01 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-24 08:22 -0800
Re: two's complement idea cross@spitfire.i.gajendra.net (Dan Cross) - 2020-02-24 03:12 +0000
Re: two's complement idea cdalten@gmail.com - 2020-02-24 05:53 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-25 07:56 -0800
Re: two's complement idea cross@spitfire.i.gajendra.net (Dan Cross) - 2020-02-25 22:00 +0000
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-25 16:14 -0800
Re: two's complement idea cdalten@gmail.com - 2020-02-25 18:18 -0800
Re: two's complement idea cross@spitfire.i.gajendra.net (Dan Cross) - 2020-02-26 02:22 +0000
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-11-11 13:59 +0000 |
| Message-ID | <EOdyF.94235$3u6.16445@fx34.iad> |
| In reply to | #69709 |
Paavo Helde <myfirstname@osa.pri.ee> writes: >On 10.11.2019 20:02, Manfred wrote: >With the specified wrapping behavior for unsigneds the story is >different however. They defined the unsigned overflow as wrapping >because they could, not because of some deeper considerations. Would the >existing hardware have provided some other behavior (like saturating) at >zero cost, I'm sure they would have standardized that behavior instead. You are projecting your preferences. I'm sure they would have made the choice they made even if saturating arithmetic operations had been available.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-11-11 17:09 +0200 |
| Message-ID | <qqbtjl$hjk$1@dont-email.me> |
| In reply to | #69710 |
On 11.11.2019 15:59, Scott Lurndal wrote: > Paavo Helde <myfirstname@osa.pri.ee> writes: >> On 10.11.2019 20:02, Manfred wrote: > >> With the specified wrapping behavior for unsigneds the story is >> different however. They defined the unsigned overflow as wrapping >> because they could, not because of some deeper considerations. Would the >> existing hardware have provided some other behavior (like saturating) at >> zero cost, I'm sure they would have standardized that behavior instead. > > You are projecting your preferences. I'm sure they would have made > the choice they made even if saturating arithmetic operations had been available. I do not have preference for saturating. Saturating is worse than wrapping, as it does not make it possible to detect overflow post factum even in the simplest usage case. Looks like I should have worded myself better: "Would the existing hardware have provided *only* some other behavior (like saturating) at zero cost, ..."
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-11-18 07:40 -0500 |
| Message-ID | <1jwAF.107444$vD7.68182@fx06.iad> |
| In reply to | #69701 |
On 11/10/19 9:31 AM, Paavo Helde wrote: > On 9.11.2019 16:24, Tim Rentsch wrote: >> Paavo Helde <myfirstname@osa.pri.ee> writes: >> >>> On 5.11.2019 17:58, Bonita Montero wrote: >>> >>>> With the same reasoning you could say that unsigneds might never >>>> wrap; but in fact they're specified to wrap. >>> >>> In retrospect, this (wrapping unsigneds) looks like a major design >>> mistake. >>> >>> IMO, wrapping integers (signed or unsigned) are an example of >>> "optimization which nobody asked for", and they are there basically >>> only because the hardware happened to support such operations. >> >> Apparently you think how the hardware behaves (specifically, for >> unsigned or two's complement operands) is some sort of accident >> of history. It isn't. It was a deliberate choice, made by smart >> people. It isn't just a coincidence that the semantics of >> wrapping works nicely in a variety of applications. > > The hardware which I am familiar with properly sets the carry and > overflow flags for arithmetic operations. In case of multiplication it > also produces the result twice larger than the operands, in order to not > lose information. So at the hardware level the results are always > well-defined and complete, this is very fine. The calling program can > study the flags and decide what to do about this. > > The problem with C is that they decided the best way to deal with this > is just to ignore the overflow flag and the upper half of the > multiplication result. Not sure about PDP-11 itself, but they had to > think about other hardware too, and at some point they decided that the > best way to deal with the problem was just to ignore all the extra > information the current or future CPU-s might provide. > > An imaginary conversation: > > A: BTW, what should we do with the arithmetic overflow? There are > overflow flags and extended precision results in some hardware that we > could use. > > B: Because of speed and simplicity, we just ignore it. Each extra opcode > would slow us down! > > A: But in case of multiplication, we might lose half of the result! > > B. Just ignore it. > > A. But what we write down in the specs? We can't just say we carry out > an hardware operation and then ignore everything except the first result > register. > > B. Let's see... Isn't there a nice name for that behavior? Yep, it's > called wrapping! Write this down in the specs! > > A. But, but, with signed integers, there are different representations, > so that on some hardware it does not actually wrap! > > B. Ouch, my head is hurting. Just declare it undefined then! > > My guess at that converstation is it would go like: A: BTW, what should we do with the arithmetic overflow? There are overflow flags and extended precision results in some hardware that we could use. B: How does that work on the other machines, can we do this efficiently? C: Not on my machine, we do it differently than that, we do it by xxx. A: My machine can't do it that way! B: Sounds like we can't make it part of the standard, leave it for implementation extensions. A: But in case of multiplication, we might lose half of the result! D: My machine doesn't automatically create a double precision result, that would slow me down a lot. B: Sounds like an extension too. Note, the key in this discussion was focused on defining consistent behavior in the language where the target machines had behavior that could be made easily consistent, and leaving as undefined behavior (or unspecified/implementation defined) that wasn't. These decisions were initially being made in the 70's and 80's, and at that time there were a lot more machines with unique operating modes. Note also, it was EXPECTED that implementations would implement extensions to let a program access special features of the machine to be more efficient on that machine. Special symbols/keywords to get access to things like the carry bit, or double precision multiplication. I remember using a multiply-divide intrinsic that would compute a * b / c where the product was done to double precision (long) and the divide took that to yield a int result.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-11-28 12:27 -0800 |
| Message-ID | <86y2vzagrd.fsf@linuxsc.com> |
| In reply to | #69701 |
Paavo Helde <myfirstname@osa.pri.ee> writes: > On 9.11.2019 16:24, Tim Rentsch wrote: > >> Paavo Helde <myfirstname@osa.pri.ee> writes: >> >>> On 5.11.2019 17:58, Bonita Montero wrote: >>> >>>> With the same reasoning you could say that unsigneds might never >>>> wrap; but in fact they're specified to wrap. >>> >>> In retrospect, this (wrapping unsigneds) looks like a major design mistake. >>> >>> IMO, wrapping integers (signed or unsigned) are an example of >>> "optimization which nobody asked for", and they are there basically >>> only because the hardware happened to support such operations. >> >> Apparently you think how the hardware behaves (specifically, for >> unsigned or two's complement operands) is some sort of accident >> of history. It isn't. It was a deliberate choice, made by smart >> people. It isn't just a coincidence that the semantics of >> wrapping works nicely in a variety of applications. > > The hardware which I am familiar with properly sets the carry and > overflow flags for arithmetic operations. In case of multiplication it > also produces the result twice larger than the operands, in order to > not lose information. So at the hardware level the results are always > well-defined and complete, this is very fine. The calling program can > study the flags and decide what to do about this. > > The problem with C is that they decided the best way to deal with this > is just to ignore the overflow flag and the upper half of the > multiplication result. Not sure about PDP-11 itself, but they had to > think about other hardware too, and at some point they decided that > the best way to deal with the problem was just to ignore all the extra > information the current or future CPU-s might provide. > > An imaginary conversation: > > A: BTW, what should we do with the arithmetic overflow? There are > overflow flags and extended precision results in some hardware that we > could use. > > B: Because of speed and simplicity, we just ignore it. Each extra > opcode would slow us down! > > A: But in case of multiplication, we might lose half of the result! > > B. Just ignore it. > > A. But what we write down in the specs? We can't just say we carry out > an hardware operation and then ignore everything except the first > result register. > > B. Let's see... Isn't there a nice name for that behavior? Yep, it's > called wrapping! Write this down in the specs! > > A. But, but, with signed integers, there are different > representations, so that on some hardware it does not actually wrap! > > B. Ouch, my head is hurting. Just declare it undefined then! I believe your view of the history doesn't match what actually occurred. I don't propose attempting to resolve the matter; I just wanted to be clear that I think I see what you're saying even though I believe some of your premises don't match the historical facts.
[toc] | [prev] | [next] | [standalone]
| From | cdalten@gmail.com |
|---|---|
| Date | 2020-01-24 05:39 -0800 |
| Message-ID | <c7ffd254-da1b-4606-83d5-495537009a2e@googlegroups.com> |
| In reply to | #69575 |
On Tuesday, November 5, 2019 at 11:45:23 AM UTC-8, Paavo Helde wrote: > On 5.11.2019 17:58, Bonita Montero wrote: > > > > With the same reasoning you could say that unsigneds might never > > wrap; but in fact they're specified to wrap. > > In retrospect, this (wrapping unsigneds) looks like a major design mistake. > > IMO, wrapping integers (signed or unsigned) are an example of > "optimization which nobody asked for", and they are there basically only > because the hardware happened to support such operations. And not having this would cause things like TCP/IP to break since parts use this to construct what are known Abelian Groups.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2020-01-24 17:53 +0200 |
| Message-ID | <r0f3to$ik1$1@dont-email.me> |
| In reply to | #71543 |
On 24.01.2020 15:39, cdalten@gmail.com wrote: > On Tuesday, November 5, 2019 at 11:45:23 AM UTC-8, Paavo Helde wrote: >> On 5.11.2019 17:58, Bonita Montero wrote: >>> >>> With the same reasoning you could say that unsigneds might never >>> wrap; but in fact they're specified to wrap. >> >> In retrospect, this (wrapping unsigneds) looks like a major design mistake. >> >> IMO, wrapping integers (signed or unsigned) are an example of >> "optimization which nobody asked for", and they are there basically only >> because the hardware happened to support such operations. > > And not having this would cause things like TCP/IP to break since parts use this to construct what are known Abelian Groups. If you mean the "Internet checksum", then my first google hit says it is 16-bit and uses one's complement addition: "One's complement addition can be implemented by "end-round-carry addition": when a carry bit is produced using conventional (two's complement) addition, the carry is added back in as a 1 value." Does not look to me like the C standard unsigned wrapover behavior.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-01-24 17:31 +0000 |
| Message-ID | <slrnr2maf8.km3.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71545 |
On Fri, 2020-01-24, Paavo Helde wrote: > On 24.01.2020 15:39, cdalten@gmail.com wrote: >> On Tuesday, November 5, 2019 at 11:45:23 AM UTC-8, Paavo Helde wrote: >>> On 5.11.2019 17:58, Bonita Montero wrote: >>>> >>>> With the same reasoning you could say that unsigneds might never >>>> wrap; but in fact they're specified to wrap. >>> >>> In retrospect, this (wrapping unsigneds) looks like a major design mistake. >>> >>> IMO, wrapping integers (signed or unsigned) are an example of >>> "optimization which nobody asked for", and they are there basically only >>> because the hardware happened to support such operations. >> >> And not having this would cause things like TCP/IP to break since >> parts use this to construct what are known Abelian Groups. > > If you mean the "Internet checksum", then my first google hit says it is > 16-bit and uses one's complement addition: > > "One's complement addition can be implemented by "end-round-carry > addition": when a carry bit is produced using conventional (two's > complement) addition, the carry is added back in as a 1 value." > > Does not look to me like the C standard unsigned wrapover behavior. He may be referring to how TCP sequence numbers wrap. Or to something else. Anyway, nothing that would be impossible to do in a parallel universe where C's unsigneds don't wrap. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-05 21:48 +0100 |
| Message-ID | <qpsn60$1i8$1@dont-email.me> |
| In reply to | #69570 |
On 05/11/2019 16:58, Bonita Montero wrote: > >> Optimizing the following away: > >> > >> int i; > >> ... > >> if( i + 1 < i ) > >> ... > >> > >> doesn't make sense. > > > Sure it makes sense. It's basic maths - if you add 1 to a number, with > > normal arithmetic, you can't make it smaller. > > With the same reasoning you could say that unsigneds might never > wrap; but in fact they're specified to wrap. Unsigneds are specified to wrap, yes - but almost all occurrences of unsigned overflow are bugs in the code. /Very/ occasionally, you want wrapping semantics for integer arithmetic. It thus made sense for C (and C++) to provide a way to get wrapping when you need it - and it was easy to specify it for unsigned types, but would be unduly inefficient for signed types. It makes no sense that if you have 4294967295 apples in a pile, add an apple, you get 0 apples. It makes no sense that if you have 2147483647 apples in a pile, add an apple, you get -2147483648 apples. > And That's not how > computers work. That is utterly irrelevant. Computers work with electrical signals, and at a different level, with bits. That has no bearing on what makes sense in a computer language or a program. The wrapping and the two's complement format is simply the cheapest and fastest way to make the hardware, nothing more than that. > If someone does this he does the above intentionally > there's only _one_ reason for it: he wants to check for wrap-around. > So this is an optimization which no one asked for. > The only reason to write code like manually that is through a misunderstanding of the language. But weird and irrational code can be generated as a result of inlining, macros, templates, constant propagation, etc. And you /want/ the compiler to optimise these and remove code that could not possibly run. Oh, and please tell me you read the rest of my post and understood it - both how it demonstrated an optimisation based on undefined signed overflows, and how compilers do not treat signed integers as wrapping. (While it would be nice to get an answer there, I know you won't give it - I know you are don't understand basic human qualities like politeness, and I know you will do anything to avoid admitting that you were wrong and prefer to remain ignorant. I wrote my posts hoping other people will benefit from them too. But if you prove /me/ wrong by replying properly to my posts and questions, I would be much obliged.)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-06 07:08 +0100 |
| Message-ID | <qpto06$4jo$1@news.albasani.net> |
| In reply to | #69577 |
>> And That's not how computers work. > That is utterly irrelevant. You can rely on that p0907r0 will be included in an upcoming standard and all implementations will have std::numeric_limits<signed...>:: is_modulo to be set to true; so g++ must drop thé shown optimization. There are so many language-properties that represent how a CPU logi- cally works, why not this property?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-06 09:30 +0100 |
| Message-ID | <qpu0at$sb8$1@dont-email.me> |
| In reply to | #69582 |
On 06/11/2019 07:08, Bonita Montero wrote: >>> And That's not how computers work. > >> That is utterly irrelevant. > > You can rely on that p0907r0 will be included in an upcoming standard > and all implementations will have std::numeric_limits<signed...>:: Have you actually /read/ the paper, and its subsequent revisions (we are now on p0907r4) ? <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r4.html> Signed integer overflow remains undefined behaviour. This is what the majority of the committee, the majority of compiler vendors, and the majority of users want. > is_modulo to be set to true; so g++ must drop thé shown optimization. "is_modulo" can be (but doesn't need to be) set to true if the implementation gives signed integer arithmetic wrapping semantics. /If/ an implementation has is_modulo set true for signed types, then you are correct that it can't do the kind of optimisations I showed (or many other optimisations). gcc, clang and MSVC currently have is_modulo false for signed integer types, and do not guarantee wrapping behaviour. This is fine, and the way it should be. (gcc and clang leave it false even under "-fwrapv", which is also fine.) > There are so many language-properties that represent how a CPU logi- > cally works, why not this property? C and C++ are high level languages, abstracted from the underlying cpu. And it has already been explained to you why undefined signed integer overflow is a good idea.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-06 09:57 +0100 |
| Message-ID | <qpu1u6$trr$1@news.albasani.net> |
| In reply to | #69584 |
>> There are so many language-properties that represent how a CPU logi- >> cally works, why not this property? > C and C++ are high level languages, abstracted from the underlying cpu. C isn't high-level and C++ is high-level as well as low-level. And the issue we're ralking about is low-level.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-05 09:02 -0800 |
| Message-ID | <f79803ae-7c19-41d3-8f0c-e8dab4b29bca@googlegroups.com> |
| In reply to | #69562 |
On Tuesday, 5 November 2019 11:31:39 UTC+2, David Brown wrote: > > When people can't agree, and when every option has its advantages and > disadvantages, the only rational solution is to give people an explicit > choice. There are lot of aspects that majority of people involved seem to agree with. * on majority of cases overflow (even unsigned) is programming error * trap (overflow that signals or throws) helps to find programming errors most reliably and quickly * wrap (overflow with modular arithmetic) can be used intentionally and efficiently in some algorithms * snap (overflow that results with saturating nan) is good when damaged, disconnected or short circuited (temperature?) sensor should not turn our device (airplane?) into brick * compiler assuming that overflow not occurring is ensured by some external logic may allow noteworthy optimizations * efficiency is of low importance for lot of code * efficiency of C++ is one of its design goals * it is good when programmer's intention can be indicated in code So if to think of it then it is large puzzle indeed how to resolve it elegantly and it continues to be bad to leave it all up to implementations to decide and then each developer to struggle with it on his own with "this standard imposes no requirements". I myself would like most current operators to trap on overflow (by raising SIGFPE or throwing std::overflow_error) both for signed and unsigned. For wrap, snap and "compiler may assume that the operation does not overflow" cases I would like new operators.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-11-05 17:15 +0000 |
| Message-ID | <37iwF.27533$FR8.21788@fx45.iad> |
| In reply to | #69571 |
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes: >On Tuesday, 5 November 2019 11:31:39 UTC+2, David Brown wrote: >> >> When people can't agree, and when every option has its advantages and >> disadvantages, the only rational solution is to give people an explicit >> choice. > >There are lot of aspects that majority of people involved seem to >agree with. > >* on majority of cases overflow (even unsigned) is programming error >* trap (overflow that signals or throws) helps to find programming > errors most reliably and quickly While true, see efficiency, below. >* wrap (overflow with modular arithmetic) can be used intentionally > and efficiently in some algorithms >* snap (overflow that results with saturating nan) is good when > damaged, disconnected or short circuited (temperature?) sensor > should not turn our device (airplane?) into brick >* compiler assuming that overflow not occurring is ensured by some > external logic may allow noteworthy optimizations >* efficiency is of low importance for lot of code With this, I cannot agree. >* efficiency of C++ is one of its design goals >* it is good when programmer's intention can be indicated in code > >So if to think of it then it is large puzzle indeed how to resolve it >elegantly and it continues to be bad to leave it all up to >implementations to decide and then each developer to struggle >with it on his own with "this standard imposes no requirements". > >I myself would like most current operators to trap on overflow >(by raising SIGFPE or throwing std::overflow_error) both for >signed and unsigned. Integer? Float? Both? Isn't that a function of the hardware? Or do you expect to generate a conditional branch to inject a signal after every arithmetic instruction (or sequence thereof) that could overflow? Note that ARM supports a cumulative overflow (floating point only) that can be used to check if one of several consecutive operations overflowed without needing to check each one. Even someone who believes that "efficiency is of low importance" wouldn't be willing to accept the performance degradation caused by such checking code. >For wrap, snap and "compiler may assume that the operation >does not overflow" cases I would like new operators.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-05 10:19 -0800 |
| Message-ID | <def5baa5-99c4-4cbf-881a-b615a94b3f04@googlegroups.com> |
| In reply to | #69572 |
On Tuesday, 5 November 2019 19:15:56 UTC+2, Scott Lurndal wrote: > =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes: > >On Tuesday, 5 November 2019 11:31:39 UTC+2, David Brown wrote: > >> > >> When people can't agree, and when every option has its advantages and > >> disadvantages, the only rational solution is to give people an explicit > >> choice. > > > >There are lot of aspects that majority of people involved seem to > >agree with. > > > >* on majority of cases overflow (even unsigned) is programming error > >* trap (overflow that signals or throws) helps to find programming > > errors most reliably and quickly > > While true, see efficiency, below. > > >* wrap (overflow with modular arithmetic) can be used intentionally > > and efficiently in some algorithms > >* snap (overflow that results with saturating nan) is good when > > damaged, disconnected or short circuited (temperature?) sensor > > should not turn our device (airplane?) into brick > >* compiler assuming that overflow not occurring is ensured by some > > external logic may allow noteworthy optimizations > >* efficiency is of low importance for lot of code > > With this, I cannot agree. You can elaborate slightly more? Perhaps you disagreed before reading "for lot of code". > > >* efficiency of C++ is one of its design goals > >* it is good when programmer's intention can be indicated in code > > > >So if to think of it then it is large puzzle indeed how to resolve it > >elegantly and it continues to be bad to leave it all up to > >implementations to decide and then each developer to struggle > >with it on his own with "this standard imposes no requirements". > > > >I myself would like most current operators to trap on overflow > >(by raising SIGFPE or throwing std::overflow_error) both for > >signed and unsigned. > > Integer? Float? Both? Isn't that a function of the hardware? I meant unsigned and signed integers. IEEE floating point has by default exceptions disabled so I would leave it like that. I see no actual dichotomy between hardware or software. > Or do you expect to > generate a conditional branch to inject a signal > after every arithmetic instruction (or sequence thereof) > that could overflow? Where hardware does not help there software has to emulate it. > Note that ARM supports a cumulative overflow (floating point only) > that can be used to check if one of several consecutive operations > overflowed without needing to check each one. Yes but I meant integers. > Even someone who believes that "efficiency is of low importance" > wouldn't be willing to accept the performance degradation caused > by such checking code. I meant (and tried to say that) "for lot of code efficiency is of low importance". It is about 90% of most code bases that runs less than 1% of total run-time. It is lot of code. Also it is often less well tested and defects in it sometimes manifest like hard-to-reproduce instability. What is worth to optimize or where overflow is not error I would like to be clearly indicated with syntax: > >For wrap, snap and "compiler may assume that the operation > >does not overflow" cases I would like new operators.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2019-11-05 19:31 +0100 |
| Message-ID | <qpsf62$drr$1@gioia.aioe.org> |
| In reply to | #69571 |
On 11/5/19 6:02 PM, Öö Tiib wrote: > On Tuesday, 5 November 2019 11:31:39 UTC+2, David Brown wrote: >> >> When people can't agree, and when every option has its advantages and >> disadvantages, the only rational solution is to give people an explicit >> choice. Except when giving a choice complicates the matter more than the benefits it can give. From this perspective I like compiler flags more than adding new source code constructs. Maybe because I think that signed wrapping, unlike unsigned, is of no practical use. > > There are lot of aspects that majority of people involved seem to > agree with. I, for one, find some of them questionable. > > * on majority of cases overflow (even unsigned) is programming error That's my first - unsigned wrapping /can/ be useful in some contexts. I can't say if it is about the majority of cases, but it is enough to keep it in place. > * trap (overflow that signals or throws) helps to find programming > errors most reliably and quickly I would say it is a better debugging aid than nothing, but as reliability goes it can only catch what is executed, and it is often impossible to test all possible combinations at runtime. On the other hand, it would degrade efficiency to a possibly unacceptable level (As Scott pointed out). > * wrap (overflow with modular arithmetic) can be used intentionally > and efficiently in some algorithms > * snap (overflow that results with saturating nan) is good when > damaged, disconnected or short circuited (temperature?) sensor > should not turn our device (airplane?) into brick I am not sure bout this. Floating point arithmetic does something of the kind (NaN propagates through), but I think that if it is about a sensor failure, and especially if it is about safety, then the hardware itself or the device driver should handle this properly, i.e. with specific error conditions, rather than the language. > * compiler assuming that overflow not occurring is ensured by some > external logic may allow noteworthy optimizations True. > * efficiency is of low importance for lot of code Disagree. It is not always important, but it is important enough to be one of the main reasons to choose C++, so it should be of primary importance for the language. > * efficiency of C++ is one of its design goals > * it is good when programmer's intention can be indicated in code True, as long as verbosity is kept at a reasonable level. > > So if to think of it then it is large puzzle indeed how to resolve it > elegantly and it continues to be bad to leave it all up to > implementations to decide and then each developer to struggle > with it on his own with "this standard imposes no requirements". > > I myself would like most current operators to trap on overflow > (by raising SIGFPE or throwing std::overflow_error) both for > signed and unsigned. I agree with Scott here. > For wrap, snap and "compiler may assume that the operation > does not overflow" cases I would like new operators. > See above, my impression is that this would result in excessive bloat of the language. Better use compiler flags, or at most #pragmas for sections of code.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-05 11:55 -0800 |
| Message-ID | <6517f0d3-959c-45b7-8125-6ddd6111ec22@googlegroups.com> |
| In reply to | #69574 |
On Tuesday, 5 November 2019 20:31:45 UTC+2, Manfred wrote: > On 11/5/19 6:02 PM, Öö Tiib wrote: > > On Tuesday, 5 November 2019 11:31:39 UTC+2, David Brown wrote: > >> > >> When people can't agree, and when every option has its advantages and > >> disadvantages, the only rational solution is to give people an explicit > >> choice. > > Except when giving a choice complicates the matter more than the > benefits it can give. > From this perspective I like compiler flags more than adding new source > code constructs. Maybe because I think that signed wrapping, unlike > unsigned, is of no practical use. > > > > > There are lot of aspects that majority of people involved seem to > > agree with. > > I, for one, find some of them questionable. > > > > > * on majority of cases overflow (even unsigned) is programming error > That's my first - unsigned wrapping /can/ be useful in some contexts. I > can't say if it is about the majority of cases, but it is enough to keep > it in place. Perhaps here is some difference in meaning of word "majority". For me "majority" means "more than 50% of all". Also "all" is all such operations in code base. You seem to express disagreement with something else. > > * trap (overflow that signals or throws) helps to find programming > > errors most reliably and quickly > I would say it is a better debugging aid than nothing, but as > reliability goes it can only catch what is executed, and it is often > impossible to test all possible combinations at runtime. On the other > hand, it would degrade efficiency to a possibly unacceptable level (As > Scott pointed out). To disagree you need to tell what helps to find programming errors involving arithmetic overflow more reliably and quickly. Also about efficiency that would move compiler optimization developers to right direction. Instead of logic that it is up to programmer to ensure that here is no overflow so if here is then this code can be erased they would try to prove that overflow is impossible themselves so they can erase the codes and not to generate trapping checks. > > * wrap (overflow with modular arithmetic) can be used intentionally > > and efficiently in some algorithms > > * snap (overflow that results with saturating nan) is good when > > damaged, disconnected or short circuited (temperature?) sensor > > should not turn our device (airplane?) into brick > I am not sure bout this. > Floating point arithmetic does something of the kind (NaN propagates > through), but I think that if it is about a sensor failure, and > especially if it is about safety, then the hardware itself or the device > driver should handle this properly, i.e. with specific error conditions, > rather than the language. Physically damaged, disconnected or short-circuited temperature sensor can no way repair or reconnect itself. So the software of device that has such sensor has to work with NaNs for currently measured temperature or has to turn into brick. There are nothing else to do. Hardware like that of T-1000 from Terminator-2 is not yet invented. > > > * compiler assuming that overflow not occurring is ensured by some > > external logic may allow noteworthy optimizations > True. > > > * efficiency is of low importance for lot of code > Disagree. It is not always important, but it is important enough to be > one of the main reasons to choose C++, so it should be of primary > importance for the language. > > > * efficiency of C++ is one of its design goals > > * it is good when programmer's intention can be indicated in code > True, as long as verbosity is kept at a reasonable level. > > > > > So if to think of it then it is large puzzle indeed how to resolve it > > elegantly and it continues to be bad to leave it all up to > > implementations to decide and then each developer to struggle > > with it on his own with "this standard imposes no requirements". > > > > I myself would like most current operators to trap on overflow > > (by raising SIGFPE or throwing std::overflow_error) both for > > signed and unsigned. > I agree with Scott here. > > > For wrap, snap and "compiler may assume that the operation > > does not overflow" cases I would like new operators. > > > See above, my impression is that this would result in excessive bloat of > the language. Better use compiler flags, or at most #pragmas for > sections of code. My reasoning is that operators (like say a +% b for wrapping add) are most terse and can be most flexibly mixed with each other.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2019-11-05 22:48 +0100 |
| Message-ID | <qpsqng$2bj$1@gioia.aioe.org> |
| In reply to | #69576 |
On 11/5/2019 8:55 PM, Öö Tiib wrote: > On Tuesday, 5 November 2019 20:31:45 UTC+2, Manfred wrote: >> On 11/5/19 6:02 PM, Öö Tiib wrote: >>> On Tuesday, 5 November 2019 11:31:39 UTC+2, David Brown wrote: >>>> >>>> When people can't agree, and when every option has its advantages and >>>> disadvantages, the only rational solution is to give people an explicit >>>> choice. >> >> Except when giving a choice complicates the matter more than the >> benefits it can give. >> From this perspective I like compiler flags more than adding new source >> code constructs. Maybe because I think that signed wrapping, unlike >> unsigned, is of no practical use. >> >>> >>> There are lot of aspects that majority of people involved seem to >>> agree with. >> >> I, for one, find some of them questionable. >> >>> >>> * on majority of cases overflow (even unsigned) is programming error >> That's my first - unsigned wrapping /can/ be useful in some contexts. I >> can't say if it is about the majority of cases, but it is enough to keep >> it in place. > > Perhaps here is some difference in meaning of word "majority". > For me "majority" means "more than 50% of all". Also "all" is > all such operations in code base. You seem to express disagreement > with something else. My point is about what to do with the fact that many times overflow is a programming error: even if this is true I think that unsigned overflow should have defined behavior (and wrap) rather than being handled as an error by the compiler. > >>> * trap (overflow that signals or throws) helps to find programming >>> errors most reliably and quickly >> I would say it is a better debugging aid than nothing, but as >> reliability goes it can only catch what is executed, and it is often >> impossible to test all possible combinations at runtime. On the other >> hand, it would degrade efficiency to a possibly unacceptable level (As >> Scott pointed out). > > To disagree you need to tell what helps to find programming errors > involving arithmetic overflow more reliably and quickly. > Also about efficiency that would move compiler optimization developers > to right direction. > Instead of logic that it is up to programmer to ensure that here is > no overflow so if here is then this code can be erased > they would try to prove that overflow is impossible themselves so they > can erase the codes and not to generate trapping checks. > >>> * wrap (overflow with modular arithmetic) can be used intentionally >>> and efficiently in some algorithms >>> * snap (overflow that results with saturating nan) is good when >>> damaged, disconnected or short circuited (temperature?) sensor >>> should not turn our device (airplane?) into brick >> I am not sure bout this. >> Floating point arithmetic does something of the kind (NaN propagates >> through), but I think that if it is about a sensor failure, and >> especially if it is about safety, then the hardware itself or the device >> driver should handle this properly, i.e. with specific error conditions, >> rather than the language. > > Physically damaged, disconnected or short-circuited temperature sensor > can no way repair or reconnect itself. Undoubtedly, but that's not what I wrote. So the software of device that > has such sensor has to work with NaNs for currently measured temperature > or has to turn into brick. There are nothing else to do. > Hardware like that of T-1000 from Terminator-2 is not yet invented. No need to call in Schwarzenegger for help. My point is that rather than using NaNs the hardware or driver should raise specific error signals (like some error code on the control I/O port, or at the API level) instead.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-05 15:49 -0800 |
| Message-ID | <aa26b7c6-8beb-4998-b3cf-c8977c0c384f@googlegroups.com> |
| In reply to | #69578 |
On Tuesday, 5 November 2019 23:48:46 UTC+2, Manfred wrote: > On 11/5/2019 8:55 PM, Öö Tiib wrote: > > On Tuesday, 5 November 2019 20:31:45 UTC+2, Manfred wrote: > >> On 11/5/19 6:02 PM, Öö Tiib wrote: > >>> On Tuesday, 5 November 2019 11:31:39 UTC+2, David Brown wrote: > >>>> > >>>> When people can't agree, and when every option has its advantages and > >>>> disadvantages, the only rational solution is to give people an explicit > >>>> choice. > >> > >> Except when giving a choice complicates the matter more than the > >> benefits it can give. > >> From this perspective I like compiler flags more than adding new source > >> code constructs. Maybe because I think that signed wrapping, unlike > >> unsigned, is of no practical use. > >> > >>> > >>> There are lot of aspects that majority of people involved seem to > >>> agree with. > >> > >> I, for one, find some of them questionable. > >> > >>> > >>> * on majority of cases overflow (even unsigned) is programming error > >> That's my first - unsigned wrapping /can/ be useful in some contexts. I > >> can't say if it is about the majority of cases, but it is enough to keep > >> it in place. > > > > Perhaps here is some difference in meaning of word "majority". > > For me "majority" means "more than 50% of all". Also "all" is > > all such operations in code base. You seem to express disagreement > > with something else. > My point is about what to do with the fact that many times overflow is a > programming error: even if this is true I think that unsigned overflow > should have defined behavior (and wrap) rather than being handled as an > error by the compiler. I just listed facts with what lot of people agree like "on majority of cases overflow (even unsigned) is programming error" I did not say what to conclude from these facts here. > >>> * wrap (overflow with modular arithmetic) can be used intentionally > >>> and efficiently in some algorithms > >>> * snap (overflow that results with saturating nan) is good when > >>> damaged, disconnected or short circuited (temperature?) sensor > >>> should not turn our device (airplane?) into brick > >> I am not sure bout this. > >> Floating point arithmetic does something of the kind (NaN propagates > >> through), but I think that if it is about a sensor failure, and > >> especially if it is about safety, then the hardware itself or the device > >> driver should handle this properly, i.e. with specific error conditions, > >> rather than the language. > > > > Physically damaged, disconnected or short-circuited temperature sensor > > can no way repair or reconnect itself. > Undoubtedly, but that's not what I wrote. Ok. > So the software of device that > > has such sensor has to work with NaNs for currently measured temperature > > or has to turn into brick. There are nothing else to do. > > Hardware like that of T-1000 from Terminator-2 is not yet invented. > No need to call in Schwarzenegger for help. > My point is that rather than using NaNs the hardware or driver should > raise specific error signals (like some error code on the control I/O > port, or at the API level) instead. Device has to operate on incomplete data. And saturating silent NaN works perfectly as such missing part of data. Driver that is panicking throwing up and signaling too lot has to be killed to reduce disturbance. Panic solves nothing regardless if you are Schwarzenegger or not. ;)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-11-09 06:13 -0800 |
| Message-ID | <86pni1cf4a.fsf@linuxsc.com> |
| In reply to | #69578 |
Manfred <noname@add.invalid> writes: > My point is about what to do with the fact that many times > overflow is a programming error: even if this is true I think that > unsigned overflow should have defined behavior (and wrap) rather > than being handled as an error by the compiler. I absolutely concur. Your other comments in the thread also are right on the money. Frankly I am rather baffled by the comments of those on the other side of what you've been saying.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2019-11-10 18:37 +0100 |
| Message-ID | <qq9hsf$8kt$2@gioia.aioe.org> |
| In reply to | #69678 |
On 11/9/19 3:13 PM, Tim Rentsch wrote: > Manfred <noname@add.invalid> writes: > >> My point is about what to do with the fact that many times >> overflow is a programming error: even if this is true I think that >> unsigned overflow should have defined behavior (and wrap) rather >> than being handled as an error by the compiler. > > I absolutely concur. Your other comments in the thread also are > right on the money. I know. Frankly I am rather baffled by the comments > of those on the other side of what you've been saying. > Not a surprise, though. The internet is this too.
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web