Derived trig function arcsin() resulting in illegal function call

[johannhowitzer]

I have a program that requires an inverse sine function to work properly, but I'm running into an illegal function call error.

Code: QB64: [Select]

1. function arcsin(n)
2. print n, atn(n / sqr(1 - (n ^ 2))): _display: sleep
3. arcsin = atn(n / sqr(1 - (n ^ 2)))
4. end function

I added the second line there so I could see what the values were for debugging purposes.  What's really unusual is that now THAT line is running into the illegal function call - but only after the sleep command!  The program displays the values, sleeps, then I press a key and it pops up with the error.

Sample values from the print just now were -.8242055 and -.9687978, in case that helps.

[SMcNeill]

Can’t you just use _ASIN?  https://www.qb64.org/wiki/ASIN

[johannhowitzer]

Huh, I thought QB64 only had inverse tangent.  Well, someone probably ought to update this page then: http://www.qb64.org/wiki/Mathematical_Operations

My program now appears to be functioning *almost* as intended, now I can do the necessary debugging, thanks to your help.

Also, still curious why the illegal function call, and why it still PRINTed before the error on the same line, if anyone has any ideas.  :)

[bplus]

Works OK for me:

Code: QB64: [Select]

1.  
2. FOR i = .8 TO 1 STEP .01
3.     a = arcsin(i)
4. NEXT
5.  
6. FUNCTION arcsin (n)
7.     PRINT n, ATN(n / SQR(1 - (n ^ 2))), _ASIN(n)
8.     arcsin = ATN(n / SQR(1 - (n ^ 2)))
9.     _DISPLAY: SLEEP
10. END FUNCTION
11.  
12.  

What are you doing before the call? integers?

[johannhowitzer]

Inverse sine is being used here as part of a formula to take two (x, y) coordinate positions, the angle and speed of the object at one position, and to aim a shot of known speed from the other position so it will hit accurately where the object will be - to "lead" the shot.  It's a small piece of a game engine I'm working on.  Here's the meat of it:

Code: QB64: [Select]

1. function tracking_2(px, py, tx, ty, ta, tv, sv)
2.  
3. r = tv / sv ' Ratio of speeds
4.  
5. dx = tx - px
6. dy = ty - py
7. h = hypo(dx, dy)
8.  
9. angle_a = arctan(next_y(ta, tv), next_x(ta, tv))
10. angle_a2 = arctan(dx, dy)
11. aprime = angle_a - angle_a2
12.  
13. angle_b = arctan(dy, dx)
14. angle_b2 = arcsin(dy / h) + arcsin(r * sin(aprime))
15. tracking_2 = angle_b2 - angle_b
16.  
17. end function

Positions are (px, py) and (tx, ty), the target's angle is ta and speed is tv, the shot's speed is sv.  Function returns the shot's angle.  Coordinates will be within an 800x600 screen, angle from 0 to 2pi radians, speed can be up to 30 pixels per frame, nonzero, for this test - I'm generating all of the above randomly for now.

[STxAxTIC]

Broski, your illegal function call is probably coming from division by zero (or accidentally invoking imaginary numbers). Change my mind!

[johannhowitzer]

The PRINT statement in arcsin() is giving two numbers, I gave examples in an earlier post.  If ATN(n / SQR(1 - (n ^ 2))) had a division by zero, I would not expect it to give output at all.

[SMcNeill]

The PRINT statement in arcsin() is giving two numbers, I gave examples in an earlier post.  If ATN(n / SQR(1 - (n ^ 2))) had a division by zero, I would not expect it to give output at all.

Is arcsin defined as an integer type?  Perhaps a DEFINT or DEFLNG in the program?  Division by zero errors can behave differently for different variable types.  I believe floats give INF for the answer, while integers just error.  It could explain the discrepancy in behavior.

[johannhowitzer]

Well, there's only one division in that line.  Working backward, the SQR would have to result in zero, so the parameter has to amount to zero... which means (n ^ 2) has to be 1, so n has to be 1.  But in the example given, PRINT did not show 1 as the value for n.  So that n value would not result in a division by zero.  n was also between 1 and -1 noninclusive, so n ^ 2 must be a positive value under 1, which means 1 - n is positive and between 0 and 1.  SQR must then also be less than 1, but if SQR results in a number closer to zero than n, ATN will be called with a parameter above 1 or below -1.

_asin suits my purposes more smoothly, anyway - this was just curiosity after that.  :)