This answer gives the reciprocal of the required output, rather than the required output itself.

In a simpler challenge this might cut out a significant part of the work, but for this particular challenge the bulk of the work is still being done. However, this still gives the answerer an advantage over a competitor using the same language but giving the correct required output.

As pointed out in a since deleted comment, the limitations imposed by pure regex mean that answers generally take unary input and give unary output (where arithmetic is required), which doesn't allow an obvious way of giving a fraction as an output, which the challenge in question requires. I think the compromise found, of using unary to express a reciprocal, is ingenious, but I'd like to see discussion of whether this is valid, so we can have consensus one way or the other.

Is such an answer valid?

  • 2
    \$\begingroup\$ IMO comes back to the whole 'golf your code not IO', if an output format is excessively cumbersome then that'll be reflected on the challenge, but here that's not the case \$\endgroup\$
    – Downgoat
    Feb 23, 2019 at 19:37
  • \$\begingroup\$ I'm not sure if this can provide an advantage, for example the reciprocal of \$\frac23\$ is \$\frac32\$, which can't be exactly expressed in plain unary anyway. \$\endgroup\$ Feb 23, 2019 at 21:52
  • \$\begingroup\$ @Erik good point. In this particular case the output is always either zero or a fraction with a numerator of one, so apart from the zero case the reciprocal is always a positive integer. \$\endgroup\$ Feb 24, 2019 at 7:46

3 Answers 3


Ask the OP

There are many ways to take input and return output. We've made some standardized ways so that challenges don't have to redefine them every time.

However, for stuff like printing the reciprocal, this is something the OP needs to decide. I don't think it is a stretch of the imagination to think that this could be abused on simpler challenges.

(In essence, the answer here is "no". This isn't an allowed default output format. OP can always override, and for this particular challenge, I'd personally vote to allow it)


Outcome for the specific challenge mentioned

I have reconsidered the output requirement following a comment from Neil on the answer in question:

@trichoplax Could you consider the answer as being the ratio of lengths of two specific capture groups? (This would actually make the answer shorter as it takes the trouble to make the whole match be the result.) – Neil

As a result, I have amended the output requirement:

So for input 8, both 1/8 and 0.125 are acceptable outputs. Output as separate numerator and denominator is also acceptable, to be inclusive of languages that support neither floats nor fractions. For example, 1 8 or [1, 8].

  • \$\begingroup\$ This needs further discussion. I think it makes no sense at all in the context of a pure regex, as explained in my answer. This format would still only be able to represent fractions where both the numerator and denominator are in the range [0,input]. And also, how should the pointers to the backref numbers the numerator and denominator are stored in be counted towards the byte cost? Numerator/denominator is only one choice of format among an infinity of choices, and the information of that choice should also be counted towards the cost... but there's no standard format for that yet, so how? \$\endgroup\$
    – Deadcode
    Feb 25, 2019 at 23:35
  • 1
    \$\begingroup\$ @Deadcode This is only for this specific challenge, I'd go with Nathan Merrill's answer as consensus - there is no standard format for this, and likely never will be \$\endgroup\$
    – ASCII-only
    Feb 26, 2019 at 2:17
  • \$\begingroup\$ @ASCII-only There might be a format; I'm considering it for addition to RegexMathEngine. In any case, I would like to see some actual discussion on this, rather than people just talking past each other as is what has happened so far... \$\endgroup\$
    – Deadcode
    Feb 26, 2019 at 2:56
  • 1
    \$\begingroup\$ @Deadcode I think it's just an issue not many people have a strong opinion on, especially since not everyone is good enough at regex know the advantages/disadvantages of each format \$\endgroup\$
    – ASCII-only
    Feb 26, 2019 at 2:59
  • \$\begingroup\$ The consensus here (or at least the significant majority view) is that outputting the reciprocal is invalid unless the challenge author makes an exception to the default rules. I've chosen a compromise which I believe is consistent with the spirit of the originally specified output formats, without going as far as to accept reciprocal output. A change in the defaults would make it valid, but this meta question is now closed as a duplicate. Further discussion would require either 5 people to reopen this question as needing an answer separately from the duplicate target, or a new question. \$\endgroup\$ Feb 26, 2019 at 19:35
  • \$\begingroup\$ I think a new question would be more useful as it sounds like there is a case to be made for treating regex differently, which seems like a wider topic than this one example. \$\endgroup\$ Feb 26, 2019 at 19:38
  • \$\begingroup\$ Ignoring for the moment that I still strongly disagree with your decision regarding numerator/denominator, in this specific challenge, what does "lowest terms" mean when applied to zero? Would it be acceptable to return a result of zero as [0, 107], [0, 43], [0, 12], etc., or does it always have to be in the form of [0, 1]? You didn't reply to my in-challenge comment. \$\endgroup\$
    – Deadcode
    Feb 26, 2019 at 19:45
  • \$\begingroup\$ I have edited the challenge to clarify what formats are valid for outputs 0 and 1. I'm happy to respect whatever defaults the community decides on. \$\endgroup\$ Feb 26, 2019 at 20:36

