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

#69622

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]

#69628

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]

#69631

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]

#69740

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]

#69635

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]

#69712

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]

#69720

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]

#69723

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]

#69741

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]

#66830

On Tue, 04 Aug 2015 01:32:32 +0100, Bartc <bc@freeuk.com> wrote:

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


Scaling and shifts are in multiples of four bits.  You also can't have
an implied one bit (since the leading significant digit can not be
1-15, not just a 1).  This effectively causes the precision to
"wobbled" by about 3 bits (a number with a most significant digit of 1
has less bits of precision than one with a first digit of 8..15).  So
double floats on S/360 had 14 hexadecimal digits of precision, a seven
bit exponent (-64..+63 - equivalent to -256..+252 for a binary FP
number), and a sign.

The intention was to speed things up by reducing the amount of
shifting needed, and to add a bit of extra precision to the numbers by
having a shorter exponent (one of the concerns was that moving from
the 7000 series machines 36 bit single precision floats to 32 bit
floats on S/360 would cause problems).  The first might have been
relevant on some low end machines, but was pretty much irrelevant
where it might have mattered.  The wobbling precision and loss of an
implied one bit actually made the effective precision *worse*.

Then there was the original implementation without guard digits, and
you had IBM field refitting the FPUs on pretty much all the early 360s
they shipped (at least the ones with the FP feature).


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


No.

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

#66834

Robert Wessel <robertwessel2@yahoo.com> wrote:
> On Tue, 04 Aug 2015 01:32:32 +0100, Bartc <bc@freeuk.com> wrote:

(snip)
>>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?
 
> Scaling and shifts are in multiples of four bits.  You also can't have
> an implied one bit (since the leading significant digit can not be
> 1-15, not just a 1).  This effectively causes the precision to
> "wobbled" by about 3 bits (a number with a most significant digit of 1
> has less bits of precision than one with a first digit of 8..15).  So
> double floats on S/360 had 14 hexadecimal digits of precision, a seven
> bit exponent (-64..+63 - equivalent to -256..+252 for a binary FP
> number), and a sign.

Yes, but the precision also wobbles in decimal, the way people
often print out numbers. We says that some values has "3 significant
digits", but 100 has only two, and 999 has slightly less than three.

And the precision even wobbles in binary, though not quite as much.
 
> The intention was to speed things up by reducing the amount of
> shifting needed, 

Well, it makes for a more efficient barrel shifter on high-end
models. I suppose also faster shifts on low-end models.

> and to add a bit of extra precision to the numbers by
> having a shorter exponent (one of the concerns was that moving from
> the 7000 series machines 36 bit single precision floats to 32 bit
> floats on S/360 would cause problems).  The first might have been
> relevant on some low end machines, but was pretty much irrelevant
> where it might have mattered.  The wobbling precision and loss of an
> implied one bit actually made the effective precision *worse*.

If you require the same exponent range, you need to give the exponent
one more bit than for IEEE single, so one less significand bit.

For many algorithms, the precision of the result depends on the
average precision (within the wobble) of the values. 
 
> Then there was the original implementation without guard digits, and
> you had IBM field refitting the FPUs on pretty much all the early 360s
> they shipped (at least the ones with the FP feature).
 
>>Does floating point in radix 16 solve the problem of representing 0.1?
 
> No.

-- glen

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

#66905

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

>Robert Wessel <robertwessel2@yahoo.com> wrote:
>> On Tue, 04 Aug 2015 01:32:32 +0100, Bartc <bc@freeuk.com> wrote:
>
>(snip)
>>>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?
> 
>> Scaling and shifts are in multiples of four bits.  You also can't have
>> an implied one bit (since the leading significant digit can not be
>> 1-15, not just a 1).  This effectively causes the precision to
>> "wobbled" by about 3 bits (a number with a most significant digit of 1
>> has less bits of precision than one with a first digit of 8..15).  So
>> double floats on S/360 had 14 hexadecimal digits of precision, a seven
>> bit exponent (-64..+63 - equivalent to -256..+252 for a binary FP
>> number), and a sign.
>
>Yes, but the precision also wobbles in decimal, the way people
>often print out numbers. We says that some values has "3 significant
>digits", but 100 has only two, and 999 has slightly less than three.
>
>And the precision even wobbles in binary, though not quite as much.


