<p>(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).</p>
<p>Numbers can be in different <a href="https://en.wikipedia.org/wiki/Radix" rel="noreferrer">bases</a>. For example, we typically use base ten. But, there are many others. As one example, the digits <code>10</code> in binary represent the same number as the digit <code>2</code> in decimal. For another example, the digits <code>FF</code> in hexadecimal represent the same number as <code>255</code> in decimal.</p>
<p>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.</p>
<p>What are the benefits to having some type of syntax like <code>0b10 == 2</code> vs <code>baseSomethingToInt(2, &quot;10&quot;) == 2</code>?</p>
<p>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?</p>

<syntax><numbers><integers>
What are some advantages/disadvantages of having built-in syntax to represent numbers in non-decimal bases?
CC BY-SA 4.0
2023-06-13T12:06:57.417Z
I'm personally really frustrated that almost no languages allow floats in different bases, especially since base 2 floats can actually be stored so give accurate answers after most basic operation.
mousetail 'he-him'
CC BY-SA 4.0
2023-06-14T10:03:14.340Z
just imagine doing something like this in a language like Verilog. An average code will easily blow up 2-3 times bigger and utterly unreadable.
SK-logic
CC BY-SA 4.0
2023-06-29T16:30:00.333Z
@JörgWMittag The question has been significantly clarified since I made that comment, it originally read more like "what are the pros and cons of allowing numbers to be _stored_ in different bases". Sorry for any confusion.
rydwolf
CC BY-SA 4.0
2023-07-19T15:25:00.553Z
There's a middle ground, where the language is sufficiently extensible that such representations can be added by user code (or libraries).
Toby Speight
CC BY-SA 4.0
2023-07-26T15:37:23.960Z
@RydwolfPrograms There is an IEEE standard for decimal floating-point which is to some degree base 1000 based. But nobody stores small decimal integers, decimal is just used for input and output of integers.
gnasher729
CC BY-SA 4.0
2023-07-26T20:03:09.540Z
Do you mean just power-of-two bases like octal or hexadecimal, or other bases (ternary, dozenal, etc.) as well?
dan04
CC BY-SA 4.0
2023-05-17T02:28:42.300Z
Why would you want to do this? All numbers on a computer are typically stored in base-2 in one way or another (sometimes in bigger blocks, e.g., base-256 for bigints, which is just 8 base-2 digits together per digit). Actually storing numbers in decimal hasn't been a thing since the 20th century (https://en.wikipedia.org/wiki/Binary-coded_decimal)
rydwolf
CC BY-SA 4.0
2023-11-10T23:05:46.987Z
The main advantage is to make it easy to write code that is easier to read by having constants appear in a "natural" form for how they are used.
Chris Dodd
<p>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.</p>
<p>The first disadvantage is particular to the C-style syntax for octal numbers, that is that integer literals beginning with a <code>0</code> are treated as octal (base 8). So for example, <code>012</code> is not equal to <code>12</code>. 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.</p>
<p>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.</p>
<p>An example is the <code>parseInt</code> function in older versions of Javascript, where <code>parseInt('08')</code> 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 <code>08</code> 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 <a href="https://stackoverflow.com/q/850341/12299000">this Stack Overflow question</a>.</p>

