Correct the definition of triangle inequality to not include degenera…

[durrellchamorro]

…te triangles.

[durrellchamorro]

I noticed the definition of triangle inequality is incorrect in the README. If the sum of two of the sides equals the sum of the third side, then that's called a degenerate triangle which looks like a straight line.

[petertseng]

Is it possible for us to, while doing this, also call out the case when the sum of two sides is exactly equal to the third, so that people will not feel the need to go back and forth on this e.g. #298 ?

It is known to us by #202 and #311 that we will not test such cases - it would be useful to explicitly note that in the README, I think.

[durrellchamorro]

After reading your discussion about this I can see why you wouldn't want to test for degenerate triangles and I also see my proposed definition is incorrect. One cool thing about exercism is you learn about different subjects.

As a programmer who writes object oriented code I found the first sentence in this Wikipedia article of value:

In mathematics, a degenerate case is a limiting case in which an element of a class of objects is qualitatively different from the rest of the class and hence belongs to another, usually simpler, class.

It might be worthwhile to programmers to explain what degeneracy is followed by what a degenerate triangle is in the README. At least for me that would have made things more clear.

[petertseng]

It might be worthwhile to programmers to explain what degeneracy is followed by what a degenerate triangle is in the README.

I think that would be good, yes! Can probably reuse this PR to do it.

[durrellchamorro]

If my conclusion that degenerate triangles do not violate the principle of triangle inequality is correct, then I would like to make pull requests to improve and fix the tests for Coffeescript, Javascript, and Ruby since those are the languages I know.

From an OO perspective, it doesn't seem like a good idea to initialize a degenerate triangle directly from the Triangle class, but that is up to you all to decide.

[petertseng]

it might be better to make clear that, more than the degenerate triangle existing, it is the triangle referred to earlier in the sentence that is degenerate (something like "that triangle is degenerate")

[durrellchamorro]

Regarding the concern about edge-case-itis and how the goal is not to write production quailty code at #287 (comment), I see a theme emerging for exercism in general. You might consider putting edge cases you think might be overkill in a Dig Deeper section in the README for people who want to challenge themselves more. You could also note in a Dig Deeper section where advanced techniques like metaprogramming shine such as in the Space Age exercise. If you've gone through the work of discovering, discussing, and voting on such cases you might want to share that knowledge and work in the README in this fashion. Those edge cases might help elucidate the problem and help people solve it as was the case for me with this triangle exercise.

If you've already decided against negative lengths, that's fine with me. Is the protocol to vote on the proposed README before I update this PR?

[petertseng]

You might consider putting edge cases you think might be overkill in a Dig Deeper section in the README for people who want to challenge themselves more. If you've gone through the work of discovering, discussing, and voting on such cases you might want to share that knowledge and work in the README in this fashion. Those edge cases might help elucidate the problem and help people solve it as was the case for me with this triangle exercise.

These are good suggestions that I have noted at #230 (comment) - there are always places where we can improve and you're right about this - these things should be documented so that we can avoid duplication of past efforts.

You could also note in a Dig Deeper section where advanced techniques like metaprogramming shine such as in the Space Age exercise.

This is also good - sometimes I see individual tracks note such things themselves if such a technique is specific to that language, but if it is broadly applicable and language-agnostic then it can be at x-common as well.

Is the protocol to vote on the proposed README before I update this PR?

What I would personally do is to update the PR now, since it is cheap to do so.

I'm not aware of a specific protocol. I do note that throughout the process of the past week, if someone other than me had changes to suggest, they've had ample opportunity to do so! On the other hand if they're OK with all this they didn't need to say anything.

[petertseng]

Yup.

I intend to squash before merging.

I'll merge if nobody has anything else to say in about two days.

[petertseng]

Thanks @durrellchamorro !