Template talk:Hexadecimal

Lua version: changing effects when not-a-number input

I have put the old code into the {{Hexadecimal/sandbox}} [1]. The effects of the Lua-change now are visible in {{Hexadecimal/testcases}}. Two not a number inputs have changed their template result:

{{Hexadecimal|}} → (was: Expression error: Unexpected > operator)
{{Hexadecimal}} → 0₁₆ (was: 0₁₆) (to compare).
{{Hexadecimal|foo}} → foo (was: Expression error: Unrecognized word "foo".)
{{Hexadecimal|5 E7}} → 2FAF080₁₆ (was: 2FAF080₁₆)

a. I think the top two should give the same result.

b. The foo example should not suggest "foo" is a number, right? Even turning it into a "0" (zero) is disputable, one can argue it should return "" a blank or not the base ₁₆. Since both are new outputs in Lua, we can introduce a smart solution when introducing Lua (no existing usage affected, except old errors).

c. Example #4 is special situation of #3. Input may be intended as a value using exponent (in base 10). Then declaring that same value being base 16 is misleading and probably wrong.-DePiep (talk) 14:51, 24 February 2013 (UTC) added example #4 -DePiep (talk) 15:08, 24 February 2013 (UTC)[reply]

Agreed about b and c. I've fixed the template to not add the base ₁₆ if the input couldn't be parsed as a number, and to accept scientific notation with whitespace around the 'e', as the old implementation did. As to your first point, I don't think it really matters what the template does when no argument is passed in, as long as it doesn't totally blow up; the empty string and 0₁₆ are both reasonable results, so I don't think it's worth fixing. Toohool (talk) 21:08, 24 February 2013 (UTC)[reply]

The changes are fine. Example a. and c. now act alike: outputs for "" (empty string) and "foo" are consistent! Example b. is not just theoretical. This template is very often embedded in other templates. In these situations the output better not be dependent on (otherwise irrelevant) coding habit. The situations "parameter 1 not defined" and "parameter 1 defined, and empty" should be alike. "not defined" is not "zero" I'd say. -DePiep (talk) 22:07, 24 February 2013 (UTC)[reply]

Not sure I'm following. Typical usage of this template in another template would be something like {{hexadecimal|{{{1}}}}}, so the passed value in an error case might be the empty string or "{{{1}}}". In no case would the value be undefined, unless the template author used it flat-out incorrectly as {{hexadecimal}}. In what situation would this actually make a difference? Toohool (talk) 23:15, 24 February 2013 (UTC)[reply]

Your description of the issue is right, it's just that I end up with a different conclusion (suggestion). In a nutshell: I think the "no input parameter" situation should be treated as "non-numerical input" and so return a blank.

Indeed typical usage is covered, including most non-numerical string input. Also the situation: "empty string input" ({{hexadecimal|}} and {{hexadecimal|1=}}), or as it is described at mw:help: "parameter defined, but null/empty" (returns a blank here: not numeric). OK so far. But now, here, the situation "parameter not defined: parameter not used" ({{hexadecimal}}) is handled differently. The template now assigns value 0 to the parameter. That is a break of consistence (namely: "non-numerical" stays "non-numerical": it has no value). The situation may be theoretically, but it adds to consistency. And it prevents having to document an exception. The two differences in omitting a parameter is mw-based (not outside, logically), and should not bother editors. Incidentally, there is one example here ;-). -DePiep (talk) 09:50, 25 February 2013 (UTC)[reply]

Adding, for whichever outcome: We could apply the same handling for non-numeric input to more if not all templates in Category:Numerical conversion templates. Each might need a check on testcases, to be sure we do not introduce errors (do not break a pre-Lua usage). e.g., {{Base 36}}. -DePiep (talk) 10:27, 25 February 2013 (UTC)[reply]

I'm not saying that the current behavior is the best possible. But in rewriting an existing template, the first priority is preserving the existing behavior. As you showed above, the template always returned 0₁₆ when called with no argument. In the case of an empty or non-numeric argument, it is a change in behavior to return the text unchanged instead of a parser error, but I think it's an unambiguous improvement (if one has the mindset of putting readers above editors), so I'm comfortable with that change. On the other hand, changing the output of {{hexadecimal}} to return an empty string is not an unambiguous improvement, as the current behavior is already reasonable. If you want to look through the 8430 transclusions of this template to make sure no one is using it that way, be my guest, but it doesn't seem worthwhile to me. I don't think these invalid use cases should even be documented on the main template page (on the testcases page is fine), as it's not good practice for editors to rely on them. Toohool (talk) 19:51, 25 February 2013 (UTC)[reply]