CC BY-SA 4.0
2023-07-27T16:42:15.370Z
2023-07-27T20:18:20.977Z
2023-07-27T20:18:20.977Z
kaya3
CC BY-SA 4.0
2023-07-27T20:47:18.933Z
This is exactly why Python 3 moved to a `0o` prefix for octal.
Karl Knechtel
CC BY-SA 4.0
2023-11-10T18:38:53.677Z
In most cases where code would want to perform string-to-number conversions, the code will know exactly what format of number is expected, and input in any format would be erroneous.  The leading zero in Javascript I find a particularly galling choice.  Allowing octal numbers to be represented via syntax like `0q123` or `0o123` or `8x123` would be useful, but allowing the specific syntax `0123` for octal notation is far less useful than allowing and ignoring leading zeroes for general numeric input.
supercat
CC BY-SA 4.0
2023-11-13T15:45:09.130Z
I don't understand why `parseInt` is mentioned, when it's got nothing to do with language syntax.
Matthieu M.
CC BY-SA 4.0
2023-11-13T18:30:24.540Z
@MatthieuM. Because as mentioned in the answer, Javascript's `parseInt` function *used* to parse any valid Javascript integer literal. This demonstrates that the programmer has an extra thing to think about when calling a standard library function to parse an integer, as explained in the previous paragraph.
kaya3
CC BY-SA 4.0
2023-11-13T21:47:56.990Z
@MatthieuM. The question isn't clear about whether it's talking about literals in the source code or parsing numbers from user input or text files.
Barmar
CC BY-SA 4.0
2023-11-13T23:19:08.380Z
@Barmar I think the question is definitely about literals, the point I'm making (in the second paragraph of my answer) is that if the language supports non-decimal integer literals, then the programmer has to worry about whether the "parse integer" function supports those syntaxes too. As I said in the answer, it's not a significant enough concern that languages shouldn't support non-decimal literals, it's just an implication.
kaya3
CC BY-SA 4.0
2023-11-20T17:27:39.080Z
@kaya3: I can't think of any languages which have an "evaluate arbitrary expression in string" function as the only means of performing string-to-number conversions.  I'd expect any other kind of convert-number-to-string function to process only the specific numeric formats described in its documentation, regardless of what other constructs the language might otherwise support.
supercat
CC BY-SA 4.0
2023-11-20T18:00:52.587Z
@supercat I didn't say anything about evaluating arbitrary expressions in strings, and `parseInt` in Javascript doesn't do that and never did. What it did do, was accept strings in the format of valid Javascript integer literals, including hex and octal numbers, and parse them as if they were literals. If Javascript didn't have hex and octal literals at the source level, then there is no chance `parseInt` would have been designed to accept them.
kaya3
<p>In a domain where a specific base is used, it is clearer if the code can reflect this and still be efficient.</p>
<p>For example, airplane transponders use base 8, and colours are often represented in base 16. It is immediately  obvious to an aviation expert that <code>8b7500</code> refers to a hijacking, while <code>3904</code> not so much. And a designer will know that  <code>16bFFFF00</code> is yellow, but not so with <code>11858400000</code>.</p>

CC BY-SA 4.0
2023-05-17T04:31:16.957Z
2023-05-17T04:31:16.957Z
Adám
<h2>Runtime safety</h2>
<p>With syntax like <code>0x1A50</code> instead of <code>parseInt(&quot;1A50&quot;,16)</code> you can make sure at compile time that <code>1A50</code> is a valid hexadecimal.</p>
<p>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 <code>parseInt(&quot;J1424&quot;, 16)</code> 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.</p>

