21
\$\begingroup\$

As far as I can tell, we don't yet have a definitive Meta consensus to the following question:

Are answers allowed to work "in theory" but fail in practice due to floating point issues?

For example, in this recent question, answers that attempt to find the answer by calculating \$\sqrt[d]n\$ will fail due to floating point errors calculating (for example) \$\sqrt[3]{125} = 4.99999991\$ rather than \$5\$.

This is a similar question that instead asks how a challenge should allow floating point imprecision, but doesn't answer whether or not it should be allowed as default.

\$\endgroup\$

5 Answers 5

Reset to default
25
\$\begingroup\$

No default; require all relevant challenges to explicitly state what to do with floating-point errors

By relevant, I mean the challenges where a theoretically valid algorithm involves floating-point numbers in the middle of computation. Even if the expected result is an integer, a square root (or any non-integer power) in many languages is likely to return a float. And then there's a whole array of functions that have no choice but return floats (unless your language is a CAS).

Allowing or disallowing such functions (and intermediate floating point values) has a huge consequence in code golf, to the point that I could say it defines the actual challenge. If the challenge author wants the answer to be exact in all cases, they should be explicit on that. If the challenge author is more lenient and feels fine with an answer that fails due to floating-point errors, they should be explicit on that too.

\$\endgroup\$
7
  • 3
    \$\begingroup\$ I initially agreed on "allow FP errors by default", but after reading some previous meta posts on the topic (which involved a lot of controversy), I guess "no default" might be a sensible option too. \$\endgroup\$
    – Bubbler
    Commented Dec 4, 2020 at 6:22
  • 3
    \$\begingroup\$ Not that I agree 100% with either my or your answers, but one potential issue is that every challenge that involves floating points would be required to specify the specific rules, which adds to our (increasingly) complex rules that new users have to follow \$\endgroup\$
    – caird coinheringaahin g Mod
    Commented Dec 6, 2020 at 4:10
  • \$\begingroup\$ @cairdcoinheringaahing The wording was a bit strong, but we can just ask to include the information when necessary. I don't think it's too much of an additional hassle. \$\endgroup\$
    – Bubbler
    Commented Dec 7, 2020 at 1:01
  • 2
    \$\begingroup\$ @cairdcoinheringaahing I think having an arbitrary rule that people would have to override is worse for new users compared to requiring them to explain what is necessary. Adding more to the amount of meta that people need to read to understand the site is what makes things complicated. \$\endgroup\$
    – FryAmTheEggman
    Commented Dec 11, 2020 at 17:14
  • \$\begingroup\$ @cairdcoinheringaahing: Perhaps we need a meta post with answers each giving a set of FP rules (with detailed explanations and some corner cases). Challenge authors can pick from one of those recommended sets of rules by linking it. IDK if this would get unwieldy, and how we'd decide what's worthy of becoming a possible-standard set of FP rules, though. But if challenges have to define FP rules for themselves, we should have a canned choices to pick from. Floating point is rarely as simple as you think it is. \$\endgroup\$
    – Peter Cordes
    Commented Dec 13, 2020 at 14:26
  • 3
    \$\begingroup\$ (To quote Bruce Dawson's paraphrase of a famous line, [Floating-point] math is hard. You just won’t believe how vastly, hugely, mind-bogglingly hard it is. I mean, you may think it’s difficult to calculate when trains from Chicago and Los Angeles will collide, but that’s just peanuts to floating-point math.) \$\endgroup\$
    – Peter Cordes
    Commented Dec 13, 2020 at 14:27
  • \$\begingroup\$ It seems as though this has a clear consensus (+21/-1 vs +16/-4), so I’m going to mark this as accepted \$\endgroup\$
    – caird coinheringaahin g Mod
    Commented Dec 22, 2020 at 13:12
16
\$\begingroup\$

Yes, answers can fail due to floating point issues

So long as the algorithm/mathematics/logic behind an answer can be proven correct, it doesn't matter if the implementation fails due to the limitations of computers and programming languages. For the example question, answers that fail because of the miscalculation in \$\sqrt[3]{125}\$ are still acceptable, so long as they fail because of the floating point error.

This is in line with our policy that answers may fail for numbers outside the bounds of their language, so long as they work in theory for all inputs

\$\endgroup\$
3
  • 1
    \$\begingroup\$ I totally agree with the last line. Accurate calculation on real numbers is one thing that is outside the bounds of the language (most languages, actually) for practical reasons. \$\endgroup\$
    – Bubbler
    Commented Dec 3, 2020 at 23:44
  • 11
    \$\begingroup\$ I mostly agree with that as a default rule. However I think there's a difference between integer overflow (which are inevitable with arbitrary large inputs) and floating point errors which can sometimes be avoided by choosing a different algorithm that doesn't rely on floating point numbers. This is the case for the recent challenge linked in the question, where the expected output is actually an integer. So I think it might be worth adding that the OP is perfectly entitled to explicitly forbid floating point errors if such alternate algorithms are known to exist. \$\endgroup\$
    – Arnauld
    Commented Dec 4, 2020 at 1:39
  • 1
    \$\begingroup\$ @Arnauld Challenge writers are always free to override the defaults if they want to. I'm not sure if I should edit the "override if such algorithms exist" into this answer, or if another answer should be posted, given that the difference could be fairly significant in some cases \$\endgroup\$
    – caird coinheringaahin g Mod
    Commented Dec 4, 2020 at 1:43
0
\$\begingroup\$

No, answers cannot fail due to floating point issues

In some challenges it may be necessary for the author to override the defaults, but in many cases it is possible to avoid floating point issues using a different algorithm or workaround.

The goal of code golf is to make the shortest program that performs the task. Our consensus is that languages are defined by their implementations, rather than how they should theoretically behave.

\$\endgroup\$
4
  • \$\begingroup\$ I don't necessarily agree with this, but I do think these are valid points against it. \$\endgroup\$
    – rydwolf
    Commented Dec 3, 2020 at 23:55
  • 2
    \$\begingroup\$ Maybe don't post answers you don't agree with. This is a discussion not a poll, sharing your honest ideas is much more valuable, and if there are people who support this view point one of them will surely make their case. \$\endgroup\$
    – Wheat Wizard Mod
    Commented Dec 4, 2020 at 10:29
  • 1
    \$\begingroup\$ @WheatWizard I guess a better way to have put it would be "I don't agree with this for all challenges", but I do think these are useful points to bring up. \$\endgroup\$
    – rydwolf
    Commented Dec 4, 2020 at 13:35
  • \$\begingroup\$ Good point. If some implementation of some algorithm is poor (inaccurate) because it used poor tools (floating-point), then it is no mitigation to say that using them inevitably risks poor results. The answerer should instead consider implementing that same algorithm using better tools. Or a different algorithm. \$\endgroup\$
    – Rosie F
    Commented Jan 9, 2021 at 21:16
-2
\$\begingroup\$

No*. Challenges should specify precision requirements.

Challenges that operate with real numbers should include explicit precision requirements- and do so with floats in mind. Unless you have a good reason to require very high precision, you should specify a standard that is well within reason for single-precision floating point numbers, e.g. +/- 0.001 for numbers between -10,000 and 10,000.

What about other representations of real numbers?

Answers should have the freedom to use different representations of numbers. If you specify that an answer can fail due to machine precision, that opens new questions for other representations that have just as much capability to fail. What if I use a half-precision float? What about fractions? Decimal floats? Fixed-point numbers? What standards are these representations held to? What happens when you introduce irrational numbers?

Extremes

In a comically extreme example, you could implement a solution in such a way that it always returns 0 due to floating point errors even though the math is theoretically correct. It goes against the spirit of solving a challenge if the answer is always wildly incorrect.

When integers are expected

Regarding situations like the referenced challenge, the challenge creator should make this expectation explicit as well. And yes, I think this is a valid thing to expect.

There are cases where a floating point result of a calculation could be close enough to an integer (but not exactly an integer, for instance \$995207\pi = 3126535.0000011\$) to get erroneously rounded to an integer. It is the answerer's responsibility to prove that a floating point error of integer rounding is nevertheless correct for all possible inputs or otherwise work around floating point limitations. Since each individual operation on a float can lose precision, these kinds of almost integers can erroneously become integers and violate the integer precision expectation.

Integers can be held to a much higher standard than floats because they are discrete by their very nature and discrete is what computers excel at.

*Opting in is fine

Challenge writers should still have the option to allow answers to fail due to floating point issues as long as they explicitly state it, but should avoid doing so without a good reason.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ This doesn't handle the situation which inspired the meta question: an algorithm that uses floating-point numbers in the middle but always gives an integer as a result (which may or may not be correct due to the imprecision in the middle). \$\endgroup\$
    – Bubbler
    Commented Dec 9, 2020 at 23:15
  • \$\begingroup\$ @Bubbler I have addressed the case in question and added it to my argument. \$\endgroup\$
    – Beefster
    Commented Dec 16, 2020 at 0:15
-6
\$\begingroup\$

It depends on the type of the result.

If that's strictly an integer what we require then we shouldn't accept floating point errors.
If it's not an integer but a general value then there may be a relative error and we have to specify it.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .