Re: Annoying octal notation

[NevilleDNZ]

On Sep 3, 2:57 pm, James Harris  wrote:
> On 3 Sep, 14:26, Albert van der Horst 
> wrote:
>
> > In article 
> > <6031ba08-08c8-416b-91db-ce8ff57ae...@w6g2000yqw.googlegroups.com>,
> > James Harris   wrote:
> > 
>
> > >So you are saying that Smalltalk has r where
> > >r is presumably for radix? That's maybe best of all. It preserves the
> > >syntactic requirement of starting a number with a digit and seems to
> > >have greatest flexibility. Not sure how good it looks but it's
> > >certainly not bad.
>
> > >  0xff & 0x0e | 0b1101
> > >  16rff & 16r0e | 2r1101
>
> > >Hmm. Maybe a symbol would be better than a letter.
>
> > Like 0#ff  16#ff ?
>
> Yes, that looks better.
>
> > That is ALGOL68. It is incredible how many of it has become
> > vindicated over time. (Yes, nineteen hundred sixty eight was
> > the year that language was conceived.)
>
> Yes, and its predecessor Algol 60 was a masterful advance in
> programming languages. It set up standards we still use today.
c.f. http://en.wikiquote.org/wiki/C._A._R._Hoare#The_Emperor.27s_Old_Clothes

>
> James

However I don't recall Algol60 having Bin/Oct/Hex numeric
literals.  c.f. http://www.masswerk.at/algol60/report.htm

And I am pretty sure that Algol60 had neither builtin
byte operators (eg xor, shl/shr), nor a builtin ability to
read nor printf oct/hex.  Maybe these were in AlgolW or a
Burroughs/Unisys dialect of Algol60?

(FYI: AlgolW has been reincarnated by Glyn Webster with
his worthy AlgolW to gcc 'C' translator.  To be found at:
http://www.jampan.co.nz/~glyn/)

The lack input/output in Algol60 did mean you could never
shoot yourself in the foot with true Algol60 c.f.:
[http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html]
>* Algol 58/60+ - shoot yourself in the foot with a Civil
>   War-era musket. The musket is aesthetically fascinating,
>   and the wound baffles the adolescent medic in the
>   emergency room.
>* Algol 60 - You spend hours trying to figure out how
>   to fire the gun because it has no provisions for input
>   or output.

On the other hand compare:
>* Algol 68 - You mildly deprocedure the gun, the bullet
>   gets firmly dereferenced, and your foot is strongly
>   coerced to void.

(I do know Algol 68 has the builtin mode "BITS" with
matching literals, casts, operators and input/output, cf:
http://rosettacode.org/wiki/Bitwise_operations#ALGOL_68 )

And in summary of 41 years of language advancement:
>* Python - You shoot yourself in the foot and then brag
>   for hours about how much more elegantly you did it
>   than if you had been using C or (God forbid) Perl.

N joy
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[MRAB]

Albert van der Horst wrote:

In article <6b5ea596-d1e3-483d-ba79-7b139d3c7...@z24g2000yqb.googlegroups.com>,
Bearophile   wrote:

MRAB:


'_': what if in the future we want to allow them in numbers for clarity?

Hettinger says it's hard (= requires too many changes) to do that and
Python programs don't have big integer constants often enough, so
probably that improvement will not see the light.

In the meantime in a Python program of mine I have put a small bug,
writing 100 instead of 1000. Now in Python I write
10*1000*1000, because I try to learn from my bugs. In D I enjoy
writing 10_000_000.


Forth is one of the few language that could accept
10,000,000 easily  (Because numbers or any token is required too be
separated by whitespace). I have added that to my ciforth.
Especially useful doing number theoretic things and large pointers
in a 64 bit language it is pleasant to have a separator like that.
Even 32 bit :   0008,,0050,4CE0

Also:
In Forth you can add interpreting words, so you can add a facility CD :
CD C:/prog/forth
that does a directory change.
If this has been loaded it is natural to use 0CD to
prevent the CD word from kicking in (definitions
trump numbers in Forth.) Before you know it, you're in
the habit of prefixing all hex numbers by 0 if they don't
start with a decimal digit:
   0DEAD 0BEEF

So for me there is nothing natural about "leading zero means
octal".


[snip]
In Modula-2, a hexadecimal literal starts with a digit and ends with
"H", for example: 0FFH. Using a leading zero to indicate a certain
base doesn't seem natural to me either.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[James Harris]

On 3 Sep, 15:54, Albert van der Horst 
wrote:
> In article ,
> Derek Martin   wrote:
>
>
>
>
>
> >--W1uEbMXJ1Mj4g6TI
> >Content-Type: text/plain; charset=iso-8859-1
> >Content-Disposition: inline
>
> >On Mon, Aug 24, 2009 at 05:03:28PM +, Steven D'Aprano wrote:
> >> On Mon, 24 Aug 2009 11:21:46 -0500, Derek Martin wrote:
> >> > since the old syntax is prevalent both within and without the
> >> > Python community, making the change is, was, and always will be a
> >> > bad idea.
>
> >> Octal syntax isn't prevalent *at all*, except in a small number of
> >> niche areas.
>
> >Steven, don't be obtuse.  Where octal is used in programming, the
> >leading zero is prevalent.
>
> That is not the point. Octal is not prevalent. Leading zero's have
> a mathematical sound meaning. The convention is changed because
> every new user to Python will fall once into this trap.
> For a person not familiar with C or the like this will be a
> hair pulling, nail byting, head banging situation.
> A mathematician might even think he is gone mad.
>
> Regarding you, you will probably have noticed by now that it is
> going to change, so you will not pull your hair, byte your nails

The first time you wrote, "byte your nails," I thought you meant it as
a pun. But since you've mentioned it twice

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[James Harris]

On 3 Sep, 15:35, Grant Edwards  wrote:

...

> >>> Obviously I can't speak for Ken Thompson's motivation in creating this
> >>> feature, but I'm pretty sure it wasn't to save typing or space on
> >>> punchcards. Even in 1969, hex was more common than octal, and yet hex
> >>> values are written with 0x. My guess is that he wanted all numbers to
> >>> start with a digit, to simplify parsing, and beyond that, it was just his
> >>> programming style -- why call the copy command `copy` when you could call
> >>> it `cp`? (Thompson was the co-inventor of Unix.)
>
> >>Maybe it was because they were working on minicomputers, not mainframes,
> >>so there was less processing power and storage available.
>
> > Not just any minicomputers: PDP11. Octal notation is friendly with
> > the PDP11 instruction set.
>
> Indeed.  Octal was the way that all of the DEC PDP-11 sw tools
> displayed machine code/data.

True. Octal was default in Macro-11 and what surprises me is that when
I used it it seemed natural to think in octal (or, preferably, hex)
rather than decimal.

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[James Harris]

On 3 Sep, 14:26, Albert van der Horst 
wrote:
> In article <6031ba08-08c8-416b-91db-ce8ff57ae...@w6g2000yqw.googlegroups.com>,
> James Harris   wrote:
> 
>
>
>
> >So you are saying that Smalltalk has r where
> >r is presumably for radix? That's maybe best of all. It preserves the
> >syntactic requirement of starting a number with a digit and seems to
> >have greatest flexibility. Not sure how good it looks but it's
> >certainly not bad.
>
> >  0xff & 0x0e | 0b1101
> >  16rff & 16r0e | 2r1101
>
> >Hmm. Maybe a symbol would be better than a letter.
>
> Like 0#ff  16#ff ?

Yes, that looks better.

> That is ALGOL68. It is incredible how many of it has become
> vindicated over time. (Yes, nineteen hundred sixty eight was
> the year that language was conceived.)

Yes, and its predecessor Algol 60 was a masterful advance in
programming languages. It set up standards we still use today.

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Grant Edwards]

On 2009-09-03, Albert van der Horst  wrote:
> In article ,
> MRAB   wrote:
>>Steven D'Aprano wrote:
>
>>> Obviously I can't speak for Ken Thompson's motivation in creating this
>>> feature, but I'm pretty sure it wasn't to save typing or space on
>>> punchcards. Even in 1969, hex was more common than octal, and yet hex
>>> values are written with 0x. My guess is that he wanted all numbers to
>>> start with a digit, to simplify parsing, and beyond that, it was just his
>>> programming style -- why call the copy command `copy` when you could call
>>> it `cp`? (Thompson was the co-inventor of Unix.)
>>>
>>Maybe it was because they were working on minicomputers, not mainframes,
>>so there was less processing power and storage available.
>
> Not just any minicomputers: PDP11. Octal notation is friendly with
> the PDP11 instruction set.

Indeed.  Octal was the way that all of the DEC PDP-11 sw tools
displayed machine code/data.

-- 
Grant Edwards   grante Yow! My CODE of ETHICS
  at   is vacationing at famed
   visi.comSCHROON LAKE in upstate
   New York!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Albert van der Horst]

In article ,
Derek Martin   wrote:
>
>--W1uEbMXJ1Mj4g6TI
>Content-Type: text/plain; charset=iso-8859-1
>Content-Disposition: inline
>
>On Mon, Aug 24, 2009 at 05:03:28PM +, Steven D'Aprano wrote:
>> On Mon, 24 Aug 2009 11:21:46 -0500, Derek Martin wrote:
>> > since the old syntax is prevalent both within and without the
>> > Python community, making the change is, was, and always will be a
>> > bad idea.
>>
>> Octal syntax isn't prevalent *at all*, except in a small number of
>> niche areas.
>
>Steven, don't be obtuse.  Where octal is used in programming, the
>leading zero is prevalent.

That is not the point. Octal is not prevalent. Leading zero's have
a mathematical sound meaning. The convention is changed because
every new user to Python will fall once into this trap.
For a person not familiar with C or the like this will be a
hair pulling, nail byting, head banging situation.
A mathematician might even think he is gone mad.

Regarding you, you will probably have noticed by now that it is
going to change, so you will not pull your hair, byte your nails
or bang your head. The more so because the new Python interpreter
will warn you with a nice friendly message.
The sacrifice asked from you is small, but all in all it is big win
for humanity at large.

>Derek D. Martin

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
alb...@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Albert van der Horst]

In article <6b5ea596-d1e3-483d-ba79-7b139d3c7...@z24g2000yqb.googlegroups.com>,
Bearophile   wrote:
>MRAB:
>
>>'_': what if in the future we want to allow them in numbers for clarity?
>
>Hettinger says it's hard (= requires too many changes) to do that and
>Python programs don't have big integer constants often enough, so
>probably that improvement will not see the light.
>
>In the meantime in a Python program of mine I have put a small bug,
>writing 100 instead of 1000. Now in Python I write
>10*1000*1000, because I try to learn from my bugs. In D I enjoy
>writing 10_000_000.

Forth is one of the few language that could accept
10,000,000 easily  (Because numbers or any token is required too be
separated by whitespace). I have added that to my ciforth.
Especially useful doing number theoretic things and large pointers
in a 64 bit language it is pleasant to have a separator like that.
Even 32 bit :   0008,,0050,4CE0

Also:
In Forth you can add interpreting words, so you can add a facility CD :
CD C:/prog/forth
that does a directory change.
If this has been loaded it is natural to use 0CD to
prevent the CD word from kicking in (definitions
trump numbers in Forth.) Before you know it, you're in
the habit of prefixing all hex numbers by 0 if they don't
start with a decimal digit:
   0DEAD 0BEEF

So for me there is nothing natural about "leading zero means
octal".

>
>---
>
>Steven D'Aprano:
>
>> In D, at least some people want to follow Python's lead and either drop
>> support for oct literals completely, or require a 0o 
>> prefix:http://d.puremagic.com/issues/show_bug.cgi?id=2656
>
>Yes, people in the D community are trying to improve things, but it's
>a slow and painful process, and often it goes nowhere. There's lot of
>politics.

There is legacy code, of course.

>
>Bye,
>bearophile

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
alb...@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[sjm]

On Aug 21, 2:45 pm, John Nagle  wrote:

>      In 2009, Unisys finally exited the mainframe hardware business, and the
> last of the 36-bit machines, the ClearPath servers, are being phased out.
> That line of machines goes back to the UNIVAC 2200 series, and the UNIVAC
> 1100 series, all the way back to the vacuum-tube UNIVAC 1103 from 1952.
> It's the longest running series of computers in history, and code for all
> those machines used octal heavily.

You're right that the 36-bit machines rely heavily on octal notation.
However, Unisys has not exited the hardware business.

The descendants of the original 36-bit 1100-series machines are now
called Dorado.  Unisys announced new models as recently as May 2009
(see http://unisys.com/unisys/news/detail.jsp?id=1694).

I have the extreme pleasure of supporting a Dorado 180 and writing
Python code on Windows--the best of both worlds!

Cheers,
  Steve J. Martin

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Albert van der Horst]

In article ,
MRAB   wrote:
>Steven D'Aprano wrote:

>> Obviously I can't speak for Ken Thompson's motivation in creating this
>> feature, but I'm pretty sure it wasn't to save typing or space on
>> punchcards. Even in 1969, hex was more common than octal, and yet hex
>> values are written with 0x. My guess is that he wanted all numbers to
>> start with a digit, to simplify parsing, and beyond that, it was just his
>> programming style -- why call the copy command `copy` when you could call
>> it `cp`? (Thompson was the co-inventor of Unix.)
>>
>Maybe it was because they were working on minicomputers, not mainframes,
>so there was less processing power and storage available.

Not just any minicomputers: PDP11. Octal notation is friendly with
the PDP11 instruction set.

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
alb...@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Albert van der Horst]

In article <6031ba08-08c8-416b-91db-ce8ff57ae...@w6g2000yqw.googlegroups.com>,
James Harris   wrote:

>
>So you are saying that Smalltalk has r where
>r is presumably for radix? That's maybe best of all. It preserves the
>syntactic requirement of starting a number with a digit and seems to
>have greatest flexibility. Not sure how good it looks but it's
>certainly not bad.
>
>  0xff & 0x0e | 0b1101
>  16rff & 16r0e | 2r1101
>
>Hmm. Maybe a symbol would be better than a letter.

Like 0#ff  16#ff ?

That is ALGOL68. It is incredible how many of it has become
vindicated over time. (Yes, nineteen hundred sixty eight was
the year that language was conceived.)

>
>James

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
alb...@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Mel]

Mensanator wrote:
[ ... ]
>> If you want your data file to have values entered in hex, or oct, or even
>> unary (1=one, 11=two, 111=three, =four...) you can.
> 
> Unary? I think you'll find that Standard Positional Number
> Systems are not defined for radix 1.

It has to be tweaked.  If the only digit you have is 0 then your numbers 
take the form

0*1 + 0*1**2 + 0*1**3 ...

and every number has an infinitely long representation.  If you cheat and 
take a 1 digit instead then it becomes workable.

Mel.



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Piet van Oostrum]

> Mensanator  (M) wrote:

>M> That's my point. Since the common usage of "binary" is for
>M> Standard Positional Number System of Radix 2, it follows
>M> that "unary" is the common usage for Standard Positional
>M> Number System of Radix 1. That's VERY confusing since such
>M> a system is undefined. Remember, common usage does not
>M> necessarily properly define things. Saying simply "unary"
>M> sounds like you're extending common usage beyond its proper
>M> boundaries.

But the customary meaning of `unary' is the tally system, as a radix
system wouldn't make sense. I don't know when this term came into use
but I have known it for a long time. 
-- 
Piet van Oostrum 
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: p...@vanoostrum.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Steven D'Aprano]

On Thu, 27 Aug 2009 10:49:27 -0700, Mensanator wrote:

> Fine. I'm over it. Point is, I HAVE encountered plenty of people who
> DON'T properly understand it, Marilyn Vos Savant, for example. 

I'm curious -- please explain. Links please?


> You can't
> blame me for thinking you don't understand it either when unary is
> brought up in a discussion of how to interpret insignificant leading
> 0's.

Er, when I show an example of what I'm calling unary, and then later on 
explain in detail and link to a detailed discussion of it, who exactly 
should I blame for your confusion?



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Mensanator]

On Aug 26, 4:59 pm, Piet van Oostrum  wrote:
> > Mensanator  (M) wrote:
> >M> That's my point. Since the common usage of "binary" is for
> >M> Standard Positional Number System of Radix 2, it follows
> >M> that "unary" is the common usage for Standard Positional
> >M> Number System of Radix 1. That's VERY confusing since such
> >M> a system is undefined. Remember, common usage does not
> >M> necessarily properly define things. Saying simply "unary"
> >M> sounds like you're extending common usage beyond its proper
> >M> boundaries.
>
> But the customary meaning of `unary' is the tally system, as a radix
> system wouldn't make sense. I don't know when this term came into use
> but I have known it for a long time.

