@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 ?

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.