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

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

Re: should c be a subset of c++?

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: should c be a subset of c++? "J. Clarke" <j.clarke.873638@gmail.com> - 2015-11-06 19:02 -0500
    Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-07 01:15 +0000
      Re: should c be a subset of c++? James Kuyper <jameskuyper@verizon.net> - 2015-11-06 20:51 -0500
        Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-07 03:07 +0000
          Re: should c be a subset of c++? James Kuyper <jameskuyper@verizon.net> - 2015-11-06 23:45 -0500
            Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-07 06:39 +0000
              Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 00:45 -0800
                Re: should c be a subset of c++? supercat@casperkitty.com - 2015-11-07 16:37 -0800
                  Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-07 16:45 -0800
                    Re: should c be a subset of c++? supercat@casperkitty.com - 2015-11-08 08:14 -0800
                      Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-08 09:42 -0800
                        Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-08 21:43 +0000
                          Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-08 13:53 -0800
                            Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-08 13:56 -0800
                            Re: should c be a subset of c++? supercat@casperkitty.com - 2015-11-08 14:27 -0800
                          Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-08 21:56 +0000
                            Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-11-08 23:05 +0100
                              Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-08 14:20 -0800
                                Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-11-09 10:10 +0100
                                  Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-11-13 14:25 -0800
                                    Re: should c be a subset of c++? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-13 17:32 -0500
                                      Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-11-13 15:38 -0800
                              Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:01 +0000
                                Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 17:15 +0000
                            Re: should c be a subset of c++? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-08 17:47 -0500
                          Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-11-08 23:04 +0100
                            Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 14:22 -0800
                              Re: should c be a subset of c++? supercat@casperkitty.com - 2015-11-08 14:31 -0800
                                Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 14:38 -0800
                                  Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-11-08 19:50 -0500
                                  Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 01:36 +0000
                                Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-11-09 12:33 +0100
                              Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:03 +0000
                          Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-11-08 19:24 -0500
                            Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 01:16 +0000
                              Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:06 +0000
                      Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-11-08 14:55 -0500
                        Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 12:03 -0800
                          Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-11-08 20:01 -0500
                            Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 02:31 -0800
                              Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-11-09 08:19 -0500
                                Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 08:47 -0800
                                  Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-09 22:45 +0000
                                    Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-11-09 14:56 -0800
                                    Re: should c be a subset of c++? supercat@casperkitty.com - 2015-11-09 15:24 -0800
                                    Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 15:56 -0800
                                  Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-11-09 21:54 -0500
                                    Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 19:07 -0800
                                      Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-11-10 08:37 -0500
                              Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:07 +0000
                        Re: should c be a subset of c++? supercat@casperkitty.com - 2015-11-08 12:35 -0800
                          Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 13:02 -0800
                      Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-08 21:40 +0000
                        Trig functions and radians supercat@casperkitty.com - 2015-11-08 13:54 -0800
                    Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-11-13 14:18 -0800
                      Re: should c be a subset of c++? supercat@casperkitty.com - 2015-11-13 14:55 -0800
                  Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-08 01:02 +0000
                  Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-11-07 20:39 -0500

Page 3 of 3 — ← Prev page 1 2 [3]

#75448

On 11/9/15 5:31 AM, Malcolm McLean wrote:
> On Monday, November 9, 2015 at 1:01:53 AM UTC, Richard Damon wrote:
>> On 11/8/15 3:03 PM, Malcolm McLean wrote:
>>
>> My general experience is that floating point (like you use with the
>> standard C sin/cos routines) is generally bad for most serious graphics
>> work. The big issue is that the varying level of precision based on the
>> magnitude of the number is the cause of just such instability. It is
>> normally better to switch to a fixed point notation to process with
>> enough fractional bits to control the affect of rounding errors.
>>
> I tried exactly that.
> The idea was that by using fixed point, you have either totally degenerate
> points (a == b) or non-degenerate points  fabs(a-b) >> FLT_EPSILON.
> It doesn't work. You get a worse mess because you don't know when to apply
> the snap to grid point.
>

That doesn't sound like using 'fixed point'. To use fixed point in C, 
you need to use integers, that you keep track of their scale factors in 
your program design. There isn't anything like FLT_EPSILON, as it 
doesn't exist at all in the model.

You don't need to make a test like this, as there are no value 'too 
close'. Note also, the resolution you store your model in will be 
coarser than the space you compute your transforms in order to avoid 
this sort of degeneration.

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