Ok, I'll accept that and in the same breath say such common usage
is stupid. I, for one, have never heard such usage and would never
use "unary" in the same breath as "decimal, octal, binary" even if
I had.

> --
> Piet van Oostrum 
> URL:http://pietvanoostrum.com[PGP 8DAE142BE17999C4]
> Private email: p...@vanoostrum.org

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Hendrik van Rooyen]

On Monday 24 August 2009 16:14:25 Derek Martin wrote:

> In fact, now that I think of it...
>
> I just looked at some old school papers I had tucked away in a family
> album.  I'm quite sure that in grammar school, I was tought to use a
> date format of 8/9/79, without leading zeros.  I can't prove it, of
> course, but feel fairly sure that the prevalence of leading zeros in
> dates occured only in the mid to late 1980's as computers became more
> prevalent in our society (no doubt because thousands of cobol

I was one of those COBOL programmers, and the time was around the end of the 
sixties, running into the seventies.  And the reason for leading zeroes on 
dates was the punched card, and its handmaiden, the data entry form, with a 
nice little block for every character. 


Does anybody remember key to tape systems other than Mohawk?


> programmers writing business apps needed a way to convert dates as
> strings to numbers that was easy and fit in small memory).
>
> Assuming I'm right about that, then the use of a leading 0 to
> represent octal actually predates the prevalence of using 0 in dates
> by almost two decades. 

Not quite - at the time I started, punch cards and data entry forms were 
already well established practice, and at least on the English machines, (ICL 
1500/1900 series) octal was prevalent, but I don't know when the leading zero 
octal notation started, and where.  I only met it much later in life, and 
learned it through hard won irritation, because it is a stupid convention, 
when viewed dispassionately.

> And while using leading zeros in other 
> contexts is "familiar" to me, I would certainly not consider it
> "common" by any means.  Thus I think it's fair to say that when this
> syntax was selected, it was a rather good choice.

I think you give it credence for far more depth of design thinking than what 
actually happened in those days - some team working on a compiler made a 
decision  (based on gut feel or experience, or precedent, or whim ) and that 
was that - lo! - a standard is born! -- We have always done it this way, here 
at company  x.  And besides, we cannot ask our main guru to spend any of his 
precious time mucking around with trivia - the man may leave us for the 
opposition if we irritate him, and systems people do not grow on trees, you 
know.

- Hendrik

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Grant Edwards]

On 2009-08-28, Neil Hodgson  wrote:
> Steven D'Aprano:
>
>> Obviously I can't speak for Ken Thompson's motivation in creating this 
>> feature, but I'm pretty sure it wasn't to save typing or space on 
>> punchcards.
>
>The original implementation of UNIX was on a PDP-7 which was an
> 18-bit machine. Octal = 3 bits at a a time which evenly divides an
> 18-bit word whereas the 4 bits of hexadecimal do not. Early
> implementations of B were (according to Wikipedia) on the PDP-7, PDP-11
> (a 16-bit machine) and Honeywell 36-bit mainframes.
>
> Octal was widely used on the PDP-11.

The PDP-11's 16-bit instruction word consisted mainly of 3-bit
fields for destiation-mode, destination-register, source-mode,
source-register.  So, it was quite easy for the progammer to
read/write machine code in octal.

-- 
Grant Edwards   grante Yow! I've read SEVEN
  at   MILLION books!!
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Neil Hodgson]

Steven D'Aprano:

> Obviously I can't speak for Ken Thompson's motivation in creating this 
> feature, but I'm pretty sure it wasn't to save typing or space on 
> punchcards.

   The original implementation of UNIX was on a PDP-7 which was an
18-bit machine. Octal = 3 bits at a a time which evenly divides an
18-bit word whereas the 4 bits of hexadecimal do not. Early
implementations of B were (according to Wikipedia) on the PDP-7, PDP-11
(a 16-bit machine) and Honeywell 36-bit mainframes.

   Octal was widely used on the PDP-11. DEC's PDP-11 Assembler defaulted
to octal and didn't even support hexadecimal. The prefixes used in
MACRO-11 for explicit radixes were ^D, ^O, and ^B.
http://computer-refuge.org/bitsavers/pdf/dec/pdp11/rsx11/RSX11M_V2/DEC-11-OIMRA-A-D_MACRO_75.pdf

   Neil
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[MRAB]

Steven D'Aprano wrote:

On Thu, 27 Aug 2009 10:31:04 -0700, Ethan Furman wrote:


Steven D'Aprano wrote:

A mistake is still a mistake even if it shared with others.

Treating its with a lead zero as octal was a design error when it was
first thought up

[snippage]

I have to disagree with you on this one.  The computing world was vastly
different when that design decision was made.  Space was at a premium,
programmers were not touch-typists, every character had to count, and
why in the world would somebody who had to use papertape or punch cards
add a lead zero without a *real* good reason?  I submit that that real
good reason was to specify an octal literal, and not a decimal literal.


Octal with a leading 0 comes from B, which influenced C, which influenced 
many languages. B was designed in 1969, the same year as Pascal, not the 
1950s -- six years *after* Basic, ten years after Lisp and Cobol, eleven 
years after Algol, and thirteen years after Fortran. *None* of these 
other languages use a leading 0 for Octal, and none of them are 
particularly terse.


Obviously I can't speak for Ken Thompson's motivation in creating this 
feature, but I'm pretty sure it wasn't to save typing or space on 
punchcards. Even in 1969, hex was more common than octal, and yet hex 
values are written with 0x. My guess is that he wanted all numbers to 
start with a digit, to simplify parsing, and beyond that, it was just his 
programming style -- why call the copy command `copy` when you could call 
it `cp`? (Thompson was the co-inventor of Unix.)



Maybe it was because they were working on minicomputers, not mainframes,
so there was less processing power and storage available.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Steven D'Aprano]

On Thu, 27 Aug 2009 10:31:04 -0700, Ethan Furman wrote:

> Steven D'Aprano wrote:
>> A mistake is still a mistake even if it shared with others.
>> 
>> Treating its with a lead zero as octal was a design error when it was
>> first thought up
> 
> [snippage]
> 
> I have to disagree with you on this one.  The computing world was vastly
> different when that design decision was made.  Space was at a premium,
> programmers were not touch-typists, every character had to count, and
> why in the world would somebody who had to use papertape or punch cards
> add a lead zero without a *real* good reason?  I submit that that real
> good reason was to specify an octal literal, and not a decimal literal.

Octal with a leading 0 comes from B, which influenced C, which influenced 
many languages. B was designed in 1969, the same year as Pascal, not the 
1950s -- six years *after* Basic, ten years after Lisp and Cobol, eleven 
years after Algol, and thirteen years after Fortran. *None* of these 
other languages use a leading 0 for Octal, and none of them are 
particularly terse.

Obviously I can't speak for Ken Thompson's motivation in creating this 
feature, but I'm pretty sure it wasn't to save typing or space on 
punchcards. Even in 1969, hex was more common than octal, and yet hex 
values are written with 0x. My guess is that he wanted all numbers to 
start with a digit, to simplify parsing, and beyond that, it was just his 
programming style -- why call the copy command `copy` when you could call 
it `cp`? (Thompson was the co-inventor of Unix.)


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Mel]

Steven D'Aprano wrote:

> Leading zeroes in decimal numbers are *very* common in dates and times.

In banking too, according to someone at work today.

Mel.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Mensanator]

On Aug 27, 2:26 pm, Piet van Oostrum  wrote:
> > Mensanator  (M) wrote:
> >M> On Aug 26, 4:59 pm, Piet van Oostrum  wrote:
> >>> > Mensanator  (M) wrote:
> >>> >M> That's my point. Since the common usage of "binary" is for
> >>> >M> Standard Positional Number System of Radix 2, it follows
> >>> >M> that "unary" is the common usage for Standard Positional
> >>> >M> Number System of Radix 1. That's VERY confusing since such
> >>> >M> a system is undefined. Remember, common usage does not
> >>> >M> necessarily properly define things. Saying simply "unary"
> >>> >M> sounds like you're extending common usage beyond its proper
> >>> >M> boundaries.
>
> >>> But the customary meaning of `unary' is the tally system, as a radix
> >>> system wouldn't make sense. I don't know when this term came into use
> >>> but I have known it for a long time.
> >M> Ok, I'll accept that and in the same breath say such common usage
> >M> is stupid. I, for one, have never heard such usage and would never
> >M> use "unary" in the same breath as "decimal, octal, binary" even if
> >M> I had.
>
> As I see it, unary just means that there is one symbol. Binary just
> means that there are two symbols, etc.

Right, and neither word, by itself, gives the full meaning.

>
> With unary, the only sensible numerical interpretation is to count the
> number of occurrences of that symbol, or if you also want to have the
> number 0, the number of occurrences - 1.

Trouble is, nothing's stopping you from making a non-sensible
interpretation.

>
> With binary and higher you can come up with more numerical
> interpretations but the most efficient one is the radix interpretation
> (for different values of `efficient'). I doubt that there are many other
> interpretations that you can call sensible.

But not impossible. You could have a base-3 tally system for ticking
off how many cars on a three lane road pass a given point. And you can
have mixed radix systems (pounds, shillings, pence or degrees, minutes
seconds).

> Therefore we immediately
> think of a radix system when we talk about binary, octal, decimal etc.
> But the word `binary' itself doesn't imply that.

Just as unary doesn't imply that it's an extension of binary made by
simply changing the base because there's more to it than that.
Yet, I constantly run into people who get confused by this. As a
result, I will never use the word "unary" even if it is considered
acceptable. If I'm trying to imply some sort of base-1 system,
I'll explain what I'm talking about and not assume the listener
will fully understand what is meant by "unary".

> --
> Piet van Oostrum 
> URL:http://pietvanoostrum.com[PGP 8DAE142BE17999C4]
> Private email: p...@vanoostrum.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Ethan Furman]

MRAB wrote:

Ethan Furman wrote:


Steven D'Aprano wrote:


A mistake is still a mistake even if it shared with others.

Treating its with a lead zero as octal was a design error when it was 
first thought up 



[snippage]

I have to disagree with you on this one.  The computing world was 
vastly different when that design decision was made.  Space was at a 
premium, programmers were not touch-typists, every character had to 
count, and why in the world would somebody who had to use papertape or 
punch cards add a lead zero without a *real* good reason?  I submit 
that that real good reason was to specify an octal literal, and not a 
decimal literal.


Now many many years have passed, much has changed, and a leading zero 
(like so much else) no longer makes the sense in once did -- 
especially in a very wide-spread and general purpose language like 
Python.  That does not mean it was not a very good decision at the time.



I think that it although it might have been reasonable when C was
invented, it wasn't a good idea when Python was invented.


Very good point.  I was thinking Steven was talking about the earliest 
case, as opposed to the earliest Python case.  My apologies if I 
misunderstood.


~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Piet van Oostrum]

> Mensanator  (M) wrote:

>M> On Aug 26, 4:59 pm, Piet van Oostrum  wrote:
>>> > Mensanator  (M) wrote:
>>> >M> That's my point. Since the common usage of "binary" is for
>>> >M> Standard Positional Number System of Radix 2, it follows
>>> >M> that "unary" is the common usage for Standard Positional
>>> >M> Number System of Radix 1. That's VERY confusing since such
>>> >M> a system is undefined. Remember, common usage does not
>>> >M> necessarily properly define things. Saying simply "unary"
>>> >M> sounds like you're extending common usage beyond its proper
>>> >M> boundaries.
>>> 
>>> But the customary meaning of `unary' is the tally system, as a radix
>>> system wouldn't make sense. I don't know when this term came into use
>>> but I have known it for a long time.

>M> Ok, I'll accept that and in the same breath say such common usage
>M> is stupid. I, for one, have never heard such usage and would never
>M> use "unary" in the same breath as "decimal, octal, binary" even if
>M> I had.

As I see it, unary just means that there is one symbol. Binary just
means that there are two symbols, etc.

With unary, the only sensible numerical interpretation is to count the
number of occurrences of that symbol, or if you also want to have the
number 0, the number of occurrences - 1.

With binary and higher you can come up with more numerical
interpretations but the most efficient one is the radix interpretation
(for different values of `efficient'). I doubt that there are many other
interpretations that you can call sensible. Therefore we immediately
think of a radix system when we talk about binary, octal, decimal etc.
But the word `binary' itself doesn't imply that.
-- 
Piet van Oostrum 
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: p...@vanoostrum.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Ethan Furman]

James Harris wrote:

On 27 Aug, 18:31, Ethan Furman  wrote:



Steven D'Aprano wrote:




A mistake is still a mistake even if it shared with others.



Treating its with a lead zero as octal was a design error when it was
first thought up


[snippage]

I have to disagree with you on this one.  The computing world was vastly
different when that design decision was made.  Space was at a premium,
programmers were not touch-typists, every character had to count, and
why in the world would somebody who had to use papertape or punch cards
add a lead zero without a *real* good reason?  I submit that that real
good reason was to specify an octal literal, and not a decimal literal.



Nice idea. Characters were expensive but not that expensive - even
then. One extra character to make the octal prefix 0t or 0q or
something could have been used. Check out the History heading at

  http://sundry.wikispaces.com/octal-zero-prefix

Note how B migrated away from both BCPL's octal and its hex notation.

  # and #x in BCPL became
  0 and 0x in B

James


Nice link.

I suspect that as much as anything is was abbreviate as much as 
possible.  In unix we have copy as cp, list as ls move as mv, etc, etc.
Different mind-set also when designing for yourself or a small group, 
versus thousands and thousands.


I am in agreement that Python should not have a leading 0 for octal, as 
there are big inconsistencies with how it's treated.  Visually, I would 
have preferred a prefix of 0c, but I understand it should be consistent 
with the string specifier of o.  Oh well, win some, lose some.


~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[James Harris]

On 27 Aug, 18:31, Ethan Furman  wrote:

> Steven D'Aprano wrote:

> > A mistake is still a mistake even if it shared with others.
>
> > Treating its with a lead zero as octal was a design error when it was
> > first thought up
>
> [snippage]
>
> I have to disagree with you on this one.  The computing world was vastly
> different when that design decision was made.  Space was at a premium,
> programmers were not touch-typists, every character had to count, and
> why in the world would somebody who had to use papertape or punch cards
> add a lead zero without a *real* good reason?  I submit that that real
> good reason was to specify an octal literal, and not a decimal literal.

Nice idea. Characters were expensive but not that expensive - even
then. One extra character to make the octal prefix 0t or 0q or
something could have been used. Check out the History heading at

  http://sundry.wikispaces.com/octal-zero-prefix

Note how B migrated away from both BCPL's octal and its hex notation.

  # and #x in BCPL became
  0 and 0x in B

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Mensanator]

On Aug 26, 10:27 pm, Steven D'Aprano  wrote:
> On Wed, 26 Aug 2009 18:53:04 -0700, Erik Max Francis wrote:
> >> In any case, unary is the standard term for what I'm discussing:
>
> >>http://en.wikipedia.org/wiki/Unary_numeral_system



> This really isn't anywhere near as controversial as you guys are making
> it. Words sometimes have meanings different from what you expect from
> reasoning by analogy. Get over it.

Fine. I'm over it. Point is, I HAVE encountered plenty of people
who DON'T properly understand it, Marilyn Vos Savant, for example.
You can't blame me for thinking you don't understand it either
when unary is brought up in a discussion of how to interpret
insignificant leading 0's.

>
> --
> Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[MRAB]

Ethan Furman wrote:

Steven D'Aprano wrote:

A mistake is still a mistake even if it shared with others.

Treating its with a lead zero as octal was a design error when it was 
first thought up 


[snippage]

I have to disagree with you on this one.  The computing world was vastly 
different when that design decision was made.  Space was at a premium, 
programmers were not touch-typists, every character had to count, and 
why in the world would somebody who had to use papertape or punch cards 
add a lead zero without a *real* good reason?  I submit that that real 
good reason was to specify an octal literal, and not a decimal literal.


Now many many years have passed, much has changed, and a leading zero 
(like so much else) no longer makes the sense in once did -- especially 
in a very wide-spread and general purpose language like Python.  That 
does not mean it was not a very good decision at the time.



I think that it although it might have been reasonable when C was
invented, it wasn't a good idea when Python was invented.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Ethan Furman]

Steven D'Aprano wrote:

