Re: Numeric literals in other than base 10 - was Annoying octal notation
On Aug 26, 4:59 pm, Piet van Oostrum p...@cs.uu.nl wrote: Mensanator mensana...@aol.com (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 p...@cs.uu.nl 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
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 mensana...@aol.com (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 p...@cs.uu.nl 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 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
On Aug 26, 10:27 pm, Steven D'Aprano st...@remove-this- cybersource.com.au 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 snip 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
Mensanator mensana...@aol.com (M) wrote: M On Aug 26, 4:59 pm, Piet van Oostrum p...@cs.uu.nl wrote: Mensanator mensana...@aol.com (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 p...@cs.uu.nl 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
On Aug 27, 2:26 pm, Piet van Oostrum p...@cs.uu.nl wrote: Mensanator mensana...@aol.com (M) wrote: M On Aug 26, 4:59 pm, Piet van Oostrum p...@cs.uu.nl wrote: Mensanator mensana...@aol.com (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 p...@cs.uu.nl 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
On Tue, 25 Aug 2009 11:45:28 -0700, Mensanator wrote: On Aug 25, 9:14 am, Steven D'Aprano st...@remove-this- 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
On Aug 26, 9:58 am, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: On Tue, 25 Aug 2009 11:45:28 -0700, Mensanator wrote: On Aug 25, 9:14 am, Steven D'Aprano st...@remove-this- 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
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
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 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
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 +numberscd=18hl=enct=clnkgl=ukie=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
On 25 Aug, 01:25, Steven D'Aprano st...@remove-this-
cybersource.com.au 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
32rst 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
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
On Aug 25, 9:14 am, Steven D'Aprano st...@remove-this-
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:
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
On 24 Aug, 03:49, Dennis Lee Bieber wlfr...@ix.netcom.com 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 G) 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: digitsradix 01110b 123d (of course, just 123 would be allowed for simplicity) 7Cx 327o 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 radixdigits 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 radixdigits you could have 0radixdigits. 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 0radixdigits 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 radixdigits where radix is numeric: So 21101 or 3122? (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
Scott David Daniels scott.dani...@acm.org (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 p...@cs.uu.nl 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
MRAB wrote: James Harris wrote: On 23 Aug, 00:16, Mel mwil...@the-wire.com 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 http://archive.adaic.com/standards/83rat/html/ratl-02-01.html#2.1: 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 02:1011, 08:7621, 016:c26b Why not just put the base first, followed by the value in quotes: 21011, 87621, 16c26b 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 radixrvalue (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
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
On 24 Aug, 02:19, Max Erickson maxerick...@gmail.com 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
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
On 24 Aug, 09:05, Erik Max Francis m...@alcyone.com 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 02:1011, 08:7621, 016:c26b Why not just put the base first, followed by the value in quotes: 21011, 87621, 16c26b 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
James Harris wrote: On 24 Aug, 09:05, Erik Max Francis m...@alcyone.com 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 02:1011, 08:7621, 016:c26b Why not just put the base first, followed by the value in quotes: 21011, 87621, 16c26b 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 wrote:
On 24 Aug, 02:19, Max Erickson maxerick...@gmail.com 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
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
On 24 Aug, 09:30, Erik Max Francis m...@alcyone.com wrote: James Harris wrote: On 24 Aug, 09:05, Erik Max Francis m...@alcyone.com 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 02:1011, 08:7621, 016:c26b Why not just put the base first, followed by the value in quotes: 21011, 87621, 16c26b 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: Literal concatenation, strings vs. numbers (was: Numeric literals in other than base 10 - was Annoying octal notation)
On Aug 23, 7:45 pm, Ben Finney ben+pyt...@benfinney.id.au wrote: greg g...@cosc.canterbury.ac.nz 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' ughi '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
On Aug 23, 9:42 pm, James Harris james.harri...@googlemail.com
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 stdio.h
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: Numeric literals in other than base 10 - was Annoying octal notation
James Harris wrote:
On 24 Aug, 02:19, Max Erickson maxerick...@gmail.com 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
J. Cliff Dyer j...@sdf.lonestar.org 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: Literal concatenation, strings vs. numbers (was: Numeric literals in other than base 10 - was Annoying octal notation)
On Mon, 24 Aug 2009 12:45:25 +1000, Ben Finney wrote: greg g...@cosc.canterbury.ac.nz 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' ughi '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
Piet van Oostrum wrote: Scott David Daniels scott.dani...@acm.org (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: Numeric literals in other than base 10 - was Annoying octal notation
On 24 Aug, 14:05, Mel mwil...@the-wire.com wrote:
James Harris wrote:
On 24 Aug, 02:19, Max Erickson maxerick...@gmail.com 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 32rst 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
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
32rst 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
On Aug 24, 7:25 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au 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
32rst 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
On Aug 24, 8:21�pm, Mel mwil...@the-wire.com 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
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 1011sub2/sub, 7621sub8/sub, c26bsub16/sub (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
In comp.lang.python James Harris james.harri...@googlemail.com 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
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
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
garabik-news-2005...@kassiopeia.juls.savba.sk wrote in message news:h6r4fb$18...@aioe.org... In comp.lang.python James Harris james.harri...@googlemail.com 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
On 23 Aug, 04:38, c...@tiac.net (Richard Harter) wrote: On Sat, 22 Aug 2009 14:54:41 -0700 (PDT), James Harris james.harri...@googlemail.com 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 base in decimalrnumber 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
On 23 Aug, 00:16, Mel mwil...@the-wire.com 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 http://archive.adaic.com/standards/83rat/html/ratl-02-01.html#2.1: 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 02:1011, 08:7621, 016: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
On 23 Aug, 21:55, James Harris james.harri...@googlemail.com 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 wrote: On 23 Aug, 00:16, Mel mwil...@the-wire.com 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 http://archive.adaic.com/standards/83rat/html/ratl-02-01.html#2.1: 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 02:1011, 08:7621, 016:c26b Why not just put the base first, followed by the value in quotes: 21011, 87621, 16c26b 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 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
Scott David Daniels scott.dani...@acm.org 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
bartc ba...@freeuk.com wrote:
Scott David Daniels scott.dani...@acm.org 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
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 maxerick...@gmail.com 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
Literal concatenation, strings vs. numbers (was: Numeric literals in other than base 10 - was Annoying octal notation)
greg g...@cosc.canterbury.ac.nz 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' ughi '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
Numeric literals in other than base 10 - was Annoying octal notation
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 base in decimalrnumber 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
Re: Numeric literals in other than base 10 - was Annoying octal notation
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 http://archive.adaic.com/standards/83rat/html/ratl-02-01.html#2.1: 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
Re: Numeric literals in other than base 10 - was Annoying octal notation
On Sat, 22 Aug 2009 14:54:41 -0700 (PDT), James Harris james.harri...@googlemail.com 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 base in decimalrnumber 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
