Apologies if this has been brought up before. I'm doing a series of calculations in my patch and stumbled across this problem. Upon further testing, it seems to only be caused by negative numbers. The example I've pasted is the cube root of -8 and should give -2 as the answer. However, it's just giving me nan...

cube-root-of-negative-number-is-nan

If it's of any use. I'm running Max 6.1.2 (32-bit) on an iMac, mid 2011, OSX Lion 10.7.5

you must think of [expr] as an algebraic object just like [sqrt].

to get the imaginary root of negative numbers, try this:

[expr (pow(((abs($f1)*($f10)))\,(1./3.)))]

you must think of [expr] as an algebraic object just like [sqrt]. 

Couldn't get your example to work but you reminded me that I could just use [abs] haha. Will paste the solution for anybody who wants to see. Cheers

the new forum software does not let me write the correct code, it shows something different from what was originally in my clipboard and the edit formular.

the reason are obviously the "greater than" and "smaller than" symbols, which are recognized as html tag when used in this order.

[code] [expr (pow(((abs($f1)*($f10))),(1./3.)))] [/code]

[expr (pow(((abs($f1)*($f1smaller0) + ($f1)*($f1greater0))),(1./3.)))]

the last line is the correct expression when you replace the operators in max. ;)

I'm getting a positive number out instead of a negative one with your new expression. The patch I pasted earlier works though.

Just realise that my method will give a negative output for a positive input.

oops, my fault, of course it must be negative:

[expr -(pow(((abs($f1)*($f1smaller0) + ($f1)*($f1greater0)))\,(1./3.)))]

our communication is heavily distorted because i see new posts (including my own) always 3 minutes after they have been posted.

for example i saw you mentioning your "patch above" before the post with the patch was actually there. wordpress does not seem to queue post.

Yours now outputs a negative when there's a positive input. I forgot to mention that I'm using positive and negative numbers here, sorry. My solution works but is clearly a bit messy.

First of all, pow(x,1.0/3.0) is not a cube root, nor is 1.0/3.0 exactly one third. The latter is a binary approximation of one third, just like 0.333333 is an approximation of one third. Close, but not the same thing.

pow(x,1/3) will give a result very close to the cube root for positive numbers, generally accurate to about 20-some-odd decimal places. But to make the calculation, pow() has to take the natural logarithm of 

. (The pow() function works generally by taking the natural logarithm of the first parameter, multiplying that by the second parameter, and raising 

 to that value for the result. Just like how you learned logarithms in, oh, about ninth grade math). The natural logarithm of a negative value is undefined, so of course pow() returns NaN.

The straightforward solution can be something like this:

For full details on pow() how reacts in unpleasant circumstances, consult the man page, for instance 

"If x is a finite value less than 0, and y is a finite noninteger, a domain error occurs, and a NaN is returned."

pow(x,1/3) will give a result very close to the cube root for positive numbers, generally accurate to about 20-some-odd decimal places. But to make the calculation, pow() has to take the natural logarithm of x. (The pow() function works generally by taking the natural logarithm of the first parameter, multiplying that by the second parameter, and raising e to that value for the result. Just like how you learned logarithms in, oh, about ninth grade math). The natural logarithm of a negative value is undefined, so of course pow() returns NaN.

For full details on pow() how reacts in unpleasant circumstances, consult the man page, for instance here. The key clause is:

"If x is a finite value less than 0, and y is a finite noninteger, a domain error occurs, and a NaN is returned."


Cube root of negative number is nan