A mistake is still a mistake even if it shared with others.

Treating its with a lead zero as octal was a design error when it was 
first thought up 


[snippage]

I have to disagree with you on this one.  The computing world was vastly 
different when that design decision was made.  Space was at a premium, 
programmers were not touch-typists, every character had to count, and 
why in the world would somebody who had to use papertape or punch cards 
add a lead zero without a *real* good reason?  I submit that that real 
good reason was to specify an octal literal, and not a decimal literal.


Now many many years have passed, much has changed, and a leading zero 
(like so much else) no longer makes the sense in once did -- especially 
in a very wide-spread and general purpose language like Python.  That 
does not mean it was not a very good decision at the time.


~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Steven D'Aprano]

On Wed, 26 Aug 2009 18:53:04 -0700, Erik Max Francis wrote:

>> In any case, unary is the standard term for what I'm discussing:
>> 
>> http://en.wikipedia.org/wiki/Unary_numeral_system
>> 
>> although Mathworld doesn't seem to know it.
> 
> Psst.  That's a hint.
> 
> Googling for "unary number system" ("unary numeral system" just comes up
> with endless mirrors of Wikipedia) gives Wikipedia as hit #1.  Hit #2 is
>   from the Institute of Druidic Technology, another hint.  The remaining
> hits are pretty much people pontificating in discussion groups just as
> they are in this one.

Perhaps you should FOLLOW THE REFERENCES from the Wikipedia article, 
instead of relying on Google.

http://www.research.att.com/~njas/sequences/A42

which in turn points to primary references:

K. G. Kroeber, Mathematik der Palindrome; p. 348; 2003; ISBN 3 499 
615762; Rowohlt Verlag; Germany 
 D. Olivastro, Ancient Puzzles. Bantam Books, NY, 1993, p. 276. 
 Amarnath Murthy, On the divisors of the unary sequence, Smarandache 
Notions Journal Vol. - 11, 2000. 
 Amarnath Murthy and Charles Ashbacher, Generalized Partitions and Some 
New Ideas on Number Theory and Smarandache Sequences, Hexis, Phoenix; USA 
2005. See Section 2.12.



> Yes, you can define something that works.  But it's not the usual
> mathematical definition of radix, 

It's not a radix. I never said it is a radix. Only you and Mensator are 
confusing it with a radix system, which is *your* problem, not mine.


> so if you want to talk about it you
> have to disclaim that it's not a proper base and that's you're making up
> as you go.  But you can't pretend like it's the "obvious" mathematical
> meaning just because the usual mathematical meaning doesn't apply, which
> is what you seem to be doing.

I explicitly gave an example, showing what I meant by unary, because I 
knew it would be unfamiliar terminology for most people. When my example 
was ignored completely, I explained further, and showed that it's fairly 
standard terminology. It is *uncommon* terminology, since most 
mathematicians don't concern themselves with non-positional number 
representations, which is why Goggle doesn't find many references to it 
apart from Wikipedia and copies of Wikipedia.

David Wheeler also discusses "base 1", and describes it as "cheating a 
bit". It's only cheating if you assume you're working with a positional 
radix system, which tallies aren't.

Here's another example, from American Scientist:

https://www.americanscientist.org/issues/pub/third-base/2

although that site seems to be having problems now and you're best off 
with the Google cache:

http://74.125.153.132/search?q=cache:7hlZ33y4uCAJ:https://
www.americanscientist.org/issues/pub/third-base/2+%22base+1%22
+numbers&cd=18&hl=en&ct=clnk&gl=uk&ie=UTF-8

[quote]
How do you measure the cost of a numeric representation? If you simply 
count digits, then the biggest base will always win; for example, base 
1,000,000 can represent any number between 0 and decimal 999,999 in a 
single digit. The trouble is, that single digit can be any of a million 
different symbols, all of which you must somehow recognize. At the 
opposite pole are unary, or base-1, numbers. The unary representation of 
decimal 1,000,000 needs only one type of symbol, but that symbol is 
repeated a million times. (Unary notation is in a category apart from 
other bases—it's not really a positional number system—but in the present 
context it serves as a useful limiting case.)
[end quote]



This really isn't anywhere near as controversial as you guys are making 
it. Words sometimes have meanings different from what you expect from 
reasoning by analogy. Get over it.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Erik Max Francis]

Steven D'Aprano wrote:

On Wed, 26 Aug 2009 10:58:12 -0700, Mensanator wrote:


But I certainly wouldn't call it "binary", for fear of confusion with
radix-2 binary.

That's my point. Since the common usage of "binary" is for Standard
Positional Number System of Radix 2, it follows that "unary" is the
common usage for Standard Positional Number System of Radix 1.


Er, no, that doesn't follow. There is no such thing as a radix-1 
positional number system -- it just doesn't work.


In any case, unary is the standard term for what I'm discussing:

http://en.wikipedia.org/wiki/Unary_numeral_system

although Mathworld doesn't seem to know it.


Psst.  That's a hint.

Googling for "unary number system" ("unary numeral system" just comes up 
with endless mirrors of Wikipedia) gives Wikipedia as hit #1.  Hit #2 is 
 from the Institute of Druidic Technology, another hint.  The remaining 
hits are pretty much people pontificating in discussion groups just as 
they are in this one.


Yes, you can define something that works.  But it's not the usual 
mathematical definition of radix, so if you want to talk about it you 
have to disclaim that it's not a proper base and that's you're making up 
as you go.  But you can't pretend like it's the "obvious" mathematical 
meaning just because the usual mathematical meaning doesn't apply, which 
is what you seem to be doing.


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
  And I've seen the promised land. I may not get there with you.
   -- Dr. Martin Luther King, Jr.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Steven D'Aprano]

On Thu, 27 Aug 2009 01:34:10 +, Steven D'Aprano wrote:

> On Wed, 26 Aug 2009 10:58:12 -0700, Mensanator wrote:
> 
>>> But I certainly wouldn't call it "binary", for fear of confusion with
>>> radix-2 binary.
>> 
>> That's my point. Since the common usage of "binary" is for Standard
>> Positional Number System of Radix 2, it follows that "unary" is the
>> common usage for Standard Positional Number System of Radix 1.
> 
> Er, no, that doesn't follow. There is no such thing as a radix-1
> positional number system -- it just doesn't work.

Sorry, this is clumsy writing... of course radix-1 positional number 
system is defined, it's just pointless -- it is only capable of 
representing 0 = 00 = 000 =  ...


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Steven D'Aprano]

On Wed, 26 Aug 2009 10:58:12 -0700, Mensanator wrote:

>> But I certainly wouldn't call it "binary", for fear of confusion with
>> radix-2 binary.
> 
> That's my point. Since the common usage of "binary" is for Standard
> Positional Number System of Radix 2, it follows that "unary" is the
> common usage for Standard Positional Number System of Radix 1.

Er, no, that doesn't follow. There is no such thing as a radix-1 
positional number system -- it just doesn't work.

In any case, unary is the standard term for what I'm discussing:

http://en.wikipedia.org/wiki/Unary_numeral_system

although Mathworld doesn't seem to know it.


> That's VERY confusing since such a system is undefined.

Base-1 positional system is defined, it just doesn't work. You would have 
to write a number by the sum of 0*(1**i), which clearly doesn't get you 
very far. Positional unary is only capable of representing zero, and no 
other numbers, which is even less useful than unary, which at least can 
be used for counting positive numbers, addition and subtraction, and even 
has a use in Elias gamma coding.



> Remember, common usage
> does not necessarily properly define things. Saying simply "unary"
> sounds like you're extending common usage beyond its proper boundaries.

You're reasoning by analogy: "binary" means "positional number system 
with radix 2", "decimal" => radix 10, etc, so "unary" => radix 1. That's 
a reasonable heuristic to follow, but it can fail, because even in 
mathematics, names for things don't necessarily follow such patterns 
perfectly. Because the radix 1 positional system can't work and therefore 
doesn't exist, the name "unary" is available, and has been taken to 
describe a number system which counts by tally marks.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Mensanator]

On Aug 26, 9:58 am, Steven D'Aprano  wrote:
> On Tue, 25 Aug 2009 11:45:28 -0700, Mensanator wrote:
> > On Aug 25, 9:14 am, Steven D'Aprano  > cybersource.com.au> wrote:
> >> On Mon, 24 Aug 2009 18:01:38 -0700, Mensanator wrote:
> >> >> If you want your data file to have values entered in hex, or oct, or
> >> >> even unary (1=one, 11=two, 111=three, =four...) you can.
>
> >> > Unary? I think you'll find that Standard Positional Number Systems
> >> > are not defined for radix 1.
>
> >> Of course not. But unary isn't a positional number system. It's a tally
> >> system, like my example above shows. Roman numerals are another tally
> >> system. Like Roman numerals, the disadvantages of unary are that you
> >> can't represent negative numbers, zero, or fractions, and anything but
> >> addition and subtraction is difficult. But if you want to use it,
> >> perhaps out of a sense of sadism towards your users, it's easy:
> [...]
> > But without insignificant leading 0's, I fail to see the relevance of
> > unary to this discussion.
>
> It was just an example of how you can use numeric data in any format, no
> matter how obscure, weird or difficult, you can use it by passing it
> through an appropriate converter. You don't need compiler support for
> user-supplied data, you just write your own function.

Ok, no problem with that.

>
> As for insignificant leading zeroes, such a thing is meaningless in a
> base-1 tally system. Zero is the absence of a tally mark.
>
> > And what would you call a tally system of
> > radix 2? Certainly not binary.
>
> "Radix" isn't the correct term, because radix doesn't apply to tally
> counting systems. I'd accept "base 2", in the sense that the tally is
> based on two different marks.

I thought the two were equivalent, but maybe I'm wrong. Anyway, that's
a minor quibble.

> We do something similar when we mark four
> tally lines, then for five we mark a diagonal line through the previous
> four. So by analogy a base-2 tally could go:
>
> /     one
> X     two
> X/    three
> XX    four
> XX/   five
> XXX   six
> XXX/  seven

Sure, as long as you're consistent, there's no problem.

>
> But I certainly wouldn't call it "binary", for fear of confusion with
> radix-2 binary.

That's my point. Since the common usage of "binary" is for
Standard Positional Number System of Radix 2, it follows
that "unary" is the common usage for Standard Positional
Number System of Radix 1. That's VERY confusing since such
a system is undefined. Remember, common usage does not
necessarily properly define things. Saying simply "unary"
sounds like you're extending common usage beyond its proper
boundaries.

> Possibly binary-tally, for lack of a better term.

Then possibly unary-tally would be better than unary.
Tally systems being much less common require a less
common terminology to avoid confusion.

>
> --
> Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Steven D'Aprano]

On Tue, 25 Aug 2009 11:45:28 -0700, Mensanator wrote:

> On Aug 25, 9:14 am, Steven D'Aprano  cybersource.com.au> wrote:
>> On Mon, 24 Aug 2009 18:01:38 -0700, Mensanator wrote:
>> >> If you want your data file to have values entered in hex, or oct, or
>> >> even unary (1=one, 11=two, 111=three, =four...) you can.
>>
>> > Unary? I think you'll find that Standard Positional Number Systems
>> > are not defined for radix 1.
>>
>> Of course not. But unary isn't a positional number system. It's a tally
>> system, like my example above shows. Roman numerals are another tally
>> system. Like Roman numerals, the disadvantages of unary are that you
>> can't represent negative numbers, zero, or fractions, and anything but
>> addition and subtraction is difficult. But if you want to use it,
>> perhaps out of a sense of sadism towards your users, it's easy:
[...]
> But without insignificant leading 0's, I fail to see the relevance of
> unary to this discussion.

It was just an example of how you can use numeric data in any format, no 
matter how obscure, weird or difficult, you can use it by passing it 
through an appropriate converter. You don't need compiler support for 
user-supplied data, you just write your own function.

As for insignificant leading zeroes, such a thing is meaningless in a 
base-1 tally system. Zero is the absence of a tally mark.


> And what would you call a tally system of
> radix 2? Certainly not binary.

"Radix" isn't the correct term, because radix doesn't apply to tally 
counting systems. I'd accept "base 2", in the sense that the tally is 
based on two different marks. We do something similar when we mark four 
tally lines, then for five we mark a diagonal line through the previous 
four. So by analogy a base-2 tally could go:

/ one
X two
X/three
XXfour
XX/   five
XXX   six
XXX/  seven


But I certainly wouldn't call it "binary", for fear of confusion with 
radix-2 binary. Possibly binary-tally, for lack of a better term.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[James Harris]

On 24 Aug, 03:49, Dennis Lee Bieber  wrote:

...

> > Here's another suggested number literal format. First, keep the
> > familar 0x and 0b of C and others and to add 0t for octal. (T is the
> >thirdletter of octal as X is thethirdletter of hex.) The numbers
> > above would be
>
>         The thing is -- "x" and "hex" have similar pronunciations: (h)ecks;
> the name of the radix is its own reminder for the character to use
> without thinking such conventions as "thirdletter of the radix name".
>
>         But "t" (tee) has no pronunciation resemblance to "oct" (o'kt)
> whereas the unlovely "o" at least if taken as a short vowel sound is
> similar to the "o" of "oct" given the short stop between it and the
> "ct".
>
> >   0b1011, 0t7621, 0xc26b
>
>         And "b" for binary breaks the "thirdletter of radix name"
> convention... You should be using "n" for that (and "c" for decimal )

I wasn't proposing a convention of using the third character of the
base name. I was saying that t is not too unreasonable given that we
use x for hex (rather than h).

>
>         Or we use b, o, d, h (as the HP calculator) and drop the "x"
> version.
>
>
>
> > where the three characters "0.(" begin the sequence.
>
>         Ugly...
>
> > Comments? Improvements?
>
>         Retaining which ever character is finally decided, I'd make all
> radix specified literals follow a quoted format:
>
>         "digits"radix
>
>         "01110"b
>         "123"d (of course, just 123 would be allowed for simplicity)
>         "7C"x
>         "327"o

The quoting is good. For hex, decimal, octal and binary, however, I
can't see a good reason to change away from the conventional prefix
form. And, in general, it's easier for a human to parse if the base is
specified first.

>
>         Probably wouldn't need that much change to the parser as it would,
> left to right, see a string, and then when the string is not followed by
> one white space character, find a radix marker -- the parser would then
> parse the string using the specified radix, and emit the appropriate
> numeric value instead of a string value.

Maybe. I think, though, that having the base as prefix would make the
parser's job easier as well as the job of humans. It's easier if we
know what we are parsing before we parse it rather than afterwards.

>        It only adds one extra
> character (instead of leading 0r, one has ""r), and the leading " serves
> as a warning to a reader that this is not directly readable as a number.
>
>         The alternative syntax of radix"digits" is the same length, but adds
> to the parsing as it initially looks like a name entity, then hits the
> quote, and has to back up to interpret the result as a radix marker.

True. The beginning of a number should be numeric. Using your scheme,
though, instead of radix"digits" you could have 0radix"digits".

> 0r
> format starts as a number, hits a radix marker while the
> "conversion/accumulator" is still a 0 value (0 is 0 in all radix) and
> switches the converter to accept the digits in the specified radix.

Sounds like you are suggesting 0radix"digits" but I'm not sure.

>
>         Whereas all prefix versions that don't start with a 0r tend to
> require more complex parsing:
>
>         0.(
>
> starts out looking like a number (the 0)... a floating point number (the
> .)... a function/method call on a floating point 0... WAIT? floating
> point numbers aren't callables (yet! I'm sure someone is going to show a
> way to define a variable bound to a number as a callable, though not to
> a literal number)... throw away this parse tree branch, back up and
> reparse as special numeric radix prefix...

You've laid it on thick but I agree in principle. What about
radix"digits" where radix is numeric: So 2"1101" or 3"122"? (Not to
replace 0b1101 etc but to supplement it for arbitrary bases.)

>
>         Of course, one still has to consider what will be used for \
> character encoding... \x0F vs \013 vs \b000?

The plans I had did not allow for the suggestions above so I have no
comments on character encoding yet but it's good that you mentioned
it.

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Mensanator]

