Template talk:Hex2dec

Lowercase can give different result

Resolved

– & we must accept wikimedia's limited thing/king

Please compare:

{{hex2dec|A9}} --> 169
{{hex2dec|a9}} --> 169
{{hex2dec|0xA9}} --> 169
{{hex2dec|0xa9}} --> 169

So when the "0x"-prefix is missing, the lowercase gives a different (and incorrect) result. So I put the disputed-tag on it. Other input might give the correct result (as I have noticed). Inputting a straight valid hex value like "a9" should be possible. -DePiep (talk) 19:01, 7 September 2010 (UTC)[reply]

Template Template:Hex2rgb(edit talk links history) uses this one, and also has this error. Tagged & talked there too. -DePiep (talk) 10:22, 8 September 2010 (UTC)[reply]

I fixed that one, I will see if I can fix this one. Plastikspork _―Œ^(talk) 21:58, 10 September 2010 (UTC)[reply]

Solved, somehow. The source of the problem is untouched! Hex2dec is a deep template (nesting about say 16 levels, innit). That is expensive, we only got 40 levels. But if it works, than let's go with it (and pray for Wikimedia to give us some string-parsing functions). -DePiep (talk) 22:18, 10 September 2010 (UTC)[reply]

I was incorrect, and struck: this template is not solved. -DePiep (talk) 22:22, 10 September 2010 (UTC)[reply]

Note that the documentation doesn't claim it works without the 0x prefix. So, I am not sure if this is "broken", or perhaps you just want the addition of another feature? I could certainly add some logic to test to see if the 0x prefix exists, but is that necessary? Plastikspork _―Œ^(talk) 22:30, 10 September 2010 (UTC)[reply]

Yes the doc doesn't promise lowercase. So? That's a programmers-excuse. Every hex user knows: A=a. So let's not blame an editor for not writing a hex value in uppercase (and even if so: at least give an error-message). Oh please, hex2dec should accept as many input as possible. No excuses between us, good programmers as we are. -DePiep (talk) 22:39, 10 September 2010 (UTC)[reply]

Please re-read what I wrote. It claims to work for lowercase, but it does not claim to work without the 0x prefix. Thanks! Plastikspork _―Œ^(talk) 22:41, 10 September 2010 (UTC)[reply]

Yes I know it doesn't work for lc. That's what I protested. Once and for all: everyone is allowed to expect that it works with lc. That is what hex is about. Now stop repeating what the doc does not promise. Help making it behave as hexpected, or go away. No one needs a "I know why it doesn't function"-help. And here is the test again: {{hex2dec|a9}} --> 169. As every hex knows, that should be 169 decimal. -DePiep (talk) 01:01, 11 September 2010 (UTC)[reply]

Please be calm.

The problem seems to be an irregularity in the way some of the core parser functions work. as near as I can tell at the moment, what's happening is that the switch function is recognizing 0x and 0X as the start of a hexidecimal number and ignoring case in those cases for comparisons, but treating a9 and A9 as text strings and comparing them on a case sensitive basis. it's a knotty problem that I can't quite see my way through yet, but I'm pondering. --Ludwigs2 06:58, 11 September 2010 (UTC)[reply]

✓ ok, looks like I fixed it. plus, I think I may have reduced its resource footprint a bit. let's see if any problems crop up. --Ludwigs2 08:18, 11 September 2010 (UTC)[reply]

E7 wrong

{{hex2dec|E7}} --> 231 OK, As we expect (231₁₀=E7₁₆)

Now please look at this:

{{hex2dec|00D7}} --> 215
{{hex2dec|00E7}} --> 231
{{hex2dec|00F7}} --> 247

(Examples, now OK, removed to speed up the page) -DePiep (talk) 12:18, 16 September 2010 (UTC)[reply]

Anyone?

-DePiep (talk) 20:44, 10 September 2010 (UTC) Added more examples. -DePiep (talk) 20:59, 10 September 2010 (UTC)[reply]

Ah, at I myself: the "E7" is read as "exponent" 7 etc. So 0 * 10^7 = zero.

-DePiep (talk) 21:14, 10 September 2010 (UTC) (moved location)- DePiep (talk) 21:14, 10 September 2010 (UTC)[reply]

Okay, this should be fixable. I will see what I can do. Plastikspork _―Œ^(talk) 21:59, 10 September 2010 (UTC)[reply]

Great, and could you please be sharp on nesting deepness ;-) -DePiep (talk)

I think I resolved this as well. can someone check? --Ludwigs2 08:41, 11 September 2010 (UTC)[reply]

e.g. the lower three tests in the list say it's OK. The earlier version said 0E7-->0 and 00E7-->0. Actually, all E-examples in the list are OK now. I'd say it's solved. -DePiep (talk) 09:49, 11 September 2010 (UTC)[reply]

Non-hex value input: errors

Resolved

by User:Ludwigs2. No-hex input --> output is "0" (=zero)

This might be a question or an issue/bug. What if non-hex code is entered?

A: {{hex2dec|U+2E18}}, {{hex2dec|2E18}} --> 0, 11800
B: {{hex2dec|U+2018}}, {{hex2dec|2018}} --> 0, 8216
C: {{hex2dec|0x3G18}} --> 0
D: {{hex2dec|-10}} --> -16

Clearly, it says A=B while input is different. Also in D the minus sign disappears (is it allowed at all in hex?). So, what to expect when non-hex input??

- If minus is allowed, then it should be returned.

- It should never give a wrong result (A, C, D-maybe).

- It might give "zero", as an indication of a problem (which is wrong still, but not as misleading)

- It might give an error message like Error: no hex input, but that could appear in existing pages, which is undesired (we are not to spoil existing pages). Any thoughts? -DePiep (talk) 12:13, 16 September 2010 (UTC)[reply]

ok, I've edited it to output 0 for most non hex entries, by using the original problem as a hack for the solution. it won't distinguish between hex notation and exponential notation (22E5 is ambiguous in any case), and it won't return negatives (Hex is mostly used for natural numbers, not as a full numeric system, and writing code to handle negatives is too much of a pain for the value). If you don't like 0, let me know what output you'd prefer. --Ludwigs2 16:35, 16 September 2010 (UTC)[reply]

Great again: non-hex --> zero. Negatives: no return (0, clearly from D: -10 above))

But why write: "22E5 is ambiguous"? Check:

{{hex2dec|22E5}} --> 8933 (& revers: {{hexadecimal|8933}}) = 22E5₁₆)

If there is a holdback, we should put it in the /doc. If not: better.

For me, 0 is OK (instead of an error, or even worse: a wrong thing)

Did I say I enjoy your solution, with this minor-leveled nests? Again I say. -DePiep (talk) 22:10, 16 September 2010 (UTC)[reply]

22E5 is ambiguous because the software recognizes 0x22E5 as hex for 8933, but also recognizes 22E5 as the number 22*10^5, or 2,200,000. because the template explicitly works with the input as a string, there is no way for it to determine whether the user meant to put in a hex number (and forgot the 0x) or meant to put in a scientific notation number. It's very unlikely anyone would intentionally add a sci notation number into the template, mind you, but if they do there's no way for the template to recognize that they've done so, and it will be treated as though it were a hex number.

and my pleasure.

--Ludwigs2 22:26, 16 September 2010 (UTC)[reply]

That's the same for a decimal number. If I input "100", the temp cannot determine if it's hex or dec. But: that is the user's fault, not the template's. On a higher level of application. That is not what this template should or can cover. Let's hope the template-name says anything. By any smart or rightful mind: not a problem of this template. -DePiep (talk) 23:34, 16 September 2010 (UTC)[reply]