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 1 of 3  [1] 2 3  Next page →

#75198 — Re: should c be a subset of c++?

In article <87egibhe03.fsf@bsb.me.uk>, ben.usenet@bsb.me.uk says...
> 
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Saturday, September 5, 2015 at 4:12:29 PM UTC-4, Ben Bacarisse wrote:
> >> raltbos@xs4all.nl (Richard Bos) writes:
> >> 
> >> > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> >> >
> >> >> On Saturday, September 5, 2015 at 1:10:44 PM UTC+1, Ben Bacarisse wrote:
> >> >> > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> >> > 
> >> >> > Yet you *still* don't refute that numerical calculations involving pi
> >> >> > can be done without approximating pi. 
> >> >> >
> >> >> Only if eventually PI cancels out somehow.
> >> >> Just as you can calculate with imaginary numbers, but you can can only
> >> >> actually cope with i^2. i is fine for intermediates, but the start
> >> >> point has to be real numbers, as does the end point, if the 
> >> >> calculation is going to be applied.
> >> >
> >> > Erm, no.
> >> >
> >> > The start and end point have to be _decimals_. The world is finite and
> >> > discrete. You'll get nowhere with a real number, unless you have a
> >> > terminated approximation.
> >> 
> >> I think the word "real" is being thrown around as an enforcer and not in
> >> it's technical sense which is a shame, since it's technical sense is
> >> relevant.  Here, "real" numbers are the ones Malcolm and Rick use, not
> >> those fancy, airy-fairy ones I use.  They live in the "real" world,
> >> dealing with "real" numbers in "real" ways.
> >
> > Real numbers are things like 3.1415...
> 
> You are correct, but, I suspect, by accident.  pi is a real number and
> another way write pi is 3.1415...  The ... means that that there is no
> finite decimal representation but, recognising the first few digits, the
> reader is supposed to know the number being written.  It is correct
> therefore to write pi = 3.1415... but, for example, pi = 3.1415 is not
> correct.
> 
> Anyway, the point is that I don't think you (or Malcolm) mean real
> numbers when you talk about real numbers.
> 
> > They are not their conceptual
> > representations of those real-world values, such as pi.  In order to
> > use pi in the real world, as applied to something physical, it has to
> > be translated from the concept of pi in a formula, which has an unending
> > sequence of decimals, and approximated to a numerical value that is
> > terminating at whatever resolution is required or possible.
> 
> And yet there are calculations involving pi, ones that produce numerical
> results that an engineer can use, that don't need pi to be approximated.

Could you given an example of such a calculation that does not cancel pi 
in some manner?

> If you'd agree with that simple fact, I would not feel I have to keep
> pointing it out.  You can borrow Malcolm's phrase and say "ah, but only
> when pi cancels out" if that makes you feel better about it.

People would be more inclined to "agree with that simple fact" if you 
supported it with evidence.

[toc] | [next] | [standalone]

#75204

"J. Clarke" <j.clarke.873638@gmail.com> writes:

> In article <87egibhe03.fsf@bsb.me.uk>, ben.usenet@bsb.me.uk says...
>> 
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>
>> > They are not their conceptual
>> > representations of those real-world values, such as pi.  In order to
>> > use pi in the real world, as applied to something physical, it has to
>> > be translated from the concept of pi in a formula, which has an unending
>> > sequence of decimals, and approximated to a numerical value that is
>> > terminating at whatever resolution is required or possible.
>> 
>> And yet there are calculations involving pi, ones that produce numerical
>> results that an engineer can use, that don't need pi to be approximated.
>
> Could you given an example of such a calculation that does not cancel pi 
> in some manner?

I'm not sure I know what you mean by cancel but I suspect the answer is
no, I can't.  All I can do (and I could swear I did in the original
thread) is support what I said.  I recall an example of an integral with
an exact answer.  That is an example of what I mean, even though it's
probably not an example of what you want.