On Aug 25, 9:14 am, Steven D'Aprano  wrote:
> On Mon, 24 Aug 2009 18:01:38 -0700, Mensanator wrote:
> >> If you want your data file to have values entered in hex, or oct, or
> >> even unary (1=one, 11=two, 111=three, =four...) you can.
>
> > Unary? I think you'll find that Standard Positional Number Systems are
> > not defined for radix 1.
>
> Of course not. But unary isn't a positional number system. It's a tally
> system, like my example above shows. Roman numerals are another tally
> system. Like Roman numerals, the disadvantages of unary are that you
> can't represent negative numbers, zero, or fractions, and anything but
> addition and subtraction is difficult. But if you want to use it, perhaps
> out of a sense of sadism towards your users, it's easy:
>
> def int2unary(n):
>     return '1'*n
>
> def unary2int(s):
>     n = 0
>     for c in s:
>         if c == '1': n+=1
>         else: raise ValueError('invalid unary string')
>     return n

But without insignificant leading 0's, I fail to see the relevance
of unary to this discussion. And what would you call a tally system
of radix 2? Certainly not binary.

>
> --
> Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Steven D'Aprano]

On Mon, 24 Aug 2009 18:01:38 -0700, Mensanator wrote:

>> If you want your data file to have values entered in hex, or oct, or
>> even unary (1=one, 11=two, 111=three, =four...) you can.
> 
> Unary? I think you'll find that Standard Positional Number Systems are
> not defined for radix 1.

Of course not. But unary isn't a positional number system. It's a tally 
system, like my example above shows. Roman numerals are another tally 
system. Like Roman numerals, the disadvantages of unary are that you 
can't represent negative numbers, zero, or fractions, and anything but 
addition and subtraction is difficult. But if you want to use it, perhaps 
out of a sense of sadism towards your users, it's easy:

def int2unary(n):
return '1'*n

def unary2int(s):
n = 0
for c in s:
if c == '1': n+=1
else: raise ValueError('invalid unary string')
return n



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[James Harris]

On 25 Aug, 01:25, Steven D'Aprano  wrote:

> On Mon, 24 Aug 2009 16:23:06 -0700, James Harris wrote:

> > Sure but while I wouldn't normally want to type something as obscure as
> > 32"rst" into a file of data I might want to type 0xff00 or similar. That
> > is far clearer than 65280 in some cases.
>
> > My point was that int('ff00', 16) is OK for the programmer but cannot be
> > used generally as it includes a function call.
>
> No, it's the other way around. If you have *data*, whether entered at run
> time by the user or read from a file, you can easily pass it to a
> function to convert to an int. (In fact you have to do this anyway,
> because the data will be a string and you need an int.)
>
> If you want your data file to have values entered in hex, or oct, or even

You are looking at this the other way round from me and I'll explain
why I think this is important. I'm not talking about the *programmer*
prescribing how the user should enter the data but the *user* being
able to choose to prepare the data in a certain format - the format
which makes sense for the data being entered. Your way only works if
those fields in every row have the same format. That may be the case
sometimes but is not general.


> unary (1=one, 11=two, 111=three, =four...) you can. There's no need
> to have the user enter int('ff00', 16) to get hex, just have them enter
> ff00.
>
> But when writing *code*, you want syntax which will accept integers in
> the most common bases (decimal, a distant second hex, an even more
> distant third octal, and way out on the horizon binary) without the
> runtime cost of a function call.

Be careful! When designing a language feature don't be too ready to
*tell* the users of that language what restrictions they want. Just
because the designer wants features with a certain frequency does not
mean that all users will have the same priorities. (If it is
impossible or unreasonable to support a feature then by all means
don't support it. But don't decide up-front before examining the
options that something in not personally appealing.)

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Mensanator]

On Aug 24, 10:20�pm, Erik Max Francis  wrote:
> Steven D'Aprano wrote:
> > On Mon, 24 Aug 2009 09:14:25 -0500, Derek Martin wrote:
>
> >> Assuming I'm right about that, then the use of a leading 0 to represent
> >> octal actually predates the prevalence of using 0 in dates by almost two
> >> decades. �And while using leading zeros in other contexts is "familiar"
> >> to me, I would certainly not consider it "common" by any means. �Thus I
> >> think it's fair to say that when this syntax was selected, it was a
> >> rather good choice.
>
> > Except of course to anyone familiar with mathematics in the last, oh,
> > five hundred years or so. Mathematics has used a positional system for
> > numbers for centuries now: leading zeroes have been insignificant, just
> > like trailing zeroes after the decimal point:
>
> > 9 = 09 = 009 = 9.0 = 9.00 = 0009.000 etc.
>
> Trailing zeroes are quite important when you're indicating the
> significance of a figure. �9 is not the same as 9.0 or 9.000.

Tell me about it. Unfortunnately, Microsoft doesn't understand
the difference between precision and significance. Makes my
job a nightmare when I have to convert ug/kg to mg/kg.

>
> --
> Erik Max Francis && m...@alcyone.com &&http://www.alcyone.com/max/
> � San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
> � �If the sky should fall, hold up your hands.
> � � -- (a Spanish proverb)- Hide quoted text -
>
> - Show quoted text -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Mensanator]

On Aug 24, 8:21�pm, Mel  wrote:
> Mensanator wrote:
>
> [ ... ]
>
> >> If you want your data file to have values entered in hex, or oct, or even
> >> unary (1=one, 11=two, 111=three, =four...) you can.
>
> > Unary? I think you'll find that Standard Positional Number
> > Systems are not defined for radix 1.
>
> It has to be tweaked. �If the only digit you have is 0 then your numbers
> take the form
>
> 0*1 + 0*1**2 + 0*1**3 ...
>
> and every number has an infinitely long representation. �If you cheat and
> take a 1 digit instead then it becomes workable.

Not really. If your single digit is one, you still have
an infinitely long representation only instead of every
position being zero, every position is one.

So either the only number that can be represented is 0,
or the only number that can be represented is infinity.
No amount of tweaking can fix this.

So, to use radix 1, you have to abandon the concept
of "Standard" (contains a 0) AND abandon "Positional"
(infinitely long representation). It's all in TAOCP
by Knuth if you want to get it straight.

You can have a radix 1 number system, but is meaningless
to speak of "unary" in the same context as hex, decimal,
octal & binary.

>
> � � � � Mel.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Erik Max Francis]

Steven D'Aprano wrote:

On Mon, 24 Aug 2009 09:14:25 -0500, Derek Martin wrote:


Assuming I'm right about that, then the use of a leading 0 to represent
octal actually predates the prevalence of using 0 in dates by almost two
decades.  And while using leading zeros in other contexts is "familiar"
to me, I would certainly not consider it "common" by any means.  Thus I
think it's fair to say that when this syntax was selected, it was a
rather good choice.


Except of course to anyone familiar with mathematics in the last, oh, 
five hundred years or so. Mathematics has used a positional system for 
numbers for centuries now: leading zeroes have been insignificant, just 
like trailing zeroes after the decimal point:


9 = 09 = 009 = 9.0 = 9.00 = 0009.000 etc.


Trailing zeroes are quite important when you're indicating the 
significance of a figure.  9 is not the same as 9.0 or 9.000.


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
  If the sky should fall, hold up your hands.
   -- (a Spanish proverb)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Mensanator]

On Aug 24, 7:25 pm, Steven D'Aprano  wrote:
> On Mon, 24 Aug 2009 16:23:06 -0700, James Harris wrote:
> > Sure but while I wouldn't normally want to type something as obscure as
> > 32"rst" into a file of data I might want to type 0xff00 or similar. That
> > is far clearer than 65280 in some cases.
>
> > My point was that int('ff00', 16) is OK for the programmer but cannot be
> > used generally as it includes a function call.
>
> No, it's the other way around. If you have *data*, whether entered at run
> time by the user or read from a file, you can easily pass it to a
> function to convert to an int. (In fact you have to do this anyway,
> because the data will be a string and you need an int.)
>
> If you want your data file to have values entered in hex, or oct, or even
> unary (1=one, 11=two, 111=three, =four...) you can.

Unary? I think you'll find that Standard Positional Number
Systems are not defined for radix 1.

> There's no need
> to have the user enter int('ff00', 16) to get hex, just have them enter
> ff00.
>
> But when writing *code*, you want syntax which will accept integers in
> the most common bases (decimal, a distant second hex, an even more
> distant third octal, and way out on the horizon binary) without the
> runtime cost of a function call.
>
> --
> Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Steven D'Aprano]

On Mon, 24 Aug 2009 12:40:24 -0500, Derek Martin wrote:

> On Mon, Aug 24, 2009 at 05:03:28PM +, Steven D'Aprano wrote:
>> On Mon, 24 Aug 2009 11:21:46 -0500, Derek Martin wrote:
>> > since the old syntax is prevalent both within and without the Python
>> > community, making the change is, was, and always will be a bad idea.
>>
>> Octal syntax isn't prevalent *at all*, except in a small number of
>> niche areas.
> 
> Steven, don't be obtuse.  Where octal is used in programming, the
> leading zero is prevalent.

Now who is being obtuse? If you take *any* feature at all, no matter how 
rare, you can say "Where it is used, it is prevalent". Among people who 
program in Whitespace, all three of them, the use of spaces and tabs as 
significant programming tokens is prevalent.

This whole argument is over whether or not a "feature" desired by a tiny 
proportion of the programming community -- the intersection of those who 
use octal frequently enough that using an extra  'o' is a hardship, and 
those who use C-based languages -- should hold *everyone else* hostage to 
their badly thought out notation.


[...]
> Why is it so hard for you to accept that intelligent people can disagree
> with you, and that what's right for you might be bad for others?

I can accept that intelligent people can disagree with me. I even 
sympathise with you, that you're one of the minority who don't find octal 
archaic and unnecessary, and you'll need to learn a new syntax for octal 
literals in Python 3.x. But your argument is fundamentally "but we've 
always done it this way, and other languages do it, so why should we 
change?". We should change because the desire to prevent silent errors 
caused by (e.g.) 012 being interpreted as 10, and the desire to be 
consistent with both mathematical notation and floating point syntax 
outweighs the need to be backward compatible.

This change was not a spur of the moment thing, it went through the 
entire PEP process with due concern for backward compatibility, which 
Python does *not* change without good reason. You lost, get over it. I'm 
sorry that you personally find this change a hardship, but HTFU. If and 
when you move to Python 3.x, you'll get used to it. If you can get used 
to putting braces around code blocks in C and braces around dicts in 
Python, you're more than capable of getting used to writing 012 in C and 
0o12 in Python.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Steven D'Aprano]

On Mon, 24 Aug 2009 16:23:06 -0700, James Harris wrote:

> Sure but while I wouldn't normally want to type something as obscure as
> 32"rst" into a file of data I might want to type 0xff00 or similar. That
> is far clearer than 65280 in some cases.
> 
> My point was that int('ff00', 16) is OK for the programmer but cannot be
> used generally as it includes a function call.


No, it's the other way around. If you have *data*, whether entered at run 
time by the user or read from a file, you can easily pass it to a 
function to convert to an int. (In fact you have to do this anyway, 
because the data will be a string and you need an int.) 

If you want your data file to have values entered in hex, or oct, or even 
unary (1=one, 11=two, 111=three, =four...) you can. There's no need 
to have the user enter int('ff00', 16) to get hex, just have them enter 
ff00.

But when writing *code*, you want syntax which will accept integers in 
the most common bases (decimal, a distant second hex, an even more 
distant third octal, and way out on the horizon binary) without the 
runtime cost of a function call.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[James Harris]

On 24 Aug, 14:05, Mel  wrote:
> James Harris wrote:
> > On 24 Aug, 02:19, Max Erickson  wrote:

> [ ... ]
> >> >>> int('100', 3)
> >> 9
> >> >>> int('100', 36)
> >> 1296
>
> > This is fine typed into the language directly but couldn't be entered
> > by the user or read-in from or written to a file.
>
> That's rather beside the point.  Literals don't essentially come from files
> or user input.  Essentially literals are a subset of expressions, just like
> function calls are, and they have to be evaluated by Python to yield a
> value.  I'm not averse to 32'rst', but we already have

...

> >>> int ('rst', 32)
>
> 28573

Sure but while I wouldn't normally want to type something as obscure
as 32"rst" into a file of data I might want to type 0xff00 or similar.
That is far clearer than 65280 in some cases.

My point was that int('ff00', 16) is OK for the programmer but cannot
be used generally as it includes a function call.

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Derek Martin]

On Mon, Aug 24, 2009 at 04:40:14PM -0300, Gabriel Genellina wrote:
> En Mon, 24 Aug 2009 14:40:24 -0300, Derek Martin
>  escribió:
> 
> >Why is it so hard for you to accept that intelligent people can
> >disagree with you, and that what's right for you might be bad for
> >others?
> 
> Ask the same question yourself please.

I accept it.  But I reserve the right to voice my dissent, and am
doing so.  The Usual Suspects in this forum seem to suggest that the
change is some silver bullet that makes Python suddenly Right With The
World, and I say it just ain't so.  I happen to opine that the old
behavior was better, and I will not be dissuaded from that opinion
just because a few prominent posters in this forum suggest that I'm an
idiot for disagreeing with them.

My original post in this thread, if you weren't paying attention, was
in opposition to several people trying to cram the idea down the
throats of other posters that leading zeros to represent octal numbers 
is inherently evil, and that anyone who suggests otherwise is an
Apostate to be damned for all eternity.  

Alright, I exaggerate.  Slightly. :)  

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D



pgpOhCKxjgCon.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Gabriel Genellina]

En Mon, 24 Aug 2009 14:40:24 -0300, Derek Martin   
escribió:



Why is it so hard for you to accept that intelligent people can
disagree with you, and that what's right for you might be bad for
others?


Ask the same question yourself please.

--
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Derek Martin]

On Mon, Aug 24, 2009 at 05:03:28PM +, Steven D'Aprano wrote:
> On Mon, 24 Aug 2009 11:21:46 -0500, Derek Martin wrote:
> > since the old syntax is prevalent both within and without the
> > Python community, making the change is, was, and always will be a
> > bad idea.
>
> Octal syntax isn't prevalent *at all*, except in a small number of
> niche areas.

Steven, don't be obtuse.  Where octal is used in programming, the
leading zero is prevalent.  

> You've said that this change is a hardship for you, because on your 
> terminal 0 and o are hard to distinguish. Personally, I'd say that's a 
> good sign that your terminal is crappy and you should use a better one, 

The terminal I use is just fine.  Stringing together similar
characters always has the possibility of confusing the reader.  The
human mind tends to see what it expects, and fills in the gaps when it
does not.  It wouldn't matter much if I changed my terminal font,
unless I made the font big enough to be not especially useful, except
for the rather exceptional case of detecting 0o1 and similar patterns
in python code.  The suggestion is asinine, and you know it.

> but putting that aside, let's accept that. To you, for whatever reason, 
> 0o looks just like 00.

It doesn't look "just like" 00, but similar enough that you have to
pay close attention.

> Okay then. Under the current 2.x syntax, 0012 would be interpreted as 
> octal. Under the new 3.x syntax, 0o12 which looks just like 0012 also 
> would be interpreted as octal. You have argued that it might not be any 
> harder to type the extra 'o' to get an octal literal, but that it will 
> hurt readability. I quote:
> 
> "Writing 0o12 presents no hardship; but I assert, with at least some
> support from others here, that *reading* it does."
 
Let me clarify my statement.  Writing 0o12 is easy -- there is no
hardship to type the characters 0o12 (well, actually it feels a bit
cumbersome, to be honest).  Remembering to do so, however, when
virtually everwhere else one uses octal writes it 012, is not easy.
Then I stand corrected:  There is indeed hardship.

> But according to you, reading 0o12 is just like reading 0012. 0o12 under 
> the new syntax gives decimal ten, and it looks just like 0012 in the old 
> syntax, which also gives ten. So there's no difference in reading, 

But there *IS* a difference in reading, because 0o12 is not the same
as 0012, and which one you use *matters*.  In particular, it will matter 
with the adoption of Python 3.x, where the latter will be an error.
But it matters even in 2.6 because right now, you can write it either
way, and that is (I think) even more confusing...  There is also still
discussion (mentioned in the relevant PEP) about making 0012 *valid
decimal*.  That should never, ever, ever happen.

Why is it so hard for you to accept that intelligent people can
disagree with you, and that what's right for you might be bad for
others?

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D



pgp98RVkdfZRq.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Harald Luessen]

On Mon, 24 Aug 2009 Derek Martin wrote:
>Those participating in this thread have pretty much all seem to agree
>that the only places where decimal numbers with leading zeros really
>are common are either in rather specialized applications, such as
>computer-oriented data or serial numbers (which typically behave more
>like strings, from a computer science perspective), or the rather
>common one of dates.  The latter case is perhaps what's significant,
>if any of those cases are.

