The help for HEX2DEC says this: HEX2DEC(Number) Number is a hexadecimal number. The number can have a maximum of 10 places. The most significant bit is the sign bit, the following bits return the value. Negative numbers are entered as two's complement. Example =HEX2DEC(64) returns 100. However, if you try to input a hexidecimal number that contains digits outside of 0-9, then it does not work: =HEX2DEC(a) returns #NAME =HEX2DEC("a") returns 10, as expected. Please clarify that a string argument is taken, not a numeric one. The help was taken from online, https://help.libreoffice.org/Calc/Add-in_Functions,_List_of_Analysis_Functions_Part_One#HEX2DEC So should be up-to-date
Do you mind giving us a sample of what would be more accurate? I can do the change but I'm not familiar enough with HEX2DEC to come up with the wording
Something like this maybe? Number is a string that represents a hexadecimal number, and can have a maximum.... ... Example =HEX2DEC("6a") returns 106
> Please clarify that a string argument is taken, not a numeric one. A numeric argument can be taken as well. Try to enter 6a to A1 and then =HEX2DEC(A1). So I would suggest to update the help as: Number is a hexadecimal number or a string that represents a hexadecimal number. It can have a maximum.... And the same applies to HEX2BIN and HEX2OCT functions.
For someone with commit acccess, it is simple to clarify the help text to avoid confusion. The original example given in the help is misleading as it does not work for arbitrary valid hex digits. The example (64) is fine, but other examples (eg A1) are clearly a cell reference, and cannot be used as per the example. Non-ambigous results, like 1A don't work at all, and using single-quotes gives the wrong answer entirely. In my testing, direct strings with double-quotes return the right answer every time, as do cell references. I assume with cell references there is some type conversion happening that is not happening in the forumula bar. The cell reference case is possibly a separate case, as can be seen by typing 6a into cell A1, then elsewhere typing =IF(A1 == "6a", "String equals","Not string equals"). It is possible == is performing type conversion. Removing the ambiguity in the example would be very helpful. =HEX2DEC("6a") (106): =HEX2DEC(6a) (262) =HEX2DEC(0A) (#NAME) =HEX2DEC(1A) (#NAME) This bug is a little old unfortunately, and easy to trip over.
I just think we need to agree on final wording, that's why I put my remark about the fact that numbers are also accepted (under certain condition). When we agree on it, I am going to propose a patch (you don't need commit access, I don't have any). So my suggestion is: ----- HEX2DEC(Number) Number is a hexadecimal number or a string that represents a hexadecimal number. It can have a maximum of 10 places. The most significant bit is the sign bit, the following bits return the value. Negative numbers are entered as two's complement. Examples =HEX2DEC(64) returns 100. =HEX2DEC("6a") returns 106. ----- ...and similarly for HEX2BIN and HEX2OCT. Is it OK? Any comments?
Hi, Thanks for the quick response. I think we just need to remove the =HEX2DEC(64), and maybe add a counter rexample. While it works for the 64 case, it is not reliable or general for all hex numbers. I would have: -- Examples =HEX2DEC("6a") returns 106. =HEX2DEC(A1) returns the hexadecimal representation for the contents at cell A1, where possible. -- this makes it clear that =HEX2DEC(64) is a "quirk", and not reliable usage.
I prepared a patch and submitted it to Gerrit: https://gerrit.libreoffice.org/#/c/9906/ I haven't included the example with reference, it seems a bit confusing for me. The patch can be changed, so any further suggestions are possible.
Stanislav Horacek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/help/commit/?id=d2e055fb50d07664c8b90456c07c2d39d49e62df fdo#63274 clarify hexadecimal argument in HEX2DEC and similar functions The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.