Which number formats are acceptable in output?

Question

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 and 5/7 acceptable? (In general, can an expression be output?)
• Is scientific notation acceptable? Like 3.45e56
• What about symbolic constants: 6pi, e?

Answer 1

Solution ≠ outputting an expression

I'll phrase this, this way: imagine there is a hypothetical question:

Given n output the sum of all numbers from 1 to n

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.

Answer 2

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.

Answer 3

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.300000000000001 is correct enough, as floating point does this)
• fractions to avoid the above, where reduced form is optional, unless specified

Answer 4

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).

Answer 5

I think these should be allowed:

• Extra 0s 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 numbers
• a+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.

Answer 6

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.