Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #66705 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2015-08-02 10:17 -0700 |
| Last post | 2015-09-07 05:02 +0200 |
| Articles | 20 on this page of 78 — 13 participants |
Back to article view | Back to comp.lang.c
routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 10:17 -0700
Re: routine for angles needed Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 10:38 -0700
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 11:10 -0700
Re: routine for angles needed Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 11:26 -0700
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 11:41 -0700
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 12:02 -0700
Re: routine for angles needed Bartc <bc@freeuk.com> - 2015-08-02 18:41 +0100
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 11:43 -0700
Re: routine for angles needed Bartc <bc@freeuk.com> - 2015-08-02 20:00 +0100
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 12:04 -0700
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 12:10 -0700
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 12:24 -0700
Re: routine for angles needed Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 12:32 -0700
Re: routine for angles needed Bartc <bc@freeuk.com> - 2015-08-02 20:40 +0100
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 12:59 -0700
Re: routine for angles needed Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 13:14 -0700
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 13:39 -0700
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 13:45 -0700
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-03 07:48 -0700
Re: routine for angles needed Bartc <bc@freeuk.com> - 2015-08-03 17:06 +0100
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-03 09:09 -0700
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-03 09:17 -0700
Re: routine for angles needed Bartc <bc@freeuk.com> - 2015-08-03 17:48 +0100
Re: routine for angles needed Keith Thompson <kst-u@mib.org> - 2015-08-03 13:44 -0700
Re: routine for angles needed Bartc <bc@freeuk.com> - 2015-08-03 23:51 +0100
Re: routine for angles needed Keith Thompson <kst-u@mib.org> - 2015-08-03 18:30 -0700
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-03 23:11 +0000
Re: routine for angles needed Bartc <bc@freeuk.com> - 2015-08-04 01:32 +0100
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-04 01:14 +0000
Re: routine for angles needed Robert Wessel <robertwessel2@yahoo.com> - 2015-08-03 20:26 -0500
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-04 18:24 +0000
Re: routine for angles needed Robert Wessel <robertwessel2@yahoo.com> - 2015-08-05 01:46 -0500
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-05 18:06 +0000
Re: routine for angles needed Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 11:37 -0700
Re: routine for angles needed Keith Thompson <kst-u@mib.org> - 2015-09-05 16:24 -0700
Re: routine for angles needed Richard Damon <Richard@Damon-Family.org> - 2015-09-05 21:01 -0400
Re: routine for angles needed Robert Wessel <robertwessel2@yahoo.com> - 2015-09-05 23:30 -0500
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-06 05:37 +0000
Re: routine for angles needed Robert Wessel <robertwessel2@yahoo.com> - 2015-09-07 00:27 -0500
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-06 05:31 +0000
Re: routine for angles needed James Kuyper <jameskuyper@verizon.net> - 2015-09-06 11:57 -0400
Re: routine for angles needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 17:44 +0100
Re: routine for angles needed James Kuyper <jameskuyper@verizon.net> - 2015-09-06 14:02 -0400
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-12 00:05 +0000
Re: routine for angles needed Robert Wessel <robertwessel2@yahoo.com> - 2015-09-07 00:31 -0500
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-12 00:00 +0000
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-11 23:17 +0000
Re: routine for angles needed James Kuyper <jameskuyper@verizon.net> - 2015-09-11 19:46 -0400
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-12 03:56 +0000
Re: routine for angles needed James Kuyper <jameskuyper@verizon.net> - 2015-09-12 12:33 -0400
Re: routine for angles needed Richard Damon <Richard@Damon-Family.org> - 2015-09-12 14:29 -0400
Re: routine for angles needed James Kuyper <jameskuyper@verizon.net> - 2015-09-12 15:58 -0400
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-13 06:21 +0000
Re: routine for angles needed Keith Thompson <kst-u@mib.org> - 2015-09-06 11:59 -0700
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-12 00:16 +0000
Re: routine for angles needed Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 18:04 -0700
Re: routine for angles needed Keith Thompson <kst-u@mib.org> - 2015-09-06 18:30 -0700
Re: routine for angles needed Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 18:48 -0700
Re: routine for angles needed Robert Wessel <robertwessel2@yahoo.com> - 2015-09-07 00:44 -0500
Re: routine for angles needed Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-10 05:44 -0700
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-12 00:25 +0000
Re: routine for angles needed Robert Wessel <robertwessel2@yahoo.com> - 2015-08-03 20:16 -0500
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-04 01:26 +0000
Re: routine for angles needed Robert Wessel <robertwessel2@yahoo.com> - 2015-08-05 02:05 -0500
Re: routine for angles needed Keith Thompson <kst-u@mib.org> - 2015-08-03 18:33 -0700
Re: routine for angles needed glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-04 21:24 +0000
Re: routine for angles needed Robert Wessel <robertwessel2@yahoo.com> - 2015-08-03 19:41 -0500
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 12:51 -0700
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 12:56 -0700
Re: routine for angles needed Bartc <bc@freeuk.com> - 2015-08-02 20:57 +0100
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 13:06 -0700
Re: routine for angles needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-02 22:25 +0100
Re: routine for angles needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-02 22:27 +0100
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-02 14:40 -0700
Re: routine for angles needed "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-08-02 19:08 -0700
Re: routine for angles needed fir <profesor.fir@gmail.com> - 2015-08-03 02:18 -0700
Re: routine for angles needed danncorbit@gmail.com - 2015-08-12 02:18 -0700
Re: routine for angles needed bartekltg <bartekltg@gmail.com> - 2015-09-07 05:02 +0200
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-06 11:57 -0400 |
| Message-ID | <55EC6281.4010500@verizon.net> |
| In reply to | #69574 |
On 09/06/2015 01:31 AM, glen herrmannsfeldt wrote: > Keith Thompson <kst-u@mib.org> wrote: >> Tim Rentsch <txr@alumni.caltech.edu> writes: >>> Robert Wessel <robertwessel2@yahoo.com> writes: >> [...] >>>> Ultimately any sort of decimal encoding has to be less efficient >>>> than binary encoding, since you invariably end up with "invalid" bit >>>> patterns. [snip] > >>> This isn't right. Using a decimal base for floating point >>> is not inherently less bit efficient than a binary base. >>> Using a decimal base can be much less convenient than >>> using a binary base, but it is not inherently less bit >>> efficient. In particular there needn't be any invalid >>> or duplicate bit patterns. > > Bit efficient is a funny term in this context. You can represent > a specific number of real values with a given number of bits. Bit efficiency compares the number of real values representable by the format under discussion, with 2^N, where N is the number of bits required to store the format. If the first number is substantially smaller than the second, the bits are being used inefficiently. This seems a reasonable use of the term.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-09-06 17:44 +0100 |
| Message-ID | <87r3mbfqf3.fsf@bsb.me.uk> |
| In reply to | #69622 |
James Kuyper <jameskuyper@verizon.net> writes: > On 09/06/2015 01:31 AM, glen herrmannsfeldt wrote: >> Keith Thompson <kst-u@mib.org> wrote: >>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>> Robert Wessel <robertwessel2@yahoo.com> writes: >>> [...] >>>>> Ultimately any sort of decimal encoding has to be less efficient >>>>> than binary encoding, since you invariably end up with "invalid" bit >>>>> patterns. [snip] >> >>>> This isn't right. Using a decimal base for floating point >>>> is not inherently less bit efficient than a binary base. >>>> Using a decimal base can be much less convenient than >>>> using a binary base, but it is not inherently less bit >>>> efficient. In particular there needn't be any invalid >>>> or duplicate bit patterns. >> >> Bit efficient is a funny term in this context. You can represent >> a specific number of real values with a given number of bits. > > Bit efficiency compares the number of real values representable by the > format under discussion, with 2^N, where N is the number of bits > required to store the format. If the first number is substantially > smaller than the second, the bits are being used inefficiently. This > seems a reasonable use of the term. It's a bit fuzzy, though, because you need to factor in some idea of the utility of the values. For example, in IEEE FP (what's the proper term for this?) there are 2^53 - 2 NaN values in the 64-bit format. Do these count or are all but one of them wasted? There's some value in having multiple NaNs (for example you can signal various kinds of error using them) so it's not clear-cut. And there's a fair few denormals, too. Are they proper values or wasted representations? And if I remember correctly the IEEE decimal FP format also has a large number of infinities. Having any more than two would seem to be wasting representations but I bet someone's already found use for them. One could settle such questions by saying that the bit-efficiency is the number of distinct rational numbers that can be represented divided by 2^N. That rules out infinities, NaNs and any duplicates (usually 0), but includes denormals. That's one way to make it exact, but I'm not sure I'd want to include denormals, simply because having a high proportion of them is a bad thing. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-06 14:02 -0400 |
| Message-ID | <55EC7FAD.7050705@verizon.net> |
| In reply to | #69628 |
On 09/06/2015 12:44 PM, Ben Bacarisse wrote: > James Kuyper <jameskuyper@verizon.net> writes: > >> On 09/06/2015 01:31 AM, glen herrmannsfeldt wrote: >>> Keith Thompson <kst-u@mib.org> wrote: >>>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>>> Robert Wessel <robertwessel2@yahoo.com> writes: >>>> [...] >>>>>> Ultimately any sort of decimal encoding has to be less efficient >>>>>> than binary encoding, since you invariably end up with "invalid" bit >>>>>> patterns. [snip] >>> >>>>> This isn't right. Using a decimal base for floating point >>>>> is not inherently less bit efficient than a binary base. >>>>> Using a decimal base can be much less convenient than >>>>> using a binary base, but it is not inherently less bit >>>>> efficient. In particular there needn't be any invalid >>>>> or duplicate bit patterns. >>> >>> Bit efficient is a funny term in this context. You can represent >>> a specific number of real values with a given number of bits. >> >> Bit efficiency compares the number of real values representable by the >> format under discussion, with 2^N, where N is the number of bits >> required to store the format. If the first number is substantially >> smaller than the second, the bits are being used inefficiently. This >> seems a reasonable use of the term. > > It's a bit fuzzy, though, because you need to factor in some idea of the > utility of the values. For example, in IEEE FP (what's the proper term > for this?) there are 2^53 - 2 NaN values in the 64-bit format. Do these > count or are all but one of them wasted? There's some value in having > multiple NaNs (for example you can signal various kinds of error using > them) so it's not clear-cut. And there's a fair few denormals, too. > Are they proper values or wasted representations? > > And if I remember correctly the IEEE decimal FP format also has a large > number of infinities. Having any more than two would seem to be wasting > representations but I bet someone's already found use for them. I checked out IEEE 754-2008's decimal64 format mentioned by Glenn. NaN's and Infinities are not exceptions - most numbers have multiple ways they can be represented. That's unambiguously inefficient. > One could settle such questions by saying that the bit-efficiency is the > number of distinct rational numbers that can be represented divided by > 2^N. That rules out infinities, NaNs and any duplicates (usually 0), > but includes denormals. That's one way to make it exact, but I'm not > sure I'd want to include denormals, simply because having a high > proportion of them is a bad thing. I will agree that all of these are relevant issues. But the concept first came into this thread in connection with a description of Binary Coded Decimal (BCD) (though not mentioned by name), which is unambiguously somewhat bit-inefficient. An encoding that uses 10*N bits to store values from 0 to 10^(3*N)-1 is also somewhat inefficient, though less so. The next level would be to store 0 to 10^28-1 in 93 bits. Every decimal floating point format I'm aware of has some such issue.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-12 00:05 +0000 |
| Message-ID | <msvq7o$d74$1@speranza.aioe.org> |
| In reply to | #69631 |
James Kuyper <jameskuyper@verizon.net> wrote: (snip on floating point bit efficiency) > I checked out IEEE 754-2008's decimal64 format mentioned by Glenn. NaN's > and Infinities are not exceptions - most numbers have multiple ways they > can be represented. That's unambiguously inefficient. OK, but when you get down to the difference between 99% and 100%, it mostly doesn't matter much. On the other hand, there are those worrying about the bit waste using 64 bit pointers for programs that never have more than 4GB to address, but run on 64 bit machines. That can be a significant waste, and matters about as much as floating point bit efficiency. >> One could settle such questions by saying that the bit-efficiency is the >> number of distinct rational numbers that can be represented divided by >> 2^N. That rules out infinities, NaNs and any duplicates (usually 0), >> but includes denormals. That's one way to make it exact, but I'm not >> sure I'd want to include denormals, simply because having a high >> proportion of them is a bad thing. > I will agree that all of these are relevant issues. But the concept > first came into this thread in connection with a description of Binary > Coded Decimal (BCD) (though not mentioned by name), which is > unambiguously somewhat bit-inefficient. An encoding that uses 10*N bits > to store values from 0 to 10^(3*N)-1 is also somewhat inefficient, > though less so. The next level would be to store 0 to 10^28-1 in 93 > bits. Every decimal floating point format I'm aware of has some such issue. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-07 00:31 -0500 |
| Message-ID | <448quadsdnctg2agnkqodgp0hvov650poe@4ax.com> |
| In reply to | #69628 |
On Sun, 06 Sep 2015 17:44:48 +0100, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >James Kuyper <jameskuyper@verizon.net> writes: > >> On 09/06/2015 01:31 AM, glen herrmannsfeldt wrote: >>> Keith Thompson <kst-u@mib.org> wrote: >>>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>>> Robert Wessel <robertwessel2@yahoo.com> writes: >>>> [...] >>>>>> Ultimately any sort of decimal encoding has to be less efficient >>>>>> than binary encoding, since you invariably end up with "invalid" bit >>>>>> patterns. [snip] >>> >>>>> This isn't right. Using a decimal base for floating point >>>>> is not inherently less bit efficient than a binary base. >>>>> Using a decimal base can be much less convenient than >>>>> using a binary base, but it is not inherently less bit >>>>> efficient. In particular there needn't be any invalid >>>>> or duplicate bit patterns. >>> >>> Bit efficient is a funny term in this context. You can represent >>> a specific number of real values with a given number of bits. >> >> Bit efficiency compares the number of real values representable by the >> format under discussion, with 2^N, where N is the number of bits >> required to store the format. If the first number is substantially >> smaller than the second, the bits are being used inefficiently. This >> seems a reasonable use of the term. > >It's a bit fuzzy, though, because you need to factor in some idea of the >utility of the values. For example, in IEEE FP (what's the proper term >for this?) there are 2^53 - 2 NaN values in the 64-bit format. Do these >count or are all but one of them wasted? There's some value in having >multiple NaNs (for example you can signal various kinds of error using >them) so it's not clear-cut. And there's a fair few denormals, too. >Are they proper values or wasted representations? > >And if I remember correctly the IEEE decimal FP format also has a large >number of infinities. Having any more than two would seem to be wasting >representations but I bet someone's already found use for them. > >One could settle such questions by saying that the bit-efficiency is the >number of distinct rational numbers that can be represented divided by >2^N. That rules out infinities, NaNs and any duplicates (usually 0), >but includes denormals. That's one way to make it exact, but I'm not >sure I'd want to include denormals, simply because having a high >proportion of them is a bad thing. FWIW, I did some estimates a few posts upthread, and making simplifying assumption favorable to IEEE DFP (vs. IEEE binary FP), I came up with about 9.2E+18 BPF different numbers for doubles, and about 7.7E+18 for DFP. So about 20% extra representable numbers for BFP, which probably isn't anything to get excited about either way.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-12 00:00 +0000 |
| Message-ID | <msvpv9$cgv$1@speranza.aioe.org> |
| In reply to | #69628 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > James Kuyper <jameskuyper@verizon.net> writes: (snip on bit efficiency) >> Bit efficiency compares the number of real values representable by the >> format under discussion, with 2^N, where N is the number of bits >> required to store the format. If the first number is substantially >> smaller than the second, the bits are being used inefficiently. This >> seems a reasonable use of the term. > It's a bit fuzzy, though, because you need to factor in some idea of the > utility of the values. For example, in IEEE FP (what's the proper term > for this?) there are 2^53 - 2 NaN values in the 64-bit format. Do these > count or are all but one of them wasted? There's some value in having > multiple NaNs (for example you can signal various kinds of error using > them) so it's not clear-cut. And there's a fair few denormals, too. > Are they proper values or wasted representations? OK, but in actual numbers 2**53 (not using the exclusive or operator) values out of 2**64 isn't all that much. That is about 99.95%. On the other hand, if it allows easier, and faster, hardware then it is probably worthwhile. That is, one should consider storage efficiency times execution efficiency. Personally, I believe that denormals were a bad idea. They make a small difference in storage efficiency, while potentially a large decrease in execution efficiency, especially for high performance implementations. > And if I remember correctly the IEEE decimal FP format also has a large > number of infinities. Having any more than two would seem to be wasting > representations but I bet someone's already found use for them. > One could settle such questions by saying that the bit-efficiency is the > number of distinct rational numbers that can be represented divided by > 2^N. That rules out infinities, NaNs and any duplicates (usually 0), > but includes denormals. That's one way to make it exact, but I'm not > sure I'd want to include denormals, simply because having a high > proportion of them is a bad thing. Yes, I would also rather not consider denormals. -- glen
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-11 23:17 +0000 |
| Message-ID | <msvndk$81q$1@speranza.aioe.org> |
| In reply to | #69622 |
James Kuyper <jameskuyper@verizon.net> wrote: (snip, regarding decimal floating point, where I wrote) >> Bit efficient is a funny term in this context. You can represent >> a specific number of real values with a given number of bits. > Bit efficiency compares the number of real values representable by the > format under discussion, with 2^N, where N is the number of bits > required to store the format. If the first number is substantially > smaller than the second, the bits are being used inefficiently. This > seems a reasonable use of the term. Yes, but it gets interesting in the floating point case. You can allocate bits for exponent or significand, which changes the range and precision of the representable values. This complicates comparison between different representations that might have similar bit efficiency. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-11 19:46 -0400 |
| Message-ID | <55F367F3.2000502@verizon.net> |
| In reply to | #70286 |
On 09/11/2015 07:17 PM, glen herrmannsfeldt wrote: > James Kuyper <jameskuyper@verizon.net> wrote: > > (snip, regarding decimal floating point, where I wrote) > >>> Bit efficient is a funny term in this context. You can represent >>> a specific number of real values with a given number of bits. > >> Bit efficiency compares the number of real values representable by the >> format under discussion, with 2^N, where N is the number of bits >> required to store the format. If the first number is substantially >> smaller than the second, the bits are being used inefficiently. This >> seems a reasonable use of the term. > > Yes, but it gets interesting in the floating point case. > > You can allocate bits for exponent or significand, which changes > the range and precision of the representable values. This complicates > comparison between different representations that might have > similar bit efficiency. Range and precision are, indeed, other issues that need to be considered. Bit efficiency is far from being the single most important criterion for choosing a floating point format - it's just one criterion among many. I was only defending the use of the term, which seemed to me quite unobjectionable - Keith certainly wasn't promoting the idea that it was the only thing to use when comparing formats. Note: I should have said "the number of *distinct* real values representable by the format under discussion". Distinctness isn't a big issue for the binary floating point formats I'm most familiar with, but I gather that it's a significant issue for IEEE 754-2008's decimal floating point formats, with corresponding complications for correctly calculating the bit efficiency: "Because the significand is not normalized, most values with less than 16 significant digits have multiple possible representations; 1×102=0.1×103=0.01×104, etc. Zero has 768 possible representations (1536 if you include both signed zeros)." <https://en.wikipedia.org/wiki/Decimal64_floating-point_format>
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-12 03:56 +0000 |
| Message-ID | <mt07qa$42s$1@speranza.aioe.org> |
| In reply to | #70288 |
James Kuyper <jameskuyper@verizon.net> wrote: (snip, I wrote) >> You can allocate bits for exponent or significand, which changes >> the range and precision of the representable values. This complicates >> comparison between different representations that might have >> similar bit efficiency. > Range and precision are, indeed, other issues that need to be > considered. Bit efficiency is far from being the single most important > criterion for choosing a floating point format - it's just one criterion > among many. I was only defending the use of the term, which seemed to me > quite unobjectionable - Keith certainly wasn't promoting the idea that > it was the only thing to use when comparing formats. > Note: I should have said "the number of *distinct* real values > representable by the format under discussion". Distinctness isn't a big > issue for the binary floating point formats I'm most familiar with, but > I gather that it's a significant issue for IEEE 754-2008's decimal > floating point formats, with corresponding complications for correctly > calculating the bit efficiency: > "Because the significand is not normalized, most values with less than > 16 significant digits have multiple possible representations; > 1×102=0.1×103=0.01×104, etc. Zero has 768 possible representations (1536 > if you include both signed zeros)." > <https://en.wikipedia.org/wiki/Decimal64_floating-point_format> But different representations aren't the same. I know IBM's HFP better, and am not so sure about IEEE 754-2008. In the IBM case, prenormalization is done using the exponent value, even if all the significand digits are zero. The Fortran AINT function (truncate fractional bits, but keep the type REAL) is done by adding 0*16**7 for single precision, or 0*16**15 for double precision. For prenormalization, values with an exponent smaller than 7 or 15, respectively, will have bits shifted out, and into the guard digit. Then add zero and post normalize. But as noted before, figure out the actual cases and it is a reasonably small fraction in most cases. The 768 zeros out of 2**64 or 2**128 possible is pretty insignificant. Does it matter if it is 99.99% or only 99.9% efficient? -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-12 12:33 -0400 |
| Message-ID | <mt1k0m$t85$1@dont-email.me> |
| In reply to | #70310 |
On 09/11/2015 11:56 PM, glen herrmannsfeldt wrote: > James Kuyper <jameskuyper@verizon.net> wrote: > > (snip, I wrote) >>> You can allocate bits for exponent or significand, which changes >>> the range and precision of the representable values. This complicates >>> comparison between different representations that might have >>> similar bit efficiency. > >> Range and precision are, indeed, other issues that need to be >> considered. Bit efficiency is far from being the single most important >> criterion for choosing a floating point format - it's just one criterion >> among many. I was only defending the use of the term, which seemed to me >> quite unobjectionable - Keith certainly wasn't promoting the idea that >> it was the only thing to use when comparing formats. > >> Note: I should have said "the number of *distinct* real values >> representable by the format under discussion". Distinctness isn't a big >> issue for the binary floating point formats I'm most familiar with, but >> I gather that it's a significant issue for IEEE 754-2008's decimal >> floating point formats, with corresponding complications for correctly >> calculating the bit efficiency: > >> "Because the significand is not normalized, most values with less than >> 16 significant digits have multiple possible representations; >> 1�102=0.1�103=0.01�104, etc. Zero has 768 possible representations (1536 >> if you include both signed zeros)." >> <https://en.wikipedia.org/wiki/Decimal64_floating-point_format> > > But different representations aren't the same. Well, yes. That's why they're called "different". However, different representations of the same value are representations of the same value - that's why they're called "the same". What's you're point? > I know IBM's HFP better, and am not so sure about IEEE 754-2008. > > In the IBM case, prenormalization is done using the exponent value, > even if all the significand digits are zero. The Fortran AINT function > (truncate fractional bits, but keep the type REAL) is done by adding > 0*16**7 for single precision, or 0*16**15 for double precision. > For prenormalization, values with an exponent smaller than 7 or 15, > respectively, will have bits shifted out, and into the guard digit. > Then add zero and post normalize. > > But as noted before, figure out the actual cases and it is a > reasonably small fraction in most cases. The 768 zeros out of 2**64 > or 2**128 possible is pretty insignificant. Does it matter if it > is 99.99% or only 99.9% efficient? It's not just 768 zeros. It says that "most values with fewer than 16 significant digits have multiple representations". I don't fully understand how decimal64 mixes together the significand and the exponent bits, so I'll carry out the following calculations as if they weren't mixed together. Someone who understands the format better than I do should figure out how to correct these calculations. I gather that the text I quoted from the Wikipedia article is not talking about significant digits in terms of their meanings. If you have 500 coins, +/- 1 coin, both of the trailing zeros are significant. However, if you have 500 coins, +/-100 coins, neither zero is significant. But with that definition of "significant digits", it would be impossible for such a statement to be meaningful. It seems to me that they must be counting the non-zero digits from first to last, ignoring both leading and trailing zeros, so that 00876000 has three significant digits, regardless of whether it means 876000 +/- 10 or 876000 +/- 100. That's the meaning I will be using in the following discussion. There are 10^16 different possible sequences of 16 digits. Of those, the ones with 16 significant digits are those where neither the first digit nor the last one are 0. There are 81*10^14 such patterns. The remaining 19*x10^14 different combinations of 16 digits are the ones with fewer than 16 significant digits. For any given value of the exponent, therefore, for every 81 values with 16 significant digits, there 19 with fewer than 16 digits. Not all of those values have multiple representations. Those with the maximum possible exponent and a trailing zero have only one representation, as do those with the minimum possible exponent and a leading zero (I think I got it right, but if I didn't, then I got it reversed - one way or the other, it should be correct). However, the overwhelming majority of those values have multiple representations. Therefore, the fraction of values with multiple representations is approximately 19%. That's not a large fraction, but it's a lot larger than you've been implying. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-09-12 14:29 -0400 |
| Message-ID | <S9_Ix.3360$pu3.2504@fx23.iad> |
| In reply to | #70357 |
On 9/12/15 12:33 PM, James Kuyper wrote: > On 09/11/2015 11:56 PM, glen herrmannsfeldt wrote: >> James Kuyper <jameskuyper@verizon.net> wrote: >> >> (snip, I wrote) >>>> You can allocate bits for exponent or significand, which changes >>>> the range and precision of the representable values. This complicates >>>> comparison between different representations that might have >>>> similar bit efficiency. >> >>> Range and precision are, indeed, other issues that need to be >>> considered. Bit efficiency is far from being the single most important >>> criterion for choosing a floating point format - it's just one criterion >>> among many. I was only defending the use of the term, which seemed to me >>> quite unobjectionable - Keith certainly wasn't promoting the idea that >>> it was the only thing to use when comparing formats. >> >>> Note: I should have said "the number of *distinct* real values >>> representable by the format under discussion". Distinctness isn't a big >>> issue for the binary floating point formats I'm most familiar with, but >>> I gather that it's a significant issue for IEEE 754-2008's decimal >>> floating point formats, with corresponding complications for correctly >>> calculating the bit efficiency: >> >>> "Because the significand is not normalized, most values with less than >>> 16 significant digits have multiple possible representations; >>> 1�102=0.1�103=0.01�104, etc. Zero has 768 possible representations (1536 >>> if you include both signed zeros)." >>> <https://en.wikipedia.org/wiki/Decimal64_floating-point_format> >> >> But different representations aren't the same. > > Well, yes. That's why they're called "different". However, different > representations of the same value are representations of the same value > - that's why they're called "the same". What's you're point? > >> I know IBM's HFP better, and am not so sure about IEEE 754-2008. >> >> In the IBM case, prenormalization is done using the exponent value, >> even if all the significand digits are zero. The Fortran AINT function >> (truncate fractional bits, but keep the type REAL) is done by adding >> 0*16**7 for single precision, or 0*16**15 for double precision. >> For prenormalization, values with an exponent smaller than 7 or 15, >> respectively, will have bits shifted out, and into the guard digit. >> Then add zero and post normalize. >> >> But as noted before, figure out the actual cases and it is a >> reasonably small fraction in most cases. The 768 zeros out of 2**64 >> or 2**128 possible is pretty insignificant. Does it matter if it >> is 99.99% or only 99.9% efficient? > > It's not just 768 zeros. It says that "most values with fewer than 16 > significant digits have multiple representations". I don't fully > understand how decimal64 mixes together the significand and the exponent > bits, so I'll carry out the following calculations as if they weren't > mixed together. Someone who understands the format better than I do > should figure out how to correct these calculations. > > I gather that the text I quoted from the Wikipedia article is not > talking about significant digits in terms of their meanings. If you have > 500 coins, +/- 1 coin, both of the trailing zeros are significant. > However, if you have 500 coins, +/-100 coins, neither zero is > significant. But with that definition of "significant digits", it would > be impossible for such a statement to be meaningful. It seems to me that > they must be counting the non-zero digits from first to last, ignoring > both leading and trailing zeros, so that 00876000 has three significant > digits, regardless of whether it means 876000 +/- 10 or 876000 +/- 100. > That's the meaning I will be using in the following discussion. > > There are 10^16 different possible sequences of 16 digits. Of those, the > ones with 16 significant digits are those where neither the first digit > nor the last one are 0. There are 81*10^14 such patterns. The remaining > 19*x10^14 different combinations of 16 digits are the ones with fewer > than 16 significant digits. For any given value of the exponent, > therefore, for every 81 values with 16 significant digits, there 19 with > fewer than 16 digits. Not all of those values have multiple > representations. Those with the maximum possible exponent and a trailing > zero have only one representation, as do those with the minimum possible > exponent and a leading zero (I think I got it right, but if I didn't, > then I got it reversed - one way or the other, it should be correct). > However, the overwhelming majority of those values have multiple > representations. Therefore, the fraction of values with multiple > representations is approximately 19%. > That's not a large fraction, but it's a lot larger than you've been > implying. > I think you are double counting. A simpler way to do it is to look at the values 0 to 10^16-1. If we all the numbers 10^15 to 10^16-1 to be 'normalized', and that this is THE 'proper' representation of a number. Any number less that 10^15 could have its mantissa increased by a factor of 10, and exponent decreased by 1 (until we hit the smallest exponent). Thus, ignoring what in binary floating point would be 'denormals' we have a 10% redundancy. This needs to be slightly dropped due to those with a minimum exponent (all are unique), and increased by a factor of (1000/1024)^5 due to use 10 bits to store 1000 values, and add a bit for multiple values of infinity and maybe NaN. (The error in counting is that (using 3 digits as an example) you are counting both 150 and 015 as having multiple values, but if you want to determined 'wasted' codes, you need to put one of these back into the usable pool or you can't express some numbers.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-12 15:58 -0400 |
| Message-ID | <mt2023$brp$1@dont-email.me> |
| In reply to | #70366 |
On 09/12/2015 02:29 PM, Richard Damon wrote: > On 9/12/15 12:33 PM, James Kuyper wrote: >> On 09/11/2015 11:56 PM, glen herrmannsfeldt wrote: ... >>> I know IBM's HFP better, and am not so sure about IEEE 754-2008. >>> >>> In the IBM case, prenormalization is done using the exponent value, >>> even if all the significand digits are zero. The Fortran AINT function >>> (truncate fractional bits, but keep the type REAL) is done by adding >>> 0*16**7 for single precision, or 0*16**15 for double precision. >>> For prenormalization, values with an exponent smaller than 7 or 15, >>> respectively, will have bits shifted out, and into the guard digit. >>> Then add zero and post normalize. >>> >>> But as noted before, figure out the actual cases and it is a >>> reasonably small fraction in most cases. The 768 zeros out of 2**64 >>> or 2**128 possible is pretty insignificant. Does it matter if it >>> is 99.99% or only 99.9% efficient? >> >> It's not just 768 zeros. It says that "most values with fewer than 16 >> significant digits have multiple representations". I don't fully >> understand how decimal64 mixes together the significand and the exponent >> bits, so I'll carry out the following calculations as if they weren't >> mixed together. Someone who understands the format better than I do >> should figure out how to correct these calculations. >> >> I gather that the text I quoted from the Wikipedia article is not >> talking about significant digits in terms of their meanings. If you have >> 500 coins, +/- 1 coin, both of the trailing zeros are significant. >> However, if you have 500 coins, +/-100 coins, neither zero is >> significant. But with that definition of "significant digits", it would >> be impossible for such a statement to be meaningful. It seems to me that >> they must be counting the non-zero digits from first to last, ignoring >> both leading and trailing zeros, so that 00876000 has three significant >> digits, regardless of whether it means 876000 +/- 10 or 876000 +/- 100. >> That's the meaning I will be using in the following discussion. >> >> There are 10^16 different possible sequences of 16 digits. Of those, the >> ones with 16 significant digits are those where neither the first digit >> nor the last one are 0. There are 81*10^14 such patterns. The remaining >> 19*x10^14 different combinations of 16 digits are the ones with fewer >> than 16 significant digits. For any given value of the exponent, >> therefore, for every 81 values with 16 significant digits, there 19 with >> fewer than 16 digits. Not all of those values have multiple >> representations. Those with the maximum possible exponent and a trailing >> zero have only one representation, as do those with the minimum possible >> exponent and a leading zero (I think I got it right, but if I didn't, >> then I got it reversed - one way or the other, it should be correct). >> However, the overwhelming majority of those values have multiple >> representations. Therefore, the fraction of values with multiple >> representations is approximately 19%. >> That's not a large fraction, but it's a lot larger than you've been >> implying. >> > > I think you are double counting. A simpler way to do it is to look at More precisely, I was counting the fraction of all representations that have other representations of the same value, rather than the fraction of all distinct values that have multiple representations There are roughly 10 times a many values with two different representations as there are with three (and roughly 10 times as many values with three representations as there are with 4), so that's almost exactly double counting. It's still a much higher percentage than you were previously estimating, while also being only a relatively small fraction. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-13 06:21 +0000 |
| Message-ID | <mt34kh$3fs$1@speranza.aioe.org> |
| In reply to | #70357 |
James Kuyper <jameskuyper@verizon.net> wrote: (snip, I wrote) >> I know IBM's HFP better, and am not so sure about IEEE 754-2008. >> In the IBM case, prenormalization is done using the exponent value, >> even if all the significand digits are zero. The Fortran AINT function >> (truncate fractional bits, but keep the type REAL) is done by adding >> 0*16**7 for single precision, or 0*16**15 for double precision. >> For prenormalization, values with an exponent smaller than 7 or 15, >> respectively, will have bits shifted out, and into the guard digit. >> Then add zero and post normalize. >> But as noted before, figure out the actual cases and it is a >> reasonably small fraction in most cases. The 768 zeros out of 2**64 >> or 2**128 possible is pretty insignificant. Does it matter if it >> is 99.99% or only 99.9% efficient? > It's not just 768 zeros. It says that "most values with fewer than 16 > significant digits have multiple representations". I don't fully > understand how decimal64 mixes together the significand and the exponent > bits, so I'll carry out the following calculations as if they weren't > mixed together. Someone who understands the format better than I do > should figure out how to correct these calculations. Five bits represent both one decimal digit, and the initial digit of the biased exponent, which is 0, 1, or 2. That is, the number of possible exponent values is three times a power of two. > I gather that the text I quoted from the Wikipedia article is not > talking about significant digits in terms of their meanings. If you have > 500 coins, +/- 1 coin, both of the trailing zeros are significant. > However, if you have 500 coins, +/-100 coins, neither zero is > significant. But with that definition of "significant digits", it would > be impossible for such a statement to be meaningful. It seems to me that > they must be counting the non-zero digits from first to last, ignoring > both leading and trailing zeros, so that 00876000 has three significant > digits, regardless of whether it means 876000 +/- 10 or 876000 +/- 100. > That's the meaning I will be using in the following discussion. In usual case of floating point, which doesn't include interval arithmetic, there is no way to distinguish the +/-1 and +/-100 case. You have to keep one of the multiple representable values. > There are 10^16 different possible sequences of 16 digits. Of those, the > ones with 16 significant digits are those where neither the first digit > nor the last one are 0. There are 81*10^14 such patterns. The remaining > 19*x10^14 different combinations of 16 digits are the ones with fewer > than 16 significant digits. For any given value of the exponent, > therefore, for every 81 values with 16 significant digits, there 19 with > fewer than 16 digits. Not all of those values have multiple > representations. Ones with an initial zero digit, non-normalized ones, are the representations other than the one that you keep, so 10%. > Those with the maximum possible exponent and a trailing > zero have only one representation, as do those with the minimum possible > exponent and a leading zero (I think I got it right, but if I didn't, > then I got it reversed - one way or the other, it should be correct). > However, the overwhelming majority of those values have multiple > representations. Therefore, the fraction of values with multiple > representations is approximately 19%. After you keep the one that you need to keep, it should be 10%. That would be worth 0.15 bits. > That's not a large fraction, but it's a lot larger than you've been > implying. There is also the advantage of using the larger base, in that you get a larger range (decimal exponent value) for the exponent bits used. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-06 11:59 -0700 |
| Message-ID | <lnh9n7v0fb.fsf@kst-u.example.com> |
| In reply to | #69560 |
Keith Thompson <kst-u@mib.org> writes:
[...]
> Are you thinking of a scheme that represents both the significand
> and the exponent in binary, but in which the exponent simply
> represents a power of 10? Has any system ever used such a scheme?
> Or are you thinking of something else?
Thinking about this a bit more, such a representation would have
to place the decimal point at the low-order end of the significand,
rather than at or near the high-order end.
A decimal floating-point scheme isn't much use if it can't represent,
for example, 1.1 exactly.
In binary floating-point, the "binary point" is at or near
the high-order end of the significand. The value 99.5, which
is 1100011.1 in binary, can be represented with a significand of
binary 0.11000111, with the exponent denoting multiplication of that
value by 2**8. (In practice, since the leading bit is always 1,
it's usually implicit; this makes 0.0 a special case.)
Similar methods can be used for BCD decimal floating-point, since
the significand can represent a value like 0.995 exactly.
A binary significand cannot represent non-binary fractions exactly,
so the significand would have to store something like 995, with
the exponent denoting multiplication by 10**-1.
You'd probably want an implicit bias on the exponent to keep the
range of positive and negative exponents more or less symmetric.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-12 00:16 +0000 |
| Message-ID | <msvqsa$efq$1@speranza.aioe.org> |
| In reply to | #69635 |
Keith Thompson <kst-u@mib.org> wrote: > Keith Thompson <kst-u@mib.org> writes: > [...] >> Are you thinking of a scheme that represents both the significand >> and the exponent in binary, but in which the exponent simply >> represents a power of 10? Has any system ever used such a scheme? >> Or are you thinking of something else? > Thinking about this a bit more, such a representation would have > to place the decimal point at the low-order end of the significand, > rather than at or near the high-order end. > A decimal floating-point scheme isn't much use if it can't represent, > for example, 1.1 exactly. Not so long ago, someone updated the bias and exponent bits for BFP, so I added them for DFP. Yes the decimal point goes at the right, but then you can set the bias anywhere you want. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-06 18:04 -0700 |
| Message-ID | <kfn4mj7ox8n.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #69560 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Robert Wessel <robertwessel2@yahoo.com> writes: > > [...] > >>> Ultimately any sort of decimal encoding has to be less efficient than >>> binary encoding, since you invariably end up with "invalid" bit >>> patterns. [snip] >> >> This isn't right. Using a decimal base for floating point >> is not inherently less bit efficient than a binary base. >> Using a decimal base can be much less convenient than >> using a binary base, but it is not inherently less bit >> efficient. In particular there needn't be any invalid >> or duplicate bit patterns. > > As sometimes happens, I suspect you're talking about something > subtle that I haven't thought of. [snip] Here is an example scheme for 16 bits. We use one bit for the sign, which leaves 15 bits. Think of those 15 bits as an unsigned number N. If N is zero, the value is 0.0. If N is greater than zero, we get three normalized decimal digits by taking (N-1) % 900 + 100, and putting the decimal point on the left. So that is a value between 0.100 and 0.999, inclusive. We get a decimal exponent value by taking (N-1)/900 - 17. These two taken together give a range of 1.00e-18 to 3.66e+18, assuming I've done my arithmetic correctly. Every value has a unique representation (not counting negative zero, which is a special case), and there are no wasted codes. Obviously we could cadge a few values out of the high end for NaNs or infinity if we wanted to, but that is a minor detail. Is this clear enough, or is more explanation needed?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-06 18:30 -0700 |
| Message-ID | <ln7fo3t3qt.fsf@kst-u.example.com> |
| In reply to | #69712 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>> [...]
>>
>>>> Ultimately any sort of decimal encoding has to be less efficient than
>>>> binary encoding, since you invariably end up with "invalid" bit
>>>> patterns. [snip]
>>>
>>> This isn't right. Using a decimal base for floating point
>>> is not inherently less bit efficient than a binary base.
>>> Using a decimal base can be much less convenient than
>>> using a binary base, but it is not inherently less bit
>>> efficient. In particular there needn't be any invalid
>>> or duplicate bit patterns.
>>
>> As sometimes happens, I suspect you're talking about something
>> subtle that I haven't thought of. [snip]
>
> Here is an example scheme for 16 bits. We use one bit
> for the sign, which leaves 15 bits. Think of those 15
> bits as an unsigned number N.
>
> If N is zero, the value is 0.0.
>
> If N is greater than zero, we get three normalized decimal digits
> by taking (N-1) % 900 + 100, and putting the decimal point on
> the left. So that is a value between 0.100 and 0.999, inclusive.
> We get a decimal exponent value by taking (N-1)/900 - 17. These
> two taken together give a range of 1.00e-18 to 3.66e+18, assuming
> I've done my arithmetic correctly. Every value has a unique
> representation (not counting negative zero, which is a special
> case), and there are no wasted codes. Obviously we could cadge
> a few values out of the high end for NaNs or infinity if we
> wanted to, but that is a minor detail.
>
> Is this clear enough, or is more explanation needed?
So you're talking about a representation that partitions the 15
bits into a significand and an exponent, but the boundary is not
on a bit boundary. An interesting idea, though I'm not at all sure
how practical it is.
In any case, if that's what you had in mind, just saying that
"Using a decimal base for floating point is not inherently less
bit efficient than a binary base" gives the impression that you
were being deliberately vague.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-09-06 18:48 -0700 |
| Message-ID | <c9f389ac-6936-4804-80b2-6de690766341@googlegroups.com> |
| In reply to | #69720 |
On Monday, September 7, 2015 at 2:30:58 AM UTC+1, Keith Thompson wrote: > Tim Rentsch <txr@alumni.caltech.edu> writes: > > So you're talking about a representation that partitions the 15 > bits into a significand and an exponent, but the boundary is not > on a bit boundary. An interesting idea, though I'm not at all sure > how practical it is. > I wouldn't like to say how easy it would be to make a hardware unit that processed such numbers. But a software implementation from Tim's description should be relatively easy.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-07 00:44 -0500 |
| Message-ID | <0b8quapdsb76bla3tue8r39v6eoa4eqk4b@4ax.com> |
| In reply to | #69720 |
On Sun, 06 Sep 2015 18:30:50 -0700, Keith Thompson <kst-u@mib.org> wrote: > >So you're talking about a representation that partitions the 15 >bits into a significand and an exponent, but the boundary is not >on a bit boundary. An interesting idea, though I'm not at all sure >how practical it is. That exactly what IEEE DFP does. The most significant digit of the significand is encoded with the exponent. If the first two bits of the exponent field are 00/01/10, then the exponent starts with 00/01/10, and the next three bits are the leading decimal digit, 0-7, and the remainder of the exponent field are the rest of the exponent bits. If the exponent starts with 1100/1101/1110, the exponent starts with 00/01/10, and the next single bit selects a leading decimal digit of 8 or 9. Exponents starting with 1111 encode infinities and NaNs. So there are some 768 possible exponent values for DFP doubles.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-10 05:44 -0700 |
| Message-ID | <kfnzj0ujvfr.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #69720 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>> Robert Wessel <robertwessel2@yahoo.com> writes: >>> >>> [...] >>> >>>>> Ultimately any sort of decimal encoding has to be less efficient than >>>>> binary encoding, since you invariably end up with "invalid" bit >>>>> patterns. [snip] >>>> >>>> This isn't right. Using a decimal base for floating point >>>> is not inherently less bit efficient than a binary base. >>>> Using a decimal base can be much less convenient than >>>> using a binary base, but it is not inherently less bit >>>> efficient. In particular there needn't be any invalid >>>> or duplicate bit patterns. >>> >>> As sometimes happens, I suspect you're talking about something >>> subtle that I haven't thought of. [snip] >> >> Here is an example scheme for 16 bits. We use one bit >> for the sign, which leaves 15 bits. Think of those 15 >> bits as an unsigned number N. >> >> If N is zero, the value is 0.0. >> >> If N is greater than zero, we get three normalized decimal digits >> by taking (N-1) % 900 + 100, and putting the decimal point on >> the left. So that is a value between 0.100 and 0.999, inclusive. >> We get a decimal exponent value by taking (N-1)/900 - 17. These >> two taken together give a range of 1.00e-18 to 3.66e+18, assuming >> I've done my arithmetic correctly. Every value has a unique >> representation (not counting negative zero, which is a special >> case), and there are no wasted codes. Obviously we could cadge >> a few values out of the high end for NaNs or infinity if we >> wanted to, but that is a minor detail. >> >> Is this clear enough, or is more explanation needed? > > So you're talking about a representation that partitions the 15 > bits into a significand and an exponent, but the boundary is not > on a bit boundary. Yes, that's a way of saying it I guess. But I think you have the idea. > An interesting idea, though I'm not at all > sure how practical it is. My point upthread was about inherent bit efficiency, not about how convenient such a scheme would be. However I think this scheme could serve a practical purpose, for storing lots of values in a comparatively small amount of memory, with computation being done primarily in another format. If it's important to trade speed for space (and working in a decimal system otherwise), this representation is pretty good. > In any case, if that's what you had in mind, just saying that > "Using a decimal base for floating point is not inherently less > bit efficient than a binary base" gives the impression that you > were being deliberately vague. I don't like to beat people over the head with an explanation, especially people that I think are smart enough to figure out what is meant without such an explanation. Part of the reason for this is that in the past I've been accused of lecturing people (and coming across as condescending), so to compensate for that I often go the other. I'm sorry if it came across as deliberately vague, which certainly was not my intention.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web