On Wed, 15 Jan 2003, "Douglas A. Gwyn" wrote:
>
> Gabriel Dos Reis wrote:
> > The singular points represent the problems.
>
> No, the arctangent function has smooth behavior across the
> singular points.  That is in fact why atan2 was invented,
> to provide a way to access that nice behavior in actual
> programs.

You're right that the arctangent function is continuous ("smooth")
and has no singular points.

The atan2 function, on the other hand, _does_ have singular
points, or _discontinuities_, which cause problems mathematically
speaking -- in particular when x equals 0, because division by zero
is left undefined in mathematics and most computer applications.

> Really this whole argument has been a waste of time.

Agreed.

>  There
> are no mathematical nor practical problems with the C Standard's
> specification for atan2. There appear to be some problems in
> some people's understanding of these matters, however.

Your first sentence contradicts your second sentence.
The C Standard's job, as I understand it, is to construct a
definition for the C language and C standard libraries which
is (a) unambiguous to the average programmer, and (b) unambiguous
to the implementors of new C implementations.

_If_ the C Standard's specification for atan2 allows division by
zero without specifying the result of such a division, it is
ambiguous, and there _is_ a problem.

_If_ the C Standard's specification for atan2 has been corrected
since the publication of N869, _then_ there indeed is no problem,
and the whole discussion has been irrelevant.


My position on this whole thing is:
 [1] atan2 should be defined in the obvious way for all values of (y,x)
except (0,0), which may safely be left undefined.
 [2] Merely specifying atan2(y,x)=atan(y/x) is _not_ the obvious way,
_nor_ does it define atan2 for all values of (y,x).
 [3] Specifying atan2(y,x) as

       Given arguments y and x, not both zero, it returns (an
       approximation of) an angle theta, -pi <= theta <= pi,
       such that

         cos(theta) == x/sqrt(x*x + y*y)
         sin(theta) == y/sqrt(x*x + y*y)

certainly seems to be an improvement on the N869 draft's specification,
as it does define atan2 in the obvious way for all (y,x) not equal to
(0,0).
 [4] I have no problem if the Standard wants to define atan(m) in terms
of atan2(m,1.0), because no unspecified behavior is implied by such
a definition.

Hope this clears the waters,
-Arthur

"Gabriel Dos Reis" <gdr@integrable-solutions.net> wrote in message
news:m3vg0sh0j4.fsf@uniton.integrable-solutions.net...
> pfefferd@hotmail.co.il ("Daniel Pfeffer") writes:
>
> | As you can see, it is quite possible to perform IEEE 754 calculations
> | without encountering zeros or infinities generated by the processor;
>
> But the relevant programming languages (C99, here and presumably C++0x
> in the future) are not defined with that single assumption.  That is
> part of why we're having this discussion on comp.std.c*

C99 and C++98 do not mandate that f.p. arithmetic be performed according to
IEEE 754, but it is obvious that the designers of the languages considered
this the preferred method of f.p. arithmetic. C99 provides the <fenv.h>
header for controlling IEEE 754-style f.p. arithmetic, and the C++98
std::numeric_limits<> family has a field which the implementor may use in
order to declare that the f.p. arithmetic is IEEE 754-compatible.

Given the existence of IEEE 754-style arithmetic (specifically - signed zero
and signed infinity), it becomes reasonable to ask what is meant by
operations on these values. Note that IEEE-style arithmetic does not define
transcendental functions, therefore we are free to define them in any way
consistent with the mathematical definition of the function. I suggest the
following definitions, which are consistent with the mathematical
definitions of the functions and with the intent of IEEE 754:

In all of the cases below. the zeros and the infinities are taken as limits
of values having the same sign.

exp(+0.0) = +1.0; exp(-0.0) = +1.0; exp(+Inf) = +Inf; exp(-Inf) = +0.0
ln(+0.0) = -Inf; ln(-0.0) = NaN; ln(+Inf) = +Inf; ln(-Inf) = NaN

sin(+0.0) = +0.0; sin(-0.0) = -0.0; sin(+Inf) = NaN; sin (-Inf) = NaN
cos(+0.0) = +1.0; cos(-0.0) = +1.0; cos (+Inf) = NaN; cos(-Inf) = NaN
tan(+0.0) = +0.0; tan(-0.0) = -0.0; tan(+Inf) = NaN; tan(-Inf) = NaN

asin(+0.0) = +0.0; asin(-0.0) = -0.0; asin(+1.0) = +Pi/2; asin(-1.0)
= -Pi/2; asin(x > 1.0) = NaN; asin(x < -1.0) = NaN
acos(+0.0) = +Pi/2; acos(-0.0) = +Pi/2; acos(+1.0) = +0.0; acos(-1.0) = +Pi;
acos(x > 1.0) = NaN; acos(x < -1.0) = NaN
atan(+0.0) = +0.0; atan(-0.0) = -0.0; atan(+Inf) = +Pi/2; atan(-Inf) = -Pi/2

Define atan2(y,x) as the angle between the positive X axis and a line drawn
from the origin through the point (x,y). We then have the following "common
sense" results:

