f



0.0**0 = ?

I'm wondering if 0.0**0 (as opposed to 0.0**0.0) has the value 1 as
per fortran standard or if this is left to the compiler vendors
(different vendors do different things, unhappily).

Thanks,

Joost
0
jv244 (405)
10/4/2004 3:41:25 PM
comp.lang.fortran 11941 articles. 2 followers. Post Follow

25 Replies
2147 Views

Similar Articles

[PageSpeed] 55

Joost VandeVondele wrote:
> I'm wondering if 0.0**0 (as opposed to 0.0**0.0) has the value 1 as
> per fortran standard or if this is left to the compiler vendors
> (different vendors do different things, unhappily).
> 
> Thanks,
> 
> Joost

Surely, 0.0**0.0 is mathematically undefined? Therefore, I wouldn't 
expect the standard to make any pronouncement about the value.

cheers,

Rich

-- 
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]
0
rhdt (1081)
10/4/2004 3:55:05 PM
jv244@cam.ac.uk (Joost VandeVondele) writes:

> I'm wondering if 0.0**0 (as opposed to 0.0**0.0) has the value 1 as
> per fortran standard or if this is left to the compiler vendors
> (different vendors do different things, unhappily).

Well, it certainly doesn't have the value 1, because that's the wrong
type; the standard is pretty explicit about that.  It might have the
value 1.0, which I'm sure is what you meant.  Anyway...

No, the standard does not specify the value.  Note that the standard
doesn't tend to specify the values of floating point results at all,
other than to say that they are approximations to the mathematical
operations.  The "usual" comment is that the standard doesn't even
specify that 2.0+2.0 gives 4.0.  (And, indeed, the standard doesn't
require that 2.0 and 4.0 be exactly representable.)

Prior to f90, the standard did say something about 0.0**0, but what it
said wasn't what you want.  What it said was that it was illegal.
Thus, allowing it would be a processor extension, with the
interpretation up to the processor.  That prohibition was also in the
initial published f90, but I think there was a corregendum that
removed it.  I forget the exact timing of the removal - might have
been in f95, and it doesn't seem worth rtacking down.

In practice, I'd say that the removal of the restriction had no
concrete effect. Prior to the removal, programs that did such an
exponentiation were illegal, making it processor-dependent what
happened to them. After the removal, it was processor-depeendent
whether such an exponentiation was allowed or not. If there is
any real difference buried here, it is certainly a subtle and
egalistic one.  In neither case does the Fortran standard specify
the result.

I also long thought that the wording of that particular restriction
reflected a narrowness of viewpoint.  It said (quoting from f77)

  "Any arithmetic operation whose result is not mathematically
   defined is prohibited... Examples are dividing by zero and
   rasing a zero-valued primary to a zero-values or negative-valued
   power."

To me, this wording illustrated a narrow viewpoint of mathematics.
Indeed, the whole notion that there is a one and only one mathematical
definition is a viewpoint that I mostly associate with people who
aren't mathematicians. Mathematicians might point out that some
definitions are more useful in building a practical framework.

Note that, although this newsgroup is about Fortran, the Fortran
standard isn't the only relevant one in the world.  The IEEE
standard probably has more to say on this.  I didn't bother to go
check there, and I don't know my way around the find points of
that standard as well as I know Fortran, but it seems likely.
If a compiler is claimed to support the Fortran and IEEE standards,
you can legitimately bitch about violations of either one.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain
0
nospam47 (9747)
10/4/2004 4:18:05 PM
On Mon, 04 Oct 2004 11:55:05 -0400, Rich Townsend wrote:
> Joost VandeVondele wrote:
>> I'm wondering if 0.0**0 (as opposed to 0.0**0.0) has the value 1 as
>> per fortran standard or if this is left to the compiler vendors
>> (different vendors do different things, unhappily).
>> 
>> Thanks,
>> 
>> Joost

> Surely, 0.0**0.0 is mathematically undefined? Therefore, I wouldn't 
> expect the standard to make any pronouncement about the value.

Consider the following function.

  real(wp) function power(b,e)
    real(wp), intent(in) :: b
    integer, intent(in) :: e
    integer k
    if (e < 0) then
      power = 1.0_wp / product( (/ (b, k=1,abs(e)) /) )
    else
      power = product( (/ (b, k=1,e) /) )
    end if
  end function power

