Remove special edge cases from triangle exercise

[bobtfish]

Fixes #1477

[github-actions]

Dear bobtfish

Thank you for contributing to the Go track on Exercism! 💙
You will see some automated feedback below 🤖. It would be great if you can make sure your PR covers those points. This will save your reviewer some time and your change can be merged quicker.

• ⬆️ The instructions and test cases for many practice exercises originate in the Exercism-wide problem-specifications repo. If the exercise you changed is listed there in the exercises folder, please consider the following.

  • Improvements to the instructions.md file should be made in the problem-spec repo so that all tracks can benefit.
    You can open a PR there instead.
  • If you want to add some language specific information, use the instructions.append.md file (see Practice Exercise Docs).
  • Test cases selected in the .meta/tests.toml file need to be implemented in the <exercise>_test.go file according to the specification in canonical-data.json.

• ✍️ If your PR is not related to an existing issue (and is not self-explaining like a typo fix), please make sure the description explains why the change you made is necessary.

• 🔤 If your PR fixes an easy to identify typo, if would be great if you could check for that typo in the whole repo. For example, if you found Unicdoe, use "replace all" in your editor (or command line magic) to fix it consistently.

Dear Reviewer/Maintainer

• 📏 Make sure you set the appropriate x:size label for the PR. (This also works after merging, in case you forgot about it.)

• 🔍 Don't be too nit-picky. If the PR is a clear improvement compared to the status quo, it should be approved as clear signal this is good to be merged even if the minor comments you might have are not addressed by the contributor. Further improvement ideas can be captured in issues (if important enough) and implemented via additional PRs.

• 🤔 After reviewing the diff in the "Files changed" section, take a moment to think about whether there are changes missing from the diff. Does something need to be adjusted in other places so the code or content stays consistent?

_{Automated comment created by PR Commenter 🤖.}

[andrerfcsantos]

I agree with the changes except the conversion of floats to ints. After removing the Inf and NaN cases, I don't think having floats or ints makes a big difference, and the tests in the specifications do have tests with floats. We would to go against specs to have ints and I don't think it's worth it.

@junedev WDYT?

[junedev]

Unfortunately, I realized it is not quite as easy as this PR. This exercise is part of the problem spec repo and the test cases there explicitly include floating point calculations.
https://github.com/exercism/problem-specifications/blob/main/exercises/triangle/canonical-data.json

We could still mark all the floating point test cases as excluded in the tests.toml file but this raises the question why no other track seems to have concerns regarding floating point comparison in this exercise. 🤔

I would like to quickly consult with other maintainers before this gets merged.

[junedev]

@andrerfcsantos While I also prefer to stick to problem spec, the person in #1448 raises a valid point there. I would like to check whether there was some prior discussion on this.

[andrerfcsantos]

Fair enough.

But I don't think there's a problem in keeping floats from our side. A simple comparison like a+b >= c && b+c >= a && a+c >= b passes the tests.

[junedev]

@andrerfcsantos @bobtfish Thanks for your patience while I tried to make up my mind about this. I managed to dig out the issue in the problem spec repo that discusses this. exercism/problem-specifications#798

Their conclusion was it is ok to assume that the exercise will not cover cases where the computational precision is a problem. So I agree with @andrerfcsantos that we should keep the floating point version and just remove the init part about Inf etc.
I will respond in #1448 and close that issue.

@bobtfish I am really sorry I didn't properly think this through before labeling the issue as ready to be worked on, thus causing unnecessary work.

[bobtfish]

@bobtfish I am really sorry I didn't properly think this through before labeling the issue as ready to be worked on, thus causing unnecessary work.

No biggie :)

[andrerfcsantos]

Thanks for this!