#75459

On Monday, November 9, 2015 at 1:20:08 PM UTC, Richard Damon wrote:
> On 11/9/15 5:31 AM, Malcolm McLean wrote:
> > On Monday, November 9, 2015 at 1:01:53 AM UTC, Richard Damon wrote:
> >> On 11/8/15 3:03 PM, Malcolm McLean wrote:
> >>
> >> My general experience is that floating point (like you use with the
> >> standard C sin/cos routines) is generally bad for most serious graphics
> >> work. The big issue is that the varying level of precision based on the
> >> magnitude of the number is the cause of just such instability. It is
> >> normally better to switch to a fixed point notation to process with
> >> enough fractional bits to control the affect of rounding errors.
> >>
> > I tried exactly that.
> > The idea was that by using fixed point, you have either totally degenerate
> > points (a == b) or non-degenerate points  fabs(a-b) >> FLT_EPSILON.
> > It doesn't work. You get a worse mess because you don't know when to apply
> > the snap to grid point.
> >
> 
> That doesn't sound like using 'fixed point'. To use fixed point in C, 
> you need to use integers, that you keep track of their scale factors in 
> your program design. There isn't anything like FLT_EPSILON, as it 
> doesn't exist at all in the model.
> 
> You don't need to make a test like this, as there are no value 'too 
> close'. Note also, the resolution you store your model in will be 
> coarser than the space you compute your transforms in order to avoid 
> this sort of degeneration.
>
The resolution we store the points in is fixed point, and we define the 
resolution so that if a == b, a - b == 0, if a != b, fabs(a-b) is very much
greater than FLT_EPSILON. The we do the transforms in IEEE double space.
Then they've got to go back to fixed point for storage.

It's exactly as you described, except we don't use a finer fixed point for
the transforms, we use floating point. 
However the system is hard to make work.

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

#75523

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> On Monday, November 9, 2015 at 1:20:08 PM UTC, Richard Damon wrote:
>> On 11/9/15 5:31 AM, Malcolm McLean wrote:
>> > On Monday, November 9, 2015 at 1:01:53 AM UTC, Richard Damon wrote:
>> >> On 11/8/15 3:03 PM, Malcolm McLean wrote:

>> >> My general experience is that floating point (like you use with the
>> >> standard C sin/cos routines) is generally bad for most serious graphics
>> >> work. The big issue is that the varying level of precision based on the
>> >> magnitude of the number is the cause of just such instability. It is
>> >> normally better to switch to a fixed point notation to process with
>> >> enough fractional bits to control the affect of rounding errors.

Yes.  It seems to me that the use of scaled fixed point arithmetic
is a lost art.  One reason is the poor support in high-level languages.

PL/I has direct support for both binary and decimal (scaled by powers
of two or ten) fixed point. 

While most computing hardware generates a double length product,
and allows a double length dividend for division, it is rare to allow
for these in high-level languages. If you have those, and appropriate
shift operations, you can manually do the operations needed for
scaled fixed point arithmetic.

>> > I tried exactly that.
>> > The idea was that by using fixed point, you have either 
>> > totally degenerate
>> > points (a == b) or non-degenerate points  fabs(a-b) >> FLT_EPSILON.
>> > It doesn't work. You get a worse mess because you don't 
>> > know when to apply the snap to grid point.
 
>> That doesn't sound like using 'fixed point'. To use fixed point in C, 
>> you need to use integers, that you keep track of their scale factors in 
>> your program design. There isn't anything like FLT_EPSILON, as it 
>> doesn't exist at all in the model.
 
(snip)

> The resolution we store the points in is fixed point, and we define the 
> resolution so that if a == b, a - b == 0, if a != b, fabs(a-b) is very much
> greater than FLT_EPSILON. The we do the transforms in IEEE double space.
> Then they've got to go back to fixed point for storage.

Comparing with FLT_EPSILON doesn't make sense unless you say how
large the fixed point values can get.  If the scaled fixed point
has the radix point just to the left of the most significant digit,
then it might be useful.
 
> It's exactly as you described, except we don't use a finer 
> fixed point for the transforms, we use floating point. 
> However the system is hard to make work.

A big advantage of scaled fixed point is that you can make sure
that all rounding is done in the appropriate way. 

In general, it is more appropriate for quantities with an absolute
uncertaity, where floating point is best for those with a 
relative uncertainty. 

