Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > computing t = pow(-11.5, .333)

Reply
Thread Tools

computing t = pow(-11.5, .333)

 
 
pete
Guest
Posts: n/a
 
      05-16-2006
Julian V. Noble wrote:

> That is, I would expect a properly written pow function to compute
>
> pow(a,2) = a*a;
> pow(a,-2) = 1/(a*a);
>
> whereas
>
> pow(a,2.0) = exp(2.0*ln(a));


It would take some kind of compiler trick,
as well as proper function writing, for a called function
to be able to distinguish between two arguments
which compare equal when converted to the type of the parameter,
but which have different types.

--
pete
 
Reply With Quote
 
 
 
 
Kenneth Brody
Guest
Posts: n/a
 
      05-16-2006
pete wrote:
>
> John Smith wrote:
> >
> > In a C program I need to do exponentiation where the base is
> > negative and the exponent is a fraction. In standard C this would
> > be something like t = pow(-11.5, .333), but with this combination
> > of arguments there is a domain error and the result is a
> > percolating NaN.

[...]
> > Is there any particular reason for this limitation in the
> > standard library function? Has anyone else had a problem with
> > this and found a better solution?


It's not a "limitation in the standard library function", but rather
a "limitation" of math itself. You cannot express the fractional power
of a negative number as a real number in the general case.

> -11.5 has a third root which is negative,
> if that's what you're really trying to find.


Of course, a power of ".333" is _not_ a third root, as ".333" is only
_close_ to 1/3. (For large enough values of "close".)

> However, if you consider that
> a negative number raised to an even integer power, is positive,
> and that
> a negative number raised to an odd integer power, is negative,
> then it just seems natural that
> the sign of a negative number raised to a non integer,
> should be undefined.


Now, his solution of negating the number, and again negating the result,
does "work" for odd integral roots and odd integral powers, but not in
the general case.

[...]

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <(E-Mail Removed)>


 
Reply With Quote
 
 
 
 
John Smith
Guest
Posts: n/a
 
      05-16-2006
CBFalconer wrote:
> John Smith wrote:
>
>>In a C program I need to do exponentiation where the base is
>>negative and the exponent is a fraction. In standard C this would
>>be something like t = pow(-11.5, .333), but with this combination
>>of arguments there is a domain error and the result is a
>>percolating NaN.
>>
>>I worked around the problem by putting the standard function in a
>>wrapper:
>>
>> double xpow(double b, double x)
>> {
>> double p;
>>
>> if(b < 0)
>> {
>> p = pow(-b, x);
>> p *= -1.0;
>> }
>> else p = pow(b, x);
>>
>> return p;
>> }
>>
>>Is there any particular reason for this limitation in the
>>standard library function? Has anyone else had a problem with
>>this and found a better solution?

>
>
> Yes. What you are doing has no meaning.


This is what happens when a non-mathematician attempts
mathematical programming.

You are actually
> returning -(b**x) instead of (-b)**x, where I am using ** to
> represent exponentiation. What is the real problem?
>
> Consider: what is the square root of -1/2? There is no answer in
> the real plane. You need complex variables for this. Yet this is
> just the value of (-0.5)**0.5.
>


My project involves solving cubic and quartic equations which
sometimes have complex roots and I am feeling my way along in the
dark. Occasionally there is a faint glimmer of light in the
distance. thanks to all for your responses. They have been helpful.

JS

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      05-16-2006
John Smith wrote:
> CBFalconer wrote:
>

.... snip ...
>>
>> Yes. What you are doing has no meaning. You are actually
>> returning -(b**x) instead of (-b)**x, where I am using ** to
>> represent exponentiation. What is the real problem?
>>
>> Consider: what is the square root of -1/2? There is no answer in
>> the real plane. You need complex variables for this. Yet this is
>> just the value of (-0.5)**0.5.

>
> My project involves solving cubic and quartic equations which
> sometimes have complex roots and I am feeling my way along in the
> dark. Occasionally there is a faint glimmer of light in the
> distance. thanks to all for your responses. They have been helpful.


