What are some advantages/disadvantages of having built-in syntax to represent numbers in non-decimal bases?

Question

(For this question, I'm referring to integers. This question also assumes the language still uses base two internally, even if to the programmer it appears as base ten - this question is about syntax).

Numbers can be in different bases. For example, we typically use base ten. But, there are many others. As one example, the digits 10 in binary represent the same number as the digit 2 in decimal. For another example, the digits FF in hexadecimal represent the same number as 255 in decimal.

While most programming languages have numbers 'inputted' as decimal by default, there are some cases where easily allowing other bases can be useful, such as hex.

What are the benefits to having some type of syntax like 0b10 == 2 vs baseSomethingToInt(2, "10") == 2?

Adding dedicated syntax can add complexity, but there are examples of where it could also be useful. What are the reasons to (or not to) have syntax for this?

Answer 1

One advantage is bitwise arithmetic. Bitwise arithmetic is much easier to understand in bases with a power of 2 radix such as hexadecimal. Here it is fairly clear that I am masking out every other byte in these numbers:

uint64_t bswap(const uint64_t n) {
    return (n&0xFF00FF00FF00FF)<<8|(n&0xFF00FF00FF00FF00)>>8;
}

In decimal this is not clear as these numbers seem arbitrary and meaningless:

uint64_t bswap(const uint64_t n) {
    return (n&71777214294589695)<<8|(n&18374966859414961920)>>8;
}

Answer 2

In a domain where a specific base is used, it is clearer if the code can reflect this and still be efficient.

For example, airplane transponders use base 8, and colours are often represented in base 16. It is immediately obvious to an aviation expert that 8b7500 refers to a hijacking, while 3904 not so much. And a designer will know that 16bFFFF00 is yellow, but not so with 11858400000.

Answer 3

The other answers so far have exclusively focused on advantages. There are two disadvantages I can think of, though neither is really a strong enough reason to exclude this feature from a language.

The first disadvantage is particular to the C-style syntax for octal numbers, that is that integer literals beginning with a 0 are treated as octal (base 8). So for example, 012 is not equal to 12. This can be confusing and lead to mistakes; there are some real-world contexts in which it is normal to write decimal numbers with leading zeroes, particularly where this allows numbers to have a fixed number of digits and be sorted lexicographically.

The second disadvantage is that it adds a complication to the standard library's functions for parsing strings as numbers. Particularly, if there is more than one syntax for a number literal in the language, then the user also needs to think about whether or not those different syntaxes are handled by the parse function. In the worst case, the parse function handles other syntaxes and the user may not even be aware that those other syntaxes exist, causing incorrect results when the input string happens to match one of the other syntaxes.

An example is the parseInt function in older versions of Javascript, where parseInt('08') was equal to 0, not 8, because this string is in octal notation ─ but the string is likely to come from an end-user who has no idea what octal is, and who thinks 08 is a perfectly sensible way of writing the number 8. Empirically, this tripped up quite a few people, based on the number of votes and duplicates of this Stack Overflow question.

Answer 4

Runtime safety

With syntax like 0x1A50 instead of parseInt("1A50",16) you can make sure at compile time that 1A50 is a valid hexadecimal.

Sort of a non-issue since you'd expect a programmer to write correct constants into his code, but I did have a classmate who once wrote something like parseInt("J1424", 16) into his code for some test and was then confused that it threw an exception. Having it fail to compile would probably have made the issue far more apparent.

Answer 5

Another advantage is in Code Golf (Where many early users of this site came from), in which you try to make the shortest code possible to complete a task. Representing numbers in a higher base can help save a few bytes. I would personally recommend adding a base 256 builtin (Note: base 255 might be better), as each byte can have 256 possible states. This way, you would utilize the byte to its full potential.

Answer 6

A lot of historical or external constants

Modern languages add this feature because it makes the code a lot cleaner when re-implementing old code or when implementing industry standards.

Think in all the error this functionality avoids, because constants then can be copied instead of the meatbag moist computers doing moist conversions at source code typing.

Also, it's a very easy feature to do, comparable to other language syntax, as any identifier starting with 0 to 9 is already reserved to numbers, so a prefix in the form 0x 0o 0b is a number anyways.

Internal _ number separators help, and type suffixes (like u8) sweetens the deal, as it eliminates a lot of casting.

For an direct example of this, NaNs does not compare with anything, but is encoded with very definitive bit patterns:

def isnan(num f32)
{
    var mask = 0b_0111_1111_1000_0000_0000_0000_0000_0000;
    return num & mask == mask;
}

Answer 7

There are sometimes situations where you want to determine 100% what a constant means. For example, someone implements the sine function, and ends up with a polynomial whose coefficients need to be known precisely. Say there is a coefficient 1.0 / 6.0 and you write it as 0.1666666666666666667. It's now up to the quality of the compiler which number you actually get. There is no floating point number exactly equal to this constant, so it's rounded up or down. And different compilers could round it in different ways. Now if you want a very precise implementation, then further constants along the line will take into account that this first constant wasn't 1/6 but a tiny bit more or a tiny bit less. So the total error in the polynomial can be kept a lot lower than 1 unit of the last floating-point bit.

So you want a notation where you can write down the exact constant that you expect. In C and C++ you use hexadecimal floating point numbers for this purpose.

Answer 8

A numeric value may actually be more kind of the structure, a binary concatenation of something that can be envisioned as fields. Depending on the base of representation, the fields could be easily visible in the written number (that is obviously more readable) or fused together so that computations are needed to extract them. In the binary system, a group of bits of any length can be visually partitioned out. Hexadecimal system allows to see the bit groups taking a multiply of 4 bits (8, 12, 16) while octal systems naturally partitions to multiplies of 3 bits (3, 6, 9). Decimal system does not naturally separate any bit groups.

For instance, a RGB colour contains 3 bytes representing red, green and blue. These components can be visually seen separately if representing the colour in hexadecimal numeric system but not in decimal. IP address can be written as a single long integer, but it represents 4 meaningful groups 8 bits each, so 01010102 (1.1.1.2) in hex makes much more sense than 16843010 in decimal.

C++ has some support for accessing bit fields of variable width within the structures that allows to partition say 5 bit groups not easily seen in hexadecimal, or single bit groups that only binary form properly reveals. But many other languages do not have this feature and even n C++ this may be an overkill when groups are well visible in hexadecimal format as well.

Answer 9

This is not exactly an answer to the "advantages/disadvantages" question, but the way Forth does it is interesting. It supports arbitrary number bases from 2 to 36, but without needing special syntax to do so. Rather, the interpreter parses and converts numbers according to the current value of the variable BASE, which can be changed dynamically by the user's code. So the numerical value pushed by a token like 17 may be different in different parts of the code, if the value of BASE has been modified in between.

This can make things very confusing if you forget the current value of BASE, because then you have trouble resetting it. For example, at first glance you might think 10 BASE ! (the Forth equivalent of BASE = 10) would bring you back to decimal, but on further thought, you will realize that 10 BASE ! is always a no-op. You also can't easily inquire about the current base, because BASE is also used by . to format numbers for output, and so BASE @ . will likewise always print 10.

So the standard word DECIMAL is predefined, to set BASE back to ten. (And : DECIMAL 10 BASE ! ; is a valid implementation, assuming BASE is ten when compiling it, because the 10 is parsed at compile time.) HEX is also available as a standard extension, and then of course you can define more if you like.

Examples:

DECIMAL
17        ( pushes seventeen )
8 BASE !  ( set octal )
17        ( pushes fifteen ) 
DECIMAL 36 BASE !  ( set base thirty-six )
HI        ( pushes six hundred and thirty )
DECIMAL
: DUODECIMAL 12 BASE ! ;  ( define a word for base twelve )

Note that Forth has no syntax to distinguish a number from a word. Rather, each token that's encountered is looked up in the dictionary of currently defined words. If it's not found, then the interpreter attempts to parse the token as a number (using BASE). So if you had previously done : HI ." Hello world" ;, then after 36 BASE !, doing HI will print Hello world rather than pushing six hundred and thirty. (I don't know if there is a way in standard Forth to force a token in the input stream to be interpreted as a number, even if it's already defined as a word.)

This also means that you can define words for tokens that otherwise appear to be numbers. You can make use of this by doing things like 0 CONSTANT 0, which defines 0 as a word that, when executed, pushes the value 0 on the stack. The advantage is that now when the token 0 is encountered, it's handled by looking up 0 in the dictionary and executing it directly, instead of having to call the number parsing routine.

You can also use it for evil, e.g. prank your friends by doing 47 CONSTANT 2, after which 2 will push the value forty-seven, or : 1 ." It's the loneliest number" ;.

Answer 10

One common limitation with representing numbers in power-of-two bases is that there is no means of indicating whether all bits to the left of the leftmost represented bit should have the same value as that bit. If e.g. one knows that the bottom 8 bits of an object will all be set, and one wants to set them to 0xEA, one could write foo &= 0xFFFFFFEA if one knew that foo was 32 bits, or one could write foo &= -0x16 without having to know the length of foo, but the first form could break if the length of foo changes and the intention of the code would be to disturb the bottom 8 bits, and the latter code would make it harder to discern the intended value. Attempts to allow programmers to specify values which should be "one"-filled on the left, such as those made by some Microsoft BASIC dialects, are prone to have surprising behaviors. For example, in some Microsoft BASIC dialects, VAL("&h00010000") would yield 65536, but VAL("&h0000FFFF")` would yield -1.