Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #66705 > unrolled thread

routine for angles needed

Back to article view | Back to comp.lang.c

Contents

  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 Robert Wessel <robertwessel2@yahoo.com> - 2015-09-07 00:31 -0500
                                                  Re: routine for angles needed Keith Thompson <kst-u@mib.org> - 2015-09-06 11:59 -0700
                                                  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 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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#66796

W dniu poniedziałek, 3 sierpnia 2015 18:06:55 UTC+2 użytkownik Bart napisał:
> On 03/08/2015 15:48, fir wrote:
> > W dniu niedziela, 2 sierpnia 2015 22:15:19 UTC+2 użytkownik Malcolm McLean napisał:
> >> On Sunday, August 2, 2015 at 8:40:18 PM UTC+1, Bart wrote:
> >>> On 02/08/2015 20:32, Malcolm McLean wrote:
> >>>
> >>> But there is a small chance, depending on how the angle was created, of
> >>> having a very large value to normalise what could cause a program to
> >>> take a long time or even hang.
> >>>
> >>> I don't know if using fmod() would help here. (When I coded this, I
> >>> limited the number of while-loops.)
> >>>
> >> Yes, it's probably worth breaking out into a function that won't
> >> take excessive time on super-high inputs.
> >> But if the angles are way out of the range -2PI to 2PI, then there's
> >> almost certainly a bug elsewhere.
> >
> > seems so but otherwise someone may have a concept of multiplying rotations/turns
> > (like by five) then you will have those
> > spiral rotations with memory of them
> > (integer part + fractional )
> >
> > anyway it also brings the idea of extending %
> > operator for floats too,
> >
> > float a = 9 % 3.33; //should give 0.01 if im not wrong
> 
> I make it about 2.34 (what you get after repeatedly subtracting 3.33 
> from 9.0, until you having something less than 3.33).
> 
> This is equivalent to 900 % 333 which gives 234.
> 
heh, youre right, i thought 10 % 3.33 but mistaken write

[toc] | [prev] | [next] | [standalone]

#66797

W dniu poniedziałek, 3 sierpnia 2015 18:09:15 UTC+2 użytkownik fir napisał:
> W dniu poniedziałek, 3 sierpnia 2015 18:06:55 UTC+2 użytkownik Bart napisał:
> > On 03/08/2015 15:48, fir wrote:
> > > W dniu niedziela, 2 sierpnia 2015 22:15:19 UTC+2 użytkownik Malcolm McLean napisał:
> > >> On Sunday, August 2, 2015 at 8:40:18 PM UTC+1, Bart wrote:
> > >>> On 02/08/2015 20:32, Malcolm McLean wrote:
> > >>>
> > >>> But there is a small chance, depending on how the angle was created, of
> > >>> having a very large value to normalise what could cause a program to
> > >>> take a long time or even hang.
> > >>>
> > >>> I don't know if using fmod() would help here. (When I coded this, I
> > >>> limited the number of while-loops.)
> > >>>
> > >> Yes, it's probably worth breaking out into a function that won't
> > >> take excessive time on super-high inputs.
> > >> But if the angles are way out of the range -2PI to 2PI, then there's
> > >> almost certainly a bug elsewhere.
> > >
> > > seems so but otherwise someone may have a concept of multiplying rotations/turns
> > > (like by five) then you will have those
> > > spiral rotations with memory of them
> > > (integer part + fractional )
> > >
> > > anyway it also brings the idea of extending %
> > > operator for floats too,
> > >
> > > float a = 9 % 3.33; //should give 0.01 if im not wrong
> > 
> > I make it about 2.34 (what you get after repeatedly subtracting 3.33 
> > from 9.0, until you having something less than 3.33).
> > 
> > This is equivalent to 900 % 333 which gives 234.
> > 
> heh, youre right, i thought 10 % 3.33 but mistaken write

ps why about it should be axactly 2.34

2*3.33 + 2.34

[toc] | [prev] | [next] | [standalone]

#66801

On 03/08/2015 17:17, fir wrote:
> W dniu poniedziałek, 3 sierpnia 2015 18:09:15 UTC+2 użytkownik fir napisał:
>> W dniu poniedziałek, 3 sierpnia 2015 18:06:55 UTC+2 użytkownik Bart napisał:
>>> On 03/08/2015 15:48, fir wrote:

