Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #66708 > unrolled thread
| Started by | luser droog <luser.droog@gmail.com> |
|---|---|
| First post | 2015-08-02 10:28 -0700 |
| Last post | 2015-08-02 17:04 -0700 |
| Articles | 6 — 4 participants |
Back to article view | Back to comp.lang.c
Radix constant notation would eat binary for Elevensies. luser droog <luser.droog@gmail.com> - 2015-08-02 10:28 -0700
Re: Radix constant notation would eat binary for Elevensies. luser droog <luser.droog@gmail.com> - 2015-08-02 10:39 -0700
Re: Radix constant notation would eat binary for Elevensies. Bartc <bc@freeuk.com> - 2015-08-02 18:56 +0100
Re: Radix constant notation would eat binary for Elevensies. Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 14:14 -0500
Re: Radix constant notation would eat binary for Elevensies. luser droog <luser.droog@gmail.com> - 2015-08-02 13:28 -0700
Re: Radix constant notation would eat binary for Elevensies. Keith Thompson <kst-u@mib.org> - 2015-08-02 17:04 -0700
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2015-08-02 10:28 -0700 |
| Subject | Radix constant notation would eat binary for Elevensies. |
| Message-ID | <3bc451b6-8f98-4e20-ae6f-d28340c41509@googlegroups.com> |
I've been following the drifted topic of binary constants in the thread 'SQL filsortcc question'. But my idea is better. Existing syntax for hexadecimal constants: 0xabcdefg0 0XABCDEFG0 Suggested extension to binary constants: 0b101010101 0B101010101 But what about? 2x101010101 2X101010101 Thus, 0 becomes a shorthand for 16, and the same mechanism naturally extends up to 36 by including the remainder of the Latin alphabet. The capitalization of 'x' retains the same significance in selecting the case of the representation whereas: `0B` ??? -- aah. lovely lovely laurels so soft so sleepy
[toc] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2015-08-02 10:39 -0700 |
| Message-ID | <dd658d7c-6cdc-4f66-9a0d-8e9bf311470a@googlegroups.com> |
| In reply to | #66708 |
On Sunday, August 2, 2015 at 12:29:01 PM UTC-5, luser droog wrote: > But what about? > > 2x101010101 > 2X101010101 > > Thus, 0 becomes a shorthand for 16, and the same mechanism > naturally extends up to 36 by including the remainder of > the Latin alphabet. What about even more extra super magic. Consider the `1x...` notation that now appears, perfect for unary numbers. If you relax the restriction on the input char to be greater than b-1, then you can write Peano constants as 1x11111 for 5, rather than 1x00000 which really looks odd. But the bonus of this relaxation would be the ability to take a compile-time length of an identifier. #define len(z) 1x ## z rather than #define len(z) ((sizeof(#z))-1)
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-02 18:56 +0100 |
| Message-ID | <mpllhj$jia$1@dont-email.me> |
| In reply to | #66708 |
On 02/08/2015 18:28, luser droog wrote:
> I've been following the drifted topic of binary constants
> in the thread 'SQL filsortcc question'. But my idea is better.
>
> Existing syntax for hexadecimal constants:
>
> 0xabcdefg0
> 0XABCDEFG0
>
> Suggested extension to binary constants:
>
> 0b101010101
> 0B101010101
>
> But what about?
>
> 2x101010101
> 2X101010101
>
> Thus, 0 becomes a shorthand for 16, and the same mechanism
> naturally extends up to 36 by including the remainder of
> the Latin alphabet. The capitalization of 'x' retains the
> same significance in selecting the case of the representation
> whereas: `0B` ???
>
Yeah, I do something like that:
println 0x100
println 2x100
println 3x100
println 4x100
println 5x100
println 6x100
println 7x100
println 8x100
println 9x100
When converted to C:
printf("%d\n",256);
printf("%d\n",4);
printf("%d\n",9);
printf("%d\n",16);
printf("%d\n",25);
printf("%d\n",36);
printf("%d\n",49);
printf("%d\n",64);
printf("%d\n",81);
(But apparently I haven't bothered to deal with 2-digit bases 10 to 16!
The should allowed for completeness.) I wouldn't have gone up to 36
either; I think that's less useful.
I think Ada also uses a similar scheme, allowing 2#100# to 16#100#.
I also however allow 0B-prefix as that can be handy when importing data
in C source format (which is why I use 0x-prefix too).
Note that: 1x100 isn't disallowed in my scheme, but '1' would be an
out-of-range digit. (1x0, 1x0000 etc will work, but are rather pointless.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-08-02 14:14 -0500 |
| Message-ID | <9nqsra5enp3381uk7t6emrms04k6vo7en7@4ax.com> |
| In reply to | #66708 |
On Sun, 2 Aug 2015 10:28:43 -0700 (PDT), luser droog <luser.droog@gmail.com> wrote: >I've been following the drifted topic of binary constants >in the thread 'SQL filsortcc question'. But my idea is better. > >Existing syntax for hexadecimal constants: > > 0xabcdefg0 > 0XABCDEFG0 > >Suggested extension to binary constants: > > 0b101010101 > 0B101010101 > >But what about? > > 2x101010101 > 2X101010101 > >Thus, 0 becomes a shorthand for 16, and the same mechanism >naturally extends up to 36 by including the remainder of >the Latin alphabet. The capitalization of 'x' retains the >same significance in selecting the case of the representation >whereas: `0B` ??? Ada, for example, uses the syntax 16#123# where the base is followed by the "quoted" number in that base. They allow 2..16. In Postscript, you use a similar 16# prefix (but the number is not "quoted", so no second #). While the regularity and completeness are appealing, the use of bases other than 2, 8, 10 and 16 is very rare, so the somewhat more ad-hoc solution is not unreasonable (well, except for the octal format). And since we already have 0bxx in C++, and many C compilers as an extension, it's kinda moot.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2015-08-02 13:28 -0700 |
| Message-ID | <4ef2c2f0-4568-411e-b82c-6e9bac82235d@googlegroups.com> |
| In reply to | #66727 |
On Sunday, August 2, 2015 at 2:14:12 PM UTC-5, robert...@yahoo.com wrote: > On Sun, 2 Aug 2015 10:28:43 -0700 (PDT), luser droog > <luser.droog@gmail.com> wrote: > > >I've been following the drifted topic of binary constants > >in the thread 'SQL filsortcc question'. But my idea is better. > > > >Existing syntax for hexadecimal constants: > > > > 0xabcdefg0 > > 0XABCDEFG0 > > > >Suggested extension to binary constants: > > > > 0b101010101 > > 0B101010101 > > > >But what about? > > > > 2x101010101 > > 2X101010101 > > > >Thus, 0 becomes a shorthand for 16, and the same mechanism > >naturally extends up to 36 by including the remainder of > >the Latin alphabet. The capitalization of 'x' retains the > >same significance in selecting the case of the representation > >whereas: `0B` ??? > > > Ada, for example, uses the syntax 16#123# where the base is followed > by the "quoted" number in that base. They allow 2..16. In > Postscript, you use a similar 16# prefix (but the number is not > "quoted", so no second #). > > While the regularity and completeness are appealing, the use of bases > other than 2, 8, 10 and 16 is very rare, so the somewhat more ad-hoc > solution is not unreasonable (well, except for the octal format). And > since we already have 0bxx in C++, and many C compilers as an > extension, it's kinda moot. Understood, but keep this on the "when there's a time-machine" list. I shouldn't need to argue too much in favor of a solution that simplifies as it generalizes. But I wasn't there when it all went down, so it's inappropriate (but still fun) to blame "them" for not heeding my suggestion.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-02 17:04 -0700 |
| Message-ID | <lnbnepi6em.fsf@kst-u.example.com> |
| In reply to | #66708 |
luser droog <luser.droog@gmail.com> writes:
> I've been following the drifted topic of binary constants
> in the thread 'SQL filsortcc question'. But my idea is better.
>
> Existing syntax for hexadecimal constants:
>
> 0xabcdefg0
> 0XABCDEFG0
G??
> Suggested extension to binary constants:
>
> 0b101010101
> 0B101010101
>
> But what about?
>
> 2x101010101
> 2X101010101
>
> Thus, 0 becomes a shorthand for 16, and the same mechanism
> naturally extends up to 36 by including the remainder of
> the Latin alphabet. The capitalization of 'x' retains the
> same significance in selecting the case of the representation
> whereas: `0B` ???
I like it, and if I were designing a new language from scratch I'd be
very tempted to use this notation. 8x123 reads better than 0123. It
has the advantage of better uniformity (with "0x" as a special-case
alias for "16x") and generality (no arbitrary restriction to bases 2, 8,
10, and 16).
Given that the suggested 0b11001001 notation is already supported in C++
and as a gcc extension, I'd still argue in favor of standardizing that
for C. The utility of bases other than 2, 8, 10, and 16 is not IMHO
that much of an advantage.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.c
csiph-web