>> If you'd agree with that simple fact, I would not feel I have to keep
>> pointing it out.  You can borrow Malcolm's phrase and say "ah, but only
>> when pi cancels out" if that makes you feel better about it.
>
> People would be more inclined to "agree with that simple fact" if you 
> supported it with evidence.

I did, didn't I?  The simple fact is evidenced by many symbolic
calculations done in systems like Mathematica.  Engineers and scientists
use these programs even though they may get exact results when they
(being engaged with the physical world) don't actually need exact
results.

-- 
Ben.

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

#75206

On 11/06/2015 08:15 PM, Ben Bacarisse wrote:
> "J. Clarke" <j.clarke.873638@gmail.com> writes:
> 
>> In article <87egibhe03.fsf@bsb.me.uk>, ben.usenet@bsb.me.uk says...
>>>
>>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> <snip>
>>>> They are not their conceptual
>>>> representations of those real-world values, such as pi.  In order to
>>>> use pi in the real world, as applied to something physical, it has to
>>>> be translated from the concept of pi in a formula, which has an unending
>>>> sequence of decimals, and approximated to a numerical value that is
>>>> terminating at whatever resolution is required or possible.
>>>
>>> And yet there are calculations involving pi, ones that produce numerical
>>> results that an engineer can use, that don't need pi to be approximated.
>>
>> Could you given an example of such a calculation that does not cancel pi 
>> in some manner?
> 
> I'm not sure I know what you mean by cancel but I suspect the answer is
> no, I can't.  All I can do (and I could swear I did in the original
> thread) is support what I said.  I recall an example of an integral with
> an exact answer.  That is an example of what I mean, even though it's
> probably not an example of what you want.

By "cancel", he means that the fact that the number can be calculated
without relying upon the value of pi is because the calculation
involves, for instance, multiplying by pi during one step, and then
later dividing by it. By rearranging the calculations, 'pi' drops out,
rendering it's numerical value irrelevant. Such a calculation does not
meaningfully involve pi, though it can be organized in a way that it
appears to. I don't really see how a calculation that meaningfully
involves pi can be reduced to an actual numerical value without using an
approximation to pi.

I want to be clear about the fact that I am not in any way endorsing
Rick Hodgin's mathematical nonsense - I'm just curious about a claim
made about the necessity (or lack thereof) of approximating pi.

>>> pointing it out.  You can borrow Malcolm's phrase and say "ah, but only
>>> when pi cancels out" if that makes you feel better about it.
>>
>> People would be more inclined to "agree with that simple fact" if you 
>> supported it with evidence.
> 
> I did, didn't I?

I used Google Groups to review previous messages in this thread. I
didn't notice any specific examples of such a calculation. I might not
have looked in the right place. Could you repeat the example, or at
least provide a link to it?

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

#75208

James Kuyper <jameskuyper@verizon.net> writes:

> On 11/06/2015 08:15 PM, Ben Bacarisse wrote:
>> "J. Clarke" <j.clarke.873638@gmail.com> writes:
>> 
>>> In article <87egibhe03.fsf@bsb.me.uk>, ben.usenet@bsb.me.uk says...
>>>>
>>>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> <snip>
>>>>> They are not their conceptual
>>>>> representations of those real-world values, such as pi.  In order to
>>>>> use pi in the real world, as applied to something physical, it has to
>>>>> be translated from the concept of pi in a formula, which has an unending
>>>>> sequence of decimals, and approximated to a numerical value that is
>>>>> terminating at whatever resolution is required or possible.
>>>>
>>>> And yet there are calculations involving pi, ones that produce numerical
>>>> results that an engineer can use, that don't need pi to be approximated.
>>>
>>> Could you given an example of such a calculation that does not cancel pi 
>>> in some manner?
>> 
>> I'm not sure I know what you mean by cancel but I suspect the answer is
>> no, I can't.  All I can do (and I could swear I did in the original
>> thread) is support what I said.  I recall an example of an integral with
>> an exact answer.  That is an example of what I mean, even though it's
>> probably not an example of what you want.
>
> By "cancel", he means that the fact that the number can be calculated
> without relying upon the value of pi is because the calculation
> involves, for instance, multiplying by pi during one step, and then
> later dividing by it.

