4
\$\begingroup\$

When the program you write for a challenge writes/outputs to multiple of the default outputs, are you, the answerer allowed to state which one is counted for the purposes for the challenge?

For example, if my program

  • Leaves the output on the stack
  • Outputs to STDOUT

Am I allowed to say that the output to stdout counts without having to clean up the stack?

\$\endgroup\$
4
  • \$\begingroup\$ I feel like there are a lot of rather subtle issues to this. We generally ignore STDERR. But probably wouldn't accept a function submission whose outputs is its return value that prints to STDOUT as a side effect (or maybe I would? I don't even know). In your case: if the submission is a program, it can have whatever state you want at the end of the program. But if it's a function, I'd expect it to leave the stack clean and reusable. So I think what I'm saying is, there's a lot cases to distinguish here. \$\endgroup\$ Apr 3, 2016 at 15:19
  • \$\begingroup\$ @MartinBüttner I've seen solutions that are functions that output by printing and have a return value that is ignored, and nobody complained, so that seems to be precedent for ignoring some form of outputs. \$\endgroup\$
    – xnor
    Apr 3, 2016 at 18:20
  • \$\begingroup\$ @xnor I think with "normal" functions and return values it's less of an issue because in most languages you explicitly need to capture the return value if you actually want it, and ignoring it is free. In stack-based languages, leaving unwanted stuff on the stack in a function is a bigger problem, because you'll have to remove it manually if you want your stack back. \$\endgroup\$ Apr 3, 2016 at 18:22
  • \$\begingroup\$ Being able to say which output is counted kinda feels like cheating. "Oh, just ignore anything that isn't the correct output." \$\endgroup\$ Apr 4, 2016 at 16:11

1 Answer 1

7
\$\begingroup\$

Yes, you can choose the output.

In fact, this is already what we do.

Trying to specify which kinds of output can be ignored and which cannot seems artificial and will probably be ambiguous.

I therefore propose that we can liberally choose a single output format and ignore any results or side effects that could alternatively be chosen as output, with the following restriction.

The output format should be consistent for all possible inputs and every time the program/function is executed. The function

def primality_test(integer):
    print True
    return False

correctly prints True for primes and correctly returns False for non-primes, but it obviously should not be considered a valid submission to a challenge.

\$\endgroup\$

You must log in to answer this question.

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