Obviously, no one would actually use such a convoluted method to compute
powers, but it does indisputably yield power(0.0_wp,0) = 1.0_wp.

The key fact is that an empty product evaluates to 1 (of the appropriate
type), and this is required by the Fortran standard.  It also agrees with
standard mathematical practice.



-- 
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/index.cfm?action=book&bookid=228>
0
dseaman (1174)
10/4/2004 6:13:11 PM
Dave Seaman wrote:
> On Mon, 04 Oct 2004 11:55:05 -0400, Rich Townsend wrote:
> 
>>Joost VandeVondele wrote:
>>
>>>I'm wondering if 0.0**0 (as opposed to 0.0**0.0) has the value 1 as
>>>per fortran standard or if this is left to the compiler vendors
>>>(different vendors do different things, unhappily).
>>>
>>>Thanks,
>>>
>>>Joost
> 
> 
>>Surely, 0.0**0.0 is mathematically undefined? Therefore, I wouldn't 
>>expect the standard to make any pronouncement about the value.
> 
> 
> Consider the following function.
> 
>   real(wp) function power(b,e)
>     real(wp), intent(in) :: b
>     integer, intent(in) :: e
>     integer k
>     if (e < 0) then
>       power = 1.0_wp / product( (/ (b, k=1,abs(e)) /) )
>     else
>       power = product( (/ (b, k=1,e) /) )
>     end if
>   end function power
> 
> Obviously, no one would actually use such a convoluted method to compute
> powers, but it does indisputably yield power(0.0_wp,0) = 1.0_wp.
> 
> The key fact is that an empty product evaluates to 1 (of the appropriate
> type), and this is required by the Fortran standard.  It also agrees with
> standard mathematical practice.

This is a nice example, but IMHO wrong. There's no such thing as 
"standard mathematical practice"; furthermore, the discussion here:

http://mathforum.org/dr.math/faq/faq.0.to.0.power.html

....makes it clear that 0^0 has an ambiguous definition at best, and is 
undefined at worst. From Richard Maine's post, I see that the standard 
states that:

   "Any arithmetic operation whose result is not mathematically
    defined is prohibited... Examples are dividing by zero and
    rasing a zero-valued primary to a zero-values or negative-valued
    power."

If one consideres 0^0 as one such "undefined operation", it would 
therefore appear that the standard prohibits it. I myself make a point 
of coding defensively, by putting in special casing to deal with 
situations where 0^0 might arise.

cheers,

Rich

-- 
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]
0
rhdt (1081)
10/4/2004 7:35:24 PM
Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:
  [about 0.0**0]
> From Richard Maine's post, I see that the standard
> states that:
....
> therefore appear that the standard prohibits it...

Do note that the quote in question was from old versions of the standard.
That quote is not in f95 or f2003 (and I think a corrigendum removed it
from f90).  The corresponding wording in the f95 and f2003 standards is

  "The execution of any numeric operation whose result is not defined
   by the arithmetic used by the processor is prohibited...."

Note that this wording refers to "the arithmetic used by the
processor" instead of presuming that there is a single, universally
defined answer.  Also note that the explicit mention of this
particular form was removed.

This generalization and removal of restriction was intentional,
making it processor-dependent instead of prohibited by the
standard.  As I mentioned, the distinction between processor-dependent
versus prohibited is perhaps a bit academic in practice, but still...
I don't think one can say that the current standard prohibits it.
Old standards (f77 and at least the first printimg of f90) did.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain
0
nospam47 (9747)
10/4/2004 8:00:14 PM
On Mon, 04 Oct 2004 15:35:24 -0400, Rich Townsend wrote:
> Dave Seaman wrote:
>> On Mon, 04 Oct 2004 11:55:05 -0400, Rich Townsend wrote:

>>>Joost VandeVondele wrote:

>>>>I'm wondering if 0.0**0 (as opposed to 0.0**0.0) has the value 1 as
>>>>per fortran standard or if this is left to the compiler vendors
>>>>(different vendors do different things, unhappily).

>>>>Thanks,

>>>>Joost


>>>Surely, 0.0**0.0 is mathematically undefined? Therefore, I wouldn't 
>>>expect the standard to make any pronouncement about the value.


>> Consider the following function.

