1
\$\begingroup\$

I imagined a golf Challenge which seemed pretty interesting to me. But to make it doable, I'd like to offer one or several functions to challengers.
For exemple:

  1. Function 1
    Input: Integer a; id of a country
    Output: the total population of the country 'a'
  2. Function 2
    Input: Integer a, Integer b
    Output: the distance in kilometers between country 'a' and country 'b'

Is it possible to make it fair for everyone in this case?

\$\endgroup\$
4
  • \$\begingroup\$ It's not at all clear to me whether your question is "Is it fair to say 'Implement any one of these functions'?" or "Is it fair to have a single challenge which requires each competitor to implement multiple functions?" Could you rephrase, and also outline why you're worried that it might be unfair? \$\endgroup\$
    – Peter Taylor
    Dec 5 '13 at 16:58
  • \$\begingroup\$ Well, it was obviously poorly explained. Let's say that my golf-challenge needs external elements (that cannot really be invented). For example : "Write a program that calculates the product of the 1000 first decimals in the Deuteron mass, let's assume that f(n) gives you the n-th decimal of this constant". This is a quite easy problem, but it requires that the program accesses this data one way or another. But "offering" this function may not be fair for some languages. Is it clearer? \$\endgroup\$
    – Fabinout
    Dec 5 '13 at 19:03
  • \$\begingroup\$ Ah, so you're effectively trying to iron out the advantages some languages have in parsing input by instead supplying black boxes. \$\endgroup\$
    – Peter Taylor
    Dec 6 '13 at 0:14
  • \$\begingroup\$ That's one way of looking at it, but it could be easier to offer more complex problems to golfers. On the other hand it also could impacts languages which can't manipulate functions. As you said it, it could be possible to offer both a function AND an input, to makes things the most convenient for everyone? \$\endgroup\$
    – Fabinout
    Dec 6 '13 at 8:46
2
\$\begingroup\$

I think giving the competitors functions that they can assume works is fair, and rather interesting. There are some things that probably need to be done though.

There are restrictions on the way a language calls functions. For example, in golfscript ( and ) have a different meaning and it would be ambiguous.

I would allow the user to name the functions(as stated by the competitor) and obviously allow them to be accessed as they would in their language. For GolfScript it would be pushing the arguments on the stack, and then calling the block.

Even with these rules, it is still unfair to some languages that don't have a notion of functions at all, but for the most part they aren't going to be winning any golf challenges anyway.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Yeah.. sorry, brainfuck \$\endgroup\$
    – John Dvorak
    Dec 11 '13 at 21:45
1
\$\begingroup\$

In principle, I think that this is a fair way of levelling the playing field with respect to parsing input. Some languages have shorter syntax for calling functions than others, but a perfect handicapping system doesn't exist so I wouldn't worry about it.

However, you might make it very hard to write a test suite if you need to provide debugged versions of the function in every language which people might use to compete.

I suggest that you post your question idea to the sandbox and let people comment on the specifics.

\$\endgroup\$

You must log in to answer this question.

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