-- glen

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

#75527

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> Yes.  It seems to me that the use of scaled fixed point arithmetic
> is a lost art.  One reason is the poor support in high-level languages.
>
> PL/I has direct support for both binary and decimal (scaled by powers
> of two or ten) fixed point. 

Take a look at Ada.

[...]

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

#75530

On Monday, November 9, 2015 at 4:46:12 PM UTC-6, glen herrmannsfeldt wrote:
> Yes.  It seems to me that the use of scaled fixed point arithmetic
> is a lost art.  One reason is the poor support in high-level languages.

I suspect the problem is that language designers seem have taken the view
that operator overloading eliminates the need for languages to include
internal support for arithmetic types other than integer and floating-point
primitives.  Working efficiently with fixed-point types, however, requires
that operators be evaluated in ways that don't fit very well with "normal"
inside-out operator-overload evaluation.  For example, if the result of a
division is stored into a fixed(24,8) variable, it needs to be evaluated
differently than if one was storing the result into a fixed(8,24), but there
is no practical mechanism via which that can happen in .NET.

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

#75535

On Monday, November 9, 2015 at 10:46:12 PM UTC, glen herrmannsfeldt wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> 
> > The resolution we store the points in is fixed point, and we define
> > the resolution so that if a == b, a - b == 0, if a != b, fabs(a-b) 
> > is very much greater than FLT_EPSILON. The we do the transforms in 
> > IEEE double space.
> > Then they've got to go back to fixed point for storage.
> 
> Comparing with FLT_EPSILON doesn't make sense unless you say how
> large the fixed point values can get.  If the scaled fixed point
> has the radix point just to the left of the most significant digit,
> then it might be useful.
>  
In practice overflow (points with values too large to represent)
isn't much of a problem, unless you are projecting a point,
e.g. intersecting two almost-parallel lines. The artwork is
constrained to lie within a thousand pixels or so of the origin.

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

#75551

On 11/9/15 11:47 AM, Malcolm McLean wrote:
> On Monday, November 9, 2015 at 1:20:08 PM UTC, Richard Damon wrote:
>> On 11/9/15 5:31 AM, Malcolm McLean wrote:
>>> On Monday, November 9, 2015 at 1:01:53 AM UTC, Richard Damon wrote:
>>>> On 11/8/15 3:03 PM, Malcolm McLean wrote:
>>>>
>>>> My general experience is that floating point (like you use with the
>>>> standard C sin/cos routines) is generally bad for most serious graphics
>>>> work. The big issue is that the varying level of precision based on the
>>>> magnitude of the number is the cause of just such instability. It is
>>>> normally better to switch to a fixed point notation to process with
>>>> enough fractional bits to control the affect of rounding errors.
>>>>
>>> I tried exactly that.
>>> The idea was that by using fixed point, you have either totally degenerate
>>> points (a == b) or non-degenerate points  fabs(a-b) >> FLT_EPSILON.
>>> It doesn't work. You get a worse mess because you don't know when to apply
>>> the snap to grid point.
>>>
>>
>> That doesn't sound like using 'fixed point'. To use fixed point in C,
>> you need to use integers, that you keep track of their scale factors in
>> your program design. There isn't anything like FLT_EPSILON, as it
>> doesn't exist at all in the model.
>>
>> You don't need to make a test like this, as there are no value 'too
>> close'. Note also, the resolution you store your model in will be
>> coarser than the space you compute your transforms in order to avoid
>> this sort of degeneration.
>>
> The resolution we store the points in is fixed point, and we define the
> resolution so that if a == b, a - b == 0, if a != b, fabs(a-b) is very much
> greater than FLT_EPSILON. The we do the transforms in IEEE double space.
> Then they've got to go back to fixed point for storage.
>
> It's exactly as you described, except we don't use a finer fixed point for
> the transforms, we use floating point.
> However the system is hard to make work.
>

You mentioned elsewhere a magnitude of about 1000 for a and b. Is you 
'very much greater than FLT_EPSILON' on the order of 100,000x ? Also, 
have you analyzed your floating point math to ensure it is 
computationally stable? The big danger with floating point is that it 
becomes complicated enough to confirm that the calculation is accurate 
enough, that it often isn't done and just assumed. One big advantage of 
fixed point is that you NEED to look at the significance at each stage, 
and thus many of the problems detected by analysis.