>>   real(wp) function power(b,e)
>>     real(wp), intent(in) :: b
>>     integer, intent(in) :: e
>>     integer k
>>     if (e < 0) then
>>       power = 1.0_wp / product( (/ (b, k=1,abs(e)) /) )
>>     else
>>       power = product( (/ (b, k=1,e) /) )
>>     end if
>>   end function power

>> Obviously, no one would actually use such a convoluted method to compute
>> powers, but it does indisputably yield power(0.0_wp,0) = 1.0_wp.

>> The key fact is that an empty product evaluates to 1 (of the appropriate
>> type), and this is required by the Fortran standard.  It also agrees with
>> standard mathematical practice.

> This is a nice example, but IMHO wrong. There's no such thing as 
> "standard mathematical practice"; furthermore, the discussion here:

Are you claiming it is wrong for the Fortran standard to require empty
products to evaluate to 1?  This is indeed standard mathematical
practice, your protestations notwithstanding.  See, for example, Lang's
_Algebra_ in the chapter on monoids, where he defines m^0 = e (the
identity element) for every m in the monoid M.  The real numbers are a
multiplicative monoid with identity e = 1.0.

> http://mathforum.org/dr.math/faq/faq.0.to.0.power.html

> ...makes it clear that 0^0 has an ambiguous definition at best, and is 
> undefined at worst. From Richard Maine's post, I see that the standard 
> states that:

That FAQ page is adapted from the sci.math FAQ, which I had a hand in
writing.  I don't see anything there that says 0^0 is ambiguous, as long
as you distinguish between the *expression* 0^0 and the *indeterminate
form* 0^0 (which is relevant only when computing limits).  That page
gives a long list of reasons why 0^0 = 1 in the case where the exponent
is viewed as an integer (and therefore limits do not apply).

>    "Any arithmetic operation whose result is not mathematically
>     defined is prohibited... Examples are dividing by zero and
>     rasing a zero-valued primary to a zero-values or negative-valued
>     power."

You have quoted obsolete language from the f77 and f90 standards.  The
f95 standard specifically does not apply to the case of 0^0.  I thought
Richard Maine had already pointed that out.

> If one consideres 0^0 as one such "undefined operation", it would 
> therefore appear that the standard prohibits it. I myself make a point 
> of coding defensively, by putting in special casing to deal with 
> situations where 0^0 might arise.

The F95 standard specifically does not prohibit that operation.
Unfortunately, that means the result is implementation-dependent.
I claim that state of affairs is less than satisfactory.



-- 
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/index.cfm?action=book&bookid=228>
0
dseaman (1174)
10/4/2004 8:01:51 PM
Dave Seaman wrote:

<snip many well-made points>

> The F95 standard specifically does not prohibit that operation.
> Unfortunately, that means the result is implementation-dependent.
> I claim that state of affairs is less than satisfactory.
> 

Yes, I didn't read Richard Maine's post properly -- as both you and he 
point out, F95 has swithced from prohibiting 0^0 to making its value 
implementation dependent.

Aside from the mathematical issues of 0^0, which you explained very well 
(thanks!), the final part of my previous post was an attempt to make 
this point: Fortran + 0^0 = trouble, so the OP (Joost) needs to be using 
special-case code.

cheers,

Rich

-- 
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]
0
rhdt (1081)
10/4/2004 8:36:33 PM

Richard E Maine wrote:

(snip)

>   "The execution of any numeric operation whose result is not defined
>    by the arithmetic used by the processor is prohibited...."
> 
> Note that this wording refers to "the arithmetic used by the
> processor" instead of presuming that there is a single, universally
> defined answer.  Also note that the explicit mention of this
> particular form was removed.

There was a claim once in comp.lang.c that a C implementation
that returned 42. for all floating point computations would
be conforming.   It seems that on a processor with such
hardware, that would also be true for Fortran.

> This generalization and removal of restriction was intentional,
> making it processor-dependent instead of prohibited by the
> standard.  

 > As I mentioned, the distinction between processor-dependent
> versus prohibited is perhaps a bit academic in practice, but still...
> I don't think one can say that the current standard prohibits it.
> Old standards (f77 and at least the first printimg of f90) did.

There is also the change over the years for complex math functions
being done in hardware instead of subprograms.  Software implementations
could be expected to test that the parameters are valid.  With
hardware, you get what you get, and it seem that Fortran agrees.

