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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: Numeric literals in other than base 10 - was Annoying octal notation

[Mel]

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 
:

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 .


Mel.

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

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

[James Harris]

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 :=)
>
>
> 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.
>
>
> >   0xff & 0x0e | 0b1101
> >   16rff & 16r0e | 2r1101
>
> > Hmm. Maybe a symbol would be better than a letter.

...

> >Or Ada's16#FF#, 8#377#...

> >I forget if DEC/VMS FORTRAN or Xerox Sigma FORTRAN used x'FF' or
> >   'FF'x, and o'377' or '377'o

...

>
> 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. 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#

Copying this post also to comp.lang.misc. Folks there may either be
interested in the discussion or have comments to add.

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