Yes, that must be one of the meanings.  I was not in doubt about that
simple example.  I'd prefer a definition because without one how can I
possibly answer?  I suspect the other ways that something can be said to
"cancel out" will simply cover (by definition) every case where the
result is an exact rational.

But I never made any claim about cancelling or not cancelling.  I said
that computations involving pi can be made that don't use an
approximation of pi.

> By rearranging the calculations, 'pi' drops out,
> rendering it's numerical value irrelevant. Such a calculation does not
> meaningfully involve pi, though it can be organized in a way that it
> appears to. I don't really see how a calculation that meaningfully
> involves pi can be reduced to an actual numerical value without using an
> approximation to pi.

I don't know what you mean by meaningful.  I suspect that any example I
give could be deemed not to use pi in a meaningful way.  It feels like a
"no true Scotsman trap".

> I want to be clear about the fact that I am not in any way endorsing
> Rick Hodgin's mathematical nonsense - I'm just curious about a claim
> made about the necessity (or lack thereof) of approximating pi.
>
>>>> pointing it out.  You can borrow Malcolm's phrase and say "ah, but only
>>>> when pi cancels out" if that makes you feel better about it.
>>>
>>> People would be more inclined to "agree with that simple fact" if you 
>>> supported it with evidence.
>> 
>> I did, didn't I?
>
> I used Google Groups to review previous messages in this thread. I
> didn't notice any specific examples of such a calculation. I might not
> have looked in the right place. Could you repeat the example, or at
> least provide a link to it?

I gave two in various places.  One was the integral of sin(x) from 0 to
pi.  Symbolic maths packages will give the answer 2 exactly without
using any approximation.  I also gave the example of computing e^(pi.i)
to get -1 but that was in a side subthread about what constitutes a
"computation".

-- 
Ben.

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

#75214

On 11/06/2015 10:07 PM, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
...
>> appears to. I don't really see how a calculation that meaningfully
>> involves pi can be reduced to an actual numerical value without using an
>> approximation to pi.
> 
> I don't know what you mean by meaningful. ...

I think that perhaps the reason the conclusion seems so obvious to me is
that it's not actually a conclusion - rather, it should be considered an
implicit definition for the term "meaningful", at least in this context:
If you can calculate any other numerical value without making any use of
an approximation to the numerical value of pi, then that other value
doesn't meaningfully depend upon the value of pi. However, I can
understand if you don't appreciate this approach to the issue.

...
>> I used Google Groups to review previous messages in this thread. I
>> didn't notice any specific examples of such a calculation. I might not
>> have looked in the right place. Could you repeat the example, or at
>> least provide a link to it?
> 
> I gave two in various places.  One was the integral of sin(x) from 0 to
> pi.  Symbolic maths packages will give the answer 2 exactly without
> using any approximation.  I also gave the example of computing e^(pi.i)
> to get -1 but that was in a side subthread about what constitutes a
> "computation".

OK - I didn't notice either of those examples during my review. I
consider those calculations to be in basically the same category as
cos(pi): the value does not depend upon the actual value of pi, but only
upon the relationship between the way the cos() function is defined and
pi. So it is indeed what you would consider a "no true Scotsman" situation.
-- 
James Kuyper

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

#75216

James Kuyper <jameskuyper@verizon.net> wrote:

(snip)

> OK - I didn't notice either of those examples during my review. I
> consider those calculations to be in basically the same category as
> cos(pi): the value does not depend upon the actual value of pi, but only
> upon the relationship between the way the cos() function is defined and
> pi. So it is indeed what you would consider a "no true Scotsman" situation.