>>>> float a = 9 % 3.33; //should give 0.01 if im not wrong
>>>
>>> I make it about 2.34 (what you get after repeatedly subtracting 3.33
>>> from 9.0, until you having something less than 3.33).
>>>
>>> This is equivalent to 900 % 333 which gives 234.
>>>
>> heh, youre right, i thought 10 % 3.33 but mistaken write
>
> ps why about it should be axactly 2.34
>
> 2*3.33 + 2.34

C uses binary floating point. 3.33 can only be expressed approximately. 
Hence the 2.34 is also approximate.

On my machine, some answers I get for fmod(9,3.33) are:

   2.3399999999999999000000000000000000000000

   2.3399999999999998578000000000000000000000

   2.3399999999999998578914528479799628257751

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#66815

Bartc <bc@freeuk.com> writes:
[...]
> C uses binary floating point.
[...]

Most (probably nearly all) C implementations use binary floating-point.
The standard permits other bases, which is why FLT_RADIX exists.

Some IBM mainframe systems use base 16 -- which has most of the
characteristics of binary, but the precision fluctuates more depending
on the exponent value.  Base 10 floating-point is not unheard of.

-- 
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]

#66817

On 03/08/2015 21:44, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
> [...]
>> C uses binary floating point.
> [...]
>
> Most (probably nearly all) C implementations use binary floating-point.
> The standard permits other bases, which is why FLT_RADIX exists.
>
> Some IBM mainframe systems use base 16 -- which has most of the
> characteristics of binary, but the precision fluctuates more depending
> on the exponent value.  Base 10 floating-point is not unheard of.

Using that knowledge, that there might be systems for which C doesn't 
use binary FP, would you be able to say that fmod(9.0,3.33) gives 
exactly 2.34?

Probably not... Certainly you couldn't rely on it.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#66831

Bartc <bc@freeuk.com> writes:
> On 03/08/2015 21:44, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>> [...]
>>> C uses binary floating point.
>> [...]
>>
>> Most (probably nearly all) C implementations use binary floating-point.
>> The standard permits other bases, which is why FLT_RADIX exists.
>>
>> Some IBM mainframe systems use base 16 -- which has most of the
>> characteristics of binary, but the precision fluctuates more depending
>> on the exponent value.  Base 10 floating-point is not unheard of.
>
> Using that knowledge, that there might be systems for which C doesn't 
> use binary FP, would you be able to say that fmod(9.0,3.33) gives 
> exactly 2.34?
>
> Probably not... Certainly you couldn't rely on it.

Certainly not.  On my system it yields
    2.339999999999999857891452847979962825775146484375
or equivalently
    0x1.2b851eb851eb8p+1

On a system where FLT_RADIX == 10 (or is a power of 10), fmod(9.0, 3.33)
probably would be exactly 2.34.

-- 
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]

#66819

Keith Thompson <kst-u@mib.org> wrote:
> Bartc <bc@freeuk.com> writes:
> [...]
>> C uses binary floating point.
> [...]
 
> Most (probably nearly all) C implementations use binary floating-point.
> The standard permits other bases, which is why FLT_RADIX exists.

I believe there are, or have been, some that are radix 8.

IBM S/360 and descendants use 16. Rumors are that it was Java that
cause them to add IEEE binary to ESA/390, (now called BFP for binary
floating point, the previous one now called HFP). 

> Some IBM mainframe systems use base 16 -- which has most of the
> characteristics of binary, but the precision fluctuates more depending
> on the exponent value.  Base 10 floating-point is not unheard of.

With the addition of decimal floating point to IEEE 754-2008,
decimal floating point (DFP) was added to z/Architecture in addition
to keeping HFP and BFP.  So, all three on one machine!

I don't know how much IBM C compilers support.

-- glen

[toc] | [prev] | [next] | [standalone]

#66823

