Comments on this loophole meta answer suggest that more than a simple yes or no answer is required.
Which number formats are valid for output? Is there a difference between code-golf and other tags? If a challenge doesn't specify which are acceptable, which should be valid by default?
For example:
- Are
0.1
and.1
both acceptable? - What about leading zeroes like
0073
? - Are
3*3
and5/7
acceptable? (In general, can an expression be output?) - Is scientific notation acceptable? Like
3.45e56
- What about symbolic constants:
6pi
,e
?
-
1\$\begingroup\$ Related \$\endgroup\$Peter Taylor– Peter Taylor2016年05月28日 10:05:10 +00:00Commented May 28, 2016 at 10:05
-
\$\begingroup\$ I'm particularly interested in whether output as Roman numerals is acceptable. This is at least an order of magnitude shorter in INTERCAL than any other method. \$\endgroup\$user62131– user621312017年01月15日 17:13:34 +00:00Commented Jan 15, 2017 at 17:13
-
\$\begingroup\$ @ais523 you could add an answer and see how the voters and commenters respond, but it might also be different enough to warrant a new meta question. \$\endgroup\$trichoplax is on Codidact now– trichoplax is on Codidact now2017年01月16日 17:50:21 +00:00Commented Jan 16, 2017 at 17:50
6 Answers 6
The language's default format for numeric output is always acceptable if it's consistent and unambiguous
We accept function submissions that return numbers directly. As such, passing those to the language's "print a number" command (if it has one) should also be accepted; jumping through hoops to format output appropriately in a full program but not a function would just be inconsistent and penalise languages where a function has a lot of boilerplate.
By "unambiguous", I mean that it should always be possible to determine which number was output via looking only at the output; a hypothetical language which prints all numbers using the same string would need some other method of outputting a number. By "consistent", I mean that each number should always be output the same way; this is to prevent cheating via outputting an unevaluated expression or the like.
These rules make sense for all sorts of numbers (integers, rationals, floats, complex numbers, etc.). Note that this is not necessarily the only acceptable format (see the other answers for ideas on what other formats might be acceptable), just a lower bound (i.e. this format is acceptable, other formats might or might not be); some languages don't have numeric output commands at all, so another format would be necessary there.
As an example, INTERCAL outputs integers using Roman numerals by default. That's an unambiguous and consistent format, if a rarely used one nowadays, and decimal conversion code would add a huge number of bytes to a program; using the default output format makes a lot of sense there.
-
2\$\begingroup\$ Does this mean that output in languages that round floats by default when printing wouldn't necessarily be acceptable? \$\endgroup\$Sparr– Sparr2018年12月20日 01:40:37 +00:00Commented Dec 20, 2018 at 1:40
Solution ≠ outputting an expression
I'll phrase this, this way: imagine there is a hypothetical question:
Given
n
output the sum of all numbers from1
ton
Okay, so the answer should calculate this. Now let's say I wrote an answer and the output for input 5
is:
5(5+1)/2
Does this seem right? No. But I'm not completely against outputting expressions...
Fractions
If an answer were to output something like 2/3
I'd say this is fine as it can be considered a fraction representation of a number. An expression evaluates to a number, it is not a representation of a number, unlike fractions. So I don't see any reasons to ban fractions. Every language which supports fractions that I know of simplifies them so I'd say that fractions should be simplified.
Format of numbers
If a number has leading zeros (e.g. 00075
), or doesn't have a leading zero of a decimal (e.g. .43
), I'd say this is fine. An answer should really be focusing on solving the problem, not trimming leading zeros to conform to an overly-strict output format. Scientific notation applies as the same as above. As long as it conforms to the required precision. It is a perfectly acceptable representation of a number.
Symbolic constants
I'm not completely decided on this. For complex numbers, if I were to output: 5i
, for complex numbers, that would be fine.
For cases of π
and other constants, this is a bit more different, I don't know of any language that outputs π
itself rather than its value. I'd say maybe not as, for example in JavaScript, instead of doing Math.PI
, I could just do +"pi"
and save a couple of bytes, which seems like avoiding to actually calculate the answer to save bytes. I'd say challenges could override this on a case-by-case basis but I'm not completely decided on this.
-
1\$\begingroup\$ Here's an example where being able to output a fraction instead of a float saved bytes. \$\endgroup\$trichoplax is on Codidact now– trichoplax is on Codidact now2016年05月27日 01:43:22 +00:00Commented May 27, 2016 at 1:43
-
10\$\begingroup\$ In Mathematica, for example, taking
5 * Pi
actually returns5Pi
; it doesn't use floating-point numbers internally. \$\endgroup\$LegionMammal978– LegionMammal9782016年05月27日 16:54:28 +00:00Commented May 27, 2016 at 16:54 -
1\$\begingroup\$ What's your stance on 5e6? What if the number is in base 7 (so its 5*7^6)? \$\endgroup\$Nathan Merrill– Nathan Merrill2016年06月01日 21:54:48 +00:00Commented Jun 1, 2016 at 21:54
-
2\$\begingroup\$ Do fractions need to be reduced? \$\endgroup\$Nathan Merrill– Nathan Merrill2016年06月01日 21:55:25 +00:00Commented Jun 1, 2016 at 21:55
-
2\$\begingroup\$ I was going to say, with this reasoning, fractions should only be valid if they're in lowest terms. \$\endgroup\$user62131– user621312017年05月04日 01:13:11 +00:00Commented May 4, 2017 at 1:13
-
1\$\begingroup\$ @ais523 I am going to say yes as every language I know of handling fractions simplifies them \$\endgroup\$Downgoat– Downgoat2017年05月04日 17:19:04 +00:00Commented May 4, 2017 at 17:19
Generally speaking, any readable number format should be valid. This might include:
- leading 0s (00045.2)
- trailing 0s after decimal point (45.200000)
- floating point quirks (0.1+0.2=0.30000000000000004 is correct enough, as floating point does this)
- fractions to avoid the above, where reduced form is optional, unless specified
The current consensus on Should Booleans be allowed where a number is required? appears to be that true
and false
values (not strings) should be accepted in place of 1
and 0
(possibly IFF the language in question recognizes them as such).
I think these should be allowed:
- Extra
0
s at the start and end (end only after decimal point) - Scientific notation (or engineering notation, which uses powers of
10^3
i
for imaginary and complex numbersa+bi
for complex numbers (+
)- Floating-point errors
Any other types of mathematical expressions should not be allowed. Mathematical constants should be decided by the poster. Obviously, the question poster can override any of these rules if they want.
-
\$\begingroup\$ @WheatWizard Clarified answer \$\endgroup\$Solomon Ucko– Solomon Ucko2017年07月14日 18:09:12 +00:00Commented Jul 14, 2017 at 18:09
What would a calculator output?
The rule of thumb here is that we follow suit to what typical calculation programs output. Typical means things like calculators/spreadsheet programs, not symbolic calculators.
Integers, Scientific notation, Decimals
Allowed.
Leading zeros are also not allowed on integers, and a single leading zero is allowed (optional) on a number that starts with a decimal point: 0.785
Fractions
I'm not a fan of fractional notation. If I put a formula in my TI-83, and I got a fraction instead of a decimal, I'd be pretty surprised (and likely frustrated).
Constants
Once again, I go back to the rule of what would I expect a calculator to output. With the case of 2i
, its as reduced as possible, so printing out i
is valid. However, printing out 4pi
is not allowed.
As with all defaults, the OP can obviously change any of the above.
-
1\$\begingroup\$ I take it you mean "what a calculator would output"? Usually they can take inputs with leading zeroes. \$\endgroup\$xnor– xnor2016年06月02日 01:25:20 +00:00Commented Jun 2, 2016 at 1:25
-
4\$\begingroup\$ Excel is a really bad example to use, because it's notorious for its poor calculations. Besides, for many questions on this site fractions are a better representation than floating point, because they allow languages with big integers (and sometimes with no floating point support) to calculate exact answers, avoiding the complications associated with f.p.. \$\endgroup\$Peter Taylor– Peter Taylor2016年06月02日 10:21:38 +00:00Commented Jun 2, 2016 at 10:21
-
1\$\begingroup\$ @PeterTaylor ok, I didn't know that about excel. I agree that fractions don't have the problems of floating point, but I don't think that's enough justification to automatically allow it on every question. \$\endgroup\$Nathan Merrill– Nathan Merrill2016年06月02日 13:42:04 +00:00Commented Jun 2, 2016 at 13:42
-
14\$\begingroup\$ Just as a counterargument, at least one calculator I've owned outputs fractions using fractional notation by default (and has a key to press to see the value in decimal). \$\endgroup\$user62131– user621312017年05月04日 01:14:50 +00:00Commented May 4, 2017 at 1:14