-- glen


0
gah (12851)
10/4/2004 8:38:56 PM
"Joost VandeVondele" <jv244@cam.ac.uk> wrote in message
news:54661aa9.0410040741.2efedd39@posting.google.com...
> I'm wondering if 0.0**0 (as opposed to 0.0**0.0) has the value 1 as
> per fortran standard or if this is left to the compiler vendors
> (different vendors do different things, unhappily).
>

0**0=1. Knuth argued the case long ago. Matlab, Mathematica, C/C++, etc. do
likewise. If your Fortran compiler does otherwise, ditch it.


-- 
You're Welcome,
Gerry T.
______
"Facts are meaningless. You could use facts to prove anything that's even
remotely true." -- Homer Simpson.


0
gfthomas (618)
10/4/2004 10:16:48 PM
Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:

> Yes, I didn't read Richard Maine's post properly -- as both you and he
> point out, F95 has swithced from prohibiting 0^0 to making its value
> implementation dependent.

As long as I'm being pedantic...

This still isn't quite right. It is implementation-dependent
whether it is allowed or not.  That's not the same thing as saying
that its value is implementation-dependent.  This distiction can
matter in practice.

If it was just an implementation-dependent value, that would require
that the implementation accept the expression and produce some value.
As has been noted, 42.0 would do fine.  But it would not be allowed
for the implementation to abort or do things other than produce a
value.

Since it is implementation-dependent whether the expression is allowed,
that allows the implementation the freedom to produce a value or to
do anything else (such as abort).  This is thus even more implementation
dependent than just a value.

All of which is just to say that the Fortran standard guarantees even
less here than you might have thought.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain
0
nospam47 (9747)
10/4/2004 10:22:33 PM
Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote in message news:<cjrror$bqk$1@scrotar.nss.udel.edu>...
> <snip>
> Surely, 0.0**0.0 is mathematically undefined? Therefore, I wouldn't 
> expect the standard to make any pronouncement about the value.
> 
> cheers,
> 
> Rich
While (almost?) all mathematicians consider 0.0**0.0 undefined, the
same is not true of 0.0**0. Some define X**I, where X is a real number
and I is an integer to have the value 1.0 when x=0.0 and I=0. This is
justified by using limits based reasoning for function arguments that
are floats, and fixed values for integers, so that 0.0**0 should have
the value of lim(x**0, x->0+) i.e. 1.0. Similarly 0**0.0 should have
the value lim(0**x, x->0+), i.e., 0.0.
0
10/4/2004 11:05:05 PM
Gerry Thomas wrote:
> "Joost VandeVondele" <jv244@cam.ac.uk> wrote in message
> news:54661aa9.0410040741.2efedd39@posting.google.com...
> 
>>I'm wondering if 0.0**0 (as opposed to 0.0**0.0) has the value 1 as
>>per fortran standard or if this is left to the compiler vendors
>>(different vendors do different things, unhappily).
>>
> 
> 
> 0**0=1. Knuth argued the case long ago. Matlab, Mathematica, C/C++, etc. do
> likewise. If your Fortran compiler does otherwise, ditch it.
> 
> 

That's funny, Mathematica gives 0^0 as "Indeterminate". Once again, your 
mean, stupid little face is dripping with egg, you pathetic little man.

Aardpig
0
Aardpig
10/4/2004 11:11:00 PM
Richard E Maine <nospam@see.signature> wrote in message news:<m1mzz2e9tu.fsf@MLMCE0000L22801.local>...
> Note that, although this newsgroup is about Fortran, the Fortran
> standard isn't the only relevant one in the world.  The IEEE
> standard probably has more to say on this.  

The IEEE-754 standard doesn't address the issue of x**y, only
the elementary operations +, -, *, /, and sqrt.  The standard does provide
a useful way to define the results of expressions like 0.0**0.0, though.
For example, since lim x/y does not exist as (x,y) -> (0,0),
IEEE defines 0.0/0.0 as NaN (not a number).  

Since lim x**y does not have a unique value as (x,y)->(0,0), a reasonable
argument can be made that 0.0**0.0 should be NaN, too.

--Eric
0
ejko123 (56)
10/5/2004 4:13:56 AM
"Gerry Thomas" <gfthomas@sympatico.ca> wrote in message news:<5_j8d.12510$jj2.523749@news20.bellglobal.com>...

