Trigonometry

During a workshop in Hamburg I briefly attended a couple of months ago, I noticed a lot of people have trouble with basic trigonometry. Figuring out angles and length of triangles. Added two components to help with this (one for right-angle triangles, one for generic triangles). Input all the values you know, and it will compute all possible missing ones.

33 members like this

View Full Size

Tags:

Comment

You need to be a member of Grasshopper to add comments!

Comment by TheChosenOne on August 28, 2014 at 3:14pm

Comment by David Rutten on August 23, 2014 at 4:54pm: Hmm, not sure I like that. First of all it would have to be clear which (+) symbol refers to which variable, which is currently not possible in the ZUI framework.

Secondly I'd have to provide 6 (+) symbols without any inputs already there, which is currently not possible in the ZUI framework.

Thirdly it prevents people from using the same component with streams of data, some of which may be nulls. Perhaps you want to use the object to solve 1000 triangles, 400 of which have only 2 known edges, and 600 of which have 2 known angles. If the component can only handle either of these cases at the same time, you'd have to split up 500 lists of data into two separate streams, use two trig components and then fold it all back together again. This is probably a very rare case, but it sounds like an unnecessary limitation.

The angles are defined as standard angle parameters, so rounding to 0.1 degrees isn't any good if you're using Radians. Plus 0.1 degrees is pretty coarse, one can do a lot better with 64-bit floating point numbers.

I think my initial solution will be to simply add a warning to the component if you supply more values than needed.

Comment by Mateusz Zwierzycki on August 23, 2014 at 3:48pm

@David: Nope.

There is only one component (the upper one). When created it doesn't have any inputs, just all outputs.

Here are few scenarios :

1.Triangle with A,B and P

When you zoom the component, you can see 6 (+) signs with what you can add (A,B,C,P,Q,R).
Let's say you add A = 90 and B = 50.
Now you can't add the third angle (cause its 180-(50+90) = C output).
What you can add at the moment is P,Q,R.
You choose to add P = 10.
There is no more a possibility to add Q and R.
All component outputs now give us the data.

2. Triangle with P,Q,R

When you zoom the component, you can see 6 (+) signs with what you can add (A,B,C,P,Q,R).
Let's say you add P = 15, Q = 20.
Now if you add R, the component's outputs all the angles and edge lengths.
If R > P+Q then component throws warning. (> or >= ?)
You cannot add A,B or C anymone.

3.Triangle with P,Q and C

When you zoom the component, you can see 6 (+) signs with what you can add (A,B,C,P,Q,R).
Let's say you add P = 15, Q = 20.
Now if you add C (angle), the component's outputs all the angles and edge lengths.
You cannot add A,B or R anymone.

To make it all easier, disable the possibility to internalize the data.

Tolerance issue... Maybe round the angles always to floor , with 0.1 precision ?

Comment by David Rutten on August 23, 2014 at 2:23pm: @Mateusz. Are we talking about the same thing? I mean that all inputs are optional, and it's thus possible to 'provide' values that cannot possibly represent a valid triangle. For example two angles can be given as 88° and 95°. All three angles must sum up to 180, and we're already 3 degrees over balance. Or maybe the user specifies three edge-lengths: 21, 12 and 8. 21 is bigger than 12+8, so even if the triangle was stretched flat, the two short edges cannot reach the ends of the long edge. The above is easy to test for and I add errors to the component if an invalid triangle is provided. However there are also many angle+edge length combinations which result in invalid triangles.

I could of course test for these as well, but the problem is now tolerance. What if the user specifies a redundant angle of 54.7°, whereas the mathematics tell us that the actual angle is 54.7002°. Is that an error? If so, is the angle wrong or is perhaps one of the edges wrong? Or has the triangle simply been over-constrained? Is there a mathematically robust way of dealing with this? And if so, would that also be the most user-friendly way of dealing with it?

Comment by Mateusz Zwierzycki on August 23, 2014 at 9:51am: I'm not really after the idea to create those components (learn trig), but I think that this problem

It is still somewhat problematic at the moment if too many values are user-specified. I performsome checking to see if the data represents a valid triangle, but there are still plenty of impossible combinations that aren't caught.

Can be very nicely solved with ZUI.

Comment by Danny Boyes on August 22, 2014 at 10:19am: A general rule at the moment is if you can see it it is GH1.0. Look out for them in the next release I would guess.

Comment by Daniel González Abalde on August 22, 2014 at 10:18am: Cool, I can't wait for the GH2!

Comment by David Rutten on August 22, 2014 at 8:43am

@Dani, sure... I kept these components simple as the inputs are fairly obvious.

From top to bottom:

Perpendicular Bisectors giving the circumcentre.
Altitudes giving the orthocentre.
Medians giving the centroid.
Angle bisectors giving the incentre.

Comment by peter fotiadis on August 22, 2014 at 2:02am: these 2 are not bad at all (the amount of people not knowing - even basic - trigonometry is 1000++ times bigger ... than the other thing).