If you want real roots (which may not exist for a quartic, but must
exist for a cubic) consider a Newton-Raphson solution. Off to the
books with you. This is now no longer a C question, but
algorithmic, and better suited to comp.programming.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>


 
Reply With Quote
 
Julian V. Noble
Guest
Posts: n/a
 
      05-16-2006
pete wrote:
> Julian V. Noble wrote:
>
>> That is, I would expect a properly written pow function to compute
>>
>> pow(a,2) = a*a;
>> pow(a,-2) = 1/(a*a);
>>
>> whereas
>>
>> pow(a,2.0) = exp(2.0*ln(a));

>
> It would take some kind of compiler trick,
> as well as proper function writing, for a called function
> to be able to distinguish between two arguments
> which compare equal when converted to the type of the parameter,
> but which have different types.
>


Not really, Fortran did it by looking for the decimal point. That is,
if it could interpret the literal exponent as an integer it would. If
it were forced to interpret it as a real (by the presence of a dp, e.g.)
it would do that. How it dealt with symbolic exponents doubtless had
to do with the type of the exponent name. Remember this is all done
at compile-time, not run-time. I once wrote a system where a variable
contained a token identifying its type so it could be done at run-time.
It really isn't that hard.

--
Julian V. Noble
Professor Emeritus of Physics
University of Virginia
 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      05-16-2006
Julian V. Noble wrote:
>
> pete wrote:
> > Julian V. Noble wrote:
> >
> >> That is, I would expect a properly written pow function to compute
> >>
> >> pow(a,2) = a*a;
> >> pow(a,-2) = 1/(a*a);
> >>
> >> whereas
> >>
> >> pow(a,2.0) = exp(2.0*ln(a));

> >
> > It would take some kind of compiler trick,
> > as well as proper function writing, for a called function
> > to be able to distinguish between two arguments
> > which compare equal when converted to the type of the parameter,
> > but which have different types.
> >

>
> Not really, Fortran did it by looking for the decimal point.


How does C do it?

--
pete
 
Reply With Quote
 
P.J. Plauger
Guest
Posts: n/a
 
      05-17-2006
"pete" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> Julian V. Noble wrote:
>>
>> pete wrote:
>> > Julian V. Noble wrote:
>> >
>> >> That is, I would expect a properly written pow function to compute
>> >>
>> >> pow(a,2) = a*a;
>> >> pow(a,-2) = 1/(a*a);
>> >>
>> >> whereas
>> >>
>> >> pow(a,2.0) = exp(2.0*ln(a));
>> >
>> > It would take some kind of compiler trick,
>> > as well as proper function writing, for a called function
>> > to be able to distinguish between two arguments
>> > which compare equal when converted to the type of the parameter,
>> > but which have different types.
>> >

>>
>> Not really, Fortran did it by looking for the decimal point.

>
> How does C do it?


Essentially by calling trunc(x) and seeing if the return value
differs from x. (More precisely, we use the _Dint function that
was discussed at length in these pages a few months ago.)

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      05-17-2006
P.J. Plauger wrote:
>
> "pete" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
> > Julian V. Noble wrote:
> >>
> >> pete wrote:
> >> > Julian V. Noble wrote:
> >> >
> >> >> That is,
> >> >> I would expect a properly written pow function to compute
> >> >>
> >> >> pow(a,2) = a*a;
> >> >> pow(a,-2) = 1/(a*a);
> >> >>
> >> >> whereas
> >> >>
> >> >> pow(a,2.0) = exp(2.0*ln(a));
> >> >
> >> > It would take some kind of compiler trick,
> >> > as well as proper function writing, for a called function
> >> > to be able to distinguish between two arguments
> >> > which compare equal when converted to the type of the parameter,
> >> > but which have different types.
> >> >
> >>
> >> Not really, Fortran did it by looking for the decimal point.

> >
> > How does C do it?