That true, the wobble in binary is just under a bit, in hex just under
4 bits, and in decimal just under 3.322 bits

 
>> The intention was to speed things up by reducing the amount of
>> shifting needed, 
>
>Well, it makes for a more efficient barrel shifter on high-end
>models. I suppose also faster shifts on low-end models.
>
>> and to add a bit of extra precision to the numbers by
>> having a shorter exponent (one of the concerns was that moving from
>> the 7000 series machines 36 bit single precision floats to 32 bit
>> floats on S/360 would cause problems).  The first might have been
>> relevant on some low end machines, but was pretty much irrelevant
>> where it might have mattered.  The wobbling precision and loss of an
>> implied one bit actually made the effective precision *worse*.
>
>If you require the same exponent range, you need to give the exponent
>one more bit than for IEEE single, so one less significand bit.
>
>For many algorithms, the precision of the result depends on the
>average precision (within the wobble) of the values. 


Then with have to get into trying to define the average precision.  If
we just assume half the wobble, it's trivially 2, 1.66 and .5 bits for
hex/decimal/binary.  OTOH, FP numbers in practice seems to be somewhat
logarithmically distributed (numbers in the range [b**n..b**(n+1)) are
more likely to be near the bottom of that range - Benford's law),
which implies that the wobble is actually worse.

But the precision of the results to be limited by the precision of the
inputs, so while the average precision for an algorithm may be related
to the average precision of the inputs, and hence the average or
typical wobble, the worst case, which I'm probably more likely to
worry about, is going to be related to the worst case wobbles.

The problem is not just the inputs, but the intermediate results as
well.  With BFP results will have some 52 useful bits of precision,
after allowing for the worst case wobble.  In DFP, with 16 decimal
digits, it's about 49.8 bits.

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

#66832

Bartc <bc@freeuk.com> writes:
> 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?

It means that the exponent part of the floating-point representation is
a power of 16 (or 8) rather than of 2.

You can represent a wider range of numbers using the same number of
exponent bits, but at the expense of some loss of precision for some
values.

With binary floating-point, the difference between consecutive
representable numbers jumps by a factor of 2 every time the exponent
value changes.  With hexadecimal, it jumps by a factor of 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?

No.  Why would it?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#66887

Keith Thompson <kst-u@mib.org> wrote:

(snip on different bases for floating point values)

> It means that the exponent part of the floating-point 
> representation is a power of 16 (or 8) rather than of 2.
 
> You can represent a wider range of numbers using the same number of
> exponent bits, but at the expense of some loss of precision for some
> values.

Note that the loss of precision for some values also happens when
you convert to a different base to output the value. 

Converting to decimal, as is common, gives the decimal exponent
jumps, which don't match the jumps in (most) other bases.

Some people forget about the increase in the exponent range for a
given number of exponent bits.
 
> With binary floating-point, the difference between consecutive
> representable numbers jumps by a factor of 2 every time the exponent
> value changes.  With hexadecimal, it jumps by a factor of 16.

Yes.

One difference that this makes in real algorithms is that multiplying
by two and then dividing by two, doesn't always give the same value.
There is a simple modification of Newton-Raphson to handle this case.

(snip)

-- glen

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

#66824

On Mon, 3 Aug 2015 23:11:21 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> 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). 