CC BY-SA 4.0
2023-06-13T18:36:51.957Z
2023-06-13T18:36:51.957Z
kouta-kun
CC BY-SA 4.0
2023-09-09T20:52:43.873Z
And executing `parseInt("1A50",16)` at runtime is also much more bloated and less efficient.
CPlus
CC BY-SA 4.0
2023-09-10T13:43:33.210Z
@user16217248 An optimizing compiler with knowledge of the function could do that at compile time but yeah, that's also a concern
kouta-kun
<p>Another advantage is in <a href="https://codegolf.stackexchange.com">Code Golf</a> (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.</p>

CC BY-SA 4.0
2023-05-17T10:51:58.693Z
2023-11-10T18:55:26.357Z
2023-11-10T18:55:26.357Z
The Empty String Photographer
CC BY-SA 4.0
2023-11-10T18:55:15.307Z
@TobySpeight That was written in May, the very early days of the site, when a large proportion of the users here were from Code Golf. It's no longer true, of course.
kaya3
CC BY-SA 4.0
2023-11-13T21:49:29.273Z
What are the digits in base 256? Do we need to extend to Hebrew, Arabic, and Cyrillic letters?
Barmar
CC BY-SA 4.0
2023-11-14T07:24:34.257Z
@Barmar U+0000 to U+0255
The Empty String Photographer
CC BY-SA 4.0
2023-11-14T16:24:03.497Z
33 of those are control characters (34 if you include space), not very practical to use them as token constituents. But I guess practicality is not a big consideration in CG.
Barmar
CC BY-SA 4.0
2023-11-14T16:32:03.870Z
@Barmar Some languages, like Vyxal, use an SBCS that doesn’t contain those control characters. This could be a potential solution.
The Empty String Photographer
CC BY-SA 4.0
2023-07-19T15:25:56.067Z
"_Where most users of this site come from_" - citation needed.
Toby Speight
CC BY-SA 4.0
2023-07-27T20:45:27.177Z
"I would personally recommend adding a base 256 builtin, as each byte can have 256 possible states" - this is a highly impractical proposition. It would require quoting and quote-escaping mechanisms and introduce parsing complexity. The best you could do, I think, is some single-character prefix for byte-sequence literals. A [base85](https://en.wikipedia.org/wiki/Ascii85) type scheme should be workable, however.
Karl Knechtel
CC BY-SA 4.0
2023-07-28T07:32:17.670Z
@KarlKnechtel fixed?
The Empty String Photographer
<h2>A lot of historical or external constants</h2>
<p>Modern languages add this feature because it makes the code a lot cleaner when re-implementing old code or when implementing industry standards.</p>
<p>Think in <em>all</em> the error this functionality avoids, because constants then can be copied instead of the <strike>meatbag</strike> moist computers doing moist conversions at source code typing.</p>
<p>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 <code>0x</code> <code>0o</code> <code>0b</code> is a number anyways.</p>
<p>Internal <code>_</code> number separators help, and type suffixes (like <code>u8</code>) sweetens the deal, as it eliminates a lot of casting.</p>
<p>For an direct example of this, <code>NaN</code>s does not compare with anything, but is <a href="https://en.wikipedia.org/wiki/NaN#Floating_point" rel="nofollow noreferrer">encoded</a> with very definitive bit patterns:</p>
<pre class="lang-python prettyprint-override"><code>def isnan(num f32)
{
    var mask = 0b_0111_1111_1000_0000_0000_0000_0000_0000;
    return num &amp; mask == mask;
}
</code></pre>

CC BY-SA 4.0
2023-07-18T21:33:41.443Z
2023-11-13T19:59:41.620Z
2023-11-13T19:59:41.620Z
André L F S Bacci
<p>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 <em>very</em> 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.</p>
<p>So you want a notation where you can write down the <em>exact</em> constant that you expect. In C and C++ you use hexadecimal floating point numbers for this purpose.</p>

CC BY-SA 4.0
2023-07-25T15:51:51.577Z
2023-07-25T15:51:51.577Z
gnasher729
<p>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 <code>foo &amp;= 0xFFFFFFEA</code> if one knew that <code>foo</code> was 32 bits, or one could write <code>foo &amp;= -0x16 </code> without having to know the length of <code>foo</code>, but the first form could break if the length of <code>foo</code> 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 &quot;one&quot;-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, <code>VAL(&quot;&amp;h00010000&quot;)</code> would yield 65536, but VAL(&quot;&amp;h0000FFFF&quot;)<span class="math-container">`</span> would yield -1.</p>

CC BY-SA 4.0
2023-11-20T20:31:04.770Z
2023-11-20T20:31:04.770Z
supercat
<p>A numeric value may actually be more kind of the structure, a binary concatenation of something that can be envisioned as <strong>fields</strong>. 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.</p>
<p>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.</p>
<p>C++ has some support for accessing <a href="https://en.cppreference.com/w/c/language/bit_field" rel="nofollow noreferrer">bit fields</a> 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.</p>

CC BY-SA 4.0
2023-11-14T18:32:32.157Z
2023-11-14T18:42:07.687Z
2023-11-14T18:42:07.687Z
Audrius Meškauskas
<p>This is not exactly an answer to the &quot;advantages/disadvantages&quot; question, but the way <strong>Forth</strong> 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 <code>BASE</code>, which can be changed <em>dynamically</em> by the user's code.  So the numerical value pushed by a token like <code>17</code> may be different in different parts of the code, if the value of <code>BASE</code> has been modified in between.</p>
<p>This can make things very confusing if you forget the current value of <code>BASE</code>, because then you have trouble resetting it.  For example, at first glance you might think <code>10 BASE !</code> (the Forth equivalent of <code>BASE = 10</code>) would bring you back to decimal, but on further thought, you will realize that <code>10 BASE !</code> is always a no-op.  You also can't easily inquire about the current base, because <code>BASE</code> is also used by <code>.</code> to format numbers for output, and so <code>BASE @ .</code> will likewise always print <code>10</code>.</p>
<p>So the standard word <code>DECIMAL</code> is predefined, to set <code>BASE</code> back to ten.  (And <code>: DECIMAL 10 BASE ! ;</code> is a valid implementation, assuming <code>BASE</code> is ten when compiling it, because the <code>10</code> is parsed at compile time.)  <code>HEX</code> is also available as a standard extension, and then of course you can define more if you like.</p>
<p>Examples:</p>
<pre><code>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 )
</code></pre>
<p>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 <code>BASE</code>).  So if you had previously done <code>: HI .&quot; Hello world&quot; ;</code>, then after <code>36 BASE !</code>, doing <code>HI</code> will print <code>Hello world</code> 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.)</p>
<p>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 <code>0 CONSTANT 0</code>, which defines 0 as a word that, when executed, pushes the value 0 on the stack.  The advantage is that now when the token <code>0</code> is encountered, it's handled by looking up <code>0</code> in the dictionary and executing it directly, instead of having to call the number parsing routine.</p>
<p>You can also use it for evil, e.g. prank your friends by doing <code>47 CONSTANT 2</code>, after which <code>2</code> will push the value forty-seven, or <code>: 1 .&quot; It's the loneliest number&quot; ;</code>.</p>

CC BY-SA 4.0
2023-11-16T16:47:14.460Z
2023-11-16T16:47:14.460Z
Nate Eldredge
CC BY-SA 4.0
2023-11-20T04:53:52.750Z
This seems like a new twist on the old (Chinese?) curse: _may you live in interesting times_. I've used languages that are "interesting" like that, and while they're great for short one-off stuff, they get really painful when trying to write large-scale maintainable code. I prefer to live - and code - in "less interesting" times.
Martin Kealey
<p>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:</p>
<pre><code>uint64_t bswap(const uint64_t n) {
    return (n&amp;0xFF00FF00FF00FF)&lt;&lt;8|(n&amp;0xFF00FF00FF00FF00)&gt;&gt;8;
}
</code></pre>
<p>In decimal this is not clear as these numbers seem arbitrary and meaningless:</p>
<pre><code>uint64_t bswap(const uint64_t n) {
    return (n&amp;71777214294589695)&lt;&lt;8|(n&amp;18374966859414961920)&gt;&gt;8;
}
</code></pre>

CC BY-SA 4.0
2023-05-17T02:48:39.963Z
2023-05-17T02:48:39.963Z
CPlus
# What are some advantages/disadvantages of having built-in syntax to represent numbers in non-decimal bases?
Posted by: username_0 on 2023-05-17
(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](https://en.wikipedia.org/wiki/Radix). 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?
**Tags:** syntax numbers integers
> **Comments:**
> **username_3**: Why would you want to do this? All numbers on a computer are typically stored in base-2 in one way or another (sometimes in bigger blocks, e.g., base-256 for bigints, which is just 8 base-2 digits together per digit). Actually storing numbers in decimal hasn't been a thing since the 20th century (https://en.wikipedia.org/wiki/Binary-coded_decimal)  
> **username_1**: I'm personally really frustrated that almost no languages allow floats in different bases, especially since base 2 floats can actually be stored so give accurate answers after most basic operation.  
> **username_2**: just imagine doing something like this in a language like Verilog. An average code will easily blow up 2-3 times bigger and utterly unreadable.  
> **username_3**: @JörgWMittag The question has been significantly clarified since I made that comment, it originally read more like "what are the pros and cons of allowing numbers to be _stored_ in different bases". Sorry for any confusion.  
> **username_4**: There's a middle ground, where the language is sufficiently extensible that such representations can be added by user code (or libraries).  
> **username_5**: @RydwolfPrograms There is an IEEE standard for decimal floating-point which is to some degree base 1000 based. But nobody stores small decimal integers, decimal is just used for input and output of integers.  
> **username_6**: Do you mean just power-of-two bases like octal or hexadecimal, or other bases (ternary, dozenal, etc.) as well?  
> **username_7**: The main advantage is to make it easy to write code that is easier to read by having constants appear in a "natural" form for how they are used.  
---
## 10 answers
### Answer by username_15 on 2023-05-17. Score: 29 | Accepted answer
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 by username_13 on 2023-05-17. Score: 19
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 by username_8 on 2023-07-27. Score: 9
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](https://stackoverflow.com/q/850341/12299000).
> **Comments:**
> **username_9** (2023-07-27): This is exactly why Python 3 moved to a `0o` prefix for octal.  
> **username_10** (2023-11-10): In most cases where code would want to perform string-to-number conversions, the code will know exactly what format of number is expected, and input in any format would be erroneous.  The leading zero in Javascript I find a particularly galling choice.  Allowing octal numbers to be represented via syntax like `0q123` or `0o123` or `8x123` would be useful, but allowing the specific syntax `0123` for octal notation is far less useful than allowing and ignoring leading zeroes for general numeric input.  
> **username_11** (2023-11-13): I don't understand why `parseInt` is mentioned, when it's got nothing to do with language syntax.  
> **username_8** (2023-11-13): @MatthieuM. Because as mentioned in the answer, Javascript's `parseInt` function *used* to parse any valid Javascript integer literal. This demonstrates that the programmer has an extra thing to think about when calling a standard library function to parse an integer, as explained in the previous paragraph.  
> **username_12** (2023-11-13): @MatthieuM. The question isn't clear about whether it's talking about literals in the source code or parsing numbers from user input or text files.  
> **username_8** (2023-11-13): @Barmar I think the question is definitely about literals, the point I'm making (in the second paragraph of my answer) is that if the language supports non-decimal integer literals, then the programmer has to worry about whether the "parse integer" function supports those syntaxes too. As I said in the answer, it's not a significant enough concern that languages shouldn't support non-decimal literals, it's just an implication.  
> **username_10** (2023-11-20): @kaya3: I can't think of any languages which have an "evaluate arbitrary expression in string" function as the only means of performing string-to-number conversions.  I'd expect any other kind of convert-number-to-string function to process only the specific numeric formats described in its documentation, regardless of what other constructs the language might otherwise support.  
> **username_8** (2023-11-20): @supercat I didn't say anything about evaluating arbitrary expressions in strings, and `parseInt` in Javascript doesn't do that and never did. What it did do, was accept strings in the format of valid Javascript integer literals, including hex and octal numbers, and parse them as if they were literals. If Javascript didn't have hex and octal literals at the source level, then there is no chance `parseInt` would have been designed to accept them.  
---
### Answer by username_14 on 2023-06-13. Score: 7
## 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.
> **Comments:**
> **username_15** (2023-09-09): And executing `parseInt("1A50",16)` at runtime is also much more bloated and less efficient.  
> **username_14** (2023-09-10): @user16217248 An optimizing compiler with knowledge of the function could do that at compile time but yeah, that's also a concern  
---
### Answer by username_16 on 2023-05-17. Score: 4
Another advantage is in [Code Golf](https://codegolf.stackexchange.com) (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.
> **Comments:**
> **username_4** (2023-07-19): "_Where most users of this site come from_" - citation needed.  
> **username_9** (2023-07-27): "I would personally recommend adding a base 256 builtin, as each byte can have 256 possible states" - this is a highly impractical proposition. It would require quoting and quote-escaping mechanisms and introduce parsing complexity. The best you could do, I think, is some single-character prefix for byte-sequence literals. A [base85](https://en.wikipedia.org/wiki/Ascii85) type scheme should be workable, however.  
> **username_16** (2023-07-28): @KarlKnechtel fixed?  
> **username_8** (2023-11-10): @TobySpeight That was written in May, the very early days of the site, when a large proportion of the users here were from Code Golf. It's no longer true, of course.  
> **username_12** (2023-11-13): What are the digits in base 256? Do we need to extend to Hebrew, Arabic, and Cyrillic letters?  
> **username_16** (2023-11-14): @Barmar U+0000 to U+0255  
> **username_12** (2023-11-14): 33 of those are control characters (34 if you include space), not very practical to use them as token constituents. But I guess practicality is not a big consideration in CG.  
> **username_16** (2023-11-14): @Barmar Some languages, like Vyxal, use an SBCS that doesn’t contain those control characters. This could be a potential solution.  
---
### Answer by username_17 on 2023-07-18. Score: 3
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 by username_5 on 2023-07-25. Score: 2
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 by username_10 on 2023-11-20. Score: 0
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.
---
### Answer by username_18 on 2023-11-14. Score: 0
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](https://en.cppreference.com/w/c/language/bit_field) 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 by username_19 on 2023-11-16. Score: 0
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" ;.
> **Comments:**
> **username_20** (2023-11-20): This seems like a new twist on the old (Chinese?) curse: _may you live in interesting times_. I've used languages that are "interesting" like that, and while they're great for short one-off stuff, they get really painful when trying to write large-scale maintainable code. I prefer to live - and code - in "less interesting" times.  
---
