Helmut Zeisel wrote:
>
> C++ does not only inherit the C function pow(double,double),
> it defines a few overloaded functions
>
> pow(T x, int n) for various types T.
>
> The author(s) of the FAQ of sci.math
>
> <http://daisy.uwaterloo.ca/~alopez-o/math-faq>
>
> suggest to define 0**0 as 1 at least when the exponent
> is an integer; in particular pow(0.0,int(0)) should be 1.
>
> It would be very easy to implement this policy in C++:
>
> The implementation of pow(T, int) is probably very different from
> the implementation of pow(double, double) etc since
> pow(T x, int n) is defined for every x, while pow(double x, double)
> is undefined for x < 0 etc.
>
> pow(x, int(0)) == 1 at least for
> every x != 0, the choice pow (0,int(0)) == 1
> might be easier to implement than to have a special case
> for x==0.
>
> For non-integer exponents, however, it might be wise to wait until the
> the C or Fortran standard provide a standardization.
>

I did not find a reaction in comp.lang.c++, but Howard W. LUDWIG sent
me an EMail which he allowed me to forward to comp.lang.c++:

>
> If you're waiting for some other language to forge a path, it has been
> done already.  Ada 95 (ANSI/ISO/IEC 8652:1995) has done basically what
> the previous poster suggested.  In particular, 0**0 is defined to be 1,
> 0.0**0 is defined to be 1.0, and 0.0**0.0 throws (raises) an exception
> without returning a value.
>
> This concept is fully compatible with modern mathematical analysis, in
> which there is strong consensus that any 0 raised to an integral (discrete)
> 0 is 1; there are two major schools of thought regarding a floating
> (continuous) 0 in the exponent:  (1) the answer is still 1; (2) there
> is no answer due to problems with limits.  Because most compilers turn
> pow(x,y) into exp(y*log(x)) when y is floating and log(0.0) is _not_
> defined, it is easiest to go with the second school of thought for
> pow(0.0,0.0).
>
> It's unfortunate that C++, with its many new features such as exceptions,
> has to be tied so strongly to C that inconsistencies arise such as having
> libraries new to C++ throw exceptions but libraries inherited from C must
> not.  Will the upcoming C standard include exceptions and use them in the
> libraries?  If so, will C++ then be lagging C as opposed to leading C, by
> being tightly coupled to an older C standard?
>
> Howard W. LUDWIG, Ph.D.

Here is again my point:

That standard should guarantee that
pow(x,int(0)) is 1 for every (double, compex, etc.) x. This
1) saves the users a lot of checks for x == 0,
2) is easy to implement (easier than a special case for x == 0),
3) is probably done in every current implementation,
4) is compatible with C (which has only pow(double,double)),
5) is compatible with other languages, in particular ADA 95.

A specification for pow(0.0,0.0) is not so important,
since "the majority of occurences of ** in the Fortran
code examined were of the form a**n where n was a small integer"
(Stroustrup, Design and Evolution of C++, Section 11.6.1).

Helmut Zeisel
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article 18F0@mds.rmit.edu.au, Marcelo Cantos
<marcelo@mds.rmit.edu.au> writes:
>
>Then here is a more general question for the standards people:
>
>  What factors govern the choice between undefined behaviour and
>  throwing an exception (as far as the standard libraries are
>  concerned)?

In the case of "pow" and other functions inherited from the C library,
the answer is easy: C compatibility is a primary concern, and C library
functions don't throw exceptions.

The purely C++ functions often indicate failure by throwing exceptions.

"Undefined behavior" usually applies in two main circumstances:
1. The violation is impossible to detect in general, or would impose too
much overhead on all programs to require detection.
2. There is no consensus on what the behavior should be, so "undefined"
allows implementors to continue to do what they have been doing, or to
find innovative solutions, or to give customers different options.

If this all sounds kind of fuzzy, that's because it is. :-) "Too much
overhead", for example, is completely subjective.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

> From Stephen.Clamage@eng.sun.com (Steve Clamage)
> In article 18F0@mds.rmit.edu.au, Marcelo Cantos
> <marcelo@mds.rmit.edu.au> writes:
> >
> >Then here is a more general question for the standards people:
> >
> >  What factors govern the choice between undefined behaviour and
> >  throwing an exception (as far as the standard libraries are
> >  concerned)?
>
> In the case of "pow" and other functions inherited from the C library,
> the answer is easy: C compatibility is a primary concern, and C library
> functions don't throw exceptions.
>
> The purely C++ functions often indicate failure by throwing exceptions.
>
> "Undefined behavior" usually applies in two main circumstances:
> 1. The violation is impossible to detect in general, or would impose too
> much overhead on all programs to require detection.
> 2. There is no consensus on what the behavior should be, so "undefined"
> allows implementors to continue to do what they have been doing, or to
> find innovative solutions, or to give customers different options.
>

C++ does not only inherit the C function pow(double,double),
it defines a few overloaded functions

pow(T x, int n) for various types T.

The author(s) of the FAQ of sci.math

<http://daisy.uwaterloo.ca/~alopez-o/math-faq>

suggest to define 0**0 as 1 at least when the exponent
is an integer; in particular pow(0.0,int(0)) should be 1.

It would be very easy to implement this policy in C++:

The implementation of pow(T, int) is probably very different from
the implementation of pow(double, double) etc since
pow(T x, int n) is defined for every x, while pow(double x, double)
is undefined for x < 0 etc.

pow(x, int(0)) == 1 at least for
every x != 0, the choice pow (0,int(0)) == 1
might be easier to implement than to have a special case
for x==0.

For non-integer exponents, however, it might be wise to wait until the
the C or Fortran standard provide a standardization.

Helmut Zeisel
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Roger Glover <glover@cray.com> wrote:

snip

>Classic mathematical analysis just refuses to guess.  It says that
>the point (0,0) is not in the domain of the power function.  Why
>should Fortran *OR* C++ wish to define something that classic math
>itself leaves undefined?

If some incautious user writes pow (0.0, 0.0), or pow (x, y) where x
and y happen to be computed as 0.0, the library has to do something.
It could return some plausible value or throw an exception to indicate
the argument is not in the domain of the function. It's possible to
argue either way about which of these is the least unsatisfactory. I'd
probably lean toward the exception, since this is almost certainly a
problem situation.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Roger Glover wrote:
>
...
> For example:   lim  pow(x,0) = 1
>                x->0
>
> but.........   lim  pow(0,y) = 0
>                y->0
>
> So which is the "right" answer?  But wait!  A case could be made for
> every real number in between 0 and 1!  Now what answer would you
> guess?
>
> Classic mathematical analysis just refuses to guess.  It says that
> the point (0,0) is not in the domain of the power function.  Why
> should Fortran *OR* C++ wish to define something that classic math
> itself leaves undefined?

Because if the standard leaves the value unspecified, then a programmer
will always have to surround a call to pow(x,y) with protective code:

if(fabs(x)<X_MIN && fabs(y)<Y_MIN)
 z = /* special expression */;
else
 z = /* general expression containing pow(x,y) */;

The appropriate values for X_MIN and Y_MIN will vary from case to case.
So will the special expression. However, in many cases, the special
expression will be the same as the general expression, with some
particular value substituted for pow(x,y). If the standard were to
specify a value for pow(0.0,0.0), every piece of code where the special
expression matched that value could be simplified. This isn't just a
matter of laziness; the simpler code will be easier to desk check, and
less prone to having inconsistent changes made to the special and
general expressions.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

wkdugan@ix.netcom.com (Bill Dugan) wrote:
>Roger Glover <glover@cray.com> wrote:
>
>>Classic mathematical analysis just refuses to guess.  It says that
>>the point (0,0) is not in the domain of the power function.  Why
>>should Fortran *OR* C++ wish to define something that classic math
>>itself leaves undefined?
>
>If some incautious user writes pow (0.0, 0.0), or pow (x, y) where x
>and y happen to be computed as 0.0, the library has to do something.

Yes, the library should do the the right thing.  Quoting from "Concrete
Mathematics: A Foundation for Computer Science", Graham, Knuth and
Patashnik, page 162:

    Some textbooks leave the quantity [pow(0,0)] undefined,
 because the functions [pow(x,0)] and [pow(0,x)] have different
 limiting values when x decreases to 0.  But this is a mistake.
 We must define

   pow(x, 0) == 1, for all x,

 if the binomial theorem is to be valid when x == 0, y == 0,
 and/or x == -y.  The theorem is too important to be arbitrarily
 restricted!  By contrast, the function [pow(0,x)] is quite
 unimportant.

The sci.math FAQ, if I recall, has a bit more to say about this
so-called "problem".
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Bill Dugan wrote:
>
> Roger Glover <glover@cray.com> wrote:
>
> snip
>
> >Classic mathematical analysis just refuses to guess.  It says that
> >the point (0,0) is not in the domain of the power function.  Why
> >should Fortran *OR* C++ wish to define something that classic math
> >itself leaves undefined?
>
> If some incautious user writes pow (0.0, 0.0), or pow (x, y) where x
> and y happen to be computed as 0.0, the library has to do something.
> It could return some plausible value or throw an exception to indicate
> the argument is not in the domain of the function. It's possible to
> argue either way about which of these is the least unsatisfactory. I'd
> probably lean toward the exception, since this is almost certainly a
> problem situation.

Then here is a more general question for the standards people:

  What factors govern the choice between undefined behaviour and
  throwing an exception (as far as the standard libraries are
  concerned)?


--
___________________________________________________________________
Marcelo Cantos, Research Assistant          marcelo@mds.rmit.edu.au
Multimedia Database Systems Group    __/_      _ Tel 61-3-9282-2497
723 Swanston St, Carlton VIC 3053, Aus/ralia ><_>Fax 61-3-9282-2490
                                     /
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

wkdugan@ix.netcom.com (Bill Dugan) writes:

> Roger Glover <glover@cray.com> wrote:
>
> snip
>
> >Classic mathematical analysis just refuses to guess.  It says that
> >the point (0,0) is not in the domain of the power function.  Why
> >should Fortran *OR* C++ wish to define something that classic math
> >itself leaves undefined?
>
> If some incautious user writes pow (0.0, 0.0), or pow (x, y) where x
> and y happen to be computed as 0.0, the library has to do something.

One question, though, is whether that something should be prescribed
by the C++ standard.  Note that the standard says nothing about what
the compiler is supposed to do with the expression "0. / 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Matt Austern wrote:
>
> zeisel@vai.co.at (Helmut Zeisel) writes:
>
> >
> > What is pow(zero1,zero2) for various types of 0 according to the draft standard?
> > a) 1  (my favorite solution - the compiler I tested did it also that way)
> > b) implementation dependent
> > c) Run time error
> > d) unspecified in the standard
>
> Unspecified in the standard.  As always, the committee didn't want to
> be innovative; Fortran doesn't specify it, so neither does C++.

In fact, the reason may be a fair bit more general than that.  There
is not a mathematically-unique candidate for the "correct answer" to
pow(0,0).

For example:   lim  pow(x,0) = 1
               x->0

but.........   lim  pow(0,y) = 0
               y->0

So which is the "right" answer?  But wait!  A case could be made for
every real number in between 0 and 1!  Now what answer would you
guess?

Classic mathematical analysis just refuses to guess.  It says that
the point (0,0) is not in the domain of the power function.  Why
should Fortran *OR* C++ wish to define something that classic math
itself leaves undefined?

---------------- Cray Research ---------------- ***    Roger Glover
***
---------- A Silicon Graphics Company ---------
http://home.cray.com/~glover
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

What is pow(zero1,zero2) for various types of 0 according to the draft standard?
a) 1 (my favorite solution - the compiler I tested did it also that way)
b) implementation dependent
c) Run time error
d) unspecified in the standard

(I posted a similar question already a week ago but no one answered)

Helmut Zeisel
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

zeisel@vai.co.at (Helmut Zeisel) writes:

>
> What is pow(zero1,zero2) for various types of 0 according to the draft standard?
> a) 1 (my favorite solution - the compiler I tested did it also that way)
> b) implementation dependent
> c) Run time error
> d) unspecified in the standard

Unspecified in the standard.  As always, the committee didn't want to
be innovative; Fortran doesn't specify it, so neither does C++.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]