On 04/08/2015 00:11, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
>> Bartc <bc@freeuk.com> writes:
>> [...]
>>> C uses binary floating point.
>> [...]
>
>> Most (probably nearly all) C implementations use binary floating-point.
>> The standard permits other bases, which is why FLT_RADIX exists.
>
> I believe there are, or have been, some that are radix 8.
>
> IBM S/360 and descendants use 16. Rumors are that it was Java that
> cause them to add IEEE binary to ESA/390, (now called BFP for binary
> floating point, the previous one now called HFP).

What does it actually mean that floating point format uses radix 8 or 16?

If someone decided to take an 8-bit byte type and implement it as 2 hex 
digits instead, but difference would it make? I'd imagine that shifts 
would work differently: a 1 digit shift in hex is the same as a 4-bit 
shift in binary; anything else?

Does floating point in radix 16 solve the problem of representing 0.1?

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#66829

Bartc <bc@freeuk.com> wrote:

(snip, I wrote)
>> IBM S/360 and descendants use 16. Rumors are that it was Java that
>> cause them to add IEEE binary to ESA/390, (now called BFP for binary
>> floating point, the previous one now called HFP).
 
> What does it actually mean that floating point format uses radix 8 or 16?

That the exponent base is 8 or 16. Pre and post normalization is done
in multiples of 3 or 4 bits. It allows for a larger exponent range
for the bits allocated to the exponent, though a larger variation
in the precision of the significand. 
 
> If someone decided to take an 8-bit byte type and implement it as 2 hex 
> digits instead, but difference would it make? I'd imagine that shifts 
> would work differently: a 1 digit shift in hex is the same as a 4-bit 
> shift in binary; anything else?

For fixed point, you normally don't notice. 
 
> Does floating point in radix 16 solve the problem of representing 0.1?

No, but DFP does. The DFP format makes very efficient use of the
bits, and also the exponent shift points match those that
users expect. If the goal is to print out some number if
decimal digits, as it is in many scientific programs, DFP
does a better job at allocating the bits. 

The hardware DFP format stores three decimal digits in 10 bits.
The IEEE single precision format has 16 digits stored in 
about 53 bits, and a base 10 exponent of between -383 and +384.
(Some bit patterns mix exponent and significand to allow for
the full precision and optimal range.)

-- glen

[toc] | [prev] | [next] | [standalone]

#66833

On Tue, 4 Aug 2015 01:14:22 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>No, but DFP does. The DFP format makes very efficient use of the
>bits, and also the exponent shift points match those that
>users expect. If the goal is to print out some number if
>decimal digits, as it is in many scientific programs, DFP
>does a better job at allocating the bits. 
>
>The hardware DFP format stores three decimal digits in 10 bits.
>The IEEE single precision format has 16 digits stored in 
>about 53 bits, and a base 10 exponent of between -383 and +384.
>(Some bit patterns mix exponent and significand to allow for
>the full precision and optimal range.)


While the DFP format is pretty efficient for a *decimal* format, it is
still less efficient in terms of rendered precision per bit of storage
than binary FP.  BFP doubles have some 9 times more numbers in their
mantissas (IOW almost an entire extra decimal digit worth) than DFP
doubles, while at the same time having a considerable wider exponent
range.

[toc] | [prev] | [next] | [standalone]

#66875

Robert Wessel <robertwessel2@yahoo.com> wrote:

(snip, I wrote)
>>The hardware DFP format stores three decimal digits in 10 bits.
>>The IEEE single precision format has 16 digits stored in 
>>about 53 bits, and a base 10 exponent of between -383 and +384.
>>(Some bit patterns mix exponent and significand to allow for
>>the full precision and optimal range.)
 
> While the DFP format is pretty efficient for a *decimal* format, it is
> still less efficient in terms of rendered precision per bit of storage
> than binary FP.  BFP doubles have some 9 times more numbers in their
> mantissas (IOW almost an entire extra decimal digit worth) than DFP
> doubles, while at the same time having a considerable wider exponent
> range.

https://en.wikipedia.org/wiki/IEEE_floating_point#Basic_and_interchange_formats

Comparing binary64 and decimal64, binary has about 2**52 different
significands (with the high bit 1), and a decimal exponent range
of about +/-308.

Decimal 64 has about 10**16, or about 2**53.15 significand values
(not nine times less) and a decimal exponent range about +/-384,
so slightly more than for binary.

