# Which number formats are acceptable in output?

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 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?
• Related – Peter Taylor May 28 '16 at 10:05
• 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. – user62131 Jan 15 '17 at 17:13
• @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. – trichoplax Jan 16 '17 at 17:50

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

• Here's an example where being able to output a fraction instead of a float saved bytes. – trichoplax May 27 '16 at 1:43
• In Mathematica, for example, taking 5 * Pi actually returns 5Pi; it doesn't use floating-point numbers internally. – LegionMammal978 May 27 '16 at 16:54
• What's your stance on 5e6? What if the number is in base 7 (so its 5*7^6)? – Nathan Merrill Jun 1 '16 at 21:54
• Do fractions need to be reduced? – Nathan Merrill Jun 1 '16 at 21:55
• I was going to say, with this reasoning, fractions should only be valid if they're in lowest terms. – user62131 May 4 '17 at 1:13
• @ais523 I am going to say yes as every language I know of handling fractions simplifies them – Downgoat May 4 '17 at 17:19

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

• Does this mean that output in languages that round floats by default when printing wouldn't necessarily be acceptable? – Sparr Dec 20 '18 at 1:40

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

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

• @WheatWizard Clarified answer – Solomon Ucko Jul 14 '17 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.

• I take it you mean "what a calculator would output"? Usually they can take inputs with leading zeroes. – xnor Jun 2 '16 at 1:25
• 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.. – Peter Taylor Jun 2 '16 at 10:21
• @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. – Nathan Merrill Jun 2 '16 at 13:42
• 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). – user62131 May 4 '17 at 1:14