space-age: describe tolerance of two decimal places

[petertseng]

In #880 we
discussed that tracks may need to use a tolerance in their floating
point comparisons.

Since this is a good idea for all tracks, this means that this is
suitable to put it in the description.

Thus, explain that the answer only needs to be correct to two decimal
places (the precision used in canonical-data). This gives the freedom to
students to round to two places or leave the answer unrounded.

It might be the case that some tracks are asking for rounded values, but
such tracks can update their READMEs and tests at their own pace.

The tracks that currently implement the exercise, and whether their
equality tests have tolerances:

Please excuse me if I miscategorised your track because of my
unfamiliarity with your language (and then correct me).

Exactly equal:

• https://github.com/exercism/csharp/blob/master/exercises/space-age/SpaceAgeTest.cs
• https://github.com/exercism/cfml/blob/master/exercises/space-age/SpaceAgeTest.cfc
• https://github.com/exercism/ecmascript/blob/master/exercises/space-age/space-age.spec.js
• https://github.com/exercism/fsharp/blob/master/exercises/space-age/SpaceAgeTest.fs
• https://github.com/exercism/javascript/blob/master/exercises/space-age/space-age.spec.js
• https://github.com/exercism/kotlin/blob/master/exercises/space-age/src/test/kotlin/SpaceAgeTest.kt
• https://github.com/exercism/lua/blob/master/exercises/space-age/space-age_spec.lua
• https://github.com/exercism/perl5/blob/master/exercises/space-age/space.t
• https://github.com/exercism/perl6/blob/master/exercises/space-age/space-age.t
• https://github.com/exercism/python/blob/master/exercises/space-age/space_age_test.py
• https://github.com/exercism/r/blob/master/exercises/space-age/test_space-age.R
• https://github.com/exercism/scala/blob/master/exercises/space-age/src/test/scala/SpaceAgeTest.scala
• https://github.com/exercism/swift/blob/master/exercises/space-age/Tests/SpaceAgeTests/SpaceAgeTests.swift
• https://github.com/exercism/typescript/blob/master/exercises/space-age/space-age.test.ts

Fixed tolerance 0.5 in either direction (so that the answer rounds to the desired value if rounding to closest integer)

• https://github.com/exercism/elm/blob/master/exercises/space-age/tests/Tests.elm

Fixed tolerance 0.01 in either direction

• https://github.com/exercism/java/blob/master/exercises/space-age/src/test/java/SpaceAgeTest.java
• https://github.com/exercism/objective-c/blob/master/exercises/space-age/SpaceAgeTest.m
• https://github.com/exercism/php/blob/master/exercises/space-age/space-age_test.php
• https://github.com/exercism/ruby/blob/master/exercises/space-age/space_age_test.rb
• https://github.com/exercism/rust/blob/master/exercises/space-age/tests/space-age.rs

Fixed tolerance 0.005 in either direction (so that the answer rounds to the desired value if rounding to two decimal places)

• https://github.com/exercism/cpp/blob/master/exercises/space-age/space_age_test.cpp
• https://github.com/exercism/clojure/blob/master/exercises/space-age/test/space_age_test.clj
• https://github.com/exercism/common-lisp/blob/master/exercises/space-age/space-age-test.lisp
• https://github.com/exercism/elixir/blob/master/exercises/space-age/space_age_test.exs
• https://github.com/exercism/erlang/blob/master/exercises/space-age/test/space_age_tests.erl
• https://github.com/exercism/haskell/blob/master/exercises/space-age/test/Tests.hs
• https://github.com/exercism/lfe/blob/master/exercises/space-age/test/space-age-tests.lfe
• https://github.com/exercism/ocaml/blob/master/exercises/space-age/test.ml
• https://github.com/exercism/prolog/blob/master/exercises/space-age/space_age_tests.plt

Variable tolerances (decided ahead-of-time):

• https://github.com/exercism/c/blob/master/exercises/space-age/test/test_space_age.c

[petertseng]

However, let's pretend that some track maintainer comes forth and says "I really think I should ask students of my track to round", whereas I continue to say "I really don't think I should ask students of my track to round". We could delete the sentence from the README completely and each track just adds the appropriate extra sentence in .meta/hints.md I suppose (depending on whether it asks its students to round).

I wish there were a less duplicative way to say "I want the problem-specifications README minus this small part of it", but that's a completely different issue that maybe I'll open one day once I figure out how I structure that (a .diff file against each README).

[ErikSchierboom]

I like this change. Being explicit on how to compare floating-point numbers is an essential part when testing floating-point numbers.

[Insti]

I'm in favor of removing the precision text from the description and leaving it up to the tracks to add if they want it.

[petertseng]

We could delete the sentence from the README completely and each track just adds the appropriate extra sentence in .meta/hints.md I suppose (depending on whether it asks its students to round).

I didn't complete this thought. Here is what I need to add to it to complete it:

I hope that they are OK with the place where it would end up if it would be placed in .meta/hints.md. If not, they would have to use an alternative (copy description.md to .meta and edit it accordingly). I regret the duplication that that will cause.

[petertseng]

I'm in favor of removing the precision text from the description and leaving it up to the tracks to add if they want it.

To gauge support for that, #946 now exists. It is only possible to merge one of #946 and #945. I await everyone's choice.

The only change to this PR was to change its commit message.

[rpottsoh]

My impression of this is that the rounding will be handled by the test suite either by actual rounding or through tolerancing. This puts a potential burden on the maintainers to process the students result correctly..... I think the burden would be minimal. On the other hand.... see my comment in #946 .

[petertseng]

the rounding will be handled by the test suite either by actual rounding or through tolerancing

yes

This puts a potential burden on the maintainers to process the students result correctly

yes,

Note that the burden is present regardless of whether this sentence is present. If it needs to happen anyway, might as well inform students of the policy.

Only problem is if a track desires to use a different policy. So, should problem-specifications define a default policy, at which point differing tracks will modify the README as necessary? Or, should problem-specifications define no policy, in which case every track that wishes to define any policy (as would be helpful to students) must do so in .meta/hints.md or via some other method?

[rpottsoh]

(but you are free to leave your answer unrounded) this statement may not be necessary. I think this may be why I am liking #946 more. This statement makes the description feel a little loose.

[petertseng]

I can thus propose "This means you are free to leave your answer unrounded"

[petertseng]

(that assumes the "But" was the only loose part about it. If instead it was the "you are free", then it would have to be "This means you should leave your answer unrounded")

[rpottsoh]

Reviewing this and #946 simultaneous is an interesting dilemma. I find myself to easily needing to bounce back and fourth between the two. I wonder if it would be easier to discuss the pros/cons of each in an issue?

[petertseng]

We can discuss in #880 if desired.

[Insti]

I prefer #946 - Revert "Note expected accuracy in space-age description"

[petertseng]

You know, if I go by the majority, since of people other than myself two people support each of #945 and #946, I could declare myself the deciding vote, and guess what, I support #945.

However, I have a second metric that I judge by as well, that being path of least resistance. And you know something? It's much easier to add text to a problem-specifications descriptions (.meta/hints.md) than it is to remove it. You can expect an issue about that soon. Until subtracting text is possible, to minimally support my desired directions yet allow for future expansions I expect I may merge #946, then rebase #945 on it so that it's ready for people when people are ready for it.

[petertseng]

Whoa there, at least let me rebase before closing it.

[petertseng]

There, now it can be reopened and merged when y'all want it. It's in your hands now.