I would like to add a "%b" format for converting numbers to binary format (1's and 0's). I realize this isn't a C-ism, but it would be very useful for teaching purposes, as newcomers find 101101 a lot easier to understand than 0x2D.
Reactions?
Greg
The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on.
In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses.
Greg Wilson Greg.Wilson@baltimore.com:
I would like to add a "%b" format for converting numbers to binary format (1's and 0's). I realize this isn't a C-ism, but it would be very useful for teaching purposes, as newcomers find 101101 a lot easier to understand than 0x2D.
Reactions?
Where rights secured by the Constitution are involved, there can be no rule making or legislation which would abrogate them. -- Miranda vs. Arizona, 384 US 436 p. 491
"Eric S. Raymond" wrote:
Greg Wilson Greg.Wilson@baltimore.com:
I would like to add a "%b" format for converting numbers to binary format (1's and 0's). I realize this isn't a C-ism, but it would be very useful for teaching purposes, as newcomers find 101101 a lot easier to understand than 0x2D.
Reactions?
Good idea. The only question I have is: in which order will you print the 0s and 1s (MSB->LSB, LSB->MSB, little/big endian) ?
I am thinking of adding a bit field type to mxNumber and have the same problem there...
-- Marc-Andre Lemburg CEO eGenix.com Software GmbH
Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
M.-A. Lemburg mal@lemburg.com:
I would like to add a "%b" format for converting numbers to binary format (1's and 0's). I realize this isn't a C-ism, but it would be very useful for teaching purposes, as newcomers find 101101 a lot easier to understand than 0x2D.
Good idea. The only question I have is: in which order will you print the 0s and 1s (MSB->LSB, LSB->MSB, little/big endian) ?
I am thinking of adding a bit field type to mxNumber and have the same problem there...
For this context, we clearly want mathematical notation; MSB to the right and no byte-swapping. After all we'd actually be printing numerals, not
dumping a bitfield.
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The people of the various provinces are strictly forbidden to have in their possession any swords, short swords, bows, spears, firearms, or other types of arms. The possession of unnecessary implements makes difficult the collection of taxes and dues and tends to foment uprisings. -- Toyotomi Hideyoshi, dictator of Japan, August 1588
[Greg Wilson]
I would like to add a "%b" format for converting numbers to binary format (1's and 0's).
-0, due to compound lumpiness: hex() is to %x is to __hex__ as oct() is to %o is to __oct__ as nothing is to %b is to nothing. In that respect it's unfortunate that Python has distinct nb_oct and nb_hex slots in the PyNumberMethods struct (as opposed to a single parameterized "convert to base N string" method).
[MAL]
Good idea. The only question I have is: in which order will you print the 0s and 1s (MSB->LSB, LSB->MSB, little/big endian) ?
I'm sure Greg has in mind only integers, in which case %x and %o already give the only useful <wink> answer.
Tim Peters tim.one@home.com:
-0, due to compound lumpiness: hex() is to %x is to __hex__ as oct() is to %o is to __oct__ as nothing is to %b is to nothing. In that respect it's unfortunate that Python has distinct nb_oct and nb_hex slots in the PyNumberMethods struct (as opposed to a single parameterized "convert to base N string" method).
Is the right answer to add the convert-to-base slot and deprecate the
other two?
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
If gun laws in fact worked, the sponsors of this type of legislation should have no difficulty drawing upon long lists of examples of criminal acts reduced by such legislation. That they cannot do so after a century and a half of trying -- that they must sweep under the rug the southern attempts at gun control in the 1870-1910 period, the northeastern attempts in the 1920-1939 period, the attempts at both Federal and State levels in 1965-1976 -- establishes the repeated, complete and inevitable failure of gun laws to control serious crime. -- Senator Orrin Hatch, in a 1982 Senate Report
[Eric S. Raymond]
Is the right answer to add the convert-to-base slot and deprecate the other two?
That would fix "the other" lump here in Python, that e.g.
int("111", 3) 13
has no inverse. string->int is happy with any base in 2..36 inclusive, but int->string is spelled via 3 different builtins covering only 3 of those bases.
It would be more expedient to add "just" a __bin__/nb_bin method + a way to spell binary int literals + a %b format + a bin() builtin.
On the fifth hand, I doubt anyone would want to add new % format codes for bases {2..36} - {2, 8, 10, 16}.
So it will remain lumpy no matter what. I look forward to the PEP <wink>.
Tim Peters tim.one@home.com:
[Eric S. Raymond]
Is the right answer to add the convert-to-base slot and deprecate the other two?
That would fix "the other" lump here in Python, that e.g.
int("111", 3) 13
has no inverse. string->int is happy with any base in 2..36 inclusive, but int->string is spelled via 3 different builtins covering only 3 of those bases.
That sounds like a strong argument to me.
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The world is filled with violence. Because criminals carry guns, we decent law-abiding citizens should also have guns. Otherwise they will win and the decent people will lose. -- James Earl Jones
Tim:
On the fifth hand, I doubt anyone would want to add new % format codes for bases {2..36} - {2, 8, 10, 16}.
So, just add one general one:
%m.nb
with n being the base. If n defaults to 2, you can read the "b" as either "base" or "binary".
Literals:
0b(5)21403 general 0b11001101 binary
Conversion functions:
base(x, n) general bin(x) equivalent to base(x, 2) (for symmetry with existing hex, oct)
Type slots:
__base__(x, n)
Backwards compatibility measures:
hex(x) --> base(x, 16) oct(x) --> base(x, 8) bin(x) --> base(x, 2)
base(x, n) checks __hex__ and __oct__ slots for special cases of n=16 and n=8, falls back on __base__
There, that takes care of integers. Anyone want to do the equivalent for floats ?-)
Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Greg Ewing greg@cosc.canterbury.ac.nz:
So, just add one general one:
%m.nb
with n being the base. If n defaults to 2, you can read the "b" as either "base" or "binary".
I had a similar idea, but your version is more elegant.
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The common argument that crime is caused by poverty is a kind of slander on the poor. -- H. L. Mencken
[Greg Ewing]
So, just add one general one:
%m.nb
with n being the base. If n defaults to 2, you can read the "b" as either "base" or "binary".
Except .n has a different meaning already for integer conversions:
"%.5d" % 2 '00002' "%.10o" % 377 '0000000571'
It would be inconsistent to hijack it to mean something else here.
Literals:
0b(5)21403 general
I've actually got no use for bases outside {2, 8, 10, 16), and have never heard a request for them either, so I'd be at best -0. Better to stop documenting the full truth about int() <0.9 wink>.
0b11001101 binary
+1.
Conversion functions:
base(x, n) general
-0, as above.
bin(x) equivalent to base(x, 2) (for symmetry with existing hex, oct)
+1 if binary literals are added.
Type slots:
__base__(x, n)
Given the tenor of the above, add __bin__ and call it a day.
Backwards compatibility measures:
hex(x) --> base(x, 16) oct(x) --> base(x, 8) bin(x) --> base(x, 2)
base(x, n) checks __hex__ and __oct__ slots for special cases of n=16 and n=8, falls back on __base__
There, that takes care of integers. Anyone want to do the equivalent for floats ?-)
Note that C99 introduces a hex notation for floats.
"GW" == Greg Wilson Greg.Wilson@baltimore.com writes:
GW> I would like to add a "%b" format for
converting numbers to
GW> binary format (1's and 0's).
For completeness, wouldn't you also want a binary integer literal so your students could write binary numbers in their code? And what about a binary() operator a la hex()?
-Barry
Barry A. Warsaw barry@digicool.com:
"GW" == Greg Wilson Greg.Wilson@baltimore.com writes:
GW> I would like to add a "%b" format for
converting numbers to
GW> binary format (1's and 0's).
For completeness, wouldn't you also want a binary integer literal so your students could write binary numbers in their code? And what about a binary() operator a la hex()?
Barry is correct. If we're going to do this, we ought to do it right and
support binary on a par with decimal, hex, and octal. I favor this.
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The direct use of physical force is so poor a solution to the problem of limited resources that it is commonly employed only by small children and great nations. -- David Friedman
Note that in Vyper (John Skaller's Python variant) these are legit integer literals:
0b11111111 0B11111111 0o777 0O777 0d999 0D999 0xfFf 0XFFf
Vyper's octal notation is still ugly, but whoever first thought
0777 != 777
was a "good idea" was certifiably insane <0.25 wink>.
Tim Peters tim.one@home.com:
Vyper's octal notation is still ugly, but whoever first thought
0777 != 777
was a "good idea" was certifiably insane <0.25 wink>.
For anyone who doesn't know the history behind this...
The 0xxx notation was copied from PDP-11 assembler literals -- the instruction-set design of the PDP-11 was such that most of the instruction subfields fit in octal digits, so this convention made it somewhat easier to read machine-code dumps.
While I'm at it, I should note that the design of the 11 was ancestral to both the 8088 and 68000 microprocessors, and thus to essentially
every new general-purpose computer designed in the last fifteen years.
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Are we to understand," asked the judge, "that you hold your own interests above the interests of the public?"
"I hold that such a question can never arise except in a society of cannibals." -- Ayn Rand
[ESR]
The 0xxx notation was copied from PDP-11 assembler literals -- the instruction-set design of the PDP-11 was such that most of the instruction subfields fit in octal digits, so this convention made it somewhat easier to read machine-code dumps.
That doesn't mean they weren't certifiably insane. At Cray, we had a much more sensible convention: all numbers were octal (yes, it was a 64-bit box and octal didn't make any sense, but Seymour Cray got used to it from the 60-bit CDC w/ 18-bit address registers and didn't feel like changing). My first boss there loved telling the story about he was out for a drive with the family, and excitedly screamed "Hey, kids! Look! The odometer is just about to change to 40,000!". Of course it read 37,777.9 at the time, and they thought he was nuts. That's where this kind of thing always leads in the end.
to-disgrace-despair-and-eventually-ruin-ly y'rs - tim
Eric wrote:
While I'm at it, I should note that the design of the 11 was ancestral to both the 8088 and 68000 microprocessors, and thus to essentially every new general-purpose computer designed in the last fifteen years.
The key to PDP-11 and VAX was lots of registers all a like and rich addressing modes for the instructions.
The 8088 is very far from this design, its owes its design more to 4004 then the PDP-11.
However the 68000 is the closer, but not as nice to program as there are too many special cases in its instruction set for my liking.
BArry
Barry Scott barry@scottb.demon.co.uk:
Eric wrote:
While I'm at it, I should note that the design of the 11 was ancestral to both the 8088 and 68000 microprocessors, and thus to essentially every new general-purpose computer designed in the last fifteen years.
The key to PDP-11 and VAX was lots of registers all a like and rich addressing modes for the instructions.
The 8088 is very far from this design, its owes its design more to 4004 then the PDP-11.
Yes, but the 4004 was designed as a sort of lobotomized imitation of the 65xx, which was descended from the 11. Admiitedly, in the chain of transmission here
were two stages of redesign so bad that the connection got really tenuous.
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
...Virtually never are murderers the ordinary, law-abiding people against whom gun bans are aimed. Almost without exception, murderers are extreme aberrants with lifelong histories of crime, substance abuse, psychopathology, mental retardation and/or irrational violence against those around them, as well as other hazardous behavior, e.g., automobile and gun accidents." -- Don B. Kates, writing on statistical patterns in gun crime
Eric> Yes, but the 4004 was designed as a sort of lobotomized imitation
Eric> of the 65xx, which was descended from the 11.
Really? I was always under the impression the 4004 was considered the first microprocessor. The page below says that and gives a date of 1971 for it. I have no idea if the author is correct, just that what he says agrees with my memory. He does seem to have an impressive collection of old computer iron:
http://www.piercefuller.com/collect/i4004/
I haven't found a statement about the origins of the 6502, but this page suggests that commercial computers were being made from 8080's before 6502's:
http://www.speer.org/2backup/pcbs_pch.html
Ah, wait a minute... This page:
http://www.geocities.com/SiliconValley/Byte/6508/6502/english/versoes.htm
says the 6502 was descended from the 6800. I'm getting less and less convinced that the 4004 somehow descended from the 65xx family.
(Maybe we should shift this thread to the always entertaining folks at comp.arch... ;-)
Skip
Skip Montanaro skip@pobox.com:
Really? I was always under the impression the 4004 was considered the first microprocessor. The page below says that and gives a date of 1971 for it.
First sentence is widely believed, but there was an earlier micro called the Star-8 designed at Burroughs that has been almost completely forgotten. I only know about it because I worked there in 1980 with one of the people who designed it.
I think I had a brain fart and it's the Z80 that was descended from the 6502. I was going by a remark in some old lecture notes. I've got a copy of the definitive reference on history of computer
architecture and will check.
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Extremism in the defense of liberty is no vice; moderation in the pursuit of justice is no virtue." -- Barry Goldwater (actually written by Karl Hess)
Eric> Skip Montanaro <skip@pobox.com>:
>> Really? I was always under the impression the 4004 was considered
>> the first microprocessor. The page below says that and gives a date
>> of 1971 for it.
Eric> First sentence is widely believed, but there was an earlier micro
Eric> called the Star-8 designed at Burroughs that has been almost
Eric> completely forgotten.
There was also a GE-8 (I think that was the name) developed at GE's R&D Center in the early 1970's timeframe - long before my time there. It was apparently very competitive with the other microprocessors produced about that time but never saw the light of day. I suspect that was at least due in part to the fact that GE built mainframes back then.
Skip
Eric, As others have pointed out your time line is wrong...
BArry
p.s. I'm ex-DEC and old enough to have seen the introduction of the 6502 (got mine at university for $25 inc postage to the U.K.), Z80 and VAX (worked on product for V1.0 of VMS). Also for my sins argued with Gordon Bell and Dave Cutler about CPU architecture.
-----Original Message----- From: Eric S. Raymond [mailto:esr@thyrsus.com] Sent: 04 June 2001 21:11 To: Barry Scott Cc: python-dev (E-mail) Subject: Re: [Python-Dev] %b format? - 8088 like a PDP-11 I think not...
Barry Scott barry@scottb.demon.co.uk:
Eric wrote:
While I'm at it, I should note that the design of the 11 was ancestral to both the 8088 and 68000 microprocessors, and thus to essentially every new general-purpose computer designed in the last fifteen years.
The key to PDP-11 and VAX was lots of registers all a like and rich addressing modes for the instructions.
The 8088 is very far from this design, its owes its design more to 4004 then the PDP-11.
Yes, but the 4004 was designed as a sort of lobotomized imitation of the 65xx, which was descended from the 11. Admiitedly, in the chain of transmission here
were two stages of redesign so bad that the connection got really tenuous.
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
...Virtually never are murderers the ordinary, law-abiding people against whom gun bans are aimed. Almost without exception, murderers are extreme aberrants with lifelong histories of crime, substance abuse, psychopathology, mental retardation and/or irrational violence against those around them, as well as other hazardous behavior, e.g., automobile and gun accidents." -- Don B. Kates, writing on statistical patterns in gun crime
-
Barry Scott -
barry＠digicool.com -
Eric S. Raymond -
Greg Ewing -
Greg Wilson -
M.-A. Lemburg -
Neil Schemenauer -
Skip Montanaro -
Tim Peters -
Tim Peters