To get closer to C, some languages have trigonometric functions
in degrees.  Without them, if you want to compute, say, sin(30 degrees)
you multiply the angle by pi/180, which depends on the approximation
of pi that you have.

The first thing the sin() function does is argument reduction, 
which includes dividing by some multiple of pi.

If your approximation is different, you don't get exactly sin(30).

It seems that many are against trig. degree functions for some
fundamental reason, unrelated to how useful they might be.

-- glen

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

#75230

On Saturday, November 7, 2015 at 6:40:16 AM UTC, glen herrmannsfeldt wrote:
> 
> To get closer to C, some languages have trigonometric functions
> in degrees.  Without them, if you want to compute, say, sin(30 degrees)
> you multiply the angle by pi/180, which depends on the approximation
> of pi that you have.
> 
> The first thing the sin() function does is argument reduction, 
> which includes dividing by some multiple of pi.
> 
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.

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

#75320

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

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

#75323

On Saturday, November 7, 2015 at 7:37:35 PM UTC-5, supe...@casperkitty.com
> 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.

It relates to the underlying architecture.  Most hardware floating point
units operate in radians.

    http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html

    Direct link:
    http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf

Look to page 209:

    "The source operands for the FSIN, FCOS, FSINCOS, and FPTAN
     instructions must be given in radians;"

Best regards,
Rick C. Hodgin

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

#75343

On Saturday, November 7, 2015 at 6:45:52 PM UTC-6, Rick C. Hodgin wrote:
> It relates to the underlying architecture.  Most hardware floating point
> units operate in radians.
> 
>     http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html

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.

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

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

#75345

On Sunday, November 8, 2015 at 11:14:23 AM UTC-5, supe...@casperkitty.com wrote:
> On Saturday, November 7, 2015 at 6:45:52 PM UTC-6, Rick C. Hodgin wrote:
> > It relates to the underlying architecture.  Most hardware floating point
> > units operate in radians.
> > 
> >     http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
> 
> FORTRAN used radians, but I doubt the earliest processors had any hardware
> support.

I would imagine the implementations later employed in hardware had
their roots in software algorithms which were optimized for the same
reason ... there was something inherent in using radians which made
them the choice ... both in software algorithms, and in hardware
implementations.  Just a guess though.

Best regards,
Rick C. Hodgin

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

#75379

Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:

(snip)

> I would imagine the implementations later employed in hardware had
> their roots in software algorithms which were optimized for the same
> reason ... there was something inherent in using radians which made
> them the choice ... both in software algorithms, and in hardware
> implementations.  Just a guess though.

No, it is only theoretical mathematics that likes radians.
In hardware or software binary fractions of a circle are best.

You can get ROM sine/cosine look-up tables, always in binary fractions
of a circle, and never in radians.

-- glen

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

#75381

On Sunday, November 8, 2015 at 4:43:20 PM UTC-5, glen herrmannsfeldt wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> 
> (snip)
> 
> > I would imagine the implementations later employed in hardware had
> > their roots in software algorithms which were optimized for the same
> > reason ... there was something inherent in using radians which made
> > them the choice ... both in software algorithms, and in hardware
> > implementations.  Just a guess though.
> 
> No, it is only theoretical mathematics that likes radians.
> In hardware or software binary fractions of a circle are best.

I find it difficult to accept that the hardware designers out there
are writing things for radians when something else is more desirable
in hardware.  It's easy to change software.  It's not easy to change
hardware.  If there was a system which used bittians or some other
form than radians more easily, which meant faster throughput, and a
better product, etc.

> You can get ROM sine/cosine look-up tables, always in binary fractions
> of a circle, and never in radians.

That doesn't make any sense to me.  All a radian is is 2pi * a binary
fraction.  So instead of using 0..1, the lookups would be 0.2pi with
a greater value separation per test.