Call the input a natural number \$n\$. I don't see a qualitative difference between:

  • Returning one number, in a challenge where it so happens that the reciprocal of the correct output is always infinity or a natural number \$≤n\$
  • Returning two numbers \$(a,b)\$, to represent a fraction \$a\over b\$ where the numerator and denominator are both guaranteed to be \$≤n\$
  • Returning two numbers \$(a,b)\$, encoding \$an+b\$, to represent a natural number that is guaranteed to be \$≤n^2+n\$
  • Returning three numbers \$(a,b,c)\$, encoding \$an^2+bn+c\$, to represent a natural number that is guaranteed to be \$≤n^3+n^2+n\$
  • Returning four numbers \$(a,b,c,d)\$, encoding \$(an+b)\over(cn+d)\$, where the numerator and denominator are guaranteed \$≤n^2+n\$
  • Returning two numbers \$(a,b)\$, encoding \$a×2^{b-\lfloor {n/2} \rfloor}\$ (floating point)
  • Returning four numbers \$(a,b,c,d)\$, encoding \${a\over b}+{c\over d}i\$ (complex rational number)
  • Returning four numbers \$(a,b,c,d)\$, encoding \${a\over b}+{c\over d}\pi\$
  • Various combinations thereof, and beyond

So the options are:

  1. Consider each of the above to be a distinct language, following the established PPCG convention regarding command-line parameters. The N-mover answer would then be unchanged, except perhaps to call the language something like "Regex (ECMAScript, reciprocal output)".
  2. Represent this metadata in some standard format (with the number of each backreference, and what it represents – \0 could indicate the return match itself), and add it to the byte cost of the regex. Then this would be a new language, focusing on pure regexes and confining the metadata format in a way that honors that restriction.
  • 1
    \$\begingroup\$ Strong disagree. (numerator, denominator) isn't just one possibility among infinitely many, it's by far the most natural one. This is not about command-line parameters; the established PPCG convention for I/O is that all allowed I/O formats count as the same language. \$\endgroup\$
    – Grimmy
    Feb 26, 2019 at 15:47
  • 1
    \$\begingroup\$ Very strongly disagree with you, @Grimy. You could pack the entire work of the program into the output method and just have a zero-byte regex. This is about command-line parameters, as that is how output methods would be naturally implemented in any interpreter that evaluates pure regexes, such as pcregrep (-o parameter with a numeric argument) and RegexMathEngine (not implemented yet, but planned). \$\endgroup\$
    – Deadcode
    Feb 26, 2019 at 19:34
  • \$\begingroup\$ Furthermore, (numerator, denominator) is not natural in any way. I already explained that both of those are limited to being in the range [0,input], which is by no means natural; it's just one among infinitely many. \$\endgroup\$
    – Deadcode
    Feb 26, 2019 at 19:50

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