atan2(+0.0,+0.0) = NaN (More than 1 reasonable result, depending on which
limit is taken first)
atan2(+0.0,-0.0) = NaN (- " -)
atan2(-0.0,+0.0) = NaN (- " -)
atan2(-0.0,-0.0) = NaN (- " -)
atan2(+Inf,+0.0) = +Pi/2
atan2(+Inf,-0.0) = +Pi/2
atan2(-Inf,+0.0) = -Pi/2
atan2(-Inf,-0.0) = -Pi/2
atan2(+0.0,+Inf) = +0.0
atan2(+0.0,-Inf) = +Pi
atan2(-0.0,+Inf) = -0.0
atan2(-0.0,-Inf) = -Pi
atan2(+Inf,+Inf) = +Pi/4
atan2(+Inf,-Inf) = 3*Pi/4
atan2(-Inf,+Inf) = -Pi/4
atan2(-Inf,-Inf) = -3*Pi/4

The following sets of results for atan2(*0.0,*0.0) are internally
self-consistent:

Set 1 (Perform y limit first, then x limit):
    atan2(+0.0,+0.0) = atan2(+0.0,x) = +0.0
    atan2(+0.0,-0.0) = atan2(+0.0,-x) = Pi
    atan2(-0.0,+0.0) = atan2(-0.0,x) = -0.0
    atan2(-0.0,-0.0) = atan2(-0.0,-x) = -Pi

Set 2 (Perform x limit first, then y limit):
    atan2(+0.0,+0.0) = atan2(y,+0.0) = +Pi/2
    atan2(+0.0,-0.0) = atan2(y,-0.0) = +Pi/2
    atan2(-0.0,+0.0) = atan2(-y,+0.0) = -Pi/2
    atan2(-0.0,-0.0) = atan2(-y,-0.0) = -Pi/2

Set 3 (Perform both limits together):
    atan2(+0.0,+0.0) = atan2(x,x) = +Pi/4
    atan2(+0.0,-0.0) = atan2(x,-x) = +3*Pi/4
    atan2(-0.0,+0.0) = atan2(-x,x) = -Pi/4
    atan2(-0.0,-0.0) = atan2(-x,-x) = -3*Pi/4


For arithmetics with no signed zero, the above results collapse into the
following:

exp(0.0) = 1.0
exp(+Inf) = +Inf
exp(-Inf) = 0.0

ln(0.0) = NaN (more than 1 reasonable result, depending on the way the limit
is taken)
ln(+Inf) = +Inf
ln(-Inf) = NaN

sin(0.0) = 0.0; sin(+Inf) = NaN; sin (-Inf) = NaN
cos(0.0) = +1.0; cos (+Inf) = NaN; cos(-Inf) = NaN
tan(0.0) = 0.0; tan(+Inf) = NaN; tan(-Inf) = NaN

asin(0.0) = 0.0; asin(+1.0) = +Pi/2; asin(-1.0) = -Pi/2; asin(x > 1.0) =
NaN; asin(x < -1.0) = NaN
acos(0.0) = +Pi/2; acos(+1.0) = 0.0; acos(-1.0) = +Pi; acos(x > 1.0) = NaN;
acos(x < -1.0) = NaN
atan(0.0) = 0.0; atan(+Inf) = +Pi/2; atan(-Inf) = -Pi/2

atan2(0.0,0.0) = NaN (More than 1 reasonable result, depending on which
limit is taken first)
atan2(+Inf,0.0) = +Pi/2
atan2(-Inf,0.0) = -Pi/2
atan2(0.0,+Inf) = 0.0
atan2(0.0,-Inf) = NaN (More than 1 reasonable result, depending on how the
limit is taken)
atan2(+Inf,+Inf) = +Pi/4
atan2(+Inf,-Inf) = 3*Pi/4
atan2(-Inf,+Inf) = -Pi/4
atan2(-Inf,-Inf) = -3*Pi/4

For atan2(0.0,0.0) any of the results given in the three sets above are
"reasonable". For atan2(0.0,-x) either -Pi or +Pi are "reasonable".


For arithmetics with no signed zero and no signed infinity, the above
results further collapse into the following:

exp(0.0) = 1.0
exp(Inf) = NaN (more than 1 reasonable result, depending on the sign of
infinity)

ln(0.0) = NaN
ln(Inf) = NaN (more than 1 reasonable result, depending on the sign of
infinity)

sin(0.0) = 0.0; sin(Inf) = NaN
cos(0.0) = +1.0; cos (Inf) = NaN
tan(0.0) = 0.0; tan(Inf) = NaN

asin(0.0) = 0.0; asin(+1.0) = +Pi/2; asin(-1.0) = -Pi/2; asin(x > 1.0) =
NaN; asin(x < -1.0) = NaN
acos(0.0) = +Pi/2; acos(+1.0) = 0.0; acos(-1.0) = +Pi; acos(x > 1.0) = NaN;
acos(x < -1.0) = NaN
atan(0.0) = 0.0; atan(Inf) = NaN

atan2(0.0,0.0) = NaN (More than 1 reasonable result, depending on which
limit is taken first)
atan2(Inf,0.0) = NaN (more than 1 reasonable result, depending on the sign
of infinity)
atan2(0.0,Inf) = NaN (More than 1 reasonable result, depending on how the
limit is taken and on the sign of infinity)
atan2(Inf,Inf) = NaN (more than 1 reasonable result, depending on the sign
of infinity)


Daniel Pfeffer


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pfefferd@hotmail.co.il ("Daniel Pfeffer") writes:

> Given the existence of IEEE 754-style arithmetic (specifically - signed zero
> and signed infinity), it becomes reasonable to ask what is meant by
> operations on these values. Note that IEEE-style arithmetic does not define
> transcendental functions, therefore we are free to define them in any way
> consistent with the mathematical definition of the function. I suggest the
> following definitions, which are consistent with the mathematical
> definitions of the functions and with the intent of IEEE 754:
...

> atan2(+Inf,+Inf) = +Pi/4
> atan2(+Inf,-Inf) = 3*Pi/4
> atan2(-Inf,+Inf) = -Pi/4
> atan2(-Inf,-Inf) = -3*Pi/4

No, those don't seem right.  Two infinities don't necessarily have the
same "magnitude".  Consider the limit of atan2(x,2x) as x goes to
infinity.  So atan2(+-Inf,+-Inf) can reasonably take on almost any
value and should return NaN.


> The following sets of results for atan2(*0.0,*0.0) are internally
> self-consistent:
>
> Set 1 (Perform y limit first, then x limit):
>     atan2(+0.0,+0.0) = atan2(+0.0,x) = +0.0
>     atan2(+0.0,-0.0) = atan2(+0.0,-x) = Pi
>     atan2(-0.0,+0.0) = atan2(-0.0,x) = -0.0
>     atan2(-0.0,-0.0) = atan2(-0.0,-x) = -Pi
>
> Set 2 (Perform x limit first, then y limit):
>     atan2(+0.0,+0.0) = atan2(y,+0.0) = +Pi/2
>     atan2(+0.0,-0.0) = atan2(y,-0.0) = +Pi/2
>     atan2(-0.0,+0.0) = atan2(-y,+0.0) = -Pi/2
>     atan2(-0.0,-0.0) = atan2(-y,-0.0) = -Pi/2
>
> Set 3 (Perform both limits together):
>     atan2(+0.0,+0.0) = atan2(x,x) = +Pi/4
>     atan2(+0.0,-0.0) = atan2(x,-x) = +3*Pi/4
>     atan2(-0.0,+0.0) = atan2(-x,x) = -Pi/4
>     atan2(-0.0,-0.0) = atan2(-x,-x) = -3*Pi/4

As with infinities, I don't think you can assume that the +-0 values
have the same "magnitude".  Consider atan2(x,2x) as x goes to zero.
So again I think you need to have atan2(+-0,+-0) return NaN.


> For arithmetics with no signed zero, the above results collapse into the
> following:
...

> ln(0.0) = NaN (more than 1 reasonable result, depending on the way the limit
> is taken)

Nevertheless, it may be useful to have ln(0) return -Inf in this case.

> atan2(0.0,-Inf) = NaN (More than 1 reasonable result, depending on how the
> limit is taken)

But the only reasonable results are +Pi and -Pi, just like with
atan2(0,-x).  It seems more useful pick one (I'd prefer +Pi myself)
rather than return NaN.


> For arithmetics with no signed zero and no signed infinity, the above
> results further collapse into the following:
...

> ln(0.0) = NaN

Nevertheless, it may be useful to have ln(0) return Inf in this case.

> ln(Inf) = NaN (more than 1 reasonable result, depending on the sign of
> infinity)

Nevertheless, it may be useful to have ln(Inf) return Inf rather than NaN.

> atan(0.0) = 0.0; atan(Inf) = NaN

Similar to atan2(0,-Inf), for atan(Inf) only +Pi/2 and -Pi/2 are
reasonable.  It seems more useful to pick one (preferably +Pi/2)
rather than return NaN.

> atan2(Inf,0.0) = NaN (more than 1 reasonable result, depending on the sign
> of infinity)

This is like atan(Inf), so should return either +Pi/2 (preferably) or -Pi/2.

> atan2(0.0,Inf) = NaN (More than 1 reasonable result, depending on how the
> limit is taken and on the sign of infinity)

This alse seems like it should return either 0 (preferably), +Pi, or
-Pi.  But this does seem less intuitive, so maybe NaN is justified
here.

--
Eric Backus
R&D Design Engineer
Agilent Technologies, Inc.
425-335-2495 Tel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Arthur J. O'Dwyer wrote:
>  [1] atan2 should be defined in the obvious way for all values of (y,x)
> except (0,0), which may safely be left undefined.

And so it is.

>  [2] Merely specifying atan2(y,x)=atan(y/x) is _not_ the obvious way,
> _nor_ does it define atan2 for all values of (y,x).

And that's not what we did.

>  [3] Specifying atan2(y,x) as
>        Given arguments y and x, not both zero, it returns (an
>        approximation of) an angle theta, -pi <= theta <= pi,
>        such that
>          cos(theta) == x/sqrt(x*x + y*y)
>          sin(theta) == y/sqrt(x*x + y*y)
> certainly seems to be an improvement on the N869 draft's specification,
> as it does define atan2 in the obvious way for all (y,x) not equal to
> (0,0).

To be acceptable that would have to be recast in terms of the
abstract mathematical functions, not C computations.  Anyway,
it is a more complicated specification for the very same thing.

>  [4] I have no problem if the Standard wants to define atan(m) in terms
> of atan2(m,1.0), because no unspecified behavior is implied by such
> a definition.

No, we prefer to talk about the principal value of the arctangent.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 16 Jan 2003, "Douglas A. Gwyn" wrote:
>
> Arthur J. O'Dwyer wrote:
> >  [1] atan2 should be defined in the obvious way for all values of (y,x)
> > except (0,0), which may safely be left undefined.
>
> And so it is.
>
> >  [2] Merely specifying atan2(y,x)=atan(y/x) is _not_ the obvious way,
> > _nor_ does it define atan2 for all values of (y,x).
>
> And that's not what we did.

Oh.  Well, what _did_ you do?  My whole contribution to this discussion
was based on the fact that the last public ISO C draft standard, N869,
_does_ define atan2(y,x) in terms of arctan(y/x), which is ambiguous
when x==0.  If the latest Standard (or non-public draft thereof) has
fixed this, that's fine.  I have no problem with that.  End of argument,
I guess.

The N1043 (November 1996) C++ draft seems to define the math functions
only in terms of the latest ISO C standard.  So C++ doesn't really
have a problem with this; fixing the C standard would have fixed C++ too.

-Arthur

"Arthur J. O'Dwyer" wrote:
> On Thu, 16 Jan 2003, "Douglas A. Gwyn" wrote:
> > Arthur J. O'Dwyer wrote:
> >  [2] Merely specifying atan2(y,x)=atan(y/x) is _not_ the obvious way,
> > _nor_ does it define atan2 for all values of (y,x).
> > And that's not what we did.
> Oh.  Well, what _did_ you do?  My whole contribution to this discussion
> was based on the fact that the last public ISO C draft standard, N869,
> _does_ define atan2(y,x) in terms of arctan(y/x), which is ambiguous
> when x==0.

The C99 specification for the atan2 function is given in terms
of the *mathematical* arc tangent of the *mathematical* quotient
of the argument values and the branch that is appropriate for the
quadrant determined by the signs of the arguments, with a
specified range of [-Pi,+Pi] for the result of the function.

There are only two ambiguities in the spec, both intentional:
(1) A domain error is allowed if both arguments are zero; this
reflects the fact that the zero vector has no particular
direction.
(2) Either -Pi or +Pi may be returned for the point (0,neg);
this reflects the fact that there is a cut line there which
separates the levels of this multivalued function, and that it
is reasonable to allow the choice of branch to depend on the
sign of the representation of 0 for implementations that support
multiple representations of 0.

The mathematical value for the arc tangent of the mathematical
quotient of nonzero y divided by zero x is clearly sign(y)*Pi/2 +
n*2*Pi, n representing an arbitrary integer.  The restriction to
[-Pi,+Pi] clearly selects the branch sign(y)*Pi/2.  There is no
ambiguity for this case.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ianmcc@lorentz.leidenuniv.nl (Ian McCulloch) writes:

| musiphil@bawi.org (KIM Seungbeom) wrote in message news:<3E1CCCA4.6EEB62C6@bawi.org>...
| > Ian McCulloch wrote:
| > >
| > > Allan W wrote:
| > >
| > > > musiphil@bawi.org (KIM Seungbeom) wrote
| > > >> Would it be correct to say sgn(-0), sgn(0), sgn(+0) should be
| > > >> -1, 0, 1, respectively? ;-)
| > > >
| > > > I hope not!
| > > >
| > > > *shudder*
| > > >
| > >
| > > Why not?  IEEE doesn't distinguish 0 from +0 so this convention is not
| > > practical in IEEE, but the intent of -0 is to represent a negative number
| > > that has underflowed, meaning it is a placeholder for the number that we
| > > really wanted, which would be something between the smallest magnitude
| > > non-zero negative number and zero.  Likewise for +0.  Given that sgn(x) can
| > > return the exact result in these circumstances, why shouldn't it?
| >
| > Since we have 0 and +0 not distinguished, what's the good of having -0
| > as a negative underflowed number? Then what about 0(or equally +0)? Is
| > it an exact zero, or a placeholder for a positive underflowed number?
|
| Well, -0 was introduced in an attempt to solve the problem of branch
| cuts, as in atan2(+0,-1) = pi, atan2(-0,-1) = -pi.

But, since -0 is -not- mandated, how is that attempt really solve the
problem?
As I see it, the invention of -0 adds to the confusion without
solving the initial problem.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> DAGwyn@null.net ("Douglas A. Gwyn") writes:
> |                        When it comes to tangent and its inverse,
> | there are singular points so it is *essential* to come to terms
> | with them; avoiding talking about them doesn't make them go away.
> Sure, but perverting the system doesn't make the fundamental problem
> go away either.

There *is* no problem.  If you see a problem, you brought it on yourself.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> But, since -0 is -not- mandated, how is that attempt
 > really solve the problem?

-0 *is* mandated for an implementation of IEEE/IEC f.p.

There is no problem to be solved otherwise.  The C standard
doesn't mandate which of the two branches is used for the
return from atan2(0,-1).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ianmcc@lorentz.leidenuniv.nl (Ian McCulloch) wrote
> [+0] is indistinguishable (without looking at the
> flags) from true zero.  Perhaps one of the numerical experts here has
> an opinion?

If everything that has been said around here is true (especially
that -1/+Inf == -0 -- not the limit, mind you, but the equation)
then it's an easy proof (via simple algebra) that

   -0 times +Inf == -1
   +1 times +Inf == +1

I guess "plain" 0 times +Inf still equals "plain" 0
(satisfying the axiom that 0 times anything is 0).

So there's an easy way to tell them apart without parsing the flags.

On the other hand, some of us are having a difficult time explaining
what happens when you multiply or divide by infinity...

I got a headache.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

DAGwyn@null.net ("Douglas A. Gwyn") writes:

| Gabriel Dos Reis wrote:
| > DAGwyn@null.net ("Douglas A. Gwyn") writes:
| > |                        When it comes to tangent and its inverse,
| > | there are singular points so it is *essential* to come to terms
| > | with them; avoiding talking about them doesn't make them go away.
| > Sure, but perverting the system doesn't make the fundamental problem
| > go away either.
|
| There *is* no problem.

How is that assertion different from "avoiding talking about them"?

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

DAGwyn@null.net ("Douglas A. Gwyn") writes:

| Gabriel Dos Reis wrote:
| > But, since -0 is -not- mandated, how is that attempt
|  > really solve the problem?
|
| -0 *is* mandated for an implementation of IEEE/IEC f.p.

It is -not- mandated by *C99*.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
> ianmcc@lorentz.leidenuniv.nl (Ian McCulloch) wrote
>
>>[+0] is indistinguishable (without looking at the
>>flags) from true zero.  Perhaps one of the numerical experts here has
>>an opinion?
>
>
> If everything that has been said around here is true (especially
> that -1/+Inf == -0 -- not the limit, mind you, but the equation)
> then it's an easy proof (via simple algebra) that
 >
 >    -0 times +Inf == -1
 >    +1 times +Inf == +1

The rules that you use to achieve that proof don't apply to computer
arithmetic. For instance, in computer arithmetic, 1.0+e==1.0, for any
value of 'e' smaller than DBL_EPSILON. Using the (inapplicable) rules of
simple algebra, it follows that e == 1.0-1.0 == 0.0.

Any computer arithmetic operation that involves +/- Inf has to be
considered as referring to limits; if the result isn't unambiguously
defined in that context, it has to return a NaN (example: +0 * +Infinity).
I'd say the same about +/-0, except that IEEE format doesn't have an
unsigned zero, so we're forced to treat +0 as if it had no sign, for
some purposes A more complete system would have special representations
for unsigned infinity and unsigned zero; but I'm sure that such a scheme
would merely have different problems that IEEE format, rather than fewer
ones.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> It is -not- mandated by *C99*.

So what?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote in message news:<7f2735a5.0301130251.3d009d3a@posting.google.com>...
> ianmcc@lorentz.leidenuniv.nl (Ian McCulloch) wrote
> > [+0] is indistinguishable (without looking at the
> > flags) from true zero.  Perhaps one of the numerical experts here has
> > an opinion?
>
> If everything that has been said around here is true (especially
> that -1/+Inf == -0 -- not the limit, mind you, but the equation)
> then it's an easy proof (via simple algebra) that
>
>    -0 times +Inf == -1
>    +1 times +Inf == +1
>
> I guess "plain" 0 times +Inf still equals "plain" 0
> (satisfying the axiom that 0 times anything is 0).

No, infinity isn't a number as such, it doesn't obey the usual rules
for numbers.  What you have done above is equivalent to dividing both
sides of the equation by zero.  In fact, 0 * Inf is NaN, irespective
of the signs.

Ignoring signed zero, the rules for infinity are basically the same as
for the "extended reals" used in analysis.  ie, extend the number line
to [-inf, ..., +inf] (note the _closed_ interval) with Inf * n = Inf,
Inf + Inf = Inf * Inf = Inf,  etc (with the obvious sign properties).
Inf / Inf, 0 * Inf, Inf - Inf are undefined.

>
> So there's an easy way to tell them apart without parsing the flags.
>
> On the other hand, some of us are having a difficult time explaining
> what happens when you multiply or divide by infinity...

Basically the same as dividing or multiplying (respectively) by zero.

Cheers,
Ian McCulloch

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

DAGwyn@null.net ("Douglas A. Gwyn") writes:

| Gabriel Dos Reis wrote:
| > It is -not- mandated by *C99*.
|
| So what?

So re-consider this sub-thread, specifically

   | Well, -0 was introduced in an attempt to solve the problem of branch
   | cuts, as in atan2(+0,-1) = pi, atan2(-0,-1) = -pi.

   But, since -0 is -not- mandated, how is that attempt really solve the
   problem?

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." wrote:
> The rules that you use to achieve that proof don't apply to computer
> arithmetic.

However, note that what I was referring to is standard mathematics,
not computer arithmetic.  In the extended reals, some algebraic
properties of the normal reals do not hold, so one has to be extra
careful when manipulating equations.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> DAGwyn@null.net ("Douglas A. Gwyn") writes:
>
> | Gabriel Dos Reis wrote:
> | > DAGwyn@null.net ("Douglas A. Gwyn") writes:
> | > |                        When it comes to tangent and its inverse,
> | > | there are singular points so it is *essential* to come to terms
> | > | with them; avoiding talking about them doesn't make them go away.
> | > Sure, but perverting the system doesn't make the fundamental problem
> | > go away either.
> |
> | There *is* no problem.
>
> How is that assertion different from "avoiding talking about them"?
>

The 'them' that he was referring to were singular points, not problems.
The singular points must be dealt with; but since they have been dealt
with, and in a fashion that Doug finds acceptable, there isn't a
problem, as far as he's concerned.

Of course, you've made it clear you don't like the way they've been
dealt with, but your reasons for feeling that way haven't convinced
Doug. They haven't convinced me, either, but that's mainly because I
don't understand them.

You talked about the real numbers not including infinity, as if that
were a reason for not including infinity in the set of represented by
IEEE formats. I know that mathematicians routinely include infinity in
the set of numbers that they work with, or exclude it, depending
entirely upon what their needs are. They also routinely distinguish, or
fail to distinguish, +infinity from -infinity, also depending upon their
needs. Thus, there's plenty of precedent for IEEE's decision that they
needed to be able to both represent and distinguish -infinity and +
infinity. So I'm confused by your objection.

You said that a vertical line doesn't have an infinite slope. The only
definition I know of for slope becomes approaches infinity in the limit
as the line approaches vertical. One of the most popular approaches for
visualizing complex numbers is to use the stereographic projection to
map them onto the Riemann sphere, and to complete the number system by
adding in complex infinity at the North pole. With that representation,
the slope is actually continuous with the line orientation at the point
where the line goes vertical.  To say that such lines have "no slope"
rather than "infinite slope" seems to pointlessly hide that insight.
Once again, I'm confused.

Could you explain in more detail?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> DAGwyn@null.net ("Douglas A. Gwyn") writes:
> | Gabriel Dos Reis wrote:
> | > DAGwyn@null.net ("Douglas A. Gwyn") writes:
> | > |                        When it comes to tangent and its inverse,
> | > | there are singular points so it is *essential* to come to terms
> | > | with them; avoiding talking about them doesn't make them go away.
> | > Sure, but perverting the system doesn't make the fundamental problem
> | > go away either.
> | There *is* no problem.
> How is that assertion different from "avoiding talking about them"?

There is no problem because the existing specification is correct;
it automatically covers the singular points.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message
news:7f2735a5.0301130251.3d009d3a@posting.google.com...
> ianmcc@lorentz.leidenuniv.nl (Ian McCulloch) wrote
> > [+0] is indistinguishable (without looking at the
> > flags) from true zero.  Perhaps one of the numerical experts here has
> > an opinion?
>
> If everything that has been said around here is true (especially
> that -1/+Inf == -0 -- not the limit, mind you, but the equation)
> then it's an easy proof (via simple algebra) that
>
>    -0 times +Inf == -1
>    +1 times +Inf == +1
>
> I guess "plain" 0 times +Inf still equals "plain" 0
> (satisfying the axiom that 0 times anything is 0).

Without going into too much detail, the IEEE 754 Standard committee had to
make the following decisions:

1. What should the result of overflow be?

Their answer was that the result should be the OVERFLOW exception, and a
result scaled by a known amount from the "true" result. If the OVERFLOW
exception is masked, an infinity of appropriate sign should be substituted.

2. What should the result of extreme underflow be?

Their answer was that the result should be the UNDERFLOW exception, and a
result scaled by a known amount from the "true" result. If the UNDERFLOW
exception is masked, a zero of appropriate sign should be substituted.

3. What would the result of division by zero be?

Their answer was that the result should be the ZERODIVIDE exception. If the
ZERODIVIDE exception is masked, the result should be an appropriately-signed
infinity.

4. What should the result of multiplication of zero by infinity be?

Their answer was that it should be the INVALID exception. If the INVALID
exception is masked, the result should be a NaN.

5. What should the result of multiplication of a non-zero number by infinity
be?

Their answer was that it should be an appropriately-signed infinity.

As you can see, it is quite possible to perform IEEE 754 calculations
without encountering zeros or infinities generated by the processor; all you
must do is be ready to handle the various exceptions that may result. The
IEEE masked results are an attempt to provide an answer that is "good
enough" for most calculations. If your needs are such that the default
result leads to erroneous results - unmask the appropriate exceptions and
perform your own exception processing.


Daniel Pfeffer


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." wrote:

> Gabriel Dos Reis wrote:
> > DAGwyn@null.net ("Douglas A. Gwyn") writes:
> >
> > | Gabriel Dos Reis wrote:
> > | > DAGwyn@null.net ("Douglas A. Gwyn") writes:
> > | > |                        When it comes to tangent and its inverse,
> > | > | there are singular points so it is *essential* to come to terms
> > | > | with them; avoiding talking about them doesn't make them go away.
> > | > Sure, but perverting the system doesn't make the fundamental problem
> > | > go away either.
> > |
> > | There *is* no problem.
> >
> > How is that assertion different from "avoiding talking about them"?
> >
>
> The 'them' that he was referring to were singular points, not problems.
> The singular points must be dealt with; but since they have been dealt
> with, and in a fashion that Doug finds acceptable, there isn't a
> problem, as far as he's concerned.
>
> Of course, you've made it clear you don't like the way they've been
> dealt with, but your reasons for feeling that way haven't convinced
> Doug. They haven't convinced me, either, but that's mainly because I
> don't understand them.
>
> You talked about the real numbers not including infinity, as if that
> were a reason for not including infinity in the set of represented by
> IEEE formats.

Infinity is not in the set represented by IEEE formats.  *Calling* the bit
pattern infinity does not make it behave as infinity.  The bit pattern labeled
infinity in the IEEE formats behaves as a hybrid of infinity and overflow.

A case in point is subtraction.  In both the mathematical and IEEE contexts,
Inf - Inf is a nonsensical expression classed as undefined or NaN
respectively.  But Inf - N (N finite) is well defined mathematically as Inf.
But in the context of IEEE it is NaN.  This makes sense if the Inf is
interpreted as an overflow, because Overflow - N might be Overflow or it could
be a normalized number.  So it would be misleading for IEEE to require the
result of Inf - N to be Inf.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

[Mods:  This message seems to contain no much C++ specific topic, but
  I believe that it should be allowed since (a) it answers a
  question that has been asked about C/C++ features; (b) it helps
  clarifying some points that are confused.  Thanks.  ]

kuyper@wizard.net ("James Kuyper Jr.") writes:

| Gabriel Dos Reis wrote:
| > DAGwyn@null.net ("Douglas A. Gwyn") writes:
| > | Gabriel Dos Reis wrote:
| > | > DAGwyn@null.net ("Douglas A. Gwyn") writes:
| > | > |                        When it comes to tangent and its inverse,
| > | > | there are singular points so it is *essential* to come to terms
| > | > | with them; avoiding talking about them doesn't make them go away.
| > | > Sure, but perverting the system doesn't make the fundamental problem
| > | > go away either.
| > | | There *is* no problem.
| > How is that assertion different from "avoiding talking about them"?
| >
|
| The 'them' that he was referring to were singular points, not
| problems. The singular points must be dealt with; but since they have
| been dealt with, and in a fashion that Doug finds acceptable, there
| isn't a problem, as far as he's concerned.

The singular points represent the problems.

| Of course, you've made it clear you don't like the way they've been
| dealt with,

I believe this is a misrepresentation of what I've been saying.  I'm
mainly complaining about the inventions of -0 and +0 (and the added
confusion), with the excuse that one has to deal with +/-Inf which may
be singular values of arctan.   But the point remains that since those
inventions are not even required (by neither C nor C++), actually
confusion has been added but no problem has been solved.

[...]

| You talked about the real numbers not including infinity, as if that
| were a reason for not including infinity in the set of represented by
| IEEE formats.

Not at all,  I didn't imply that.  I have objected to specific
claims.  I've even stated repeatedely that mathematical Analysis
should not be confused with computation.  So yes, IEEE formats may
include infinities if they wish (and they do).  But, claims about -0
and +0 because +Inf being valid for the inverse of tangent argument
need to be questioned, since they confuse many concepts of analysis
and computation.  See below.

| I know that mathematicians routinely include infinity in
| the set of numbers that they work with, or exclude it, depending
| entirely upon what their needs are.

Yes, I'm well aware of that, and indeed it really *depends* on what
you're doing.  And if you're going to speak about "slopes", the proper
setting is Projective Geometry and -not- the one-point
compactification.   The source of the confusion seems to be that, by
an (un)fortunate accident, the one-point compactification of the plane
coincides with its projective completion.  Therefore people makes all
sort of confusion.  I guess this is an opportunity to point out
misleading statement (if not totally confused):  Doug stated earlier
that

  +              Vertical lines do have slope, +-Infinity (which
  +  is a single point on the Riemann sphere).  This is standard
  +  mathematical practice, and the corresponding angle (thus the
  +  result of the arctangent function) is evident.

Firstly, we're talking about lines in the *plane*.  Furthermore since
only their slopes are interesting to the discussion, it is the same as if
we were talking about lines passing through the origin.  The totality
of such lines has nothing to do with the Riemann sphere.  On the
contrary, the totality of such lines has to do with the unit *circle*
-- where we desesperately try to define atan().
The Riemann sphere is the double cover of the totality of lines in
*three-dimensional* space.


| They also routinely distinguish,
| or fail to distinguish, +infinity from -infinity, also depending upon
| their needs.

Again agreed.  You'll also notice that depending on whether you
distinguish +Inf from -Inf, the rules of applicable algebra are quite
different.

| Thus, there's plenty of precedent for IEEE's decision
| that they needed to be able to both represent and distinguish
| -infinity and + infinity. So I'm confused by your objection.

The trouble is that different people want to plug in IEEE f.p.
everything they can come with.  Some want to do one-point
compactification analysis with it, while others (maybe the same) want
to do Projective Geometry with it.  But they forget that the rules are
not always compatible, failing to note that, confusion follows.  And
we have indeed a total mess, where circles are confused with spheres,
analysis confused with computation...

| You said that a vertical line doesn't have an infinite slope.

Not at all.  More specifically, I said precisely this:

  | > Although this may have changed (in the US anyway) in recent
  | > years; yesterday I asked a high-school math teacher what
  | > students were being taught about vertical lines, and she
  | > said that they were being taught that they had "no slope";
  | > infinity is never mentioned.

  Since the standard (mathematical) set of real numbers does not include
  +/- infitnity and the slope of a line is defined a real number, it
  comes as no surprise that saying "the slope of the vertical line is
  +/- infinity" is meaningless.

Note also the context.  Note also that I'm not saying vertical lines
don't have slope.  I'm explaining why a particular sentence is
meaningless.

| The only
| definition I know of for slope becomes approaches infinity in the
| limit as the line approaches vertical.

Agreed.  Notice that "approaching" does not mean "being equal".

| One of the most popular
| approaches for visualizing complex numbers is to use the stereographic
| projection to map them onto the Riemann sphere, and to complete the
| number system by adding in complex infinity at the North pole.

This is the one-point compactification of the plane I was talking about.
It is most appropriate if you want to do (Complex) Analysis -- where
you're more concerned about points than about lines.  It is
not the natural setting for talking about lines and their slopes; the
natural setting for that is Projective Geometry.

Notice that, in the one-point compactification, lines through the
origin maps to circles containing the Nord and South pole.  What entity
do you call "slope" in that picture?

| With
| that representation, the slope is actually continuous with the line

Beware that talking about "continuity" implies that you've choosen
topologies on both the domain and target spaces -- which you are still
trying to define.

| orientation at the point where the line goes vertical.  To say that
| such lines have "no slope" rather than "infinite slope" seems to
| pointlessly hide that insight. Once again, I'm confused.

It doesn't pointlessly hide that insight.  It just points out
confusion -- assuming I've said what you claim (which I didn't).

| Could you explain in more detail?

Sure, assuming it will pass moderator's filter.

Without loss of generality, we may assume that we are talking
about lines passing through the origin.  Such a (non-directed) line is
characterized at the set of points (x, y) solutions of the equation

    a * x + b * y = 0

for some fixed real numbers a and b -- both not simultaneously nul.
You therefore realize that  (a, b) may be thought of as a coordinate
of a line.  For non-null l, (a * l, b * l) and (a, b) are the
coordinates of the -same- line.  When b is nonnul, one calls the
ratio a/b the slope of the line with coordinate (a, b).  As you may
guess, there is a sensation that some number is redundant and that the
slope a/b is a reduced coordinate.  Indeed, the set of of lines
passing through the origin is a one-dimensional thingy.  For this
thingy, if you insist on talking about slope even when b == 0 (for the
vertical line), then *you don't want to distinguish +Inf from -Inf*
since (-1, 0) and (1, 0) are valid coordinates for the same line.

However, if you consider the set of *directed lines*, then (a, b) will
designate the same (oriented) line as (a * l, b * l) only if l is
positive.  For the set of oriented lines, it is necessary to
distinguish +Inf from -Inf.  You can easily see that the set of
directed lines is a double cover of the set of non-directed lines, and
is the *unit circle*.

Therefore, if your interest is in computing the slope of a line (which
are not directed), then you don't need +Inf and -Inf.


What I've said above generalizes to higher dimensions.  And the sets
you get do -not- concide with the one-point compactification.  What
happens in the plane is just an "accident".

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3E236C01.389A0CBA@attbi.com>, witless@attbi.com (Witless)
wrote:

> "James Kuyper Jr." wrote:
>
> > Gabriel Dos Reis wrote:
> > > DAGwyn@null.net ("Douglas A. Gwyn") writes:
> > >
> > > | Gabriel Dos Reis wrote:
> > > | > DAGwyn@null.net ("Douglas A. Gwyn") writes:
> > > | > |                        When it comes to tangent and its inverse,
> > > | > | there are singular points so it is *essential* to come to terms
> > > | > | with them; avoiding talking about them doesn't make them go away.
> > > | > Sure, but perverting the system doesn't make the fundamental problem
> > > | > go away either.
> > > |
> > > | There *is* no problem.
> > >
> > > How is that assertion different from "avoiding talking about them"?
> > >
> >
> > The 'them' that he was referring to were singular points, not problems.
> > The singular points must be dealt with; but since they have been dealt
> > with, and in a fashion that Doug finds acceptable, there isn't a
> > problem, as far as he's concerned.
> >
> > Of course, you've made it clear you don't like the way they've been
> > dealt with, but your reasons for feeling that way haven't convinced
> > Doug. They haven't convinced me, either, but that's mainly because I
> > don't understand them.
> >
> > You talked about the real numbers not including infinity, as if that
> > were a reason for not including infinity in the set of represented by
> > IEEE formats.
>
> Infinity is not in the set represented by IEEE formats.  *Calling* the bit
> pattern infinity does not make it behave as infinity.  The bit pattern labeled
> infinity in the IEEE formats behaves as a hybrid of infinity and overflow.
>
> A case in point is subtraction.  In both the mathematical and IEEE contexts,
> Inf - Inf is a nonsensical expression classed as undefined or NaN
> respectively.  But Inf - N (N finite) is well defined mathematically as Inf.
> But in the context of IEEE it is NaN.  This makes sense if the Inf is
> interpreted as an overflow, because Overflow - N might be Overflow or it could
> be a normalized number.  So it would be misleading for IEEE to require the
> result of Inf - N to be Inf.

I wouldn't want to comment whether it is misleading or not, but that is
exactly what it requires. Inf - N => Inf, if N is any finite number.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In message <3E236582.90908@wizard.net>, James Kuyper Jr.
<kuyper@wizard.net> writes
>You said that a vertical line doesn't have an infinite slope. The only
>definition I know of for slope becomes approaches infinity in the limit
>as the line approaches vertical. One of the most popular approaches for
>visualizing complex numbers is to use the stereographic projection to
>map them onto the Riemann sphere, and to complete the number system by
>adding in complex infinity at the North pole. With that representation,
>the slope is actually continuous with the line orientation at the point
>where the line goes vertical.  To say that such lines have "no slope"
>rather than "infinite slope" seems to pointlessly hide that insight.
>Once again, I'm confused.

I am reminded of something Dr Conway wrote in the introduction to his
book 'On Numbers and Games' which basically said that if a concept is
useful use it. This was in the context of infinitesimals where
traditional analysis denies their existence and goes through contortions
to avoid them. Non-standard analysis gives them meaning and uses them.

Infinity may not be a real number but it is a valid mathematical concept
(the only problem being that there are many of them). Even the
mathematical traditionalists understand what is meant by saying a line
has infinite gradient, so let us stop arguing about angels and pin
heads.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pfefferd@hotmail.co.il ("Daniel Pfeffer") writes:

| As you can see, it is quite possible to perform IEEE 754 calculations
| without encountering zeros or infinities generated by the processor;

But the relevant programming languages (C99, here and presumably C++0x
in the future) are not defined with that single assumption.  That is
part of why we're having this discussion on comp.std.c*

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> The singular points represent the problems.

No, the arctangent function has smooth behavior across the
singular points.  That is in fact why atan2 was invented,
to provide a way to access that nice behavior in actual
programs.

> The Riemann sphere is the double cover of the totality of lines in
> *three-dimensional* space.

It's more usually employed as a 2-dimensional domain that
extends the complex field by including one additional point,
which greatly simplifies operations with conformal mappings.

>   comes as no surprise that saying "the slope of the vertical line is
>   +/- infinity" is meaningless.
> Note also the context.  Note also that I'm not saying vertical lines
> don't have slope.  I'm explaining why a particular sentence is
> meaningless.

So if they do have slope, what is their slope?

> ...l line), then *you don't want to distinguish +Inf from -Inf*
> since (-1, 0) and (1, 0) are valid coordinates for the same line.

That's fine with me.  Indeed, to make the distinction for some
of the singular trig functions, one has to have additional
information (such as might be encoded in the sign of zero).
The arctangent is continuous from -Inf to +Inf anyway, so
this is irrelevant.

Really this whole argument has been a waste of time.  There
are no mathematical nor practical problems with the C Standard's
specification for atan2.  There appear to be some problems in
some people's understanding of these matters, however.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> I am reminded of something Dr Conway wrote in the introduction to his
> book 'On Numbers and Games' which basically said that if a concept is
> useful use it. This was in the context of infinitesimals where
> traditional analysis denies their existence and goes through contortions
> to avoid them. Non-standard analysis gives them meaning and uses them.

Indeed, Conway's version of surreal numbers allows their use as
values of (simple) games, in which one's advantage is infinitesimal
but nevertheless sufficient to win against weaker infinitesimals.
There is a whole algebra for such numbers.

"Winning Ways" has a good description of this.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

DAGwyn@null.net ("Douglas A. Gwyn") writes:

| Gabriel Dos Reis wrote:
| > The singular points represent the problems.
|
| No, the arctangent function has smooth behavior across the
| singular points.  That is in fact why atan2 was invented,
                                                  ^^^^^^^^
Actually, that is not a real invention:  That function has been there
all the time; only confusion didn't make it appear from the outset.

| to provide a way to access that nice behavior in actual
| programs.

While atan2() is the right function to consider and provide a nice
computational counterpart of the mathematical object, atan() does
-not- has a smooth behavior across the singular points.

| > The Riemann sphere is the double cover of the totality of lines in
| > *three-dimensional* space.
|
| It's more usually employed as a 2-dimensional domain that
| extends the complex field by including one additional point,
| which greatly simplifies operations with conformal mappings.

But that is irrelevant: You quoted the above out of context.  The
context was correcting the false claim

  +              Vertical lines do have slope, +-Infinity (which
  +  is a single point on the Riemann sphere).  This is standard
  +  mathematical practice, and the corresponding angle (thus the
  +  result of the arctangent function) is evident.

If you were to consider atan() as a function on the Riemann sphere you
will quickly realize that the distinction +Inf. vs -Inf. is
meaningless, or more precisely troublesome and does -not- simply anything.

| >   comes as no surprise that saying "the slope of the vertical line is
| >   +/- infinity" is meaningless.
| > Note also the context.  Note also that I'm not saying vertical lines
| > don't have slope.  I'm explaining why a particular sentence is
| > meaningless.
|
| So if they do have slope, what is their slope?

See the previous message of mine you were replying to.

| > ...l line), then *you don't want to distinguish +Inf from -Inf*
| > since (-1, 0) and (1, 0) are valid coordinates for the same line.
|
| That's fine with me.  Indeed, to make the distinction for some
| of the singular trig functions, one has to have additional
| information (such as might be encoded in the sign of zero).