I have a plan to create an built-in FPU with SIMD support for my LibSF
386-x40 CPU.  I plan on investigating this.  And I'm actually very
excited about an alternative I've just discovered, called UNUM, which,
according to the author, fixes the issues of rounding seen in IEEE 754
implementations.

It's something I'd like to become an expert in after I get RDC and CAlive
completed, Visual FreePro, Jr. out there, and also Visual FreePro (full
version) completed.  If I can get those done, I'll be moving then to my
OS, but before I do that I'll spend a couple months investigating my
Logician software, and seeing what I can come up with for a real CPU
design (regardless of how low performing it is).  I've also learned that
in 2015, a set of 250nm masks cost about $10K, which means a real CPU
built on 250nm processes would cost $10K for masks, and then the cost of
a run on a fully depreciated fab, and a fully debugged process... cheap!

:-)

Best regards,
Rick C. Hodgin

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

#75384

On Sunday, November 8, 2015 at 4:53:58 PM UTC-5, Rick C. Hodgin wrote:
> On Sunday, November 8, 2015 at 4:43:20 PM UTC-5, glen herrmannsfeldt wrote:
> > > I would imagine the implementations later employed in hardware had
> > > their roots in software algorithms which were optimized for the same
> > > reason ... there was something inherent in using radians which made
> > > them the choice ... both in software algorithms, and in hardware
> > > implementations.  Just a guess though.
> > 
> > No, it is only theoretical mathematics that likes radians.
> > In hardware or software binary fractions of a circle are best.
> 
> I find it difficult to accept that the hardware designers out there
> are writing things for radians when something else is more desirable
> in hardware.  It's easy to change software.  It's not easy to change
> hardware.  If there was a system which used bittians or some other
> form than radians more easily, which meant faster throughput, and a
> better product, etc.

I didn't finish my thought!  LOL! :-)

If there was a system which used bittians (or some other form other
than radians) more easily, which meant faster throughput, easier
implementations, better scaling, etc., and an overall better product,
they would've switched to it, or added it as a new FPU engine to
replace the x87 and other hardware and ISA implementations which are
geared toward radians.

Best regards,
Rick C. Hodgin

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

#75392

On Sunday, November 8, 2015 at 3:53:58 PM UTC-6, Rick C. Hodgin wrote:
> On Sunday, November 8, 2015 at 4:43:20 PM UTC-5, glen herrmannsfeldt wrote:
> > No, it is only theoretical mathematics that likes radians.
> > In hardware or software binary fractions of a circle are best.
> 
> I find it difficult to accept that the hardware designers out there
> are writing things for radians when something else is more desirable
> in hardware.  It's easy to change software.  It's not easy to change
> hardware.  If there was a system which used bittians or some other
> form than radians more easily, which meant faster throughput, and a
> better product, etc.

I don't know the history of hardware trig functions, but I suspect that a
lot of things are a result of historical inertia more than anything else.
Sinclair's first scientific calculator calculated trig functions in units
of 0.001 radian and handled degrees by simply printing a conversion factor
on the front of the case, but it should be noted that the firmware for the
entire calculator had to fit in 320 instructions(!), and would take the
sine of e.g. 1.234 radians by iterating a 0.001-radian rotation step 1,234
times--not exactly a good approach for quick calculations.  

> > You can get ROM sine/cosine look-up tables, always in binary fractions
> > of a circle, and never in radians.
> 
> That doesn't make any sense to me.  All a radian is is 2pi * a binary
> fraction.  So instead of using 0..1, the lookups would be 0.2pi with
> a greater value separation per test.

