Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #123317 > unrolled thread
| Started by | luser droog <luser.droog@gmail.com> |
|---|---|
| First post | 2017-11-22 09:39 -0800 |
| Last post | 2017-11-30 23:56 -0600 |
| Articles | 20 on this page of 276 — 37 participants |
Back to article view | Back to comp.lang.c
[computerphile] Why can't floating point do money? luser droog <luser.droog@gmail.com> - 2017-11-22 09:39 -0800
Re: [computerphile] Why can't floating point do money? "F. Russell" <fr@random.info> - 2017-11-23 13:11 +0000
Re: [computerphile] Why can't floating point do money? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-23 05:35 -0800
Re: [computerphile] Why can't floating point do money? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-23 13:47 +0000
Re: [computerphile] Why can't floating point do money? "F. Russell" <fr@random.info> - 2017-11-23 15:20 +0000
Re: [computerphile] Why can't floating point do money? Robert Wessel <robertwessel2@yahoo.com> - 2017-11-24 00:53 -0600
Re: [computerphile] Why can't floating point do money? supercat@casperkitty.com - 2017-11-24 14:16 -0800
Re: [computerphile] Why can't floating point do money? Robert Wessel <robertwessel2@yahoo.com> - 2017-11-24 23:50 -0600
Re: [computerphile] Why can't floating point do money? Noob <root@127.0.0.1> - 2017-11-24 09:44 +0100
Re: [computerphile] Why can't floating point do money? Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-24 09:18 -0500
Re: [computerphile] Why can't floating point do money? Noob <root@127.0.0.1> - 2017-11-29 11:50 +0100
Re: Toy code for currency handling Noob <root@127.0.0.1> - 2017-11-29 16:13 +0100
Re: Toy code for currency handling Noob <root@127.0.0.1> - 2017-11-29 16:53 +0100
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2017-11-29 10:42 -0600
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-11-29 09:25 -0800
Re: Toy code for currency handling Noob <root@127.0.0.1> - 2017-11-29 19:38 +0100
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-11-29 11:03 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-11-29 19:14 +0000
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-11-29 11:31 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2017-12-01 00:04 -0600
Re: Toy code for currency handling fr314159@gmail.com - 2017-12-01 12:41 -0800
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-01 15:24 -0800
Re: Toy code for currency handling Noob <root@127.0.0.1> - 2017-12-03 18:08 +0100
Re: Toy code for currency handling fr314159@gmail.com - 2017-12-04 10:06 -0800
Re: Toy code for currency handling jameskuyper@verizon.net - 2017-12-04 10:19 -0800
Re: Toy code for currency handling fr314159@gmail.com - 2017-12-04 11:35 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-04 11:56 -0800
Re: Toy code for currency handling Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 15:01 -0500
Re: Toy code for currency handling "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-05 07:14 +0100
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-05 09:18 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 11:31 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-05 14:13 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 14:39 +0000
Re: Toy code for currency handling Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-05 15:00 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 15:19 +0000
Re: Toy code for currency handling Melzzzzz <mel@zzzzz.com> - 2017-12-05 16:31 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 16:07 +0000
Re: Toy code for currency handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-06 01:25 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 02:00 +0000
Re: Toy code for currency handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-06 03:04 +0000
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2017-12-05 16:14 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-05 17:28 +0100
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-05 11:25 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 21:47 +0000
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-05 14:13 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 22:40 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 00:38 +0100
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 00:21 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 02:22 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 10:04 +0100
Re: Toy code for currency handling gordonb.g8o8d@burditt.org (Gordon Burditt) - 2017-12-10 21:45 -0600
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-06 08:31 -0800
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-05 16:25 +0100
Re: Toy code for currency handling already5chosen@yahoo.com - 2017-12-05 08:33 -0800
Re: Toy code for currency handling Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-05 19:09 +0000
Re: Toy code for currency handling already5chosen@yahoo.com - 2017-12-05 12:27 -0800
Re: Toy code for currency handling Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-05 20:40 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 16:42 +0000
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-05 09:39 -0800
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2017-12-05 17:52 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-06 07:59 +1300
Re: Toy code for currency handling Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-05 19:12 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 21:59 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 00:44 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 01:52 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-06 19:40 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 12:03 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 10:30 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 11:40 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 14:03 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 14:32 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 16:25 +0100
Re: Toy code for currency handling already5chosen@yahoo.com - 2017-12-06 07:47 -0800
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2017-12-06 16:06 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 18:08 +0000
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-06 11:22 -0800
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-06 09:24 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-06 11:23 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-06 11:18 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 19:59 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 20:02 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-07 09:39 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 21:36 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-07 11:15 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 23:36 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-07 12:49 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 23:58 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-07 13:08 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 01:51 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-07 14:54 +1300
Re: Toy code for currency handling Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-12-07 11:27 -0500
Re: Toy code for currency handling Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2017-12-07 03:38 +0100
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-06 20:39 -0800
Re: Toy code for currency handling "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-07 12:45 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 12:21 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-07 14:53 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 14:31 +0000
Re: Toy code for currency handling "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-07 15:33 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 14:53 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 14:46 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-07 20:28 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 20:03 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-07 22:27 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 22:45 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-08 00:39 +0100
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-24 03:41 -0800
Re: Toy code for currency handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-07 21:38 +0000
Re: Toy code for currency handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-07 15:24 +0000
Re: Toy code for currency handling herrmannsfeldt@gmail.com - 2017-12-11 02:17 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-11 08:50 -0800
Re: Toy code for currency handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-11 17:42 +0000
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-12 11:33 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2017-12-11 12:23 -0600
Re: Toy code for currency handling David Thompson <dave.thompson2@verizon.net> - 2018-01-21 11:53 -0500
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-21 11:44 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2018-01-21 12:24 -0800
Re: Toy code for currency handling herrmannsfeldt@gmail.com - 2018-01-23 21:03 -0800
Re: Toy code for currency handling Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-01-24 15:02 +0000
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-24 08:45 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2018-01-24 11:40 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-24 14:52 -0600
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-24 13:05 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-24 13:12 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 01:04 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-24 19:17 -0600
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-24 17:33 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 12:14 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 04:31 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 13:03 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 05:28 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 05:37 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 05:43 -0800
Re: Toy code for currency handling mark.bluemel@gmail.com - 2018-01-25 05:57 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 15:48 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 08:32 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 10:56 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 21:28 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 15:10 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 06:14 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 06:38 -0800
Re: Toy code for currency handling gordonb.ma9h0@burditt.org (Gordon Burditt) - 2018-01-24 21:53 -0600
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2018-01-25 18:05 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 18:16 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-26 07:30 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 22:08 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-26 20:00 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-26 11:31 +0000
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2018-01-26 15:51 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-26 10:32 -0600
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-26 08:50 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-26 13:11 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-26 18:32 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-26 13:07 -0600
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-27 09:43 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-26 21:44 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-27 11:02 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-27 00:46 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-28 09:19 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-27 21:19 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-27 14:14 -0800
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-28 11:21 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-27 22:32 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-28 12:16 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 00:44 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 04:13 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 13:56 +0000
Re: Toy code for currency handling Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-01-28 06:12 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 06:43 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 15:40 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 07:56 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 16:12 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 08:34 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 16:53 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 09:30 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 09:48 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-28 23:23 -0600
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-29 18:29 +1300
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-28 23:45 -0600
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-29 19:54 +1300
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-29 01:38 -0600
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-29 20:56 +1300
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-29 20:34 -0600
Re: Toy code for currency handling "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-01-29 21:46 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-28 23:34 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 12:02 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 12:33 +0000
Re: Toy code for currency handling Richard Damon <Richard@Damon-Family.org> - 2018-01-29 08:30 -0500
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 14:08 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-29 19:36 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-30 11:49 +0000
Re: Toy code for currency handling already5chosen@yahoo.com - 2018-01-30 04:45 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-30 13:04 +0000
Re: Toy code for currency handling already5chosen@yahoo.com - 2018-01-30 05:17 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-30 14:23 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-30 11:39 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-30 18:23 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-30 18:25 -0600
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-31 07:56 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-31 12:56 -0600
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-31 13:09 -0800
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2018-01-31 21:35 +0000
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-31 16:45 -0800
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2018-02-01 08:59 +0100
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-02-01 02:40 -0600
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2018-02-01 10:13 +0100
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2018-02-01 14:49 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2018-02-01 16:13 +0100
Re: Toy code for currency handling supercat@casperkitty.com - 2018-02-01 09:05 -0800
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2018-02-01 22:07 +0100
Re: Toy code for currency handling supercat@casperkitty.com - 2018-02-01 15:49 -0800
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2018-02-02 13:13 +0100
Re: Toy code for currency handling already5chosen@yahoo.com - 2018-01-30 05:30 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-30 10:48 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 12:59 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-29 20:26 -0600
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-29 20:36 -0600
Re: Toy code for currency handling mark.bluemel@gmail.com - 2018-01-30 00:34 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-30 11:33 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-30 11:49 -0600
Re: Toy code for currency handling jameskuyper@verizon.net - 2018-01-30 12:03 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-30 17:40 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-30 12:56 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-30 11:28 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-31 19:19 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 04:16 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 13:40 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 06:35 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 07:24 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 15:24 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 07:44 -0800
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-29 18:34 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 12:21 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-30 07:59 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 19:56 +0000
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2018-01-29 20:53 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 21:52 +0000
Re: Toy code for currency handling Richard Damon <Richard@Damon-Family.org> - 2018-01-27 18:32 -0500
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-27 13:22 -0600
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-26 13:23 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-26 13:41 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-26 14:12 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-26 22:23 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-26 14:44 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-26 15:28 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-26 16:22 -0800
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2018-01-25 09:11 +0100
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 02:27 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-24 15:23 -0600
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2018-01-24 14:29 -0800
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-24 14:49 -0800
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-07 07:42 -0800
Re: Toy code for currency handling herrmannsfeldt@gmail.com - 2017-12-11 02:20 -0800
Re: Toy code for currency handling gordonb.s654i@burditt.org (Gordon Burditt) - 2017-12-11 03:06 -0600
Re: Toy code for currency handling gordonb.pit4p@burditt.org (Gordon Burditt) - 2017-12-11 03:55 -0600
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2017-12-07 14:58 +0000
Re: Toy code for currency handling already5chosen@yahoo.com - 2017-12-06 01:45 -0800
Re: Toy code for currency handling Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-05 08:38 -0500
Re: Toy code for currency handling "James R. Kuyper" <jameskuyper@verizon.net> - 2017-12-04 15:16 -0500
Re: Toy code for currency handling asetofsymbols@gmail.com - 2017-12-05 02:56 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-04 11:04 -0800
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-05 09:33 +0100
Re: Toy code for currency handling Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 14:56 -0500
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2017-12-04 20:44 -0600
Re: Toy code for currency handling herrmannsfeldt@gmail.com - 2017-12-06 21:59 -0800
Re: [computerphile] Why can't floating point do money? Robert Wessel <robertwessel2@yahoo.com> - 2017-11-29 10:51 -0600
Re: [computerphile] Why can't floating point do money? Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-30 16:18 -0500
Re: [computerphile] Why can't floating point do money? scott@slp53.sl.home (Scott Lurndal) - 2017-11-30 22:13 +0000
Re: [computerphile] Why can't floating point do money? Robert Wessel <robertwessel2@yahoo.com> - 2017-11-24 10:19 -0600
Re: [computerphile] Why can't floating point do money? Spiros Bousbouras <spibou@gmail.com> - 2017-11-24 16:43 +0000
Re: [computerphile] Why can't floating point do money? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-24 08:53 -0800
Re: [computerphile] Why can't floating point do money? bert <bert.hutchings@btinternet.com> - 2017-11-24 08:57 -0800
Re: [computerphile] Why can't floating point do money? bartc <bc@freeuk.com> - 2017-11-24 16:57 +0000
Re: [computerphile] Why can't floating point do money? Robert Wessel <robertwessel2@yahoo.com> - 2017-11-24 23:35 -0600
Re: [computerphile] Why can't floating point do money? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-11-25 05:59 +0000
Re: [computerphile] Why can't floating point do money? supercat@casperkitty.com - 2017-11-27 10:14 -0800
Re: [computerphile] Why can't floating point do money? Robert Wessel <robertwessel2@yahoo.com> - 2017-11-30 23:56 -0600
Page 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
| From | fr314159@gmail.com |
|---|---|
| Date | 2017-12-01 12:41 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <3cb426ac-ef34-44c1-a16b-a9da054c208d@googlegroups.com> |
| In reply to | #123618 |
On Wednesday, November 29, 2017 at 2:14:42 PM UTC-5, Bart wrote: > > A strategy needs to be used that will always yield the same result. > That strategy is called IEEE758-2008 and most hardware now conforms to its specifications. However, the financial world needs a bit of time to learn and adjust. Hopefully by the year 2100 all the old MBAs will have been replaced by tech savvy ones. Incidentally, why only 64-bits in the IEEE FP standard? The reason, as stated by William Kahan who is the father of IEEE 754, is that 64-bits is enough to guarantee the accuracy of most calculations without having to hire an expensive error analyst. Floating point calculations must never be applied indiscriminately. Every algorithm using FP must be properly analyzed for stability, condition number, and error bounds. Otherwise things may turn around and bite back hard. One need only look at the Intel hardware trigonometric fiasco. This error condition is baked into EVERY Intel processor that exists and is the sole reason why trig calculations are executed (slowly) in software. Do we need a class actions suit against Intel?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-01 15:24 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <a197412d-6888-46d6-a08a-1a1b0aa2f6bf@googlegroups.com> |
| In reply to | #123696 |
On Friday, December 1, 2017 at 2:41:57 PM UTC-6, fr31...@gmail.com wrote: > Incidentally, why only 64-bits in the IEEE FP standard? > > The reason, as stated by William Kahan who is the father of IEEE 754, > is that 64-bits is enough to guarantee the accuracy of most calculations > without having to hire an expensive error analyst. Kahan advocated for an 80-bit computation type, and having operations on floating-point types convert values to that type and then convert results back. Such a design would be in line with the way K&R's C processed "float" values, but requires that the language include a type which actually holds the full precision, and that operations that coerce floating-point values to a default-promoted type (e.g. passing to a variadic function) treat the full-precision type the same as other floating-point types. Unfortunately, ANSI C makes it impossible for implementations to uphold both requirements while using 80-bit intermediates except by having "double" be an 80-bit type, which would cause its own problems.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-12-03 18:08 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p01b1t$i92$1@dont-email.me> |
| In reply to | #123696 |
On 01/12/2017 21:41, fr314159 wrote:
> That strategy is called IEEE758-2008 and most hardware now conforms
> to its specifications.
>
> However, the financial world needs a bit of time to learn and adjust.
> Hopefully by the year 2100 all the old MBAs will have been replaced
> by tech savvy ones.
>
> Incidentally, why only 64-bits in the IEEE FP standard?
AFAIU, IEEE 754 supports a 128-bit type.
Sign bit: 1 bit
Exponent width: 15 bits
Significand precision: 113 bits (112 explicitly stored)
https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format
> The reason, as stated by William Kahan who is the father of IEEE 754,
> is that 64-bits is enough to guarantee the accuracy of most calculations
> without having to hire an expensive error analyst.
The Wikipedia article quotes Kahan as having said:
> For now the 10-byte Extended format is a tolerable compromise between
> the value of extra-precise arithmetic and the price of implementing
> it to run fast; very soon two more bytes of precision will become
> tolerable, and ultimately a 16-byte format... That kind of gradual
> evolution towards wider precision was already in view when IEEE
> Standard 754 for Floating-Point Arithmetic was framed.
Regards.
[toc] | [prev] | [next] | [standalone]
| From | fr314159@gmail.com |
|---|---|
| Date | 2017-12-04 10:06 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <fdafceed-9f68-496f-93a5-0fdfc38b9f32@googlegroups.com> |
| In reply to | #123760 |
On Sunday, December 3, 2017 at 12:08:30 PM UTC-5, Noob wrote: > > AFAIU, IEEE 754 supports a 128-bit type. > Yes, and the C language also has a 128-bit FP type called __float128. But, AFAIK, there is no hardware implementation of 128-bit FP. A fixed floating point format is quickly becoming passe. What is required now is "adaptive precision" where the number of bits is adjusted according to the needs of a computation. The Mathematica software does this already. The next step in hardware evolution has to address this issue.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-12-04 10:19 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <e2caf181-7855-4864-8cc7-f4889117c17c@googlegroups.com> |
| In reply to | #123812 |
On Monday, December 4, 2017 at 1:06:53 PM UTC-5, fr31...@gmail.com wrote: > On Sunday, December 3, 2017 at 12:08:30 PM UTC-5, Noob wrote: > > > > > AFAIU, IEEE 754 supports a 128-bit type. > > > > Yes, and the C language also has a 128-bit FP type called __float128. No, it does not. A particular implementation of C may recognize that type as a 128-bit floating point type, but that is an extension to C, and not part of the C language itself.
[toc] | [prev] | [next] | [standalone]
| From | fr314159@gmail.com |
|---|---|
| Date | 2017-12-04 11:35 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <f412ad32-7c89-45cb-825e-04d3e5a5fbbf@googlegroups.com> |
| In reply to | #123813 |
On Monday, December 4, 2017 at 1:19:24 PM UTC-5, james...@verizon.net wrote: > > No, it does not. A particular implementation of C may recognize that type > My programming universe is GNU/Linux where __float128 is used. Are there actually C programmers who don't use GNU/Linux? (No, I am not being facetious.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-04 11:56 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <ln8teiuv1q.fsf@kst-u.example.com> |
| In reply to | #123821 |
fr314159@gmail.com writes:
> On Monday, December 4, 2017 at 1:19:24 PM UTC-5, james...@verizon.net wrote:
>> No, it does not. A particular implementation of C may recognize that type
>
> My programming universe is GNU/Linux where __float128 is used.
There are still GNU/Linux systems where __float128 doesn't exist. As I
recall, gcc supports it only on 64-bit targets.
> Are there actually C programmers who don't use GNU/Linux?
>
> (No, I am not being facetious.)
Yes, there most certainly are.
C is defined by the ISO C standard. The latest public draft is
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
You should get a copy.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-12-04 15:01 -0500 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p049if$amr$1@jstuckle.eternal-september.org> |
| In reply to | #123821 |
On 12/4/2017 2:35 PM, fr314159@gmail.com wrote: > On Monday, December 4, 2017 at 1:19:24 PM UTC-5, james...@verizon.net wrote: > >> >> No, it does not. A particular implementation of C may recognize that type >> > > My programming universe is GNU/Linux where __float128 is used. > > Are there actually C programmers who don't use GNU/Linux? > > (No, I am not being facetious.) > There are many C programmers who don't use GNU/Linux. Anything from dedicated processors and DSP chips to mainframes. Many of the small chips don't even have an OS but are still running C. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2017-12-05 07:14 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <m27eu1aegy.fsf@despina.home> |
| In reply to | #123825 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 12/4/2017 2:35 PM, fr314159@gmail.com wrote: >> On Monday, December 4, 2017 at 1:19:24 PM UTC-5, james...@verizon.net wrote: >> >>> >>> No, it does not. A particular implementation of C may recognize that type >>> >> >> My programming universe is GNU/Linux where __float128 is used. >> >> Are there actually C programmers who don't use GNU/Linux? >> >> (No, I am not being facetious.) >> > > There are many C programmers who don't use GNU/Linux. Anything from > dedicated processors and DSP chips to mainframes. Many of the small > chips don't even have an OS but are still running C. This is misleading. The C programmers who don't use GNU/Linux use MS-Windows or MacOSX. (or perhaps in some strange places, some old UNIX hardware). As you write, many small chips don't have an OS,much less a native development environment! The programmers writing programs for those machines use GNU/Linux! (or MS-Windows if they're masochists). -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-05 09:18 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p05knp$m2$1@dont-email.me> |
| In reply to | #123836 |
On 05/12/17 07:14, Pascal J. Bourguignon wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 12/4/2017 2:35 PM, fr314159@gmail.com wrote: >>> On Monday, December 4, 2017 at 1:19:24 PM UTC-5, james...@verizon.net wrote: >>> >>>> >>>> No, it does not. A particular implementation of C may recognize that type >>>> >>> >>> My programming universe is GNU/Linux where __float128 is used. >>> >>> Are there actually C programmers who don't use GNU/Linux? >>> >>> (No, I am not being facetious.) >>> >> >> There are many C programmers who don't use GNU/Linux. Anything from >> dedicated processors and DSP chips to mainframes. Many of the small >> chips don't even have an OS but are still running C. > > This is misleading. > Yes, it has lead you into confusion... You are mixing up "host" and "target" here. Whether or not a C implementation supports "__float128" is a question of the /target/, and is independent of the host OS. It doesn't really matter if the programmer uses Linux, Windows, or whatever for their hosting - it is the target that matters. And C is used on a /huge/ range of target devices - most of which don't run any kind of OS, or which run an embedded OS of some sort (FreeRTOS, mbed, RTEMS, etc.). Many of these programmers use gcc - regardless of the host OS. Many also use other compilers - again, regardless of the host OS. > The C programmers who don't use GNU/Linux use MS-Windows or MacOSX. > (or perhaps in some strange places, some old UNIX hardware). > Most people use Linux (or, for the fanatics out there, GNU/Linux) or Windows for the /host/. MacOS, FreeBSD, and Solaris are also used - other hosts OS's are increasingly rare. > As you write, many small chips don't have an OS,much less a native > development environment! The programmers writing programs for those > machines use GNU/Linux! (or MS-Windows if they're masochists). > Yes, but that is totally irrelevant to a discussion of __float128 and other /target/ and compiler features.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-05 11:31 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <FsvVB.87499$UP1.39411@fx31.am4> |
| In reply to | #123836 |
On 05/12/2017 06:14, Pascal J. Bourguignon wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: >> There are many C programmers who don't use GNU/Linux. Anything from >> dedicated processors and DSP chips to mainframes. Many of the small >> chips don't even have an OS but are still running C. > > This is misleading. > > The C programmers who don't use GNU/Linux use MS-Windows or MacOSX. > (or perhaps in some strange places, some old UNIX hardware). > > As you write, many small chips don't have an OS,much less a native > development environment! (I've developed programs for a small[ish] chip using a compiler running on the same chip, without benefit of any OS.) > The programmers writing programs for those > machines use GNU/Linux! (or MS-Windows if they're masochists). Say you're using C. The development process might involve running a text editor, C compiler, and a linker. What aspect of that would make someone running Windows (or anything that isn't Unix/Linux), a masochist? In what way? If the resulting program has to run on a different processor, what is it about Windows that makes that so impossible that someone would be a masochist if they insisted on doing so? What magic does Unix/Linux bring to the table that is impossible to duplicate in any other OS? Is it that the software they're developing on this chip itself is dependent in some way on Linux, or on the host machine running Linux, so that /moving/ the development anywhere else would be impossible? /That/ would be masochistic! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-05 14:13 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p06612$hb4$1@dont-email.me> |
| In reply to | #123842 |
On 05/12/17 12:31, bartc wrote: > On 05/12/2017 06:14, Pascal J. Bourguignon wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: > >>> There are many C programmers who don't use GNU/Linux. Anything from >>> dedicated processors and DSP chips to mainframes. Many of the small >>> chips don't even have an OS but are still running C. >> >> This is misleading. >> >> The C programmers who don't use GNU/Linux use MS-Windows or MacOSX. >> (or perhaps in some strange places, some old UNIX hardware). >> >> As you write, many small chips don't have an OS,much less a native >> development environment! > > (I've developed programs for a small[ish] chip using a compiler running > on the same chip, without benefit of any OS.) > >> The programmers writing programs for those >> machines use GNU/Linux! (or MS-Windows if they're masochists). > > Say you're using C. The development process might involve running a text > editor, C compiler, and a linker. > My development process usually involves an IDE (not just a text editor), a compiler, an assembler (usually called by the compiler driver), a linker, libraries, and headers. Builds are driven by make - with the process also using a range of utilities like sed, cp, touch, etc. (Why? Because it makes my builds faster, smoother, easier to maintain and better organised. My programs don't consist of a couple of C files - they usually consist of many dozens of files over several directories.) Sometimes there are additional tools or scripts involved, usually in Python. There is always a revision control system (like subversion or git). There are all sorts of tests, perhaps also simulations. There are debuggers, and programmers for my embedded systems. There are usually terminal emulators, and might be network test code or loggers. There is documentation - LibreOffice or LaTeX. /Real/ development processes involve vastly more than hacking out a C file or two with Notepad and running "gcc file1.c file2.c -o coolprogram.exe". I can usually do most of this with Windows. In fact, I make a point of being able to replicate my builds on Windows as well as Linux. But on Linux, the whole process is more efficient and smoother to use - at least for me, as someone familiar with both systems. The big picture is mostly the same - I can use the same Eclipse on both systems, the same gcc, and I have the same *nix utilities for makefiles (via msys2 on Windows). It is all the little things that add up, and make life simpler for a developer when using Linux. (Faster multiprocessing and better parallel builds, much faster file accesses, far better use of memory and swap, multiple workspaces, a decent command line, ssh, better networking, more utilities, updates when /I/ want them, no malware, proper user control, sane hardware support, support for development with serial ports and USB, better virtual machine support, etc.) So I, for one, /could/ do most of my C development work on Windows - but I much prefer to use Linux. There are other things in my job that are better done on Windows - and some things that can /only/ be done on Windows or only be done on Linux. > What aspect of that would make someone running Windows (or anything that > isn't Unix/Linux), a masochist? In what way? > > If the resulting program has to run on a different processor, what is it > about Windows that makes that so impossible that someone would be a > masochist if they insisted on doing so? > > What magic does Unix/Linux bring to the table that is impossible to > duplicate in any other OS? > > Is it that the software they're developing on this chip itself is > dependent in some way on Linux, or on the host machine running Linux, so > that /moving/ the development anywhere else would be impossible? /That/ > would be masochistic! >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-05 14:39 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <PcyVB.51063$by1.2211@fx24.am4> |
| In reply to | #123847 |
On 05/12/2017 13:13, David Brown wrote: > On 05/12/17 12:31, bartc wrote: >> Say you're using C. The development process might involve running a text >> editor, C compiler, and a linker. >> > > My development process usually involves an IDE (not just a text editor), > a compiler, an assembler (usually called by the compiler driver), a > linker, libraries, and headers. > > Builds are driven by make - with the process also using a range of > utilities like sed, cp, touch, etc. (Why? Because it makes my builds > faster, smoother, easier to maintain and better organised. My programs > don't consist of a couple of C files - they usually consist of many > dozens of files over several directories.) > > Sometimes there are additional tools or scripts involved, usually in > Python. There is always a revision control system (like subversion or > git). There are all sorts of tests, perhaps also simulations. There > are debuggers, and programmers for my embedded systems. There are > usually terminal emulators, and might be network test code or loggers. > There is documentation - LibreOffice or LaTeX. > > /Real/ development processes involve vastly more than hacking out a C > file or two with Notepad and running "gcc file1.c file2.c -o > coolprogram.exe". Why makes you think /I/ have never done real development? My apps also involved many dozens of files, and in pre-Windows days they included printer drivers, plotter drivers, video drivers, mice/tablet drivers, bitmap fonts, vector fonts, image file handlers, and message files (for internationalisation). Plus application-specific data files (GUI icons for example). Plus of course I created all my own tools, some of which were part of the apps, so files for editors, interpreters and compilers. Source code included compiled programs, interpreted programs, and command scripts. Did any of this demand any special features of the OS? No it didn't. It just needed a file system. To compile everything from source was just a matter of compiling one file after another. If the IDE didn't handle it, then it was the simplest kind of batch file. I think what happens is that people just make use of the miscellaneous, arcane features of an OS like Linux, so that they develop a dependency on it. Then they have problems in working with a comparatively bare OS like Windows, without having to import half of Linux, and that's when they complain that Windows is so terrible to work with. > I can usually do most of this with Windows. In fact, I make a point of > being able to replicate my builds on Windows as well as Linux. But on > Linux, the whole process is more efficient and smoother to use - at > least for me, as someone familiar with both systems. The big picture is > mostly the same - I can use the same Eclipse on both systems, the same > gcc, and I have the same *nix utilities for makefiles (via msys2 on > Windows). Yeah, importing half of Linux... > It is all the little things that add up, and make life > simpler for a developer when using Linux. If you're used to Linux then just use that. But don't say that Windows is so terrible because it doesn't include your favourite toys. However, /my/ complaints about Linux are more fundamental. Like its case sensitivity. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2017-12-05 15:00 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p06car$ti1$1@news.albasani.net> |
| In reply to | #123852 |
On 2017-12-05, bartc <bc@freeuk.com> wrote: > On 05/12/2017 13:13, David Brown wrote: >> On 05/12/17 12:31, bartc wrote: > >>> Say you're using C. The development process might involve running a text >>> editor, C compiler, and a linker. >>> >> >> My development process usually involves an IDE (not just a text editor), >> a compiler, an assembler (usually called by the compiler driver), a >> linker, libraries, and headers. >> >> Builds are driven by make - with the process also using a range of >> utilities like sed, cp, touch, etc. (Why? Because it makes my builds >> faster, smoother, easier to maintain and better organised. My programs >> don't consist of a couple of C files - they usually consist of many >> dozens of files over several directories.) >> >> Sometimes there are additional tools or scripts involved, usually in >> Python. There is always a revision control system (like subversion or >> git). There are all sorts of tests, perhaps also simulations. There >> are debuggers, and programmers for my embedded systems. There are >> usually terminal emulators, and might be network test code or loggers. >> There is documentation - LibreOffice or LaTeX. >> >> /Real/ development processes involve vastly more than hacking out a C >> file or two with Notepad and running "gcc file1.c file2.c -o >> coolprogram.exe". > > Why makes you think /I/ have never done real development? My apps also > involved many dozens of files, and in pre-Windows days they included > printer drivers, plotter drivers, video drivers, mice/tablet drivers, > bitmap fonts, vector fonts, image file handlers, and message files (for > internationalisation). Plus application-specific data files (GUI icons > for example). > > Plus of course I created all my own tools, some of which were part of > the apps, so files for editors, interpreters and compilers. > > Source code included compiled programs, interpreted programs, and > command scripts. > > Did any of this demand any special features of the OS? No it didn't. It > just needed a file system. Sure. > > However, /my/ complaints about Linux are more fundamental. Like its case > sensitivity. Your problem with Linux is that you used to Windows naming convention. Put all files in lower case and no problem to move between Windows and Linux ;) > -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-05 15:19 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <4OyVB.84874$X11.8571@fx20.am4> |
| In reply to | #123853 |
On 05/12/2017 15:00, Melzzzzz wrote: > On 2017-12-05, bartc <bc@freeuk.com> wrote: >> However, /my/ complaints about Linux are more fundamental. Like its case >> sensitivity. > > Your problem with Linux is that you used to Windows naming convention. Which is what? > Put all files in lower case and no problem to move between Windows and > Linux ;) If all Linux files are always lower case, they why should it matter if the names are typed in upper case? ABC.C should be assumed to mean abc.c. The fact is that in Linux, abc.c, abc.C, abC.c, abC.C, aBc.c, aBc.C, aBC.c, aBC.C, Abc.c, Abc.C, AbC.c, AbC.C, ABc.c, ABc.C, ABC.c and ABC.C are all different files, even in the same directory. /That/ is crazy. (It's a good thing I chose an example with only four letters otherwise this could have been a very long post.) The world is fortunate that Google searches are case-insensitive... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2017-12-05 16:31 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p06e49$pp3$1@news.albasani.net> |
| In reply to | #123854 |
On 12/5/17 4:19 PM, bartc wrote: > On 05/12/2017 15:00, Melzzzzz wrote: >> On 2017-12-05, bartc <bc@freeuk.com> wrote: > >>> However, /my/ complaints about Linux are more fundamental. Like its case >>> sensitivity. >> >> Your problem with Linux is that you used to Windows naming convention. > > Which is what? You have problem on Linux, no? You refer to file as "file.h" but you actually name it File.h ;) > >> Put all files in lower case and no problem to move between Windows and >> Linux ;) > > If all Linux files are always lower case, they why should it matter if > the names are typed in upper case? ABC.C should be assumed to mean abc.c. > > The fact is that in Linux, abc.c, abc.C, abC.c, abC.C, aBc.c, aBc.C, > aBC.c, aBC.C, Abc.c, Abc.C, AbC.c, AbC.C, ABc.c, ABc.C, ABC.c and ABC.C > are all different files, even in the same directory. /That/ is crazy. > > (It's a good thing I chose an example with only four letters otherwise > this could have been a very long post.) > > The world is fortunate that Google searches are case-insensitive... > You can argue about case sensitivity in programming languages as well.. C is case sensitive, is it bad or good, as well? >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-05 16:07 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <CuzVB.82859$M61.30839@fx38.am4> |
| In reply to | #123857 |
On 05/12/2017 15:31, Melzzzzz wrote: > On 12/5/17 4:19 PM, bartc wrote: >> On 05/12/2017 15:00, Melzzzzz wrote: >>> On 2017-12-05, bartc <bc@freeuk.com> wrote: >> >>>> However, /my/ complaints about Linux are more fundamental. Like its >>>> case >>>> sensitivity. >>> >>> Your problem with Linux is that you used to Windows naming convention. >> >> Which is what? > > You have problem on Linux, no? You refer to file as "file.h" but you > actually name it File.h ;) > >> >>> Put all files in lower case and no problem to move between Windows and >>> Linux ;) >> >> If all Linux files are always lower case, they why should it matter if >> the names are typed in upper case? ABC.C should be assumed to mean abc.c. >> >> The fact is that in Linux, abc.c, abc.C, abC.c, abC.C, aBc.c, aBc.C, >> aBC.c, aBC.C, Abc.c, Abc.C, AbC.c, AbC.C, ABc.c, ABc.C, ABC.c and ABC.C >> are all different files, even in the same directory. /That/ is crazy. >> >> (It's a good thing I chose an example with only four letters otherwise >> this could have been a very long post.) >> >> The world is fortunate that Google searches are case-insensitive... >> > You can argue about case sensitivity in programming languages as well.. > C is case sensitive, is it bad or good, as well? A few years, I copied some features of C into my own language, notably: (1) Using 0x notation for hex constants (to replace 123H and 0ABCH, which become 0x123 and 0xABC) (2) Requiring F() to call a function F even with no parameters, instead of just F (3) When F is a function, for F in an expression to yield a pointer to that function, when it is not written as F(...). (4) Being case sensitive Most of those have worked well, except for case sensitivity. It is a nuisance when adding quick temporary code for debugging, not to be able to capitals to highlight the code, to make it easy to see and comment out/remove later. Or to get the capitalisation just right even for such code. Or to be able to highlight code for other reasons. So (4) has recently been reversed. And actually, I've just found out that (3) gives me a discontinuity in my syntax: if F is a function, then I can call it as F(), or as F^() (ie. (*F)() in C, even though F is not a pointer. But fortunately not as F^^(), as C does allow (**F)(). So I'm thinking of reversing (3) too! (I would need to write &F to get a pointer to F, so that, if (2) is retained, F by itself is an error.) To answer your question, I think case sensitivity in a language is bad. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-06 01:25 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <87609k4pg9.fsf@bsb.me.uk> |
| In reply to | #123858 |
bartc <bc@freeuk.com> writes: <snip> > A few years, I copied some features of C into my own language, notably: <snip> > (3) When F is a function, for F in an expression to yield a pointer to > that function, when it is not written as F(...). This is not really how C does it. Your wording states that using F in a call (F(...)) is an exception to the conversion rule whilst at least suggesting that use in function call is the only exception to the rule. But in C, neither is the case: function designators converts to a pointers even in call expressions, and they don't get converted when they appear as the operand of sizeof or &. It's not a very significant correction, but a couple of things about C are hard to explain unless you know what the rules are. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-06 02:00 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <GaIVB.122188$XT.41738@fx37.am4> |
| In reply to | #123906 |
On 06/12/2017 01:25, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > <snip> >> A few years, I copied some features of C into my own language, notably: > <snip> >> (3) When F is a function, for F in an expression to yield a pointer to >> that function, when it is not written as F(...). > > This is not really how C does it. Your wording states that using F in a > call (F(...)) is an exception to the conversion rule whilst at least > suggesting that use in function call is the only exception to the rule. > > But in C, neither is the case: function designators converts to a > pointers even in call expressions, and they don't get converted when > they appear as the operand of sizeof or &. I think my C compiler works differently: the F in F(....) doesn't get turned into a function pointer value. But that's just a little optimisation which avoids having to unnecessarily construct a suitable function pointer type, only to get rid of it again as soon as the following ( forces a dereference. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-06 03:04 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <87bmjc36b7.fsf@bsb.me.uk> |
| In reply to | #123910 |
bartc <bc@freeuk.com> writes: > On 06/12/2017 01:25, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: >> <snip> >>> A few years, I copied some features of C into my own language, notably: >> <snip> >>> (3) When F is a function, for F in an expression to yield a pointer to >>> that function, when it is not written as F(...). >> >> This is not really how C does it. Your wording states that using F in a >> call (F(...)) is an exception to the conversion rule whilst at least >> suggesting that use in function call is the only exception to the rule. >> >> But in C, neither is the case: function designators converts to a >> pointers even in call expressions, and they don't get converted when >> they appear as the operand of sizeof or &. > > I think my C compiler works differently: the F in F(....) doesn't get > turned into a function pointer value. > > But that's just a little optimisation which avoids having to > unnecessarily construct a suitable function pointer type, only to get > rid of it again as soon as the following ( forces a dereference. Yes, no compiler has to do the conversion -- it's about what the language definition says. To understand C, you have to know the conversion rules, the type promotion rules and so on. If you only looked at what the compiler did on some particular machine, you would have a very hard time understanding C. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web