-- glen

[toc] | [prev] | [next] | [standalone]

#66903

On Tue, 4 Aug 2015 18:24:32 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>Robert Wessel <robertwessel2@yahoo.com> wrote:
>
>(snip, I wrote)
>>>The hardware DFP format stores three decimal digits in 10 bits.
>>>The IEEE single precision format has 16 digits stored in 
>>>about 53 bits, and a base 10 exponent of between -383 and +384.
>>>(Some bit patterns mix exponent and significand to allow for
>>>the full precision and optimal range.)
> 
>> While the DFP format is pretty efficient for a *decimal* format, it is
>> still less efficient in terms of rendered precision per bit of storage
>> than binary FP.  BFP doubles have some 9 times more numbers in their
>> mantissas (IOW almost an entire extra decimal digit worth) than DFP
>> doubles, while at the same time having a considerable wider exponent
>> range.
>
>https://en.wikipedia.org/wiki/IEEE_floating_point#Basic_and_interchange_formats
>
>Comparing binary64 and decimal64, binary has about 2**52 different
>significands (with the high bit 1), and a decimal exponent range
>of about +/-308.
>
>Decimal 64 has about 10**16, or about 2**53.15 significand values
>(not nine times less) and a decimal exponent range about +/-384,
>so slightly more than for binary.


Well, this is a fine mess I've made...

While it's true that you only have 2**52 values for a given exponent,
you get another 2**52 with the exponent adjusted by one.  You can't do
the same thing with higher bases.  So you really have to consider BFP
doubles to have 53 bits of precision.  That being said, that's about
15.95 decimal digits of precision, which is less than the 16 digits
nominally provided by a DFP double.  On the flip side, the wobble
takes out a good chuck of that highest decimal digit in terms of
useful precision for DFP.

And you're quite correct that I neglected to consider the decimal vs.
binary range of the exponents.

In short, I pretty much pooched all of that.

But, my actual point, that the DFP format was not particularly
efficient in encoding numbers, at least compared with BFP, is still
correct.

To simplify a bit, though, let's assume normalized numbers in both
cases (that assumption favors DFP, where unnormalized numbers are
possible, and reduce the actual quantity of possible numbers), and
ignoring special cases (zeros, NaNs, Infs, denormals, etc.), you have
BFP doubles representing some 2046*(2**52) different numbers (about
9.2E+18), while with DFP you have 768*(10**16) (about 7.7E+18), so
even biasing the assumptions towards DFP, the BFP format can represent
nearly 20% more numbers than the DFP format.

Ultimately any sort of decimal encoding has to be less efficient than
binary encoding, since you invariably end up with "invalid" bit
patterns.  Consider the DPD format, which for a DFP double includes 5
"declets" of ten bits each, each of which codes three decimal digits
(the other digit is encoded with the exponent).  This uses only 1000
of the 1024 possible bit patterns in each declet (the DPD encoding has
redundant codings rather than invalid ones, FWIW).

[toc] | [prev] | [next] | [standalone]

#66923

Robert Wessel <robertwessel2@yahoo.com> wrote:

(snip, I wrote)
>>https://en.wikipedia.org/wiki/IEEE_floating_point#Basic_and_interchange_formats

>>Comparing binary64 and decimal64, binary has about 2**52 different
>>significands (with the high bit 1), and a decimal exponent range
>>of about +/-308.

>>Decimal 64 has about 10**16, or about 2**53.15 significand values
>>(not nine times less) and a decimal exponent range about +/-384,
>>so slightly more than for binary.
 
> Well, this is a fine mess I've made...
 
> While it's true that you only have 2**52 values for a given exponent,
> you get another 2**52 with the exponent adjusted by one.  You can't do
> the same thing with higher bases.  So you really have to consider BFP
> doubles to have 53 bits of precision.  That being said, that's about
> 15.95 decimal digits of precision, which is less than the 16 digits
> nominally provided by a DFP double.  On the flip side, the wobble
> takes out a good chuck of that highest decimal digit in terms of
> useful precision for DFP.

Since 15.95 is close to 16, you have a good chance of 16 digits
when converted to decimal for printing of having 16 digits.