I don't like the 'leading 0 is octal'-syntax. I typically think of
numbers as decimal and bytes as hexadecimal.
I would even write something like this:

# iterate over bits 3 to 5
for i in range(0x00, 0x40, 0x08):
...
print "0x%02x\n" % i

0x00
0x08
0x10
0x18
0x20
0x28
0x30
0x38

For me it is easier to see where the bits are in the hex notation.

And it is very common to use numbers with leading zeroes
that are hexadecimal. Like this:

# print address and data
for i in range(0x1):
print "%04x: %d\n" % i, data[i]

: ...
0001: ...
...
000f: ...
0010: ...
...

When you are looking for examples of numbers where leading zeroes
do not mean octal then consider decimal AND hexadecimal.

>I tend to think that within the computer
>science arena, the history and prevalence of the leading 0 indicating
>octal far outweighs all of those cases combined.

I disagree.

Harald

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Steven D'Aprano]

On Mon, 24 Aug 2009 11:21:46 -0500, Derek Martin wrote:

> since the old
> syntax is prevalent both within and without the Python community, making
> the change is, was, and always will be a bad idea.

Octal syntax isn't prevalent *at all*, except in a small number of niche 
areas.

You've said that this change is a hardship for you, because on your 
terminal 0 and o are hard to distinguish. Personally, I'd say that's a 
good sign that your terminal is crappy and you should use a better one, 
but putting that aside, let's accept that. To you, for whatever reason, 
0o looks just like 00.

Okay then. Under the current 2.x syntax, 0012 would be interpreted as 
octal. Under the new 3.x syntax, 0o12 which looks just like 0012 also 
would be interpreted as octal. You have argued that it might not be any 
harder to type the extra 'o' to get an octal literal, but that it will 
hurt readability. I quote:

"Writing 0o12 presents no hardship; but I assert, with at least some
support from others here, that *reading* it does."

But according to you, reading 0o12 is just like reading 0012. 0o12 under 
the new syntax gives decimal ten, and it looks just like 0012 in the old 
syntax, which also gives ten. So there's no difference in reading, and 
you've already accepted that the extra effort in writing it "presents no 
hardship".

A whole lot of noise over a change which is more or less invisible.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Derek Martin]

On Mon, Aug 24, 2009 at 04:47:43PM +, Steven D'Aprano wrote:
> Except of course to anyone familiar with mathematics in the last, oh, 
> five hundred years or so. Mathematics has used a positional system for 
> numbers for centuries now: leading zeroes have been insignificant, just 
> like trailing zeroes after the decimal point:
> 
> 9 = 09 = 009 = 9.0 = 9.00 = 0009.000 etc.

Dude, seriously.  No one ever *uses* leading zeros in the context of
mathematics except in 2nd grade math class.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D



pgpCgRpbc7UrM.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Steven D'Aprano]

On Mon, 24 Aug 2009 09:14:25 -0500, Derek Martin wrote:

> Assuming I'm right about that, then the use of a leading 0 to represent
> octal actually predates the prevalence of using 0 in dates by almost two
> decades.  And while using leading zeros in other contexts is "familiar"
> to me, I would certainly not consider it "common" by any means.  Thus I
> think it's fair to say that when this syntax was selected, it was a
> rather good choice.

Except of course to anyone familiar with mathematics in the last, oh, 
five hundred years or so. Mathematics has used a positional system for 
numbers for centuries now: leading zeroes have been insignificant, just 
like trailing zeroes after the decimal point:

9 = 09 = 009 = 9.0 = 9.00 = 0009.000 etc.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Derek Martin]

On Mon, Aug 24, 2009 at 08:31:13AM -0700, Carl Banks wrote:
> On Aug 24, 6:56 am, Derek Martin  wrote:
> > I think hard-coding dates is more uncommon than using octal. ;-)
> > [It unquestionably is, for me personally.]
> 
> You just don't get it, do you?  

I think I get it just fine, thanks.

> Do you really think this is a contest over what's more common and
> the winner gets to choose the syntax?  You really think that's the
> issue?

No, I think it's about egos.  Someone got the idea that 0o1 was better
than 01, and had to be Right.  And had the power to make it happen, or
at least (sadly) convince the people with the power.

I'm simply presenting an argument that the need for the change is not so
clear.  You say the old syntax is retarded.  I say the new syntax, and
the very act of making the change itself is retarded.  I think my
argument is very solid and persuasive; but of course some minds are
invulnerable to persuasion.  I might not even disagree that the old
syntax could be improved upon, except that it already is what it is,
and the new syntax is NOT better; I personally believe it's not only
not better, but that it's actually worse.  Others have agreed.

> It is not.  The issue is that C's arcane octal notation is MIND-
> BOGGLINGLY RETARDED.

As I said, I searched the web on this topic before I bothered to post.
I did a bit of research.  One of the things that my search turned up:
A lot of smart people disagree with you.  If the use of the leading
zero boggles your mind, then perhaps your mind is too easily boggled,
and perhaps you should seek a different way to occupy your time.

This is yet another case where some Pythonista has gotten it in his
head that "There is One Truth, and the Old Way be Damned, my way is
The Way, and Thus Shall It Be Evermore."  And worse yet, managed to
convince others.  Well, there's no such thing as One Truth, and there
are different perspectives that are just as valid as yours.  I'm
expressing one now.  This change sucks.  I already know that my rant
won't change the syntax.  The only reason I bothered to post is
because I do actually quite like Python -- something I can say of only
one other programming language -- and I think the powers that be are
(in some cases) making it worse, not better.  I hoped to open a few
minds with a different perspective, but of course I should have known
better.

0o1 is not better than 01. On my terminal it's hard to see the
difference between 0 and o.  YMMV.  But since YMMV, and since the old
syntax is prevalent both within and without the Python community,
making the change is, was, and always will be a bad idea.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D



pgpP7sETirZLX.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Scott David Daniels]

Piet van Oostrum wrote:

Scott David Daniels  (SDD) wrote:



SDD> James Harris wrote:...

Another option:

0.(2:1011), 0.(8:7621), 0.(16:c26b)

where the three characters "0.(" begin the sequence.

Comments? Improvements?



SDD> I did a little interpreter where non-base 10 numbers
SDD> (up to base 36) were:



SDD> .7.100   == 64  (octal)
SDD> .9.100   == 100 (decimal)
SDD> .F.100   == 256 (hexadecimal)
SDD> .1.100   == 4   (binary)
SDD> .3.100   == 9   (trinary)
SDD> .Z.100   == 46656 (base 36)


I wonder how you wrote that interpreter, given that some answers are wrong.
Obviously I started with a different set of examples and edited after 
starting to make a table that could be interpretted in each base.  After

doing that, I forgot to double check, and lo and behold .F.1000 = 46656,
while .F.100 = 1296.  Since it has been decades since I've had access
to that interpreter, this is all from memory.

--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Derek Martin]

On Mon, Aug 24, 2009 at 05:22:39PM +0200, Hendrik van Rooyen wrote:
> > Assuming I'm right about that, then the use of a leading 0 to
> > represent octal actually predates the prevalence of using 0 in dates
> > by almost two decades. 
> 
> Not quite - at the time I started, punch cards and data entry forms were 
> already well established practice, and at least on the English machines, (ICL 
> 1500/1900 series) octal was prevalent, but I don't know when the leading zero 
> octal notation started, and where.  

I said "prevalence."  The key is that the average person did not start
using leading zeros in dates until (I think) much, much later, and
that's what's relevant to this discussion.  If it were not commonplace
for people to use decimal numbers with leading zeros, this whole
thread would be a moot point, the python devs likely never would have
considered changing the syntax, and we would not be having this
discussion.  Most people did not work as data entry clerks on ICL
computers... :)

Those participating in this thread have pretty much all seem to agree
that the only places where decimal numbers with leading zeros really
are common are either in rather specialized applications, such as
computer-oriented data or serial numbers (which typically behave more
like strings, from a computer science perspective), or the rather
common one of dates.  The latter case is perhaps what's significant,
if any of those cases are.  I tend to think that within the computer
science arena, the history and prevalence of the leading 0 indicating
octal far outweighs all of those cases combined.

> I think you give it credence for far more depth of design thinking than what 
> actually happened in those days - some team working on a compiler made a 
> decision  (based on gut feel or experience, or precedent, or whim ) and that 
> was that - lo! - a standard is born! 

Rather, I think you give the folks at Bell Labs way too little credit.
They designed a programming language and an operating system that,
while certainly not exactly the same as their original incarnations,
even then contained a lot of features and design principles that
remain state-of-the-art (though perhaps their specific implementation
details have since been improved) and in many ways superior to a lot
of what has come since (e.g. virtually anything that came out of
Microsoft).  [That's just my opinion, of course... but shared by many.
:)]  I don't think that happened by mere accident.  That's not to say
they were perfect, but those guys had their proverbial $#!t together.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D



pgpTSmevmuY7i.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Literal concatenation, strings vs. numbers (was: Numeric literals in other than base 10 - was Annoying octal notation)

[Steven D'Aprano]

On Mon, 24 Aug 2009 12:45:25 +1000, Ben Finney wrote:

> greg  writes:
> 
>> J. Cliff Dyer wrote:
>>
>> > What happens if you use a literal like 0x10f 304?
>>
>> To me the obvious thing to do is concatenate them textually and then
>> treat the whole thing as a single numeric literal. Anything else
>> wouldn't be sane, IMO.

Agreed. It's the only sane way to deal with concatenating numeric 
literals. It makes it simple and easy to understand: remove the 
whitespace from inside the literal, and parse as normal.

123 4567 => 1234567  # legal
0xff 123 => 0xff123  # legal
123 0xff => 1230xff  # illegal

The first two examples would be legal, the last would raise a syntax 
error, for obvious reasons. This would also work for floats:

1.23 4e5 => 1.234e5  # legal
1.23 4.5 => 1.234.5  # illegal
1e23 4e5 => 1e234e5  # illegal



> Yet, as was pointed out, that behaviour would be inconsistent with the
> concatenation of string literals::
> 
> >>> "abc" r'def' u"ghi" 'jkl'
> u'abcdefghijkl'

Unicode/byte conversion is obviously a special case, and arguably should 
have been prohibited, although "practicality beats purity" suggests that 
a single unicode string in the sequence should make the lot unicode. 
(What else could it mean?)

In any case, numeric concatenation and string concatenation are very 
different beasts. With strings, you have to interpret each piece as 
either bytes or characters, you have to treat escapes specially, you have 
to deal with matching delimiters. For numeric concatenation, none of 
those complications is relevant: there is no equivalent to the byte/
character dichotomy, there are no escape sequences, there are no 
delimiters.

Numeric literals are much simpler than string literals, consequently the 
concatenation rule can be correspondingly simpler too. There's no need to 
complicate it by *adding* complexity: you can't have mixed bases in a 
single numeric literal without spaces, why would you expect to have mixed 
bases in one with spaces?




-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Carl Banks]

On Aug 24, 6:56 am, Derek Martin  wrote:
> I think
> hard-coding dates is more uncommon than using octal. ;-)  [It
> unquestionably is, for me personally.]

You just don't get it, do you?  Do you really think this is a contest
over what's more common and the winner gets to choose the syntax?  You
really think that's the issue?

It is not.  The issue is that C's arcane octal notation is MIND-
BOGGLINGLY RETARDED.

So, even if Unix file permissions were a hundred times more common
than padding integer constants with zero, it still wouldn't be a good
idea to have it in Python because the notation is retarded.

Even if 99.999% of other languages use the notation, it still wouldn't
be a good idea to have it in Python because the notation is retarded.

The vast majority of people reading this will understand intuitively
why the arcane octal notation is retarded.  I was going to explain it,
but I decided it's not worth a serious argument.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal?notation

[garabik-news-2005-05]

J. Cliff Dyer  wrote:
> I had an objection to using spaces in numeric literals last time around
> and it still stands, and it still stands in the new one.
> 

Or, we can use U+00A0 NO-BREAK SPACE, once we already have unicode
variable names :-)
(probably some people would find it difficult to type, though
with my keyboard layout it is COMPOSE + SPACE + SPACE, not 
more difficult than _).
Well, reading code listings could be a bit confusing.
Thinking about it, U+2005 FOUR-PER-EM SPACE makes more sense.
Aesthetically, too :-)

-- 
 ---
| Radovan Garabík http://kassiopeia.juls.savba.sk/~garabik/ |
| __..--^^^--..__garabik @ kassiopeia.juls.savba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Derek Martin]

On Mon, Aug 24, 2009 at 08:56:48AM -0500, Derek Martin wrote:
> On Sun, Aug 23, 2009 at 01:13:32PM +, Matthew Woodcraft wrote:
> > A more common case is dates.
> 
> I suppose this is true, but [...]
> I tend to also discount this example, because when we write dates
> with leading zeros, usually it's in some variation of the form
> 08/09/2009, which, containing slashes, is a string, not a number

In fact, now that I think of it...

I just looked at some old school papers I had tucked away in a family
album.  I'm quite sure that in grammar school, I was tought to use a
date format of 8/9/79, without leading zeros.  I can't prove it, of
course, but feel fairly sure that the prevalence of leading zeros in
dates occured only in the mid to late 1980's as computers became more
prevalent in our society (no doubt because thousands of cobol
programmers writing business apps needed a way to convert dates as
strings to numbers that was easy and fit in small memory).

Assuming I'm right about that, then the use of a leading 0 to
represent octal actually predates the prevalence of using 0 in dates
by almost two decades.  And while using leading zeros in other
contexts is "familiar" to me, I would certainly not consider it
"common" by any means.  Thus I think it's fair to say that when this
syntax was selected, it was a rather good choice.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D



pgphWLB493GWi.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Derek Martin]

On Sun, Aug 23, 2009 at 01:13:32PM +, Matthew Woodcraft wrote:
> Dennis Lee Bieber  writes:
> > About the only place one commonly sees leading zeros on decimal
> > numbers, in my experience, is zero-filled COBOL data decks (and since
> > classic COBOL stores in BCD anyway... binary (usage is
> > computational/comp-1) was a later add-on to the data specification model
> > as I recall...)
> 
> A more common case is dates.

I suppose this is true, but I can't remember the last time I
hard-coded a date in a program, or worked on someone else's code with
hard-coded dates.  I'm fairly certain I've never done it, and if I
had, I obviously would not have used leading zeros.  I think
hard-coding dates is more uncommon than using octal. ;-)  [It
unquestionably is, for me personally.]  I tend to also discount this
example, because when we write dates with leading zeros, usually it's
in some variation of the form 08/09/2009, which, containing slashes,
is a string, not a number, and can not be used as a date literal in
any language I know.  We do it for reasons of format, which again
implies that it has more the characteristics of a string than of a
number.  To use such a thing in any programming language I can think
of would require translation from a string.

> I've seen people trip over this writing things like
> 
> xxx = [
> date(2009, 10, 12),
> date(2009, 12, 26),
> date(2010, 02, 09),
> ]

I've never seen anyone do this (no doubt because it would be an
error), but as I said, I don't think I've ever seen hard-coded dates
in any programs I've worked on.  I've never encountered anyone having
problems with octals who was not a total noob at programming.  The
changing of this syntax seems like much ado about nothing to me, and
as such is annoying, consider that I use it very often.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D



pgpJdmZ75Hu7Q.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Derek Martin]

On Sun, Aug 23, 2009 at 06:13:31AM +, Steven D'Aprano wrote:
> On Sat, 22 Aug 2009 22:19:01 -0500, Derek Martin wrote:
> > On Sat, Aug 22, 2009 at 02:55:51AM +, Steven D'Aprano wrote:
> >> And the great thing is that now you get to teach yourself to stop
> >> writing octal numbers implicitly and be write them explicitly with a
> >> leading 0o instead :)
> > 
> > Sorry, I don't write them implicitly.  A leading zero explicitly states
> > that the numeric constant that follows is octal.
> 
> That is incorrect.

No, it simply isn't.  It is a stated specification in most popular
programming languages that an integer preceded by a leading zero is an
octal number.  That makes it explicit, when used by a programmer to
write an octal literal.  By definition.  End of discussion.

