Note expected accuracy in space-age description

[stkent]

Inspired by exercism/kotlin#100.

Consistent with the rounding policy used by the canonical data.

[rpottsoh]

I'll trust that your math is correct. 😉

[stkent]

I pulled this from the canonical data, thereby passing the buck 😄

[petertseng]

Sure the README should impose the **requirement** to round the result, rather than to leave it unrounded?

[stkent]

The canonical data already imposed that requirement.

[petertseng]

I do not think the fact that the canonical data was rounded to two places implies that student solutions are expected to round to two places. My impression may be biased by the tracks that I have seen implement this exercise

[stkent]

It seems that explicit rounding would make life much easier for tracks with generated tests. Are there other cases where we use some approximate representation of the actual value you would expect to be computed?

[petertseng]

Here a te souce of my bias * Ruby exercism/ruby#103 exercism/ruby#104 * C# exercism/csharp#19 But, there are possibly other tracks that do not. I cannot provide them right now.

Are there other cases where we use some approximate representation of the actual value you would expect to be computed?

I thik space age is one of two of our exercis with foats. te othr is triangle, #798, but the expectatio is a boolean so no approximation. I suppose if there ae exercises thatuseproperty-based testing (diamond, dminoes) that iskind of in the same vein but not really?

[stkent]

From one of those threads you linked:

It's not a problem if the results should be rounded to two decimal places but I think it should explicitly say that in the problem.

That's the problem solved here, no?

[petertseng]

> It's not a problem if the results should be rounded to two decimal places but I think it should explicitly say that in the problem. That's the problem solved here, no?

Exactly the question I am asking: whether it is OK to explicitly require rounding and say so in the README. My immediate reaction is "This seems like an arbitrary extra requirement to tack on to the problem. Why not just let students leave the answers unrounded?", and therefore I originally thought that I would oppose adding the requirement. But I don't have a logical reason that the extra requirement is *bad*. One may even consider it **good** to expose students to how to round. Whether we want rounding or not, I think we run into the same problems regarding having to compare two floating point numbers, so I think those considerations don't affect this decision either way, but let me know if I am wrong, especially if there is a solution that produces a false negative or a false positive.

[stkent]

I think I see. There are essentially two main options that would make sense for generated tests:

1. expect rounding, mention this in the README, and provide the rounded values to match exactly in the data;
2. do not expected rounding, don't mention rounding in the README, and provide both rounded values to match and a rounding tolerance in the data.

This PR moved us to option 1; you're suggesting that we may want to consider something like option 2 based on the concepts it will introduce (assertions with tolerances, vs explicit rounding in option 1)?

[rpottsoh]

I apologize for merging too soon. This is an interesting discussion.

[stkent]

I apologize for merging too soon. This is an interesting discussion.

No worries, and agreed r.e. the discussion :) Easy to adjust once a conclusion is reached, if required.

[petertseng]

provide the rounded values to match exactly in the data;

I read that it is inadvisable to compare floating-point numbers for equality, but I have no firsthand experience backing up this statement (whether in the context of this exercise or other contexts) nor do I remember what exactly gave me this impression. So if the option to expect+mention rounding is taken, tolerances *may* still be necessary. I do not know for sure, so I hope anyone who knows more than I do can help.

provide both rounded values to match and a rounding tolerance in the data.

Interesting add-on that I hadn't thought of before! Adding a tolerance has the advantage of being a reminder to readers (human or computer) of the file. I would say the driver of the decision of whether to expect+mention rounding should be whether it makes sense to ask student implementations to round. Pro: Helps students learn how to round in the implementation language. Con: Seems "arbitrary", meaning there doesn't seem a good reason other than "because the specification says so". Based on that, I would say not to expect+mention rounding, with the strength of my opinion being 1/10. Whether to test with tolerances I think is driven by whether (in conjunction with whether we decide to round) it may cause false positives or false negatives. I don't know to what precision we would write the values in the JSON file if we don't expect rounding (so we would probably need tolerances). If we do expect rounding I don't see a reason it matters whether we have tolerances but given what I read I could be wrong.

[petertseng]

I do see that there is a factor in the decision that I had been disregarding by not mentioning it at all: The effect on test generators. This factor is good to consider, though I think secondary in relation to "whether it may cause false positives or false negatives"

[stkent]

So if the option to expect+mention rounding is taken, tolerances may
still be necessary.

This is an excellent point; given this, tracks need to decide on (or use a canonical) equality tolerance for both options I outlined, in which case, it might be better for the README to instead state this tolerance explicitly?

[petertseng]

it might be better for the README to instead state this tolerance explicitly?

That seems to make sense. May be a good time to link to any resources we can find on why checks for floating point equality are done that way. (There was talk in #798 of having a specific problem dedicated to floating point, but it seems exercises expecting floating point answers will also inevitably have to touch on equality)