>
> Essentially by calling trunc(x) and seeing if the return value
> differs from x. (More precisely, we use the _Dint function that
> was discussed at length in these pages a few months ago.)


There's no function that can be called from pow,
that will distinguish
pow(a, 2);
from
pow(a, 2.0);

--
pete
 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      05-17-2006
pete wrote:
>
> P.J. Plauger wrote:
> >
> > "pete" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> >
> > > Julian V. Noble wrote:
> > >>
> > >> pete wrote:
> > >> > Julian V. Noble wrote:
> > >> >
> > >> >> That is,
> > >> >> I would expect a properly written pow function to compute
> > >> >>
> > >> >> pow(a,2) = a*a;
> > >> >> pow(a,-2) = 1/(a*a);
> > >> >>
> > >> >> whereas
> > >> >>
> > >> >> pow(a,2.0) = exp(2.0*ln(a));
> > >> >
> > >> > It would take some kind of compiler trick,
> > >> > as well as proper function writing, for a called function
> > >> > to be able to distinguish between two arguments
> > >> > which compare equal
> > >> > when converted to the type of the parameter,
> > >> > but which have different types.
> > >> >
> > >>
> > >> Not really, Fortran did it by looking for the decimal point.
> > >
> > > How does C do it?

> >
> > Essentially by calling trunc(x) and seeing if the return value
> > differs from x. (More precisely, we use the _Dint function that
> > was discussed at length in these pages a few months ago.)

>
> There's no function that can be called from pow,
> that will distinguish
> pow(a, 2);
> from
> pow(a, 2.0);


I'm not very familiar with C99, so for a moment
I thought trunc() was one of your own, like _Dint.

Now that I've read the standard description of trunc,
I can say that there's absolutley no way that calling trunc
can help to distinguish
pow(a, 2);
from
pow(a, 2.0);

--
pete
 
Reply With Quote
 
P.J. Plauger
Guest
Posts: n/a
 
      05-17-2006
"pete" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> P.J. Plauger wrote:
>>
>> "pete" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>
>> > Julian V. Noble wrote:
>> >>
>> >> pete wrote:
>> >> > Julian V. Noble wrote:
>> >> >
>> >> >> That is,
>> >> >> I would expect a properly written pow function to compute
>> >> >>
>> >> >> pow(a,2) = a*a;
>> >> >> pow(a,-2) = 1/(a*a);
>> >> >>
>> >> >> whereas
>> >> >>
>> >> >> pow(a,2.0) = exp(2.0*ln(a));
>> >> >
>> >> > It would take some kind of compiler trick,
>> >> > as well as proper function writing, for a called function
>> >> > to be able to distinguish between two arguments
>> >> > which compare equal when converted to the type of the parameter,
>> >> > but which have different types.
>> >> >
>> >>
>> >> Not really, Fortran did it by looking for the decimal point.
>> >
>> > How does C do it?

>>
>> Essentially by calling trunc(x) and seeing if the return value
>> differs from x. (More precisely, we use the _Dint function that
>> was discussed at length in these pages a few months ago.)

>
> There's no function that can be called from pow,
> that will distinguish
> pow(a, 2);
> from
> pow(a, 2.0);


Right. I was addressing the issue of determining whether you have
an exact integer power, however it was arrived at.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Optical Computing: special issue - Natural Computing, Springer optical supercomputing C Programming 0 01-16-2009 12:18 PM
Optical Computing: special issue - Natural Computing, Springer optical supercomputing C Programming 0 12-19-2008 12:22 PM
Razer Tarantula Gaming Keyboard Review at XYZ Computing at XYZ Computing Silverstrand Front Page News 0 11-01-2006 05:13 PM
Samsung Experience (6.17.05) Event Coverage at XYZ Computing Silverstrand Front Page News 3 06-26-2005 07:10 AM
Sunbeam 20-in-1 Superior Panel Review at XYZ Computing Silverstrand Front Page News 1 06-23-2005 03:18 PM



Advertisments