> (Explicitness isn't a binary state

Of course it is.  Something can be either stated or implied... there
are no shades in between.  Perhaps you mean "obvious and intutitive"
where you are using the word "explicit" above (and that would be a
matter of subjective opinion).  The leading zero, however, is
undoubtedly explicit.  It is an explicitly written token which, in
that context, has the meaning that the digits that follow are an octal
number.  One simply needs to be aware of that aspect of the
specification of the programming language, and one will clearly know
that it is octal.

My point in mentioning that many other programming languages, by the
way, was NOT to suggest that, "See, look here, all these other folks
do it that way too, so it must be right."  It was to refute the notion that 
the leading zero as octal was in some way unusual.  It is, in fact,
ubiquitous in computing, taught roughly in the first week of any
beginning computing course using nearly any modern popular programming
language, and discussed within the first full page of text in the
section on numerical literals in _Learning Python_ (and undoubtedly
many other books on Python).  It may be a surprise the first time you
run into it, but you typically won't forget that detail after you run
into it the first time.

> However, octal numbers are defined implicitly: 012 is a legal base 10 
> number, or base 3, or base 9, or base 16. 

Not in any programming language I use today, it's not.  In all of
those, 012 is an octal integer literal, per the language spec.

> There's nothing about a leading zero that says "base 8" apart from
> familiarity. 

That is simply untrue.  What says base 8 about a leading zero is the
formal specification of the programming language.  

The only way using octal could be implicit in the code is if you
wrote something like:

  x = 12 

in your code, and then had to pass a flag to your compiler or
interpreter to tell it that you meant to use octal integer literals
instead of decimal ones.  That, of course, would be insane.  But
specifying a leading zero to represent an octal number zero is very
much explicit, by definition.

> We can see the difference between leading 0x and leading 0 if you
> repeat it: repeating an explicit 0x, as in 0x0xFF, is a syntax
> error, while repeating an implicit 0 silently does nothing
> different:

No, we can't.  Just as you can type 0012, you can also type 0x0FF.
It's not different AT ALL.  In both cases, the marker designated by
the programming language as the base indicator can be followed by an
arbitrary number of zeros which do not impact the magnitude of the
integer so specified.  Identical behavior.  The key is simply to
understand that the first 0 is not a digit -- it's a syntactic marker,
an operator if you will (though Python may not technically think of it
that way).  The definition of '0' is overloaded, just as other
language tokens often are.  This, too, is hardly unusual.

> There are a bunch of languages, pretty much all heavily influenced
> by C, which treat integer literals with leading 0s as oct: C++,
> Javascript, Python 2.x, Ruby, Perl, Java. As so often is the case,
> C's design mistakes become common practice. Sigh.

That it is a design mistake is a matter of opinion.  Obviously the
people who designed it didn't think it was a mistake, and neither do
I.  If you search the web for this topic (I did), you will find no
shortage of people who think the recent movement to irradicate the
leading zero to be frustrating, annoying, and/or stupid.  And by
the way, this representation predates C.  It was at least present in
B.

> FORTRAN 90 uses a leading O (uppercase o) for octal

That clearly IS a design mistake, because O is virtually
indistinguishable from 0, especially considering varying fonts and
people's variable eye sight quality.

> Algol uses an explicit base: 8r12 to indicate octal 10.

This is far better than 0o01.  I maintain that 0o1 is only marginally
better than O01 (from your fortran example) or 0O1, allowed by Python.
The string 8r12 has the nicety that it can easily be used to represent
integers of any radix in a consistent fashion.  But I maintain that
the leading zero is j

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Mel]

James Harris wrote:

> On 24 Aug, 02:19, Max Erickson  wrote:
[ ... ]
>> >>> int('100', 3)
>> 9
>> >>> int('100', 36)
>> 1296
> 
> This is fine typed into the language directly but couldn't be entered
> by the user or read-in from or written to a file.

That's rather beside the point.  Literals don't essentially come from files 
or user input.  Essentially literals are a subset of expressions, just like 
function calls are, and they have to be evaluated by Python to yield a 
value.  I'm not averse to 32'rst', but we already have

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> int ('rst', 32)
28573

Mel.

> 
> James


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[NevilleDNZ]

On Aug 23, 9:42 pm, James Harris 
wrote:
> The numbers above would be
>
>   0b1011, 0t7621, 0xc26b

Algol68 has the type BITS, that is converted to INT with the ABS
operator.
The numbers above would be:
>   2r1011, 8r7621, 16rc26b

"r" is for radix: http://en.wikipedia.org/wiki/Radix

The standard supports 2r, 4r, 8r & 16r only.

The standard supports LONG BITS, LONG LONG BITS etc, but does not
include UNSIGNED.

Compare gcc's:

bash$ cat num_lit.c
#include 
main(){
  printf("%d %d %d %d\n",0x,0,,0b);
}

bash$ ./num_lit
65535 4095  15


With Algol68's: https://sourceforge.net/projects/algol68/

bash$ cat num_lit.a68
main:(
  printf(($g$,ABS 16r,ABS 8r,,ABS 2r,$l$))
)

bash$ algol68g ./num_lit.a68
 +65535  +4095  ++15

Enjoy
N
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Literal concatenation, strings vs. numbers (was: Numeric literals in other than base 10 - was Annoying octal notation)

[Carl Banks]

On Aug 23, 7:45 pm, Ben Finney  wrote:
> greg  writes:
> > J. Cliff Dyer wrote:
>
> > > What happens if you use a literal like 0x10f 304?
>
> > To me the obvious thing to do is concatenate them textually and then
> > treat the whole thing as a single numeric literal. Anything else
> > wouldn't be sane, IMO.
>
> Yet, as was pointed out, that behaviour would be inconsistent with the
> concatenation of string literals::
>
>     >>> "abc" r'def' u"ghi" 'jkl'
>     u'abcdefghijkl'

Well my take on it is that this would not be the same as string
concatenation, the series of digits would be parsed as a single token
with spaces automatically removed.  That does make a difference to the
users (it's not just under the covers).

For instance, string concatenation works across lines:

"abc"
"def"

but if the numbers were parsed as a single token it wouldn't
necessarily be allowed, and would be unwise, so this is out:

100
200

You might want to also enforce rules such as only a single space can
separate digits, no tabs, not multiple spaces, so this

100  200

would also be right out.  You might even want to enforce that spaces
be at regular intervals.  I don't think it would matter too much that
digit separation can superficially resemble string concatenation if
you don't break the strings across lines, it's not too difficult to
explain what the difference is, and there's really not much chance
anyone would be confused by their meanings.

Having said all that, I would favor _ as a digit separator in Python
any day of the week, and I don't think it's all that important to have
one at all.

HOWEVER, I once proposed that if I were designing a new language I'd
consider allowing spaces in identifiers.  (That didn't stop people
from arguing why it would be confusing in Python, but never mind
that.)  If spaces were allowed in identifiers, then I'd be also in
favor of spaces in numeric literals.


> So, different representations of literals are parsed as separate
> literals, then concatenated. To have the behaviour you describe, the
> case needs to be made separately that digit concatenation should not be
> consistent with the established string literal parsing behaviour.

Well, one doesn't really *need* to make that case, they just might not
care about consistency.

But if they did I think Erik's case is a good one: very little chance
of confusion because there's really only one reasonable
interpretation.  The point of consistency is to help understand things
by analogy, but if analogy doesn't help understanding--and it wouldn't
in this case--there's no point.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[James Harris]

On 24 Aug, 09:30, Erik Max Francis  wrote:
> James Harris wrote:
> > On 24 Aug, 09:05, Erik Max Francis  wrote:
>  Here's another suggested number literal format. First, keep the
>  familar 0x and 0b of C and others and to add 0t for octal. (T is the
>  third letter of octal as X is the third letter of hex.) The numbers
>  above would be
>    0b1011, 0t7621, 0xc26b
>  Second, allow an arbitrary number base by putting base and number in
>  quotes after a zero as in
>    0"2:1011", 0"8:7621", 0"16:c26b"
> >>> Why not just put the base first, followed by the value in quotes:
> >>>     2"1011", 8"7621", 16"c26b"
> >> It's always a bit impressive how syntax suggestions get more and more
> >> involved and, if you'll forgive me for saying, ridiculous as the
> >> conversation continues.  This is starting to get truly nutty.
>
> > Why do you say that here? MRAB's suggestion is one of the clearest
> > there has been. And it incorporates the other requirements: starts
> > with a digit, allows an appropriate alphabet, has no issues with
> > spacing digit groups, shows clearly where the number ends and could
> > take an exponent suffix.
>
> In your opinion.  Obviously not in others.  Which is pretty obviously
> what I meant, so the rhetorical question is a bit weird here.

Don't get defensive Yes, in my opinion, if you like, but you can't
say "obviously not in others" as no one else but you has commented on
MRAB's suggestion.

Also, when you say "This is starting to get truly nutty" would you
accept that that's in your opinion?

> There's a reason that languages designed by committee end up horrific
> nightmares.

True but I would suggest that mistakes are also made by designers who
do not seek the opinions of others. There's a balance to be struck
between a committee and an ivory tower.

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Erik Max Francis]

Hendrik van Rooyen wrote:
I also tried to include an example of a literal with a base of a Googol but I 
ran out of both ink and symbols.

:-)


... or particles in the observable Universe, for that matter.

--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
  Do not seek death. Death will find you.
   -- Dag Hammarskjold
--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Erik Max Francis]

James Harris wrote:

On 24 Aug, 02:19, Max Erickson  wrote:

It can be assumed however that .9. isn't in binary?
That's a neat idea. But an even simpler scheme might be:
.octal.100
.decimal.100
.hex.100
.binary.100
.trinary.100
until it gets to this anyway:
.thiryseximal.100

At some point, abandoning direct support for literals and just
having a function that can handle different bases starts to make a
lot of sense to me:


int('100', 8)

64

int('100', 10)

100

int('100', 16)

256

int('100', 2)

4

int('100', 3)

9

int('100', 36)

1296


This is fine typed into the language directly but couldn't be entered
by the user or read-in from or written to a file.


Why would a programmer be expecting an arbitrary-radix numeric literal 
typed in by a user or read from a file?  If you're reading it from a 
file, you've already got it in some satisfactory form, binary or 
otherwise.  If you're taking it as input from a user, they're not going 
to know the Python syntax anyway, and would type in the radix and then 
the literal (in the unlikely case this would ever be required, which is 
still hard to imagine).


Either way, conversion is, as Max showed, one line of code.  It's hard 
to see the explicit need for truly arbitrary-radix literals in any 
language -- and I'm the guy who's put quaternary literals in syntaxes 
he's had to develop just for fun.  Binary, octal, decimal, hexadecimal, 
sure.  Beyond that it's a solution begging for problems.


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
  Do not seek death. Death will find you.
   -- Dag Hammarskjold
--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Erik Max Francis]

James Harris wrote:

On 24 Aug, 09:05, Erik Max Francis  wrote:

Here's another suggested number literal format. First, keep the
familar 0x and 0b of C and others and to add 0t for octal. (T is the
third letter of octal as X is the third letter of hex.) The numbers
above would be
  0b1011, 0t7621, 0xc26b
Second, allow an arbitrary number base by putting base and number in
quotes after a zero as in
  0"2:1011", 0"8:7621", 0"16:c26b"

Why not just put the base first, followed by the value in quotes:
2"1011", 8"7621", 16"c26b"

It's always a bit impressive how syntax suggestions get more and more
involved and, if you'll forgive me for saying, ridiculous as the
conversation continues.  This is starting to get truly nutty.


Why do you say that here? MRAB's suggestion is one of the clearest
there has been. And it incorporates the other requirements: starts
with a digit, allows an appropriate alphabet, has no issues with
spacing digit groups, shows clearly where the number ends and could
take an exponent suffix.


In your opinion.  Obviously not in others.  Which is pretty obviously 
what I meant, so the rhetorical question is a bit weird here.


There's a reason that languages designed by committee end up horrific 
nightmares.


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
  Do not seek death. Death will find you.
   -- Dag Hammarskjold
--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[James Harris]

On 24 Aug, 09:05, Erik Max Francis  wrote:

...

> >> Here's another suggested number literal format. First, keep the
> >> familar 0x and 0b of C and others and to add 0t for octal. (T is the
> >> third letter of octal as X is the third letter of hex.) The numbers
> >> above would be
>
> >>   0b1011, 0t7621, 0xc26b
>
> >> Second, allow an arbitrary number base by putting base and number in
> >> quotes after a zero as in
>
> >>   0"2:1011", 0"8:7621", 0"16:c26b"
>
> > Why not just put the base first, followed by the value in quotes:
>
> >     2"1011", 8"7621", 16"c26b"
>
> It's always a bit impressive how syntax suggestions get more and more
> involved and, if you'll forgive me for saying, ridiculous as the
> conversation continues.  This is starting to get truly nutty.

Why do you say that here? MRAB's suggestion is one of the clearest
there has been. And it incorporates the other requirements: starts
with a digit, allows an appropriate alphabet, has no issues with
spacing digit groups, shows clearly where the number ends and could
take an exponent suffix.

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Hendrik van Rooyen]

On Monday 24 August 2009 01:04:37 bartc wrote:

> That's a neat idea. But an even simpler scheme might be:
>
> .octal.100
> .decimal.100
> .hex.100
> .binary.100
> .trinary.100
>
> until it gets to this anyway:
>
> .thiryseximal.100

Yeah right.  So now I first have to type a string, which probably has a strict 
spelling, before a number.  It is only marginally less stupid than this:

1.0 
- Unary
11.0101 - Binary
111. 012012 - Trinary
.01234567   - Octal
11.0123456789   - Decimal
.0123456789abcdef   - Hex

Any parser that can count will immediately know what to do.

I also tried to include an example of a literal with a base of a Googol but I 
ran out of both ink and symbols.
:-)
- Hendrik
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[James Harris]

On 24 Aug, 02:19, Max Erickson  wrote:

...

> > It can be assumed however that .9. isn't in binary?
>
> > That's a neat idea. But an even simpler scheme might be:
>
> > .octal.100
> > .decimal.100
> > .hex.100
> > .binary.100
> > .trinary.100
>
> > until it gets to this anyway:
>
> > .thiryseximal.100
>
> At some point, abandoning direct support for literals and just
> having a function that can handle different bases starts to make a
> lot of sense to me:
>
> >>> int('100', 8)
> 64
> >>> int('100', 10)
> 100
> >>> int('100', 16)
> 256
> >>> int('100', 2)
> 4
> >>> int('100', 3)
> 9
> >>> int('100', 36)
> 1296

This is fine typed into the language directly but couldn't be entered
by the user or read-in from or written to a file.

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Erik Max Francis]

J. Cliff Dyer wrote:

I had an objection to using spaces in numeric literals last time around
and it still stands, and it still stands in the new one.

What happens if you use a literal like 0x10f 304?  Is 304 treated as
decimal or hexadecimal?  It's not clear how you would begin to combine
it.


Well, you can't combine them in any meaningful mathematical or 
computational sense if they're of different bases, so the answer lies 
therein:  You shouldn't be allowed to do that.



The way string concatenation works, it takes two independent string
literals, and combines them.  If you specify r'\n' 'abc\n', the first
half is treated independently as a raw string, and the second half is
treated as a normal string.  The result is '\\nabc\n'.

With numeric literals, this behavior doesn't even make sense.  How do
you concatenate hex 10f with decimal 304?


You can't, and the operation makes no sense, which is what makes the 
syntax unambiguous.  An extended numeric literal continues the radix of 
wherever it started.


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
  Do not seek death. Death will find you.
   -- Dag Hammarskjold
--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Erik Max Francis]

MRAB wrote:

James Harris wrote:

On 23 Aug, 00:16, Mel  wrote:

James Harris wrote:

I have no idea why Ada which uses the # also apparently uses it to end
a number
  2#1011#, 8#7621#, 16#c26b#

Interesting.  They do it because of this example from
:


Thanks for providing an explanation.


2#1#E8-- an integer literal of value 256

where the E prefixes a power-of-2 exponent, and can't be taken as a 
digit of

the radix.  That is to say

16#1#E2

would also equal 256, since it's 1*16**2 .


Here's another suggested number literal format. First, keep the
familar 0x and 0b of C and others and to add 0t for octal. (T is the
third letter of octal as X is the third letter of hex.) The numbers
above would be

  0b1011, 0t7621, 0xc26b

Second, allow an arbitrary number base by putting base and number in
quotes after a zero as in

  0"2:1011", 0"8:7621", 0"16:c26b"


Why not just put the base first, followed by the value in quotes:

2"1011", 8"7621", 16"c26b"


It's always a bit impressive how syntax suggestions get more and more 
involved and, if you'll forgive me for saying, ridiculous as the 
conversation continues.  This is starting to get truly nutty.