The first step of taking the sine or cosine of an arbitrary angle is argument
reduction.  If one has a function that can compute sines and cosines for
angles within a small range, it's possible to extend this to a larger range
either by using coefficients loaded from a table or by using various trig
identities (e.g. it's possible to compute the sine and cosine of (x+y) if one
knows the sine and cosine of x and y individually; in many cases, x will be a
small angle and y will be an angle from a table.  If angles are in power-of-2
units, then one only needs one octant worth of coefficients and can use
symmetry for the rest.  If angles are in radians, however, symmetry won't
hold.  Further, if one wants to "correctly" report that the sine of the
floating-point value closest to pi accurate to 53 bits, one will need to
perform argument reduction with much greater than 53 bits of precision.

> I have a plan to create an built-in FPU with SIMD support for my LibSF
> 386-x40 CPU.  I plan on investigating this.  And I'm actually very
> excited about an alternative I've just discovered, called UNUM, which,
> according to the author, fixes the issues of rounding seen in IEEE 754
> implementations.

There are some things I like about IEEE-754, but some I don't.  IMHO, a
good floating-point standard should distinguish between computations where
determinism is more important than overall precision or speed, and those
where a result that's accurate to within 9/16ulp would be just as usable as
one which was accurate to within 1/2ulp.  Computing the product of two
double-precision floating-point values requires that one compute all 52x52
partial products, even though almost half of them could be omitted if
rounding to within 9/16ulp was acceptable.

Also, I'd like to see a floating-point implementation offer a set of
"ranking" comparison operators (I think IEEE-754 added a set in 2009 though
I've never heard of any language supporting them) and four zeroes with the
following semantics: Identity Zero, Positive Tiny, Negative Tiny, and
Unsigned Tiny.

1. Adding or subtracting identity zero from anything yields the same thing,
   and multiplying anything other than NaN by IZ yields IZ.  Dividing IZ
   by anything other than NaN or IZ yields IZ.  IZ/IZ yields NaN.

2. Adding or subtracting any value from itself yields UT.  Multiplications
   or divisions that would underflow yield PT or NT.  Adding PT to NT or UT,
   or adding NT to PT or UT, yields UT.

3. Division of a finite value by PT or NT yields positive or negative
   infinity, as appropriate.  Division by UT yields NaN, as does division of
   PT, UT, or NT by PT, UT, or NT.

I don't think a four-zero system would be much harder to implement than a
two-zero system, but it has the following advantages versus IEEE-754:

1. It is symmetric, unlike IEEE-754 which biases zeroes toward being viewed
   as positive.

2. Common arithmetic identities (e.g. x+0 and 0+x are both equivalent to x,
   and 0-x is equivalent to -1*x) would hold everywhere.

Another concept I would think might be interesting in a floating-point format
would be a means of distinguishing discrete values from approximate values,
though I'm not sure how that should best be realized.  If a floating-point
format recognized the concept of exact values, then it would be possible to
have the difference between two exact equal values yield Identity Zero rather
than Unsigned Tiny, which might improve some corner-case behaviors (though
the differences between IZ and UT may not be sufficient to make that be worth
worrying about, IZ*inf=0 but UT*inf=NaN may be important.



> 
> It's something I'd like to become an expert in after I get RDC and CAlive
> completed, Visual FreePro, Jr. out there, and also Visual FreePro (full
> version) completed.  If I can get those done, I'll be moving then to my
> OS, but before I do that I'll spend a couple months investigating my
> Logician software, and seeing what I can come up with for a real CPU
> design (regardless of how low performing it is).  I've also learned that
> in 2015, a set of 250nm masks cost about $10K, which means a real CPU
> built on 250nm processes would cost $10K for masks, and then the cost of
> a run on a fully depreciated fab, and a fully debugged process... cheap!
> 
> :-)
> 
> Best regards,
> Rick C. Hodgin

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

#75383

On 08/11/15 21:43, glen herrmannsfeldt wrote:

<snip>

> You can get ROM sine/cosine look-up tables, always in binary fractions
> of a circle, and never in radians.

I have been single-handedly responsible for a great many Computer 
Science innovations... or at least, *would* have been, had I not later 
discovered that Somebody Else had beaten me to it.

This is one such innovation - the idea of a binary angle (and thus the 
idea of UCHAR_MAX+1-sized arrays of pre-computed sines, cosines, 
tangents, etc). MY idea... except that lots of other people obviously 
got there before me, and didn't bother to let me know.

It is just possible, however, that (somewhere in the period 2000-2004) I 
was the first to use the word "bangle" to describe such angles.

My mobile phone ran out of charge recently. If the Nobel Prize committee 
is reading this and had some trouble getting through to me, the phone's 
fully charged now, so perhaps you could try again? Thanks.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#75388

On 08/11/15 22:56, Richard Heathfield wrote:
> On 08/11/15 21:43, glen herrmannsfeldt wrote:
>
> <snip>
>
>> You can get ROM sine/cosine look-up tables, always in binary fractions
>> of a circle, and never in radians.
>
> I have been single-handedly responsible for a great many Computer
> Science innovations... or at least, *would* have been, had I not later
> discovered that Somebody Else had beaten me to it.
>
> This is one such innovation - the idea of a binary angle (and thus the
> idea of UCHAR_MAX+1-sized arrays of pre-computed sines, cosines,
> tangents, etc). MY idea... except that lots of other people obviously
> got there before me, and didn't bother to let me know.
>
> It is just possible, however, that (somewhere in the period 2000-2004) I
> was the first to use the word "bangle" to describe such angles.
>
> My mobile phone ran out of charge recently. If the Nobel Prize committee
> is reading this and had some trouble getting through to me, the phone's
> fully charged now, so perhaps you could try again? Thanks.
>

You get full credit for inventing the word "bangle", as far as I am 
concerned :-)

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

#75390

On Sunday, November 8, 2015 at 5:05:59 PM UTC-5, David Brown wrote:
> On 08/11/15 22:56, Richard Heathfield wrote:
> > On 08/11/15 21:43, glen herrmannsfeldt wrote:
> >
> > <snip>
> >
> >> You can get ROM sine/cosine look-up tables, always in binary fractions
> >> of a circle, and never in radians.
> >
> > I have been single-handedly responsible for a great many Computer
> > Science innovations... or at least, *would* have been, had I not later
> > discovered that Somebody Else had beaten me to it.
> >
> > This is one such innovation - the idea of a binary angle (and thus the
> > idea of UCHAR_MAX+1-sized arrays of pre-computed sines, cosines,
> > tangents, etc). MY idea... except that lots of other people obviously
> > got there before me, and didn't bother to let me know.
> >
> > It is just possible, however, that (somewhere in the period 2000-2004) I
> > was the first to use the word "bangle" to describe such angles.
> >
> > My mobile phone ran out of charge recently. If the Nobel Prize committee
> > is reading this and had some trouble getting through to me, the phone's
> > fully charged now, so perhaps you could try again? Thanks.
> >
> 
> You get full credit for inventing the word "bangle", as far as I am 
> concerned :-)

