On 2005-03-13 15:26:05 +0100, Gabriel Dos Reis wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> | When one uses the power notation in mathematics, one (almost) never
> | says when the context is a function R x R -> R or R x Z -> R or
> | whatever.
>
> That is (almost) absolutely false.
Your
Ronny Peine <[EMAIL PROTECTED]> writes:
> | Well yes in the general case it's not applieable, but x^0 is 1 in the
> | complex case, too.
On Thu, Mar 17, 2005 at 01:08:58PM +0100, Gabriel Dos Reis wrote:
> Just repeating it does not make it a reality.
However, repeating it does annoy the readersh
Ronny Peine <[EMAIL PROTECTED]> writes:
| Dave Korn wrote:
| > Original Message
| >
| >>From: Ronny Peine
| >>Sent: 16 March 2005 17:34
| >
| >>See for example:
| >>http://mathworld.wolfram.com/ExponentLaws.html
| >>
| > Ok, I did.
| >
| >> Even though, gcc returns 1 for pow(0.0,0.0) in
Dave Korn wrote:
Original Message
From: Ronny Peine
Sent: 16 March 2005 17:34
See for example:
http://mathworld.wolfram.com/ExponentLaws.html
Ok, I did.
Even though, gcc returns 1 for pow(0.0,0.0) in version 3.4.3 like many
other c-compiler do. The same behaviour would be expected fr
Original Message
>From: Ronny Peine
>Sent: 16 March 2005 17:34
> See for example:
> http://mathworld.wolfram.com/ExponentLaws.html
>
Ok, I did.
>Even though, gcc returns 1 for pow(0.0,0.0) in version 3.4.3 like many
>other c-compiler do. The same behaviour would be expected from cpow.
Ronny Peine <[EMAIL PROTECTED]> writes:
| Hi,
|
| Kai Henningsen wrote:
| > [EMAIL PROTECTED] (Robert Dewar) wrote on 07.03.05 in <[EMAIL PROTECTED]>:
| >
| >>Ronny Peine wrote:
| >>
| >>
| >>>Sorry for this, maybe i should sleep :) (It's 2 o'clock here)
| >>>But as i know of 0^0 is defined as 1
Hi,
Kai Henningsen wrote:
[EMAIL PROTECTED] (Robert Dewar) wrote on 07.03.05 in <[EMAIL PROTECTED]>:
Ronny Peine wrote:
Sorry for this, maybe i should sleep :) (It's 2 o'clock here)
But as i know of 0^0 is defined as 1 in every lecture i had so far.
Were these math classes, or CS classes.
Let's
On Sat, 12 Mar 2005 03:02:20 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> said:
> David Carlton <[EMAIL PROTECTED]> writes:
>> On Thu, 10 Mar 2005 15:54:03 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]>
>> said:
>>> Vincent Lefevre <[EMAIL PROTECTED]> writes:
On 2005-03-10 01:01:18 +0100, Gabriel
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sun, 2005-03-13 at 15:26 +0100, Gabriel Dos Reis wrote:
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| >
| > | On 2005-03-12 02:59:46 +0100, Gabriel Dos Reis wrote:
| > | > You probably noticed that in the polynomial expansion, you are using
| > |
> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
>> Paul Schlie <[EMAIL PROTECTED]> writes:
> | > From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> | > |Paul Schlie <[EMAIL PROTECTED]> writes:
> | > | Thank you. In essence, I've intentionally defined the question of x^y's
> | > | value about x=y->0 as a con
On Sun, 2005-03-13 at 15:26 +0100, Gabriel Dos Reis wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
>
> | On 2005-03-12 02:59:46 +0100, Gabriel Dos Reis wrote:
> | > You probably noticed that in the polynomial expansion, you are using
> | > an integer power -- which everybody agrees on yield
Paul Schlie <[EMAIL PROTECTED]> writes:
| > From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| > |Paul Schlie <[EMAIL PROTECTED]> writes:
| > | Thank you. In essence, I've intentionally defined the question of x^y's
| > | value about x=y->0 as a constrained "bivariate" function, to where only
| > | the
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-12 02:59:46 +0100, Gabriel Dos Reis wrote:
| > You probably noticed that in the polynomial expansion, you are using
| > an integer power -- which everybody agrees on yield 1 at the limit.
| >
| > I'm tlaking about 0^0, when you look at the
Vincent Lefevre wrote:
in some standard C program. Could/does gcc 4.0 generate special code,
taking into account the fact that 6.0 is a small integer?
Ah, that does already: have a look to builtins.c, expand_builtin_pow in
particular.
Paolo.
On 2005-03-12 02:59:46 +0100, Gabriel Dos Reis wrote:
> You probably noticed that in the polynomial expansion, you are using
> an integer power -- which everybody agrees on yield 1 at the limit.
>
> I'm tlaking about 0^0, when you look at the limit of function x^y
> -- which is closer to cpow() tg
On 2005-03-10 18:05:24 +0100, Paolo Carlini wrote:
> Vincent Lefevre wrote:
> >BTW, couldn't it be used when compiling C programs too?
> >Is there anything planned?
> >
> Can be used as any other __builtin_*: just call it ;)
But this wouldn't be portable. I mean:
double x, y;
...
y = pow(x, 6
> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> |Paul Schlie <[EMAIL PROTECTED]> writes:
> | Thank you. In essence, I've intentionally defined the question of x^y's
> | value about x=y->0 as a constrained "bivariate" function, to where only
> | the direction, not the relative rate of the argument's
Paul Schlie <[EMAIL PROTECTED]> writes:
[...]
| > You've transmuted the function x^y to the function x^x which is a
| > different beast. Existing of limit of the latter does not imply
| > existance of limit of the former. Again check the counterexamples in
| > the message I referred to above.
|
[EMAIL PROTECTED] (Robert Dewar) wrote on 07.03.05 in <[EMAIL PROTECTED]>:
> Ronny Peine wrote:
>
> > Sorry for this, maybe i should sleep :) (It's 2 o'clock here)
> > But as i know of 0^0 is defined as 1 in every lecture i had so far.
>
> Were these math classes, or CS classes.
Let's just say t
> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
>> Paul Schlie <[EMAIL PROTECTED]> writes:
> | > Gabriel Dos Reis wrote:
> | > You probably noticed that in the polynomial expansion, you are using
> | > an integer power -- which everybody agrees on yield 1 at the limit.
> | >
> | > I'm tlaking about 0^
Paul Schlie <[EMAIL PROTECTED]> writes:
| > Gabriel Dos Reis wrote:
| > You probably noticed that in the polynomial expansion, you are using
| > an integer power -- which everybody agrees on yield 1 at the limit.
| >
| > I'm tlaking about 0^0, when you look at the limit of function x^y
|
| Out of
> Gabriel Dos Reis wrote:
> You probably noticed that in the polynomial expansion, you are using
> an integer power -- which everybody agrees on yield 1 at the limit.
>
> I'm tlaking about 0^0, when you look at the limit of function x^y
Out of curiosity, on what basis can one conclude:
lim{|x|==
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-10 15:29:49 +0100, Paolo Carlini wrote:
| > Vincent Lefevre wrote:
| > >What is powi()? I couldn't find it in the C standard. It isn't
| > >in the Linux man pages either.
| > >
| > ;) It's just a new builtin that we have in mainline, very us
David Carlton <[EMAIL PROTECTED]> writes:
| On Thu, 10 Mar 2005 15:54:03 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> said:
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| > | On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote:
|
| > | > The asseryion that 0^0 is mathematically undefined is no
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-10 15:54:03 +0100, Gabriel Dos Reis wrote:
| > The C standard is not the holy bible and certainly does not define
| > everything. We're talking about compiler construction, here.
|
| This isn't just compiler construction. __builtin_cpow is
On Thu, 10 Mar 2005 15:54:03 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> said:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> | On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote:
> | > The asseryion that 0^0 is mathematically undefined is not a bogus
> | > reason. It is a fact.
> |
> | I disa
Vincent Lefevre wrote:
BTW, couldn't it be used when compiling C programs too?
Is there anything planned?
Can be used as any other __builtin_*: just call it ;)
By the way, it's also in 4.0, not only mainline.
Paolo.
On 2005-03-10 15:29:49 +0100, Paolo Carlini wrote:
> Vincent Lefevre wrote:
> >What is powi()? I couldn't find it in the C standard. It isn't
> >in the Linux man pages either.
> >
> ;) It's just a new builtin that we have in mainline, very useful for
> implementing the integer power overloads manda
On 2005-03-10 15:54:03 +0100, Gabriel Dos Reis wrote:
> The C standard is not the holy bible and certainly does not define
> everything. We're talking about compiler construction, here.
This isn't just compiler construction. __builtin_cpow is equivalent
to the C99 cpow (as said in gcc/doc/extend.
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote:
| > No. I mean when I call powi() either through built-ins or appropriate
| > overload (several programming languages do so), I expect sane semantics.
|
| What is powi()? I couldn't find it in the
Vincent Lefevre wrote:
On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote:
No. I mean when I call powi() either through built-ins or appropriate
overload (several programming languages do so), I expect sane semantics.
What is powi()? I couldn't find it in the C standard. It isn't
in the
On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote:
> No. I mean when I call powi() either through built-ins or appropriate
> overload (several programming languages do so), I expect sane semantics.
What is powi()? I couldn't find it in the C standard. It isn't
in the Linux man pages either.
>
On Mar 9, 2005, at 03:18, Duncan Sands wrote:
if the Ada front-end has an efficient, accurate implementation
of x^y, wouldn't it make sense to move it to the back-end
(__builtin_pow) so everyone can benefit?
Does not have it yet. Current implementation is reasonably accurate,
but not very fast. How
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-09 17:37:59 +0100, Gabriel Dos Reis wrote:
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| > | Well, mathematically, you can distinguish these two functions:
| > |
| > | powrr: RxR -> R (not defined on (0,0) in particular)
| > |
| > |
On 2005-03-09 17:37:59 +0100, Gabriel Dos Reis wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> | Well, mathematically, you can distinguish these two functions:
> |
> | powrr: RxR -> R (not defined on (0,0) in particular)
> |
> | and
> |
> | powrz: RxZ -> R (where powint(0,0) = 1)
> |
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-09 12:45:57 +0100, Duncan Sands wrote:
| > The problem is x^0.0 (real exponent), not x^0 (integer exponent).
|
| Well, mathematically, you can distinguish these two functions:
|
| powrr: RxR -> R (not defined on (0,0) in particular)
|
|
Duncan Sands wrote:
if the Ada front-end has an efficient, accurate implementation
of x^y, wouldn't it make sense to move it to the back-end
(__builtin_pow) so everyone can benefit?
I don't know how efficient or accurate the current implementation
is (we are in the process of redoing our math routi
On 2005-03-09 12:45:57 +0100, Duncan Sands wrote:
> The problem is x^0.0 (real exponent), not x^0 (integer exponent).
Well, mathematically, you can distinguish these two functions:
powrr: RxR -> R (not defined on (0,0) in particular)
and
powrz: RxZ -> R (where powint(0,0) = 1)
and even oth
> On the one hand, as said above, there is no way of defining 0^0
> using continuity, but on the other hand, many important properties
> remain satisfied if we choose 0^0 = 1 (which is frequently
> adopted, as a convention, by mathematicians). Kahan suggests to
> choose 0^0 = 1.
On 2005-03-07 17:09:46 +0100, Duncan Sands wrote:
> Mathematically speaking zero^zero is undefined, so it should be NaN.
[...]
Mathematically, this is just about conventions. But the main problem
here is that the power function is overloaded. For instance, you can
use pow() to compute x^i, where i
Hi Robert,
> >>Well if you tell me there are people about there implementing cpow
> >>with log and exp, that's enough for me to decide that Ada should
> >>continue to stay away (the Ada RM has accuracy requirements that
> >>would preclude a broken implementation of this kind) :-)
> >
> >
> > the
> Ronny Peine
>
> Maybe i found something:
>
> http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
> page 9 says:
>
> "A number of real expressions are sometimes implemented as INVALID
> by mistake, or declared Undefined by illconsidered
> language standards; a few examples are ...
> 0.0**
Duncan Sands wrote:
Hi Robert,
Well if you tell me there are people about there implementing cpow
with log and exp, that's enough for me to decide that Ada should
continue to stay away (the Ada RM has accuracy requirements that
would preclude a broken implementation of this kind) :-)
the referenc
Hi Robert,
> Well if you tell me there are people about there implementing cpow
> with log and exp, that's enough for me to decide that Ada should
> continue to stay away (the Ada RM has accuracy requirements that
> would preclude a broken implementation of this kind) :-)
the reference manual all
This proof is absolutely correct and in no way bogus, it is lectured to
nearly every mathematics student PERIOD
But you are right, if the standards handles this otherwise, then this
doesn't help in any case.
Robert Dewar wrote:
Ronny Peine wrote:
I hope that this make things clearer for some who
Ronny Peine wrote:
I hope that this make things clearer for some who don't believe 0^0 = 1
in the real case.
Believe??? so now its a matter of religeon. Anyway, your bogus proof is
irrelevant for the real case, since the language standard is clear in
the real case anyway. It really is completely p
Paolo Carlini wrote:
Duncan Sands wrote:
aren't __builtin_cpow and friends language independent? I mean, if a
front-end sees a x^y then presumably it ends up being turned into a
call to a __builtin_?pow by the back-end. If so, then conforming to
the C99 and C++ standards isn't enough: the standar
Maybe i should make it more clearer, why 0^x is not defined for real
exponents x, and not continual in any way.
Be G a set ("Menge" in german) and op : G x G -> G, (a,b) -> a op b.
If op is associative than (G,op) is called a half-group.
Therefore then exponentiation is defined as:
a from G, n fr
Duncan Sands wrote:
aren't __builtin_cpow and friends language independent? I mean, if a
front-end sees a x^y then presumably it ends up being turned into a
call to a __builtin_?pow by the back-end. If so, then conforming to
the C99 and C++ standards isn't enough: the standards for all gcc
suppor
Hi Paolo,
> > What we are debating here isn't really maths at all, just the
> > definition which will be most useful and least suprising (and perhaps
> > also what various standards tell us to use).
>
> Also, since we are definitely striving to consistently implement the
> current C99 and C++
Well, you are right, this discussion becomes a bit off topic.
I think 0^0 should be 1 in the complex case, too. Otherwise the complex
and real definitions would collide.
Example:
use complex number 0+i*0 then this should be handled equivalent to the
real number 0. Otherwise the programmer would get
Chris Jefferson wrote:
What we are debating here isn't really maths at all, just the
definition which will be most useful and least suprising (and perhaps
also what various standards tell us to use).
Also, since we are definitely striving to consistently implement the
current C99 and C++ Standar
Ronny Peine wrote:
Well, i'm studying mathematics and as i know so far 0^0 is always 1
(for real and complex numbers) and well defined even in numerical and
theoretical mathematics. Could you point me to some publications which
say other things?
cu, Ronny
Just wanting to put in my mathematical
Ronny Peine wrote:
Well, i'm studying mathematics and as i know so far 0^0 is always 1
(for real and complex numbers) and well defined even in numerical and
theoretical mathematics. Could you point me to some publications which
say other things?
cu, Ronny
Just wanting to put in my mathematical
Ronny Peine wrote:
Well this article was referenced by http://grouper.ieee.org/groups/754/,
so i don't think it's an unreliable source.
Since Kahan is one of the primary movers behind 754 that's not so
surprising.
For me, 754 is authoritative significantly because of this connection.
If there wer
Well this article was referenced by http://grouper.ieee.org/groups/754/,
so i don't think it's an unreliable source.
It would be nice if you wouldn't try to insult me Joe Buck, that's not
very productive.
Robert Dewar wrote:
Marcin Dalecki wrote:
Are we a bit too obedient today? Look I was talk
Hi Florian,
> From a mathematical point of view, 0^0 = 1 is the more convenient one
> in most contexts. Otherwise, you suddenly lack a compact notation of
> polynomials (and power series). However, this definition is only used
> in a context were the exponent is an integer, so it's not really
>
Florian Weimer wrote:
* Robert Dewar:
Marcin Dalecki wrote:
There is no reason here and you presented no reasoning. But still
there is a
*convenient* extension of the definition domain for the power of
function for the
zero exponent.
The trouble is that there are *two* possible convenient extensi
* Robert Dewar:
> Marcin Dalecki wrote:
>
>> There is no reason here and you presented no reasoning. But still
>> there is a
>> *convenient* extension of the definition domain for the power of
>> function for the
>> zero exponent.
>
> The trouble is that there are *two* possible convenient extensi
Marcin Dalecki wrote:
Are we a bit too obedient today? Look I was talking about the paper
presented
above not about the author there of.
But a paper like this must be read in context, and if you don't
know who the author is, you
a) don't have the context to read the paper
b) you show yourself to b
Hi Robert,
> > It's not true because it's neither true nor false. It's a not well
> > formulated statement. (Mathematically).
>
> I disagree with this, we certainly agree that 0.0 ** negative value
> is undefined, i.e. that this is outside the domain of the ** function,
> and I think normally in
On 2005-03-08, at 05:06, David Starner wrote:
The author's opinion comes from experience in the field. When someone
with a lot of experience talks, wise people listen, if they don't
agree in the end. I see no reason to casually dismiss that article.
My point is that there are really few hard argume
On Tue, 8 Mar 2005 04:18:44 +0100, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
> Are we a bit too obedient today? Look I was talking about the paper
> presented
> above not about the author there of.
Since we're getting personal, you've been terse, hostile and
dismissive this entire thread, and it h
On 2005-03-08, at 04:07, David Starner wrote:
On Tue, 8 Mar 2005 03:24:35 +0100, Marcin Dalecki <[EMAIL PROTECTED]>
wrote:
On 2005-03-08, at 02:55, Ronny Peine wrote:
Maybe i found something:
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
page 9 says:
Lot's of opinions few hard argume
On Tue, 8 Mar 2005 03:24:35 +0100, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
>
> On 2005-03-08, at 02:55, Ronny Peine wrote:
>
> > Maybe i found something:
> >
> > http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
> > page 9 says:
>
> Lot's of opinions few hard arguments... I see there
On 2005-03-08, at 02:55, Ronny Peine wrote:
Maybe i found something:
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
page 9 says:
Lot's of opinions few hard arguments... I see there.
I wouldn't consider the above mentioned paper authoritative in any way.
Maybe i found something:
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
page 9 says:
"A number of real expressions are sometimes implemented as INVALID
by mistake, or declared Undefined by illconsidered
language standards; a few examples are ...
0.0**0.0 = inf**0.0 = NaN**0.0 = 1.0, no
Hi again,
a small example often used in mathematics and electronic engineering:
the geometric row ("Reihe" in german, i don't know the correct
expression in english):
sum from k=0 to +unlimited q^k = 1/(1-q) if |q|<1.
this is also correct for q=0 where the sum gives q^0+q^1+q^2+...= 1 + 0
+ 0 +
Well, these were math lectures (Analysis 1,2 and 3, Function Theory,
Numerical Mathematics and so on). In every lectures it was defined as 1
and in most cases mathematical expressions are mostly tried to transform
in equivalent calculations for the FPU (even though associativity is for
example
Ronny Peine wrote:
Sorry for this, maybe i should sleep :) (It's 2 o'clock here)
But as i know of 0^0 is defined as 1 in every lecture i had so far.
Were these math classes, or CS classes.
Generally when you have a situation like this, where the value of
the function is different depending on how y
On 2005-03-08, at 02:01, Robert Dewar wrote:
Yes, and usually by definition in mathematics 0**0 is outside the
domain
of the exponentiation operator.
Usually the domain of the function in question with possible extensions
there of is given explicitly where such a function is in use.
"There is no r
Ronny Peine wrote:
Joe Buck wrote:
On Tue, Mar 08, 2005 at 01:47:13AM +0100, Ronny Peine wrote:
Hi again,
a small proof.
if A and X are real numbers and A>0 then
A^X := exp(X*ln(A)) (Definition in analytical mathematics).
That is an incomplete definition, as 0^X is well-defined.
0^0 = lim A->0,
Ronny Peine wrote:
I don't think it's hidden. The former definiton is absolutely right.
Yes, but the argument by limits is specious, and indeed as already
shown in this thread, can lead to one of two answers. Just because
a function approaches the value X at point Y does not mean it has
the value X
Joe Buck wrote:
On Tue, Mar 08, 2005 at 01:47:13AM +0100, Ronny Peine wrote:
Hi again,
a small proof.
if A and X are real numbers and A>0 then
A^X := exp(X*ln(A)) (Definition in analytical mathematics).
That is an incomplete definition, as 0^X is well-defined.
0^0 = lim A->0, A>0 (exp(0*ln(A)) =
Marcin Dalecki wrote:
It's not a matter of reason it's a matter of definition. Thus the
statement "This is why there is no reasonable mathematical value for 0^0
is neither true nor false", has the same sense as saying that... well
for example:
"rose bears fly very high". Just a random alliteration
On Tue, Mar 08, 2005 at 01:47:13AM +0100, Ronny Peine wrote:
> Hi again,
>
> a small proof.
>
> if A and X are real numbers and A>0 then
>
> A^X := exp(X*ln(A)) (Definition in analytical mathematics).
That is an incomplete definition, as 0^X is well-defined.
> 0^0 = lim A->0, A>0 (exp(0*ln(A))
Hi,
Marcin Dalecki wrote:
On 2005-03-08, at 01:47, Ronny Peine wrote:
Hi again,
a small proof.
How cute.
if A and X are real numbers and A>0 then
A^X := exp(X*ln(A)) (Definition in analytical mathematics).
0^0 = lim A->0, A>0 (exp(0*ln(A)) = 1 if exp(X*ln(A)) is continual
continued
The complex c
On 2005-03-08, at 01:47, Ronny Peine wrote:
Hi again,
a small proof.
How cute.
if A and X are real numbers and A>0 then
A^X := exp(X*ln(A)) (Definition in analytical mathematics).
0^0 = lim A->0, A>0 (exp(0*ln(A)) = 1 if exp(X*ln(A)) is continual
continued
The complex case can be derived from thi
On 2005-03-08, at 01:21, Robert Dewar wrote:
Paolo Carlini wrote:
Interesting, thanks. The problem is, since the C standard is
admittedly
rather vague in this area, some implementation of the C library simply
implement the basic formula (i.e., cexp(c*clog(z))) and don't deal
*at all*
with special
Hi again,
a small proof.
if A and X are real numbers and A>0 then
A^X := exp(X*ln(A)) (Definition in analytical mathematics).
0^0 = lim A->0, A>0 (exp(0*ln(A)) = 1 if exp(X*ln(A)) is continual continued
The complex case can be derived from this (0^(0+ib) = 0^0*0^ib = 1 =
0^a*0^(i*0) ).
Well, i kno
On 2005-03-08, at 01:14, Robert Dewar wrote:
Marcin Dalecki wrote:
On 2005-03-07, at 17:16, Chris Jefferson wrote:
| This is why there is no reasonable
| mathematical value for 0^0.
|
That is true.
It's not true because it's neither true nor false. It's a not well
formulated statement. (Mathematica
On 2005-03-08, at 01:11, Robert Dewar wrote:
Marcin Dalecki wrote:
There is no reason here and you presented no reasoning. But still
there is a
*convenient* extension of the definition domain for the power of
function for the
zero exponent.
The trouble is that there are *two* possible convenient
Paolo Carlini wrote:
Interesting, thanks. The problem is, since the C standard is admittedly
rather vague in this area, some implementation of the C library simply
implement the basic formula (i.e., cexp(c*clog(z))) and don't deal *at all*
with special cases. This leads *naturally* to (nan, nan).
I
Robert Dewar wrote:
However, the one chosen by the C standard has indeed become pretty
prevalent (the Ada RM for instance specifies that 0**0 = 1 (applies
to complex case as well).
Interesting, thanks. The problem is, since the C standard is admittedly
rather vague in this area, some implementation
Marcin Dalecki wrote:
On 2005-03-07, at 17:16, Chris Jefferson wrote:
| Mathematically speaking zero^zero is undefined, so it should be NaN.
| This already clear for real numbers: consider x^0 where x decreases
| to zero. This is always 1, so you could deduce that 0^0 should be 1.
| However, consi
Marcin Dalecki wrote:
There is no reason here and you presented no reasoning. But still there
is a
*convenient* extension of the definition domain for the power of
function for the
zero exponent.
The trouble is that there are *two* possible convenient extensions.
However, the one chosen by the C
Well, i'm studying mathematics and as i know so far 0^0 is always 1 (for
real and complex numbers) and well defined even in numerical and
theoretical mathematics. Could you point me to some publications which
say other things?
cu, Ronny
Duncan Sands wrote:
On Mon, 2005-03-07 at 10:51 -0500, Rob
On 2005-03-07, at 17:16, Chris Jefferson wrote:
| Mathematically speaking zero^zero is undefined, so it should be NaN.
| This already clear for real numbers: consider x^0 where x decreases
| to zero. This is always 1, so you could deduce that 0^0 should be 1.
| However, consider 0^x where x decrea
On 2005-03-07, at 17:31, Duncan Sands wrote:
I would agree with Paolo that the most imporant point is arguably
consistency, and it looks like that is pow(0.0,0.0)=1
just so long as everyone understands that they are upholding the
standard, not mathematics, then that is fine by me :)
All the best,
D
On 2005-03-07, at 17:09, Duncan Sands wrote:
Mathematically speaking zero^zero is undefined, so it should be NaN.
I don't see the implication here. Thus this certain is no
"mathematical" speak.
This already clear for real numbers: consider x^0 where x decreases
to zero. This is always 1, so you
Hi Chris,
> | Mathematically speaking zero^zero is undefined, so it should be NaN.
> | This already clear for real numbers: consider x^0 where x decreases
> | to zero. This is always 1, so you could deduce that 0^0 should be 1.
> | However, consider 0^x where x decreases to zero. This is always
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan Sands wrote:
| On Mon, 2005-03-07 at 10:51 -0500, Robert Dewar wrote:
|
|>Paolo Carlini wrote:
|>
|>>Andrew Haley wrote:
|>>
|>>
|>>>F9.4.4 requires pow (x, 0) to return 1 for any x, even NaN.
|>>>
|>>>
|>>
|>>Indeed. My point, basically, is that
On Mon, 2005-03-07 at 10:51 -0500, Robert Dewar wrote:
> Paolo Carlini wrote:
> > Andrew Haley wrote:
> >
> >> F9.4.4 requires pow (x, 0) to return 1 for any x, even NaN.
> >>
> >>
> > Indeed. My point, basically, is that consistency appear to require the
> > very same behavior for *complex* zer
Paolo Carlini wrote:
Andrew Haley wrote:
F9.4.4 requires pow (x, 0) to return 1 for any x, even NaN.
Indeed. My point, basically, is that consistency appear to require the
very same behavior for *complex* zero^zero.
I am not sure, it looks like the standard is deliberately vague here,
and is not
Andrew Haley wrote:
F9.4.4 requires pow (x, 0) to return 1 for any x, even NaN.
Indeed. My point, basically, is that consistency appear to require the
very same behavior for *complex* zero^zero.
Paolo.
Robert Dewar wrote:
Paolo Carlini wrote:
Actually, sorry, __builtin_cpow returns (nan, nan) (got sidetracked
by a strange issue I'm seeing in the C++ library), even "worse", so
to speak...
Paolo.
Well it certainly seems the right result in this case to me. Does the
standard really require the wr
Robert Dewar writes:
> Paolo Carlini wrote:
>
> > Actually, sorry, __builtin_cpow returns (nan, nan) (got
> > sidetracked by a strange issue I'm seeing in the C++ library),
> > even "worse", so to speak...
>
> Well it certainly seems the right result in this case to me. Does
> the standar
Paolo Carlini wrote:
Actually, sorry, __builtin_cpow returns (nan, nan) (got sidetracked by a
strange issue I'm seeing in the C++ library), even "worse", so to speak...
Paolo.
Well it certainly seems the right result in this case to me. Does the
standard really require the wrong result here?
Paolo Carlini wrote:
Hi everyone,
why the result is (0,0) instead of (1,0)?!?
Actually, sorry, __builtin_cpow returns (nan, nan) (got sidetracked by a
strange issue I'm seeing in the C++ library), even "worse", so to speak...
Paolo.
Hi everyone,
why the result is (0,0) instead of (1,0)?!? It seems to me that only the
latter is consistent with the C99 requirements for real power (F.9.4.4)
- that is 1.0 - and, on the other hand, according to G.6.4.1 and note
318, cpow behavior in "special cases" is rather implementation depen
100 matches
Mail list logo
