Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #66708 > unrolled thread

Radix constant notation would eat binary for Elevensies.

Started byluser droog <luser.droog@gmail.com>
First post2015-08-02 10:28 -0700
Last post2015-08-02 17:04 -0700
Articles 6 — 4 participants

Back to article view | Back to comp.lang.c


Contents

  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

#66708 — Radix constant notation would eat binary for Elevensies.

Fromluser droog <luser.droog@gmail.com>
Date2015-08-02 10:28 -0700
SubjectRadix 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]


#66710

Fromluser droog <luser.droog@gmail.com>
Date2015-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]


#66714

FromBartc <bc@freeuk.com>
Date2015-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]


#66727

FromRobert Wessel <robertwessel2@yahoo.com>
Date2015-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]


#66740

Fromluser droog <luser.droog@gmail.com>
Date2015-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]


#66760

FromKeith Thompson <kst-u@mib.org>
Date2015-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