But, the point is that the invention of "sign of zero"
   1) is insufficient to encode such information
   2) perverts the rest of algebra with no gain

In the end, it is an invention that does not solve a problem, but
rather adds a whole bunch of other ones.

| The arctangent is continuous from -Inf to +Inf anyway, so
| this is irrelevant.

irrelevant to what?  One of the issue in this subthread was the slope
of the vertical line, and it was acknowledged that the right function
to consider is atan2() and not atan().
However, arguments using behaviours of atan() as ways of determining
slope of lines or to justify the invention "+0 or -0" are suspect.

| Really this whole argument has been a waste of time.

Not really, it permitted to correct some misunderstanding.

|  There
| are no mathematical nor practical problems with the C Standard's
| specification for atan2.

You would have certainly noticed that I was -not- questioning the definition
of atan2(); I was questioning specific claims.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

DAGwyn@null.net ("Douglas A. Gwyn") writes:

[...]

|                        When it comes to tangent and its inverse,
| there are singular points so it is *essential* to come to terms
| with them; avoiding talking about them doesn't make them go away.

Sure, but perverting the system doesn't make the fundamental problem
go away either.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

DAGwyn@null.net ("Douglas A. Gwyn") writes:

| Gabriel Dos Reis wrote:
| > But that inspiration ignores the basic fact that numerical computation
| > is -not- (mathematical) Analysis, and more importantly reuses a
| > convention ouf of its context.  No surprises it leads to confusion
| > scary situations.
|
| The issue has nothing to do with numerical computation vs. Analysis.
| I'm not trying to defend a naive reliance on the model realized by
| IEEE/IEC f.p. to get the right answer automatically in all situations;
| indeed I've argued vociferously against it in WG14 discussions.
| What I *am* saying is that the extended number system model for which
| 1/0 has a value (+-)Infinity which is a valid argument to the inverse
| of the tangent function is absolutely standard among mathematicians.

This is were Analysis is confused with computation.
What is a standard practice among mathematicians is Arctan(-+infinity)
and Arctan(-infinity) well defined by taking the appropriate *limits*.
That standard practice (mathematical Analysis) does not automaticallly
define -0 or +0.

| The result is well defined (modulo the periodicity that applies to
| all values), and the use of this convention in a brief specification
| should cause no problem.

The result is well defiined when the context of its derivation is -not-
forgotten.  But the trouble is that, computations nrealy forgets about
context.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

musiphil@bawi.org (KIM Seungbeom) wrote in message news:<3E1CCCA4.6EEB62C6@bawi.org>...
> Ian McCulloch wrote:
> >
> > Allan W wrote:
> >
> > > musiphil@bawi.org (KIM Seungbeom) wrote
> > >> Would it be correct to say sgn(-0), sgn(0), sgn(+0) should be
> > >> -1, 0, 1, respectively? ;-)
> > >
> > > I hope not!
> > >
> > > *shudder*
> > >
> >
> > Why not?  IEEE doesn't distinguish 0 from +0 so this convention is not
> > practical in IEEE, but the intent of -0 is to represent a negative number
> > that has underflowed, meaning it is a placeholder for the number that we
> > really wanted, which would be something between the smallest magnitude
> > non-zero negative number and zero.  Likewise for +0.  Given that sgn(x) can
> > return the exact result in these circumstances, why shouldn't it?
>
> Since we have 0 and +0 not distinguished, what's the good of having -0
> as a negative underflowed number? Then what about 0(or equally +0)? Is
> it an exact zero, or a placeholder for a positive underflowed number?

Well, -0 was introduced in an attempt to solve the problem of branch
cuts, as in atan2(+0,-1) = pi, atan2(-0,-1) = -pi.  Distinguishing
between positive and negative underflowed data in the sgn() function
is something that might be desirable (although I can't say I've ever
missed not having it), but is a different problem.  The only way in
IEEE to distinguish 0 from a positive underflow is with traps/flags.

As to whether it is a good idea to regard +/- 0 as a placeholder for
an underflowed value, I don't know.  Certainly for +0 it is
problematic because it is indistinguishable (without looking at the
flags) from true zero.  Perhaps one of the numerical experts here has
an opinion?

Cheers,
Ian

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

DAGwyn@null.net ("Douglas A. Gwyn") wrote
> Allan W wrote:
> > Beg to differ. In real life and in algebra, there IS no reciprocal
> > of -Infinity.
> > The closest you can get is first-semester Calculus, which states
> > that as x approaches -Infinity, 1/x increases towards 0. I don't
> > think that was ever called -0, though.
>
> (1) There is a reciprocal of -Infinity, if one *has* -Infinity
> in one's extension of the real number system in the first place.
> That reciprocal is precisely -0.  Whether this is also equal to
> +0 depends on other matters.

You're suggesting that there's some "extended" real number z, such
that 1/z == -0. By extension, then, 1/-0 == z. You also suggest that
this is relevant to the way that C++ defines atan2, because it
makes the definition of y/x valid when x==0.

Even if there's some branch of mathematics where all of this is true,
it certainly can't be assumed when reading a language spec. As anyone
who has studied High School math knows, an expression such as y/x
comes with a (possibly-implied) statement that x != 0. Since the
standard paragraph about atan2() doesn't explicitly mention behavior
when x==0, it's natural to conclude that this isn't valid. If you
want to make it valid, you're going to have to say something in the
standard!

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

DAGwyn@null.net ("Douglas A. Gwyn") wrote
> I don't think there is any need to refer to geometric terms
> in the specification.  In fact I don't think there is any
> problem understanding the specification, assuming one has
> had standard mathematical training at the high-school level.

This thread is evidence to the contrary; it wasn't me who
first pointed out problems with the current specification
referring to the fraction y/x.

> Although this may have changed (in the US anyway) in recent
> years; yesterday I asked a high-school math teacher what
> students were being taught about vertical lines, and she
> said that they were being taught that they had "no slope";
> infinity is never mentioned.

As was I.

> One wonders how these guys are
> ever going to apply IEEE/IEC f.p. if they have no knowledge
> of the use of infinity in an extension of the real number
> system.

Exactly. High schools don't teach floating-point math; they
teach real numbers. Until you're in calculus, there's no such
thing as infinity.

Even then, limits tell us that as x approaches 0, 1/x approaches
infinity -- but this is very different than saying that 1/0=infinity.

> > How about:
> >     The atan2 functions compute the principal value of the arc tangent
> >     of a line with slope y/x in the first or fourth quadrant.
>
> No!  The result can be in any quadrant.  You are being
> befuddled by thinking of one-argument arctangent as a
> single-valued function.

What's your alternative?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) writes:

| > Although this may have changed (in the US anyway) in recent
| > years; yesterday I asked a high-school math teacher what
| > students were being taught about vertical lines, and she
| > said that they were being taught that they had "no slope";
| > infinity is never mentioned.

Since the standard (mathematical) set of real numbers does not include
+/- infitnity and the slope of a line is defined a real number, it
comes as no surprise that saying "the slope of the vertical line is
+/- infinity" is meaningless.

(And yes, I teach mathematics).

| As was I.

Which is quite understandable.

| > One wonders how these guys are
| > ever going to apply IEEE/IEC f.p. if they have no knowledge
| > of the use of infinity in an extension of the real number
| > system.

That aasertion confuses "real numbers" with IEEE/IEC floating points.
That is regrettable because it adds to an already confused situation.
It is quite possible (and that do happens routinely) to find people
who have a perfect understanding of real numbers (with all those
infinities) and find IEEE/IEC f.p. a good example of absurdity.
Conversely, some people have good understanding of IEEE/IEC f.p. but
have less good understanding of real numbers and infinities.

| Exactly. High schools don't teach floating-point math; they
| teach real numbers.

Agreed.  And floating points calculus is -not- real number calculus.

Major programming languages like C and C++ should refrain from adding
to the confusion.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

DAGwyn@null.net ("Douglas A. Gwyn") writes:

| Allan W wrote:
| > Beg to differ. In real life and in algebra, there IS no reciprocal
| > of -Infinity.
| > The closest you can get is first-semester Calculus, which states
| > that as x approaches -Infinity, 1/x increases towards 0. I don't
| > think that was ever called -0, though.

The short answer is "numerical computation is neither Analysis nor Algebra".

| (1) There is a reciprocal of -Infinity, if one *has* -Infinity
| in one's extension of the real number system in the first place.
| That reciprocal is precisely -0.

Only if one decides that -Infinity has a reciprocal and one decides to
call that reciprocal -0.  Plain 0 is an equally reasonable choice.
As you can see, it is not matter of theorem: It is a confused
engineering decision that leads to confusion.

|  Whether this is also equal to
| +0 depends on other matters.

Yeah.

| (2) Standard terminology for approaching 0 from below is arrow 0-
| and IEEE/IEC usage of signed zero is inspired by this model.

But that inspiration ignores the basic fact that numerical computation
is -not- (mathematical) Analysis, and more importantly reuses a
convention ouf of its context.  No surprises it leads to confusion
scary situations.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ian McCulloch wrote:
>
> Allan W wrote:
>
> > musiphil@bawi.org (KIM Seungbeom) wrote
> >> Would it be correct to say sgn(-0), sgn(0), sgn(+0) should be
> >> -1, 0, 1, respectively? ;-)
> >
> > I hope not!
> >
> > *shudder*
> >
>
> Why not?  IEEE doesn't distinguish 0 from +0 so this convention is not
> practical in IEEE, but the intent of -0 is to represent a negative number
> that has underflowed, meaning it is a placeholder for the number that we
> really wanted, which would be something between the smallest magnitude
> non-zero negative number and zero.  Likewise for +0.  Given that sgn(x) can
> return the exact result in these circumstances, why shouldn't it?

