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 1 of 14 [1] 2 3 … 14 Next page →
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2017-11-22 09:39 -0800 |
| Subject | [computerphile] Why can't floating point do money? |
| Message-ID | <c55dca02-2d15-4704-bc24-9b695e879327@googlegroups.com> |
https://www.youtube.com/watch?v=PZRI1IfStY0
[toc] | [next] | [standalone]
| From | "F. Russell" <fr@random.info> |
|---|---|
| Date | 2017-11-23 13:11 +0000 |
| Message-ID | <ov6hef02etp@news3.newsguy.com> |
| In reply to | #123317 |
On Wed, 22 Nov 2017 09:39:20 -0800, luser droog wrote: > https://www.youtube.com/watch?v=PZRI1IfStY0 > It is incorrect to say that the digital floating point format cannot "do money." The inability to "do money" applies only to the *binary* floating point format. However, the *decimal* floating point format (DFP), which is based on powers of 10 rather than 2, can perform financial calculations with perfect accuracy. DFP is codified in the IEEE 754-2008 international standard and this standard is already implemented in hardware on the IBM Power processors. Intel hardware is sadly way behind the times. But software DFP libraries exist for Intel and other "antiquated" systems (C libraries of course).
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-11-23 05:35 -0800 |
| Message-ID | <46ea7467-f329-495c-91a2-d318c1a83788@googlegroups.com> |
| In reply to | #123369 |
On Thursday, November 23, 2017 at 8:12:56 AM UTC-5, F. Russell wrote:
> On Wed, 22 Nov 2017 09:39:20 -0800, luser droog wrote:
>
> > https://www.youtube.com/watch?v=PZRI1IfStY0
> >
>
> It is incorrect to say that the digital floating point format
> cannot "do money." The inability to "do money" applies only
> to the *binary* floating point format.
>
> However, the *decimal* floating point format (DFP), which is
> based on powers of 10 rather than 2, can perform financial
> calculations with perfect accuracy. DFP is codified in the
> IEEE 754-2008 international standard and this standard is
> already implemented in hardware on the IBM Power processors.
> Intel hardware is sadly way behind the times.
>
> But software DFP libraries exist for Intel and other "antiquated"
> systems (C libraries of course).
In addition, the FPU contains a 64-bit integer ability, which has
been used for decades for a fixed point currency format, typically
with four decimals.
https://stackoverflow.com/questions/17986940/in-foxpro-the-difference-between-currency-and-number-datatype
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-11-23 13:47 +0000 |
| Message-ID | <878texrts2.fsf@bsb.me.uk> |
| In reply to | #123369 |
"F. Russell" <fr@random.info> writes: > On Wed, 22 Nov 2017 09:39:20 -0800, luser droog wrote: > >> https://www.youtube.com/watch?v=PZRI1IfStY0 >> > > It is incorrect to say that the digital floating point format > cannot "do money." The inability to "do money" applies only > to the *binary* floating point format. Also the term "do money" is too wide. Financial calculations are often done in binary floating point, but only when the required accuracy can be met. The most common cases are financial models (particularly macroeconomic models) that work just fine with binary floating point. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "F. Russell" <fr@random.info> |
|---|---|
| Date | 2017-11-23 15:20 +0000 |
| Message-ID | <ov6ovv0r46@news6.newsguy.com> |
| In reply to | #123369 |
On Thu, 23 Nov 2017 14:35:37 +0000, Stefan Ram wrote: > ^^^^ > Not also to the *ternary* floating point format? > > And what about a decimal floating point format > with only four significant digits in the mantissa > and one in the exponent? > Please show hardware and/or software that uses such formats.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-11-24 00:53 -0600 |
| Message-ID | <95ef1d5h7atckanagpqevoeif63munoosa@4ax.com> |
| In reply to | #123369 |
On 23 Nov 2017 13:11:43 GMT, "F. Russell" <fr@random.info> wrote: >On Wed, 22 Nov 2017 09:39:20 -0800, luser droog wrote: > >> https://www.youtube.com/watch?v=PZRI1IfStY0 >> > >It is incorrect to say that the digital floating point format >cannot "do money." The inability to "do money" applies only >to the *binary* floating point format. > >However, the *decimal* floating point format (DFP), which is >based on powers of 10 rather than 2, can perform financial >calculations with perfect accuracy. DFP is codified in the >IEEE 754-2008 international standard and this standard is >already implemented in hardware on the IBM Power processors. >Intel hardware is sadly way behind the times. > >But software DFP libraries exist for Intel and other "antiquated" >systems (C libraries of course). That's not really correct. While DFP does remove a few issues, it's a slightly odd set of feature that lets you treat DFP as (almost) fixed point (decimal) arithmetic, which allows you to reasonably build a currency format. But no, you can't really do currency in DFP, except in the semi-fixed-point subset. OTOH, you actually *can* do currency in either binary or decimal FP, it's just a huge pain to get right, and you tend to end up throwing away all the advantages of the "floating" format (and again, the DFP standard actually makes that reasonably easy to do). DFPs main claim is that (non-currency) calculations will end up with results nearer the ones humans expect, by virtue of its decimal nature. IOW, you can't just define all your currency fields as "decimal long double" and expect things to work. In fact they won't, and for most of the same reasons that a binary long double is problematic. But DFP does provide some better ways to support building currency capable operations than does BFP. Now there *are* some simple operations, on restricted sizes, that *do* just magically work when done in DFP, it doesn't cover everything, not be a long shot. As an interesting aside, IBM's mainframe packed decimal operations have been very stable since S/360. Basically shift-and-round-packed (with S/370, circa 1970) and test-decimal (validates a decimal field, added something in the 64-bit era) are the only two instructions that have been added. The DFP support, starting with the z9 (or at least partial support on the z9, where it was mostly implemented as a microcode upgrade, and quite slow, circa 2007, but "real" hardware came later, on the z10), was the big addition to decimal support. And while some applications used it instead of the old packed decimal ISA, it hasn't been implemented universally. In fact not even the Cobol compiler uses the DFP instructions generally for decimal arithmetic, because it's still more work in most cases to get DFP working correctly than it is to use the old ISA, with all the quirks it has. With the new z14, the short vector facility has been enhanced with a set of (fixed point) packed decimal instructions, that look a lot like the old packed instructions, but with a lot of the ISA issues the old instructions had, cleaned up.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-11-24 14:16 -0800 |
| Message-ID | <e4d87703-50de-476a-a7b1-c0cd121d311d@googlegroups.com> |
| In reply to | #123418 |
On Friday, November 24, 2017 at 12:53:19 AM UTC-6, robert...@yahoo.com wrote: > On 23 Nov 2017 13:11:43 GMT, "F. Russell" <fr@random.info> wrote: > >However, the *decimal* floating point format (DFP), which is > >based on powers of 10 rather than 2, can perform financial > >calculations with perfect accuracy. DFP is codified in the > >IEEE 754-2008 international standard and this standard is > >already implemented in hardware on the IBM Power processors. > >Intel hardware is sadly way behind the times. > While DFP does remove a few issues, it's a slightly odd set of feature > that lets you treat DFP as (almost) fixed point (decimal) arithmetic, > which allows you to reasonably build a currency format. But no, you > can't really do currency in DFP, except in the semi-fixed-point > subset. The .NET Framework includes a decimal floating-point type which seems to have been intended for applications that need to process fixed-point data (such as exists in many databases). I think the design intention was to handle the needs of applications that need many digits to the left of the decimal point and few to the right, as well as those that need many to the right and few to the left. I really dislike the design that MS ended up using, though. A key feature of fixed-point types is that for any values x and y of matching precision, the expression (x+y)-x will never yield a value other than x. Floating-point types, even decimal ones, throw that guarantee out the window.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-11-24 23:50 -0600 |
| Message-ID | <6j0i1dp23m77g3vgsqr9460sjcaclf8l01@4ax.com> |
| In reply to | #123456 |
On Fri, 24 Nov 2017 14:16:38 -0800 (PST), supercat@casperkitty.com wrote: >On Friday, November 24, 2017 at 12:53:19 AM UTC-6, robert...@yahoo.com wrote: >> On 23 Nov 2017 13:11:43 GMT, "F. Russell" <fr@random.info> wrote: >> >However, the *decimal* floating point format (DFP), which is >> >based on powers of 10 rather than 2, can perform financial >> >calculations with perfect accuracy. DFP is codified in the >> >IEEE 754-2008 international standard and this standard is >> >already implemented in hardware on the IBM Power processors. >> >Intel hardware is sadly way behind the times. > >> While DFP does remove a few issues, it's a slightly odd set of feature >> that lets you treat DFP as (almost) fixed point (decimal) arithmetic, >> which allows you to reasonably build a currency format. But no, you >> can't really do currency in DFP, except in the semi-fixed-point >> subset. > >The .NET Framework includes a decimal floating-point type which seems to >have been intended for applications that need to process fixed-point data >(such as exists in many databases). I think the design intention was to >handle the needs of applications that need many digits to the left of the >decimal point and few to the right, as well as those that need many to the >right and few to the left. I really dislike the design that MS ended up >using, though. A key feature of fixed-point types is that for any values >x and y of matching precision, the expression (x+y)-x will never yield a >value other than x. Floating-point types, even decimal ones, throw that >guarantee out the window. In many ways the decimal type is more like the traditional Cobol scaled integer than a real float. It's a 96 bit binary number, with a negative scale factor of 0-28 powers of ten. It's floating in the sense that the scale factor is not fixed for a given field, which leave you manually adjusting something and manually doing some rounding, but it's pretty usable, so long as you don't overflow the precision (which at ~28 digits, covers a lot of operations). I don't know why they decided to just toss some 26 bits of precision of the potential, that would have been good for about seven extra decimal digits in intermediate results (presumably they decided that the speed of 96-bit operations outweighed the value of the extra precision).
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-11-24 09:44 +0100 |
| Message-ID | <ov8m5j$vn9$1@dont-email.me> |
| In reply to | #123369 |
On 23/11/2017 14:11, F. Russell wrote: > On Wed, 22 Nov 2017 09:39:20 -0800, luser droog wrote: > >> https://www.youtube.com/watch?v=PZRI1IfStY0 > > It is incorrect to say that the digital floating point format > cannot "do money." The inability to "do money" applies only > to the *binary* floating point format. > > However, the *decimal* floating point format (DFP), which is > based on powers of 10 rather than 2, can perform financial > calculations with perfect accuracy. DFP is codified in the > IEEE 754-2008 international standard and this standard is > already implemented in hardware on the IBM Power processors. > Intel hardware is sadly way behind the times. > > But software DFP libraries exist for Intel and other "antiquated" > systems (C libraries of course). I have a naive question. Why would someone want to use floating point for currency? Why not use 64-bit integers, and work with fractions of the currency as the base unit, e.g. 1/10^3 or 1/10^6 depending on how many decimals one might need. Hmmm, I suppose that's just fixed point arithmetic. It works well for add, sub. Is there a need for mul and div? Regards.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-11-24 09:18 -0500 |
| Message-ID | <ov99nf$5uc$1@jstuckle.eternal-september.org> |
| In reply to | #123423 |
On 11/24/2017 3:44 AM, Noob wrote: > On 23/11/2017 14:11, F. Russell wrote: > >> On Wed, 22 Nov 2017 09:39:20 -0800, luser droog wrote: >> >>> https://www.youtube.com/watch?v=PZRI1IfStY0 >> >> It is incorrect to say that the digital floating point format >> cannot "do money." The inability to "do money" applies only >> to the *binary* floating point format. >> >> However, the *decimal* floating point format (DFP), which is >> based on powers of 10 rather than 2, can perform financial >> calculations with perfect accuracy. DFP is codified in the >> IEEE 754-2008 international standard and this standard is >> already implemented in hardware on the IBM Power processors. >> Intel hardware is sadly way behind the times. >> >> But software DFP libraries exist for Intel and other "antiquated" >> systems (C libraries of course). > > I have a naive question. > > Why would someone want to use floating point for currency? > > Why not use 64-bit integers, and work with fractions of the > currency as the base unit, e.g. 1/10^3 or 1/10^6 depending > on how many decimals one might need. > > Hmmm, I suppose that's just fixed point arithmetic. It works > well for add, sub. Is there a need for mul and div? > > Regards. > They could, but it hasn't been until relatively recently that 64 bit integers were supported by the hardware. And even now, there's a lot of hardware which doesn't support 64 bit integers - at least directly. And yes, there is a huge need for multiplication and division for money. The most obvious example is figuring interest on a savings account. But there's a lot more - from figuring loan payments to actuarial work buy insurance companies. And financial institutions, insurance companies, governments and more in the U.S. usually carry financial calculations to six decimal places with a maximum of at least 99 billion dollars - which means 17 significant digits. Until fairly recently that level of precision hasn't been available outside of packed decimal or similar. And it's a huge reason why COBOL is still the most popular programming language - the last estimate I saw was two billion lines of new code every year (and growing). Interestingly enough, even the 8086 supported a packed decimal format. Very limited (one byte - two decimal digits), but the support is there. Just no one seems to have ever used it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-11-29 11:50 +0100 |
| Message-ID | <ovm3di$vgs$1@dont-email.me> |
| In reply to | #123434 |
On 24/11/2017 15:18, Jerry Stuckle wrote: > On 11/24/2017 3:44 AM, Noob wrote: >> On 23/11/2017 14:11, F. Russell wrote: >> >>> On Wed, 22 Nov 2017 09:39:20 -0800, luser droog wrote: >>> >>>> https://www.youtube.com/watch?v=PZRI1IfStY0 >>> >>> It is incorrect to say that the digital floating point format >>> cannot "do money." The inability to "do money" applies only >>> to the *binary* floating point format. >>> >>> However, the *decimal* floating point format (DFP), which is >>> based on powers of 10 rather than 2, can perform financial >>> calculations with perfect accuracy. DFP is codified in the >>> IEEE 754-2008 international standard and this standard is >>> already implemented in hardware on the IBM Power processors. >>> Intel hardware is sadly way behind the times. >>> >>> But software DFP libraries exist for Intel and other "antiquated" >>> systems (C libraries of course). >> >> I have a naive question. >> >> Why would someone want to use floating point for currency? >> >> Why not use 64-bit integers, and work with fractions of the >> currency as the base unit, e.g. 1/10^3 or 1/10^6 depending >> on how many decimals one might need. >> >> Hmmm, I suppose that's just fixed point arithmetic. It works >> well for add, sub. Is there a need for mul and div? > > They could, but it hasn't been until relatively recently that 64 bit > integers were supported by the hardware. I believe 64-bit computers have been available for some time. (e.g. MIPS and Alpha in the 90s, AMD and Intel in the 00s) https://en.wikipedia.org/wiki/64-bit_computing > And even now, there's a lot of hardware which doesn't support 64 bit > integers - at least directly. What kind of hardware do you have in mind? (Atom? ARM?) Why would financial institutions use such hardware? > And yes, there is a huge need for multiplication and division for money. > The most obvious example is figuring interest on a savings account. > But there's a lot more - from figuring loan payments to actuarial work > buy insurance companies. Indeed! I should have thought of that. > And financial institutions, insurance companies, governments and more in > the U.S. usually carry financial calculations to six decimal places with > a maximum of at least 99 billion dollars - which means 17 significant > digits. 2**64 = 1.8e19 Using one millionth dollars as the base unit, we can express values from 0 to 18000 billion dollars. But I guess this doesn't solve rounding issues, which have to be dealt with when multiplying. I'll write a toy program to experiment with that :-) > Until fairly recently that level of precision hasn't been > available outside of packed decimal or similar. And it's a huge reason > why COBOL is still the most popular programming language - the last > estimate I saw was two billion lines of new code every year (and growing). Your "fairly recently" comment appears to be in the context of COBOL, which has been available since the 60s. 20 years ago may be considered recently compared to 60 years ago :-) Regards.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-11-29 16:13 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <ovmirc$cs7$1@dont-email.me> |
| In reply to | #123598 |
On 29/11/2017 11:50, Noob wrote:
> 2**64 = 1.8e19
> Using one millionth dollars as the base unit, we can express
> values from 0 to 18000 billion dollars.
>
> But I guess this doesn't solve rounding issues, which have to
> be dealt with when multiplying.
>
> I'll write a toy program to experiment with that :-)
I played around with a different approach: storing the integral part
in a u64, and the fractional part (in billionth) in a u32 (effectively
~94 significant bits). I'm still not quite sure how to handle rounding.
#include <stdio.h>
#include <stdlib.h>
typedef unsigned __int128 u128;
typedef unsigned long long u64;
typedef unsigned int u32;
typedef struct {
u64 ip; /* integer part, in currency */
u32 fp; /* fractional part, in nano-currency */
} currency;
#define GIGA 1000000000u
void print_currency(currency *val)
{
printf("%19llu.%09u\n", val->ip, val->fp);
}
void add(currency *res, currency v1, currency v2)
{
u32 fp_sum = v1.fp + v2.fp;
u64 ip_sum = v1.ip + v2.ip;
if (fp_sum >= GIGA) {
ip_sum += 1;
fp_sum -= GIGA;
}
res->ip = ip_sum;
res->fp = fp_sum;
}
void mul(currency *res, currency v1, u32 ppb)
{
u64 msw = v1.ip * (u64)ppb;
u64 lsw = v1.fp * (u64)ppb;
currency t1 = { msw / GIGA, msw % GIGA };
currency t2 = { 0, lsw / GIGA };
if (lsw % GIGA >= GIGA / 2) ++t2.fp; /* Round here? */
add(res, t1, t2);
}
int main(int argc, char **argv)
{
u64 ip = strtoull(argv[1], NULL, 0);
u32 fp = strtoul (argv[2], NULL, 0);
currency res, val = { ip, fp };
mul(&res, val, 230000000); /* 23% */
print_currency(&val);
print_currency(&res);
return 0;
}
Regards.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-11-29 16:53 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <ovml54$vg2$1@dont-email.me> |
| In reply to | #123603 |
On 29/11/2017 16:13, Noob wrote:
> void mul(currency *res, currency v1, u32 ppb)
> {
> u64 msw = v1.ip * (u64)ppb;
And there's a bug right there, because the result is likely
to overflow a u64.
$ gcc-7 -O2 -Wall money.c && ./a.out 123456789123456 777888999
123456789123456.777888999
5522368956.058977446
Back to the drawing board :-)
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-11-29 10:42 -0600 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <q7nt1d1sd4p5pl10b9k5igu4sq0ik7m2f7@4ax.com> |
| In reply to | #123603 |
On Wed, 29 Nov 2017 16:13:48 +0100, Noob <root@127.0.0.1> wrote:
>On 29/11/2017 11:50, Noob wrote:
>
>> 2**64 = 1.8e19
>> Using one millionth dollars as the base unit, we can express
>> values from 0 to 18000 billion dollars.
>>
>> But I guess this doesn't solve rounding issues, which have to
>> be dealt with when multiplying.
>>
>> I'll write a toy program to experiment with that :-)
>
>I played around with a different approach: storing the integral part
>in a u64, and the fractional part (in billionth) in a u32 (effectively
>~94 significant bits). I'm still not quite sure how to handle rounding.
>
>
>#include <stdio.h>
>#include <stdlib.h>
>
>typedef unsigned __int128 u128;
>typedef unsigned long long u64;
>typedef unsigned int u32;
>
>typedef struct {
> u64 ip; /* integer part, in currency */
> u32 fp; /* fractional part, in nano-currency */
>} currency;
>
>#define GIGA 1000000000u
>
>void print_currency(currency *val)
>{
> printf("%19llu.%09u\n", val->ip, val->fp);
>}
>
>void add(currency *res, currency v1, currency v2)
>{
> u32 fp_sum = v1.fp + v2.fp;
> u64 ip_sum = v1.ip + v2.ip;
>
> if (fp_sum >= GIGA) {
> ip_sum += 1;
> fp_sum -= GIGA;
> }
>
> res->ip = ip_sum;
> res->fp = fp_sum;
>}
>
>void mul(currency *res, currency v1, u32 ppb)
>{
> u64 msw = v1.ip * (u64)ppb;
> u64 lsw = v1.fp * (u64)ppb;
>
> currency t1 = { msw / GIGA, msw % GIGA };
> currency t2 = { 0, lsw / GIGA };
> if (lsw % GIGA >= GIGA / 2) ++t2.fp; /* Round here? */
> add(res, t1, t2);
>}
>
>int main(int argc, char **argv)
>{
> u64 ip = strtoull(argv[1], NULL, 0);
> u32 fp = strtoul (argv[2], NULL, 0);
> currency res, val = { ip, fp };
> mul(&res, val, 230000000); /* 23% */
> print_currency(&val);
> print_currency(&res);
> return 0;
>}
You have just implemented a limited, and slightly odd, bignum (or at
least, multiple precision) library.
You'd need to analyze the use cases to make sure you're retained
enough precision right of the decimal point with just nine digits
there, but that would often be enough.
But it would be good for intermediate results in many cases.
Rounding will need to be done with an understanding of the storage
format. Say you multiply a dollar amount by a percentage, say
(12345,670000000)*(81250000) (IOW $12345.67 * 8.125%), and you were
storing this as another dollars and cents value, the rounding would
have to be at the 10-millions place in the fractional part, for other
result formats, it might be elsewhere. Second, rounding often needs
to be done at the end of a series of calculations, not at the
intermediate operations (IOW compute a=b*c*d often needs *one*
rounding, just before the assignment).
The question is if this is sufficiently simpler than just doing a
proper 128 bit type. If you had a 128 bit type, and you did:
u64 result = (u128)currencyinpennies64 * percentage / 100000;
I'd expect a competent compiler to generate (on x86-64) one
multiplication instruction and two divisions. On x86-32, two
multiplications and three divisions (and sundry other simple
operations) (obviously that also ignores rounding).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-11-29 09:25 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <lnvahtxai3.fsf@kst-u.example.com> |
| In reply to | #123603 |
Noob <root@127.0.0.1> writes:
> On 29/11/2017 11:50, Noob wrote:
>
>> 2**64 = 1.8e19
>> Using one millionth dollars as the base unit, we can express
>> values from 0 to 18000 billion dollars.
>>
>> But I guess this doesn't solve rounding issues, which have to
>> be dealt with when multiplying.
>>
>> I'll write a toy program to experiment with that :-)
>
> I played around with a different approach: storing the integral part
> in a u64, and the fractional part (in billionth) in a u32 (effectively
> ~94 significant bits). I'm still not quite sure how to handle rounding.
[...]
As I understand it, there are specific rules, in laws and/or
regulations, that govern exactly how rounding is to be performed.
I have no idea what those rules are (I've never particularly needed
to know). If I were going to work on production software that
deals with money, I'd have to learn them.
If you're writing something for your own use, say to balance your
checkbook, and a 1-cent error on an interest calculation isn't fatal,
you probably don't need to worry about it.
--
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 | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-11-29 19:38 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <ovmuqj$cgs$1@dont-email.me> |
| In reply to | #123610 |
On 29/11/2017 18:25, Keith Thompson wrote: > If you're writing something for your own use, say to balance your > checkbook, and a 1-cent error on an interest calculation isn't fatal, > you probably don't need to worry about it. I would definitely *not* need 94 digits to balance my checkbook ;-) Regards.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-11-29 11:03 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <lnr2sgykjb.fsf@kst-u.example.com> |
| In reply to | #123612 |
Noob <root@127.0.0.1> writes:
> On 29/11/2017 18:25, Keith Thompson wrote:
>> If you're writing something for your own use, say to balance your
>> checkbook, and a 1-cent error on an interest calculation isn't fatal,
>> you probably don't need to worry about it.
>
> I would definitely *not* need 94 digits to balance my checkbook ;-)
If you have an interest-bearing account, and an interest payment
increases your balance by an amount very very close to 0.5 cents,
you might need some large number of digits to determine which way
to round.
--
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 | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-11-29 19:14 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <sGDTB.97528$3X1.57428@fx28.am4> |
| In reply to | #123615 |
On 29/11/2017 19:03, Keith Thompson wrote: > Noob <root@127.0.0.1> writes: >> On 29/11/2017 18:25, Keith Thompson wrote: >>> If you're writing something for your own use, say to balance your >>> checkbook, and a 1-cent error on an interest calculation isn't fatal, >>> you probably don't need to worry about it. >> >> I would definitely *not* need 94 digits to balance my checkbook ;-) > > If you have an interest-bearing account, and an interest payment > increases your balance by an amount very very close to 0.5 cents, > you might need some large number of digits to determine which way > to round. That might not help. Even if you have a million digits, one machine might result in 0.4999...9999, and another 0.5000...0001, and they will round in different ways to get 0.0 and 1.0 cents. A strategy needs to be used that will always yield the same result. Using integers won't help either (for working out interest), without specifying exactly how such calculations are to be done. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-11-29 11:31 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <lnmv34yj9l.fsf@kst-u.example.com> |
| In reply to | #123618 |
bartc <bc@freeuk.com> writes:
> On 29/11/2017 19:03, Keith Thompson wrote:
>> Noob <root@127.0.0.1> writes:
>>> On 29/11/2017 18:25, Keith Thompson wrote:
>>>> If you're writing something for your own use, say to balance your
>>>> checkbook, and a 1-cent error on an interest calculation isn't fatal,
>>>> you probably don't need to worry about it.
>>>
>>> I would definitely *not* need 94 digits to balance my checkbook ;-)
>>
>> If you have an interest-bearing account, and an interest payment
>> increases your balance by an amount very very close to 0.5 cents,
>> you might need some large number of digits to determine which way
>> to round.
>
> That might not help. Even if you have a million digits, one machine
> might result in 0.4999...9999, and another 0.5000...0001, and they will
> round in different ways to get 0.0 and 1.0 cents.
>
> A strategy needs to be used that will always yield the same result.
>
> Using integers won't help either (for working out interest), without
> specifying exactly how such calculations are to be done.
Here's an example of the rules for converting between pre-Euro
nationatal currencies and Euros:
ARTICLE 4; The conversion rates shall be adopted as one euro
expressed in terms of each of the national currencies. They
shall be adopted with six significant figures. The conversion
rates themselves must not be rounded or truncated when
making conversions. The conversion rates shall be used for
conversions either way between the euro and the national
currency units. Inverse rates derived from the conversion
rates shall not be used. Monetary amounts to be converted
from one national currency unit into another shall first be
converted into a monetary amount expressed in the euro unit,
which amount may be rounded to not less than three decimal
places and shall then be converted into the other national
currency unit. No alternative method of calculation may be used,
unless it produces the same result.
ARTICLE 5; Monetary amounts to be paid or accounted for,
when a rounding takes place after a conversion into the euro
unit according to article 4, shall be rounded up or down to the
nearest cent, Monetary amounts to be paid or accounted for which
are converted into a national currency unit shall be rounded up
or down to the nearest sub-unit, or in the absence of a sub-unit
to the nearest unit or according to national law or practice to
a multiple or fraction of the sub-unit or unit of the national
currency unit. If the application of the conversion rates gives
a result which is exactly half-way, the sum shall be rounded up.
http://www.sysmod.com/eurofaq.htm#ROUNDING
This all appears to be specified in terms of decimal representations.
The phrase "not less than three decimal places" is suprisingly
ambiguous; I can imagine cases where the decision to use, say,
4 vs. 5 decimal places might yield results that differ by 1 cent.
There are, as I understand it, a *lot* of written rules like this
in various contexts. I think consistency of results is generally
considered more important than mathematical perfection. You might
need 94 or more digits, or even arbitrarily many digits, to compute
a correctly rounded interest payment, but there are bound to be
financial regulations in place that specify the rounding without
requiring ludicrous precision. And you might get into some trouble
if you do a computation using more precision than the regulations
specify, if you end up with a different result.
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-12-01 00:04 -0600 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <orr12dluo9ig717bogvrm4ssokvd128760@4ax.com> |
| In reply to | #123618 |
On Wed, 29 Nov 2017 19:14:42 +0000, bartc <bc@freeuk.com> wrote:
>On 29/11/2017 19:03, Keith Thompson wrote:
>> Noob <root@127.0.0.1> writes:
>>> On 29/11/2017 18:25, Keith Thompson wrote:
>>>> If you're writing something for your own use, say to balance your
>>>> checkbook, and a 1-cent error on an interest calculation isn't fatal,
>>>> you probably don't need to worry about it.
>>>
>>> I would definitely *not* need 94 digits to balance my checkbook ;-)
>>
>> If you have an interest-bearing account, and an interest payment
>> increases your balance by an amount very very close to 0.5 cents,
>> you might need some large number of digits to determine which way
>> to round.
>
>That might not help. Even if you have a million digits, one machine
>might result in 0.4999...9999, and another 0.5000...0001, and they will
>round in different ways to get 0.0 and 1.0 cents.
>
>A strategy needs to be used that will always yield the same result.
>
>Using integers won't help either (for working out interest), without
>specifying exactly how such calculations are to be done.
For calculations that cannot be represented as rational numbers (like
exponentiation operations for interest calculations), there's usually
a rule along the lines of "compute to nine places past the decimal
point, then round". The exact amount will vary by the standard. For
example, MSRB's (municipal bonds and such) rule is:
"(d) Standards of Accuracy; Truncation.
(i) Intermediate Values. All values used in computations of
accrued interest, yield, and dollar price shall be computed to not
less than ten decimal places.
(ii) Results of Computations. Results of computations shall be
presented in accordance with the following:
(A) Accrued interest shall be truncated to three decimal
places, and rounded to two decimal places immediately prior to
presentation of total accrued interest amount on the confirmation;
(B) Dollar prices shall be truncated to three decimal places
immediately prior to presentation of dollar price on the confirmation
and computation of extended principal; and
(C) Yields shall be truncated to four decimal places, and
rounded to three decimal places, provided, however, that for purposes
of confirmation display as required under rule G-15(a) yields accurate
to the nearest .05 percentage points shall be deemed satisfactory.
Numbers shall be rounded, where required, in the following manner:
if the last digit after truncation is five or above, the preceding
digit shall be increased to the next highest number, and the last
digit shall be discarded."
http://www.msrb.org/Rules-and-Interpretations/MSRB-Rules/General/Rule-G-33.aspx#_d
[toc] | [prev] | [next] | [standalone]
Page 1 of 14 [1] 2 3 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web