How come he gets credit for inventing the word bangle, but I get my
thread moved to the junk area and people start bring up Humpty Dumpty
making words mean whatever he wants to when I invent the word floan to
describe an anti-aliased point?

    Posting as "foxmuldr" on that forum (my old, old email address):
    http://gimpforums.com/thread-another-term-for-anti-alias-floan

Floan is a play on the flone word, which relates to an arrow, such as
the pixel going right where it's supposed to.  It's spelled "floan"
because it relates to the floating point nature of its existence, and
not an integer form, which is being applied as is without translation.

It made perfect sense to me.  An anti-aliased point is a floan.  You
floan to perform the operation.  The image has been floaned when it
is complete.  You enable floaning to perform the operation.

I believe floaning is a fundamental operation, and it should not be
reliant upon the opposite of aliasing, which is another fundamental
operation, but of a different kind, such that both deserve their own
word.

    https://www.wordnik.com/words/flone

Also, I believe The Bangles had big hits 20 years prior with that
name.  And in looking up the word just now, a bangle is an anklet.
Sounds like the term might trip people up.  Get it?  "Trip" them
up.  Oh well... I try.

Best regards,
Rick C. Hodgin

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

#75424

On 08/11/15 23:20, Rick C. Hodgin wrote:
> On Sunday, November 8, 2015 at 5:05:59 PM UTC-5, David Brown wrote:
>> On 08/11/15 22:56, Richard Heathfield wrote:
>>> On 08/11/15 21:43, glen herrmannsfeldt wrote:
>>>
>>> <snip>
>>>
>>>> You can get ROM sine/cosine look-up tables, always in binary fractions
>>>> of a circle, and never in radians.
>>>
>>> I have been single-handedly responsible for a great many Computer
>>> Science innovations... or at least, *would* have been, had I not later
>>> discovered that Somebody Else had beaten me to it.
>>>
>>> This is one such innovation - the idea of a binary angle (and thus the
>>> idea of UCHAR_MAX+1-sized arrays of pre-computed sines, cosines,
>>> tangents, etc). MY idea... except that lots of other people obviously
>>> got there before me, and didn't bother to let me know.
>>>
>>> It is just possible, however, that (somewhere in the period 2000-2004) I
>>> was the first to use the word "bangle" to describe such angles.
>>>
>>> My mobile phone ran out of charge recently. If the Nobel Prize committee
>>> is reading this and had some trouble getting through to me, the phone's
>>> fully charged now, so perhaps you could try again? Thanks.
>>>
>>
>> You get full credit for inventing the word "bangle", as far as I am 
>> concerned :-)
> 
> How come he gets credit for inventing the word bangle, but I get my
> thread moved to the junk area and people start bring up Humpty Dumpty
> making words mean whatever he wants to when I invent the word floan to
> describe an anti-aliased point?