Since we have 0 and +0 not distinguished, what's the good of having -0
as a negative underflowed number? Then what about 0(or equally +0)? Is
it an exact zero, or a placeholder for a positive underflowed number?

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
> Even if there's some branch of mathematics where all of this is true,
> it certainly can't be assumed when reading a language spec.

Excuse me?  The C standard even has an annex for binding to
IEEE/IEC floating-point, which has explicit representations
for all those extended numbers (+-Zero, +-Infinity).  If the
reader of the standard doesn't understand how these notions
work, he's going to have trouble with a lot more than just
the atan2 spec.

> As anyone who has studied High School math knows, an
 > expression such as y/x comes with a (possibly-implied)
 > statement that x != 0.

Actually I help a high-school math teacher in my spare time,
and the students are not taught much of anything about the
relevant concepts in these situations.  Why should vertical
lines be qualitatively different from horizontal lines?  The
correct answer is that they shouldn't, but the requisite
degree of generality to handle them properly is these days
considered to be "too much" for students at that level.

It is true (and provable, if high-school students were
appropriately taught) that there is no conventional real
number z such that z = y/0 when y is nonzero.  It is also
true that the real number system can be extended by including
special values that share some but not all of the usual
algebraic rules.  Indeed when one studies complex functions
it is essential (for some purposes) to include a "point at
infinity" in order to avoid exceptional cases, just as
actually *handling* the slope of a vertical line instead of
pretending that it cannot happen avoids making a special
case for that direction for atan2.

> If you want to make it valid, you're going to have to
 > say something in the standard!

I don't think it has been a problem for implementors to
understand what is required for that situation.  Do you
know of any implementation that has gotten it wrong?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> That aasertion confuses "real numbers" with IEEE/IEC floating points.

To the contrary, I'm well aware of the differences.  The point is
that IEEE/IEC f.p. represents a number system that has a different
*model* than the ordinary unextended real-number system.  All these
models are human inventions; the appropriate one(s) should be used
for the task at hand.  When it comes to tangent and its inverse,
there are singular points so it is *essential* to come to terms
with them; avoiding talking about them doesn't make them go away.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> But that inspiration ignores the basic fact that numerical computation
> is -not- (mathematical) Analysis, and more importantly reuses a
> convention ouf of its context.  No surprises it leads to confusion
> scary situations.

The issue has nothing to do with numerical computation vs. Analysis.
I'm not trying to defend a naive reliance on the model realized by
IEEE/IEC f.p. to get the right answer automatically in all situations;
indeed I've argued vociferously against it in WG14 discussions.
What I *am* saying is that the extended number system model for which
1/0 has a value (+-)Infinity which is a valid argument to the inverse
of the tangent function is absolutely standard among mathematicians.
The result is well defined (modulo the periodicity that applies to
all values), and the use of this convention in a brief specification
should cause no problem.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Sorry, I meant "principal angle".  "Principle" means something else.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:

> musiphil@bawi.org (KIM Seungbeom) wrote
>> Would it be correct to say sgn(-0), sgn(0), sgn(+0) should be
>> -1, 0, 1, respectively? ;-)
>
> I hope not!
>
> *shudder*
>

Why not?  IEEE doesn't distinguish 0 from +0 so this convention is not
practical in IEEE, but the intent of -0 is to represent a negative number
that has underflowed, meaning it is a placeholder for the number that we
really wanted, which would be something between the smallest magnitude
non-zero negative number and zero.  Likewise for +0.  Given that sgn(x) can
return the exact result in these circumstances, why shouldn't it?

Cheers,
Ian McCulloch

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3E177F0A.5020000@null.net>,
Douglas A. Gwyn <DAGwyn@null.net> wrote:
>Mark Jason Dominus wrote:
>> Arthur J. O'Dwyer <ajo@andrew.cmu.edu> wrote:
>>>All posters so far have skirted around the obvious reason:
>>>according to the literal word of the Standard, atan2(0,-1.)
>>>is allowed to produce an undefined result!
>> So it is.  Thanks; this had escaped me.
>
>Wrong, atan2() has a defined result for all argument pairs.
>Technically there is a choice of -Pi or Pi for that example,