What I've done in my projects is simply extend the pattern of 0x... for 
hexadecimal literals in C to 0b... for binary, 0o... for octal, 0d... 
for decimal (though redundant as that's the default), and so on.  (Go 
crazy and add 0t... for trinary and 0q... for quaternary if you feel 
like it.)  To me this always seemed elegant, simple, and understandable.


If arbitrary radix values is what's desirable, then some syntax like

r

(e.g., 8r024222570 for an octal number which represents a very lame 
joke) would work, but seems to me like huge overkill.  A normal string 
literal coupled with a "constructor" type function would seem far more 
appropriate -- and we already have that with `int`.


As for large literals, I'd go with having spaces indicate automatic 
concatenation (though only the first in the series can indicate the 
radix, whichever method you choose above).  It's the same as for 
strings, and it's the common SI recommendation for thousands separators 
anyway.


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
  The little I know, I owe to my ignorance.
   -- Sacha Guitry
--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Piet van Oostrum]

> Scott David Daniels  (SDD) wrote:

>SDD> James Harris wrote:...
>>> Another option:
>>> 
>>> 0.(2:1011), 0.(8:7621), 0.(16:c26b)
>>> 
>>> where the three characters "0.(" begin the sequence.
>>> 
>>> Comments? Improvements?

>SDD> I did a little interpreter where non-base 10 numbers
>SDD> (up to base 36) were:

>SDD> .7.100   == 64  (octal)
>SDD> .9.100   == 100 (decimal)
>SDD> .F.100   == 256 (hexadecimal)
>SDD> .1.100   == 4   (binary)
>SDD> .3.100   == 9   (trinary)
>SDD> .Z.100   == 46656 (base 36)

I wonder how you wrote that interpreter, given that some answers are wrong.
-- 
Piet van Oostrum 
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: p...@vanoostrum.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Literal concatenation, strings vs. numbers (was: Numeric literals in other than base 10 - was Annoying octal notation)

[Ben Finney]

greg  writes:

> J. Cliff Dyer wrote:
>
> > What happens if you use a literal like 0x10f 304?
>
> To me the obvious thing to do is concatenate them textually and then
> treat the whole thing as a single numeric literal. Anything else
> wouldn't be sane, IMO.

Yet, as was pointed out, that behaviour would be inconsistent with the
concatenation of string literals::

>>> "abc" r'def' u"ghi" 'jkl'
u'abcdefghijkl'

So, different representations of literals are parsed as separate
literals, then concatenated. To have the behaviour you describe, the
case needs to be made separately that digit concatenation should not be
consistent with the established string literal parsing behaviour.

-- 
 \“What if the Hokey Pokey IS what it's all about?” —anonymous |
  `\   |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Ben Finney]

Max Erickson  writes:

> At some point, abandoning direct support for literals and just 
> having a function that can handle different bases starts to make a 
> lot of sense to me:
>
> >>> int('100', 8)
> 64
> >>> int('100', 10)
> 100
> >>> int('100', 16)
> 256
> >>> int('100', 2)
> 4
> >>> int('100', 3)
> 9
> >>> int('100', 36)
> 1296

Hah! You don't get me that easily, nobody would make something so simple
and obvious.

Right, guys?

-- 
 \   “When a well-packaged web of lies has been sold to the masses |
  `\over generations, the truth will seem utterly preposterous and |
_o__)its speaker a raving lunatic.” —Dresden James |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[greg]

J. Cliff Dyer wrote:


What happens if you use a literal like 0x10f 304?


To me the obvious thing to do is concatenate them
textually and then treat the whole thing as a single
numeric literal. Anything else wouldn't be sane, IMO.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Max Erickson]

"bartc"  wrote:

> 
> "Scott David Daniels"  wrote in message 
> news:kn2dnszr5b0bwazxnz2dnuvz_s-dn...@pdx.net...
>> James Harris wrote:...
>>> Another option:
> 
> It can be assumed however that .9. isn't in binary?
> 
> That's a neat idea. But an even simpler scheme might be:
> 
> .octal.100
> .decimal.100
> .hex.100
> .binary.100
> .trinary.100
> 
> until it gets to this anyway:
> 
> .thiryseximal.100
> 

At some point, abandoning direct support for literals and just 
having a function that can handle different bases starts to make a 
lot of sense to me:

>>> int('100', 8)
64
>>> int('100', 10)
100
>>> int('100', 16)
256
>>> int('100', 2)
4
>>> int('100', 3)
9
>>> int('100', 36)
1296


max

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[bartc]

"Scott David Daniels"  wrote in message 
news:kn2dnszr5b0bwazxnz2dnuvz_s-dn...@pdx.net...

James Harris wrote:...

Another option:

  0.(2:1011), 0.(8:7621), 0.(16:c26b)

where the three characters "0.(" begin the sequence.

Comments? Improvements?


I did a little interpreter where non-base 10 numbers
(up to base 36) were:

.7.100   == 64  (octal)
.9.100   == 100 (decimal)
.F.100   == 256 (hexadecimal)
.1.100   == 4   (binary)
.3.100   == 9   (trinary)
.Z.100   == 46656 (base 36)
Advantages:
Tokenizer can recognize chunks easily.
Not visually too confusing,
No issue of what base the base indicator is expressed in.


It can be assumed however that .9. isn't in binary?

That's a neat idea. But an even simpler scheme might be:

.octal.100
.decimal.100
.hex.100
.binary.100
.trinary.100

until it gets to this anyway:

.thiryseximal.100

--
Bartc 


--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Scott David Daniels]

James Harris wrote:...

Another option:

  0.(2:1011), 0.(8:7621), 0.(16:c26b)

where the three characters "0.(" begin the sequence.

Comments? Improvements?


I did a little interpreter where non-base 10 numbers
(up to base 36) were:

.7.100   == 64  (octal)
.9.100   == 100 (decimal)
.F.100   == 256 (hexadecimal)
.1.100   == 4   (binary)
.3.100   == 9   (trinary)
.Z.100   == 46656 (base 36)
Advantages:
Tokenizer can recognize chunks easily.
Not visually too confusing,
No issue of what base the base indicator is expressed in.

--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[MRAB]

James Harris wrote:

On 23 Aug, 00:16, Mel  wrote:

James Harris wrote:

I have no idea why Ada which uses the # also apparently uses it to end
a number
  2#1011#, 8#7621#, 16#c26b#

Interesting.  They do it because of this example from
:


Thanks for providing an explanation.


2#1#E8-- an integer literal of value 256

where the E prefixes a power-of-2 exponent, and can't be taken as a digit of
the radix.  That is to say

16#1#E2

would also equal 256, since it's 1*16**2 .


Here's another suggested number literal format. First, keep the
familar 0x and 0b of C and others and to add 0t for octal. (T is the
third letter of octal as X is the third letter of hex.) The numbers
above would be

  0b1011, 0t7621, 0xc26b

Second, allow an arbitrary number base by putting base and number in
quotes after a zero as in

  0"2:1011", 0"8:7621", 0"16:c26b"


Why not just put the base first, followed by the value in quotes:

2"1011", 8"7621", 16"c26b"


This would work for arbitrary bases and allows an exponent to be
tagged on the end. It only depends on zero followed by a quote mark
not being used elsewhere. Finally, although it uses a colon it doesn't
take it away from being used elsewhere in the language.

Another option:

  0.(2:1011), 0.(8:7621), 0.(16:c26b)

where the three characters "0.(" begin the sequence.

Comments? Improvements?


--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[James Harris]

On 23 Aug, 21:55, James Harris  wrote:

...

> >  However for floating point you
> > need at least three letters because a floating point number has
> > three parts: the fixed point point, the exponent base, and the
> > exponent.  Now we can represent the radices of the individual
> > parts with the 'r'scheme, e.g., 2r101001, but we need separate
> > letters to designate the exponent base and the exponent.  B and E
> > are the obvious choices, though we want to be careful about a
> > confusion with 'b' in hex.  For example, using 'R',
>
> > 3R20.1B2E16Rac
>
> Ooh err!
>
> > is 20.1 in trinary (6 1/3) times 2**172 (hex ac).
>
> > I grant that this example looks a bit gobbledegookish,
>
> You think? :-)
>
> > but normal
> > usage would be much simpler.  The notation doesn't handle
> > balanced trinary; however I opine that balanced trinary requires
> > special notation.
>
> When the programmer needs to construct such values how about allowing
> him or her to specify something like
>
>   (20.1 in base 3) times 2 to the power of 0xac
>
> Leaving out how to specify (20.1 in base 3) for now this could be
>
>   (20.1 in base 3) * 2 ** 0xac

Using the suggestion from another post would convert this to

  0.(3:20.1) * 2 ** 0xac

>
> The compiler could convert this to a constant.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[James Harris]

On 23 Aug, 00:16, Mel  wrote:
> James Harris wrote:
> > I have no idea why Ada which uses the # also apparently uses it to end
> > a number
>
> >   2#1011#, 8#7621#, 16#c26b#
>
> Interesting.  They do it because of this example from
> :

Thanks for providing an explanation.

>
> 2#1#E8                    -- an integer literal of value 256
>
> where the E prefixes a power-of-2 exponent, and can't be taken as a digit of
> the radix.  That is to say
>
> 16#1#E2
>
> would also equal 256, since it's 1*16**2 .

Here's another suggested number literal format. First, keep the
familar 0x and 0b of C and others and to add 0t for octal. (T is the
third letter of octal as X is the third letter of hex.) The numbers
above would be

  0b1011, 0t7621, 0xc26b

Second, allow an arbitrary number base by putting base and number in
quotes after a zero as in

  0"2:1011", 0"8:7621", 0"16:c26b"

This would work for arbitrary bases and allows an exponent to be
tagged on the end. It only depends on zero followed by a quote mark
not being used elsewhere. Finally, although it uses a colon it doesn't
take it away from being used elsewhere in the language.

Another option:

  0.(2:1011), 0.(8:7621), 0.(16:c26b)

where the three characters "0.(" begin the sequence.

Comments? Improvements?

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[James Harris]

On 23 Aug, 04:38, c...@tiac.net (Richard Harter) wrote:
> On Sat, 22 Aug 2009 14:54:41 -0700 (PDT), James Harris
>
>
>
>
>
>  wrote:
> >On 22 Aug, 10:27, David <71da...@libero.it> wrote:
>
> >... (snipped a discussion on languages and other systems interpreting
> >numbers with a leading zero as octal)
>
> >> > Either hexadecimal should have been 0h or octal should
> >> > have been 0t :=3D)
>
> >> I have seen the use of Q/q instead in order to make it clearer. I still
> >> prefer Smalltalk's 16rFF and 8r377.
>
> >> Two interesting options. In a project I have on I have also considered
> >> using 0q as indicating octal. I maybe saw it used once somewhere else
> >> but I have no idea where. 0t was a second choice and 0c third choice
> >> (the other letters of oct). 0o should NOT be used for obvious reasons.
>
> >> So you are saying that Smalltalk has r where
> >> r is presumably for radix? That's maybe best of all. It preserves the
> >> syntactic requirement of starting a number with a digit and seems to
> >> have greatest flexibility. Not sure how good it looks but it's
> >> certainly not bad.
>
> I opine that a letter is better; special characters are a
> valuable piece of real estate.

Very very true.

>  However for floating point you
> need at least three letters because a floating point number has
> three parts: the fixed point point, the exponent base, and the
> exponent.  Now we can represent the radices of the individual
> parts with the 'r'scheme, e.g., 2r101001, but we need separate
> letters to designate the exponent base and the exponent.  B and E
> are the obvious choices, though we want to be careful about a
> confusion with 'b' in hex.  For example, using 'R',
>
> 3R20.1B2E16Rac

Ooh err!


> is 20.1 in trinary (6 1/3) times 2**172 (hex ac).
>
> I grant that this example looks a bit gobbledegookish,

You think? :-)

> but normal
> usage would be much simpler.  The notation doesn't handle
> balanced trinary; however I opine that balanced trinary requires
> special notation.

When the programmer needs to construct such values how about allowing
him or her to specify something like

  (20.1 in base 3) times 2 to the power of 0xac

Leaving out how to specify (20.1 in base 3) for now this could be

  (20.1 in base 3) * 2 ** 0xac

The compiler could convert this to a constant.

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[James Harris]

On 21 Aug, 00:59, James Harris  wrote:

...

> > Is there some magic to make the 2.x CPython interpreter to ignore the
> > annoying octal notation?
> > I'd really like 012 to be "12" and not "10".
>
> This is (IMHO) a sad hangover from C (which took it from B ...

This seemed worth writing up so I've taken the snipped comments and
posted them at

  http://sundry.wikispaces.com/octal-zero-prefix

The idea is that the page can be pointed to any time the issue comes
up again.

I've also fleshed the comments out a bit.

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[bartc]

 wrote in message 
news:h6r4fb$18...@aioe.org...

In comp.lang.python James Harris  wrote:

On 22 Aug, 10:27, David <71da...@libero.it> wrote:


...


What about 2_1011, 8_7621, 16_c26h or 2;1011, 8;7621, 16;c26h ?


They look good - which is important. The trouble (for me) is that I
want the notation for a new programming language and already use these
characters. I have underscore as an optional separator for groups of
digits - 123000 and 123_000 mean the same.


Why not just use the space? 123 000 looks better than 123_000, and
is not syntactically ambiguous (at least in python).


If the purpose is to allow "_" to introduce a non-base ten literal, using 
this to enter a hexadecimal number might result in:


16_1234 ABCD

I'd say that that was ambiguous (depending on whether a name can follow a 
number; if you have a operator called ABCD, then that would be a problem). 
Unless each block of digits used it's own base:


16_1234 16_ABCD



And as it
already works for string literals, it could be applied to numbers, too…


String literals are conveniently surround by quotes, so they're a bit easier 
to recognise.


--
Bart 


--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[J. Cliff Dyer]

I had an objection to using spaces in numeric literals last time around
and it still stands, and it still stands in the new one.

What happens if you use a literal like 0x10f 304?  Is 304 treated as
decimal or hexadecimal?  It's not clear how you would begin to combine
it   The way string concatenation works, it takes two independent string
literals, and combines them.  If you specify r'\n' 'abc\n', the first
half is treated independently as a raw string, and the second half is
treated as a normal string.  The result is '\\nabc\n'.

With numeric literals, this behavior doesn't even make sense.  How do
you concatenate hex 10f with decimal 304?  I suppose you could multiply
0x10f by 1000, and add them, but this probably wouldn't fit any
practical usecase.  

Alternatively, you could raise an exception, and require the user to use
numeric literals of the same type, like 0x10f 0x304, but then you lose
any readability benefit you might have gained by dropping the _ to begin
with.  

If, on the other hand, you want to combine the tokens before processing
their independent meanings, which makes the most intuitive sense, well,
in that case we're no longer talking about an operation analogous to
string contcatenation.  We're talking about integers no longer being
simple tokens that can be assigned a value.  I'm not familiar with the
code that makes all this happen in C Python (or any other implementation
for that matter), but it seems like it extends the complexity of the
parser unnecessarily. 

I'm concerned that the benefit in readability will be outweighed by the
burden it places on the parser, and the cognitive burden on the
programmer of knowing what to expect when using non-decimal numeric
literals.  For that reason, I'm a -1 on using a space in numeric
literals, but +1 on using some other separator, and an _, in spite of
its slight awkwardness in typing, seems like a good idea.

If someone with a solid understanding of the python parser could chime
in that this wouldn't cause as much friction as I think, and explain a
clean, elegant implementation for this, many of my concerns would be
alleviated, and I would change my -1 to a -0.

Cheers,
Cliff


On Mon, 2009-08-24 at 00:01 +1000, Ben Finney wrote:
> garabik-news-2005...@kassiopeia.juls.savba.sk writes:

> > Why not just use the space? 123 000 looks better than 123_000, and is
> > not syntactically ambiguous (at least in python). And as it already
> > works for string literals, it could be applied to numbers, too…
> 
> +1 to all this. I think this discussion was had many months ago, but
> can't recall how it ended back then.
> 
> -- 
>  \  “Only the educated are free.” —Epictetus, _Discourses_ |
>   `\   |
> _o__)  |
> Ben Finney

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Ben Finney]

garabik-news-2005...@kassiopeia.juls.savba.sk writes:

> Why not just use the space? 123 000 looks better than 123_000, and is
> not syntactically ambiguous (at least in python). And as it already
> works for string literals, it could be applied to numbers, too…

+1 to all this. I think this discussion was had many months ago, but
can't recall how it ended back then.

-- 
 \  “Only the educated are free.” —Epictetus, _Discourses_ |
  `\   |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Matthew Woodcraft]

