Description: entered =HEX2DEC("d5caef682d") and got -181278906323. Should be 918232721453. -181278906323 converts to FFFFFFD5CAEF682D, so it seems to be adding 6 F's to the front for some reason. Steps to Reproduce: 1.Type in "=HEX2DEC("d5caef682d")" to any cell 2. 3. Actual Results: Returned -181278906323 Expected Results: Return 918232721453 Reproducible: Always User Profile Reset: No Additional Info:
Confirmed with Ubuntu 18.04.1 and LO 6.3Alpha0
(In reply to Drew Jensen from comment #1) > Confirmed with Ubuntu 18.04.1 and LO 6.3Alpha0 Also I put new as it is my understanding the function should accept up to 10 digits for the hex number, and this value is 10 digits. Maybe I don't have that right however.
I don't think its wrong because tested with gnumeric and AOO 4.1.6; 4.2.0alpha -1,83E+011 is the result i see, and adjust the cell give -181278906323 But lets ask the expert's on this, set this back to unconfirmed Best regards
https://www.binaryhexconverter.com/hex-to-decimal-converter, https://hextodecimal.org/ or https://www.rapidtables.com/convert/number/hex-to-decimal.html gives 918232721453 as an answer. If I convert -181278906323 back to hex I get FFFFFFD5CAEF682D. So it seems the calculation of LO, AOO and gnumeric are wrong. They don't look for the first FFFFFF, which gives a negative. Or the first 6 are always set as F's by default.
After reading the explanation in comment 4 and have a look at the website given by MM i confirm the problem. And i think its inherent from ooo Version: 6.3.0.0.alpha0+ Build ID: b052974a6574e4074794ffa590fe60f7c1726768 CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); UI-Language: en-US Calc: threaded
result in excel 2016 is: -181278906323
-181278906323 is the expected result. "The HEX2DEC function syntax has the following arguments: Number Required. The hexadecimal number you want to convert. Number cannot contain more than 10 characters (40 bits). The most significant bit of number is the sign bit. The remaining 39 bits are magnitude bits." If you want to convert out of range numbers, use DECIMAL and BASE (for reciprocical) functions.
I'm Confused, isn't "d5caef682d" 10 characters? If so why dose it not convert properly into "918232721453"?
Hexadecimal "d5caef682d" if not signed is 918232721453 in decimal and 1101010111001010111011110110100000101101 in binary. Which is a 40 bit number, and the 1st bit is 1. So this is a negative number as per specification : http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part2.html#__RefHeading__1018822_715980110 All 10 digits hexadecimal beginning with 8-F are negative. (1-7 are positive)
(In reply to GerardF from comment #9) > Hexadecimal "d5caef682d" if not signed is 918232721453 in decimal and > 1101010111001010111011110110100000101101 in binary. > > Which is a 40 bit number, and the 1st bit is 1. > So this is a negative number as per specification : > http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part2. > html#__RefHeading__1018822_715980110 > > All 10 digits hexadecimal beginning with 8-F are negative. (1-7 are positive) Some good news on this - I was mislead, kind of, in that I went to the currently available Calc Guide from TDF for details on this function and in the guide there is no mention of the constraint on the high bit (only that it was max 10 characters and my calculator results of course didn't match the software results) - but, the good news is that, in the current help system this is explicitly explained, and language is now in the draft for the next release of the Guide explaining it in detail also.