triangle: incorrect test in some tracks about erlang HOT 17 CLOSED

There is such a test which demands a failure. AFAIR I just took this from JSON or another track. Is it enough to just remove that test or shall I rewrite it to test for a specific kind?

I will tackle this after #84 is finished and merged.

from erlang.

Oh, good question. I think we should have it return an isosceles triangle -- it's a good edge case to have.

from erlang.

Hmm, I just asked Wolfram alpha, it does classify as degenerated.

So I'd go for either taking further research when a triangle is degenerated
exactly and add it as another possible return value for kind. Or leaving as
is (error) or do classify as isosceles, because this is what comes when you
simply change the inequality.

Since we have 1 o'clock in the morning here, I'll go to bed now, but I'll
do some more research tomorrow and open a ticket in xcommon (or chime into
an ongoing one if there is one).

Katrina Owen [email protected] schrieb am Sa., 30. Jan. 2016 00:58:

Oh, good question. I think we should have it return an isosceles triangle
-- it's a good edge case to have.

—
Reply to this email directly or view it on GitHub
#85 (comment).

from erlang.

This is very interesting. You are right.
2,4,2 is not a triangle because since 2 + 2 equals the length of the 4, then the 2 + 2 sides merge into the same plane so you end up with only a line.. (Technically is is three lines that occupy the same space of the 4 length)

from erlang.

So I'd go for either taking further research when a triangle is degenerated exactly and add it as another possible return value for kind.

So wikipedia is wrong, huh. Imagine that! OK, let's do some more research.

from erlang.

Wikipedia is not wrong. The 2,2,4 is a degenerate triangle, but still a triangle. In either case, we should call out our definition clearly in the .md.

from erlang.

So for a degenerate triangle (e.g. 2,2,4) which looks like a line segment do we return "isosceles" as kind or "degenerate"?

from erlang.

My opinion is that we either add degenerate as a case, or specifically say in our problem definition that degenerate triangles should be rejected.

To be honest, rejecting degenerate triangles feels like a cleaner solution. I'd just like the problem description to get an update.

from erlang.

triangle.md could really need some improvement. I think it should also mention the 3 kinds.

+1 rejecting degenerate triangles

from erlang.

++ for adding degenerate as a case

We can then separate the math definition from the notion of accepting or rejecting as a triangle, thus moving the conversation away from declaring what is or not a triangle, to just stating the type of case.
(I personally think degenerate triangles are not triangles and should be rejected! they are just lines! ;) "the emperor has no clothes" yo! ).

from erlang.

It seems like the general vibe here is to reject degenerate triangles and update the .md accordingly, yeah?

from erlang.

👍

from erlang.

So actually, we leave all the "faulty" tests as they are and repair the
"correct" ones?

Which again would mean I don't need to do anything here?

Katrina Owen [email protected] schrieb am Sa., 30. Jan. 2016 20:25:

yeah, agreed

—
Reply to this email directly or view it on GitHub
#85 (comment).

from erlang.

I'm not sure I understand your double quotes, @NobbZ, but the xerlang triangle tests look good as they are.

from erlang.

I say that we do exclude examples that stretch the definition to an absurd[1] degree. We keep to general position not special position geometry, and keep this where it should be in the context of the program here. If the assumption is that Triangles have area, this goes against that assumption, and is suitable for our purposes, and keeps everything at a non-college level, and is reasonable.

We don't test for the other more commonly known triangles, which is to say "right, acute or obtuse" why are we jumping into special position before we talk about all the general position triangles?

This is (as far as I can see) meant to be a simple exercise, even more so since we test for only 3 specific triangles.

from erlang.

Yeah, having slept on this I think that the right approach is to avoid the edge cases and stick to the basics (having things that obviously violate the triangle inequality thing is great, the distinction between not-a-triangle and yes-but-degenerate seems like a tangent that isn't useful here.

from erlang.

I've summarized this issue here: exercism/problem-specifications#202

I am closing this issue. If necessary I will open a new issue once we have come to an agreement about how to resolve the inconsistencies and what exact steps to take.

from erlang.