Dennis Lee Bieber  writes:
>   About the only place one commonly sees leading zeros on decimal
> numbers, in my experience, is zero-filled COBOL data decks (and since
> classic COBOL stores in BCD anyway... binary (usage is
> computational/comp-1) was a later add-on to the data specification model
> as I recall...)

A more common case is dates.

I've seen people trip over this writing things like

xxx = [
date(2009, 10, 12),
date(2009, 12, 26),
date(2010, 02, 09),
]

-M-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[garabik-news-2005-05]

In comp.lang.python James Harris  wrote:
> On 22 Aug, 10:27, David <71da...@libero.it> wrote:

... 
>>
>> What about 2_1011, 8_7621, 16_c26h or 2;1011, 8;7621, 16;c26h ?
> 
> They look good - which is important. The trouble (for me) is that I
> want the notation for a new programming language and already use these
> characters. I have underscore as an optional separator for groups of
> digits - 123000 and 123_000 mean the same.

Why not just use the space? 123 000 looks better than 123_000, and 
is not syntactically ambiguous (at least in python). And as it
already works for string literals, it could be applied to numbers, too…

-- 
 ---
| Radovan Garabík http://kassiopeia.juls.savba.sk/~garabik/ |
| __..--^^^--..__garabik @ kassiopeia.juls.savba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Bearophile]

MRAB:

>'_': what if in the future we want to allow them in numbers for clarity?

Hettinger says it's hard (= requires too many changes) to do that and
Python programs don't have big integer constants often enough, so
probably that improvement will not see the light.

In the meantime in a Python program of mine I have put a small bug,
writing 100 instead of 1000. Now in Python I write
10*1000*1000, because I try to learn from my bugs. In D I enjoy
writing 10_000_000.

---

Steven D'Aprano:

> In D, at least some people want to follow Python's lead and either drop
> support for oct literals completely, or require a 0o 
> prefix:http://d.puremagic.com/issues/show_bug.cgi?id=2656

Yes, people in the D community are trying to improve things, but it's
a slow and painful process, and often it goes nowhere. There's lot of
politics.

Bye,
bearophile
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Dmitry A. Kazakov]

On Sat, 22 Aug 2009 14:54:41 -0700 (PDT), James Harris wrote:

> They look good - which is important. The trouble (for me) is that I
> want the notation for a new programming language and already use these
> characters. I have underscore as an optional separator for groups of
> digits - 123000 and 123_000 mean the same. The semicolon terminates a
> statement. Based on your second idea, though, maybe a colon could be
> used instead as in
> 
>   2:1011, 8:7621, 16:c26b
> 
> I don't (yet) use it as a range operator.
> 
> I could also use a hash sign as although I allow hash to begin
> comments it cannot be preceded by anything other than whitespace so
> these would be usable
> 
>   2#1011, 8#7621, 16#c26b
> 
> I have no idea why Ada which uses the # also apparently uses it to end
> a number
> 
>   2#1011#, 8#7621#, 16#c26b#

If you are going Unicode, you could use the mathematical notation, which is

   10112, 76218, c26b16

(subscript specification of the base). Yes, it might be difficult to type
(:-)), and would require some look-ahead in the parser. One of the
advantages of Ada notation, is that a numeric literal always starts with
decimal digit. That makes things simple for a descent recursive parser. I
guess this choice was intentional, back in 1983 a complex parser would eat
too much resources...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Steven D'Aprano]

On Sat, 22 Aug 2009 22:19:01 -0500, Derek Martin wrote:

> On Sat, Aug 22, 2009 at 02:55:51AM +, Steven D'Aprano wrote:
>> > I can see how 012 can
>> > be confusing to new programmers, but at least it's legible, and the
>> > great thing about humans is that they can be taught (usually).
>> 
>> And the great thing is that now you get to teach yourself to stop
>> writing octal numbers implicitly and be write them explicitly with a
>> leading 0o instead :)
> 
> Sorry, I don't write them implicitly.  A leading zero explicitly states
> that the numeric constant that follows is octal.

That is incorrect.

Decimal numbers implicitly use base 10, because there's nothing in the 
literal 12340 (say) to indicate the base is ten, rather than 16 or 9 or 
23. Although implicit is usually bad, when it's as common and expected as 
decimal notation, it's acceptable.

Hex decimals explicitly use base 16, because the leading 0x is defined to 
mean "base 16". 0x is otherwise not a legal decimal number, or hex number 
for that matter. (It would be legal in base 34 or greater, but that's 
rare enough that we can ignore this.) For the bases we care about, a 
leading 0x can't have any other meaning -- there's no ambiguity, so we 
can treat it as a synonym for "base 16".

(Explicitness isn't a binary state, and it would be even more explicit if 
the base was stated in full, as in e.g. Ada where 16#FF# = decimal 255.)

However, octal numbers are defined implicitly: 012 is a legal base 10 
number, or base 3, or base 9, or base 16. There's nothing about a leading 
zero that says "base 8" apart from familiarity. We can see the difference 
between leading 0x and leading 0 if you repeat it: repeating an explicit 
0x, as in 0x0xFF, is a syntax error, while repeating an implicit 0 
silently does nothing different:

>>> 0x0xFF
  File "", line 1
0x0xFF
 ^
SyntaxError: invalid syntax
>>> 0077
63


> It is so in 6 out of 7
> computer languages I have more than a passing familiarity with (the 7th
> being scheme, which is a thing unto itself), including Python.  It's
> that way on Bourne-compatible and POSIX-compatible Unix shells (though
> it requires a leading backslash before the leading zero there).  I'm
> quite certain it can not be the case on only those 6 languages that I
> happen to be familiar with...

No, of course not. There are a bunch of languages, pretty much all 
heavily influenced by C, which treat integer literals with leading 0s as 
oct: C++, Javascript, Python 2.x, Ruby, Perl, Java. As so often is the 
case, C's design mistakes become common practice. Sigh.

However, there are many, many languages that don't, or otherwise do 
things differently to C. Even some modern C-derived languages reject the 
convention:

C# doesn't have octal literals at all.

As far as I can tell, Objective-C and Cocoa requires you to explicitly 
enable support for octal literals before you use them.

In D, at least some people want to follow Python's lead and either drop 
support for oct literals completely, or require a 0o prefix:
http://d.puremagic.com/issues/show_bug.cgi?id=2656

E makes a leading 0 a syntax error.


As far as other, non-C languages go, leading 0 = octal seems to be rare 
or non-existent:

Basic and VB use a leading &O for octal.

FORTRAN 90 uses a leading O (uppercase o) for octal, and surrounds the 
literal in quotation marks: O"12" would be ten in octal. 012 would be 
decimal 12.

As far as I can tell, COBOL also ignores leading zeroes.

Forth interprets literals according to the current value of BASE (which 
defaults to 10). There's no special syntax for it.To enter ten in octal, 
you might say:

8 BASE ! 12

or if your system provides it:

OCT 12

Standard Pascal ignores leading 0s in integers, and doesn't support octal 
at all. A leading $ is used for hex. At least one non-standard Pascal 
uses leading zero for octal.

Haskell requires an explicit 0o:
http://www.haskell.org/onlinereport/lexemes.html#lexemes-numeric

So does OCaml.

Ada uses decimal unless you explicitly give the base:
http://archive.adaic.com/standards/83lrm/html/lrm-02-04.html

Leading zeroes are insignificant in bc:

[st...@sylar ~]$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
012 + 011
23

Leading zeroes are also insignificant in Hewlett-Packard RPN language 
(e.g. HP-48GX calculators), Hypertalk and languages derived from it.

I'm not sure, but it looks to me like Boo doesn't support octal literals, 
although it supports hex with 0x and binary with 0b.

Algol uses an explicit base: 8r12 to indicate octal 10.

Common Lisp and Scheme use a #o prefix.

As far as *languages* go, 0-based octal literals are in the tiny 
minority. As far as *programmers* go, it may be in a plurality, perhaps 
even a small minority, but remember there are still millions of VB 
programmers out there who are just as unfamiliar with C conventions.

> W

Re: Annoying octal notation

[Steven D'Aprano]

On Sat, 22 Aug 2009 14:04:17 -0500, Derek Martin wrote:

>> These human programmers, whether newbies or long-experienced, also deal
>> with decimal numbers every day, many of which are presented as a
>> sequence of digits with leading zeros — and we continue to think of
>> them as decimal numbers regardless. Having the language syntax opposed
>> to that is
>  
> ...consistent with virtually every other popular programming language.

A mistake is still a mistake even if it shared with others.

Treating its with a lead zero as octal was a design error when it was 
first thought up (possibly in C?) and it remains a design error no matter 
how many languages copy it. I feel your pain of having to unlearn 
something you have learned, but just because you have been lead astray by 
the languages you use doesn't mean we should compound the error by 
leading the next generation of coders astray too.

Octal is of little importance today, as near as I can tell it only has 
two common uses in high level languages: file umasks and permissions on 
Unix systems. It simply isn't special enough to justify implicit notation 
that surprises people, leads to silent errors, and is inconsistent with 
standard mathematical notation and treatment of floats:

>>> 123.2000 # insignificant trailing zeroes don't matter
123.2
>>> 000123.2 # neither do insignificant leading zeroes
123.2
>>> 001.23e0023  # not even if it is an integer
1.23e+23
>>> 000123  # but here is matters
83


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literals in other than base 10 - was Annoying octal notation

[Richard Harter]

On Sat, 22 Aug 2009 14:54:41 -0700 (PDT), James Harris
 wrote:

>On 22 Aug, 10:27, David <71da...@libero.it> wrote:
>
>... (snipped a discussion on languages and other systems interpreting
>numbers with a leading zero as octal)
>
>> > Either hexadecimal should have been 0h or octal should
>> > have been 0t :=3D)
>>
>>
>> I have seen the use of Q/q instead in order to make it clearer. I still
>> prefer Smalltalk's 16rFF and 8r377.
>>
>>
>> Two interesting options. In a project I have on I have also considered
>> using 0q as indicating octal. I maybe saw it used once somewhere else
>> but I have no idea where. 0t was a second choice and 0c third choice
>> (the other letters of oct). 0o should NOT be used for obvious reasons.
>>
>> So you are saying that Smalltalk has r where
>> r is presumably for radix? That's maybe best of all. It preserves the
>> syntactic requirement of starting a number with a digit and seems to
>> have greatest flexibility. Not sure how good it looks but it's
>> certainly not bad.

I opine that a letter is better; special characters are a
valuable piece of real estate.  However for floating point you
need at least three letters because a floating point number has
three parts: the fixed point point, the exponent base, and the
exponent.  Now we can represent the radices of the individual
parts with the 'r'scheme, e.g., 2r101001, but we need separate
letters to designate the exponent base and the exponent.  B and E
are the obvious choices, though we want to be careful about a
confusion with 'b' in hex.  For example, using 'R',

3R20.1B2E16Rac

is 20.1 in trinary (6 1/3) times 2**172 (hex ac).

I grant that this example looks a bit gobbledegookish, but normal
usage would be much simpler.  The notation doesn't handle
balanced trinary; however I opine that balanced trinary requires
special notation.

   
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
No one asks if a tree falls in the forest 
if there is no one there to see it fall.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Derek Martin]

On Fri, Aug 21, 2009 at 04:23:57PM -0700, James Harris wrote:
> You misunderstand. I was saying that taking a leading zero as
> indicating octal is archaic. Octal itself is fine where appropriate.

I don't see that the leading zero is any more archaic than the use of
octal itself...  Both originate from around the same time period, and
are used in the same cases.  We should just prohibit octal entirely
then.

But I suppose it depends on which definition of "archaic" you use.  In
the other common sense of the word, the leading zero is no more
archaic than the C programming language.  Let's ban the use of all
three. :)  (I believe C is still the language in which the largest
number of lines of new code are written, but if not, it's way up
there.)
 
> The chmod command doesn't require a leading zero.

No, but it doesn't need any indicator that the number given to it is
in octal; in the case of the command line tool, octal is *required*,
and the argument is *text*.  However, the chmod() system call, and the
interfaces to it in every language I'm familiar with that has one, do
require the leading zero (because that's how you represent octal).
Including Python, for some 20 years or so.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D



pgpf8DJDYdSjx.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Derek Martin]

On Sat, Aug 22, 2009 at 02:55:51AM +, Steven D'Aprano wrote:
> > I can see how 012 can
> > be confusing to new programmers, but at least it's legible, and the
> > great thing about humans is that they can be taught (usually).
> 
> And the great thing is that now you get to teach yourself to stop writing 
> octal numbers implicitly and be write them explicitly with a leading 0o 
> instead :)

Sorry, I don't write them implicitly.  A leading zero explicitly
states that the numeric constant that follows is octal.  It is so in 6
out of 7 computer languages I have more than a passing familiarity
with (the 7th being scheme, which is a thing unto itself), including
Python.  It's that way on Bourne-compatible and POSIX-compatible Unix
shells (though it requires a leading backslash before the leading zero
there).  I'm quite certain it can not be the case on only those 6
languages that I happen to be familiar with...

While it may be true that people commonly write decimal numbers with
leading zeros (I dispute even this, having to my recollection only
recently seen it as part of some serial number, which in practice is
really more of a string identifier than a number, often containing
characters other than numbers), it's also true that in the context of
computer programming languages, for the last 40+ years, a number
represented with a leading zero is most often an octal number.  This
has been true even in Python for nearly *twenty years*.  Why the
sudden need to change it?

So no, I don't get to teach myself to stop writing octal numbers with
a leading zero.  Instead, I have to remember an exception to the rule.

Also I don't think it's exactly uncommon for computer languages to do
things differently than they are done in non-CS circles.  A couple of
easy examples: we do not write x+=y except in computer languages.  The
POSIX system call to create a file is called creat().  If you think
about it, I'm sure you can come up with lots of examples where even
Python takes liberties.  Is this a bad thing?  Not inherently, no.
Will it be confusing to people who aren't familiar with the usage?
Quite possibly, but that is not inherently bad either.  It's all about
context.

> Use of octal isn't common. 

It's common enough.  Peruse the include files for your C libraries, or
the source for your operating system's kernel, or system libraries,
and I bet you'll find plenty of octal.  I did.  [Note that it is
irrelevant that these are C/C++ files; here we are only concerned with
whether they use octal, not how it is represented therein.]  I'd guess
there's a fair chance that any math or scientific software package
uses octal.  Octal is a convenient way to represent bit fields that
naturally occur in groups of 3, of which there are potentially
limitless cases.  

> You've given two cases were octal notation is useful, but for every
> coder who frequently writes umasks on Unix systems, there are a
> thousand who don't.

I gave two cases that I use *daily*, or very nearly daily.  My hats
currently include system admin, SQA, and software development, and I
find it convenient to use octal in each of those.  But those are
hardly the only places where octal is useful.  Have a look at the
ncurses library, for example.  Given that Python has an ncurses
interface, I'm guessing it's used there too.  In fact if the Python
source had no octal in it, I would find that very surprising.

> It's no hardship to write 0o12 instead of 012.

Computer languages are not write-only, excepting maybe Perl. ;-)
Writing 0o12 presents no hardship; but I assert, with at least some
support from others here, that *reading* it does.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D



pgp2DtXpzfNjd.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Carl Banks]

On Aug 21, 12:48 pm, Derek Martin  wrote:
> John Nagle wrote:
> > Yes, and making lead zeros an error as suggested in PEP 3127 is a
> > good idea.  It will be interesting to see what bugs that flushes
> > out.
> James Harris wrote:
> > It maybe made sense once but this relic of the past should have been
> > consigned to the waste bin of history long ago.
>
> Sigh.  Nonsense.  I use octal notation *every day*, for two extremely
> prevalent purposes: file creation umask, and Unix file permissions
> (i.e. the chmod() function/command).

Unix file permissions maybe made sense once but this relic of the past
should have been consigned to the waste bin of history long ago.  :)


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Annoying octal notation

[Carl Banks]

On Aug 22, 12:04 pm, Derek Martin  wrote:
> On Sat, Aug 22, 2009 at 10:03:35AM +1000, Ben Finney wrote:
> > These human programmers, whether newbies or long-experienced, also deal
> > with decimal numbers every day, many of which are presented as a
> > sequence of digits with leading zeros — and we continue to think of them
> > as decimal numbers regardless. Having the language syntax opposed to
> > that is
>
> ...consistent with virtually every other popular programming language.


If you know anything about Python, you should know that "consistent
with virtually every other programming langauge" is, at most, a polite
suggestion for how Python should do it.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list