I didn't say he got /positive/ credit for "bangle" :-)  Unlike some
people in this thread, I believe in negative numbers too.

Other than that, it's just that the name "bangle" appealed to me, while
the name "floan" does not.  From your post below, I am guessing that
perhaps "bangle" is not a word much used in the USA - it was certainly
common in Scotland when I grew up (where it means "bracelet" in general,
rather than "anklet").

> 
>     Posting as "foxmuldr" on that forum (my old, old email address):
>     http://gimpforums.com/thread-another-term-for-anti-alias-floan
> 
> Floan is a play on the flone word, which relates to an arrow, such as
> the pixel going right where it's supposed to.  It's spelled "floan"
> because it relates to the floating point nature of its existence, and
> not an integer form, which is being applied as is without translation.
> 
> It made perfect sense to me.  An anti-aliased point is a floan.  You
> floan to perform the operation.  The image has been floaned when it
> is complete.  You enable floaning to perform the operation.
> 
> I believe floaning is a fundamental operation, and it should not be
> reliant upon the opposite of aliasing, which is another fundamental
> operation, but of a different kind, such that both deserve their own
> word.
> 
>     https://www.wordnik.com/words/flone
> 
> Also, I believe The Bangles had big hits 20 years prior with that
> name.  And in looking up the word just now, a bangle is an anklet.
> Sounds like the term might trip people up.  Get it?  "Trip" them
> up.  Oh well... I try.
> 
> Best regards,
> Rick C. Hodgin
> 

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

#75981

On Mon, 09 Nov 2015 10:10:25 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>I didn't say he got /positive/ credit for "bangle" :-)  Unlike some
>people in this thread, I believe in negative numbers too.
>
>Other than that, it's just that the name "bangle" appealed to me, while
>the name "floan" does not.  From your post below, I am guessing that
>perhaps "bangle" is not a word much used in the USA - it was certainly
>common in Scotland when I grew up (where it means "bracelet" in general,
>rather than "anklet").

Here in the United States, we sing the Stars Bangled Banner at
sporting events. ;)

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web