Forums > MaxMSP

Cube root of negative number is nan


Tim
May 27, 2013 | 7:34 am

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…

<code>

– Pasted Max Patch, click to expand. –

</code>



Tim
May 27, 2013 | 8:31 am

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


May 27, 2013 | 9:15 am

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.)))]

-110



Tim
May 27, 2013 | 9:25 am

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

<code>

– Pasted Max Patch, click to expand. –

</code>


May 27, 2013 | 9:26 am

ok this is really weird.

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.)))]

-110


May 27, 2013 | 9:28 am

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


May 27, 2013 | 9:28 am

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



Tim
May 27, 2013 | 9:34 am

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



Tim
May 27, 2013 | 9:40 am

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

Here’s the new patch:

<code>

– Pasted Max Patch, click to expand. –

</code>


May 27, 2013 | 9:42 am

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

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


May 27, 2013 | 9:44 am

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


May 27, 2013 | 9:47 am

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.



Tim
May 27, 2013 | 9:50 am

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.


May 28, 2013 | 2:00 am

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 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.

The straightforward solution can be something like this:

<code>

– Pasted Max Patch, click to expand. –

</code>

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."


Viewing 14 posts - 1 through 14 (of 14 total)