With 16 digit DFP, you have exactly the digits to print.
 
> And you're quite correct that I neglected to consider 
> the decimal vs. binary range of the exponents.
 
> In short, I pretty much pooched all of that.
 
> But, my actual point, that the DFP format was not particularly
> efficient in encoding numbers, at least compared with BFP, is still
> correct.
 
> To simplify a bit, though, let's assume normalized numbers in both
> cases (that assumption favors DFP, where unnormalized numbers are
> possible, and reduce the actual quantity of possible numbers), and
> ignoring special cases (zeros, NaNs, Infs, denormals, etc.), you have
> BFP doubles representing some 2046*(2**52) different numbers (about
> 9.2E+18), while with DFP you have 768*(10**16) (about 7.7E+18), so
> even biasing the assumptions towards DFP, the BFP format can represent
> nearly 20% more numbers than the DFP format.

So 20%, or about 0.26 bits worth. 

When deciding on a floating point format, there is always a
balance between exponent bits and range. Note that the IEEE DFP
format has more exponent range. You could generate a binary format
with one additional exponent bit, and one less significand bit,
to exceed that range. 

> Ultimately any sort of decimal encoding has to be less efficient than
> binary encoding, since you invariably end up with "invalid" bit
> patterns.  Consider the DPD format, which for a DFP double includes 5
> "declets" of ten bits each, each of which codes three decimal digits
> (the other digit is encoded with the exponent).  This uses only 1000
> of the 1024 possible bit patterns in each declet (the DPD encoding has
> redundant codings rather than invalid ones, FWIW).

But the number of redundant codes doesn't really matter, as long
as it covers the ones you want to use.  That is always the question.

-- glen

[toc] | [prev] | [next] | [standalone]

#69513

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Tue, 4 Aug 2015 18:24:32 +0000 (UTC), glen herrmannsfeldt
> <gah@ugcs.caltech.edu> wrote:
>
>> Robert Wessel <robertwessel2@yahoo.com> wrote:
>>
>> (snip, I wrote)
>>>> The hardware DFP format stores three decimal digits in 10 bits.
>>>> The IEEE single precision format has 16 digits stored in 
>>>> about 53 bits, and a base 10 exponent of between -383 and +384.
>>>> (Some bit patterns mix exponent and significand to allow for
>>>> the full precision and optimal range.)
>>>
>>> While the DFP format is pretty efficient for a *decimal* format, it is
>>> still less efficient in terms of rendered precision per bit of storage
>>> than binary FP.  BFP doubles have some 9 times more numbers in their
>>> mantissas (IOW almost an entire extra decimal digit worth) than DFP
>>> doubles, while at the same time having a considerable wider exponent
>>> range.
>>
>> https://en.wikipedia.org/wiki/IEEE_floating_point#Basic_and_interchange_formats
>>
>> Comparing binary64 and decimal64, binary has about 2**52 different
>> significands (with the high bit 1), and a decimal exponent range
>> of about +/-308.
>>
>> Decimal 64 has about 10**16, or about 2**53.15 significand values
>> (not nine times less) and a decimal exponent range about +/-384,
>> so slightly more than for binary.
>
> [snip]
>
> 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.

[toc] | [prev] | [next] | [standalone]

#69560

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.

The most obvious way to implement decimal floating-point on a
binary machine is to use binary-coded decimal, with each decimal
digit encoded as 4 bits.  This is obviously bit-inefficient, using
only 10 of 16 possible bit patterns, effectively wasting about 17%
of the bits.

Another approach I've seen is to use 10 bits to store values from
0 to 1000, using 1000 of 1024 possible bit patterns, which is
about 99.66% efficient.  I think IBM has proposed, and probably
implemented, something like this.

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?

-- 
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]

#69562

On 9/5/15 7:24 PM, Keith Thompson 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.
>
> As sometimes happens, I suspect you're talking about something
> subtle that I haven't thought of.
>
> The most obvious way to implement decimal floating-point on a
> binary machine is to use binary-coded decimal, with each decimal
> digit encoded as 4 bits.  This is obviously bit-inefficient, using
> only 10 of 16 possible bit patterns, effectively wasting about 17%
> of the bits.
>
> Another approach I've seen is to use 10 bits to store values from
> 0 to 1000, using 1000 of 1024 possible bit patterns, which is
> about 99.66% efficient.  I think IBM has proposed, and probably
> implemented, something like this.
>
> 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?
>

