On Thursday, March 29 at 10:42 AM, quoth Daniele:
>-> (-27)^(1/3)
> = Not a Number
>-> -(27)^(1/3)
> = -3
>-> cbrt (-27)
> = -3
>
>it seems the first evaluation isn't correct. I use wcalc version 2.2.2.

Huh. That's pretty strange. What appears to be happening is that we're
tripping over an oddity in the mpfr number library. Check here:
http://www.mpfr.org/mpfr-current/mpfr.html#Basic-Arithmetic-Functions

In it's description of mpfr_pow (which is what wcalc uses to raise one
number to the power of another number), it says:

pow(x, y) returns NaN for finite negative x and finite non-integer y

Which is precisely what we have going on here. (Your second example is
thwarted by order-of-operations, because it's really displaying the
same thing as '- cbrt (27)'.)

I believe the problem is that numbers aren't stored *exactly*, but are
instead stored as finite approximations. Thus, 1/3 isn't stored as the
abstract concept of one-third, but is instead stored as the number
0.333333333333333333333333333333333333333333333333333333333333333333333333333333\
33333333333333333333333333333333333333333333333333333333333333333333333333333333\
33333333333333333333333333333333333333333333333333333333333333333333333333333333\
333333333333333333333333333333333333333333333333333333333333333333333343
The 43 at the end is a natural result of having a limited number of
bits (1024 by default) to represent the fraction. After all,
(-27)^(0.33) isn't the cube-root of -27.

I compared the output with Apple's scientific calculator, and they
have the same problem. Actually, they have a worse problem, because
they can't even compute the cube root of -27.

There are a couple different ways of solving this, none of which are
terribly thrilling. The first would be to make wcalc recognize simple
fractions (such as 1/3, 1/4, 1/123, etc.) and store them internally as
fractions (e.g. mpq_t's) rather than as numbers, and then recognize
the special case where a number is raised to a fraction. That would be
rather irritating, and someone will complain when they discover that
(-27)^((2asin(1))/(3pi)) (or -27 raised to some other function that
should result in approximately 1/3rd) doesn't return -3. Or we could
make it an even further special case where any number raised to
something that is approximately 1/3 will be assumed to be a cube-root,
which then relies on the accuracy of our approximation method, and
will only work for a limited number of special-case fractions.

I'm open to suggestion, but I'm having trouble thinking of any
particularly reliable ways out of this. Essentially, this boils down
to the fact that the computer is providing an approximation rather
than an abstract computation. Can anyone else think of a better
solution?

~Kyle

--
I would be delighted to offer any advice I can on understanding women.
When I have some I'll let you know.
-- Jean Luc Picard