Utne Wire Man

8th January 2005 01:34 UTC

Qnan???
I have a problem.
I use a DM in a preset, and the screen randomly goes blank... for good. This is either a compile error, a divide by zero, or an imaginary number. The debug window shows 1.#QNAN000000000 etc. What the?
Only when I change something in the offending DM does it go back to normal.

PAK-9

8th January 2005 02:11 UTC

1.#QNAN000000000 is 'not a number'... I guess the 'q' stands for quantity or something.

Its not a divide by zero cos that results in infinity (#INF000...) and AVS can handle imaginary numbers, it just chops off the i I think, try the square root of -1 and you'll just get 1. As for the error, its probably just a bug in your DM, I'm not sure what tho, post the code.

Utne Wire Man

8th January 2005 14:41 UTC

OK, here is the code. It isn't specific to just this one DM, but to many that I make.

r=10

t1=t1+abs((ti1*ra2));
t2=t2+abs((ti2*ra4));

ra1=rand(100);
ra2=(ra1-50)/abs(ra1-50);
ti1=rand(200)/3500;
ra3=rand(100);
ra4=(ra1-50)/abs(ra1-50);
ti2=rand(200)/3500;

r=sin(r-sin(r)+t1/3);
r=sin(d*r+cos(t1)/3*d-cos(t1)*sin(t1)*x)+t1;
d=2*sin(sin(t2)*(x+y))*atan(sin(r)-y*sqrt(d)-sqrt(d)-x)/3+(sin(d*acos(sin(x)*sin(y)))*x);

One possible problem might be the random -1 or 1 generator that I use...it does give a zero once every rare occasion...
What does AVS do what confronted with a divide by zero?
does it ditch the computation, or ignore it? If it does, then I might need a more efficient generator, or some if => then code.

P.S. Would it speed up framerate to split the final d value into variables, not a bulky equation like this?

jheriko

9th January 2005 06:22 UTC

if you want some optimisation tips:

x/abs(x) = sign(x) although its only onbeat... still...


also calculate sin(t1) and cos(t1) per frame and store them in buffer varibles for use per pixel as sin and cos are slow and t1 doesn't change per pixel

*.333333 is faster than /3 because / is slower than *

JFASI

9th January 2005 14:12 UTC

Ooops...
I feel really stupid because my friend came to my house and signed in a Utne Wire Man... And didn't sign out. I accidentally used his account twice...

Anyway, my true identity is JFASI.

I tried looking into the possible divde by zero in the -1,1 algorithm...Didn't work. The d and r values die, and the algorithm continues calculating.

PAK-9

9th January 2005 16:43 UTC

Originally posted by PAK-9
...Its not a divide by zero cos that results in infinity (#INF000...) ...

JFASI

9th January 2005 20:42 UTC

I'm sorry...

When I bebug, The d and r value fry.
No idea as to why, but I do my best.

I'm pretty sure its in the pos/neg algorithm, as the same problem arises in presets where I use it. Could you please give me a list of errors that show up, like QNAN or INF?

UnConeD

10th January 2005 22:25 UTC

The only thing that I can think of in that statement is the acos... acos doesn't have a value for an input outside of -1..1. But your code is acos(sin(x)*sin(y)) and sin is bounded by -1..1, so so should sin*sin.

Other ideas other than input domain errors could be overflow, although that's very unlikely. Also, while floating point functions can return infinity, I think that passing them to a function could well result in NaN. E.g. sin(INF).

Splitting up your equation into separate statements will slow down your code, but it might help you locate the error. Just remove each of the lines one by one until it works. Or it might be caused by something somewhere else.

JFASI

10th January 2005 22:37 UTC

Thanks for the advice.
I think, however, that the problem lies somewhere in the
-1, +1 algorithm, as other presets that I have used it in crash in the same way.

How high does overflow set in, because if its like 50 factorial or something, then it isn't the case. It only get up to 150 or so, then the DM crashes.