Where does it say that?  I only see:

       7.12.4.4[#2] The atan2 functions compute the principal value of
       the arc tangent of y/x, using the signs of both arguments to
       determine the quadrant of the return value.  A domain error may
       occur if both arguments are zero.

For atan2(1, 0), this means that the function should compute the
principal value of the arc tangent of 1/0.  But

        6.5.5[#5] The result of the / operator is the quotient from
       the division of the first operand by the second; ... if the
       value of the second operand is zero, the behavior is undefined.

Is there some way to know that the mention of "y/x" in 7.12.4.4[#2] is
not referring to the / operator?

7.12.4.4[#2] could have said something like:

        The atan2 functions return the angle, in radians, of the ray
        from the origin to the point (x, y), measured counterclockwise
        from the positive x axis.  A domain error may occur if both
        arguments are zero.

But it does not; it specifically mentions division of y by x, and
division by zero is undefined unless annex F is in force.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Mark Jason Dominus wrote:
> Douglas A. Gwyn <DAGwyn@null.net> wrote:
>>Mark Jason Dominus wrote:
>>>Arthur J. O'Dwyer <ajo@andrew.cmu.edu> wrote:
>>>>according to the literal word of the Standard, atan2(0,-1.)
>>>>is allowed to produce an undefined result!
>>>So it is.  Thanks; this had escaped me.
>>Wrong, atan2() has a defined result for all argument pairs.
>>Technically there is a choice of -Pi or Pi for that example,
> Where does it say that?  I only see:
>        7.12.4.4[#2] The atan2 functions compute the principal value of
>        the arc tangent of y/x, using the signs of both arguments to
>        determine the quadrant of the return value.  A domain error may
>        occur if both arguments are zero.
> For atan2(1, 0), this means that the function should compute the
> principal value of the arc tangent of 1/0.

Note also that that is not the specific example being discussed.
The point (1,0) is not the same point as (0,-1).  Division by
zero is not an issue of any sort for the original example of
obtaining a value for Pi as atan2(0,-1).

 >  But
>         6.5.5[#5] The result of the / operator is the quotient from
>        the division of the first operand by the second; ... if the
>        value of the second operand is zero, the behavior is undefined.

There is no / operator involved in the atan2 definition.  *That*
division occurs in the extended real-number field, and does not
involve any C data types.

> Is there some way to know that the mention of "y/x" in 7.12.4.4[#2]
 > is not referring to the / operator?

I don't have my copy of C99 at hand to check, but if we got
the typography right then that / character should not be in
Courier font.

A better way to see it is to note that the only domain error
mentioned would be a subset of the domain errors that would
be allowed if division by zero was supposed to be a problem
in this context.  The only reason there is a problem at the
point (0,0) is that *any* value in the allowed range would
work.  (In my own implementations I always return the
definite value 0.)

Finally, atan2 has a very long history going back to early
versions of Fortran, and it has always been meant to get
the right answer along the axes.

If you still don't believe me, get your national body on
WG14 to submit a Defect Report and I'll make sure that we
tell you the same thing in the official response.

> 7.12.4.4[#2] could have said something like:
>         The atan2 functions return the angle, in radians, of the ray
>         from the origin to the point (x, y), measured counterclockwise
>         from the positive x axis.  A domain error may occur if both
>         arguments are zero.

That would be wrong for half the domain.  Since there is a
well-understood convention for the principal angle, we just
made use of that rather than complicate the description.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Arthur J. O'Dwyer wrote:
> The N869 draft explicitly refers to atan(y/x) in the
 > definition of atan2(y,x), ...

It shouldn't; C89 had it right: it is the arc tangent
of y/x that is computed (taking into account the
quadrant), and that y/x is in the extended real-number
domain, not a floating-point operation (which as you
say would result in undefined behavior).  My copy of
the C99 standard isn't at hand right now, but if it
differs from C89 in the way you indicated then it is
wrong and we need to correct it.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 6 Jan 2003, "Douglas A. Gwyn" wrote:
>
> Mark Jason Dominus wrote:
> > Douglas A. Gwyn <DAGwyn@null.net> wrote:
> >>Mark Jason Dominus wrote:
> >>>Arthur J. O'Dwyer <ajo@andrew.cmu.edu> wrote:
> >>>>according to the literal word of the Standard, atan2(0,-1.)
> >>>>is allowed to produce an undefined result!

Whoops.  That whole y-before-x thing is messing me up.  I am wrong
on this point; Doug is right.  It is atan2(-1.,0) that is allowed
to produce an undefined result.

> >>>So it is.  Thanks; this had escaped me.
> >>Wrong, atan2() has a defined result for all argument pairs.
> >>Technically there is a choice of -Pi or Pi for that example,
> > Where does it say that?  I only see:
> >        7.12.4.4[#2] The atan2 functions compute the principal value of
> >        the arc tangent of y/x, using the signs of both arguments to
> >        determine the quadrant of the return value.  A domain error may
> >        occur if both arguments are zero.
> > For atan2(1, 0), this means that the function should compute the
> > principal value of the arc tangent of 1/0.
>
> Note also that that is not the specific example being discussed.
> The point (1,0) is not the same point as (0,-1).  Division by
> zero is not an issue of any sort for the original example of
> obtaining a value for Pi as atan2(0,-1).

Yes, you're right.  I'm sorry.  <OT> I think in Turbo Pascal the atan2
function has the arguments in (x,y) order, and that's why I'm constantly
confusing them. </OT>

On the other hand, this raises another reason to use 4*atan2(1.,1.)
over atan2(0,-1.) ... because there's no chance of mixing up the
arguments in the former case!

> >  But
> >         6.5.5[#5] The result of the / operator is the quotient from
> >        the division of the first operand by the second; ... if the
> >        value of the second operand is zero, the behavior is undefined.
>
> There is no / operator involved in the atan2 definition.  *That*
> division occurs in the extended real-number field, and does not
> involve any C data types.
>
> > Is there some way to know that the mention of "y/x" in 7.12.4.4[#2]
> > is not referring to the / operator?
>
> I don't have my copy of C99 at hand to check, but if we got
> the typography right then that / character should not be in
> Courier font.

It's hard for me to tell from N869.pdf, but I think you're
probably right.  That is, the y and the x are both in Courier,
but the slash appears not to be.  What this is intended to show
in the Standard, I'm not sure.

> A better way to see it is to note that the only domain error
> mentioned would be a subset of the domain errors that would
> be allowed if division by zero was supposed to be a problem
> in this context.  The only reason there is a problem at the
> point (0,0) is that *any* value in the allowed range would
> work.  (In my own implementations I always return the
> definite value 0.)
>
> Finally, atan2 has a very long history going back to early
> versions of Fortran, and it has always been meant to get
> the right answer along the axes.

I certainly agree that that is what atan2 is *meant* to do.
I merely pointed out (or tried to) that that is not what the
C99 Standard *says* it does, necessarily.

> If you still don't believe me, get your national body on
> WG14 to submit a Defect Report and I'll make sure that we
> tell you the same thing in the official response.
>
> > 7.12.4.4[#2] could have said something like:
> >         The atan2 functions return the angle, in radians, of the ray
> >         from the origin to the point (x, y), measured counterclockwise
> >         from the positive x axis.  A domain error may occur if both
> >         arguments are zero.
>
> That would be wrong for half the domain.  Since there is a
> well-understood convention for the principal angle, we just
> made use of that rather than complicate the description.

My point was that the atan2 description does *not* mention anything
about the principal angle.  Adding such a description would fix the
problem.

This has gotten pretty far from the discussion about
calculating pi, but it looks like the choice now is between

  4*atan2(1.,1.)
and
  fabs(atan2(0,-1.))   [ or abs(...) in C++: to get rid of -PI ]

and I still prefer the former version.
Obviously, there's less chance of getting confused about
it. ;-)

-Arthur


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

KIM Seungbeom wrote:
....
> I cannot even figure out what the negative zero is supposed to
> represent in real life and mathematics..

One way to think about it is that f(-0.0) represents the limit of f(x)
as x approach 0.0 from the negative direction. One of the peculiarities
of IEEE floating point format is that, in principle, it has a
representation for +0.0 and one for -0.0, but not one for a signless 0.0
(though in most cases you can ignore the difference between +0.0 and
0.0). This decision has advantages and disadvantages, and it can be
argued over, but it's unlikely to be changed anytime soon.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jean-Marc Bourguet wrote:
>
> musiphil@bawi.org (KIM Seungbeom) writes:
>
> > Then, in what ways should the negative zero be different from the
> > positive zero? They are compared equal by the relational and
> > equality operators, so we have a==b but f(a)!=f(b) (where a=0.0,
> > b=-0.0, f(x)=atan2(x, -1.0)). Isn't it confusing?
>
> atan2 has a discontinuity at 0 for the first argument. positive 0
> gives one side of the discontinuity, negative 0 the other side.

Mathematically, we can say for some function f that
lim_{x->-0} f(x) != lim_{x->+0} f(x), but not f(-0) != f(+0).

Would it be correct to say sgn(-0), sgn(0), sgn(+0) should be
-1, 0, 1, respectively? ;-)

> > I cannot even figure out what the negative zero is supposed to
> > represent in real life and mathematics..
>
> It's only usefullness is when computing the value of functions which
> have a discontinuity at 0 where it allows to get the values on the two
> side.  Too much a special case to be anything other than a hack.

So, is the negative zero different from the positive zero?
(We are not talking about limiting values which imply direction.)
If we want to treat them as the same values, as they are currently
compared by the relational and equality operators, I think
atan2(-0.0, -1.0) should be the same as atan2(+0.0, -1.0).

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Mark Jason Dominus wrote:
>
> In article <3E177F0A.5020000@null.net>,
> Douglas A. Gwyn <DAGwyn@null.net> wrote:
> >
> >Wrong, atan2() has a defined result for all argument pairs.
> >Technically there is a choice of -Pi or Pi for that example,
>
> Where does it say that?  I only see:
>
>        7.12.4.4[#2] The atan2 functions compute the principal value of
>        the arc tangent of y/x, using the signs of both arguments to
>        determine the quadrant of the return value.  A domain error may
>        occur if both arguments are zero.
>
> For atan2(1, 0), this means that the function should compute the
> principal value of the arc tangent of 1/0.  But
>
>         6.5.5[#5] The result of the / operator is the quotient from
>        the division of the first operand by the second; ... if the
>        value of the second operand is zero, the behavior is undefined.
>
> Is there some way to know that the mention of "y/x" in 7.12.4.4[#2] is
> not referring to the / operator?
>
> 7.12.4.4[#2] could have said something like:
>
>         The atan2 functions return the angle, in radians, of the ray
>         from the origin to the point (x, y), measured counterclockwise
>         from the positive x axis.  A domain error may occur if both
>         arguments are zero.
>
> But it does not; it specifically mentions division of y by x, and
> division by zero is undefined unless annex F is in force.

That's what I suggested in another posting of mine.

Or, to avoid mentioning geometrical things, we could define
atan2(y, x) like this:

    atan2(y, x) returns the angle a in the range (-pi, +pi]
    such that cos(a)==x/hypot(x, y) and sin(a)==y/hypot(x, y).

I'd like to add that it seems very unclear to me how that definition
can explain what atan2(-1, -1) should return. It mentions "arc tangent
of y/x" so atan2(-1, -1) and atan2(+1, +1) are not distinguished.
The phrase "using the signs of both arguments to determine the quadrant
of the return value" does not describe how in detail.

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

KIM Seungbeom wrote:
> The phrase "using the signs of both arguments to determine
 > the quadrant of the return value" does not describe how in
 > detail.

We assume implementors will have taken Algebra II in high
school.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

KIM Seungbeom wrote:
> Mathematically, we can say for some function f that
> lim_{x->-0} f(x) != lim_{x->+0} f(x), but not f(-0) != f(+0).

arctangent is a "multiple-valued" function, and some
convention is needed to turn it into a single-valued
function.  Conventionally this is done with a cut ray
along the negative x axis.  Therefore there is a
discontinuity for the single-valued function across
the negative x axis.  Which if either of the two
obvious values is picked for a point "on" the axis
is another arbitrary choice.  The C standard allows
either to be picked, and there needn't be consistency
(although in practice one would expect it).

> Would it be correct to say sgn(-0), sgn(0), sgn(+0)
 > should be -1, 0, 1, respectively? ;-)

Possibly; you need to check what the IEEE/IEC f.p.
standard specifies.  Note that there is no "unsigned"
f.p. zero in the IEEE/IEC scheme.

> So, is the negative zero different from the positive
 > zero?

Certainly.

> (We are not talking about limiting values which imply
 > direction.)

One could argue that that is implicit when using -0 vs.
+0.

> If we want to treat them as the same values, as they
 > are currently compared by the relational and equality
 > operators, I think atan2(-0.0, -1.0) should be the same
 > as atan2(+0.0, -1.0).

The IEEE/IEC f.p. community would disagree with you.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> KIM Seungbeom wrote:
> > I cannot even figure out what the negative zero is
> > supposed to represent in real life and mathematics..

DAGwyn@null.net ("Douglas A. Gwyn") wrote
> It's the reciprocal of -Infinity, for example.

Beg to differ. In real life and in algebra, there IS no reciprocal
of -Infinity.

The closest you can get is first-semester Calculus, which states
that as x approaches -Infinity, 1/x increases towards 0. I don't
think that was ever called -0, though.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

DAGwyn@null.net ("Douglas A. Gwyn") wrote
> KIM Seungbeom wrote:
> > The phrase "using the signs of both arguments to determine
>  > the quadrant of the return value" does not describe how in
>  > detail.
>
> We assume implementors will have taken Algebra II in high
> school.

Meaning that the standard should be allowed to describe the
workings of the trig functions in terms of standard mathematical
terms, I assume. In which case, we can also assume that users
will have taken Algebra II (and/or Trigonometry, as appropriate).

I see this as a practical neccessity -- we cannot expect the C or
C++ standards to include a tutorial on Trigonometry. (Perhaps by
reference, but not directly!).

But that assumption still does not describe "the quadrant of the
return value" in detail, not with the current wording which uses
division -- presumably to indicate the slope of the line.
Which also indicates why we can't ever take the arc-tangent of
a line without a slope (delta-x is 0)!

Please also note that a line is not a (mathematical) vector --
it indicates an infinite series of points on (in this case) a
Euclidian (2-dimensional) plane, but does not indicate a direction.
All lines with nonzero slope pass through two quadrants, not one!
The current standard attempts to resolve this by limiting the return
value to [-pi,+pi]. Even if we replace the reference to division
with a reference to slope, that alone won't resolve what the expected
result will be for lines with no slope.

How about:

    The atan2 functions compute the principal value of the arc tangent
    of a line with slope y/x in the first or fourth quadrant. The
    return value is always greater than -pi, and less than or equal to
    +pi. If y==0, then the return value is 0; if x==0 (indicating a
    line with no slope), then the return value is +pi.

Does that express what everyone both wants and expects?

If we really wanted to be precise, we would use the lowercase Greek
letter "pi" instead of the two-letter spelling, so as to avoid the
false implication that the language has a keyword which returns this
value. AFAIK, every branch of mathematics uses this same Greek letter
to represent this same value, so there is no significant risk of
being misinterpreted.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

musiphil@bawi.org (KIM Seungbeom) wrote
> Would it be correct to say sgn(-0), sgn(0), sgn(+0) should be
> -1, 0, 1, respectively? ;-)

I hope not!

*shudder*

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
>>KIM Seungbeom wrote:
>>
>>>I cannot even figure out what the negative zero is
>>>supposed to represent in real life and mathematics..
>>
>
> DAGwyn@null.net ("Douglas A. Gwyn") wrote
>
>>It's the reciprocal of -Infinity, for example.
>
>
> Beg to differ. In real life and in algebra, there IS no reciprocal
> of -Infinity.
 >
> The closest you can get is first-semester Calculus, which states
> that as x approaches -Infinity, 1/x increases towards 0. I don't
> think that was ever called -0, though.

That's only a peculiarity of notation; when I learned about 1-sided
limits, the notation usually used was

 lim
 x->0-

where '-' was a superscript. Given the context of IEEE arithmetic,
"-0.0" strikes me as an entirely reasonable notation for that same concept.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <7f2735a5.0301061812.2daf4449@posting.google.com>
allan_w@my-dejanews.com (Allan W) writes:

>How about:
>
>    The atan2 functions compute the principal value of the arc tangent
>    of a line with slope y/x in the first or fourth quadrant. The
>    return value is always greater than -pi, and less than or equal to
>    +pi. If y==0, then the return value is 0; if x==0 (indicating a
>    line with no slope), then the return value is +pi.
>
>Does that express what everyone both wants and expects?

       atan2 is a four-quadrant function.  Given arguments x and y,
not both zero, it returns (an approximation of) an angle theta,
-pi <= theta <= pi, such that

         cos(theta) = x/sqrt(x*x + y*y)
         sin(theta) = y/sqrt(x*x + y*y)

It is important that the signs of cos(theta) and sin(theta) match those
of x and y.
--
A local drug store selling wine boasts a drug and alcohol free workplace.
A local grocery store advertises Hot Buys even on frozen foods.
        Peter-Lawrence.Montgomery@cwi.nl    Home: San Rafael, California
        Microsoft Research and CWI

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
> But that assumption still does not describe "the quadrant of the
> return value" in detail, not with the current wording which uses
> division -- presumably to indicate the slope of the line.
> Which also indicates why we can't ever take the arc-tangent of
> a line without a slope (delta-x is 0)!

(1) The proper quadrant is evident to anyone with standard
training in basic trig, from the use of menmonics "x" and "y"
for the arguments.  We could have said "principle angle" but
thought that what we said instead is just as clear to anybody
who has any business implementing or using this function.

(2) The argument to arctangent is a number, not a line.  The
number can be, but needn't be, thought of as the slope of
some line.  Vertical lines do have slope, +-Infinity (which
is a single point on the Riemann sphere).  This is standard
mathematical practice, and the corresponding angle (thus the
result of the arctangent function) is evident.  (Always
modulo the directional ambiguity that use of atan2
resolves.)

> Please also note that a line is not a (mathematical) vector --
> it indicates an infinite series of points on (in this case) a
> Euclidian (2-dimensional) plane, but does not indicate a direction.
> All lines with nonzero slope pass through two quadrants, not one!

Any line in the plane has a set of associated directions that
differ by integer multiples of Pi.  For the single-argument
arctangent, *one* of this set is chosen for the result,
called the "principle angle".  For the two-argument atan2,
*one* of this set is chosen for the result, called the
"principle angle".  The difference is that atan2's range of
princple angles is twice that of the one-argument atan.

> The current standard attempts to resolve this by limiting the return
> value to [-pi,+pi].

That merely indicates the conventional range of principle
angles that can be result from atan2.

> Even if we replace the reference to division with a reference
> to slope, that alone won't resolve what the expected result
> will be for lines with no slope.

I don't think there is any need to refer to geometric terms
in the specification.  In fact I don't think there is any
problem understanding the specification, assuming one has
had standard mathematical training at the high-school level.
Although this may have changed (in the US anyway) in recent
years; yesterday I asked a high-school math teacher what
students were being taught about vertical lines, and she
said that they were being taught that they had "no slope";
infinity is never mentioned.  One wonders how these guys are
ever going to apply IEEE/IEC f.p. if they have no knowledge
of the use of infinity in an extension of the real number
system.

> How about:
>     The atan2 functions compute the principal value of the arc tangent
>     of a line with slope y/x in the first or fourth quadrant.

No!  The result can be in any quadrant.  You are being
befuddled by thinking of one-argument arctangent as a
single-valued function.

> If we really wanted to be precise, we would use the lowercase Greek
> letter "pi" instead of the two-letter spelling, so as to avoid the
> false implication that the language has a keyword which returns this
> value.

The C standard *does* use the Greek character.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
> Beg to differ. In real life and in algebra, there IS no reciprocal
> of -Infinity.
> The closest you can get is first-semester Calculus, which states
> that as x approaches -Infinity, 1/x increases towards 0. I don't
> think that was ever called -0, though.

(1) There is a reciprocal of -Infinity, if one *has* -Infinity
in one's extension of the real number system in the first place.
That reciprocal is precisely -0.  Whether this is also equal to
+0 depends on other matters.

(2) Standard terminology for approaching 0 from below is arrow 0-
and IEEE/IEC usage of signed zero is inspired by this model.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Pine.LNX.4.44L-027.0301021343140.8879-100000@unix45.andrew.cmu.edu>,
Arthur J. O'Dwyer <ajo@andrew.cmu.edu> wrote:
>All posters so far have skirted around the obvious reason:
>according to the literal word of the Standard, atan2(0,-1.)
>is allowed to produce an undefined result!

So it is.  Thanks; this had escaped me.

Clearly there's no point in guarding the call with __STDC_IEC_559__:

#ifdef __STDC_IEC_559__   /* silly */
  pi = atan2(0.0, -1.0);
#endif


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Mark Jason Dominus wrote:
> Arthur J. O'Dwyer <ajo@andrew.cmu.edu> wrote:
>>All posters so far have skirted around the obvious reason:
>>according to the literal word of the Standard, atan2(0,-1.)
>>is allowed to produce an undefined result!
> So it is.  Thanks; this had escaped me.

Wrong, atan2() has a defined result for all argument pairs.
Technically there is a choice of -Pi or Pi for that example,
but it has to be one or the other (within f.p. tolerance).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 5 Jan 2003, "Douglas A. Gwyn" wrote:
>
> Mark Jason Dominus wrote:
> > Arthur J. O'Dwyer <ajo@andrew.cmu.edu> wrote:
> >>All posters so far have skirted around the obvious reason:
> >>according to the literal word of the Standard, atan2(0,-1.)
> >>is allowed to produce an undefined result!
> > So it is.  Thanks; this had escaped me.
>
> Wrong, atan2() has a defined result for all argument pairs.
> Technically there is a choice of -Pi or Pi for that example,
> but it has to be one or the other (within f.p. tolerance).

Can you point to any place in the Standards (C99 and C++) where
this is stated?  [I only have access to the drafts, which I
realize are not the current versions, and I'd be glad to hear
if they've patched this hole.]

The N869 draft explicitly refers to atan(y/x) in the definition
of atan2(y,x), and explicitly states that division by zero is
undefined.

-Arthur


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Mark Jason Dominus wrote:
>
> In article <3E13D72D.3B04C5C8@bawi.org>,
> KIM Seungbeom <musiphil@bawi.org> wrote:
> >Moreover, looking only at the definition in the standard, it's
> >not very clear whether atan2(0.0, -1.0) should return pi or -pi,
> >because return values in the range [-pi, pi] are allowed.
>
> 7.3.3#2 seems clear to me.
>
> >IMO the return range should have been (-pi, pi]. Anyone knows
> >why the range was chosen to be [-pi, pi], not (-pi, pi]?
>
> On implementations that support negative 0,
>
>         atan2(-0.0, -1.0)
>
> returns -pi.

Wow, it really does! I'm surprised.

Then, in what ways should the negative zero be different from
the positive zero? They are compared equal by the relational
and equality operators, so we have a==b but f(a)!=f(b) (where
a=0.0, b=-0.0, f(x)=atan2(x, -1.0)). Isn't it confusing?

I cannot even figure out what the negative zero is supposed to
represent in real life and mathematics..

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

KIM Seungbeom wrote:
> ... Isn't it confusing?

It can be.

> I cannot even figure out what the negative zero is
 > supposed to represent in real life and mathematics..

It's the reciprocal of -Infinity, for example.
There are several ways to extend the real-number system,
and this is the one that was chosen for the IEEE/IEC
floating-point standard.  C99 accommodates, but does not
require, that standard.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

musiphil@bawi.org (KIM Seungbeom) writes:

> Then, in what ways should the negative zero be different from the
> positive zero? They are compared equal by the relational and
> equality operators, so we have a==b but f(a)!=f(b) (where a=0.0,
> b=-0.0, f(x)=atan2(x, -1.0)). Isn't it confusing?

atan2 has a discontinuity at 0 for the first argument. positive 0
gives one side of the discontinuity, negative 0 the other side.

> I cannot even figure out what the negative zero is supposed to
> represent in real life and mathematics..

It's only usefullness is when computing the value of functions which
have a discontinuity at 0 where it allows to get the values on the two
side.  Too much a special case to be anything other than a hack.

A+

--
Jean-Marc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3E13D72D.3B04C5C8@bawi.org>,
KIM Seungbeom <musiphil@bawi.org> wrote:
>Moreover, looking only at the definition in the standard, it's
>not very clear whether atan2(0.0, -1.0) should return pi or -pi,
>because return values in the range [-pi, pi] are allowed.

7.3.3#2 seems clear to me.

>IMO the return range should have been (-pi, pi]. Anyone knows
>why the range was chosen to be [-pi, pi], not (-pi, pi]?

On implementations that support negative 0,

        atan2(-0.0, -1.0)

returns -pi.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 2 Jan 2003, "Douglas A. Gwyn" wrote:
>
> Allan W wrote:
> > mjd@plover.com (Mark Jason Dominus) wrote
> >>        pi = atan2(0., -1.);
> > According to Dinkumware.com, atan2(x,y) "returns the angle whose tangent
> > is y/x, in the full angular range [-pi, +pi] radians."
>
> And also is in the correct quadrant when (x,y) is interpreted
> as Cartesian coordinates.

According to the C99 draft standard, but not according to Dinkumware.
I suspect that Dinkumware merely overlooked that part, _not_ that
their library is broken.

> >     atan2(0,x)=0
>  > for all x.
>
> No, only for positive x.  atan(0,x)=pi for negative x.

Last time I checked, x/0 was _undefined_ for all x, positive
or negative.  ITYM atan2(x,0)==0 for all positive x.

> It is actually arguable whether that should be -pi or pi,
> since it falls right on the cut line.  That's the kind
> of problem we avoid by using pi = 4. * atan2(1., 1.).

All posters so far have skirted around the obvious reason:
according to the literal word of the Standard, atan2(0,-1.)
is allowed to produce an undefined result!

Both of my compilers get it right (3.141593), but quite
conceivably there may exist some system with a very low
QoI quotient on which atan2(0,-1.) produces undefined
behaviour.  I seem to recall having problems with other
languages along these lines -- languages that define
atan2 in the same way the Standard does:

double atan2(double x, double y)
{
  if (x==0 && y==0) cause_domain_error();
  return atan(y/x);
}


There is no potential UB when defining pi as 4*atan2(1.,1.).
That is why it's done that way.

-Arthur

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

KIM Seungbeom wrote:
> why the range was chosen to be [-pi, pi], not (-pi, pi]?

To support implementations that have a "negative zero".

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 2 Jan 2003, "Douglas A. Gwyn" wrote:
>
> Allan W wrote:
> > mjd@plover.com (Mark Jason Dominus) wrote
> >>        pi = atan2(0., -1.);
> > According to Dinkumware.com, atan2(x,y) "returns the angle whose tangent
> > is y/x, in the full angular range [-pi, +pi] radians."
>
> And also is in the correct quadrant when (x,y) is interpreted
> as Cartesian coordinates.

Whoops!  My last post was factually incorrect.
You should have written, atan2(y,x) returns atan(y/x);
NOT atan2(x,y) returns atan(y/x).

So my swapping of Douglas's and Alan's function arguments was
incorrect.  However, the potential UB I point out still exists,
and my reasoning as to the prevalence of 4*atan2(1.,1.) still
holds.

Sorry about that, guys.

-Arthur

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Arthur J. O'Dwyer wrote:
> Last time I checked, x/0 was _undefined_ for all x, positive
> or negative.  ITYM atan2(x,0)==0 for all positive x.

No, I meant what I said.  Perhaps you missed that the
arguments are given in y,x order.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

mjd@plover.com (Mark Jason Dominus) wrote
> Why do people invariably use
>
>         pi = 4. * atan2(1., 1.)
>
> rather than
>
>         pi = atan2(0., -1.);

Couldn't the second expression yield 0.0?

According to Dinkumware.com, atan2(x,y) "returns the angle whose tangent
is y/x, in the full angular range [-pi, +pi] radians."

If I remember my high-school trig properly (and I'm not certain that I
do!):
    sin(0)=0 and cos(0)=1
and therefore
    tan(0)=0
which means that
    atan2(0,x)=0
for all x.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Mark Jason Dominus wrote:
> Why do people invariably use
>         pi = 4. * atan2(1., 1.)
> rather than
>         pi = atan2(0., -1.);
> ?

We like to avoid singular points.
Sometimes this produces a more accurate value.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 26 Dec 2002 02:40:13 CST, mjd@plover.com (Mark Jason
Dominus) wrote:

>In article <3DDBF2AF.3EB1DF91@null.net>,
>Douglas A. Gwyn <DAGwyn@null.net> wrote:
>>What most of us have done in the interim is to compute our
>>own, e.g. if (!init) pi = 4.*atan2(1.,1.);
>
>Why do people invariably use
>
>        pi = 4. * atan2(1., 1.)
>
>rather than
>
>        pi = atan2(0., -1.);
>
>?

Fortran or other early versions used by numerical analysts or
engineers may only have worked accurately, portably, reliably,
and quickly with arguments in the domain [-1,1] giving results in
the range [-pi/2,pi/2] so pi/4 was passed along as the standard
form to use in programs.
This was then used in C, where the math library was not really
documented until the first Standard was produced in 1989.
GNU gcc libc info for atan2() uses the latter expression as an
example.

Thanks. Take care, Brian Inglis  Calgary, Alberta, Canada
--
Brian.Inglis@CSi.com  (Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address  use address above to reply
abuse@aol.com tosspam@aol.com abuse@att.com abuse@earthlink.com
abuse@hotmail.com abuse@mci.com abuse@msn.com abuse@sprint.com
abuse@yahoo.com abuse@cadvision.com abuse@shaw.ca abuse@telus.com
abuse@ibsystems.com uce@ftc.gov    spam traps

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
>
> mjd@plover.com (Mark Jason Dominus) wrote
> > Why do people invariably use
> >
> >         pi = 4. * atan2(1., 1.)
> >
> > rather than
> >
> >         pi = atan2(0., -1.);
>
> Couldn't the second expression yield 0.0?
>
> According to Dinkumware.com, atan2(x,y) "returns the angle whose tangent
> is y/x, in the full angular range [-pi, +pi] radians."
>
> If I remember my high-school trig properly (and I'm not certain that I
> do!):
>     sin(0)=0 and cos(0)=1
> and therefore
>     tan(0)=0
> which means that
>     atan2(0,x)=0
> for all x.

No, it's true only for positive values of x.
0 is not the only value of x that makes tan(x) zero:
any integral multiples of pi will do.
(Even integral multiples corresponds to positive values of x
and odd integral multiples to negative values of x.)

I think the definition of atan2(y, x) in the standard

    The atan2 functions compute the value of the arc tangent
    of y/x, using the signs of both arguments to determine
    the quadrant of the return value.

is not very clear - what does "the quadrant of the return value"
mean? It is also wrong in that it mentions "y/x" while x may be 0.
It would have been more correct and clear to define atan2(y, x)
as the argument(also called the phase angle) of the point (x, y).

Moreover, looking only at the definition in the standard, it's
not very clear whether atan2(0.0, -1.0) should return pi or -pi,
because return values in the range [-pi, pi] are allowed.
IMO the return range should have been (-pi, pi]. Anyone knows
why the range was chosen to be [-pi, pi], not (-pi, pi]?

This may explain why "pi = atan2(0.0, -1.0)" is not commonly used.
In addition to "4.0 * atan2(1.0, 1.0)", "2.0 * atan2(0.0, 1.0)"
is equally correct, but the order of the arguments to atan2 may be
confusing("Why not atan2(x, y)?"), so it is safer to stick to the
former where the order of the arguments doesn't matter.

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
> mjd@plover.com (Mark Jason Dominus) wrote
>>        pi = atan2(0., -1.);
> According to Dinkumware.com, atan2(x,y) "returns the angle whose tangent
> is y/x, in the full angular range [-pi, +pi] radians."

And also is in the correct quadrant when (x,y) is interpreted
as Cartesian coordinates.

>     atan2(0,x)=0
 > for all x.

No, only for positive x.  atan(0,x)=pi for negative x.
It is actually arguable whether that should be -pi or pi,
since it falls right on the cut line.  That's the kind
of problem we avoid by using pi = 4. * atan2(1., 1.).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 Please do keep any followups on-topic for comp.std.c++,
or take them to another forum.



===================================== END OF MODERATOR'S COMMENT
On Thu, 26 Dec 2002 02:40:13 CST,
 Mark Jason Dominus <mjd@plover.com> wrote:
> In article <3DDBF2AF.3EB1DF91@null.net>,
> Douglas A. Gwyn <DAGwyn@null.net> wrote:
>>What most of us have done in the interim is to compute our
>>own, e.g. if (!init) pi = 4.*atan2(1.,1.);
>
> Why do people invariably use
>
>         pi = 4. * atan2(1., 1.)
>
> rather than
>
>         pi = atan2(0., -1.);
>
> ?

Hi mjd,

I believe we've both been involved in a discussion about this exact same
question, then raised by Randal Schwartz, on comp.lang.perl.misc, and it
wasn't the first time that came up there either.

Just for reference, there were some opinions offered back then about
possible reasons for this phenomenon. Randal's post had the message ID
<9f14b8f2.0204211843.2d315200@posting.google.com>, several messages
hanging off that, including one of you and one of me, give possible
reasons.

Martien
--
                        |
Martien Verbruggen      | Since light travels faster than sound, isn't
                        | that why some people appear bright until you
                        | hear them speak?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3DDBF2AF.3EB1DF91@null.net>,
Douglas A. Gwyn <DAGwyn@null.net> wrote:
>What most of us have done in the interim is to compute our
>own, e.g. if (!init) pi = 4.*atan2(1.,1.);

Why do people invariably use

        pi = 4. * atan2(1., 1.)

rather than

        pi = atan2(0., -1.);

?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Kuyper Jr.") writes:

> Jun Woong wrote:
> ....
> > We also have the international standards for the units. The unit
> > problem is completely resolved by referring to those standard as
> > normative references implicitly or explicitly.
>
> The US remains an island of non-conformity to those standards, and in
> economic terms it's far too big of an island to ignore. I doubt that a C
> or C++ standard that endorsed physical constants in metric units, rather
> than English ones, would go over well with US industries.

I disagree.  Even in the US, all science and much engineering is done
using SI units.  As long as conversion to "English" units was
relatively straightforward, I can't see the US standing in the way of
standardizing on SI units for constants in C++.

--
Eric Backus
R&D Design Engineer
Agilent Technologies, Inc.
425-335-2495 Tel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

krlynch@bu.edu (Kevin Lynch) wrote:
>
> For example, even in the SI, there is no PHYSICAL reason, other than
> historical convention, to have different base units for length and time
> ... special relativity tells us that they are the same physical thing.

Although the metre is still called one of the base units of SI, I don't
think it counts as such any more since it is currently defined in terms
of the second and the speed of light.

Tony.
--
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: SOUTHEASTERLY 4 OR 5 INCREASING 6 OR 7. OCCASIONAL
RAIN. MODERATE.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andy Sawyer schrieb:

> In article <as0sjt$cns$1@news3.bu.edu>,
>  on Tue, 26 Nov 2002 22:42:28 +0000 (UTC),
>  krlynch@bu.edu (Kevin Lynch) wrote:
>
> > The only extensible C solution I can think of would require more
> > functions (rsin for radians, dsin for degrees) The horrible
> > combinatorial explosion of necessary functions is mindblowingly
> > scary stuff (rsin, rsinf, rsind, rsinl, dsin, dsinf, dsind, dsinl,
> > etc. etc. etc....)
>
> Which is why we carry on using the same, simple, well known and well
> understood technique that we've been using for umpteen years. We use
> radians as the units for arguments to (and results from) trigonometric
> functions. The combinatorial explosion" doesn't happen, since we just
> add a couple of functions "deg_to_rad"/"rad_to_deg" (or whatever you
> want to call them) which then work fine for arguments to trig
> functions and results from their inverses.

But do we all our arithmetic in long double and convert back and forth when
required?

I hope not, and don't want to be limited to radians for calculating
trig-functions.


regards.

Thomas


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
....
>     // More accurate than anyone is likely to need -- but it won't
>     // compile everywhere, will it?
>     sin(90.0 * 3.141592653589793238462643383279 / 180.0);

Why not? The C/C++ standards don't impose an upper limit on the number
of digits after the decimal point in a floating point constant(C) or
literal(C++), and I can't think of any reason why they would need to.
The algorithms I'm aware of for converting digit strings to floating
point numbers will work to the required level of precision with
arbitrarily long strings, as long as they're of finite length.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andy Sawyer schrieb:

> In article <7f2735a5.0211251834.76369715@posting.google.com>,
>  on Tue, 26 Nov 2002 03:53:16 +0000 (UTC),
>  allan_w@my-dejanews.com (Allan W) wrote:
>
> > >  allan_w@my-dejanews.com (Allan W) wrote:
> > > > Find some high school or college students who have taken geometry but
> > > > not yet trig. Try to tell them how to get sin(90.0) equal to 1.0,
> > > > using only portable code.
> >
> > news@evo6.com (Andy Sawyer) wrote
> > > You'll have a hard time, since sin(90.0) doesn't equal 1.0 (at least,
> > > not in the universe I live in) - the argument to sin is expressed in
> > > radians, and 90 radians do not a right angle make.
> >
> > That was exactly my point.
>
> Cleverly obscured by the fact that I knew this before I attended
> grammar school (which, agewise, is roughly the equivalent of what you
> mean by high school).
>
>  So exactly how _do_ you get sin(90.0) equal to 1.0?  (as opposed to
> sin(90.0 * pi / 180.0) being equal to 1.0?)
>
> Of course, we could have do something like: std::rad::sin,
> std::deg::sin and std::grad::sin which all calculate sin but use
> different units of angular measurement - no, this isn't a serious
> suggestion.

A serious soluting would be to pass in a second argument to sin, that determines
the unit of angular measurement.
A very simple enumeration could do this quite fine, with a default-value to
support current code.


cheers,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

news@evo6.com (Andy Sawyer) wrote in message news:<k7j1j5g8.fsf@ender.evo6.com>...
> In article <3DE2C286.7030204@wizard.net>,
>  on Tue, 26 Nov 2002 03:52:30 +0000 (UTC),
>  kuyper@wizard.net ("James Kuyper Jr.") wrote:
>
> > Jun Woong wrote:
> > ....
> > > We also have the international standards for the units. The unit
> > > problem is completely resolved by referring to those standard as
> > > normative references implicitly or explicitly.
> >
> > The US remains an island of non-conformity to those standards, and in
> > economic terms it's far too big of an island to ignore. I doubt that a
> > C or C++ standard that endorsed physical constants in metric units,
> > rather than English ones, would go over well with US industries.
>
> I doubt "English" units would suffice - you'd want "US Imperial" unit
> (which are, in some cases, different to "British Imperial").
>
> Regards,
>  Andy S.

The nonmetric U.S. units are not imperial.  They are English (except
for things like some old land records in the Southwest, with distances
in varas and the like).

Gene Nygaard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Thomas Mang wrote:
>
>
> A serious soluting would be to pass in a second argument to sin, that determines
> the unit of angular measurement.
> A very simple enumeration could do this quite fine, with a default-value to
> support current code.
>
>

That's not an extensible solution, however.  If I add a "bignum" type
(or struct), I have a different interface to the library, since I can't
modify the enumeration to include my new type.

I think that a better C++ solution would be to (templated) math
functions/classes with overloads/specializations for units classes.  The
correct implementation would be chosen by the compiler using the same
syntax as you are currently used to, and you wouldn't have to clutter
the interface with implementation details.  The current functions would
be unaltered.

Degrees<double> d = 90.;
Radians<double> r = pi/2.;
double degresult = sin(d);
double radresult = sin(r);

which would call sin( Degrees<double>& x) or sin( Radians<double>& x).

The only extensible C solution I can think of would require more
functions (rsin for radians, dsin for degrees)  The horrible
combinatorial explosion of necessary functions is mindblowingly scary
stuff (rsin, rsinf, rsind, rsinl, dsin, dsinf, dsind, dsinl, etc. etc.
etc....)

--
-------------------------------------------------------------------------------
Kevin Lynch    voice: (617) 353-6025
Physics Department   Fax: (617) 353-9393
Boston University   office:  PRB-361
590 Commonwealth Ave.   e-mail:  krlynch@bu.edu
Boston, MA 02215 USA   http://budoe.bu.edu/~krlynch
-------------------------------------------------------------------------------

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In message <df336888.0211261429.3db618c0@posting.google.com>, Gene
Nygaard <gnygaard@nccray.com> writes
>> I doubt "English" units would suffice - you'd want "US Imperial" unit
>> (which are, in some cases, different to "British Imperial").
>>
>> Regards,
>>  Andy S.
>
>The nonmetric U.S. units are not imperial.  They are English (except
>for things like some old land records in the Southwest, with distances
>in varas and the like).

Funny, I thought they were US. I am certainly used to writing about US
gallons, pints, cups etc. versus Imperial gallons ...


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <df336888.0211261429.3db618c0@posting.google.com>,
 on Tue, 26 Nov 2002 22:36:55 +0000 (UTC),
 gnygaard@nccray.com (Gene Nygaard) wrote:

> news@evo6.com (Andy Sawyer) wrote in message
> news:<k7j1j5g8.fsf@ender.evo6.com>...
> > In article <3DE2C286.7030204@wizard.net>,
> >  on Tue, 26 Nov 2002 03:52:30 +0000 (UTC),
> >  kuyper@wizard.net ("James Kuyper Jr.") wrote:
> >
> > > Jun Woong wrote:
> > > ....
> > > > We also have the international standards for the units. The unit
> > > > problem is completely resolved by referring to those standard as
> > > > normative references implicitly or explicitly.
> > >
> > > The US remains an island of non-conformity to those standards, and in
> > > economic terms it's far too big of an island to ignore. I doubt that a
> > > C or C++ standard that endorsed physical constants in metric units,
> > > rather than English ones, would go over well with US industries.
> >
> > I doubt "English" units would suffice - you'd want "US Imperial" unit
> > (which are, in some cases, different to "British Imperial").
> >
> > Regards,
> >  Andy S.
>
> The nonmetric U.S. units are not imperial.  They are English (except
> for things like some old land records in the Southwest, with distances
> in varas and the like).

They're certainly not English - since an English Pint is the same size
as a British Pint. A US pint, on the other hand, is smaller.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote:
>
>Funny, I thought they were US. I am certainly used to writing about US
>gallons, pints, cups etc. versus Imperial gallons ...

The US gallon has the same definition as one of the pre-Imperial English
gallons; the avoirdupois weights are supposed to be the same, as are the
lengths based on the international inch.

Tony.
--
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
THE MULL OF GALLOWAY TO MULL OF KINTYRE INCLUDING THE FIRTH OF CLYDE AND THE
NORTH CHANNEL: SOUTHEAST 6 OR 7 INCREASING GALE 8 LATER. RAIN AT TIMES.
MODERATE OR GOOD. MODERATE OR ROUGH.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Kevin Lynch schrieb:

> Thomas Mang wrote:
> >
> >
> > A serious soluting would be to pass in a second argument to sin, that determines
> > the unit of angular measurement.
> > A very simple enumeration could do this quite fine, with a default-value to
> > support current code.
> >
> >
>
> That's not an extensible solution, however.  If I add a "bignum" type
> (or struct), I have a different interface to the library, since I can't
> modify the enumeration to include my new type.
>
> I think that a better C++ solution would be to (templated) math
> functions/classes with overloads/specializations for units classes.  The
> correct implementation would be chosen by the compiler using the same
> syntax as you are currently used to, and you wouldn't have to clutter
> the interface with implementation details.  The current functions would
> be unaltered.
>
> Degrees<double> d = 90.;
> Radians<double> r = pi/2.;
> double degresult = sin(d);
> double radresult = sin(r);
>
> which would call sin( Degrees<double>& x) or sin( Radians<double>& x).

Maybe a template function taking 2 arguments: The value, and a (default) calcualtion
functor.

template <typename T, class Func = rad_sin<T> >
T sin(T value, Func functor = Func())
{
  return functor(value);
}

NOTE: I know the code above is illegal, because of a default-template in
template-function. Wrote it that way to show what Func could be.

Here it's also simple to calculate the sin of other but the built-in types.

This doesn't solve the C - problem, of course.


regards,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <as0sjt$cns$1@news3.bu.edu>,
 on Tue, 26 Nov 2002 22:42:28 +0000 (UTC),
 krlynch@bu.edu (Kevin Lynch) wrote:

> The only extensible C solution I can think of would require more
> functions (rsin for radians, dsin for degrees) The horrible
> combinatorial explosion of necessary functions is mindblowingly
> scary stuff (rsin, rsinf, rsind, rsinl, dsin, dsinf, dsind, dsinl,
> etc. etc. etc....)

Which is why we carry on using the same, simple, well known and well
understood technique that we've been using for umpteen years. We use
radians as the units for arguments to (and results from) trigonometric
functions. The combinatorial explosion" doesn't happen, since we just
add a couple of functions "deg_to_rad"/"rad_to_deg" (or whatever you
want to call them) which then work fine for arguments to trig
functions and results from their inverses.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Gene Nygaard" <gnygaard@nccray.com> wrote...
>
> The nonmetric U.S. units are not imperial.  They are English (except
> for things like some old land records in the Southwest, with distances
> in varas and the like).

To clarify, it is the British who no longer use "English" units, having
standardised (changed) them into "Imperial" ones in the Victorian
period. Much the same argument can be made for the language, of course.

Back on topic, I suspect that all regions of the world have "domestic"
unit systems, all with different actual sizes, but in most cases they
are only of historical interest. Still, I think you are getting
political if you offer to support anything beyond SI.

Stepping back, one could conceive of locale facets which read and wrote
(binary) SI values as (text) local measures. The "magic numbers" for
converting one way and the other would then be hidden in library code
and we wouldn't have to think of names for them or use them ourselves.
This is what I do in my own programs.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> wrote in message
>      I'd argue for a standardized name for the value of "pi", at
> least.

James Kanze <kanze@gabi-soft.de> wrote:
>And that the symbol name should be std::\u03C0, of course.

I wish I knew if you were serious or not.

      Ross Ridge

--
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/u/rridge/
 db  //

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ken Hagan wrote:
> Back on topic, I suspect that all regions of the world have "domestic"
> unit systems, all with different actual sizes, but in most cases they
> are only of historical interest. Still, I think you are getting
> political if you offer to support anything beyond SI.
>

But this ignores an issue that I tried to bring up in a post that never
appeared ... the SI system of units is NOT the only unit system you
might want to consider.  For example, even in the SI, there is no
PHYSICAL reason, other than historical convention, to have different
base units for length and time ... special relativity tells us that they
are the same physical thing.  In fact particle physics uses just such a
system, which results in mass, energy, momentum, and a whole host of
other quantities have the same units as inverse length.  There are other
fields with their own unit systems (astrophysics and cosmology come to
mind, but I'm sure there are others.  This is just to point out that the
seven "fundamental" physical quantities of the SI are not in any way the
  "correct" choice of quantities for all fields.  And the SI doesn't
even begin to touch on quantity and unit matters of interest to the
financial sector.

There is no reason for the C++ standard to impose SI (or any other
system) on users.  But I would be VERY happy if the standard provided a
library that allowed user definition of quantities and unit systems
which automatically handled (or provided the tools to handle) derived
units, conversions, and I/O.  I haven't yet seen a proposal,
unfortunately, that meets these objectives.

And I wouldn't even begin to hope that C would be able to handle this
issue gracefully.


--
-------------------------------------------------------------------------------
Kevin Lynch    voice: (617) 353-6025
Physics Department   Fax: (617) 353-9393
Boston University   office:  PRB-361
590 Commonwealth Ave.   e-mail:  krlynch@bu.edu
Boston, MA 02215 USA   http://budoe.bu.edu/~krlynch
-------------------------------------------------------------------------------

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> > >  allan_w@my-dejanews.com (Allan W) wrote:
> > > > Find some high school or college students who have taken geometry but
> > > > not yet trig. Try to tell them how to get sin(90.0) equal to 1.0,
> > > > using only portable code.

> > news@evo6.com (Andy Sawyer) wrote
> > > You'll have a hard time, since sin(90.0) doesn't equal 1.0 (at least,
> > > not in the universe I live in) - the argument to sin is expressed in
> > > radians, and 90 radians do not a right angle make.

>  allan_w@my-dejanews.com (Allan W) wrote:
> > That was exactly my point.

news@evo6.com (Andy Sawyer) wrote
> Cleverly obscured by the fact that I knew this before I attended
> grammar school (which, agewise, is roughly the equivalent of what you
> mean by high school).

> > So you have to multiply (or divide) 90.0 by some constant -- but
> > what's the constant
>
> Last time I studied maths, I multiplied by pi / 180.0.

You're still missing my point. If the problem domain has to use sin() or
cos(), then we can assume that they know what a degree and a radian are.
We can even assume that they know how to translate back and forth (on
their $3 calculators). It would be easy enough to tell them to use
    sin(90.0 * std::math::pi / 180.0);
if C++ had such a constant. But it doesn't. So what's the alternative?

    // How accurate is this? About 2 decimal places.
    sin(90.0 * 22.0 / 7.0 / 180.00);

    // Accurate to 4 decimal places, still far less than most computers
    // are capable of
    sin(90.0 * 3.142 / 180.0);

    // Accurate to 6 decimal places:
    sin(90.0 * 3.14159 / 180.0);

    // More accurate than anyone is likely to need -- but it won't
    // compile everywhere, will it?
    sin(90.0 * 3.141592653589793238462643383279 / 180.0);

I'd like the library to define pi to as much detail as the current
implementation will support.

> > This justifies the definition of std::math::pi.
>
> Clearly not, in and of itself.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 25 Nov 2002 17:26:51 +0000 (UTC), news@evo6.com (Andy Sawyer)
wrote:

[...]
>
>But the "Giga" in "my 120GB hard drive" is often different to the
>"Giga" in "my 120 Gigiwatt laser". One of them is 1e9, and the other
>is 2^30. (A problem compounded by the fact that programmers think in
>binary whilst marketing droids think in SI.)

The IEC has come up with a solution for that.  Your "120GB hard drive"
(assuming you don't really mean "giga," like some manufacturers do) is
really a "120GiB" hard drive, for "gibi" or "gigabinary" or 2^30.  See

   http://physics.nist.gov/cuu/Units/binary.html

for more info.

Although, I've never seen these prefixes used, except to note that
they exist...

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andy Sawyer wrote:
> In article <7f2735a5.0211211708.717db26b@posting.google.com>,
>  on Fri, 22 Nov 2002 01:10:49 +0000 (UTC),
>  allan_w@my-dejanews.com (Allan W) wrote:
....
>>Remember the Pentium floating-point bug? We could end up with
>>pi=3.0 exactly!
>
>
> Not very likely - the result of FLDPI was not affected by the bug.

The point is that, given the one bug, another similar bug that DOES
affect FLDPI becomes a bit more plausible.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> wrote in message
news:<3DDDBB19.2030203@animats.com>...
> Allan W wrote:
> > a9804814@unet.univie.ac.at (Thomas Mang) wrote in message
> > news:<c9ab3170.0211200155.39a70723@posting.google.com>...

> >>Neither the C99, nor the C++98 - standard contain fundamental
> >>mathematical values, such as pi or epsilon.

>      I'd argue for a standardized name for the value of "pi", at
> least.

And that the symbol name should be std::\u03C0, of course.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jun Woong wrote:
....
> We also have the international standards for the units. The unit
> problem is completely resolved by referring to those standard as
> normative references implicitly or explicitly.

The US remains an island of non-conformity to those standards, and in
economic terms it's far too big of an island to ignore. I doubt that a C
or C++ standard that endorsed physical constants in metric units, rather
than English ones, would go over well with US industries.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3DE2C01C.8080902@wizard.net>,
 on Tue, 26 Nov 2002 00:36:05 +0000 (UTC),
 kuyper@wizard.net ("James Kuyper Jr.") wrote:

> Andy Sawyer wrote:
> > In article <7f2735a5.0211211708.717db26b@posting.google.com>,
> >  on Fri, 22 Nov 2002 01:10:49 +0000 (UTC),
> >  allan_w@my-dejanews.com (Allan W) wrote:
> ....
> >>Remember the Pentium floating-point bug? We could end up with
> >>pi=3.0 exactly!
> > Not very likely - the result of FLDPI was not affected by the bug.
>
> The point is that, given the one bug, another similar bug that DOES
> affect FLDPI becomes a bit more plausible.

Not really, if you think about the nature of the instructions
involved. If you genuinely hold that opinion, then I suggest you
dispose of all of your Intel (and clones - AMD, Cyrix etc) based
hardware right now, since there are things which are much harder to
get right than FLDPI. Bear in mind that the infamous FDIV bug only
occured when the instruction was presented with certain, very
specific, sets of arguments. Since FLDPI takes no arguments, then it's
much, much easier to test the hardware design. So no, I don't accept
the possibility that a "similar bug that DOES affect FLDPI" is not at
all plausible. It's possible that a completely dissimilar bug might
affect FLDPI in the future, but I doubt it very, very much.

 Of course, if your argument is that implementations shouldn't use
FLDPI because it's a hardware instruction and therefore might be
buggy, then presumably none of the hardware arithmetic functions
should be used either (since they're hardware instructions and so
might be buggy?)

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>  allan_w@my-dejanews.com (Allan W) wrote:
> > Find some high school or college students who have taken geometry but
> > not yet trig. Try to tell them how to get sin(90.0) equal to 1.0,
> > using only portable code.

news@evo6.com (Andy Sawyer) wrote
> You'll have a hard time, since sin(90.0) doesn't equal 1.0 (at least,
> not in the universe I live in) - the argument to sin is expressed in
> radians, and 90 radians do not a right angle make.

That was exactly my point. So you have to multiply (or divide) 90.0 by
some constant -- but what's the constant, and how can you get maximum
accuracy while remaining portable? This justifies the definition of
std::math::pi.

Adding pi to the standard library would not be an undue burden on
compiler- or library-writers, I think -- they can easily write
compiler-specific code, while many of the rest of us strive to rely on
these libraries to write portable code.

> "Light thinks it travels faster than anything but it is wrong. No matter
>  how fast light travels it finds the darkness has always got there first,
>  and is waiting for it."                  -- Terry Pratchett, Reaper Man

But what if Light stops at a Motel 6? Tom Bodette will "leave the light
on for you" -- so darkness will have to wait until Light checks out.
Ha ha -- Light wins again. (Ever try to measure the speed of dark?)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3DE2C286.7030204@wizard.net>,
 on Tue, 26 Nov 2002 03:52:30 +0000 (UTC),
 kuyper@wizard.net ("James Kuyper Jr.") wrote:

> Jun Woong wrote:
> ....
> > We also have the international standards for the units. The unit
> > problem is completely resolved by referring to those standard as
> > normative references implicitly or explicitly.
>
> The US remains an island of non-conformity to those standards, and in
> economic terms it's far too big of an island to ignore. I doubt that a
> C or C++ standard that endorsed physical constants in metric units,
> rather than English ones, would go over well with US industries.

I doubt "English" units would suffice - you'd want "US Imperial" unit
(which are, in some cases, different to "British Imperial").

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <7f2735a5.0211251834.76369715@posting.google.com>,
 on Tue, 26 Nov 2002 03:53:16 +0000 (UTC),
 allan_w@my-dejanews.com (Allan W) wrote:

> >  allan_w@my-dejanews.com (Allan W) wrote:
> > > Find some high school or college students who have taken geometry but
> > > not yet trig. Try to tell them how to get sin(90.0) equal to 1.0,
> > > using only portable code.
>
> news@evo6.com (Andy Sawyer) wrote
> > You'll have a hard time, since sin(90.0) doesn't equal 1.0 (at least,
> > not in the universe I live in) - the argument to sin is expressed in
> > radians, and 90 radians do not a right angle make.
>
> That was exactly my point.

Cleverly obscured by the fact that I knew this before I attended
grammar school (which, agewise, is roughly the equivalent of what you
mean by high school).

 So exactly how _do_ you get sin(90.0) equal to 1.0?  (as opposed to
sin(90.0 * pi / 180.0) being equal to 1.0?)

Of course, we could have do something like: std::rad::sin,
std::deg::sin and std::grad::sin which all calculate sin but use
different units of angular measurement - no, this isn't a serious
suggestion.

> So you have to multiply (or divide) 90.0 by some constant -- but
> what's the constant

Last time I studied maths, I multiplied by pi / 180.0. I think, based
on one of your earlier posts ("pi=3.0"), you want to divide by 60.0?

> and how can you get maximum accuracy while remaining portable?

How can you get maximum accuracy while remaining portable, even given
std::maths::pi?

Clue: Here are four different ways (there = your angle measured in
degrees)

 theta * std::maths::pi / 180.0;
 theta / 180.0 * pi;
 theta * std::maths::pi_divided_by_180;
 theta / std::maths::N180_divided_by_pi;

Which gives "maximum accuracy", whilst "remaining portable"? Which is
most accurate might well depend on the platform, or compiler
optimizations or whatever.

Mathematically, of course, they're all equivalent - but that doesn't
mean they're all equivalent to a floating point unit.

Compound that with the fact that (apparently) high school and college
students will have trouble understanding why you're doing tricks with
"magic numbers" in your code, you'd be better off writing a function
named something like "degrees_to_radians" and calling that, then
implement that function with the "maximally accurate" expression for
whichever platform you're currently dealing with. I have a vague
recollection that the Z8000 FPU (I may be wrong) has a hardware
instruction to do the conversion (and the inverse), which would
probably be more accurate - and would certainly be faster - than any
of the above expressions, but only on that platform.

> This justifies the definition of std::math::pi.

Clearly not, in and of itself. Not that I'm saying std::maths::pi,
std::maths::e, std::maths::log_2_10, std::maths::log_10_2,
std::maths::positive_zero, std::maths::negative_zero and lots of other
useful numbers are bad ideas - because clearly they aren't. But
there's more to this than just requiring vendors to provide some
constants - you have to know how to use them correctly (which sounds
like it might leave some of your high school/college students
floundering). Doing floating point arithmetic with computers is one of
those areas where most people don't know enough to realise how much
they don't know, some people DO know enough to realise how much they
don't know, and a handful of people actually do understand what
they're doing. I'm most definitely /not/ in the last category.

 The other possible issue with these numbers is should they be
constants (in the sense of "const double std::maths::pi") or functions
(i.e. double std::maths::pi()). The former probably "feels" more
natural to most of use, but the latter probably makes it somewhat
easier for the vendor to take advantage of hardware instructions which
load special constants into registers. (Since someone asked last time
I mentioned hardware instructions that provide special constants, the
Intel NDPs have instructions for 1.0, log2(e), log2(10), log10(2),
ln(2), PI and +0.0 - I don't have the documentation for anyone else's
hardware conveniently to hand)

> > "Light thinks it travels faster than anything but it is wrong. No matter
> >  how fast light travels it finds the darkness has always got there first,
> >  and is waiting for it."                  -- Terry Pratchett, Reaper Man
>
> But what if Light stops at a Motel 6?

Then it takes longer to go wherever it was going, so the darkness has
got there first and is waiting for it. (I doubt light stops at Motel 6
- I imagine it has deeper pockets than that)

> Tom Bodette will "leave the light on for you"

I have no idea what you're talking about (other than a reference to an
inexpensive motel), so I'll assume it's way, way, off topic in a
couple of programming language standards newsgroups and leave it well
enough alone.

> (Ever try to measure the speed of dark?)

Yes. Serially, and with malice aforethought. The best "dark" for this
kind of experiment is the kind found at the bottom of a Guinness
glass. I have observed that, on occasion, it can travel pretty quickly
from there towards the back of my throat. Indeed, there are even a few
witnesses to these experiments hanging around in c.s.c++ :-)

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""James Kuyper Jr."" <kuyper@wizard.net> wrote in message news:3DE2C286.7030204@wizard.net...
> Jun Woong wrote:
> ....
> > We also have the international standards for the units. The unit
> > problem is completely resolved by referring to those standard as
> > normative references implicitly or explicitly.
>
> The US remains an island of non-conformity to those standards, and in
> economic terms it's far too big of an island to ignore. I doubt that a C
> or C++ standard that endorsed physical constants in metric units, rather
> than English ones, would go over well with US industries.
>

ISO/IEC Directives may have the answer to this.

For example, from ISO/IEC Direvtives pt.3 used to draft C99:
(6.6.8 Quantities, units, symbols and signs):
] The International System of units (SI) as set out in ISO 31 shall be
] used.

Of course, I know that these provisions can be ignored if it need do
so.


--
Jun, Woong (mycoboco@hanmail.net)
Dept. of Physics, Univ. of Seoul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 Standard-related content flatlining.  Please consider email.


===================================== END OF MODERATOR'S COMMENT
Andy Sawyer wrote:
> In article <3DE2C01C.8080902@wizard.net>,
>  on Tue, 26 Nov 2002 00:36:05 +0000 (UTC),
>  kuyper@wizard.net ("James Kuyper Jr.") wrote:
>
>
>>Andy Sawyer wrote:
>>
....
>>>Not very likely - the result of FLDPI was not affected by the bug.
>>
>>The point is that, given the one bug, another similar bug that DOES
>>affect FLDPI becomes a bit more plausible.
>
>
> Not really, if you think about the nature of the instructions
....
> all plausible. It's possible that a completely dissimilar bug might
> affect FLDPI in the future, but I doubt it very, very much.

So do I, but my doubt is significantly weaker than it would have been
without the FDIV bug. That's all I'm saying. I'm not trying to imply
that the chance of such a bug is significant, only that the
insignificant chance that it would occur is higher than I would have
thought it was, had the FDIV bug never happened.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dietmar Schindler wrote:
....
> The prefix letter for kilo is k (lower case).
> The symbol for the average acceleration of Earth's gravity is g (lower
> case).
> g is 9.80665 meters per second squared.

Only at some particular locations. It varies from place to place over
the surface of the earth, and the number of digits you've selected is
large enough to show that variation. I seem to remember that there's a
standard value: the value at sea level, on the prime meridian, at
latitude 45N. That's probably the number you're quoting.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

musiphil@bawi.org (KIM Seungbeom) writes:

> ericjb@lksejb.lks.agilent.com wrote:
> > I like this idea.  Perhaps extend it with std::physics to hold
> > physical constants like the gravitational constant and electron
> > charge, and possibly even std::astro to hold astronomical constants.
>
> Physical constants have units and are meaningless without them.
> Speeds in m/s or mph? Forces in N or dyn? Energies in J or eV or MeV
> or erg? Temperatures in Celcius or Fahrenheit or Kelvin?
> Adopting those constants can be done only after inventing some way
> to represent units and to convert between different units, and for the
> Plank constant 6.626e-34 J s should be as natural as 4.136e-15 eV s.

The obvious choice would be to use SI units, which are an
international standard and widely used.

A bigger problem is that most of these values aren't known to
arbitrary precision.

--
Eric Backus
R&D Design Engineer
Agilent Technologies, Inc.
425-335-2495 Tel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) writes:

> Seems to me the best place to put these new constants is in a namespace
> WITHIN namespace std. I nominate std::math (not my original idea -- I
> don't know who said it first, but I've heard it many times before).
>
> How about std::math::pi and std::math::e, which would be double constants
> with as many significant digits as the target platform allows.
>
> Other candidates include std::math::sqrt2 and std::math::sqrt3, which
> tend to pop up a lot in their own right.

I like this idea.  Perhaps extend it with std::physics to hold
physical constants like the gravitational constant and electron
charge, and possibly even std::astro to hold astronomical constants.


> And, in the spirit of what Andy Sawyer suggested:
>     std::math::nano                    would be 1e-9
>     std::math::micro                   would be 1e-6
>     std::math::milli                   would be 1e-3
>     std::math::kilo  and std::math::K  would both be 1e3 or 1000 (integer?)
>     std::math::mega  and std::math::M  would both be 1e6 or 1000000 (long?)
>     std::math::giga                    would be 1e9

But this seems completely unnecessary.  The reason you need pi or
sqrt2 is that they can't be exactly represented in decimal (or hex)
notation.  So while M_PI=3.14159 may be full precision on one
platform, it won't be on another platform.  But the prefix values are
represented exactly in decimal, so NANO=1e-9 retains full precision on
any platform.  No need to abstract it behind std::math.

--
Eric Backus
R&D Design Engineer
Agilent Technologies, Inc.
425-335-2495 Tel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ericjb@lksejb.lks.agilent.com wrote:
>
> allan_w@my-dejanews.com (Allan W) writes:
>
> > Seems to me the best place to put these new constants is in a namespace
> > WITHIN namespace std. I nominate std::math (not my original idea -- I
> > don't know who said it first, but I've heard it many times before).
> >
> > How about std::math::pi and std::math::e, which would be double constants
> > with as many significant digits as the target platform allows.
> >
> > Other candidates include std::math::sqrt2 and std::math::sqrt3, which
> > tend to pop up a lot in their own right.
>
> I like this idea.  Perhaps extend it with std::physics to hold
> physical constants like the gravitational constant and electron
> charge, and possibly even std::astro to hold astronomical constants.

Physical constants have units and are meaningless without them.
Speeds in m/s or mph? Forces in N or dyn? Energies in J or eV or MeV
or erg? Temperatures in Celcius or Fahrenheit or Kelvin?
Adopting those constants can be done only after inventing some way
to represent units and to convert between different units, and for the
Plank constant 6.626e-34 J s should be as natural as 4.136e-15 eV s.

>
> > And, in the spirit of what Andy Sawyer suggested:
> >     std::math::nano                    would be 1e-9
> >     std::math::micro                   would be 1e-6
> >     std::math::milli                   would be 1e-3
> >     std::math::kilo  and std::math::K  would both be 1e3 or 1000 (integer?)
> >     std::math::mega  and std::math::M  would both be 1e6 or 1000000 (long?)
> >     std::math::giga                    would be 1e9
>
> But this seems completely unnecessary.  The reason you need pi or
> sqrt2 is that they can't be exactly represented in decimal (or hex)
> notation.  So while M_PI=3.14159 may be full precision on one
> platform, it won't be on another platform.  But the prefix values are
> represented exactly in decimal, so NANO=1e-9 retains full precision on
> any platform.  No need to abstract it behind std::math.

They still serve documentational purpose, don't they?

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>
>
> Physical constants have units and are meaningless without them.
> Speeds in m/s or mph? Forces in N or dyn? Energies in J or eV or MeV
> or erg? Temperatures in Celcius or Fahrenheit or Kelvin?

Sure they have. But others too. e.g. what's the result of sin(45)?
Answer: Depends if calculation mode is deg, rad or grad.


Physics is quite clear in defining 7 base-units and deriving other units =
from them.

So speed is m/s , temperature is K, Energy is kg m=B2 /s=B2 (which =3D=3D=
 J)


Indeed, for me it makes more sense to set the energy unit as J then to
automatically set trig-calculation to rad-mode, as C/C++ does.

regards,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

[removed comp.std.c from the NG list]
musiphil@bawi.org (KIM Seungbeom) wrote in message news:<3DDED3A5.2D00A04F@bawi.org>...
> ericjb@lksejb.lks.agilent.com wrote:
> >
> > allan_w@my-dejanews.com (Allan W) writes:
> >
> > > Seems to me the best place to put these new constants is in a namespace
> > > WITHIN namespace std. I nominate std::math (not my original idea -- I
> > > don't know who said it first, but I've heard it many times before).
> > >
> > > How about std::math::pi and std::math::e, which would be double constants
> > > with as many significant digits as the target platform allows.
> > >
> > > Other candidates include std::math::sqrt2 and std::math::sqrt3, which
> > > tend to pop up a lot in their own right.

I agree with this.  Unix98 puts these (except sqrt3) as macros in
math.h anyway, so C++ solution would be nice.  Perhaps they should be
functions though, as floating point hardware often has instructions to
load pi and other values directly.  OTOH, function notation is uglier,
and I imagine it isn't too hard for the compiler to just 'know' that
std::math::pi is available as a floating point operation (I guess they
do this already for 1.0 ?)

> >
> > I like this idea.  Perhaps extend it with std::physics to hold
> > physical constants like the gravitational constant and electron
> > charge, and possibly even std::astro to hold astronomical constants.
>
> Physical constants have units and are meaningless without them.
> Speeds in m/s or mph? Forces in N or dyn? Energies in J or eV or MeV
> or erg? Temperatures in Celcius or Fahrenheit or Kelvin?
> Adopting those constants can be done only after inventing some way
> to represent units and to convert between different units, and for the
> Plank constant 6.626e-34 J s should be as natural as 4.136e-15 eV s.

I usually use Plank == speed of light == 1 ;-)

With the possible exception of the speed of light in a vacuum, which
is now defined to be exactly 299,792,458 m/s, the physical constants
are not known exactly so the C++ standards committee would also have
the problem of deciding exactly which value to use, how many
significant digits to require, how to expose the number of significant
digits to the user and of course also put in place a mechanism to
update the values if and when new experiments improve the previous
best measurement.

Given this scenario, a program that was required to be portable would
use its own header of physical constants to guarantee that they have
exactly the same value on all platforms.

Then there is the problem that some recent experiments suggest that
some of the physical constants may in fact change in time (admittedly
slowly enough that it presents no practical problem, but there is
still a philosophical one).

>
> >
> > > And, in the spirit of what Andy Sawyer suggested:
> > >     std::math::nano                    would be 1e-9
> > >     std::math::micro                   would be 1e-6
> > >     std::math::milli                   would be 1e-3
> > >     std::math::kilo  and std::math::K  would both be 1e3 or 1000 (integer?)
> > >     std::math::mega  and std::math::M  would both be 1e6 or 1000000 (long?)
> > >     std::math::giga                    would be 1e9
> >
> > But this seems completely unnecessary.  The reason you need pi or
> > sqrt2 is that they can't be exactly represented in decimal (or hex)
> > notation.  So while M_PI=3.14159 may be full precision on one
> > platform, it won't be on another platform.  But the prefix values are
> > represented exactly in decimal, so NANO=1e-9 retains full precision on
> > any platform.  No need to abstract it behind std::math.
>
> They still serve documentational purpose, don't they?

I don't really have an opinion on this, except to say that I doubt too
many programmers would prefer to write 'std::math::giga' over '10^9'.
Perhaps such things are more useful in a 'units' package, where it
really would be useful, eg math::distance d = 5 * math::feet + 10 *
math::metres and it is typesafe, and just works, independent of
underlying representation of a distance.  NASA needs something like
this ;)

Cheers,
Ian McCulloch

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <7f2735a5.0211211724.244caebe@posting.google.com>,
 on Fri, 22 Nov 2002 01:50:23 +0000 (UTC),
 allan_w@my-dejanews.com (Allan W) wrote:

> a9804814@unet.univie.ac.at (Thomas Mang) wrote in message
> news:<c9ab3170.0211200155.39a70723@posting.google.com>...
> > Hello everybody,
> >
> >
> > Neither the C99, nor the C++98 - standard contain fundamental
> > mathematical values, such as pi or epsilon.
> >
> > However, these are commonly used. (Can't prove this by statistical
> > surveys, but I think so.)
>
> I don't have useful statistics either, but I have seen it first-hand.
> Find some high school or college students who have taken geometry but
> not yet trig. Try to tell them how to get sin(90.0) equal to 1.0,
> using only portable code.

You'll have a hard time, since sin(90.0) doesn't equal 1.0 (at least,
not in the universe I live in) - the argument to sin is expressed in
radians, and 90 radians do not a right angle make.

> Seems to me the best place to put these new constants is in a namespace
> WITHIN namespace std. I nominate std::math (not my original idea -- I
> don't know who said it first, but I've heard it many times before).
>
> How about std::math::pi and std::math::e, which would be double constants
> with as many significant digits as the target platform allows.
>
> Other candidates include std::math::sqrt2 and std::math::sqrt3, which
> tend to pop up a lot in their own right.
>
> And, in the spirit of what Andy Sawyer suggested:
>     std::math::nano                    would be 1e-9
>     std::math::micro                   would be 1e-6
>     std::math::milli                   would be 1e-3
>     std::math::kilo  and std::math::K  would both be 1e3 or 1000 (integer?)
>     std::math::mega  and std::math::M  would both be 1e6 or 1000000 (long?)
>     std::math::giga                    would be 1e9

Those aren't really mathematical values, they're SI values.

> But what would std::math::G mean? Commonly used as a synonym for
> Giga, as in "my 120GB hard drive."

But the "Giga" in "my 120GB hard drive" is often different to the
"Giga" in "my 120 Gigiwatt laser". One of them is 1e9, and the other
is 2^30. (A problem compounded by the fact that programmers think in
binary whilst marketing droids think in SI.)


 But also commonly used for one
> gravity, which (I believe) is about 0.98 meters per second squared,
> or something like that...

The symbol commonly used for one (Earth) gravity is 'g' (note
case). Last time I checked, it was more like 9.81
meters/second/second. 'G', on the other hand, is the unversal
gravitational constant which is approximatly 6.672e-11. But these
aren't strictly mathematical values either, so maybe they belong in
std::physics?


--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <7f2735a5.0211211708.717db26b@posting.google.com>,
 on Fri, 22 Nov 2002 01:10:49 +0000 (UTC),
 allan_w@my-dejanews.com (Allan W) wrote:

> news@evo6.com (Andy Sawyer) wrote
> > pi is a particularly interesting case, since some hardware already has
> > a "built-in" value for pi and I think it would be nice if we could use
> > that (assuming it's correct!).
>
> Remember the Pentium floating-point bug? We could end up with
> pi=3.0 exactly!

Not very likely - the result of FLDPI was not affected by the bug.

> Does the C++ Standards committee have the authority to change the
> value of pi?

If you mean the ratio of the diameter of a circle to its
circumference, then no - you need rather more authority than a
standards committe has to change the nature of the universe. If, on
the other hand, you mean the value assigned to a constant named pi in
the C++ standard library, then yes of course it does.

> It doesn't have to be 3.0 exactly -- I'll settle for any rational
> value, but 22/7 seems like a good choice.

It's a handy approximiation for doing calculations in one's head, but I
don't see it as being very useful for computed calculations.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
>     std::math::kilo  and std::math::K  would both be 1e3 or 1000 (integer?)
>     std::math::mega  and std::math::M  would both be 1e6 or 1000000 (long?)
>     std::math::giga                    would be 1e9
> But what would std::math::G mean? Commonly used as a synonym for Giga,
> as in "my 120GB hard drive." But also commonly used for one gravity,
> which (I believe) is about 0.98 meters per second squared, or something
> like that...

The prefix letter for kilo is k (lower case).
The symbol for the average acceleration of Earth's gravity is g (lower
case).
g is 9.80665 meters per second squared.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote in message
news:<7f2735a5.0211211724.244caebe@posting.google.com>...

    [...]
> And, in the spirit of what Andy Sawyer suggested:
>     std::math::nano                    would be 1e-9
>     std::math::micro                   would be 1e-6
>     std::math::milli                   would be 1e-3
>     std::math::kilo  and std::math::K  would both be 1e3 or 1000 (integer?)
>     std::math::mega  and std::math::M  would both be 1e6 or 1000000 (long?)
>     std::math::giga                    would be 1e9
> But what would std::math::G mean? Commonly used as a synonym for Giga,
> as in "my 120GB hard drive." But also commonly used for one gravity,
> which (I believe) is about 0.98 meters per second squared, or
> something like that...

But that would be std::physics::G, no ? :-)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

     I'd avoid putting in physical constants.  The numerical ones
like pi and e are definitively known to any desired precision.
The physical constants are only known to a limited number of
digits, and may change slightly with later experimental results.

    John Nagle
    Animats

ericjb@lksejb.lks.agilent.com wrote:


> I like this idea.  Perhaps extend it with std::physics to hold
> physical constants like the gravitational constant and electron
> charge, and possibly even std::astro to hold astronomical constants.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

musiphil@bawi.org (KIM Seungbeom) wrote in message news:<3DDED3A5.2D00A04F@bawi.org>...
> ericjb@lksejb.lks.agilent.com wrote:
> >
> > allan_w@my-dejanews.com (Allan W) writes:
> >
> > > Seems to me the best place to put these new constants is in a namespace
> > > WITHIN namespace std. I nominate std::math (not my original idea -- I
> > > don't know who said it first, but I've heard it many times before).
> > >
> > > How about std::math::pi and std::math::e, which would be double constants
> > > with as many significant digits as the target platform allows.
> > >
> > > Other candidates include std::math::sqrt2 and std::math::sqrt3, which
> > > tend to pop up a lot in their own right.
> >
> > I like this idea.  Perhaps extend it with std::physics to hold
> > physical constants like the gravitational constant and electron
> > charge, and possibly even std::astro to hold astronomical constants.
>
> Physical constants have units and are meaningless without them.
> Speeds in m/s or mph? Forces in N or dyn? Energies in J or eV or MeV
> or erg? Temperatures in Celcius or Fahrenheit or Kelvin?
> Adopting those constants can be done only after inventing some way
> to represent units and to convert between different units, and for the
> Plank constant 6.626e-34 J s should be as natural as 4.136e-15 eV s.
>

We also have the international standards for the units. The unit
problem is completely resolved by referring to those standard as
normative references implicitly or explicitly.


--
Jun, Woong (mycoboco@hanmail.net)
Dept. of Physics, Univ. of Seoul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3DDED3A5.2D00A04F@bawi.org>,
 on Sat, 23 Nov 2002 03:57:03 +0000 (UTC),
 musiphil@bawi.org (KIM Seungbeom) wrote:

> ericjb@lksejb.lks.agilent.com wrote:
> >=20
> > allan_w@my-dejanews.com (Allan W) writes:
> >=20
> > > Seems to me the best place to put these new constants is in a names=
pace
> > > WITHIN namespace std. I nominate std::math (not my original idea --=
 I
> > > don't know who said it first, but I've heard it many times before).
> > >
> > > How about std::math::pi and std::math::e, which would be double con=
stants
> > > with as many significant digits as the target platform allows.
> > >
> > > Other candidates include std::math::sqrt2 and std::math::sqrt3, whi=
ch
> > > tend to pop up a lot in their own right.
> >=20
> > I like this idea.  Perhaps extend it with std::physics to hold
> > physical constants like the gravitational constant and electron
> > charge, and possibly even std::astro to hold astronomical constants.
>=20
> Physical constants have units and are meaningless without them.

Not all of them. There are several=B9 very important dimensionless
constants (The "Fine Structure Constant" is probably the best known
example, but it's certainly not unique.).

Regards,
 Andy S.


=B9 I've heard it asserted that there are at least 26=B2. I'm not a
physicist, to can't comment on the validity of the assertion. The only
reason that the figure (26) stuck in my mind was that it was another
one of those really neat "coincidences" about the Universe - it has as
many fundamental constants as my native alphabet had letters :-)
=B2 That is to say 26 _fundamental_ dimensionless constants. There are,
apparently, more but they can all be derived from these 26 fundamental
values. At least, I think that's what he was saying...
--=20
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello everybody,


Neither the C99, nor the C++98 - standard contain fundamental
mathematical values, such as pi or epsilon.

However, these are commonly used. (Can't prove this by statistical
surveys, but I think so.)


Therefore, I propose to make them part of the standard; e.g. as
constants defined in math.h / cmath, or as parts of a templated system
like "std::numeric_limits", where the returned value will implicitely
have the chosen type, e.g:

std::math_values<double>::pi();  //  Returns pi with double-precision
for given platform
std::math_values<float>::pi();   // float precision



best regards,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 20 Nov 2002 18:58:22 +0000 (UTC), a9804814@unet.univie.ac.at
(Thomas Mang) wrote:

>Hello everybody,
>
>
>Neither the C99, nor the C++98 - standard contain fundamental
>mathematical values, such as pi or epsilon.
>
>However, these are commonly used. (Can't prove this by statistical
>surveys, but I think so.)
>
>
>Therefore, I propose to make them part of the standard; e.g. as
>constants defined in math.h / cmath, or as parts of a templated system
>like "std::numeric_limits", where the returned value will implicitely
>have the chosen type, e.g:
>
>std::math_values<double>::pi();  //  Returns pi with double-precision
>for given platform
>std::math_values<float>::pi();   // float precision

Those wouldn't work too well in C.  You did crosspost...

How about 4*atan(1.0) for double, 4*atanf(1.0) for float, and
4*atanl(1.0) for long double?

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Thomas Mang wrote:
> Neither the C99, nor the C++98 - standard contain fundamental
> mathematical values, such as pi or epsilon.

[I suppose you mean e, Napier's base.]

> Therefore, I propose to make them part of the standard; e.g. as
> constants defined in math.h / cmath, or ...

Historically there have been various such implementations,
with notorious lack of agreement on the names.  One problem
in the pre-hexadecimal-floating-constant days was that the
nearest representable value of such a constant was not
precisely expressible using the available decimal-floating-
constant notation.  Also, existing implementations tended
to truncate radically when ported to wider architectures
(think of #define PI 3.14159).  If one wanted to standardize
such symbols in <math.h>, I'd strongly urge that the names
come from the space reserved for implementations, e.g.
__M_PI.

What most of us have done in the interim is to compute our
own, e.g. if (!init) pi = 4.*atan2(1.,1.);

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3DDBF2AF.3EB1DF91@null.net>,
 on Wed, 20 Nov 2002 22:22:40 +0000 (UTC),
 DAGwyn@null.net ("Douglas A. Gwyn") wrote:

> Thomas Mang wrote:
> > Neither the C99, nor the C++98 - standard contain fundamental
> > mathematical values, such as pi or epsilon.
>
> [I suppose you mean e, Napier's base.]
>
> > Therefore, I propose to make them part of the standard; e.g. as
> > constants defined in math.h / cmath, or ...
>
> Historically there have been various such implementations,
> with notorious lack of agreement on the names.

Lack of agreement on the names, the values or indeed which fundamental
constants should be included. (Although they're not strictly
*mathematical* constants, I'd like to have h=6.626e-34, and
G=6.672e-11 in there myself. And it'd be terrific if anyone has
accurate values for the coefficients in Drake's equation?...)

> What most of us have done in the interim is to compute our
> own, e.g. if (!init) pi = 4.*atan2(1.,1.);

pi is a particularly interesting case, since some hardware already has
a "built-in" value for pi and I think it would be nice if we could use
that (assuming it's correct!).


Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Thomas Mang" <a9804814@unet.univie.ac.at> wrote...
>
> Neither the C99, nor the C++98 - standard contain fundamental
> mathematical values, such as pi or epsilon.
>
> However, these are commonly used. (Can't prove this by statistical
> surveys, but I think so.)
>
> Therefore, I propose to make them part of the standard; [rest snipped]

The boost people have already been down this path. There was general
agreement about the usefulness and, after a while, some consensus about
how to present such constants, and I think discussions about naming
conventions (the really hard bit :) have just about decided on
something.

See http://groups.yahoo.com/group/boost/files/MathConstants/

As I recall, the person doing most of the legwork was very keen to come
up with something for C users as well, so the #define-d values are
collected in a header, which is usable in C as-is and used in the
implementation of the C++ template solution.

"Andy Sawyer" <news@evo6.com> wrote...
>
> (Although they're not strictly
> *mathematical* constants, I'd like to have h=6.626e-34, and
> G=6.672e-11 in there myself. And it'd be terrific if anyone has
> accurate values for the coefficients in Drake's equation?...)

Physical "constants" were considered too. I don't think Drake's equation
came up, but you could probably use "1" without fear of contradiction in
the short term.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Douglas A. Gwyn" schrieb:

> Thomas Mang wrote:
> > Neither the C99, nor the C++98 - standard contain fundamental
> > mathematical values, such as pi or epsilon.
>
> [I suppose you mean e, Napier's base.]

Yepp, meant e.
Sorry.


regards,
Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

news@evo6.com (Andy Sawyer) wrote
> pi is a particularly interesting case, since some hardware already has
> a "built-in" value for pi and I think it would be nice if we could use
> that (assuming it's correct!).

Remember the Pentium floating-point bug? We could end up with
pi=3.0 exactly!

(That would simplify a lot of things, though.
If Diameter=8, then Circumference=24 -- no calculator needed!)

Does the C++ Standards committee have the authority to change the value
of pi? It doesn't have to be 3.0 exactly -- I'll settle for any rational
value, but 22/7 seems like a good choice.

(Someone once suggested making pi equal to 1.0 base pi -- but that
would just lead us in circles, pun intended!)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

a9804814@unet.univie.ac.at (Thomas Mang) wrote in message news:<c9ab3170.0211200155.39a70723@posting.google.com>...
> Hello everybody,
>
>
> Neither the C99, nor the C++98 - standard contain fundamental
> mathematical values, such as pi or epsilon.
>
> However, these are commonly used. (Can't prove this by statistical
> surveys, but I think so.)

I don't have useful statistics either, but I have seen it first-hand.
Find some high school or college students who have taken geometry but
not yet trig. Try to tell them how to get sin(90.0) equal to 1.0,
using only portable code.

Seems to me the best place to put these new constants is in a namespace
WITHIN namespace std. I nominate std::math (not my original idea -- I
don't know who said it first, but I've heard it many times before).

How about std::math::pi and std::math::e, which would be double constants
with as many significant digits as the target platform allows.

Other candidates include std::math::sqrt2 and std::math::sqrt3, which
tend to pop up a lot in their own right.

And, in the spirit of what Andy Sawyer suggested:
    std::math::nano                    would be 1e-9
    std::math::micro                   would be 1e-6
    std::math::milli                   would be 1e-3
    std::math::kilo  and std::math::K  would both be 1e3 or 1000 (integer?)
    std::math::mega  and std::math::M  would both be 1e6 or 1000000 (long?)
    std::math::giga                    would be 1e9
But what would std::math::G mean? Commonly used as a synonym for Giga,
as in "my 120GB hard drive." But also commonly used for one gravity,
which (I believe) is about 0.98 meters per second squared, or something
like that...

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:

> [...]
> And, in the spirit of what Andy Sawyer suggested:
>     std::math::nano                    would be 1e-9
>     std::math::micro                   would be 1e-6
>     std::math::milli                   would be 1e-3
>     std::math::kilo  and std::math::K  would both be 1e3 or 1000
> (integer?)
>     std::math::mega  and std::math::M  would both be 1e6 or 1000000
> (long?)
>     std::math::giga                    would be 1e9
> But what would std::math::G mean? Commonly used as a synonym for Giga,
> as in "my 120GB hard drive." But also commonly used for one gravity,
> which (I believe) is about 0.98 meters per second squared, or
> something like that...

Actually, you're thinking of G as the gravitational constant, which is
in units of m^3/kg s^2, if I did my units correctly.  And if you're
worried about mixing prefixes with constants or other well-known
mathematical meanings, then consider that K is also Kelvins, and M is
molarity.  It seems to me that single-letter names are not a
particularly useful choice, unless embedded in yet more namespaces.  But
then, who wants to write:

std::math::prefix::M

?  Pas moi. ;)

Dave

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 Possible topic drift...


===================================== END OF MODERATOR'S COMMENT
Allan W wrote:
> Find some high school or college students who have taken geometry but
> not yet trig. Try to tell them how to get sin(90.0) equal to 1.0,
> using only portable code.

I didn't understand that at all.
sin(90.0) is nowhere near 1.0.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:

> a9804814@unet.univie.ac.at (Thomas Mang) wrote in message news:<c9ab3170.0211200155.39a70723@posting.google.com>...
>
>>Hello everybody,
>>
>>
>>Neither the C99, nor the C++98 - standard contain fundamental
>>mathematical values, such as pi or epsilon.


     I'd argue for a standardized name for the value of
"pi", at least.  Most graphics programs have
a symbol for pi, and many of them have several
such symbols.  It's not unusual
to find values for pi in graphics programs that
have less precision than the machine supports,
sometimes much less.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]