Almost certainly.  Java support was pretty much the first thing from
IBM that supported the FP ISA (except for the assembler and C
compiler).  The JVM prior to that emulated IEEE FP in software (as
that's required for Java).


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


All three.  You can select between BFP and HFP with a compiler option
(so float/double/etc. are one or the other), DFP is supported as an
extension with its own set of types (_Decimal32/64/128).  There's also
support for fixed point decimal ("decimal(10,2) x;").

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

#66733

W dniu niedziela, 2 sierpnia 2015 21:32:39 UTC+2 użytkownik Malcolm McLean napisał:
> On Sunday, August 2, 2015 at 8:24:44 PM UTC+1, fir wrote:
> > 
> > 
> > if(x>180) x-=360;
> > if(x<-180) x+=360;
> > 
> > hope it will work
> >
> Not if, while. usually you wont' go more that 360 degrees out of range.
> But if you use while, you can just forget about wrapping - whatever
> cumulative additions you perform, the result will go back into the#rage you want.

thats what i did - this is becouse i cannot fully safe asume that input A angle to the routine is normalised 

otherwise it wouldnt be needed, but probably
this is not big waste anyway ... and anyway probably atan is killing slow. but it should suffice for sporadic use

 float NormAngle(float alfa)
 {
       while( alfa <  -180. )  alfa += 360.;
       while( alfa >=  180. )  alfa -= 360.;

       return alfa;
 }


  float DXDYToAngle(float dx, float dy)
 {
    if(dx==0 && dy ==0) return 0; //ERROR_("XY2Alfa alfa undefined");

    if(dx==0 && dy>0) return 90.0;
    if(dx==0 && dy<0) return -90.0;

    if(dy==0 && dx>0) return 0.0;
    if(dy==0 && dx<0) return 180.0;


    float angle = (180.0/M_PI)*atan(dy/dx);

    if(dy<0 && dx<0) angle +=180.0-360.0;
    if(dy>0 && dx<0) angle +=180.0;

    return angle;

 }

 float GiveAngleASeesB(float xa, float ya, float anglea, float xb, float yb)
 {

  float dx = xb - xa;
  float dy = yb - ya;

  float b_point_angle = XY2Alfa(dx, dy);

  return NormAngle( b_point_angle - anglea );


 }

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

#66734

W dniu niedziela, 2 sierpnia 2015 21:51:20 UTC+2 użytkownik fir napisał:
>     if(dx==0 && dy>0) return 90.0;
>     if(dx==0 && dy<0) return -90.0;
> 
>     if(dy==0 && dx>0) return 0.0;
>     if(dy==0 && dx<0) return 180.0;
> 
now im not sure if this above is needed at all probably no, but anyway. may think later on it ;C

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

#66735

On 02/08/2015 20:51, fir wrote:
> W dniu niedziela, 2 sierpnia 2015 21:32:39 UTC+2 użytkownik Malcolm McLean napisał:
>> On Sunday, August 2, 2015 at 8:24:44 PM UTC+1, fir wrote:
>>>
>>>
>>> if(x>180) x-=360;
>>> if(x<-180) x+=360;
>>>
>>> hope it will work
>>>
>> Not if, while. usually you wont' go more that 360 degrees out of range.
>> But if you use while, you can just forget about wrapping - whatever
>> cumulative additions you perform, the result will go back into the#rage you want.
>
> thats what i did - this is becouse i cannot fully safe asume that input A angle to the routine is normalised
>
> otherwise it wouldnt be needed, but probably
> this is not big waste anyway ... and anyway probably atan is killing slow. but it should suffice for sporadic use
>
>   float NormAngle(float alfa)
>   {
>         while( alfa <  -180. )  alfa += 360.;
>         while( alfa >=  180. )  alfa -= 360.;
>
>         return alfa;
>   }

I thought your use of degrees were just for illustration. I didn't 
realise you used degrees in the code too.

Normally radians are used for this stuff, with degrees for user input 
and output. Then your normalised angles would be within +/- pi.

-- 
Bartc

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

#66737

W dniu niedziela, 2 sierpnia 2015 21:58:02 UTC+2 użytkownik Bart napisał:
> On 02/08/2015 20:51, fir wrote:
> > W dniu niedziela, 2 sierpnia 2015 21:32:39 UTC+2 użytkownik Malcolm McLean napisał:
> >> On Sunday, August 2, 2015 at 8:24:44 PM UTC+1, fir wrote:
> >>>
> >>>
> >>> if(x>180) x-=360;
> >>> if(x<-180) x+=360;
> >>>
> >>> hope it will work
> >>>
> >> Not if, while. usually you wont' go more that 360 degrees out of range.
> >> But if you use while, you can just forget about wrapping - whatever
> >> cumulative additions you perform, the result will go back into the#rage you want.
> >
> > thats what i did - this is becouse i cannot fully safe asume that input A angle to the routine is normalised
> >
> > otherwise it wouldnt be needed, but probably
> > this is not big waste anyway ... and anyway probably atan is killing slow. but it should suffice for sporadic use
> >
> >   float NormAngle(float alfa)
> >   {
> >         while( alfa <  -180. )  alfa += 360.;
> >         while( alfa >=  180. )  alfa -= 360.;
> >
> >         return alfa;
> >   }
> 
> I thought your use of degrees were just for illustration. I didn't 
> realise you used degrees in the code too.
> 
> Normally radians are used for this stuff, with degrees for user input 
> and output. Then your normalised angles would be within +/- pi.
> 

-180 to 180 seem more handy for me than radians
(not used for mass processing only for few starships
in local vicinity) - I use it to check if it is worth for
both starship to open a fire forward (you know, 2d warship)

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

#66745

fir <profesor.fir@gmail.com> writes:
<snip>
>  float NormAngle(float alfa)
>  {
>        while( alfa <  -180. )  alfa += 360.;
>        while( alfa >=  180. )  alfa -= 360.;
>
>        return alfa;
>  }

Consider fmod.

>   float DXDYToAngle(float dx, float dy)
>  {
>     if(dx==0 && dy ==0) return 0; //ERROR_("XY2Alfa alfa undefined");
>
>     if(dx==0 && dy>0) return 90.0;
>     if(dx==0 && dy<0) return -90.0;
>
>     if(dy==0 && dx>0) return 0.0;
>     if(dy==0 && dx<0) return 180.0;
>
>
>     float angle = (180.0/M_PI)*atan(dy/dx);
>
>     if(dy<0 && dx<0) angle +=180.0-360.0;
>     if(dy>0 && dx<0) angle +=180.0;
>
>     return angle;

Consider atan2.

<snip>
-- 
Ben.

[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