IEEE has a standard for Decimal Floating point that basically does that. 
You get about 3 digits of precision for 10 bits. Because the binary 
floating points formats don't give you multiple of 3 precision normally 
(std precision in 7 digits, double is 16 digits) the add a 5 bit field 
that encode one digit of precision with 2 bits (with range of only 0-2) 
of high bits of exponent (10 * 3 = 30, 5 bits with 2 left over codes).

[toc] | [prev] | [next] | [standalone]

#69569

On Sat, 05 Sep 2015 16:24:49 -0700, 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.
>
>As sometimes happens, I suspect you're talking about something
>subtle that I haven't thought of.
>
>The most obvious way to implement decimal floating-point on a
>binary machine is to use binary-coded decimal, with each decimal
>digit encoded as 4 bits.  This is obviously bit-inefficient, using
>only 10 of 16 possible bit patterns, effectively wasting about 17%
>of the bits.
>
>Another approach I've seen is to use 10 bits to store values from
>0 to 1000, using 1000 of 1024 possible bit patterns, which is
>about 99.66% efficient.  I think IBM has proposed, and probably
>implemented, something like this.
>
>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?


That would certainly make alignment and normalization more painful
that with some encoded decimal scheme.

[toc] | [prev] | [next] | [standalone]

#69576

Robert Wessel <robertwessel2@yahoo.com> wrote:

(snip, Keith wrote)

>>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?
 
> That would certainly make alignment and normalization more painful
> that with some encoded decimal scheme.

Processing the 10 bits for three digits form in software, using
masking and shifting is painful. Pre/post normalization of a
binary representation of some number of decimal digits is easy
if you have fast multiply and divide, especially if you have 
multiply that generates a full (double) length product, and
divide that takes a double length dividend. 

-- glen

[toc] | [prev] | [next] | [standalone]

#69739

On Sun, 6 Sep 2015 05:37:56 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>Robert Wessel <robertwessel2@yahoo.com> wrote:
>
>(snip, Keith wrote)
>
>>>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?
> 
>> That would certainly make alignment and normalization more painful
>> that with some encoded decimal scheme.
>
>Processing the 10 bits for three digits form in software, using
>masking and shifting is painful. Pre/post normalization of a
>binary representation of some number of decimal digits is easy
>if you have fast multiply and divide, especially if you have 
>multiply that generates a full (double) length product, and
>divide that takes a double length dividend. 


Converting groups of ten-bits/three-decimal-digits in hardware is
pretty easy and fast.  IOW, you do all the actual work in "pure" BCD.
I've never really looked at any hardware implementation of IEEE DFP,
but I wouldn't be surprised if that was a a common approach.

[toc] | [prev] | [next] | [standalone]

#69574

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.
They can be spaced differently along the real line.
 
> As sometimes happens, I suspect you're talking about something
> subtle that I haven't thought of.
 
> The most obvious way to implement decimal floating-point on a
> binary machine is to use binary-coded decimal, with each decimal
> digit encoded as 4 bits.  This is obviously bit-inefficient, using
> only 10 of 16 possible bit patterns, effectively wasting about 17%
> of the bits.
 
> Another approach I've seen is to use 10 bits to store values from
> 0 to 1000, using 1000 of 1024 possible bit patterns, which is
> about 99.66% efficient.  I think IBM has proposed, and probably
> implemented, something like this.

Not only proposed, but it is in IEEE 754-2008.
 
> 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?

The 10 bits to store three digits form works pretty well for hardware
implementations. It is much less convenient to implement in software
on a machine that otherwise does binary arithmetic. Storing the
significand in binary allows for fairly efficient (in processing
time) software implementations. You do need to do some multiply
and divide by powers of 10 for pre/post normalization. 

As with the IEEE 754-2008 forms, some bits hold a mix of exponent
and significand bits for  good bit efficiency.

-- glen


 

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web