Apache OpenOffice (AOO) Bugzilla – Issue 115798
DEC2BIN() and HEX2BIN(): support of more than 10 binary digits
Last modified: 2013-01-29 21:48:20 UTC
DEC2BIN() and HEX2BIN(): support of more than 10 binary digits, like BASE() do. While 10 digit are enough for decimal and hex numbers, 10 bit are very few for a binary number. Consider that as two's complement representation, the range is restricted to -512 / +511 only. As now, on the other side, BASE() do not support negative numbers, so there is no solution to represent high negative numbers. I saw that OpenDocument Formula require 10 digit, but let implement more than 10 digit (say "implementation-defined"): http://docs.oasis-open.org/office/v1.2/cd05/OpenDocument-v1.2-cd05-part2.html#a_6_19_7_DEC2BIN http://docs.oasis-open.org/office/v1.2/cd05/OpenDocument-v1.2-cd05-part2.html#a_6_19_11_HEX2BIN
binary places must be 32 up to 64 as modern cpu bus
Sounds like a good idea, because the current limitation is way too short. On the other hand for the general fix we have to consider the existing behavior, e.g. BIN2DEC(1100100100) results in -220 now, but with the suggested change it would result in +804 because the most significant bit used to be interpreted as the sign bit of a two's complement binary number and that MSB was the first digit of a ten digit binary number. Changing that would also decrease compatibility with descendants of the current code base. Of course one could say that nobody should have depended on the old (current) behavior because the limitation was obviously stupid as it was way too short. When fixing this issue maybe one should consider fixing the functions that have less potential for controversy, e.g. DEC2*, HEX2BIN, HEX2OCT, OCT2HEX, OCT2BIN, etc.
I hate to say it, but the OpenFormula specification is quite strict about the limitation of the text of the binary form being limited to 10 binary digits and that it be for a signed two's-complement value. So BIN2DEC(0111111111) is the largest positive value and BIN2DEC(1000000000) is the smallest (negative) value. (BIN2DEC(1111111111) = -1). Here's the relevant text: "Converts given binary number into decimal equivalent, with the topmost 10th digit being the sign bit (using a two's complement representation). If given Text, the text is considered a binary number representation. If given a Number, the digits of the number when printed as base 10 are considered the digits of the equivalently-represented binary number." I find that rather awful, but it is apparently an interoperablity requirement and it is wired into the OpenFormula specification. The weird thing about BIN2HEX is that the result is allowed to be up to 10 hexadecimal digits (still for a twos-complement value) even though the input is restricted to 10 binary bits. However, the desired number of hexadecimal digits is an optional parameter. There is this odd statement: "If the input has its 10th bit on, the Digits argument is ignored; otherwise, the Digits indicates the number of digits in the output, with leading 0 digits added as necessary to bring it up to that number of digits." So, for a negative input (10th-bit on), it is not clear how many hexadecimal digits are produced in the result (there being no default value for the Digits parameter). So I would say, for OpenFormula, the behavior of BIN2DEC is not a bug.
let concentrate on *2BIN functions at first. We can add an optional parameter for the number of digit (or the position of binary sign). If this parameter is missing, default to 10 for backward compatibility. The parameter can be up to 64
you may be interested in related RFE #115797 and 115799
Regarding #115797 and #115799, I note that the second has a JIRA issue at the ODF TC. However, it is marked as deferred until ODF 1.3 and I don't believe it has been taken up yet. So there is just what ODF 1.2 OpenFormula says that these enhancement issues conflict with. I suspect that the only clean way to solve this would be by alternative functions and deprecation of the present ones (though I am not so certain about BASE). Of course, it is possible for Apache OpenOffice to implement alternatives to the OpenFormula functions and identify them as implementation-specific extensions. I.e., org.OpenOffice.BASE or somethine equivalent. There are an interesting number of interoperability issues to reconcile.