Hello,

I've been working on some vex snippet functions that heavily rely on the use of trigonometry and the vex trig functions.

I have alot of conditionals that reflect positions that are “exactly” in the following sets:

Equals 0/360 degrees;
More than 0 and less than 90 degrees;
Equals 90 degrees;
More than 90 degrees and less than 180 degrees;
Equals 180 degrees;
More than 180 degrees and less than 270 degrees;
Equals 270 degrees;
More than 270 degrees and less than 360 degrees;

However, now I am needing to make use of the vex rotation function but have noticed the results could potentialy throw off my programming logic as I listed above.

For example if my angle is exactly 270 degrees and I apply a rotation of 90 degrees( using vex rotation function ) to bring it to 0/360 degrees;

Instead of the result being 0, I get an extremely small number close to 0 but not 0.

If the result was only a visual matter in terms of seeing the difference of 0 to something very close to 0 then it would not be an issue.

However, because the results will have a conditional applied , I could possibly get some very unexpected results.

If I apply my rotation of 90 degrees with a method that uses the vex trig functions I do end up with exactly 0.

However, I am at a point where I want to add another level of complexity to my functions and introducing the rotation function seems like a way to reduce the coding and help retain my ability to keep focused on the bigger picture.

I've also noticed that I don't get the same results if I compare an equivalent negative rotation vs. positive ( again using the vex rotation function),

eg. -270 and 90 degrees.

Any thoughts on the behaviour of the rotation function is appreciated.

Thanks.

VEX trig functions expect radians not degrees.

You can wrap your values in a call to radians() to convert from degrees to radians.

Hi Daryl,

Yes I am doing that, but there is something else going on in regards to the vex trig functions and the rotation function.


Perhaps when I get to it I will make a simple scaled down version file that shows this.

However, because the results will have a conditional applied , I could possibly get some very unexpected results.

This may come out quite ignorant but can't you use thresholds instead of directly comparing to a value.
Like this :

if abs(my_value) < 0.001

instead of

if my_value == 0

I'm sorry for not being much help with the rotation functions.

Good luck !

So, I assume you are measuring the angle between 2 vectors to determine which set the resultant angle belongs too?

…which would mean you are modifying one of the vectors (via vex rotate) and are expecting the resultant angle to be a specific value, and instead, you are getting some variance?

Is that an accurate problem statement for your scenario?

Georgie: Yeah I could but that makes my code much more verbose.

eg. if( (x < (90 - 0.001)) && (x > (90 + 0.001)))

which is fine..but the question then remains how small can I go too, that at the same time will give me a consistant results that I can expect.

Daryl: You describe something that is similar to what I am doing.

But to elaborate further on the issue.

I was having problems with my own algorithms due to my own faulty logic.

I encountered this issue with the non zero results while testing.

As a result it brought up the thought that if I am going to use this rotation function in a more complex algorithm it may not give the results I want and/or make it harder to debug if I am having problems with it;

Because I would be getting unexpected results in some way. If that happens remains to be seen.

But I am just wanting to find out what I am dealing with and why.

So I made a simpler version of what I was doing and with a bit of net searching found out what is going on.

In trigonometry sine 0 degrees represents the ratio of ‘opposite’/'hypotenuse' and in the case of sine 0 degrees that means that the numerator is 0 and we should get 0 from sine 0 as a result.

So I tested that in the vex snippet and thats what I get.

Conversely with cosine 90 degrees we have ‘adjacent’/'hypotenuse' and in this case of 90 degrees ‘adjacent’ is 0; So again the numerator is 0 and our result should be 0 from cosine 90 degrees.

However, when I printf the result of cosine 90 I get the same ‘peculiar’ very small number ( close to 0 ) but not 0 itself.

So I am thinking how come with the sine function at 0 degrees we can get 0 but not with cosine 90 degrees.

After all in both cases the numerator is zero.

But actually it's not.

I then tested this out using python and got the same results.

So then I did a search including a python reference and discovered that it's due to rounding errors in using radians function. (converting degrees to radians for the trig functions which use radians as their argument).

At least now I know why and what I am dealing with and can work/adjust accordingly.

Thanks guys for offering your input. It did help towards sorting out the issue.

EDIT:

Got the idea that maybe I will just work with radians…but 90 degrees in radians is pi/2.

So my saying its the conversion of degrees to radians but it looks like it's because we are dealing with pi.

And because of that if I really wanted to be a ‘stickler’ to small detail my smallest ‘resoltuion’ to account for would be some combination of the ‘largest’ float value that houdini uses with the value of pi/x.

I'm sure some testing in that direction would give a me an idea of what ‘constant’ I would go for.

stumbled on this looking for something else.

i know it's been a long time, but just wanted to throw it out there:

If you are specifically rotating by 90 degree increments, and you're doing it in a cartesian plane (XY plane, for instance)— you can simply swap the axis and negate one of them for a perfect 90 degree rotation. Which axis you negate will determine whether you are applying a positive or negative 90 degree rotation.

vector newpos = set(oldpos.y,-oldpos.x,0);

no $PI needed.

That old exercise I was doing was not about doing a specific rotation, but rather ‘dectecting’ a float value that would represent any rotational value between 0 and 360 degrees.

The issue became for the float values that would represent exactly angles 0/360, 90, 280, and 270.

It turned out I wasn't aware of the issue of floating point errors.( not with Houdini, but with computers in general )

The solution in that case was to change my conditional statements and what I do in each case, like I mention above:

eg. if( (x < (90 - 0.001)) && (x > (90 + 0.001)))

Of course since that time I've become familiar with other vex functions that has enabled me to simplify (less verbose) my functions.

Although, I still had to set up my logic to take into account natural floating point errors inherent in computer processing.