Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #81271 > unrolled thread
| Started by | alessandro volturno <alessandro.volturno@libero.it> |
|---|---|
| First post | 2021-09-16 14:59 +0200 |
| Last post | 2021-09-24 02:48 -0700 |
| Articles | 20 on this page of 230 — 21 participants |
Back to article view | Back to comp.lang.c++
rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-16 14:59 +0200
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-16 16:40 +0300
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-16 18:24 +0200
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-16 17:05 +0000
Re: rational numbers Manfred <noname@add.invalid> - 2021-09-16 19:58 +0200
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-17 09:21 +0200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-17 10:34 +0200
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-17 15:55 +0200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-17 17:49 +0200
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-17 18:22 +0200
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-17 22:07 +1200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-17 13:32 +0200
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-18 09:15 +1200
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-17 14:06 +0000
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-16 20:41 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-16 21:11 +0100
Re: rational numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-16 21:26 +0100
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-16 21:54 +0100
Re: rational numbers "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-16 23:07 +0200
Re: rational numbers "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-16 23:27 +0200
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-16 23:12 +0300
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-17 09:50 +0200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-17 11:15 +0200
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-17 19:19 +0200
Re: rational numbers James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-17 19:00 -0400
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-18 11:39 +0200
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-18 11:56 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-18 11:01 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-17 05:36 +0000
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-17 09:55 +0200
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-17 11:16 +0000
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-17 18:33 +0200
Re: rational numbers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 13:06 -0700
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-17 14:03 +0000
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-17 17:12 +0200
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-17 17:16 +0200
Re: rational numbers Manfred <noname@add.invalid> - 2021-09-17 18:59 +0200
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-17 17:13 +0000
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-19 10:17 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-19 14:07 +0000
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-19 15:58 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-19 21:53 +0000
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-18 09:34 +1200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-18 12:00 +0200
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-18 14:54 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-18 17:36 +0100
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-18 23:29 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-19 01:09 +0100
Re: rational numbers red floyd <no.spam.here@its.invalid> - 2021-09-18 23:45 -0700
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-18 22:48 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-19 00:46 +0100
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-19 08:06 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-19 10:26 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-19 10:23 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-19 12:04 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-19 16:01 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-19 17:39 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-20 05:25 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-20 10:37 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-22 04:58 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-22 11:26 +0100
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-22 23:13 +1200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-22 13:45 +0100
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-24 21:37 +1200
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-22 15:29 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-23 07:26 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-19 21:54 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-20 00:31 +0100
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-20 08:33 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-20 16:11 +0100
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-20 18:08 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-20 18:39 +0100
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-20 19:49 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-20 19:04 +0100
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-20 21:35 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-20 21:38 +0100
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-21 10:28 +1200
Re: rational numbers Bo Persson <bo@bo-persson.se> - 2021-09-21 09:08 +0200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-21 09:39 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 11:12 +0100
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-21 15:45 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 14:37 +0100
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-21 17:09 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 16:26 +0100
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-21 18:04 +0200
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-21 11:51 -0700
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-22 11:09 +0200
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 15:38 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 15:36 +0000
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-21 15:49 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 16:21 +0000
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-22 09:21 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 17:45 +0100
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 17:02 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 18:16 +0100
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-21 11:53 -0700
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 20:48 +0100
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 20:23 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 23:29 +0100
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-21 13:47 -0700
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-21 20:11 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 18:33 +0100
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-21 20:43 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 18:59 +0100
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-21 21:20 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 20:32 +0100
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 20:24 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 18:52 +0000
Re: rational numbers Bo Persson <bo@bo-persson.se> - 2021-09-21 18:34 +0200
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-21 01:16 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 00:39 +0100
Re: rational numbers Manfred <noname@add.invalid> - 2021-09-22 23:45 +0200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-22 23:51 +0200
Re: rational numbers Manfred <noname@add.invalid> - 2021-09-23 18:42 +0200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-23 21:52 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 00:17 +0100
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-23 02:03 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 11:18 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-23 10:26 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 12:21 +0100
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 12:40 +0100
Re: rational numbers Richard Damon <Richard@Damon-Family.org> - 2021-09-23 08:05 -0400
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 15:02 +0100
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-24 08:48 +1200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 23:05 +0100
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-23 23:47 +0000
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-23 16:56 -0700
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-24 01:58 +0100
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 01:40 +0000
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-23 19:35 -0700
Re: rational numbers "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-24 09:07 -0700
Re: rational numbers "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-24 09:21 -0700
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-23 14:58 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 17:02 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-23 16:21 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 18:31 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-24 09:12 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-24 12:10 +0100
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 11:23 +0000
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-24 15:19 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-24 17:25 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-25 09:27 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-25 11:07 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-25 10:14 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-25 11:53 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-25 11:23 +0000
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 12:34 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-25 15:37 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-25 15:46 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-25 15:19 +0000
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 17:16 +0000
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-27 23:51 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-27 23:41 +0100
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-23 10:26 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-23 14:04 +0000
Re: rational numbers Manfred <noname@add.invalid> - 2021-09-23 17:47 +0200
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-23 17:07 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-23 17:08 +0000
Re: rational numbers Manfred <noname@add.invalid> - 2021-09-23 19:30 +0200
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-24 10:06 +1200
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-22 05:06 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-22 10:51 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-22 10:54 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-22 11:59 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-22 11:04 +0000
Re: rational numbers "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-22 14:17 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-22 14:32 +0100
Re: rational numbers "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-22 16:23 +0200
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-22 15:18 +0300
Re: rational numbers "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-22 16:16 +0200
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-22 15:15 +0000
Re: rational numbers "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-22 17:57 +0200
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-22 16:05 +0000
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-22 14:13 -0700
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-23 09:01 +0000
Re: rational numbers James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-23 12:08 -0400
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-23 10:55 -0700
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-22 20:46 +0300
Re: rational numbers "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-22 14:42 -0700
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-23 09:15 +0300
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-22 14:04 +0000
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-22 07:18 -0700
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-23 07:31 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-23 11:05 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-23 08:28 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-24 00:51 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-24 04:37 +0000
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 07:46 +0000
Re: rational numbers "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-24 08:59 -0700
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-24 22:49 +0300
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 00:55 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-24 12:17 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-27 05:25 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-27 11:37 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-28 04:49 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 11:29 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-24 04:38 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-24 11:15 +0100
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 10:19 +0000
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-27 05:34 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-23 14:07 +0000
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-23 14:50 +0000
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-20 05:20 +0000
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-24 21:45 +1200
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-25 16:15 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-27 05:36 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-27 11:19 +0300
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-27 21:27 +1300
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-27 15:49 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-28 04:53 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-28 10:16 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-29 12:10 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-29 14:34 +0100
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-29 15:54 +0100
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-28 13:23 +0300
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-29 10:34 +1300
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-29 12:18 +0300
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-29 22:46 +1300
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-29 13:07 +0300
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-10-02 22:57 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-29 12:16 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-29 20:15 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-30 04:46 +0000
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-19 11:03 +1200
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-19 10:12 +0000
Re: rational numbers Siri Cruise <chine.bleu@yahoo.com> - 2021-09-23 07:38 -0700
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-24 09:45 +0200
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 07:50 +0000
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-24 10:58 +0200
Re: rational numbers Siri Cruise <chine.bleu@yahoo.com> - 2021-09-24 02:48 -0700
Page 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-16 23:12 +0300 |
| Message-ID | <si08gc$sc9$1@dont-email.me> |
| In reply to | #81273 |
16.09.2021 19:24 alessandro volturno kirjutas: > Il 16/09/2021 15:40, Paavo Helde ha scritto: >> 16.09.2021 15:59 alessandro volturno kirjutas: >>> >>> Maybe my question is stupid, but >>> why not to introduce a way to handle rational numbers inside the C++ >>> standard or better make it a built in type? > > I speak as a non-competent, hobbyist programmer and computer-user. > >> What are the use cases for rationals? If something is not in the >> standard, then often there are different use cases which cannot be >> easily covered by a common "standard" implementation. > > Computers were born to manipulate numbers and the languages for doing > that, at that time, were mainly two: FORTRAN, and LISP. I have noticed > that C++ (that I presume it could be thought of as a descendant of > FORTRAN, is shifting towards Functional programming language facilities, > like that offered by the LISP family. That's good, but numerical > programming is still important nowadays. Of course numerical programming is important. It's done mostly in floating-point (64-bit and 32-bit; in recent years also 16-bit on GPU-s). In some cases it can be done in integers, for more speed, but it's not so simple and the speedups are not very large any more nowadays. I notice that you still haven't presented any use case for rationals. I have to admit I also wrote a C++ class for rational numbers ca 20 years ago, but so far I have not found any usage for it in my work (which also involves a lot of heavy numeric computations). > >> For rationals it feels like a fast implementation would have a pretty >> limited numeric range, and unlimited range would require arbitrary >> precision integers and would probably be many times slower even in >> case of small numbers. > > Mine uses long long int, that is the maximum offered by the language, > but calculation speed is constantly increasing. I don't see that a as a > limiting factor. Long long int probably means 64 bits, which is not so much. The smallest positive rational would be 1/2^64, i.e. ca 10^-61. Meanwhile, the smallest positive double is ca 10^-308, with the same number of bits. Ditto for the largest values. IOW, floating-point can approximate values with much more precision, and there is much less danger of overflows during computations. The only advantage what rationals offer above floating-point is that the calculation results are always exact. However, in numeric programming the input data often comes from a physical measurement, meaning that it already contains measurement inaccuracies. Thus the end result will not be absolutely accurate anyway, so there is no need to use absolutely precise computations. Sure, with floating-point algorithms one must take care to not lose too much precision in intermediate results. However, I suspect that with rational number algorithms even more care is needed, to avoid numeric overflows in intermediate results. [...] > Thank you for your kind reply, Thanks!
[toc] | [prev] | [next] | [standalone]
| From | alessandro volturno <alessandro.volturno@libero.it> |
|---|---|
| Date | 2021-09-17 09:50 +0200 |
| Message-ID | <si1hed$unn$1@gioia.aioe.org> |
| In reply to | #81278 |
Il 16/09/2021 22:12, Paavo Helde ha scritto: > 16.09.2021 19:24 alessandro volturno kirjutas: >> Il 16/09/2021 15:40, Paavo Helde ha scritto: >>> What are the use cases for rationals? If something is not in the >>> standard, then often there are different use cases which cannot be >>> easily covered by a common "standard" implementation. > I notice that you still haven't presented any use case for rationals. I > have to admit I also wrote a C++ class for rational numbers ca 20 years > ago, but so far I have not found any usage for it in my work (which also > involves a lot of heavy numeric computations). I am not a mathematician nor a physicist but probably solving systems of linear equations with Gauss or Gauss-Jordan methods can be an application of rational numbers. Many years ago trying to use the Common lisp programming language, I was impressed by its natural handling of rational numbers and by its use of integers or floating point numbers of arbitrary precision. Common Lisp is an ANSI standard dated 1990 but it inherits properties and behaviours from ancient LISP dialects. So it seemed to me a bit strange that a programming language as widespread as C++ doesn't offer that same facilities. > The only advantage what rationals offer above floating-point is that the > calculation results are always exact. However, in numeric programming > the input data often comes from a physical measurement, meaning that it > already contains measurement inaccuracies. Thus the end result will not > be absolutely accurate anyway, so there is no need to use absolutely > precise computations. there are not only physical measures, you could develop examples with integer numbers just for didactic goals. C++ must be learned like any other discipline. And having wide numerical facilities can be very useful permitting to develop new strategies by tackling numerical problems in a different way. I'm sorry for my general argumentation and lack of practical examples, but as I had already written, I do program just for fun. > [...] And talking about features offered by a programming language, there is just another addition that could help developing large applications or bigger projects, and that is 2d and GUI facilities. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r10.pdf Thank you again for the opportunity of this discussion. alessandro
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-17 11:15 +0200 |
| Message-ID | <si1mc4$u4h$1@dont-email.me> |
| In reply to | #81285 |
On 17/09/2021 09:50, alessandro volturno wrote: > Il 16/09/2021 22:12, Paavo Helde ha scritto: >> 16.09.2021 19:24 alessandro volturno kirjutas: >>> Il 16/09/2021 15:40, Paavo Helde ha scritto: > >>>> What are the use cases for rationals? If something is not in the >>>> standard, then often there are different use cases which cannot be >>>> easily covered by a common "standard" implementation. > >> I notice that you still haven't presented any use case for rationals. >> I have to admit I also wrote a C++ class for rational numbers ca 20 >> years ago, but so far I have not found any usage for it in my work >> (which also involves a lot of heavy numeric computations). > > I am not a mathematician nor a physicist but probably solving systems of > linear equations with Gauss or Gauss-Jordan methods can be an > application of rational numbers. > You will quickly get meaninglessly big numbers if you use rationals for that kind of thing. Calculations with rationals usually only makes sense for pure mathematics and number theory, not applied mathematics or physics. > Many years ago trying to use the Common lisp programming language, I was > impressed by its natural handling of rational numbers and by its use of > integers or floating point numbers of arbitrary precision. Common Lisp > is an ANSI standard dated 1990 but it inherits properties and behaviours > from ancient LISP dialects. So it seemed to me a bit strange that a > programming language as widespread as C++ doesn't offer that same > facilities. > C++ arithmetic aims for efficiency, predictability, and fixed sizes. Fixed size rationals are of quite limited use - you can't do much arithmetic on them before the sizes overflow. As I mentioned earlier, there is a lot of fun and learning from making classes to support these, but little practical use - therefore no point in having them in the standard library. (The C++ standard library has support for compile-time rational arithmetic, mainly as a convenient way to handle magnitudes of SI units.) So for useful rationals, you need arbitrary precision integers. And that is a whole different ballgame from fixed sizes - you are now talking about memory management, big complicated algorithms, and all sorts of trade-offs in the implementation. For some languages, it's okay to pick one "reasonable" implementation. It might be big and incorporate a range of algorithms for different sizes - that's fine for a language like Python that already has huge libraries. It might be small and simple, and do a reasonable job for smaller sizes but be less optimal for huge values - that made sense for Bart in his language. For C++, it's a /lot/ harder to decide what to do for the standard library, as C++ programmers have such different needs. Someone who just wants to do arithmetic up to 4K bits for cryptography will not want the cost to support megabit sizes. Someone who needs a lot of decimal I/O might want a base-10 model rather than a base-2 model. People with particular processors might want a model optimised for the SIMD instructions they have, though it might be much less efficient on other processors. C++ does not try to put /everything/ a programmer might need into its standard library - it aims to have the tools and basics there, so that others can make libraries as needed. That's the case here. >> The only advantage what rationals offer above floating-point is that >> the calculation results are always exact. However, in numeric >> programming the input data often comes from a physical measurement, >> meaning that it already contains measurement inaccuracies. Thus the >> end result will not be absolutely accurate anyway, so there is no need >> to use absolutely precise computations. > > there are not only physical measures, you could develop examples with > integer numbers just for didactic goals. C++ must be learned like any > other discipline. And having wide numerical facilities can be very > useful permitting to develop new strategies by tackling numerical > problems in a different way. > I agree with those aims. And a C++ standard library for rational numbers would be completely against that aim - how could you learn about making good classes and abstractions using rational numbers if the library already supported them? Make it yourself - that's how you will learn. > I'm sorry for my general argumentation and lack of practical examples, > but as I had already written, I do program just for fun. > >> [...] > > And talking about features offered by a programming language, there is > just another addition that could help developing large applications or > bigger projects, and that is 2d and GUI facilities. > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r10.pdf > The proposal for adding gui facilities to the C++ standard is /highly/ controversial. Some people think it would be nice to have in the standard because "everyone" needs graphics and a gui. Others think it is a terrible idea because there are several dozen popular gui libraries, with wildly varying pros and cons, and making a "standard C++ gui library" would be as bad an idea as a country's roads department picking a standard car. > Thank you again for the opportunity of this discussion. > > alessandro > >
[toc] | [prev] | [next] | [standalone]
| From | alessandro volturno <alessandro.volturno@libero.it> |
|---|---|
| Date | 2021-09-17 19:19 +0200 |
| Message-ID | <si2ioe$14d1$1@gioia.aioe.org> |
| In reply to | #81288 |
Il 17/09/2021 11:15, David Brown ha scritto: > You will quickly get meaninglessly big numbers if you use rationals for > that kind of thing. Calculations with rationals usually only makes > sense for pure mathematics and number theory, not applied mathematics or > physics. A tool is crafted for a certain scope, you could but don't want to peel an apple with a cutter. If a tool is present in a computer language's library that doesn't mean every one has ever to use it. > C++ arithmetic aims for efficiency, predictability, and fixed sizes. > Fixed size rationals are of quite limited use - you can't do much > arithmetic on them before the sizes overflow. This is my personal opinion: C's and C++'s search for efficiency is probably one of the cause that made other computer scientists develop newer or more complete and easy to use computer languages. > For C++, it's a /lot/ harder to decide what to do for the standard > library, as C++ programmers have such different needs. Someone who just > wants to do arithmetic up to 4K bits for cryptography will not want the > cost to support megabit sizes. Someone who needs a lot of decimal I/O > might want a base-10 model rather than a base-2 model. People with > particular processors might want a model optimised for the SIMD > instructions they have, though it might be much less efficient on other > processors. If something is in the standard library that doesn't mean everyone has to use it. Your argument is valid if it were made a built in facility, but in Common Lisp you have the usual fixed sized numerical types as well as the wider and heavier ratios or numbers of arbitrary precision. it's at your discretion use those things or not. > C++ does not try to put /everything/ a programmer might need into its > standard library - it aims to have the tools and basics there, so that > others can make libraries as needed. That's the case here. Libraries are a bless, but there are so many of them all around you get confused, and one has to spend many weeks studying one of them to obtain something you could do inside your favourite programming language. I have written, some years ago, a silly game in C++, quite similar to Amiga's Colors. The platform used to develop it was linux. and well, to paint on the screen I had to use an external library (Allegro 4). Another toy program that I wrote uses FLTK's GUI facility. If I had the opportunity of a graphics library inside C++, my program could just be recompiled on Windows to work, without having to compile the library using tools like cygwin to make it working in Windows. >>> The only advantage what rationals offer above floating-point is that >>> the calculation results are always exact. However, in numeric >>> programming the input data often comes from a physical measurement, >>> meaning that it already contains measurement inaccuracies. Physics is not the only Science out there >> [...] you could develop examples with >> integer numbers just for didactic goals. C++ must be learned like any >> other discipline. And having wide numerical facilities can be very >> useful permitting to develop new strategies by tackling numerical >> problems in a different way. >> > I agree with those aims. And a C++ standard library for rational > numbers would be completely against that aim Why? - how could you learn about > making good classes and abstractions using rational numbers if the > library already supported them? Make it yourself - that's how you will > learn. You could just try to reinvent the wheel, thinking about how it could be implemented. But that doesn't mean having rationals in the language hinder you to mimic its functionality. Thank you, alessandro
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-09-17 19:00 -0400 |
| Message-ID | <si36md$jks$1@dont-email.me> |
| In reply to | #81302 |
On 9/17/21 1:19 PM, alessandro volturno wrote: > Il 17/09/2021 11:15, David Brown ha scritto: ... >>>> The only advantage what rationals offer above floating-point is that >>>> the calculation results are always exact. However, in numeric >>>> programming the input data often comes from a physical measurement, >>>> meaning that it already contains measurement inaccuracies. > > Physics is not the only Science out there Yes, but exactly rational numbers that are an accurate reflection of something in reality remain rare in all of the sciences.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-18 11:39 +0200 |
| Message-ID | <si4c47$2ff$1@dont-email.me> |
| In reply to | #81302 |
On 17/09/2021 19:19, alessandro volturno wrote:
> Il 17/09/2021 11:15, David Brown ha scritto:
>
>> C++ arithmetic aims for efficiency, predictability, and fixed sizes.
>> Fixed size rationals are of quite limited use - you can't do much
>> arithmetic on them before the sizes overflow.
>
> This is my personal opinion: C's and C++'s search for efficiency is
> probably one of the cause that made other computer scientists develop
> newer or more complete and easy to use computer languages.
Yes - and that's a good thing. There are all kinds of programming
tasks, and all kinds of programmers - there needs to be a variety of
programming languages. C++ should not become Python or Lisp any more
than Python should become Lua or Lisp should become Fortran.
>
>>>> The only advantage what rationals offer above floating-point is that
>>>> the calculation results are always exact. However, in numeric
>>>> programming the input data often comes from a physical measurement,
>>>> meaning that it already contains measurement inaccuracies.
>
> Physics is not the only Science out there
>
You were the one that brought up physics ("I am not a mathematician or a
physicist"). /All/ sciences - to be worthy of the name "science" -
involve measurements of real things. Almost always, these are inexact
measurements, with the exceptions being relatively small whole number
counts. Rational numbers turn up very rarely in science of any kind.
Probably the only science in which they /do/ turn up is quantum
mechanics in physics, and even there we are talking about small and
specific values (half-integer spin, third or two-third charges on
quarks, that kind of thing).
Rational arithmetic does not really turn up anywhere outside pure
mathematics and certain direct applications (such as in cryptography).
[toc] | [prev] | [next] | [standalone]
| From | alessandro volturno <alessandro.volturno@libero.it> |
|---|---|
| Date | 2021-09-18 11:56 +0200 |
| Message-ID | <si4d4c$m3d$1@gioia.aioe.org> |
| In reply to | #81306 |
Il 18/09/2021 11:39, David Brown ha scritto:
> On 17/09/2021 19:19, alessandro volturno wrote:
>> Il 17/09/2021 11:15, David Brown ha scritto:
>>
>
>>> C++ arithmetic aims for efficiency, predictability, and fixed sizes.
>>> Fixed size rationals are of quite limited use - you can't do much
>>> arithmetic on them before the sizes overflow.
>>
>> This is my personal opinion: C's and C++'s search for efficiency is
>> probably one of the cause that made other computer scientists develop
>> newer or more complete and easy to use computer languages.
>
> Yes - and that's a good thing. There are all kinds of programming
> tasks, and all kinds of programmers - there needs to be a variety of
> programming languages. C++ should not become Python or Lisp any more
> than Python should become Lua or Lisp should become Fortran.
>
>>
>>>>> The only advantage what rationals offer above floating-point is that
>>>>> the calculation results are always exact. However, in numeric
>>>>> programming the input data often comes from a physical measurement,
>>>>> meaning that it already contains measurement inaccuracies.
>>
>> Physics is not the only Science out there
>>
>
> You were the one that brought up physics ("I am not a mathematician or a
> physicist"). /All/ sciences - to be worthy of the name "science" -
> involve measurements of real things. Almost always, these are inexact
> measurements, with the exceptions being relatively small whole number
> counts. Rational numbers turn up very rarely in science of any kind.
> Probably the only science in which they /do/ turn up is quantum
> mechanics in physics, and even there we are talking about small and
> specific values (half-integer spin, third or two-third charges on
> quarks, that kind of thing).
>
> Rational arithmetic does not really turn up anywhere outside pure
> mathematics and certain direct applications (such as in cryptography).
>
But as you say, can have some advantage from them.
Anyway I now have a clear picture of the scenario about rational numbers
and C++ standard.
I can consider the question closed.
Thank you to all who took part in this thread.
alessandro
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-18 11:01 +0100 |
| Message-ID | <si4df7$aog$1@dont-email.me> |
| In reply to | #81306 |
On 18/09/2021 10:39, David Brown wrote:
> On 17/09/2021 19:19, alessandro volturno wrote:
>>
>>>>> The only advantage what rationals offer above floating-point is that
>>>>> the calculation results are always exact. However, in numeric
>>>>> programming the input data often comes from a physical measurement,
>>>>> meaning that it already contains measurement inaccuracies.
>>
>> Physics is not the only Science out there
>>
>
> You were the one that brought up physics ("I am not a mathematician or a
> physicist"). /All/ sciences - to be worthy of the name "science" -
> involve measurements of real things. Almost always, these are inexact
> measurements, with the exceptions being relatively small whole number
> counts. Rational numbers turn up very rarely in science of any kind.
> Probably the only science in which they /do/ turn up is quantum
> mechanics in physics, and even there we are talking about small and
> specific values (half-integer spin, third or two-third charges on
> quarks, that kind of thing).
>
> Rational arithmetic does not really turn up anywhere outside pure
> mathematics and certain direct applications (such as in cryptography).
So where does big integer arithemetic turn up?
With big integers, I can see that sometimes you want (A/B)*B to result in A.
With integer divide, that might not be the case.
Using floating point divide with finite precision, you can lose
information (and perversely end up with too much useless precision; if I
do (1/3)*3, with 100M digits, I get 100M digits of 0.9999....).
Letting A/B (perhaps with a special divide op) yield a rational type
would work.
In that case, I can see this being of value with i64 and i128 types too,
for the two parts of a rational number.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-17 05:36 +0000 |
| Message-ID | <si19hm$3cl$1@gioia.aioe.org> |
| In reply to | #81271 |
alessandro volturno <alessandro.volturno@libero.it> wrote: > printDescription() // prints a description of the number and its > // numerical value This is not really something that belongs to a class that behaves like an arithmetic numerical value. At most what you could have is a separate std::ostream& operator<<(std::ostream&, YourRationalClass); function for outputting the value to a std::ostream.
[toc] | [prev] | [next] | [standalone]
| From | alessandro volturno <alessandro.volturno@libero.it> |
|---|---|
| Date | 2021-09-17 09:55 +0200 |
| Message-ID | <si1hmg$120l$1@gioia.aioe.org> |
| In reply to | #81283 |
Il 17/09/2021 07:36, Juha Nieminen ha scritto: > alessandro volturno <alessandro.volturno@libero.it> wrote: >> printDescription() // prints a description of the number and its >> // numerical value > > This is not really something that belongs to a class that behaves like an > arithmetic numerical value. > > At most what you could have is a separate > > std::ostream& operator<<(std::ostream&, YourRationalClass); > > function for outputting the value to a std::ostream. > if you read the two lines right before the one here reported you can see I did that. I wrote that function to give an extensive description of a rational number in a way like this: "4/16 reduces to 1/4 and evaluates to 0.25" thank you, alessandro
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-17 11:16 +0000 |
| Message-ID | <si1tdv$j0a$1@gioia.aioe.org> |
| In reply to | #81286 |
alessandro volturno <alessandro.volturno@libero.it> wrote: > Il 17/09/2021 07:36, Juha Nieminen ha scritto: >> alessandro volturno <alessandro.volturno@libero.it> wrote: >>> printDescription() // prints a description of the number and its >>> // numerical value >> >> This is not really something that belongs to a class that behaves like an >> arithmetic numerical value. >> >> At most what you could have is a separate >> >> std::ostream& operator<<(std::ostream&, YourRationalClass); >> >> function for outputting the value to a std::ostream. >> > > if you read the two lines right before the one here reported you can see > I did that. > > I wrote that function to give an extensive description of a rational > number in a way like this: > > "4/16 reduces to 1/4 and evaluates to 0.25" I still think that designwise such a function does not belong in that class. Sure, nobody is stopping you from adding such functions to your class, if and when you want to use just in your own small projects, but generally, when designing such classes for general use for a wider audience and a wider set of applications, that's just not something that logically belongs to such a class. A class that behaves like a numerical value shouldn't itself print anything, because that doesn't make much logical sense. You could have separate functions that do that, but they don't belong as members of the class. Even when you do implement something like an operator<<(std::ostream&) for the class, its output should just be an ascii representation of the number itself, and nothing else. If you want to provide such printing functions for convenience, you could implement them as separate functions (maybe even declared in their own separate header file). Note, however, that you will be fixing the format (and language) of such messages, which is one of the reasons why it's not something you usually want to do. Let the user of the class decide how such things are printed, rather than the library forcing a particular format (and language). (After all, it's not such a huge amount of work to write a simple printing line which uses values from the instance of the class.)
[toc] | [prev] | [next] | [standalone]
| From | alessandro volturno <alessandro.volturno@libero.it> |
|---|---|
| Date | 2021-09-17 18:33 +0200 |
| Message-ID | <si2g22$1pnr$1@gioia.aioe.org> |
| In reply to | #81290 |
Il 17/09/2021 13:16, Juha Nieminen ha scritto: > I still think that designwise such a function does not belong in that class. You are right, but the project started as a game and it is not intentended to leave my PC :-) > Sure, nobody is stopping you from adding such functions to your class, if > and when you want to use just in your own small projects, but generally, > when designing such classes for general use for a wider audience and a > wider set of applications, that's just not something that logically > belongs to such a class. > > A class that behaves like a numerical value shouldn't itself print > anything, because that doesn't make much logical sense. You could have > separate functions that do that, but they don't belong as members of > the class. you were perfectly clear, thank you for that. alessandro
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-10-06 13:06 -0700 |
| Message-ID | <86ee8xrk8n.fsf@linuxsc.com> |
| In reply to | #81290 |
Juha Nieminen <nospam@thanks.invalid> writes: > alessandro volturno <alessandro.volturno@libero.it> wrote: > >> Il 17/09/2021 07:36, Juha Nieminen ha scritto: >> >>> alessandro volturno <alessandro.volturno@libero.it> wrote: >>> >>>> printDescription() // prints a description of the number and its >>>> // numerical value >>> >>> This is not really something that belongs to a class that behaves >>> like an arithmetic numerical value. >>> >>> At most what you could have is a separate >>> >>> std::ostream& operator<<(std::ostream&, YourRationalClass); >>> >>> function for outputting the value to a std::ostream. >> >> if you read the two lines right before the one here reported you >> can see I did that. >> >> I wrote that function to give an extensive description of a >> rational number in a way like this: >> >> "4/16 reduces to 1/4 and evaluates to 0.25" > > I still think that designwise such a function does not belong in > that class. That depends on exactly what the function does. If the function depends on the object's internal representation or on invariants that are not publically available, then certainly defining the function as a member function is a more natural choice.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-17 14:03 +0000 |
| Message-ID | <qe11J.71442$QzOf.28358@fx17.iad> |
| In reply to | #81283 |
Juha Nieminen <nospam@thanks.invalid> writes:
>alessandro volturno <alessandro.volturno@libero.it> wrote:
>> printDescription() // prints a description of the number and its
>> // numerical value
>
>This is not really something that belongs to a class that behaves like an
>arithmetic numerical value.
>
>At most what you could have is a separate
>
> std::ostream& operator<<(std::ostream&, YourRationalClass);
>
>function for outputting the value to a std::ostream.
I could rant for hours on the unsuitability of the silly
C++ output stream crap in real applications.
But I've got too much on my plate right now. Much of which
is making performance improvements to a large CPU-bound
C++ application; primarily by getting rid of all outputstringstream
crap (replacing with snprintf) and eliminating most trivial
run-time (vs. startup time) uses of std::string.
void
a(void)
{
std::string fred = "this is a test";
printf("%s", fred.c_str());
}
0000000000400970 <a()>:
400970: 53 push %rbx
400971: be 50 0b 40 00 mov $0x400b50,%esi
400976: 48 83 ec 20 sub $0x20,%rsp
40097a: 48 8d 7c 24 10 lea 0x10(%rsp),%rdi
40097f: 48 8d 54 24 0f lea 0xf(%rsp),%rdx
400984: e8 97 fe ff ff callq 400820 <std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)@plt>
400989: 48 8b 74 24 10 mov 0x10(%rsp),%rsi
40098e: bf 5f 0b 40 00 mov $0x400b5f,%edi
400993: 31 c0 xor %eax,%eax
400995: e8 36 fe ff ff callq 4007d0 <printf@plt>
40099a: 48 8b 44 24 10 mov 0x10(%rsp),%rax
40099f: 48 8d 78 e8 lea -0x18(%rax),%rdi
4009a3: 48 81 ff 80 10 60 00 cmp $0x601080,%rdi
4009aa: 75 06 jne 4009b2 <a()+0x42>
4009ac: 48 83 c4 20 add $0x20,%rsp
4009b0: 5b pop %rbx
4009b1: c3 retq
4009b2: b9 00 00 00 00 mov $0x0,%ecx
4009b7: 48 8d 57 10 lea 0x10(%rdi),%rdx
4009bb: 48 85 c9 test %rcx,%rcx
4009be: 74 35 je 4009f5 <a()+0x85>
4009c0: 83 c8 ff or $0xffffffff,%eax
4009c3: f0 0f c1 02 lock xadd %eax,(%rdx)
4009c7: 85 c0 test %eax,%eax
4009c9: 7f e1 jg 4009ac <a()+0x3c>
4009cb: 48 8d 74 24 0f lea 0xf(%rsp),%rsi
4009d0: e8 3b fe ff ff callq 400810 <std::string::_Rep::_M_destroy(std::allocator<char> const&)@plt>
4009d5: eb d5 jmp 4009ac <a()+0x3c>
4009d7: 48 89 c3 mov %rax,%rbx
4009da: 48 8b 44 24 10 mov 0x10(%rsp),%rax
4009df: 48 8d 74 24 0f lea 0xf(%rsp),%rsi
4009e4: 48 8d 78 e8 lea -0x18(%rax),%rdi
4009e8: e8 03 fe ff ff callq 4007f0 <std::string::_Rep::_M_dispose(std::allocator<char> const&)@plt>
4009ed: 48 89 df mov %rbx,%rdi
4009f0: e8 5b fe ff ff callq 400850 <_Unwind_Resume@plt>
4009f5: 8b 50 f8 mov -0x8(%rax),%edx
4009f8: 8d 4a ff lea -0x1(%rdx),%ecx
4009fb: 89 48 f8 mov %ecx,-0x8(%rax)
4009fe: 89 d0 mov %edx,%eax
400a00: eb c5 jmp 4009c7 <a()+0x57>
400a02: 66 66 66 66 66 2e 0f data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1)
400a09: 1f 84 00 00 00 00 00
(and that's _with_ -O3).
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2021-09-17 17:12 +0200 |
| Message-ID | <si2b9u$q1u$1@dont-email.me> |
| In reply to | #81293 |
Am 17.09.21 um 16:03 schrieb Scott Lurndal:
> Juha Nieminen <nospam@thanks.invalid> writes:
>> alessandro volturno <alessandro.volturno@libero.it> wrote:
>>> printDescription() // prints a description of the number and its
>>> // numerical value
>>
>> This is not really something that belongs to a class that behaves like an
>> arithmetic numerical value.
>>
>> At most what you could have is a separate
>>
>> std::ostream& operator<<(std::ostream&, YourRationalClass);
>>
>> function for outputting the value to a std::ostream.
>
> I could rant for hours on the unsuitability of the silly
> C++ output stream crap in real applications.
>
> But I've got too much on my plate right now. Much of which
> is making performance improvements to a large CPU-bound
> C++ application; primarily by getting rid of all outputstringstream
> crap (replacing with snprintf) and eliminating most trivial
> run-time (vs. startup time) uses of std::string.
>
> void
> a(void)
> {
> std::string fred = "this is a test";
> printf("%s", fred.c_str());
> }
>
> [...long assembly...]
Wow, thats an awful lot of code. Does it improve if you do const
std::string or constexpr or the like?
Christian
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2021-09-17 17:16 +0200 |
| Message-ID | <si2bhj$uvc$1@dont-email.me> |
| In reply to | #81295 |
Am 17.09.21 um 17:12 schrieb Christian Gollwitzer:
> Am 17.09.21 um 16:03 schrieb Scott Lurndal:
>> Juha Nieminen <nospam@thanks.invalid> writes:
>>> alessandro volturno <alessandro.volturno@libero.it> wrote:
>>>> printDescription() // prints a description of the number and its
>>>> // numerical value
>>>
>>> This is not really something that belongs to a class that behaves
>>> like an
>>> arithmetic numerical value.
>>>
>>> At most what you could have is a separate
>>>
>>> std::ostream& operator<<(std::ostream&, YourRationalClass);
>>>
>>> function for outputting the value to a std::ostream.
>>
>> I could rant for hours on the unsuitability of the silly
>> C++ output stream crap in real applications.
>>
>> But I've got too much on my plate right now. Much of which
>> is making performance improvements to a large CPU-bound
>> C++ application; primarily by getting rid of all outputstringstream
>> crap (replacing with snprintf) and eliminating most trivial
>> run-time (vs. startup time) uses of std::string.
>>
>> void
>> a(void)
>> {
>> std::string fred = "this is a test";
>> printf("%s", fred.c_str());
>> }
>>
>> [...long assembly...]
>
> Wow, thats an awful lot of code. Does it improve if you do const
> std::string or constexpr or the like?
>
> Christian
Quick test on compiler explorer shows a much more reasonable code:
https://godbolt.org/z/5MzscK95W
with gcc 11.
Christian
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-09-17 18:59 +0200 |
| Message-ID | <si2hib$bp5$1@gioia.aioe.org> |
| In reply to | #81296 |
On 9/17/2021 5:16 PM, Christian Gollwitzer wrote:
> Am 17.09.21 um 17:12 schrieb Christian Gollwitzer:
>> Am 17.09.21 um 16:03 schrieb Scott Lurndal:
>>> Juha Nieminen <nospam@thanks.invalid> writes:
>>>> alessandro volturno <alessandro.volturno@libero.it> wrote:
>>>>> printDescription() // prints a description of the number and its
>>>>> // numerical value
>>>>
>>>> This is not really something that belongs to a class that behaves
>>>> like an
>>>> arithmetic numerical value.
>>>>
>>>> At most what you could have is a separate
>>>>
>>>> std::ostream& operator<<(std::ostream&, YourRationalClass);
>>>>
>>>> function for outputting the value to a std::ostream.
>>>
>>> I could rant for hours on the unsuitability of the silly
>>> C++ output stream crap in real applications.
>>>
>>> But I've got too much on my plate right now. Much of which
>>> is making performance improvements to a large CPU-bound
>>> C++ application; primarily by getting rid of all outputstringstream
>>> crap (replacing with snprintf) and eliminating most trivial
>>> run-time (vs. startup time) uses of std::string.
>>>
>>> void
>>> a(void)
>>> {
>>> std::string fred = "this is a test";
>>> printf("%s", fred.c_str());
>>> }
>>>
>>> [...long assembly...]
>>
>> Wow, thats an awful lot of code. Does it improve if you do const
>> std::string or constexpr or the like?
>>
>> Christian
>
> Quick test on compiler explorer shows a much more reasonable code:
> https://godbolt.org/z/5MzscK95W
>
> with gcc 11.
>
> Christian
Still,
Feeding a C string to a std::string to be fed to printf() /is/ masochism
(or sadism, depending on which side you are on).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-17 17:13 +0000 |
| Message-ID | <d141J.660$fZ.598@fx06.iad> |
| In reply to | #81300 |
Manfred <noname@add.invalid> writes:
>On 9/17/2021 5:16 PM, Christian Gollwitzer wrote:
>> Am 17.09.21 um 17:12 schrieb Christian Gollwitzer:
>>> Am 17.09.21 um 16:03 schrieb Scott Lurndal:
>>>> Juha Nieminen <nospam@thanks.invalid> writes:
>>>>> alessandro volturno <alessandro.volturno@libero.it> wrote:
>>>>>> printDescription() // prints a description of the number and its
>>>>>> // numerical value
>>>>>
>>>>> This is not really something that belongs to a class that behaves
>>>>> like an
>>>>> arithmetic numerical value.
>>>>>
>>>>> At most what you could have is a separate
>>>>>
>>>>> std::ostream& operator<<(std::ostream&, YourRationalClass);
>>>>>
>>>>> function for outputting the value to a std::ostream.
>>>>
>>>> I could rant for hours on the unsuitability of the silly
>>>> C++ output stream crap in real applications.
>>>>
>>>> But I've got too much on my plate right now. Much of which
>>>> is making performance improvements to a large CPU-bound
>>>> C++ application; primarily by getting rid of all outputstringstream
>>>> crap (replacing with snprintf) and eliminating most trivial
>>>> run-time (vs. startup time) uses of std::string.
>>>>
>>>> void
>>>> a(void)
>>>> {
>>>> std::string fred = "this is a test";
>>>> printf("%s", fred.c_str());
>>>> }
>>>>
>>>> [...long assembly...]
>>>
>>> Wow, thats an awful lot of code. Does it improve if you do const
>>> std::string or constexpr or the like?
>>>
>>> Christian
>>
>> Quick test on compiler explorer shows a much more reasonable code:
>> https://godbolt.org/z/5MzscK95W
>>
>> with gcc 11.
>>
>> Christian
>
>Still,
>
>Feeding a C string to a std::string to be fed to printf() /is/ masochism
>(or sadism, depending on which side you are on).
One quite often runs across C++ purists (or new grads) who falsly eschew
C constructs as "not C++".
Unfortunately, we need to support GCC4 through GCC11 efficiently.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-19 10:17 +0000 |
| Message-ID | <si72nv$rme$1@gioia.aioe.org> |
| In reply to | #81301 |
Scott Lurndal <scott@slp53.sl.home> wrote: > One quite often runs across C++ purists (or new grads) who falsly eschew > C constructs as "not C++". My response to them is that "if it's in the C++ standard, then it's C++, through and through. Use the tools that are best for the task at hand." Just because something is "inherited" from C (so to speak) doesn't mean it's not suitable and perfectly valid to use in C++. After all, keywords like 'for' and 'if' are inherited from C. Does that mean they shouldn't be used in C++? Why is using those ok, but eg. using std::printf() is not? What's the difference? > Unfortunately, we need to support GCC4 through GCC11 efficiently. I find it fascinating how common gcc 4 is still out there in the wild, even to this day. It kind of has taken the mantle of gcc 2, which likewise was in very wide use years and years after it had become completely obsolete and antiquated (as, IIRC, it didn't even support 100% of C++98.) The difference is that gcc 4 has persisted for a *lot* longer than gcc 2 did. I blame certain Linux distros for this.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-19 14:07 +0000 |
| Message-ID | <TuH1J.16886$dI3.146@fx10.iad> |
| In reply to | #81323 |
Juha Nieminen <nospam@thanks.invalid> writes: >Scott Lurndal <scott@slp53.sl.home> wrote: >> One quite often runs across C++ purists (or new grads) who falsly eschew >> C constructs as "not C++". > >My response to them is that "if it's in the C++ standard, then it's C++, >through and through. Use the tools that are best for the task at hand." > >Just because something is "inherited" from C (so to speak) doesn't mean >it's not suitable and perfectly valid to use in C++. After all, keywords >like 'for' and 'if' are inherited from C. Does that mean they shouldn't >be used in C++? Why is using those ok, but eg. using std::printf() is not? >What's the difference? > >> Unfortunately, we need to support GCC4 through GCC11 efficiently. > >I find it fascinating how common gcc 4 is still out there in the wild, >even to this day. It is the default compiler for Redhat 6 and Redhat 7 (and thus the deriviations such as CentOS) which are widely used. > >I blame certain Linux distros for this. I wouldn't use the verb "blame" here. Most programmers don't particularly care about the version of the compiler, so long as it works.
[toc] | [prev] | [next] | [standalone]
Page 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
Back to top | Article view | comp.lang.c++
csiph-web