10 August 2010

Questions about the 9 August 2010 Quiz(1326)

The quiz on 9 August asked the following question: "Which of the following functions can you use to change the case of a string?" We then listed UPPER, LOWER, INITCAP, NLS_INITCAP and REVERSE_CASE. We scored the first four as correct, the last as incorrect. We received emails raising the following concerns: 1. "The wording for the today's quiz should be slightly different (bold word added): 'which of the following builtin functions...". Since anyone could write a function with the name reverse_case and use that to change the case of a string." 2. "For today's quiz question, regarding functions you can use to change the case of a string, I think I answered correctly based on my perception of your intent of the question, however, I wanted to point out that technically NONE of the functions listed CHANGE any supplied string, but instead return a new string, actually leaving the supplied string itself unchanged." 3. "Depends what case the string was to start with e.g. lower('asdfg') will not change case but UPPER('asdfg') will, similarly UPPER('ASDFG') won't." Regarding (1), I will change the text of the question to explicitly reference "built-in functions," but I do not think it was necessary, given the assumptions that we state for the quizzes. Anyone could write a function, but unless that function is defined as part of the question, you must assume that such a function does not exist. Regarding (2), yes, it is true that these functions do not actually change the case of a string passed to them. Instead, they return a string with a possibly changed case. I believe, however, that the meaning of this question was clear and will not be adjusting any scores or ranks. I will, though, change the text to make that explicit. Regarding (3), the player is correct that there are circumstances under which none of these functions would return a string any different from that passed into it, but that wasn't the question. The fact is, you can use those first four functions to return a string with changed case. I look forward to your thoughts on this. Regards, Steven


  1. Steven, I must say that I respect your patience immensely....

  2. In general, don't change the wording to much or don't do it at all in this question. It is clear as it is and some people make it a sport to find ambiguity in someone sentences. I know, I do it too sometimes.
    Also if you must take into account every option that can be misinterpreted (intentionally?), even the assumptions, the question becomes unreadable.

  3. None of those concerns are valid, IMHO. 1. it's quite clear from the question and assumptions that no custom functions are available; 2. & 3. the question said "which functions *can you use to* change the case of a string", not "which functions *will* change the case of a string".

  4. Hello,
    I have to confess that the original question text made me confused and I considered it as the function must change the case of whole string and I did not pick the nls_initcap and initcap functions. And then, I saw the new version and much more clearer text of the question on the past quizzes section as "Which of the following built-in functions can you use to change the case of some or all of the characters in a string?". If the original text was like this I would select the inicap functions for sure.
    I think the scores must be justified.

  5. I should have added a comment to this blog before making the change in the text. The original formulation simply asked which of the functions "change the case of a string". It did not ask if the function changed all or some of the characters of the function.

    "Change the case" is a general statement that, I believe, incorporates both changing every the case of every character and changing the case of some of the characters.

    I do not think that this was necessary to answering the question. That is, I am not going to rescore/rank based on that objection.

    Having said that, I am always looking for ways to "tighten up" my questions and avoid any possible ambiguity in the future, so I did make that change.

    My apologies for any confusion it caused.