The symptoms you describe really sound like a typical loss of significance.

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

#75552

On Tuesday, November 10, 2015 at 2:54:36 AM UTC, Richard Damon wrote:
> On 11/9/15 11:47 AM, Malcolm McLean wrote:
> > On Monday, November 9, 2015 at 1:20:08 PM UTC, Richard Damon wrote:
> >> On 11/9/15 5:31 AM, Malcolm McLean wrote:
> >>> On Monday, November 9, 2015 at 1:01:53 AM UTC, Richard Damon wrote:
> >>>> On 11/8/15 3:03 PM, Malcolm McLean wrote:
> >>>>
> >>>> My general experience is that floating point (like you use with the
> >>>> standard C sin/cos routines) is generally bad for most serious graphics
> >>>> work. The big issue is that the varying level of precision based on the
> >>>> magnitude of the number is the cause of just such instability. It is
> >>>> normally better to switch to a fixed point notation to process with
> >>>> enough fractional bits to control the affect of rounding errors.
> >>>>
> >>> I tried exactly that.
> >>> The idea was that by using fixed point, you have either totally degenerate
> >>> points (a == b) or non-degenerate points  fabs(a-b) >> FLT_EPSILON.
> >>> It doesn't work. You get a worse mess because you don't know when to apply
> >>> the snap to grid point.
> >>>
> >>
> >> That doesn't sound like using 'fixed point'. To use fixed point in C,
> >> you need to use integers, that you keep track of their scale factors in
> >> your program design. There isn't anything like FLT_EPSILON, as it
> >> doesn't exist at all in the model.
> >>
> >> You don't need to make a test like this, as there are no value 'too
> >> close'. Note also, the resolution you store your model in will be
> >> coarser than the space you compute your transforms in order to avoid
> >> this sort of degeneration.
> >>
> > The resolution we store the points in is fixed point, and we define the
> > resolution so that if a == b, a - b == 0, if a != b, fabs(a-b) is very much
> > greater than FLT_EPSILON. The we do the transforms in IEEE double space.
> > Then they've got to go back to fixed point for storage.
> >
> > It's exactly as you described, except we don't use a finer fixed point for
> > the transforms, we use floating point.
> > However the system is hard to make work.
> >
> 
> You mentioned elsewhere a magnitude of about 1000 for a and b. Is you 
> 'very much greater than FLT_EPSILON' on the order of 100,000x ? Also, 
> have you analyzed your floating point math to ensure it is 
> computationally stable? The big danger with floating point is that it 
> becomes complicated enough to confirm that the calculation is accurate 
> enough, that it often isn't done and just assumed. One big advantage of 
> fixed point is that you NEED to look at the significance at each stage, 
> and thus many of the problems detected by analysis.
> 
> The symptoms you describe really sound like a typical loss of 
> significance.
>
That could well have been the problem.
The code was using doubles, but littered with FLT_EPSILONs to try to
get rid of numerical problems. I then tried storing the results
in fixed point. However I didn't do a thorough job on changing
everything such as root finders.
I realised it wasn't helping and it would take too long to rewrite
and re-test everything, so I reverted to double precision points
and patching up numerical problems as they appeared.
But it's extremely difficult to handle degenerate or near-
degenerate complex geometry. 

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

#75573

