The Triangle exercise doesn’t have any test where a + b = c (or any other combination where the sum of two sides is equal to the third) outside of the all sides = 0.
This case corresponds to a degenerate triangle where the 3 points are aligned, which should probably not considered a triangle.
In other words, the code should validate the triangle inequality with a strict inequality.
Degenerate triangle has triangle in the name. It’s ambiguous, which makes it a fun semantic argument to have, but often not a very productive argument to have. It’s easier to just bypass that argument and not test it either way. If you search the forum for degenerate triangle, I believe this has been discussed in the past.
it was mostly caused by confusion among people trying to figure out what a triangle is. On one hand, we have the term “degenerate triangle”, which suggests that it is a triangle, after all, it does satisfy the triangle inequality. On the other hand, a degenerate triangle isn’t really a triangle, but rather a straight line. The same confusion could arise among people attempting to solve the exercise.
However, a better approach to this problem is to simply remove the equality from the instructions: “the sum of the lengths of any two sides must be greater than or equal to the length of the third side”. This simplifies the exercise and avoids edge cases entirely. It is also a mathematically valid approach. Wikipedia also supports this:
“In mathematics, the triangle inequality states that for any triangle, the sum of the lengths of any two sides must be greater than or equal to the length of the remaining side.[1][2] This statement permits the inclusion of degenerate triangles, but some authors, especially those writing about elementary geometry, will exclude this possibility, thus leaving out the possibility of equality.”
@maintainers: Would removing the ‘equal to’ from the instructions be appropriate? After all we aren’t testing for degenerate triangles.
What argument are you referring to? It’s not clear to me. The topic you’re linking to is a discussion about what is and what isn’t a triangle. Something that satisfies a = b + c isn’t a triangle in the mathematical sense, so there’s nothing to discuss […]
In any case, it’s much easier to update the instructions so they are consistent with the tests. This way, people won’t waste everyone’s time by starting forum topics, only to have their valid arguments unfairly rejected because the instructions haven’t been updated.
The argument I referred to is that there was a time where testing for degenerate triangles was encouraged (before problem-specifications existed), was part of testing in some tracks and so was part of many solutions to the problem. After lenghty discussions the encouragement of testing for degenerate triangles was removed from problem-specification instructions and the wording of the instructions was kept open for degenerate triangles.
In the spirit of “instructions are unprecise, tests are the spec” this was acceptable to most people.
So, in answer to your question “Would removing the ‘equal to’ from the instructions be appropriate? After all we aren’t testing for degenerate triangles.” I think: No, please don’t start that discussion again.
Exercism exercises aren’t intended to be exhaustive given they are toy exercises for developing fluency. Prior discussions indicated this issue isn’t cut and dry so changing this might end up being as controversial as leaving it. So I’d be fine leaving the tests as-is given the precedent set by the previous conversations.
I haven’t even had the chance to read the topic properly because I was in a rush. So, I have no idea what is actually being said there, even if I said otherwise. Apologies if I offended anyone, that was not my intention.
That’s a good point, but leaving things too open to interpretation tends to create significant confusion, which I don’t think is worth it due to many undesired side effects: people repeatedly engaging in the same discussions, others feeling frustrated when their proposals are rejected, readers getting annoyed by having to read the same explanations over and over, or having to dig through obscure, old sources to understand why things are the way they are.
There are cases where this flexibility makes sense, but in this case it really doesn’t, because, as Isaac said, it’s just a matter of semantics. Picking one explanation and sticking with it is usually much more convenient.
For a shape to be a triangle at all, all sides have to be of length > 0, and the sum of the lengths of any two sides must be greater than or equal to the length of the third side.
+ Note, we opted to not include degenerate triangles in the tests to keep things simpler.
How about a note block. Something like this maybe?
For a shape to be a triangle at all, all sides have to be of length > 0, and the sum of the lengths of any two sides must be greater than or equal to the length of the third side.
~~~~exercism/note
We opted to not include degenerate triangles (triangles that violate these rules) in the tests to keep things simpler.
You may handle those situations if you wish to do so, or safely ignore them.
~~~~
My only thought is are there tracks that have already included degenerate triangles? If so, maybe what we want here is an instructions append then like we did for Anagram where we noted if a given track expects the results in a particular order or not.
How did this work? Did we ask all tracks to add an append? I wonder if there’s an option to have a default append that appears unless tracks override it?
Oh, if it’s only four tracks, it’s not really worth the effort to do appends for the remaining tracks. Let’s just make an append for those four tracks and then they can decide if they want to accept the append or drop the tests.