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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-02 16:25 -0400 |
| Message-ID | <nqcn7n$6nb$1@jstuckle.eternal-september.org> |
| In reply to | #93130 |
On 9/2/2016 2:42 PM, David Brown wrote: > On 02/09/16 18:25, Jerry Stuckle wrote: >> On 9/2/2016 11:11 AM, supercat@casperkitty.com wrote: >>> On Thursday, September 1, 2016 at 7:51:00 PM UTC-5, Jerry Stuckle wrote: >>>> No, it's actually quite simple with bcd arithmetic. Especially with >>>> chips like the Intel series which have native support for it - although >>>> there is some work to get longer values. >>> >>> Multiplying two ten-digit numbers which are stored on base 1,000,000,000 >>> will require computing four partial products. Doing it in BCD would >>> require >>> either computing 100 partial products or computing 40 ten-digit sums; >>> if a >>> processor had instructions to compute BCD sums eight digits (32 bits) >>> at a >>> time, the latter approach might be almost workable, but I don't think >>> I've >>> seen a processor which could handle BCD math more than two digits at >>> a time. >>> >> >> You obviously do not understand Intel chip assembler languages. > > Have you a reference for the Intel assembly instructions that work with > more than two BCD digits (packed or unpacked) at a time? > > Instructions that deal with strings of BCD data are common in mainframe > processors, but not in microprocessors. > In never said a single instruction (but I know you're just trolling, again). Instructions work together to handle as many digits as you want. >> >> And IBM Mainframes handle 31 digits at a time - and have for over 40 >> years. >> >> You still haven't shown the code to divide two numbers using your method. >> > -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-09-03 08:43 +0200 |
| Message-ID | <87inudiivb.fsf@news.bourguet.org> |
| In reply to | #93134 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 9/2/2016 2:42 PM, David Brown wrote: >> On 02/09/16 18:25, Jerry Stuckle wrote: >>> On 9/2/2016 11:11 AM, supercat@casperkitty.com wrote: >>>> On Thursday, September 1, 2016 at 7:51:00 PM UTC-5, Jerry Stuckle wrote: >>>>> No, it's actually quite simple with bcd arithmetic. Especially with >>>>> chips like the Intel series which have native support for it - although >>>>> there is some work to get longer values. >>>> >>>> Multiplying two ten-digit numbers which are stored on base 1,000,000,000 >>>> will require computing four partial products. Doing it in BCD would >>>> require >>>> either computing 100 partial products or computing 40 ten-digit sums; >>>> if a >>>> processor had instructions to compute BCD sums eight digits (32 bits) >>>> at a >>>> time, the latter approach might be almost workable, but I don't think >>>> I've >>>> seen a processor which could handle BCD math more than two digits at >>>> a time. >>>> >>> >>> You obviously do not understand Intel chip assembler languages. >> >> Have you a reference for the Intel assembly instructions that work with >> more than two BCD digits (packed or unpacked) at a time? >> >> Instructions that deal with strings of BCD data are common in mainframe >> processors, but not in microprocessors. >> > > In never said a single instruction (but I know you're just trolling, > again). Instructions work together to handle as many digits as you want. In the context of multi-precision arithmetic (integer or fixed-point), the issue is the same: you can't get the correct value of the result without having seen the last digit. If you do a good job with your estimation (normalization and use the first three digits), you may be off at most by one and only an addition is needed as corrective step. So the only thing needed is the possibility to do 2 digits by one digit division and remainder and the code is mostly the same that your base is 2^32, 10^9 (if you have 64-bit by 32-bit division), 2^16 or 10^4 (if you have 32-bit by 16-bit division) or 10 (if you are doing BCD). If you have to do a non negligible amount of multiplications and divisions, using base 10^9, 10^4 or 10 is probably more costly than using base 2^32, 2^16 or 2^8 and having costlier conversion at input/output. If you have to do mostly additions and substractions, using base 10^9 or 10^4 can be better for performance if input/output is done to decimal format. Doing computation using BCD seems to make sense only if that's the external format (thus that there is no conversion at all on input/output) and that the run-time is so dominated by IO that improving computation time is not worthwhile; hardware assist could change that a little, but I doubt that what x86 provides counts as usefull hardware assist (if I'm not mistaken, they are not available in 64-bit mode). Yours -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-03 10:48 -0400 |
| Message-ID | <nqensr$pma$1@jstuckle.eternal-september.org> |
| In reply to | #93146 |
On 9/3/2016 2:43 AM, Jean-Marc Bourguet wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 9/2/2016 2:42 PM, David Brown wrote: >>> On 02/09/16 18:25, Jerry Stuckle wrote: >>>> On 9/2/2016 11:11 AM, supercat@casperkitty.com wrote: >>>>> On Thursday, September 1, 2016 at 7:51:00 PM UTC-5, Jerry Stuckle wrote: >>>>>> No, it's actually quite simple with bcd arithmetic. Especially with >>>>>> chips like the Intel series which have native support for it - although >>>>>> there is some work to get longer values. >>>>> >>>>> Multiplying two ten-digit numbers which are stored on base 1,000,000,000 >>>>> will require computing four partial products. Doing it in BCD would >>>>> require >>>>> either computing 100 partial products or computing 40 ten-digit sums; >>>>> if a >>>>> processor had instructions to compute BCD sums eight digits (32 bits) >>>>> at a >>>>> time, the latter approach might be almost workable, but I don't think >>>>> I've >>>>> seen a processor which could handle BCD math more than two digits at >>>>> a time. >>>>> >>>> >>>> You obviously do not understand Intel chip assembler languages. >>> >>> Have you a reference for the Intel assembly instructions that work with >>> more than two BCD digits (packed or unpacked) at a time? >>> >>> Instructions that deal with strings of BCD data are common in mainframe >>> processors, but not in microprocessors. >>> >> >> In never said a single instruction (but I know you're just trolling, >> again). Instructions work together to handle as many digits as you want. > > In the context of multi-precision arithmetic (integer or fixed-point), the > issue is the same: you can't get the correct value of the result without > having seen the last digit. If you do a good job with your estimation > (normalization and use the first three digits), you may be off at most by > one and only an addition is needed as corrective step. > > So the only thing needed is the possibility to do 2 digits by one digit > division and remainder and the code is mostly the same that your base is > 2^32, 10^9 (if you have 64-bit by 32-bit division), 2^16 or 10^4 (if you > have 32-bit by 16-bit division) or 10 (if you are doing BCD). > > If you have to do a non negligible amount of multiplications and divisions, > using base 10^9, 10^4 or 10 is probably more costly than using base 2^32, > 2^16 or 2^8 and having costlier conversion at input/output. > > If you have to do mostly additions and substractions, using base 10^9 or > 10^4 can be better for performance if input/output is done to decimal > format. > > Doing computation using BCD seems to make sense only if that's the external > format (thus that there is no conversion at all on input/output) and that > the run-time is so dominated by IO that improving computation time is not > worthwhile; hardware assist could change that a little, but I doubt that > what x86 provides counts as usefull hardware assist (if I'm not mistaken, > they are not available in 64-bit mode). > > Yours > Computing using BCD is required when you need lots of digits of precision. Financial institutions in the United States, for instance, use at least 18 digits (12 left of the decimal point and six right of the decimal point). Additionally, databases use DECIMAL format to store such data - and have for over 50 years. It doesn't matter how much faster something is if you can't get the needed precision. And converting from BCD and back will also lose precision. 64 bit mode is only relatively recent in computer history. There are hundreds of billions of lines of code already using BCD or packed decimal, and those are not going to be rewritten just because C supports 64 bit floating point numbers. BCD multiplication and division can easily be extended to almost any number of digits on Intel chips. No, it's not a single instruction. But the routines are not all that complicated. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-09-03 19:43 +0200 |
| Message-ID | <87h99wev56.fsf@news.bourguet.org> |
| In reply to | #93151 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > Computing using BCD is required when you need lots of digits of > precision. Required? That's a strong word. I've a fixed point library allowing to chose to base of limbs up to 2^32. > Financial institutions in the United States, for instance, use at least > 18 digits (12 left of the decimal point and six right of the decimal > point). 18 is not a lot in my book (without sign that holds in a 64-bit unsigned integer, it's just shy of holding in a 64-bit signed integer). Lots of digits for me is when the loop run-time dominates its setup time. For that format, I'd seriously consider base 10^9 digit in 32-bit word, with one word after the point (ie 18+9 instead of 12+6). > Additionally, databases use DECIMAL format to store such data - and have > for over 50 years. There is a reason for which I wrote that having the external representation already in BCD make it more interesting. And database related load are usually not computation intensive compared with the IO part; if each number is part of one computation doing that computation in the external format is for sure something to be considered. (See below, if multiplication and division are involved, I'm now pretty sure that doing the conversion is the best solution). > It doesn't matter how much faster something is if you can't get the > needed precision. And converting from BCD and back will also lose > precision. If you want lossless conversion to fixed point BCD, just use another power of ten base fixed point. > 64 bit mode is only relatively recent in computer history. I mentionned 64-bit mode of x86 just to note that the interest of BCD instructions of x86 was so low that they removed it. There is all the support needed for 2^32 and 10^9 limbs in 32-bit mode on x86. > There are hundreds of billions of lines of code already using BCD or > packed decimal, and those are not going to be rewritten just because C > supports 64 bit floating point numbers. Why do you mention FP here? That seems totally irrelevant. > BCD multiplication and division can easily be extended to almost any > number of digits on Intel chips. No, it's not a single instruction. > But the routines are not all that complicated. I never said they were complicated, I just said they had the same complexity than the one needed for other bases. And now that I've had a look in the manual, the support for decimal multiplication and division is close to a joke (at least AAA, AAS, DAA, DAS are playing with the nibble carry; AAD is just a 8-bit multiply and accumulate with an immediate multiplicant, AAM is just a 8-bit division and remainder with an immediate divisor, did I have missed something?) Converting BCD, packed or not, on the fly to base 10^9 or base 10^4 and doing the work in that base and converting back to BCD is probably what makes the more sense on a x86 for division and multiplication, even in 32-bit mode, even in 16-bit mode, even in ASM. If you think that working directly in BCD is better I want to see the code. Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-03 18:16 -0400 |
| Message-ID | <nqfi4k$l0s$1@jstuckle.eternal-september.org> |
| In reply to | #93156 |
On 9/3/2016 1:43 PM, Jean-Marc Bourguet wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> Computing using BCD is required when you need lots of digits of >> precision. > > Required? That's a strong word. I've a fixed point library allowing to > chose to base of limbs up to 2^32. > 2^32 gives 9 digits of precision. >> Financial institutions in the United States, for instance, use at least >> 18 digits (12 left of the decimal point and six right of the decimal >> point). > > 18 is not a lot in my book (without sign that holds in a 64-bit unsigned > integer, it's just shy of holding in a 64-bit signed integer). Lots of > digits for me is when the loop run-time dominates its setup time. > > For that format, I'd seriously consider base 10^9 digit in 32-bit word, > with one word after the point (ie 18+9 instead of 12+6). > Once again, 32 bits is only 9 digits of precision. And 64 bit machines haven't been around very long in computing time. >> Additionally, databases use DECIMAL format to store such data - and have >> for over 50 years. > > There is a reason for which I wrote that having the external representation > already in BCD make it more interesting. And database related load are > usually not computation intensive compared with the IO part; if each number > is part of one computation doing that computation in the external format is > for sure something to be considered. (See below, if multiplication and > division are involved, I'm now pretty sure that doing the conversion is the > best solution). > Not only external representation. Internal usage is important, also. >> It doesn't matter how much faster something is if you can't get the >> needed precision. And converting from BCD and back will also lose >> precision. > > If you want lossless conversion to fixed point BCD, just use another power > of ten base fixed point. > Once again, not possible with 32 bits. >> 64 bit mode is only relatively recent in computer history. > > I mentionned 64-bit mode of x86 just to note that the interest of BCD > instructions of x86 was so low that they removed it. There is all the > support needed for 2^32 and 10^9 limbs in 32-bit mode on x86. > And once again, 64 bit processors haven't been around all that long. Certainly not for the 50+ years financial institutions have required 18 bits of precision. >> There are hundreds of billions of lines of code already using BCD or >> packed decimal, and those are not going to be rewritten just because C >> supports 64 bit floating point numbers. > > Why do you mention FP here? That seems totally irrelevant. > Because others have mentioned it. And that's what the values are. Sure, you can fake part of it using integers. But sooner or later you have to convert to floating point. >> BCD multiplication and division can easily be extended to almost any >> number of digits on Intel chips. No, it's not a single instruction. >> But the routines are not all that complicated. > > I never said they were complicated, I just said they had the same > complexity than the one needed for other bases. And now that I've had a > look in the manual, the support for decimal multiplication and division is > close to a joke (at least AAA, AAS, DAA, DAS are playing with the nibble > carry; AAD is just a 8-bit multiply and accumulate with an immediate > multiplicant, AAM is just a 8-bit division and remainder with an immediate > divisor, did I have missed something?) > Not a joke - just not carrying very far. > Converting BCD, packed or not, on the fly to base 10^9 or base 10^4 and > doing the work in that base and converting back to BCD is probably what > makes the more sense on a x86 for division and multiplication, even in > 32-bit mode, even in 16-bit mode, even in ASM. If you think that working > directly in BCD is better I want to see the code. > > Yours, > I'm not going to post a bunch of assembler code here - not only is it off topic, but it's a fair amount of code. But the library is pretty fast using Intel assembler - much faster than using strings of digits to represent the number. And also compatible with database DECIMAL fields, which is what it was made for. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-09-08 11:18 -0700 |
| Message-ID | <56b0f47c-eb89-4f16-9615-99df130a89f5@googlegroups.com> |
| In reply to | #93181 |
Operation on string of char seems to me more slow than the one of array of int or float Conversions routines I used from base to base I remember are slower routines...
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-09-07 19:59 -0500 |
| Message-ID | <4td1tb9n8tskguoeg4ru6upe7nh4gte336@4ax.com> |
| In reply to | #93130 |
On Fri, 02 Sep 2016 20:42:08 +0200, David Brown <david.brown@hesbynett.no> wrote: >On 02/09/16 18:25, Jerry Stuckle wrote: >> On 9/2/2016 11:11 AM, supercat@casperkitty.com wrote: >>> On Thursday, September 1, 2016 at 7:51:00 PM UTC-5, Jerry Stuckle wrote: >>>> No, it's actually quite simple with bcd arithmetic. Especially with >>>> chips like the Intel series which have native support for it - although >>>> there is some work to get longer values. >>> >>> Multiplying two ten-digit numbers which are stored on base 1,000,000,000 >>> will require computing four partial products. Doing it in BCD would require >>> either computing 100 partial products or computing 40 ten-digit sums; if a >>> processor had instructions to compute BCD sums eight digits (32 bits) at a >>> time, the latter approach might be almost workable, but I don't think I've >>> seen a processor which could handle BCD math more than two digits at a time. >>> >> >> You obviously do not understand Intel chip assembler languages. > >Have you a reference for the Intel assembly instructions that work with >more than two BCD digits (packed or unpacked) at a time? FBLD and FBSTP? FSVO "works with".
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-08 08:13 -0700 |
| Message-ID | <917eebb1-2a41-437a-ac71-712dfd2f2b61@googlegroups.com> |
| In reply to | #93285 |
On Wednesday, September 7, 2016 at 7:59:49 PM UTC-5, robert...@yahoo.com wrote: > >Have you a reference for the Intel assembly instructions that work with > >more than two BCD digits (packed or unpacked) at a time? > > > FBLD and FBSTP? FSVO "works with". If I recall, those instructions perform a BCD-to-binary or binary-to-BCD conversion; on the 8087 they would have processed digits sequentially, and I've never heard of later chips adding logic to process digits in parallel. Logic to process digits in groups of 3 would probably not be overly expensive, but I'd be somewhat surprised if Intel bothered with even that level of optimization.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-09-08 19:34 -0500 |
| Message-ID | <9504tbt3s1ienthqnrvsln5g33bjq9evl2@4ax.com> |
| In reply to | #93298 |
On Thu, 8 Sep 2016 08:13:48 -0700 (PDT), supercat@casperkitty.com wrote: >On Wednesday, September 7, 2016 at 7:59:49 PM UTC-5, robert...@yahoo.com wrote: >> >Have you a reference for the Intel assembly instructions that work with >> >more than two BCD digits (packed or unpacked) at a time? >> >> >> FBLD and FBSTP? FSVO "works with". > >If I recall, those instructions perform a BCD-to-binary or binary-to-BCD >conversion; on the 8087 they would have processed digits sequentially, and >I've never heard of later chips adding logic to process digits in parallel. >Logic to process digits in groups of 3 would probably not be overly expensive, >but I'd be somewhat surprised if Intel bothered with even that level of >optimization. I don't see how the implementation is relevant here. The instruction deals with a 19 BCD digit (plus sign) number in one chunk. But yes, I'd assume a fairly serial implementation given the rather severe non-use. A fully parallel converter (in either direction) would be about the same size as a full multiplier of similar width. Interestingly both got significantly slower on the 486 relative to the 387. FBLD is documented as 43 micro-ops on Haswell, which tracks pretty well with a two-micro-op-per-decimal-digit serial implementation. FBSTP is something like 230(!!), which sounds like they didn't even try, and are just doing repeated division.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-09 07:50 -0700 |
| Message-ID | <d69d6faa-c080-4435-a454-fda56cf4eafa@googlegroups.com> |
| In reply to | #93319 |
On Thursday, September 8, 2016 at 7:35:15 PM UTC-5, robert...@yahoo.com wrote: > But yes, I'd assume a fairly serial implementation given the rather > severe non-use. A fully parallel converter (in either direction) > would be about the same size as a full multiplier of similar width. > Interestingly both got significantly slower on the 486 relative to the > 387. FBLD is documented as 43 micro-ops on Haswell, which tracks > pretty well with a two-micro-op-per-decimal-digit serial > implementation. FBSTP is something like 230(!!), which sounds like > they didn't even try, and are just doing repeated division. Converting a binary fraction 0-0.1111111 to a BCD number 0-0.99 should not be too hard--just use repeated multiplication. The tricky bit would be handling numbers scaled by other amounts and getting correct rounding. Still, if it's that slow I would find myself wondering whether a trap might be just as fast.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-02 23:40 -0700 |
| Message-ID | <9b16b659-c293-4af5-80bd-58371b2340fe@googlegroups.com> |
| In reply to | #93111 |
On Friday, September 2, 2016 at 4:11:18 PM UTC+1, supe...@casperkitty.com wrote: > On Thursday, September 1, 2016 at 7:51:00 PM UTC-5, Jerry Stuckle wrote: > > No, it's actually quite simple with bcd arithmetic. Especially with > > chips like the Intel series which have native support for it - although > > there is some work to get longer values. > > Multiplying two ten-digit numbers which are stored on base 1,000,000,000 > will require computing four partial products. Doing it in BCD would > require either computing 100 partial products or computing 40 ten-digit > sums; if a processor had instructions to compute BCD sums eight digits > (32 bits) at a time, the latter approach might be almost workable, but > I don't think I've seen a processor which could handle BCD math more > than two digits at a time. > BCD is used mainly for amounts of money. I don't think performance really matters. If HM Treasury adds up every single receipt from every single tax payer in a day, it would still only be a few tens of millions of calculations - a ZX81 would be adequate for their purposes. (I might be wrong with financial trading apps, where you have to buy a second before the next man when the oil price drops a cent, I don't know much about that world). If you want to multiply huge integers, you can use Fourier transforms rather than the primary school multiply the digit and carry algorithm.
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-09-03 09:06 +0200 |
| Message-ID | <87d1klihrs.fsf@news.bourguet.org> |
| In reply to | #93145 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > If you want to multiply huge integers, you can use Fourier transforms > rather than the primary school multiply the digit and carry algorithm. I've done that but I was surprised by the number of big digits needed to get an improvement over simpler but not N^2 algorithms. And my numerical analysis skills felt short of being able to compute the number of digits after which rounding errors in the FP code caused miscomputations. (GMP documentation says that they are making the switch at around 3000 limbs and contains some information about the precision, they have also description of other algorithms they use). Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-03 10:52 -0400 |
| Message-ID | <nqeo2f$pma$2@jstuckle.eternal-september.org> |
| In reply to | #93145 |
On 9/3/2016 2:40 AM, Malcolm McLean wrote: > On Friday, September 2, 2016 at 4:11:18 PM UTC+1, supe...@casperkitty.com wrote: >> On Thursday, September 1, 2016 at 7:51:00 PM UTC-5, Jerry Stuckle wrote: >>> No, it's actually quite simple with bcd arithmetic. Especially with >>> chips like the Intel series which have native support for it - although >>> there is some work to get longer values. >> >> Multiplying two ten-digit numbers which are stored on base 1,000,000,000 >> will require computing four partial products. Doing it in BCD would >> require either computing 100 partial products or computing 40 ten-digit >> sums; if a processor had instructions to compute BCD sums eight digits >> (32 bits) at a time, the latter approach might be almost workable, but >> I don't think I've seen a processor which could handle BCD math more >> than two digits at a time. >> > BCD is used mainly for amounts of money. > I don't think performance really matters. If HM Treasury adds up > every single receipt from every single tax payer in a day, it > would still only be a few tens of millions of calculations - a > ZX81 would be adequate for their purposes. > (I might be wrong with financial trading apps, where you have to > buy a second before the next man when the oil price drops a cent, > I don't know much about that world). > > If you want to multiply huge integers, you can use Fourier transforms > rather than the primary school multiply the digit and carry algorithm. > Performance matters a lot when you're doing tens of millions transactions every day - which is easily done by even a medium-sized bank. And credit card processors do a lot more than that. And Fourier transforms are great for estimating - but you aren't going to get the needed accuracy as easily as just using "primary school multiply and carry algorithm". -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2016-08-24 08:57 +0200 |
| Message-ID | <k5hqrbp2ba2fjgbhp41pm12vs951vo0b5i@4ax.com> |
| In reply to | #92571 |
On Sun, 21 Aug 2016 18:31:05 -0400, Jerry Stuckle <jstucklex@attglobal.net> wrote: >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: >> But Maple itself is implemented in C. You can't "just" use another language, I remember i had read in some place that Maple use one programming language different from C and from Maple language itself, and its pourpose it make Maple portable trhu compiler cpu etc i not find in internet one trace of that so possibly i remember wrong
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-24 01:04 -0700 |
| Message-ID | <49bc24d5-249d-4e5b-bb7e-fdb7bdaf1c45@googlegroups.com> |
| In reply to | #92669 |
On Wednesday, August 24, 2016 at 7:58:04 AM UTC+1, Rosario19 wrote: > > >> But Maple itself is implemented in C. You can't "just" use > >> another language, > > I remember i had read in some place that Maple use one programming > language different from C and from Maple language itself, > and its pourpose it make Maple portable trhu compiler cpu etc > > i not find in internet one trace of that so possibly i remember wrong > I haven't been involved in Maple development. But from what they say, there's a C "core" which runs the engine, it represents the equations and applies the basic manipulations. That core then has a high-level interface to a Maple scripting interpreter. The more advanced features are then written in the scripting language and call the core. Maple itself might be different from the scripting language and of course it can't call the core directly. I'm not sure about that detail.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-08-08 06:44 +0000 |
| Message-ID | <slrn3vfsnqgaj0.idp.ike@iceland.freeshell.org> |
| In reply to | #91886 |
On 2016-08-07, Stefan Ram <ram@zedat.fu-berlin.de> wrote: > ram@zedat.fu-berlin.de (Stefan Ram) writes: >>For most scientific calculations N is small, >>just in the range of FLT_DIG and DBL_DIG. > > A counterexample is the following calculation I once programmed, > where a large precession is needed for some intermediate values: Precession? > A walker is walking on a treadmill. The walker walks with > 1 m/s relative to the treadmill. The treadmill itself has > a speed of 1/s relative to the ground. What is the speed > of the walker relative to the ground? > > approximately 1,999999999999999977746998878927631604116230150263 m/s Given the input data, one would expect 2 or 0 (depending on the direction of the walker with respect to the treadmill vs. the direction of the motion of the treadmill with respect to the ground). In a practical situation, the 0 result seems most likely. > Ok, one can't do this easily with standard C AFAIK, so I had > to use a /real/ programming language. And to read the code, > one needs a real newsreader (a newsreader that can display > real lines [lines with more than 80 characters]). Are you saying that lines with <=80 characters are not real? In that case, most of what you wrote is not real.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-08 00:16 -0700 |
| Message-ID | <lna8gnwx17.fsf@kst-u.example.com> |
| In reply to | #91919 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2016-08-07, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>For most scientific calculations N is small,
>>>just in the range of FLT_DIG and DBL_DIG.
>>
>> A counterexample is the following calculation I once programmed,
>> where a large precession is needed for some intermediate values:
>
> Precession?
>
>> A walker is walking on a treadmill. The walker walks with
>> 1 m/s relative to the treadmill. The treadmill itself has
>> a speed of 1/s relative to the ground. What is the speed
>> of the walker relative to the ground?
>>
>> approximately 1,999999999999999977746998878927631604116230150263 m/s
>
> Given the input data, one would expect 2 or 0 (depending on the
> direction of the walker with respect to the treadmill vs. the
> direction of the motion of the treadmill with respect to the ground).
> In a practical situation, the 0 result seems most likely.
I think the intent is to account for relativistic effects.
[...]
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-08-08 23:29 -0400 |
| Message-ID | <R6cqz.8546$xe1.3360@fx02.iad> |
| In reply to | #91920 |
On 8/8/16 3:16 AM, Keith Thompson wrote: > Ike Naar <ike@iceland.freeshell.org> writes: >> On 2016-08-07, Stefan Ram <ram@zedat.fu-berlin.de> wrote: >>> ram@zedat.fu-berlin.de (Stefan Ram) writes: >>>> For most scientific calculations N is small, >>>> just in the range of FLT_DIG and DBL_DIG. >>> >>> A counterexample is the following calculation I once programmed, >>> where a large precession is needed for some intermediate values: >> >> Precession? >> >>> A walker is walking on a treadmill. The walker walks with >>> 1 m/s relative to the treadmill. The treadmill itself has >>> a speed of 1/s relative to the ground. What is the speed >>> of the walker relative to the ground? >>> >>> approximately 1,999999999999999977746998878927631604116230150263 m/s >> >> Given the input data, one would expect 2 or 0 (depending on the >> direction of the walker with respect to the treadmill vs. the >> direction of the motion of the treadmill with respect to the ground). >> In a practical situation, the 0 result seems most likely. > > I think the intent is to account for relativistic effects. > > [...] > But unless the speeds are measured to amazing accuracy (i.e. 1.0000000000000000 m/s not just 1 m/s), the difference from the provided answer and 2 is insignificant.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-08 14:03 +0200 |
| Message-ID | <no9seq$mcl$1@dont-email.me> |
| In reply to | #91886 |
Le 08/08/2016 à 00:55, Real Troll a écrit : > So how do you perform scientific calculations which have to be as > precise as possible? what changes one has to make to get 22 or more > decimal places (see the program I gave before). To give you a trivial > example, PI can be written as infinite decimal places so how do you > accommodate this? Use the lcc-win compiler system! 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 All those types are supported by printf
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-08 05:14 -0700 |
| Message-ID | <7c087bca-29df-4914-a5f6-633852be7afb@googlegroups.com> |
| In reply to | #91948 |
On Monday, August 8, 2016 at 8:03:45 AM UTC-4, jacobnavia wrote:
> Le 08/08/2016 à 00:55, Real Troll a écrit :
> > So how do you perform scientific calculations which have to be as
> > precise as possible? what changes one has to make to get 22 or more
> > decimal places (see the program I gave before). To give you a trivial
> > example, PI can be written as infinite decimal places so how do you
> > accommodate this?
>
> Use the lcc-win compiler system!
>
> lcc-win offers
>
> 1) Real long double (80 bits) support with approx 19 decimal digits
Awesome. Many old compilers used to support those, but dropped
support over time to be compatible with other architectures that
did not have them.
Do you have a native type name for them (rather than "long double")?
CAlive plans f32, f64, and f80 for CPU-supported types.
> 2) 128 bit IEEE double precision with around 30 decimal digits
Where does lcc get support for this? From a source like the double-double
and quad-double libraries? Or did you write your own?
Double-double, Quad-double, using hardware for higher precision:
http://web.mit.edu/tabbott/Public/quaddouble-debian/qd-2.3.4-old/docs/qd.pdf
> 3) Qfloat numbers with approx 130 (!!!) digits precision
What are Qfloats? And how do they get 130 digits of precision?
> All those types are supported by printf
An impressive assemblage of floating point power, Jacob.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web