On 11/9/15 10:07 PM, Malcolm McLean wrote:
> On Tuesday, November 10, 2015 at 2:54:36 AM UTC, Richard Damon wrote:
>> On 11/9/15 11:47 AM, Malcolm McLean wrote:
>>> On Monday, November 9, 2015 at 1:20:08 PM UTC, Richard Damon wrote:
>>>> On 11/9/15 5:31 AM, Malcolm McLean wrote:
>>>>> On Monday, November 9, 2015 at 1:01:53 AM UTC, Richard Damon wrote:
>>>>>> On 11/8/15 3:03 PM, Malcolm McLean wrote:
>>>>>>
>>>>>> My general experience is that floating point (like you use with the
>>>>>> standard C sin/cos routines) is generally bad for most serious graphics
>>>>>> work. The big issue is that the varying level of precision based on the
>>>>>> magnitude of the number is the cause of just such instability. It is
>>>>>> normally better to switch to a fixed point notation to process with
>>>>>> enough fractional bits to control the affect of rounding errors.
>>>>>>
>>>>> I tried exactly that.
>>>>> The idea was that by using fixed point, you have either totally degenerate
>>>>> points (a == b) or non-degenerate points  fabs(a-b) >> FLT_EPSILON.
>>>>> It doesn't work. You get a worse mess because you don't know when to apply
>>>>> the snap to grid point.
>>>>>
>>>>
>>>> That doesn't sound like using 'fixed point'. To use fixed point in C,
>>>> you need to use integers, that you keep track of their scale factors in
>>>> your program design. There isn't anything like FLT_EPSILON, as it
>>>> doesn't exist at all in the model.
>>>>
>>>> You don't need to make a test like this, as there are no value 'too
>>>> close'. Note also, the resolution you store your model in will be
>>>> coarser than the space you compute your transforms in order to avoid
>>>> this sort of degeneration.
>>>>
>>> The resolution we store the points in is fixed point, and we define the
>>> resolution so that if a == b, a - b == 0, if a != b, fabs(a-b) is very much
>>> greater than FLT_EPSILON. The we do the transforms in IEEE double space.
>>> Then they've got to go back to fixed point for storage.
>>>
>>> It's exactly as you described, except we don't use a finer fixed point for
>>> the transforms, we use floating point.
>>> However the system is hard to make work.
>>>
>>
>> You mentioned elsewhere a magnitude of about 1000 for a and b. Is you
>> 'very much greater than FLT_EPSILON' on the order of 100,000x ? Also,
>> have you analyzed your floating point math to ensure it is
>> computationally stable? The big danger with floating point is that it
>> becomes complicated enough to confirm that the calculation is accurate
>> enough, that it often isn't done and just assumed. One big advantage of
>> fixed point is that you NEED to look at the significance at each stage,
>> and thus many of the problems detected by analysis.
>>
>> The symptoms you describe really sound like a typical loss of
>> significance.
>>
> That could well have been the problem.
> The code was using doubles, but littered with FLT_EPSILONs to try to
> get rid of numerical problems. I then tried storing the results
> in fixed point. However I didn't do a thorough job on changing
> everything such as root finders.
> I realised it wasn't helping and it would take too long to rewrite
> and re-test everything, so I reverted to double precision points
> and patching up numerical problems as they appeared.
> But it's extremely difficult to handle degenerate or near-
> degenerate complex geometry.
>
FLT_EPSILON can be a dangerous tool. The problem is that you really need 
to scale by the magnitude of your numbers, and then again by how much 
reserve precision you need, which is a hard value to compute. The fact 
that it is there, can give you a false sense of security, thinking it 
does more than what it really does.

One often overlooked problem with geometric transforms (especially 
rotations) is that these can generate significance an order of magnitude 
(or more) below the base value of your numbers, and if you do 2-norms, 
you normally have an intermediary that can need twice the precision of 
your base numbers.

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

#75623

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> On Monday, November 9, 2015 at 1:01:53 AM UTC, Richard Damon wrote:

> > My general experience is that floating point (like you use with the 
> > standard C sin/cos routines) is generally bad for most serious graphics 
> > work. The big issue is that the varying level of precision based on the 
> > magnitude of the number is the cause of just such instability. It is 
> > normally better to switch to a fixed point notation to process with 
> > enough fractional bits to control the affect of rounding errors.
> >
> I tried exactly that.
> The idea was that by using fixed point, you have either totally degenerate
> points (a == b) or non-degenerate points  fabs(a-b) >> FLT_EPSILON.
> It doesn't work. You get a worse mess because you don't know when to apply
> the snap to grid point.

Only at the final stage. Obviously.

Richard

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

#75366

On Sunday, November 8, 2015 at 1:56:07 PM UTC-6, Richard Damon wrote:
> The key aspect is that MATHEMATICS uses radians. It is a practical 
> certainty, that whenever you see sin(x) or cos(x) in a formula, and x 
> isn't directly a physical angle, x will be assumed to be expressed in 
> radians and not any other unit of measure. (if x is a physical angle, 
> then it becomes clear that you need to use the version of sin/cos that 
> takes an argument of the same type as you measure the angle with).

There are many situations in mathematics where one ends with a factor of 2pi
in the arguments to trig functions.  For example, if one wants to perform
Foorier analysis on a function with a unit period, all of the sine and cosine
functions will have a multiple of 2pi in their argument, so it's inefficient
to require user code to multiply by 2*pi and immediately have a sine/cosine
routine multiply by 1/pi.

