Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #91879 > unrolled thread
| Started by | Real Troll <real.troll@trolls.com> |
|---|---|
| First post | 2016-08-07 17:59 -0400 |
| Last post | 2016-08-10 15:00 -0500 |
| Articles | 20 on this page of 123 — 23 participants |
Back to article view | Back to comp.lang.c
Float Vs Double Real Troll <real.troll@trolls.com> - 2016-08-07 17:59 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-07 23:38 +0100
Re: Float Vs Double Real Troll <real.troll@trolls.com> - 2016-08-07 18:55 -0400
Re: Float Vs Double jameskuyper@verizon.net - 2016-08-07 16:43 -0700
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-07 19:36 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 04:05 +0100
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-07 20:41 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 11:41 +0100
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 04:23 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 23:45 +0100
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-10 03:26 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 01:00 +0100
Re: Float Vs Double jameskuyper@verizon.net - 2016-08-08 08:52 -0700
Re: Float Vs Double James Kuyper <jameskuyper@verizon.net> - 2016-08-08 11:58 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 10:06 -0700
Re: Float Vs Double "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-08 19:46 -0400
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:29 -0400
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 14:04 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:00 -0400
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 18:43 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 14:34 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 12:00 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 16:42 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 14:04 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:48 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-10 03:22 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-21 18:31 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-08-22 08:39 -0700
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-22 19:29 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-22 19:24 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 01:01 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-22 21:58 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 09:38 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 08:15 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 15:07 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 09:40 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 15:14 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 10:38 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 17:18 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 15:47 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 16:39 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 11:45 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 21:42 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 15:52 -0400
Re: Float Vs Double Ian Collins <ian-news@hotmail.com> - 2016-08-24 08:36 +1200
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-24 09:39 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:31 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 10:48 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 08:17 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 06:01 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 09:44 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 07:19 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 10:39 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 08:18 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 14:47 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 10:40 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 01:31 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 20:53 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-08-23 23:20 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:32 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-24 09:46 +0200
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 14:53 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:35 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 08:57 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 17:36 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 12:50 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 17:26 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 12:51 -0400
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:33 -0400
Re: Float Vs Double Robert Wessel <robertwessel2@yahoo.com> - 2016-08-28 02:33 -0500
Re: Float Vs Double antispam@math.uni.wroc.pl - 2016-08-31 22:36 +0000
Re: Float Vs Double supercat@casperkitty.com - 2016-08-31 15:51 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:42 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-09-01 08:32 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 15:00 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-09-01 13:45 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 20:50 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-09-02 08:11 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 12:25 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-09-02 20:42 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 16:25 -0400
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-03 08:43 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 10:48 -0400
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-03 19:43 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 18:16 -0400
Re: Float Vs Double asetofsymbols@gmail.com - 2016-09-08 11:18 -0700
Re: Float Vs Double Robert Wessel <robertwessel2@yahoo.com> - 2016-09-07 19:59 -0500
Re: Float Vs Double supercat@casperkitty.com - 2016-09-08 08:13 -0700
Re: Float Vs Double Robert Wessel <robertwessel2@yahoo.com> - 2016-09-08 19:34 -0500
Re: Float Vs Double supercat@casperkitty.com - 2016-09-09 07:50 -0700
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-02 23:40 -0700
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-03 09:06 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 10:52 -0400
Re: Float Vs Double Rosario19 <Ros@invalid.invalid> - 2016-08-24 08:57 +0200
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 01:04 -0700
Re: Float Vs Double Ike Naar <ike@iceland.freeshell.org> - 2016-08-08 06:44 +0000
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-08 00:16 -0700
Re: Float Vs Double Richard Damon <Richard@Damon-Family.org> - 2016-08-08 23:29 -0400
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 14:03 +0200
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-08 05:14 -0700
Re: Float Vs Double BGB <cr88192@hotmail.com> - 2016-08-09 19:53 -0500
Re: Float Vs Double "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-07 18:47 -0400
Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 17:04 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-08 05:49 -0700
Re: Float Vs Double Nobody <nobody@nowhere.invalid> - 2016-08-10 03:26 +0100
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-09 20:15 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-10 06:07 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-10 06:13 -0700
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-10 16:43 +0200
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-10 07:56 -0700
Re: Float Vs Double supercat@casperkitty.com - 2016-08-10 08:39 -0700
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 09:56 -0700
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 10:04 -0700
Re: Float Vs Double Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-11 07:08 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-11 07:15 -0700
Re: Float Vs Double Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-12 08:11 -0700
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-10 20:38 +0200
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 12:20 -0700
Re: Float Vs Double supercat@casperkitty.com - 2016-08-10 12:17 -0700
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-10 21:48 +0200
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 13:40 -0700
Re: Float Vs Double Ian Collins <ian-news@hotmail.com> - 2016-08-12 08:01 +1200
Re: Float Vs Double BGB <cr88192@hotmail.com> - 2016-08-10 15:00 -0500
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-08 14:34 -0400 |
| Message-ID | <noajbb$6ev$2@jstuckle.eternal-september.org> |
| In reply to | #91972 |
On 8/8/2016 12:43 PM, jacobnavia wrote: > Le 08/08/2016 à 15:00, Jerry Stuckle a écrit : >> On 8/8/2016 8:04 AM, jacobnavia wrote: >>> Le 08/08/2016 à 03:29, Jerry Stuckle a écrit : >>>> You use a language better suited to higher precision. C is not the >>>> best >>>> language for everything. >>> >>> You are just not up to date. >>> >>> Use lcc-win! >>> >>> lcc-win offers >>> >>> 1) Real long double (80 bits) support with approx 19 decimal digits >>> 2) 128 bit IEEE double precision with around 30 decimal digits >>> 3) Qfloat numbers with approx 130 (!!!) digits precision >>> >>> >> >> Oh, I'm up to date. But you're using a compiler for a single OS with >> non-standard extensions that can change at any time. Not something I >> recommend for long-term development. >> > > One of my customers is MATLAB, and that since I started this project, in > 1995. > > I am still here, but COMPAQ disappeared, Borland disappeared, and many > other "BIG" companies disappeared. > > Another customer, is using my JIT under Macintosh OS X and linux. You > just speak your prejudices against my work. > > By the way my extensions are foreseen in the standard, since it > explicitly says that implementation might provide numbers of greater > precision. > No prejudices against your work. Your extensions are not part of the standard, and only have limited availability. Those are enough for me to not use them. As for the "big companies" - they may still be around, but their ex-employees are (at least most of them). So this is another fallacious argument on your part. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-08 12:00 -0700 |
| Message-ID | <41c4843e-bc27-48f6-af0d-07fd1400b5db@googlegroups.com> |
| In reply to | #91980 |
On Monday, August 8, 2016 at 7:34:28 PM UTC+1, Jerry Stuckle wrote: > > No prejudices against your work. Your extensions are not part of the > standard, and only have limited availability. Those are enough for me > to not use them. > > As for the "big companies" - they may still be around, but their > ex-employees are (at least most of them). So this is another fallacious > argument on your part. > If you need high precision arithmetic, Jacob's compiler allows you to use it simply be declaring variables of the extended type. But it's possible the code will need to be compiled under an environment that doesn't support it. So change the file extension to C++ and supply the extended precision type as a class with operator overloads.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-08 16:42 -0400 |
| Message-ID | <noaqrq$4kl$1@jstuckle.eternal-september.org> |
| In reply to | #91985 |
On 8/8/2016 3:00 PM, Malcolm McLean wrote: > On Monday, August 8, 2016 at 7:34:28 PM UTC+1, Jerry Stuckle wrote: >> >> No prejudices against your work. Your extensions are not part of the >> standard, and only have limited availability. Those are enough for me >> to not use them. >> >> As for the "big companies" - they may still be around, but their >> ex-employees are (at least most of them). So this is another fallacious >> argument on your part. >> > If you need high precision arithmetic, Jacob's compiler allows you to > use it simply be declaring variables of the extended type. > But it's possible the code will need to be compiled under an > environment that doesn't support it. So change the file extension > to C++ and supply the extended precision type as a class with > operator overloads. > > That's fine if you can use C++. But it's not always possible (or desirable). -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-08 14:04 -0700 |
| Message-ID | <74cabdab-6774-491d-b514-e56506ee5113@googlegroups.com> |
| In reply to | #91993 |
On Monday, August 8, 2016 at 9:42:42 PM UTC+1, Jerry Stuckle wrote: > On 8/8/2016 3:00 PM, Malcolm McLean wrote: > > On Monday, August 8, 2016 at 7:34:28 PM UTC+1, Jerry Stuckle wrote: > >> > >> No prejudices against your work. Your extensions are not part of the > >> standard, and only have limited availability. Those are enough for me > >> to not use them. > >> > >> As for the "big companies" - they may still be around, but their > >> ex-employees are (at least most of them). So this is another fallacious > >> argument on your part. > >> > > If you need high precision arithmetic, Jacob's compiler allows you to > > use it simply be declaring variables of the extended type. > > But it's possible the code will need to be compiled under an > > environment that doesn't support it. So change the file extension > > to C++ and supply the extended precision type as a class with > > operator overloads. > > > > > > That's fine if you can use C++. But it's not always possible (or > desirable). > Or you can develop the algorithm on Jacob's compiler, then translate to an unreadable version that calls functions for arithmetical operations. At a certain level of complexity that will become unfeasible. Sometimes one must eventually give up.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-09 08:48 -0400 |
| Message-ID | <nocjej$82v$1@jstuckle.eternal-september.org> |
| In reply to | #91995 |
On 8/8/2016 5:04 PM, Malcolm McLean wrote: > On Monday, August 8, 2016 at 9:42:42 PM UTC+1, Jerry Stuckle wrote: >> On 8/8/2016 3:00 PM, Malcolm McLean wrote: >>> On Monday, August 8, 2016 at 7:34:28 PM UTC+1, Jerry Stuckle wrote: >>>> >>>> No prejudices against your work. Your extensions are not part of the >>>> standard, and only have limited availability. Those are enough for me >>>> to not use them. >>>> >>>> As for the "big companies" - they may still be around, but their >>>> ex-employees are (at least most of them). So this is another fallacious >>>> argument on your part. >>>> >>> If you need high precision arithmetic, Jacob's compiler allows you to >>> use it simply be declaring variables of the extended type. >>> But it's possible the code will need to be compiled under an >>> environment that doesn't support it. So change the file extension >>> to C++ and supply the extended precision type as a class with >>> operator overloads. >>> >>> >> >> That's fine if you can use C++. But it's not always possible (or >> desirable). >> > Or you can develop the algorithm on Jacob's compiler, then translate > to an unreadable version that calls functions for arithmetical > operations. At a certain level of complexity that will become > unfeasible. Sometimes one must eventually give up. > Or you can just use a language which supports higher precision in the first place. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-10 03:22 -0700 |
| Message-ID | <ae1ae857-1e93-41c4-bb64-2df6eb08f30e@googlegroups.com> |
| In reply to | #92010 |
On Tuesday, August 9, 2016 at 1:48:35 PM UTC+1, Jerry Stuckle wrote: > On 8/8/2016 5:04 PM, Malcolm McLean wrote: > > >> That's fine if you can use C++. But it's not always possible (or > >> desirable). > >> > > Or you can develop the algorithm on Jacob's compiler, then translate > > to an unreadable version that calls functions for arithmetical > > operations. At a certain level of complexity that will become > > unfeasible. Sometimes one must eventually give up. > > > > Or you can just use a language which supports higher precision in the > first place. > You can use a language which supports higher precision in the first place, and often that will be a sensible choice. If you're writing programs to explore mathematical functions, something like Maple which store intermediates like sqrt(2) as "root two" rather than "1.4 and a bit", is probably a good way to go. But Maple itself is implemented in C. You can't "just" use another language, only if you know that the code will only ever need to be compiled and run under an environment where that language is acceptable. If we use Jacob's extended precision arithmetic, code will of course break if we need to move to an embedded system where lcc-win is unavailable. But only lightly, it's a short job for a medium-skilled person to write multi-precison emulation and go through the source replacing operators with calls. Trying to translate Maple to C is a lot harder.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-21 18:31 -0400 |
| Message-ID | <npda3a$sef$1@jstuckle.eternal-september.org> |
| In reply to | #92051 |
On 8/10/2016 6:22 AM, Malcolm McLean wrote: > On Tuesday, August 9, 2016 at 1:48:35 PM UTC+1, Jerry Stuckle wrote: >> On 8/8/2016 5:04 PM, Malcolm McLean wrote: >> >>>> That's fine if you can use C++. But it's not always possible (or >>>> desirable). >>>> >>> Or you can develop the algorithm on Jacob's compiler, then translate >>> to an unreadable version that calls functions for arithmetical >>> operations. At a certain level of complexity that will become >>> unfeasible. Sometimes one must eventually give up. >>> >> >> Or you can just use a language which supports higher precision in the >> first place. >> > You can use a language which supports higher precision in the first place, > and often that will be a sensible choice. If you're writing programs to explore > mathematical functions, something like Maple which store intermediates > like sqrt(2) as "root two" rather than "1.4 and a bit", is probably a good way > to go. > But Maple itself is implemented in C. You can't "just" use another language, > only if you know that the code will only ever need to be compiled and run > under an environment where that language is acceptable. If we use Jacob's > extended precision arithmetic, code will of course break if we need to move > to an embedded system where lcc-win is unavailable. But only lightly, it's a > short job for a medium-skilled person to write multi-precison emulation and > go through the source replacing operators with calls. Trying to translate Maple > to C is a lot harder. > And you can only use Maple in an environment where it is acceptable. That is true for any program in any language. It may be a short job for a medium-skilled person to write a multi-precision emulation. But to do it efficiently is another story. And when you're talking high precision, often times efficiency in such a library is important, due to the number of calculations involved. For instance - I've seen it implemented as storing the digits in a string. Quite easy to implement - but performance was terrible, as you can imagine. OTOH, I implemented one back in the 80's based on two digits per byte, using 808x assembler. Much faster, but not portable and not all that easy. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-22 08:39 -0700 |
| Message-ID | <43d67165-178e-4745-9943-d2475cb58615@googlegroups.com> |
| In reply to | #92571 |
On Sunday, August 21, 2016 at 5:31:13 PM UTC-5, Jerry Stuckle wrote: > For instance - I've seen it implemented as storing the digits in a > string. Quite easy to implement - but performance was terrible, as you > can imagine. OTOH, I implemented one back in the 80's based on two > digits per byte, using 808x assembler. Much faster, but not portable > and not all that easy. I'm surprised I haven't seen more "decimal math" libraries using 9 digits per word; such a thing would seem like a natural fit on a 32-bit processor with a 32x32->64 multiply. Performance would be likely slower than for binary math, but nowhere near as slow as using single-digit or two-digit chunks (on processors which can't use a carry flag for extended-precision math, addition and subtraction could benefit from the fact that the sum or difference of any two 9-digit chunks could fit in a 32-bit signed "int").
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-08-22 19:29 +0200 |
| Message-ID | <8737lwww36.fsf@news.bourguet.org> |
| In reply to | #92584 |
supercat@casperkitty.com writes: > On Sunday, August 21, 2016 at 5:31:13 PM UTC-5, Jerry Stuckle wrote: >> For instance - I've seen it implemented as storing the digits in a >> string. Quite easy to implement - but performance was terrible, as you >> can imagine. OTOH, I implemented one back in the 80's based on two >> digits per byte, using 808x assembler. Much faster, but not portable >> and not all that easy. > > I'm surprised I haven't seen more "decimal math" libraries using 9 digits > per word; such a thing would seem like a natural fit on a 32-bit processor > with a 32x32->64 multiply. Performance would be likely slower than for > binary math, Depending on the load. I've used that in some cases where the gain on the simplified decimal IO was enough to overcome the increased cost of other operations. Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-22 19:24 -0400 |
| Message-ID | <npg1jd$b3k$2@jstuckle.eternal-september.org> |
| In reply to | #92584 |
On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote: > On Sunday, August 21, 2016 at 5:31:13 PM UTC-5, Jerry Stuckle wrote: >> For instance - I've seen it implemented as storing the digits in a >> string. Quite easy to implement - but performance was terrible, as you >> can imagine. OTOH, I implemented one back in the 80's based on two >> digits per byte, using 808x assembler. Much faster, but not portable >> and not all that easy. > > I'm surprised I haven't seen more "decimal math" libraries using 9 digits > per word; such a thing would seem like a natural fit on a 32-bit processor > with a 32x32->64 multiply. Performance would be likely slower than for > binary math, but nowhere near as slow as using single-digit or two-digit > chunks (on processors which can't use a carry flag for extended-precision > math, addition and subtraction could benefit from the fact that the sum > or difference of any two 9-digit chunks could fit in a 32-bit signed "int"). > 9 digits per word would not be decimal math. The most you could get into 32 bits would be 8 decimal digits. And I suspect trying it would be even slower than decimal math. It would be much more complicated to implement. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-23 01:01 +0100 |
| Message-ID | <874m6ctktg.fsf@bsb.me.uk> |
| In reply to | #92610 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote: >> On Sunday, August 21, 2016 at 5:31:13 PM UTC-5, Jerry Stuckle wrote: >>> For instance - I've seen it implemented as storing the digits in a >>> string. Quite easy to implement - but performance was terrible, as you >>> can imagine. OTOH, I implemented one back in the 80's based on two >>> digits per byte, using 808x assembler. Much faster, but not portable >>> and not all that easy. >> >> I'm surprised I haven't seen more "decimal math" libraries using 9 digits >> per word; such a thing would seem like a natural fit on a 32-bit processor >> with a 32x32->64 multiply. Performance would be likely slower than for >> binary math, but nowhere near as slow as using single-digit or two-digit >> chunks (on processors which can't use a carry flag for extended-precision >> math, addition and subtraction could benefit from the fact that the sum >> or difference of any two 9-digit chunks could fit in a 32-bit signed "int"). >> > > 9 digits per word would not be decimal math. The most you could get > into 32 bits would be 8 decimal digits. I think what supercat is talking about might otherwise be called base 1,000,000,000 arithmetic. > And I suspect trying it would > be even slower than decimal math. It would be much more complicated to > implement. In software, it's faster and simpler than using BCD-type schemes, but it's a matter of definition if is a decimal scheme or not. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-22 21:58 -0400 |
| Message-ID | <npgak4$13a$1@jstuckle.eternal-september.org> |
| In reply to | #92611 |
On 8/22/2016 8:01 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote: >>> On Sunday, August 21, 2016 at 5:31:13 PM UTC-5, Jerry Stuckle wrote: >>>> For instance - I've seen it implemented as storing the digits in a >>>> string. Quite easy to implement - but performance was terrible, as you >>>> can imagine. OTOH, I implemented one back in the 80's based on two >>>> digits per byte, using 808x assembler. Much faster, but not portable >>>> and not all that easy. >>> >>> I'm surprised I haven't seen more "decimal math" libraries using 9 digits >>> per word; such a thing would seem like a natural fit on a 32-bit processor >>> with a 32x32->64 multiply. Performance would be likely slower than for >>> binary math, but nowhere near as slow as using single-digit or two-digit >>> chunks (on processors which can't use a carry flag for extended-precision >>> math, addition and subtraction could benefit from the fact that the sum >>> or difference of any two 9-digit chunks could fit in a 32-bit signed "int"). >>> >> >> 9 digits per word would not be decimal math. The most you could get >> into 32 bits would be 8 decimal digits. > > I think what supercat is talking about might otherwise be called base > 1,000,000,000 arithmetic. > >> And I suspect trying it would >> be even slower than decimal math. It would be much more complicated to >> implement. > > In software, it's faster and simpler than using BCD-type schemes, but > it's a matter of definition if is a decimal scheme or not. > I understand what he's after, and my comments stand. For instance, how easy would it be to subtract 123.456 from 789012.345678? Not that hard with BCD, but very difficult with supercat's idea. Adjusting for the decimal point would not be easy. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-23 09:38 +0200 |
| Message-ID | <npgui2$hjt$1@dont-email.me> |
| In reply to | #92612 |
On 23/08/16 03:58, Jerry Stuckle wrote: > On 8/22/2016 8:01 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote: >>>> On Sunday, August 21, 2016 at 5:31:13 PM UTC-5, Jerry Stuckle wrote: >>>>> For instance - I've seen it implemented as storing the digits in a >>>>> string. Quite easy to implement - but performance was terrible, as you >>>>> can imagine. OTOH, I implemented one back in the 80's based on two >>>>> digits per byte, using 808x assembler. Much faster, but not portable >>>>> and not all that easy. >>>> >>>> I'm surprised I haven't seen more "decimal math" libraries using 9 digits >>>> per word; such a thing would seem like a natural fit on a 32-bit processor >>>> with a 32x32->64 multiply. Performance would be likely slower than for >>>> binary math, but nowhere near as slow as using single-digit or two-digit >>>> chunks (on processors which can't use a carry flag for extended-precision >>>> math, addition and subtraction could benefit from the fact that the sum >>>> or difference of any two 9-digit chunks could fit in a 32-bit signed "int"). >>>> >>> >>> 9 digits per word would not be decimal math. The most you could get >>> into 32 bits would be 8 decimal digits. >> >> I think what supercat is talking about might otherwise be called base >> 1,000,000,000 arithmetic. >> >>> And I suspect trying it would >>> be even slower than decimal math. It would be much more complicated to >>> implement. >> >> In software, it's faster and simpler than using BCD-type schemes, but >> it's a matter of definition if is a decimal scheme or not. >> > > I understand what he's after, and my comments stand. For instance, how > easy would it be to subtract 123.456 from 789012.345678? Not that hard > with BCD, but very difficult with supercat's idea. Adjusting for the > decimal point would not be easy. > That would depend on whether he is considering just integers (in which case arithmetic with a decimal point is /really/ hard!), or a representation supporting multiple 9-digit chunks (in which case, subtracting 000000123.456000000 from 000789012.345678000 would be quite simple), or something with a floating decimal point (which would be very messy). Personally, I don't think there would be anything much to be gained from base 1G formats, except perhaps in very niche cases.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-23 08:15 -0400 |
| Message-ID | <nphepg$1dn$3@jstuckle.eternal-september.org> |
| In reply to | #92615 |
On 8/23/2016 3:38 AM, David Brown wrote: > On 23/08/16 03:58, Jerry Stuckle wrote: >> On 8/22/2016 8:01 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote: >>>>> On Sunday, August 21, 2016 at 5:31:13 PM UTC-5, Jerry Stuckle wrote: >>>>>> For instance - I've seen it implemented as storing the digits in a >>>>>> string. Quite easy to implement - but performance was terrible, as you >>>>>> can imagine. OTOH, I implemented one back in the 80's based on two >>>>>> digits per byte, using 808x assembler. Much faster, but not portable >>>>>> and not all that easy. >>>>> >>>>> I'm surprised I haven't seen more "decimal math" libraries using 9 digits >>>>> per word; such a thing would seem like a natural fit on a 32-bit processor >>>>> with a 32x32->64 multiply. Performance would be likely slower than for >>>>> binary math, but nowhere near as slow as using single-digit or two-digit >>>>> chunks (on processors which can't use a carry flag for extended-precision >>>>> math, addition and subtraction could benefit from the fact that the sum >>>>> or difference of any two 9-digit chunks could fit in a 32-bit signed "int"). >>>>> >>>> >>>> 9 digits per word would not be decimal math. The most you could get >>>> into 32 bits would be 8 decimal digits. >>> >>> I think what supercat is talking about might otherwise be called base >>> 1,000,000,000 arithmetic. >>> >>>> And I suspect trying it would >>>> be even slower than decimal math. It would be much more complicated to >>>> implement. >>> >>> In software, it's faster and simpler than using BCD-type schemes, but >>> it's a matter of definition if is a decimal scheme or not. >>> >> >> I understand what he's after, and my comments stand. For instance, how >> easy would it be to subtract 123.456 from 789012.345678? Not that hard >> with BCD, but very difficult with supercat's idea. Adjusting for the >> decimal point would not be easy. >> > > That would depend on whether he is considering just integers (in which > case arithmetic with a decimal point is /really/ hard!), or a > representation supporting multiple 9-digit chunks (in which case, > subtracting 000000123.456000000 from 000789012.345678000 would be quite > simple), or something with a floating decimal point (which would be very > messy). > > Personally, I don't think there would be anything much to be gained from > base 1G formats, except perhaps in very niche cases. > > > The whole thread is about real numbers, not integers, David. And seldom do the numbers always have the same number of decimal places. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-23 15:07 +0200 |
| Message-ID | <nphhqp$db1$1@dont-email.me> |
| In reply to | #92617 |
On 23/08/16 14:15, Jerry Stuckle wrote: > On 8/23/2016 3:38 AM, David Brown wrote: >> On 23/08/16 03:58, Jerry Stuckle wrote: >>> On 8/22/2016 8:01 PM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote: >>>>>> On Sunday, August 21, 2016 at 5:31:13 PM UTC-5, Jerry Stuckle wrote: >>>>>>> For instance - I've seen it implemented as storing the digits in a >>>>>>> string. Quite easy to implement - but performance was terrible, as you >>>>>>> can imagine. OTOH, I implemented one back in the 80's based on two >>>>>>> digits per byte, using 808x assembler. Much faster, but not portable >>>>>>> and not all that easy. >>>>>> >>>>>> I'm surprised I haven't seen more "decimal math" libraries using 9 digits >>>>>> per word; such a thing would seem like a natural fit on a 32-bit processor >>>>>> with a 32x32->64 multiply. Performance would be likely slower than for >>>>>> binary math, but nowhere near as slow as using single-digit or two-digit >>>>>> chunks (on processors which can't use a carry flag for extended-precision >>>>>> math, addition and subtraction could benefit from the fact that the sum >>>>>> or difference of any two 9-digit chunks could fit in a 32-bit signed "int"). >>>>>> >>>>> >>>>> 9 digits per word would not be decimal math. The most you could get >>>>> into 32 bits would be 8 decimal digits. >>>> >>>> I think what supercat is talking about might otherwise be called base >>>> 1,000,000,000 arithmetic. >>>> >>>>> And I suspect trying it would >>>>> be even slower than decimal math. It would be much more complicated to >>>>> implement. >>>> >>>> In software, it's faster and simpler than using BCD-type schemes, but >>>> it's a matter of definition if is a decimal scheme or not. >>>> >>> >>> I understand what he's after, and my comments stand. For instance, how >>> easy would it be to subtract 123.456 from 789012.345678? Not that hard >>> with BCD, but very difficult with supercat's idea. Adjusting for the >>> decimal point would not be easy. >>> >> >> That would depend on whether he is considering just integers (in which >> case arithmetic with a decimal point is /really/ hard!), or a >> representation supporting multiple 9-digit chunks (in which case, >> subtracting 000000123.456000000 from 000789012.345678000 would be quite >> simple), or something with a floating decimal point (which would be very >> messy). >> >> Personally, I don't think there would be anything much to be gained from >> base 1G formats, except perhaps in very niche cases. >> >> >> > > The whole thread is about real numbers, not integers, David. And seldom > do the numbers always have the same number of decimal places. > Just because the thread is about real numbers, does not mean that Supercat is still talking about them! But I think that in many situations where you might be interested in tracking your numbers in decimal digit formats rather than floating point, scaled integer, or other binary formats, then you probably /do/ have a fixed number of decimal digits. Financial calculations would be an example. The exception would be in mathematical calculations where you want arbitrary precision in your decimal calculations. And in either case, I can't see why storing 9 digits in 32-bit chunks is going to be much more complicated than storing 1 or 2 digits in 8-bit chunks (BCD, packed or unpacked). It will certainly be more efficient for calculations. 18 digits in 64-bit chunks is going to be even better on modern cpus.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-23 09:40 -0400 |
| Message-ID | <nphjp1$k66$1@jstuckle.eternal-september.org> |
| In reply to | #92627 |
On 8/23/2016 9:07 AM, David Brown wrote: > On 23/08/16 14:15, Jerry Stuckle wrote: >> On 8/23/2016 3:38 AM, David Brown wrote: >>> On 23/08/16 03:58, Jerry Stuckle wrote: >>>> On 8/22/2016 8:01 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote: >>>>>>> On Sunday, August 21, 2016 at 5:31:13 PM UTC-5, Jerry Stuckle wrote: >>>>>>>> For instance - I've seen it implemented as storing the digits in a >>>>>>>> string. Quite easy to implement - but performance was terrible, as you >>>>>>>> can imagine. OTOH, I implemented one back in the 80's based on two >>>>>>>> digits per byte, using 808x assembler. Much faster, but not portable >>>>>>>> and not all that easy. >>>>>>> >>>>>>> I'm surprised I haven't seen more "decimal math" libraries using 9 digits >>>>>>> per word; such a thing would seem like a natural fit on a 32-bit processor >>>>>>> with a 32x32->64 multiply. Performance would be likely slower than for >>>>>>> binary math, but nowhere near as slow as using single-digit or two-digit >>>>>>> chunks (on processors which can't use a carry flag for extended-precision >>>>>>> math, addition and subtraction could benefit from the fact that the sum >>>>>>> or difference of any two 9-digit chunks could fit in a 32-bit signed "int"). >>>>>>> >>>>>> >>>>>> 9 digits per word would not be decimal math. The most you could get >>>>>> into 32 bits would be 8 decimal digits. >>>>> >>>>> I think what supercat is talking about might otherwise be called base >>>>> 1,000,000,000 arithmetic. >>>>> >>>>>> And I suspect trying it would >>>>>> be even slower than decimal math. It would be much more complicated to >>>>>> implement. >>>>> >>>>> In software, it's faster and simpler than using BCD-type schemes, but >>>>> it's a matter of definition if is a decimal scheme or not. >>>>> >>>> >>>> I understand what he's after, and my comments stand. For instance, how >>>> easy would it be to subtract 123.456 from 789012.345678? Not that hard >>>> with BCD, but very difficult with supercat's idea. Adjusting for the >>>> decimal point would not be easy. >>>> >>> >>> That would depend on whether he is considering just integers (in which >>> case arithmetic with a decimal point is /really/ hard!), or a >>> representation supporting multiple 9-digit chunks (in which case, >>> subtracting 000000123.456000000 from 000789012.345678000 would be quite >>> simple), or something with a floating decimal point (which would be very >>> messy). >>> >>> Personally, I don't think there would be anything much to be gained from >>> base 1G formats, except perhaps in very niche cases. >>> >>> >>> >> >> The whole thread is about real numbers, not integers, David. And seldom >> do the numbers always have the same number of decimal places. >> > > Just because the thread is about real numbers, does not mean that > Supercat is still talking about them! > Try again, stoopid. > But I think that in many situations where you might be interested in > tracking your numbers in decimal digit formats rather than floating > point, scaled integer, or other binary formats, then you probably /do/ > have a fixed number of decimal digits. Financial calculations would be > an example. > No, financial calculations are not an example. For instance, banks generally go at least six decimal places for monetary calculations, but may go four to eight for percentage calculations (depending on how often interest is calculated). And, of course, account transfers are only two decimal places. The are many different numbers of decimal places used in financial calculations. > The exception would be in mathematical calculations where you want > arbitrary precision in your decimal calculations. > More the rule than the exception. > And in either case, I can't see why storing 9 digits in 32-bit chunks is > going to be much more complicated than storing 1 or 2 digits in 8-bit > chunks (BCD, packed or unpacked). It will certainly be more efficient > for calculations. 18 digits in 64-bit chunks is going to be even better > on modern cpus. > Then you show how to subtract 123.456 from 789012.345678 using 18 digits in 64 bit chunks. I'd love to see you do it. But you've already shown you have no clue, so I won't hold my breath. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-23 15:14 +0100 |
| Message-ID | <87shtvr2rg.fsf@bsb.me.uk> |
| In reply to | #92631 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 8/23/2016 9:07 AM, David Brown wrote: <snip> >> And in either case, I can't see why storing 9 digits in 32-bit chunks is >> going to be much more complicated than storing 1 or 2 digits in 8-bit >> chunks (BCD, packed or unpacked). It will certainly be more efficient >> for calculations. 18 digits in 64-bit chunks is going to be even better >> on modern cpus. Maybe. The advantage of base 10^9 is that the result of any single digit multiplication fits in 64 bits. If you have a 64-bit to 128-bit multiply them, sure, use base 10^18, but if you don't, or you want to write the code in portable C, then 10^9 is probably better. > Then you show how to subtract 123.456 from 789012.345678 using 18 digits > in 64 bit chunks. I'd love to see you do it. It's the same as I showed for base 1,000,000,000 only base 10^18. The numbers are represented with two digits -- one before and one after the point. The position of the point is signalled with a count: (1, [789012, 345678000000000000]) - (1, [123, 456000000000000000]) Again, because 456000000000000000 > 345678000000000000 the subtraction involves a "borrow" to give: (1, [789012 - 123 - 1, 10^18 + 345678000000000000 - 456000000000000000]) > But you've already shown you have no clue, so I won't hold my breath. Ah, the insults are starting. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-23 10:38 -0400 |
| Message-ID | <nphn56$de$1@jstuckle.eternal-september.org> |
| In reply to | #92642 |
On 8/23/2016 10:14 AM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 8/23/2016 9:07 AM, David Brown wrote: > <snip> >>> And in either case, I can't see why storing 9 digits in 32-bit chunks is >>> going to be much more complicated than storing 1 or 2 digits in 8-bit >>> chunks (BCD, packed or unpacked). It will certainly be more efficient >>> for calculations. 18 digits in 64-bit chunks is going to be even better >>> on modern cpus. > > Maybe. The advantage of base 10^9 is that the result of any single > digit multiplication fits in 64 bits. If you have a 64-bit to 128-bit > multiply them, sure, use base 10^18, but if you don't, or you want to > write the code in portable C, then 10^9 is probably better. > The smart thing to do would be to store them as 32 (or 64) bit integers and let the processor do the multiplication in its native format. >> Then you show how to subtract 123.456 from 789012.345678 using 18 digits >> in 64 bit chunks. I'd love to see you do it. > > It's the same as I showed for base 1,000,000,000 only base 10^18. The > numbers are represented with two digits -- one before and one after the > point. The position of the point is signalled with a count: > > (1, [789012, 345678000000000000]) - (1, [123, 456000000000000000]) > > Again, because 456000000000000000 > 345678000000000000 the subtraction > involves a "borrow" to give: > > (1, [789012 - 123 - 1, 10^18 + 345678000000000000 - 456000000000000000]) > Total fail. Let's see some actual code to do it. >> But you've already shown you have no clue, so I won't hold my breath. > > Ah, the insults are starting. > The truth hurts, doesn't it? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-23 17:18 +0100 |
| Message-ID | <87d1kzqx02.fsf@bsb.me.uk> |
| In reply to | #92646 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 8/23/2016 10:14 AM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 8/23/2016 9:07 AM, David Brown wrote: >> <snip> >>>> And in either case, I can't see why storing 9 digits in 32-bit chunks is >>>> going to be much more complicated than storing 1 or 2 digits in 8-bit >>>> chunks (BCD, packed or unpacked). It will certainly be more efficient >>>> for calculations. 18 digits in 64-bit chunks is going to be even better >>>> on modern cpus. >> >> Maybe. The advantage of base 10^9 is that the result of any single >> digit multiplication fits in 64 bits. If you have a 64-bit to 128-bit >> multiply them, sure, use base 10^18, but if you don't, or you want to >> write the code in portable C, then 10^9 is probably better. > > The smart thing to do would be to store them as 32 (or 64) bit integers > and let the processor do the multiplication in its native format. What is the "them"? The numbers themselves don't fit into single 32 bit (or 64 bit) integers, and if you meed the base 10^9 (or base 10^18) digits, then what else do you think it being suggested here? >>> Then you show how to subtract 123.456 from 789012.345678 using 18 digits >>> in 64 bit chunks. I'd love to see you do it. >> >> It's the same as I showed for base 1,000,000,000 only base 10^18. The >> numbers are represented with two digits -- one before and one after the >> point. The position of the point is signalled with a count: >> >> (1, [789012, 345678000000000000]) - (1, [123, 456000000000000000]) >> >> Again, because 456000000000000000 > 345678000000000000 the subtraction >> involves a "borrow" to give: >> >> (1, [789012 - 123 - 1, 10^18 + 345678000000000000 - 456000000000000000]) > > Total fail. Let's see some actual code to do it. I'm not your performing monkey. If anyone *else* would like to see C code for this I'll take the time to do it, but experience shows that once this stage is reached no even code for obvious algorithms like the above will persuade you. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-23 15:47 -0400 |
| Message-ID | <npi98m$2po$1@jstuckle.eternal-september.org> |
| In reply to | #92653 |
On 8/23/2016 12:18 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 8/23/2016 10:14 AM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 8/23/2016 9:07 AM, David Brown wrote: >>> <snip> >>>>> And in either case, I can't see why storing 9 digits in 32-bit chunks is >>>>> going to be much more complicated than storing 1 or 2 digits in 8-bit >>>>> chunks (BCD, packed or unpacked). It will certainly be more efficient >>>>> for calculations. 18 digits in 64-bit chunks is going to be even better >>>>> on modern cpus. >>> >>> Maybe. The advantage of base 10^9 is that the result of any single >>> digit multiplication fits in 64 bits. If you have a 64-bit to 128-bit >>> multiply them, sure, use base 10^18, but if you don't, or you want to >>> write the code in portable C, then 10^9 is probably better. >> >> The smart thing to do would be to store them as 32 (or 64) bit integers >> and let the processor do the multiplication in its native format. > > What is the "them"? The numbers themselves don't fit into single 32 bit > (or 64 bit) integers, and if you meed the base 10^9 (or base 10^18) > digits, then what else do you think it being suggested here? > If you had read the entire thread, you wouldn't have to ask. >>>> Then you show how to subtract 123.456 from 789012.345678 using 18 digits >>>> in 64 bit chunks. I'd love to see you do it. >>> >>> It's the same as I showed for base 1,000,000,000 only base 10^18. The >>> numbers are represented with two digits -- one before and one after the >>> point. The position of the point is signalled with a count: >>> >>> (1, [789012, 345678000000000000]) - (1, [123, 456000000000000000]) >>> >>> Again, because 456000000000000000 > 345678000000000000 the subtraction >>> involves a "borrow" to give: >>> >>> (1, [789012 - 123 - 1, 10^18 + 345678000000000000 - 456000000000000000]) >> >> Total fail. Let's see some actual code to do it. > > I'm not your performing monkey. If anyone *else* would like to see C > code for this I'll take the time to do it, but experience shows that > once this stage is reached no even code for obvious algorithms like the > above will persuade you. > > <snip> > You have that correct. No "performing" by you at all. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web