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 1 of 12 [1] 2 3 … 12 Next page →
| From | alessandro volturno <alessandro.volturno@libero.it> |
|---|---|
| Date | 2021-09-16 14:59 +0200 |
| Subject | rational numbers |
| Message-ID | <shvf4c$ark$3@gioia.aioe.org> |
Hello group,
I am writing some C++ code to implement a class that handles fractional
numbers.
C++11 has the Ratio facility, but it is not possible to instantiate
Ratio objects or pass them to functions (at least I was not able to do
that), so just for fun I started a simple rational class, adding the
following:
private members *num* and *den*
constructor;
destructor; // defaulted
copy assignment operator // defaulted
copy constructor // defaulted
move assignment operator // defaulted
move constructor // defaulted
operator+ ()
operator- ()
operator* ()
operator/ ()
operator== ()
operator!= ()
friend operator<= ()
friend operator< ()
friend operator> ()
friend operator>= ()
friend operator<< ()
friend operator>> ()
printDescription() // prints a description of the number and its
// numerical value
reduce() // simplifies a fraction using a static GCD function
reciprocal() // inverts a rational number
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?
[toc] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-16 16:40 +0300 |
| Message-ID | <shvhfq$mt2$1@dont-email.me> |
| In reply to | #81271 |
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? 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. 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. Nevertheless, there is at least one proposal to include rationals in the standard, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3363.html Meanwhile one can use the Boost Rational library.
[toc] | [prev] | [next] | [standalone]
| From | alessandro volturno <alessandro.volturno@libero.it> |
|---|---|
| Date | 2021-09-16 18:24 +0200 |
| Message-ID | <shvr5o$ovs$1@gioia.aioe.org> |
| In reply to | #81272 |
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. > 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. True that C++ applications can be built for every available hardware configuration (and so they can be run on older or slower cpus), but rational are an important class of numbers and its family is wider than integers' > Nevertheless, there is at least one proposal to include rationals in the > standard, see > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3363.html The proposal you presented is quite dated, so I presume many talkings have been made about it. I don't know the reason why, but it evidently came out not to add this feature to the language. Many computer languages are evolving and new ones are born every one or two years. In my opinion, to keep a language competitive with respect to the others around, that language should also permit basic number manipulation as easier as possible. I repeat myself, I'm a hobbyist, spare-time programmer, but as complex numbers have been added to C++, so there should be some mechanics to handle rationals. > Meanwhile one can use the Boost Rational library. I've heard about the Boost library but I've never made an attempt to study it nor to use it. My projects are small ones and I write them by scratch just for the sake of knowing how I progress in this discipline (computer programming). Thank you for your kind reply, alessandro
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-16 17:05 +0000 |
| Message-ID | <3PK0J.78848$g81.78219@fx33.iad> |
| In reply to | #81273 |
alessandro volturno <alessandro.volturno@libero.it> writes: >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. I suspect that the vast majority of people use existing software packages like Matlab or R (for statistics) than write C++ code for numerical software nowadays. It's really hard to get it right when using binary floating point, hence standard numerical libraries (LINPACK, et alia). https://en.wikipedia.org/wiki/List_of_numerical_libraries
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-09-16 19:58 +0200 |
| Message-ID | <si00jj$1h9q$1@gioia.aioe.org> |
| In reply to | #81274 |
On 9/16/2021 7:05 PM, Scott Lurndal wrote: > alessandro volturno <alessandro.volturno@libero.it> writes: >> 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. > > I suspect that the vast majority of people use existing > software packages like Matlab or R (for statistics) than write C++ code > for numerical software nowadays. It's really hard to get it > right when using binary floating point, hence standard numerical > libraries (LINPACK, et alia). > > https://en.wikipedia.org/wiki/List_of_numerical_libraries > It is true that numerical analysis is easier in Matlab than C++, but I think the main point is that, if you know what you are doing, standard floating point and integer types can cover the a lot of application use even when writing C++ (as well as C) programs. The main advantage of rational arithmetic is that it allows an exact representation of a significant class of numbers, without rounding errors. But in many practical applications (engineering, automation, ...) 16 significant digits (as offered by the 'double' type) yield rounding errors that are small enough. It is true, though, that specific knowledge is required - naive code can easily yield garbage. The limitation that I see with digital rationals, without having read the linked proposal, is that they would still represent a limited subset of the rational numbers, which is a limitation for theoretical analysis - in addition, output results can be exact only if inputs are exact rationals numbers, which rules out all physical quantities, a limitation of the advantage over floating point math. In short, it is understandable that there is not enough motivation to include this as a native type in the language, compared to what is already available through libraries.
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2021-09-17 09:21 +0200 |
| Message-ID | <si1fl2$k9o$1@dont-email.me> |
| In reply to | #81274 |
Am 16.09.21 um 19:05 schrieb Scott Lurndal: > I suspect that the vast majority of people use existing > software packages like Matlab or R (for statistics) than write C++ code > for numerical software nowadays. It's really hard to get it > right when using binary floating point, hence standard numerical > libraries (LINPACK, et alia). I am a scientist, and Matlab and R are popular, but slowly they give way to Python. With the "numpy" package wrapping LAPACK and "scipy", which is based on it, Python code almost looks like Matlab, but it's completely open source. To my understanding, that and the machine learning libs are the reasons why Python gained so much in the last years. The language on its own is not that much better than other modern scripting languages, it's the libraries with a large user base. Christian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-17 10:34 +0200 |
| Message-ID | <si1jvi$en8$1@dont-email.me> |
| In reply to | #81284 |
On 17/09/2021 09:21, Christian Gollwitzer wrote: > > Am 16.09.21 um 19:05 schrieb Scott Lurndal: >> I suspect that the vast majority of people use existing >> software packages like Matlab or R (for statistics) than write C++ code >> for numerical software nowadays. It's really hard to get it >> right when using binary floating point, hence standard numerical >> libraries (LINPACK, et alia). > > I am a scientist, and Matlab and R are popular, but slowly they give way > to Python. With the "numpy" package wrapping LAPACK and "scipy", which > is based on it, Python code almost looks like Matlab, but it's > completely open source. To my understanding, that and the machine > learning libs are the reasons why Python gained so much in the last > years. The language on its own is not that much better than other modern > scripting languages, it's the libraries with a large user base. > Python might not be much better than Matlab as a language for the numerical bits (I haven't done Matlab programming to compare), but as a general purpose language it is vastly more powerful for everything else than highly specialised and consequently limited tools like Matlab. All the extra capabilities from Python, such sending emails when your calculations are done, interacting with databases, generating pdf reports from the results, etc., are going to make it a lot more attractive if it can handle the maths you need.
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2021-09-17 15:55 +0200 |
| Message-ID | <si26oc$n9k$1@dont-email.me> |
| In reply to | #81287 |
Am 17.09.21 um 10:34 schrieb David Brown: > On 17/09/2021 09:21, Christian Gollwitzer wrote: >> >> Am 16.09.21 um 19:05 schrieb Scott Lurndal: >>> I suspect that the vast majority of people use existing >>> software packages like Matlab or R (for statistics) than write C++ code >>> for numerical software nowadays. It's really hard to get it >>> right when using binary floating point, hence standard numerical >>> libraries (LINPACK, et alia). >> >> I am a scientist, and Matlab and R are popular, but slowly they give way >> to Python. With the "numpy" package wrapping LAPACK and "scipy", which >> is based on it, Python code almost looks like Matlab, but it's >> completely open source. To my understanding, that and the machine >> learning libs are the reasons why Python gained so much in the last >> years. The language on its own is not that much better than other modern >> scripting languages, it's the libraries with a large user base. >> > > Python might not be much better than Matlab as a language for the > numerical bits (I haven't done Matlab programming to compare), but as a > general purpose language it is vastly more powerful for everything else > than highly specialised and consequently limited tools like Matlab. I agree, and maybe I wasn't clearly expressing myself. Matlab has a little edge if one does linear algebra stuff. There are some weird extra parentheses in numpy sometimes (e.g. numpy.zeros((3,4)) vs zeros(3,4) in Matlab), numpy does not distinguish row and column vectors and therefore leads to more cumbersome code for matrix multiplications, and literals also look cleaner in Matlab. In addition, the documentation of Matlab and the toolboxes is really high standard, commercial quality and well maintained whereas in Scipy you can often see that it is more of a "hobbyist" thing. But these are minor disadvantages of Python that are a bit annoying in interactive use like Jupyter notebooks and not real show-stoppers. > All > the extra capabilities from Python, such sending emails when your > calculations are done, interacting with databases, generating pdf > reports from the results, etc., are going to make it a lot more > attractive if it can handle the maths you need. OTOH, Matlab is a terrible general purpose language. They have bolted on to that matrix language everything, you *can* use object orientation, general I/O, GUIs and also send emails https://www.mathworks.com/help/matlab/import_export/sending-email.html connect databases https://www.mathworks.com/help/database/ug/odbc.html and create PDFs https://www.mathworks.com/help/rptgen/ug/create-an-html-or-pdf-template.html but it often looks quirky and not like a language I would want to write a larger program in. Python was constructed as a sane language to begin with, but so have been Lua, Julia, Ruby, Kotlin, and surely dozens of others. Why Python has become the Nr#1? I suspect that as soon as scientists picked it up with numpy it grew as an alternative to the de-facto standard Matlab simply because it was free. And then the machine learning guys really boosted it to a point where it couldn't be ignored any longer. The same happened years ago with Tcl. Python and Tcl are almost the same age. Due to Tk, which allowed non-guru-level programmers to make simple GUIs and the adoption of the circuit CAD industry, Tcl became the de-facto scripting standard for many years. The decline came with the stall of development (Sun pulled the money out) and the main focus has shifted away from desktop GUI and circuit board designers. Now it's Python that everyone uses and recommends. Christian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-17 17:49 +0200 |
| Message-ID | <si2df7$s1t$1@dont-email.me> |
| In reply to | #81292 |
On 17/09/2021 15:55, Christian Gollwitzer wrote: > Am 17.09.21 um 10:34 schrieb David Brown: >> On 17/09/2021 09:21, Christian Gollwitzer wrote: >>> Am 16.09.21 um 19:05 schrieb Scott Lurndal: >>>> I suspect that the vast majority of people use existing >>>> software packages like Matlab or R (for statistics) than write C++ code >>>> for numerical software nowadays. It's really hard to get it >>>> right when using binary floating point, hence standard numerical >>>> libraries (LINPACK, et alia). >>> >>> I am a scientist, and Matlab and R are popular, but slowly they give way >>> to Python. With the "numpy" package wrapping LAPACK and "scipy", which >>> is based on it, Python code almost looks like Matlab, but it's >>> completely open source. To my understanding, that and the machine >>> learning libs are the reasons why Python gained so much in the last >>> years. The language on its own is not that much better than other modern >>> scripting languages, it's the libraries with a large user base. >>> >> >> Python might not be much better than Matlab as a language for the >> numerical bits (I haven't done Matlab programming to compare), but as a >> general purpose language it is vastly more powerful for everything else >> than highly specialised and consequently limited tools like Matlab. > > I agree, and maybe I wasn't clearly expressing myself. Matlab has a > little edge if one does linear algebra stuff. There are some weird extra > parentheses in numpy sometimes (e.g. numpy.zeros((3,4)) vs zeros(3,4) in > Matlab), numpy does not distinguish row and column vectors and therefore > leads to more cumbersome code for matrix multiplications, and literals > also look cleaner in Matlab. In addition, the documentation of Matlab > and the toolboxes is really high standard, commercial quality and well > maintained whereas in Scipy you can often see that it is more of a > "hobbyist" thing. > > But these are minor disadvantages of Python that are a bit annoying in > interactive use like Jupyter notebooks and not real show-stoppers. > >> All >> the extra capabilities from Python, such sending emails when your >> calculations are done, interacting with databases, generating pdf >> reports from the results, etc., are going to make it a lot more >> attractive if it can handle the maths you need. > > > OTOH, Matlab is a terrible general purpose language. They have bolted on > to that matrix language everything, you *can* use object orientation, > general I/O, GUIs and also send emails > https://www.mathworks.com/help/matlab/import_export/sending-email.html > connect databases https://www.mathworks.com/help/database/ug/odbc.html > and create PDFs > https://www.mathworks.com/help/rptgen/ug/create-an-html-or-pdf-template.html > but it often looks quirky and not like a language I would want to write > a larger program in. > > Python was constructed as a sane language to begin with, but so have > been Lua, Julia, Ruby, Kotlin, and surely dozens of others. Why Python > has become the Nr#1? I suspect that as soon as scientists picked it up > with numpy it grew as an alternative to the de-facto standard Matlab > simply because it was free. And then the machine learning guys really > boosted it to a point where it couldn't be ignored any longer. > Lua, Julia, Ruby, etc., are also free. But Python was there first, and I think momentum has a lot to do with it. It's also a higher level language than, say, Lua, and while there are some mixed opinions on some aspects of Python's syntax, it is generally regarded as a easier to read, write and learn than Ruby and many alternatives. > The same happened years ago with Tcl. Python and Tcl are almost the same > age. Due to Tk, which allowed non-guru-level programmers to make simple > GUIs and the adoption of the circuit CAD industry, Tcl became the > de-facto scripting standard for many years. The decline came with the > stall of development (Sun pulled the money out) and the main focus has > shifted away from desktop GUI and circuit board designers. Now it's > Python that everyone uses and recommends. > Tcl is okay as a "tool control language", but it is far too weak for more advanced work. Python was considered too "heavy" for simple scripting in many areas - but as everything else (disks, memory, cpus, etc.) has got bigger, the relative cost of Python has dropped.
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2021-09-17 18:22 +0200 |
| Message-ID | <si2fcp$pkp$1@dont-email.me> |
| In reply to | #81297 |
Am 17.09.21 um 17:49 schrieb David Brown: > On 17/09/2021 15:55, Christian Gollwitzer wrote: > Tcl is okay as a "tool control language", but it is far too weak for > more advanced work. To be fair, one must say "has been". Tcl has improved since the days back then and acquired many modern things like coroutines, built-in object orientation etc. but the development went on a very slow path after the support from Sun was dropped. I'm one of the inhabitants of a small Gallic village ;) this is one of my projects realized in modern Tcl: https://github.com/BessyHDFViewer/BessyHDFViewer But the world has moved on, and now I'm recommending Pyton to everyone who needs a programming language as the first pick. C++ comes second, if speed is required or special hardware control etc. Of course, as a scientist my environment is data analysis and lab hardware control. On embedded devices the ranking would be different. Christian
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-17 22:07 +1200 |
| Message-ID | <iqj7miFb6apU1@mid.individual.net> |
| In reply to | #81284 |
On 17/09/2021 19:21, Christian Gollwitzer wrote: > > Am 16.09.21 um 19:05 schrieb Scott Lurndal: >> I suspect that the vast majority of people use existing >> software packages like Matlab or R (for statistics) than write C++ code >> for numerical software nowadays. It's really hard to get it >> right when using binary floating point, hence standard numerical >> libraries (LINPACK, et alia). > > I am a scientist, and Matlab and R are popular, but slowly they give way > to Python. With the "numpy" package wrapping LAPACK and "scipy", which > is based on it, Python code almost looks like Matlab, but it's > completely open source. To my understanding, that and the machine > learning libs are the reasons why Python gained so much in the last > years. The language on its own is not that much better than other modern > scripting languages, it's the libraries with a large user base. Matlab does have one advantage (at least in our environment); it can convert models into C++ code! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-17 13:32 +0200 |
| Message-ID | <si1ucn$rki$1@dont-email.me> |
| In reply to | #81289 |
On 17/09/2021 12:07, Ian Collins wrote: > On 17/09/2021 19:21, Christian Gollwitzer wrote: >> >> Am 16.09.21 um 19:05 schrieb Scott Lurndal: >>> I suspect that the vast majority of people use existing >>> software packages like Matlab or R (for statistics) than write C++ code >>> for numerical software nowadays. It's really hard to get it >>> right when using binary floating point, hence standard numerical >>> libraries (LINPACK, et alia). >> >> I am a scientist, and Matlab and R are popular, but slowly they give way >> to Python. With the "numpy" package wrapping LAPACK and "scipy", which >> is based on it, Python code almost looks like Matlab, but it's >> completely open source. To my understanding, that and the machine >> learning libs are the reasons why Python gained so much in the last >> years. The language on its own is not that much better than other modern >> scripting languages, it's the libraries with a large user base. > > Matlab does have one advantage (at least in our environment); it can > convert models into C++ code! > A few times in the past, I've seen C code generated by Matlab, produced by researchers who then wanted the whole think running in a little microcontroller. The generated code was utterly hideous - vastly over-complex, and ridiculous inefficiencies (malloc allocation for things that should be local stack variables, multiplying integers by 0.5 instead of dividing by 2, using strings and strcmp() instead of enums, etc.). But perhaps it was the user rather than the software that was at fault - it's not a tool I use myself. I just know that for use on a small microcontroller, I'd rather hand-translate some well-written Python than clear up the vomit that Matlab produced.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-18 09:15 +1200 |
| Message-ID | <iqkeraFb6apU2@mid.individual.net> |
| In reply to | #81291 |
On 17/09/2021 23:32, David Brown wrote: > On 17/09/2021 12:07, Ian Collins wrote: >> On 17/09/2021 19:21, Christian Gollwitzer wrote: >>> >>> Am 16.09.21 um 19:05 schrieb Scott Lurndal: >>>> I suspect that the vast majority of people use existing >>>> software packages like Matlab or R (for statistics) than write C++ code >>>> for numerical software nowadays. It's really hard to get it >>>> right when using binary floating point, hence standard numerical >>>> libraries (LINPACK, et alia). >>> >>> I am a scientist, and Matlab and R are popular, but slowly they give way >>> to Python. With the "numpy" package wrapping LAPACK and "scipy", which >>> is based on it, Python code almost looks like Matlab, but it's >>> completely open source. To my understanding, that and the machine >>> learning libs are the reasons why Python gained so much in the last >>> years. The language on its own is not that much better than other modern >>> scripting languages, it's the libraries with a large user base. >> >> Matlab does have one advantage (at least in our environment); it can >> convert models into C++ code! >> > > A few times in the past, I've seen C code generated by Matlab, produced > by researchers who then wanted the whole think running in a little > microcontroller. The generated code was utterly hideous - vastly > over-complex, and ridiculous inefficiencies (malloc allocation for > things that should be local stack variables, multiplying integers by 0.5 > instead of dividing by 2, using strings and strcmp() instead of enums, > etc.). But perhaps it was the user rather than the software that was at > fault - it's not a tool I use myself. I just know that for use on a > small microcontroller, I'd rather hand-translate some well-written > Python than clear up the vomit that Matlab produced. The generated code isn't great, but with a little care in the model, it isn't too bad either. I liken the process to the hand optimisations we used to do in C to get the best from 80's vintage compilers! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-17 14:06 +0000 |
| Message-ID | <Sh11J.71443$QzOf.36580@fx17.iad> |
| In reply to | #81289 |
Ian Collins <ian-news@hotmail.com> writes: >On 17/09/2021 19:21, Christian Gollwitzer wrote: >> >> Am 16.09.21 um 19:05 schrieb Scott Lurndal: >>> I suspect that the vast majority of people use existing >>> software packages like Matlab or R (for statistics) than write C++ code >>> for numerical software nowadays. It's really hard to get it >>> right when using binary floating point, hence standard numerical >>> libraries (LINPACK, et alia). >> >> I am a scientist, and Matlab and R are popular, but slowly they give way >> to Python. With the "numpy" package wrapping LAPACK and "scipy", which >> is based on it, Python code almost looks like Matlab, but it's >> completely open source. To my understanding, that and the machine >> learning libs are the reasons why Python gained so much in the last >> years. The language on its own is not that much better than other modern >> scripting languages, it's the libraries with a large user base. > >Matlab does have one advantage (at least in our environment); it can >convert models into C++ code! One of my colleagues wrote a tool (verilator) to convert Verilog into C++ code. Quite useful. https://en.wikipedia.org/wiki/Verilator
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-16 20:41 +0200 |
| Message-ID | <si035k$kma$1@dont-email.me> |
| In reply to | #81273 |
On 16/09/2021 18:24, alessandro volturno wrote: > Il 16/09/2021 15:40, Paavo Helde ha scritto: > >> 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. > > True that C++ applications can be built for every available hardware > configuration (and so they can be run on older or slower cpus), but > rational are an important class of numbers and its family is wider than > integers' There are two key difficulties about constructive use of rationals. One is that you have to handle reduction by greatest common denominator - that is not a simple operation, but is time-consuming and has unpredictable timing. The other is that the sizes of the denominator and numerator very quickly get very big for all but the simplest of calculations - you don't have to do a lot with them before the arithmetic becomes impossible within the fixed size framework. (This is in comparison to complex numbers, which are easy.) Basically, I don't think there is that much need of rationals of fixed size - you can usually make do with floating point or integers, or you need arbitrary precision. Rationals are very important in mathematics, much less so in practical programming. However, as a hobby task, a good set of rational number classes would be great fun to work on. You can start with a basic implementation, then work on a templated version handling different sizes, learn about concepts with a practical use-case, figure how to make everything constexpr, get neat ways to make bigger fixed-size rational types, explore ways to handle overflows. The scope for enjoyment and learning is huge here.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-16 21:11 +0100 |
| Message-ID | <si08ef$s0c$1@dont-email.me> |
| In reply to | #81276 |
On 16/09/2021 19:41, David Brown wrote: > On 16/09/2021 18:24, alessandro volturno wrote: >> Il 16/09/2021 15:40, Paavo Helde ha scritto: >> >>> 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. >> >> True that C++ applications can be built for every available hardware >> configuration (and so they can be run on older or slower cpus), but >> rational are an important class of numbers and its family is wider than >> integers' > > There are two key difficulties about constructive use of rationals. One > is that you have to handle reduction by greatest common denominator - > that is not a simple operation, but is time-consuming and has > unpredictable timing. The other is that the sizes of the denominator > and numerator very quickly get very big for all but the simplest of > calculations - you don't have to do a lot with them before the > arithmetic becomes impossible within the fixed size framework. (This is > in comparison to complex numbers, which are easy.) You get a similar problem with arbitrary precision floats. (At least, in my library. I don't know how others deal with it; I use upper limits on precision). Multiply two numbers with M and N digits of precision respectively, and the result will have M*N digits of precision, without the magnitude necessarily getting bigger. It's worse with divide: just do 1.0/3.0, and it will be calculating 0.3333.... forever (the theoretical limit in mine is 36 billion digits, but it will be aborted, long before). At least with rationals, this can be deferred, or cancelled out if the next thing is to multiply by 3 again. > Basically, I don't think there is that much need of rationals of fixed > size - you can usually make do with floating point or integers, or you > need arbitrary precision. Rationals are very important in mathematics, > much less so in practical programming. > However, as a hobby task, a good set of rational number classes would be > great fun to work on. You can start with a basic implementation, then > work on a templated version handling different sizes, learn about > concepts with a practical use-case, figure how to make everything > constexpr, get neat ways to make bigger fixed-size rational types, > explore ways to handle overflows. The scope for enjoyment and learning > is huge here. I've often reserved a rational type in the languages I create, but have never got round to implementing them. They will usually need a big-integer type for a start. But as you say they are not that practical. How would they be displayed for example; as proper and improper fractions? I get enough grief when my Casio gets stuck in fraction mode and I can't remember how to fix it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-09-16 21:26 +0100 |
| Message-ID | <87pmt8cln8.fsf@bsb.me.uk> |
| In reply to | #81277 |
Bart <bc@freeuk.com> writes: > You get a similar problem with arbitrary precision floats. (At least, > in my library. I don't know how others deal with it; I use upper > limits on precision). > > Multiply two numbers with M and N digits of precision respectively, > and the result will have M*N digits of precision, without the > magnitude necessarily getting bigger. That sounds odd. If it's binary FP, multiplying 2 by 2 need not result in a result with more digits than the already exact operands. Do you always widen the mantissa in a multiplication? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-16 21:54 +0100 |
| Message-ID | <si0auu$cop$1@dont-email.me> |
| In reply to | #81279 |
On 16/09/2021 21:26, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> You get a similar problem with arbitrary precision floats. (At least, >> in my library. I don't know how others deal with it; I use upper >> limits on precision). >> >> Multiply two numbers with M and N digits of precision respectively, >> and the result will have M*N digits of precision, without the >> magnitude necessarily getting bigger. > > That sounds odd. If it's binary FP, multiplying 2 by 2 need not result > in a result with more digits than the already exact operands. Do you > always widen the mantissa in a multiplication? (My library is decimal, but there will be the same issues with binary.) I think I meant M+N, not M*N! And that's approximate. Squaring a single digit 1-9 will result in 1-81, which is 1 or 2 digits. (M*N applies to exponentiation.) In any case, it will increase the number of digits when chaining a lot of multiplications, when you have no upper limit on precision. There is some confusion since digits or bits don't usually exist by themselves, but grouped into words or 'limbs'. Squaring 31 bits of value contained within a 64-bit type yields something that still fits into 64 bits, but may need 61/62 of those bits to represent. But this is about arbitrary precision with multiple words to store results.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2021-09-16 23:07 +0200 |
| Message-ID | <si0bmt$hq3$1@dont-email.me> |
| In reply to | #81279 |
On 16 Sep 2021 22:26, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> You get a similar problem with arbitrary precision floats. (At least, >> in my library. I don't know how others deal with it; I use upper >> limits on precision). >> >> Multiply two numbers with M and N digits of precision respectively, >> and the result will have M*N digits of precision, without the >> magnitude necessarily getting bigger. > > That sounds odd. If it's binary FP, multiplying 2 by 2 need not result > in a result with more digits than the already exact operands. Do you > always widen the mantissa in a multiplication? I think Ben meant to write M + N, not M*N. :-o Consider the product of A = a*r^n and B = b*r^m, where a and b are integers and r is the numeral system radix. You get a result C = A*B = a*b*r^(n+m), where the number of digits of C is roughly (the number of digits of a) + (the number of digits of b). - Alf
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2021-09-16 23:27 +0200 |
| Message-ID | <si0cs3$p2p$1@dont-email.me> |
| In reply to | #81281 |
On 16 Sep 2021 23:07, Alf P. Steinbach wrote: > On 16 Sep 2021 22:26, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> You get a similar problem with arbitrary precision floats. (At least, >>> in my library. I don't know how others deal with it; I use upper >>> limits on precision). >>> >>> Multiply two numbers with M and N digits of precision respectively, >>> and the result will have M*N digits of precision, without the >>> magnitude necessarily getting bigger. >> >> That sounds odd. If it's binary FP, multiplying 2 by 2 need not result >> in a result with more digits than the already exact operands. Do you >> always widen the mantissa in a multiplication? > > I think Ben meant to write M + N, not M*N. :-o > > Consider the product of A = a*r^n and B = b*r^m, where a and b are > integers and r is the numeral system radix. > > You get a result C = A*B = a*b*r^(n+m), where the number of digits of C > is roughly (the number of digits of a) + (the number of digits of b). I evidently meant to write "Bart", not "Ben". Oh well. - Alf
[toc] | [prev] | [next] | [standalone]
Page 1 of 12 [1] 2 3 … 12 Next page →
Back to top | Article view | comp.lang.c++
csiph-web