> 0**0=1. Knuth argued the case long ago. Matlab, Mathematica, C/C++, etc. do
> likewise. 

No, they don't.  Section 7.12.7.4 of the C standard states

   "The pow functions compute x to the power y.  A domain error
   occurs if x is finite and negative and y is finite and not
   an integer value.  A domain error may occur if x is zero and
   y is less than or equal to zero."

Some implementations, such as GNU, may choose to define pow(0.0,0.0)=1.0,
but this is an extension to the standard; portable programs cannot rely on it.

--Eric
0
ejko123 (56)
10/5/2004 4:45:35 AM
Eric K. wrote:
> "Gerry Thomas" <gfthomas@sympatico.ca> wrote in message
> news:<5_j8d.12510$jj2.523749@news20.bellglobal.com>...
>
>> 0**0=1. Knuth argued the case long ago. Matlab, Mathematica, C/C++, etc. do
>> likewise.
>
> No, they don't.  Section 7.12.7.4 of the C standard states
>
>    "The pow functions compute x to the power y.  A domain error
>    occurs if x is finite and negative and y is finite and not
>    an integer value.  A domain error may occur if x is zero and
>    y is less than or equal to zero."
>
> Some implementations, such as GNU, may choose to define pow(0.0,0.0)=1.0,
> but this is an extension to the standard; portable programs cannot rely on it.

Well, C is a little schizo on the subject.  Appendix F, (which is
marked normative) says that an implementation that defines
symbol _ _STDC_IEC_559_ _ must comply with the rules
specified in that appendix.  Among other requirements, they
have the rather peculiar requirement that pow(x,�0) must
return one for any x, even a NaN.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare


0
jamesgiles (2210)
10/5/2004 5:12:44 AM
"Eric K." <ejko123@yahoo.com> wrote in message
news:4ccbcc1c.0410042045.5c78ad27@posting.google.com...
> "Gerry Thomas" <gfthomas@sympatico.ca> wrote in message
news:<5_j8d.12510$jj2.523749@news20.bellglobal.com>...
>
> > 0**0=1. Knuth argued the case long ago. Matlab, Mathematica, C/C++,
etc. do
> > likewise.
>
> No, they don't.  Section 7.12.7.4 of the C standard states
>
>    "The pow functions compute x to the power y.  A domain error
>    occurs if x is finite and negative and y is finite and not
>    an integer value.  A domain error may occur if x is zero and
>    y is less than or equal to zero."
>
> Some implementations, such as GNU, may choose to define pow(0.0,0.0)=1.0,
> but this is an extension to the standard; portable programs cannot rely
on it.
>

Portability be damned, I care even less about the C standard than I do
about the Fortran's, any C/C++ compiler that I use sets pow(x,y) = 1 if y =
0.0, and =\ 0 or x = 0.0; if x = 0.0, and y < 0 it returns Inf, exactly
like Matlab. This suites me fine.

--
You're Welcome,
Gerry T.
______
"The most successful tyranny is not the one that uses force to assure
uniformity but the one that removes the awareness of other possibilities,
that makes it seem inconceivable that other ways are viable, that removes
the sense that there is an outside." -- Allan Bloom, in The Closing of the
American Mind.


0
gfthomas (618)
10/5/2004 5:28:47 AM
"Gerry Thomas" <gfthomas@sympatico.ca> writes:

> 0**0=1. Knuth argued the case long ago. Matlab, Mathematica, C/C++, etc. do
> likewise. 

Mathematica doesn't :
0^0, 0.^0, 0^0. and 0.^0. all return Indeterminate
-- 
Gareth Owen
Gratuitous Film Spoiler : Fight Club - He's beating himself up.
0
usenet8607 (54)
10/5/2004 9:35:52 AM
On 05 Oct 2004 10:35:52 +0100, Gareth Owen wrote:
> "Gerry Thomas" <gfthomas@sympatico.ca> writes:

>> 0**0=1. Knuth argued the case long ago. Matlab, Mathematica, C/C++, etc. do
>> likewise. 

> Mathematica doesn't :
> 0^0, 0.^0, 0^0. and 0.^0. all return Indeterminate

Which doesn't even make sense.  The value of an expression can be
undefined, but it cannot be indeterminate.  The phrase "indeterminate
form" applies only to the evaluation of limits, which is not the case
here.  You would think that the creators of Mathematica, in which there
is a "Limit" function specifically for the purpose of evaluating limits,
would be aware of the difference.

An indeterminate form can have a well defined limit.  A limit can also be
undefined without being an indeterminate form.  And "indeterminate" is
never the final outcome of a limit calculation; either the limit exists,
or it doesn't.  An "indeterminate form" simply means that you need to
find another way to evaluate the limit.

I submitted a bug report to Wolfram many years ago, but they are not
listening.

And for another data point, the Common Lisp standard requires that zero
to the zero must return 1 if the exponent is integer, but is an error if
the exponent is real.

(expt 0 0)	=> 1
(expt 0.0 0)	=> 1.0
(expt 0 0.0)	=> error
(expt 0.0 0.0)	=> error


-- 
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/index.cfm?action=book&bookid=228>
0
dseaman (1174)
10/5/2004 1:13:42 PM
Dave Seaman <dseaman@no.such.host> writes:

> On 05 Oct 2004 10:35:52 +0100, Gareth Owen wrote:
> > "Gerry Thomas" <gfthomas@sympatico.ca> writes:
> 
> >> 0**0=1. Knuth argued the case long ago. Matlab, Mathematica, C/C++, etc. do
> >> likewise. 
> 
> > Mathematica doesn't :
> > 0^0, 0.^0, 0^0. and 0.^0. all return Indeterminate
> 
> Which doesn't even make sense.  

Well, thats true, if you presume Mathematica and mathematicians use the word
Indeterminate to mean exactly the same thing as one another.  Which they don't.
-- 
Gareth Owen
If I were to ask you a hypothetical question, would you answer it? 
0
usenet8607 (54)
10/5/2004 1:19:34 PM
Gerry Thomas wrote:
> "Eric K." <ejko123@yahoo.com> wrote in message
> news:4ccbcc1c.0410042045.5c78ad27@posting.google.com...
> 
>>"Gerry Thomas" <gfthomas@sympatico.ca> wrote in message
> 
> news:<5_j8d.12510$jj2.523749@news20.bellglobal.com>...
> 
>>>0**0=1. Knuth argued the case long ago. Matlab, Mathematica, C/C++,
> 
> etc. do
> 
>>>likewise.
>>
>>No, they don't.  Section 7.12.7.4 of the C standard states
>>
>>   "The pow functions compute x to the power y.  A domain error
>>   occurs if x is finite and negative and y is finite and not
>>   an integer value.  A domain error may occur if x is zero and
>>   y is less than or equal to zero."
>>
>>Some implementations, such as GNU, may choose to define pow(0.0,0.0)=1.0,
>>but this is an extension to the standard; portable programs cannot rely
> 
> on it.
> 
> 
> Portability be damned, I care even less about the C standard than I do
> about the Fortran's, any C/C++ compiler that I use sets pow(x,y) = 1 if y =
> 0.0, and =\ 0 or x = 0.0; if x = 0.0, and y < 0 it returns Inf, exactly
> like Matlab. This suites me fine.

Foot in your mouth, Gerry -- you were wrong about Mathematica, and 
you're now wrong about C/C++. What your compiler does is not relevant here.

If I were you, I'd stop posting to c.l.f; you make an utter fool of 
yourself every time you do so.

Aardpig
0
Aardpig
10/5/2004 1:43:45 PM
>> 0^0, 0.^0, 0^0. and 0.^0. all return Indeterminate
>
>Which doesn't even make sense.  The value of an expression can be
>undefined, but it cannot be indeterminate.

IEEE math. has special values for a number that cannot be determined,
such as infinity*zero or infinity-infinity -- that value is called
IND which is short for indeterminate AFAIK.   Many computer programs
will output +IND or -IND or just IND if given one of these special
values, just as they will often output INF or +INF or -INF when
given one of the IEEE standard's infinite values.  

Of course, many people are sloppy about the distinctions between
IND, NaN &c.  Just as many people are sloppy about the similar
mathematical distinctions and domains of applicability.

YMMV
0
kgrhoads (401)
10/5/2004 2:27:08 PM
On 05 Oct 2004 14:19:34 +0100, Gareth Owen wrote:
> Dave Seaman <dseaman@no.such.host> writes:

