10
\$\begingroup\$

When I take the time to test solutions of competitors, I sometimes find failing answers, which not even solve the examples.

I don't want to discuss a certain question and its solutions, but we all prefer concrete examples - don't we? So please don't take it personal.

For the question to spoonerize words, we got the examples:

Example: A lack of pies = A pack of lies. Bad salad = Sad ballad (ish) :)

3 of the early solutions produced lA pack of ies, 2 of them ruby, 1 perl. I didn't test the haskell, J and C# solution, because I don't have them installed.

It's not the first time, that I stumbled over easy to find bugs. Of course, it is always hard to avoid all traps from complicated border cases, but such obvious failings?

In my opinion we should be honest in providing only answers which work, or disclosure ourselves known shortcomings.

My voting policy is normally to upvote every answer which is better than my own one, but I would like to be sure to only vote on working solutions. I don't want to install every competing language on my machine, to perform basic tests on code, I can only guess about (haskell, J, C# for me - maybe Scala, bash for you).

And I suggest to routinely test competing code. If we allow too much errors, the answers which only pretend to solve the puzzle will win.

Fun and entertainment only work, if you take it seriously. :)

update:

Well - maybe my view is too much biased from my first interpretation of what the challenge is, and the other people did not provide faulty answers, but just interpreted the question in a different manner. I can hardly leave my perspective, but I have to admit, that my interpretation of the question can be questioned.

... Write a program to spoonerise two words ...

In this case, my whole concern shrinks, and becomes: Don't answer ambigious questions, but wait for the master of the game to clarify the meaning, maybe by downvoting and voting to close.

\$\endgroup\$
6
  • 1
    \$\begingroup\$ As originally posted, the question said "Challenge: Write a program to spoonerise two words in the shortest characters possible." One of the rules also states: "the th gets removed and put on the front of the other word", implying only two words. \$\endgroup\$
    – migimaru
    Aug 20, 2011 at 17:24
  • \$\begingroup\$ Is this version not visible when looking through the edit-history? That's where I found the 'A lack of pile'. \$\endgroup\$
    – user unknown
    Aug 20, 2011 at 18:01
  • \$\begingroup\$ "A pack of lies" is in the original, but that's an example of a spoonerism, not an example input for the challenge. See Alex's comment on the Haskell submission, where he says "when I wrote the question I was only aiming for 2 words." \$\endgroup\$
    – migimaru
    Aug 20, 2011 at 18:28
  • \$\begingroup\$ Aug 16, 22:05: 1. If the first letter is a consonant, you must include the preceding letters until you reach a vowel. (e.g. 'thanks' - the th gets removed and put on the front of the other word). 2. With words that start with vowels, do not remove anything from the start of the word. \$\endgroup\$
    – user unknown
    Aug 20, 2011 at 19:50
  • \$\begingroup\$ That quote says "the front of the other word," which implies that there is only one other word to apply it to (i.e. 2 words). The "2 words" does not refer only to words starting with consonants. Joey Adams asked 'does "big apple" become "ig bapple", and does "ant eater" remain the same', and Alex confirmed that they do. (Note that apple does not start with a consonant yet still gets spoonerized.) \$\endgroup\$
    – migimaru
    Aug 20, 2011 at 20:01
  • \$\begingroup\$ Yes, but this 'of the other word' follows an 'if ...', and the if the first letter is a consonant implies, that there are cases, where it isn't. \$\endgroup\$
    – user unknown
    Aug 20, 2011 at 20:50

2 Answers 2

Reset to default
8
\$\begingroup\$

As a general rule I am a big fan of down-votes on all the sites, they are where the cruft is cleared: up-votes only sort the workable answers.

When I take the time to test solutions of competitors, I sometimes find failing answers, which not even solve the examples.

I trust that you point out these deficiencies in the comments? Because testing does take time and effort and I only do it religiously when I posed the problem.

In my opinion we should be honest in providing only answers which work, or disclosure ourselves known shortcomings.

Quite so. I personally find that a list of the limitation of a particular solution shows an understanding of the problem.

There have been several discussion of the "how and why" of voting on CodeGolf.SE. It is in some ways less clear cut than the on factual Stack Exchange sites. My personal policy runs to

  • Acceptance for the submission that "wins" (i.e. shortest in , wins the round robin in , etc...)
  • Up-votes for submissions that meet the spec, take a creditable crack at winning, I more or less understand and are clever or interesting in some way.
  • Down-votes for submissions which do not meet the spec and the author will not correct, or make no attempt to win (i.e. un-golfed submissions to (which is to be distinguished from a golfed submission in a wordy language)), try to demonstrate how "clever" the author is by breaking the spirit (those were funny in the late paleolithic when they were first discovered).
\$\endgroup\$
1
\$\begingroup\$

I agree that ambiguous questions should be clarified before answering. We had a recent case which gathered a handful of answers while the question was still so vague that I couldn't say whether they actually solved the problem or not. (It could still do with improvement).

In such a case I think there's no doubt that it's reasonable to down-vote the question; and I can certainly see a case for down-voting answers which don't seem to be making reasonable assumptions about how the question is likely to be fixed. OTOH I personally wouldn't down-vote questions which explicitly state their assumptions and then solve their interpretation.

\$\endgroup\$
1
  • \$\begingroup\$ Mobinga (meanwhile) answered some questions (should work for negative values). Some parts aren't that ambigious. If the output shall be Integer A is greater than B. it is not enough to know that they are not equal - whether you out 'A is lesser than B' or 'B is greater than A' in the case A is not greater B. But the size was not specified, or maybe to handle values of arbitrary size. That's true. However: a discussion process in chat or in the meta thread, can clear many questions before. \$\endgroup\$
    – user unknown
    Aug 23, 2011 at 0:05

You must log in to answer this question.

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