Problem-specifications: triangle: clarify confusion and adjust test suites

[kytrinyx]

A few weeks ago I hastily submitted an issue about triangle to every single track that has implemented it. In addition to being hasty, it was also confusingly ambiguous in its phrasing. And wrong. See discussion in https://github.com/exercism/xerlang/issues/85

The issue is surrounding the definition of the basic triangle inequality: z ≤ x + y

Notice the less than or equal to in that equation. Our test suites have been implemented as though that was only less than. A triangle with sides 2, 2, and 4 is a triangle, it's just a degenerate triangle.

Within the context of Exercism, this is taking edge cases to the absurd. The exercise is supposed to be simple, and I don't think that it makes sense to distinguish between _not a triangle_ and _degenerate triangle_.

I think that the best solution here would be to have a test case for a triangle that obviously violates the triangle inequality, and simply avoid the edge case where it is degenerate.

This would mean that we need to check each track's implementation and make sure that any cases where x+y=z are removed, and that there is at least one test case for x+y < z, e.g. 5, 4, 8 or 5, 5, 9. 5, 4, 10 or 5, 5, 11

@kotp @NobbZ @masters3d @hankturowski @behrtam @yurrriq Have I summarized the discussion in https://github.com/exercism/xerlang/issues/85 correctly? Does this sound like a good solution to this mess?

/cc @exercism/track-maintainers @exercism/project-management

[NobbZ]

Yeah, this summary seems to be correct and I also think this solution is the best thing we con do, without either requiring to implement something wrong or making the exercise unnecessary complex.

[petertseng]

that there is at least one test case for x+y < z, e.g. 5, 4, 8 or 5, 5, 9

The examples you've given do not fit x+y < z; instead, they fit x+y > z. I believe you do mean x+y < z (so you want to change the examples, not the inequality)

[hankturowski]

@kytrinyx You're 100% correct. We were hung up on a pedantic issue and losing sight of the purpose of the exercise. At least I was.

I like this solution as It neatly sidesteps the degenerate issue. Even better, if the user decides to add the tests for equality to their own test suite, they can decided how to handle it themselves and avoid more confusion.

We may want to leave a note for future track maintainers to avoid someone helpfully adding the tests back in.

[kytrinyx]

@petertseng oops, yes. I want to have examples that fail the inequality, so something like 5, 4, 10, and/or 5, 5, 11.

[yurrriq]

So, if I'm understanding correctly, we want to avoid tests that check degenerate triangles, leaving it up to the user whether or not to handle them? Maybe some rewording of the description is in order, to emphasize that a triangle that isn't equilateral, isosceles or scalene should be considered invalid.

[kytrinyx]

@yurrriq Yeah, that's what I was thinking. Would a degenerate triangle still be considered isosceles/scalene/equilateral given that the length of the sides would match one of those categories?

[yurrriq]

I'll have to brush up on the triangle inequality laws before answering.. I think not though.

[kotp]

Since it is a "Programming" exercise, not a "Geometry" exercise, I think it should be avoided as a formality. This _does not prevent_ the discussion from happening with the exercists :smiling_imp: if they are aware and notice the absurdity or lack thereof.

Being a degenerative triangle should not make it exclusively degenerative. It is also, if allowed at all, a specific type of triangle, one of the three classifications.

Otherwise, it is simply a line with three known segments that happen to fall infinitesimally close to being a regular, run of the mill, one of the types of, triangle.

Not really a strong opinion, as it is an interesting topic, have it or not. But I think having it effects all other tests, allowing for something contradicting "elementary" level geometry as a "first look" level thing. And we have, I am sure, young students learning with Exercism, and probably don't need to be initially conflicted with something that they recently were taught in their studies. Yet, without the attention raised toward degenerative triangles, I am sure the discussion will come up in the exercises. And that is :100: :ok_hand: , even encouraged.

[matthewmorgan]

@yurriq @kytrinyx I think a degenerate triangle (quacks like a line) could certainly be isosceles or scalene, as long as the lengths of two sides add up to but don't exceed the length of the third side.

[petertseng]

I actually think that although exercism/xcpp#86 solved the problem for that particular track, the cross-track problem has not been solved yet, so the issue was closed prematurely. I'll reopen to lessen the chance of it falling off of people's radars.

[masters3d]

That was me. I saw that there was just one issue left open so I tagged it to close this too.

If another round of issues gets created, it's probably best to open a new "master" issue to keep track of those so it's not too confusing to maintainers.

[kytrinyx]

Yeah, if we do want to do another round on this, let's open a new issue.

[petertseng]

In the interest of being not-confusing, glad to close this.

Note that many tracks still have tests where a + b = c, as noted at https://github.com/exercism/x-common/pull/311#issuecomment-236520834 . But discussion can be brought there.

[kytrinyx]

@petertseng Would you mind opening a new issue and summarizing what needs to be done? I can submit it with blazon.

[petertseng]

Once #311 is sorted then that can happen. The message to be sent to each track will probably be something like "Triangle has a JSON file now, please update. You will notice that cases with negative lengths were removed, here's why. You will notice that cases where a + b = c was removed, here's why". I can write something more sensible when time allows.