>> On 05 Oct 2004 10:35:52 +0100, Gareth Owen wrote:
>> > "Gerry Thomas" <gfthomas@sympatico.ca> writes:
>> 
>> >> 0**0=1. Knuth argued the case long ago. Matlab, Mathematica, C/C++, etc. do
>> >> likewise. 
>> 
>> > Mathematica doesn't :
>> > 0^0, 0.^0, 0^0. and 0.^0. all return Indeterminate
>> 
>> Which doesn't even make sense.  

> Well, thats true, if you presume Mathematica and mathematicians use the word
> Indeterminate to mean exactly the same thing as one another.  Which they don't.

It's obvious that Mathematica does not use the word Indeterminate the way
mathematicians do.  That was my point.


-- 
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/index.cfm?action=book&bookid=228>
0
dseaman (1174)
10/5/2004 2:54:37 PM
On Tue, 05 Oct 2004 14:27:08 +0000, Kevin G. Rhoads wrote:
>>> 0^0, 0.^0, 0^0. and 0.^0. all return Indeterminate
>>
>>Which doesn't even make sense.  The value of an expression can be
>>undefined, but it cannot be indeterminate.

> IEEE math. has special values for a number that cannot be determined,
> such as infinity*zero or infinity-infinity -- that value is called
> IND which is short for indeterminate AFAIK.   

IND stands for "indefinite," which is not the same thing.
"Indeterminate" applies only to limit operations, which do not exist in
IEEE arithmetic.


-- 
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/index.cfm?action=book&bookid=228>
0
dseaman (1174)
10/5/2004 4:02:28 PM
"Dave Seaman" <dseaman@no.such.host> wrote in message
news:cju6m6$oum$2@mozo.cc.purdue.edu...
> On 05 Oct 2004 10:35:52 +0100, Gareth Owen wrote:
> > "Gerry Thomas" <gfthomas@sympatico.ca> writes:
>
> >> 0**0=1. Knuth argued the case long ago. Matlab, Mathematica, C/C++,
etc. do
> >> likewise.
>
> > Mathematica doesn't :
> > 0^0, 0.^0, 0^0. and 0.^0. all return Indeterminate
>
> Which doesn't even make sense.  The value of an expression can be
> undefined, but it cannot be indeterminate.  The phrase "indeterminate
> form" applies only to the evaluation of limits, which is not the case
> here.  You would think that the creators of Mathematica, in which there
> is a "Limit" function specifically for the purpose of evaluating limits,
> would be aware of the difference.
>
> An indeterminate form can have a well defined limit.  A limit can also be
> undefined without being an indeterminate form.  And "indeterminate" is
> never the final outcome of a limit calculation; either the limit exists,
> or it doesn't.  An "indeterminate form" simply means that you need to
> find another way to evaluate the limit.
>
> I submitted a bug report to Wolfram many years ago, but they are not
> listening.

Ah, now I see that I gave Mathematica more credit than was it due.

BTW, even VB sets 0^0 = 1.

-- 
You're Welcome,
Gerry T.
______
"It is dangerous to be right in matters on which the established
authorities are wrong." --  Voltaire.


0
gfthomas (618)
10/5/2004 4:44:04 PM
In article <r5i655pjymf.fsf@gill.maths.keele.ac.uk>,
Gareth Owen  <usenet@gwowen.freeserve.co.uk> wrote:
>"Gerry Thomas" <gfthomas@sympatico.ca> writes:
>
>> 0**0=1. Knuth argued the case long ago. Matlab, Mathematica, C/C++, etc. do
>> likewise. 
>
>Mathematica doesn't :
>0^0, 0.^0, 0^0. and 0.^0. all return Indeterminate

Maple, in which I = Fortran's CMPLX(0,1), has changed what it does.
In Maple V release 5, 0^0, 0.^0, 0^0., (I*0.)^0. and 0^(I*0.) all gave
   Error, 0^0 is undefined 
But now, in Maple 9.5, those 5 expressions give 5 different results:
0^0 returns 1 
0.^0 returns 1. 
0^0. returns Float(undefined)
(I*0.)^0. returns Float(undefined) + 0. I
0^(I*0.) returns Float(undefined) + Float(undefined) I

John Harper, School of Mathematics, Statistics and Computer Science, 
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
0
harper (719)
10/6/2004 1:25:37 AM
Reply: