Calc (number types in depth)

[eriknoc]

I apologize in advance, as I don’t know where else to post this. I also apologize for this being long winded. This is not a question the general public would be able to answer. I’m hoping I can get an answer from one of the Calc programmers for an answer to this from a programming prospective (not a general user prospective). Now I’m not a well seasoned up to date programmer, but I have dabbled in BASIC, C, C++, Pascal, 6502 assembly and pc assembly, off and on mostly throughout the 90’s. So I’m not oblivious to simple to moderate programming concepts.

Okay, so here’s my question. Why can’t binary, hexadecimal, octadecimal (or a custom base type) numbers be an actual number type in any spreadsheet program? I did ask in Microsoft’s help forum (I believe) many years ago, but the only answers I got was you can’t do it, and to use dec2hex, dec2bin, etc… They also told me if I wanted to create a column and/or of hex or bin numbers via dragging the handle of a cell, I would have to create a column and/or row of decimal numbers, another column and/or row of dec2hex conversions for viewing, and then reference the dec column for any calculations I wanted to do, and then convert the answer back using dec2hex. And if I didn’t want or need to see the decimal numbers, then I could just hide those columns and/or rows. I don’t get why this is such a difficult concept to have included in a spread sheet program. Windows calculator (I know. It’s much less complicated) can jump around between dec, hex and bin, on the fly. I have also made simple programs that convert between these different base numbers. Obviously, the programmers had some thought on these number types, because we have these xxx2xxx functions as a result. I’d like to know why they chose to have a functions work-around instead of just having them as number types.

I believe that to be an unnecessary level of complexity to end users in having to continually do this “work-around” to these not being number types in the first place. It doesn’t make sense to me to have to make this a separate series of number-to-text or text-to-number functions in order to calculate anything. So my logic is, we already have many number types as it is. The date/time (mm/dd/yyyy XX:XX:XX) looks much more complicated than bin, hex and oct put together, and the date/time is treated as a number type, in which you can reference them in formulas and even drag the handle of the cell it’s in to make a list of incremental changes.

I did at one time try to look through the .xls file specifications, but it was so mind boggling complex that I wasn’t able to hardly make heads or tails of it. I don’t remember if I tried looking through the .ods file specifications or not, but I suspect it would be just as mind boggling.

Thank you.

[Lupp]

(I am NOT a devloper.)
Number types are a mathematical concept primarily. Mostly these types are considered to describe sets. There are the common types like “natural numbers”, “whole (integer) numbers”, “rational numbers”, “real numbers”, “complex numbers”. All these sets are of infinite cardinality.
Since a real computer only allows for a finite number of states (and for many more “pragmatic” reasons) software can only represent a finite subset of any of the mentioned number types.
Moreover software needs to represent numbers in formats appropriate for different purposes: Sometimes “human readable”, sometimes “interchangeable with other software”, sometimes “as UniCode prefers for labelling CodePoints”, and very rarely “as user eriknoc currently prefers”.
For spreadsheet software and for much of other software used for calculations the most relevant aspects are sufficient efficiency in calculations and standardization concerning interchangeability.
To ease both there is global styndardization concerning the calculating units of computers (hardware!). Spreadsheet generally prefer to internally represent all the numeric data in IEEE 754 Double on the hardware. In Calc this is the one and only actual number type - and this type never is decimal though some function-names suggest it is.
Quoting the OP: “Why can’t binary, hexadecimal, octadecimal (or a custom base type) numbers be an actual number type in any spreadsheet program?”
A simple answer is: What you listed as " number types" actually are none. They are formats for different standards of representation. Software can, of course, implement support for these formats concerning the display and the for the process of recognizing entered data as well. If doing so it has to care for all the related problems concerning user expectations, ambiguities, expense in relation to usefulness, portability/interoperability, and many more.
The current state is: Support only by the so-called conversion functions.

You may file a feature request (bug with severity/importance enhancement) to bugs.documentfoundation.org
But: Many a user would be seriously surprised if they enter fade and get “recognised” something that equals 64222.

BTW: There is no octadecimal format I would know of. You meant octal most likely.