Incidentally, I find it curious that there isn't any standard function to
compute 1-cos(x) given that in many cases the output of a function could
have much more useful precision than cos(x) [when x is near zero, the
derivative of cos(x) is at its smallest, but the space between consecutive
output values is at its largest; by contrast, 1-cos(x) would have the
tightest spacing between output values in those cases where the input is
most precisely specifiable.

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

#75372

On Sunday, November 8, 2015 at 8:35:47 PM UTC, supe...@casperkitty.com wrote:
>  
> Incidentally, I find it curious that there isn't any standard function to
> compute 1-cos(x) given that in many cases the output of a function could
> have much more useful precision than cos(x) [when x is near zero, the
> derivative of cos(x) is at its smallest, but the space between consecutive
> output values is at its largest; by contrast, 1-cos(x) would have the
> tightest spacing between output values in those cases where the input is
> most precisely specifiable.
>
Because if 53 bits of precision in a cosine isn't enough for you, you
need to rewrite the routine totally from scratch, very carefully 
considering the numerical issues. Patching the cosine call will 
seldom be the fix.

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

#75378

supercat@casperkitty.com wrote:

(snip)

> FORTRAN used radians, but I doubt the earliest processors had any hardware
> support.  All approaches to computing trig functions that I know about
> require starting with an argument-normalization phase which identifies the
> angle as being in one of eight octants.  If angles were specified in some
> power-of-two fractions of a circle, such rediction could take place with
> perfect precision; even if the routine to compute an angle within an octant
> needed a value in radians, having a trig function accept a number of circles,
> do the reduction, and then multiply by pi would in most cases be faster and
> more accurate than starting out with a number of radians.

PL/I has both radians and degree functions as far back as it goes.

Yes, the ones I know of go through octants. 
 
> Although there are a few cases where radians are helpful, they are really
> quite few and far between.  Even if e.g. one is running a simulator with
> 1us time steps and needs to simulate a process which runs at 1/2pi Hz,
> which would seem like a perfect time to use radians, they don't really
> work out to be any better than working with whole circles would be (since
> the value 1/1000000 can't be represented any more accurately than
> 1/2000000pi).
 
> Further, as noted, while having radian-based functions is useful, they make
> zero sense in the context of things like graphic rotation (which frequently
> need to be precisely-representable numbers of degrees, and almost never need
> to be precisely-representable numbers of radians).

It is worse than that.  The Postscript operators are in degrees, but
they still get it wrong. Well, maybe it has changed by now, but some
years ago when I was working on a big postscript project, I was
talking with someone who worked more directly with publishing from
postscript input, and the rotations are still wrong. It seems likely
that they convert degrees to radians, then get the wrong values
for a 90 or 180 degree rotation. 

-- glen

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

#75382 — Trig functions and radians

On Sunday, November 8, 2015 at 3:41:05 PM UTC-6, glen herrmannsfeldt wrote:
> It is worse than that.  The Postscript operators are in degrees, but
> they still get it wrong. Well, maybe it has changed by now, but some
> years ago when I was working on a big postscript project, I was
> talking with someone who worked more directly with publishing from
> postscript input, and the rotations are still wrong. It seems likely
> that they convert degrees to radians, then get the wrong values
> for a 90 or 180 degree rotation. 

And here I'd thought the silliness in some of HTML5's graphics methods was
inherited from PostScript [since that's where the basic drawing model,
including its broken miter behavior, seems to have come from].  Well, maybe
some of the silliness comes from PostScript, but it's curious that HTML5
would use radians if PostScript used degrees.  I wonder if there's any
reason PostScript didn't do argument reduction to +/- 45 degrees before
performing trig functions for rotation, since many hardware trig functions
are optimized for angles in the range 0..pi/4, and could be eliminated
altogether for the most common angles (e.g. multiples of 90 degrees).

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

#75979

One radian is the angle subtended at the center of a circle by an arc
that is equal in length to the radius of the circle. More generally,
the magnitude in radians of such a subtended angle is equal to the
ratio of the arc length to the radius of the circle; that is, theta =
s/r, where theta is the subtended angle in radians, s is arc length,
and r is radius. 

There are 2pi radians in a circle but everyone knows this is an
unfortunate accident of history since the proper circle constant is
Tau and there are Tau radians in a circle. :)

Radians were preferred in mathematics because they are unitless,
integral ratios and the trigonometric functions are easier to express
symbolically. (180 deg. = pi radians, 90 deg. is pi/2 radians, etc.)
So an angle is easily expressed as unit ratios of pi. Interior angles
of a right triangle are pi/2, pi/3 and pi/6, for example.

Using Tau, 180 deg. = 1/2 Tau radian, 90 deg. is Tau/4, a much better
concept to picture mentally. Interior angles of a right triangle are
Tau/4, Tau/6, Tau/12, summing to Tau/2, 180 degrees...

Physics, dependent on mathematics, is stuck with radians. FORTRAN,
being a computational language for describing physical processes kept
the tradition. Designers of the hardware followed along for their own
reasons. sin(pi/2) = 1

Angular velocity is expressed as radians per second or radian per unit
time and the choice of time units is important when dealing with
rotating machines (rpm (Tau per minute anyone?) or rad/s) or orbital
mechanics (rad/hour) or (rad/min).

Conversion to arbitrary non-rational units like degrees or grads or
Gradians (1/400 Tau) or any other divisions of a circle.

The angular mil is another arbitrary unit that subtends a distance of
1 meter at a range of 1000 meters. (1/6400 of a circle)

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

#75986

On Friday, November 13, 2015 at 4:18:40 PM UTC-6, Geoff wrote:
> Physics, dependent on mathematics, is stuck with radians. FORTRAN,
> being a computational language for describing physical processes kept
> the tradition. Designers of the hardware followed along for their own
> reasons. sin(pi/2) = 1

And to a computer using 64-bit double, the sine of pi equals the sine of
884279719003555.0/281474976710656.0, which is to say roughly 1.224646799e-16;
note that some inferior implementations compute the sine of pi as being only
1.22460635382e-16, but Java takes extra time to compute the sine accurately
though I'm curious in how many situations a function which computes the sine
of x precisely would be more useful than one which computes the sine of
1.0000000000000000389817183251938x?

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

#75326

supercat@casperkitty.com wrote:
> On Saturday, November 7, 2015 at 2:46:02 AM UTC-6, Malcolm McLean wrote:
>> Try passing through a value of 30 degrees plus two pi through the
>> sine function (available in Basic Algorithms if you don't have
>> one) and see what happens.
 
> It's not possible to specify such an angle precisely, so I'm not 
> clear what you'd be looking to prove.
 
> I do find it odd that almost every language includes trig 
> functions in radians but very few include trig functions in 
> some other unit (I'd be inclined to use multiples of whole circles 
> myself, though degrees would also be good), even though there 
> are very few cases where an angle will be known to be a precise 
> representable number of radians, but many cases where it will 
> be known to be a precisely-representable number of circles and 
> even more where it will be known to be a precise number of degrees.  

Radians are natural in the same way that e is natural for logs,
but most languages also include log10(). 

> Even the functions to rotate graphic transforms in PostScript and 
> JavaScript use radians, which seems downright bizarre, since there 
> are many cases where one might want to rotate a transform by 
> precisely 90 degrees, but I can't think of any where one would 
> want to rotate by a precisely-representable number of radians.

Yes, you can't make an exact 90 or 180 rotation in postscript,
from roundoff in the sine and cosine.

-- glen

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

#75330

On 11/7/15 7:37 PM, supercat@casperkitty.com wrote:
  I do find it odd that almost every language includes trig functions in 
radians
> but very few include trig functions in some other unit (I'd be inclined to use
> multiples of whole circles myself, though degrees would also be good), even
> though there are very few cases where an angle will be known to be a precise
> representable number of radians, but many cases where it will be known to be a
> precisely-representable number of circles and even more where it will be known
> to be a precise number of degrees.  Even the functions to rotate graphic
> transforms in PostScript and JavaScript use radians, which seems downright
> bizarre, since there are many cases where one might want to rotate a transform
> by precisely 90 degrees, but I can't think of any where one would want to
> rotate by a precisely-representable number of radians.
>

The likely source is that mathematicians found that when angles were 
represented in radians for using the trig functions, a lot of things 
became simpler. For instance the derivative of the sine function is the 
cosine function, but if you use any other angle measure, that scale 
factor pops up.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web