Wednesday, October 08, 2008
found on a phd thesis
Saturday, September 27, 2008
Left Leaning Balanced Trees
http://www.cs.princeton.edu/~rs/talks/LLRB/RedBlack.pdf
Author: Robert Sedgewick
Thursday, September 04, 2008
Thursday, August 21, 2008
song of the day
Nobody feels any pain
Tonight as I stand inside the rain
Ev'rybody knows
That Baby's got new clothes
But lately I see her ribbons and her bows
Have fallen from her curls.
She takes just like a woman, yes, she does
She makes love just like a woman, yes, she does
And she aches just like a woman
But she breaks just like a little girl.
Queen Mary, she's my friend
Yes, I believe I'll go see her again
Nobody has to guess
That Baby can't be blessed
Till she sees finally that she's like all the rest
With her fog, her amphetamine and her pearls.
She takes just like a woman, yes, she does
She makes love just like a woman, yes, she does
And she aches just like a woman
But she breaks just like a little girl.
It was raining from the first
And I was dying there of thirst
So I came in here
And your long-time curse hurts
But what's worse
Is this pain in here
I can't stay in here
Ain't it clear that--
I just can't fit
Yes, I believe it's time for us to quit
When we meet again
Introduced as friends
Please don't let on that you knew me when
I was hungry and it was your world.
Ah, you fake just like a woman, yes, you do
You make love just like a woman, yes, you do
Then you ache just like a woman
But you break just like a little girl.
pandora.com really work?
I created a station for Led-Zep, hoping for the good and guess what played on fourth song: Tom Petty. Where is the connection?
Sunday, August 17, 2008
Alan Peril
EPIGRAMS IN PROGRAMMING
1. One man's constant is another man's variable.
2. Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process.
3. Syntactic sugar causes cancer of the semicolon.
4. Every program is a part of some other program and rarely fits.
5. If a program manipulates a large amount of data, it does so in a small number of ways.
6. Symmetry is a complexity-reducing concept (co-routines include subroutines); seek it everywhere.
7. It is easier to write an incorrect program than understand a correct one.
8. A programming language is low level when its programs require attention to the irrelevant.
9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.
10. Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.
11. If you have a procedure with ten parameters, you probably missed some.
12. Recursion is the root of computation since it trades description for time.
13. If two people write exactly the same program, each should be put into microcode and then they certainly won't be the same.
14. In the long run every program becomes rococo - then rubble.
15. Everything should be built top-down, except the first time.
16. Every program has (at least) two purposes: the one for which it was written, and another for which it wasn't.
17. If a listener nods his head when you're explaining your program, wake him up.
18. A program without a loop and a structured variable isn't worth writing.
19. A language that doesn't affect the way you think about programming, is not worth knowing.
20. Wherever there is modularity there is the potential for misunderstanding: Hiding information implies a need to check communication.
21. Optimization hinders evolution.
22. A good system can't have a weak command language.
23. To understand a program you must become both the machine and the program.
24. Perhaps if we wrote programs from childhood on, as adults we'd be able to read them.
25. One can only display complex information in the mind. Like seeing, movement or flow or alteration of view is more important than the static picture, no matter how lovely.
26. There will always be things we wish to say in our programs that in all known languages can only be said poorly.
27. Once you understand how to write a program get someone else to write it.
28. Around computers it is difficult to find the correct unit of time to measure progress. Some cathedrals took a century to complete. Can you imagine the grandeur and scope of a program that would take as long?
29. For systems, the analogue of a face-lift is to add to the control graph an edge that creates a cycle, not just an additional node.
30. In programming, everything we do is a special case of something more general -- and often we know it too quickly.
31. Simplicity does not precede complexity, but follows it.
32. Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis.
33. The eleventh commandment was "Thou Shalt Compute" or "Thou Shalt Not Compute" - I forget which.
34. The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information.
35. Everyone can be taught to sculpt: Michelangelo would have had to be taught not to. So it is with great programmers.
36. The use of a program to prove the 4-color theorem will not change mathematics - it merely demonstrates that the theorem, a challenge for a century, is probably not important to mathematics.
37. The most important computer is the one that rages in our skulls and ever seeks that satisfactory external emulator. The standarization of real computers would be a disaster - and so it probably won't happen.
38. Structured Programming supports the law of the excluded middle.
39. Re graphics: A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures.
40. There are two ways to write error-free programs; only the third one works.
41. Some programming languages manage to absorb change, but withstand progress.
42. You can measure a programmer's perspective by noting his attitude on the continuing vitality of FORTRAN.
43. In software systems, it is often the early bird that makes the worm.
44.Sometimes I think the only universal in the computing field is the fetch-execute cycle.
45. The goal of computation is the emulation of our synthetic abilities, not the understanding of our analytic ones.
46. Like punning, programming is a play on words.
47. As Will Rogers would have said, "There is no such thing as a free variable."
48. The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book on anything for the layman.
49. Giving up on assembly language was the apple in our Garden of Eden: Languages whose use squanders machine cycles are sinful. The LISP machine now permits LISP programmers to abandon bra and fig-leaf.
50. When we understand knowledge-based systems, it will be as before -- except our fingertips will have been singed.
51. Bringing computers into the home won't change either one, but may revitalize the corner saloon.
52. Systems have sub-systems and sub-systems have sub- systems and so on ad infinitum - which is why we're always starting over.
53. So many good ideas are never heard from again once they embark in a voyage on the semantic gulf.
54. Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.
55. A LISP programmer knows the value of everything, but the cost of nothing.
56. Software is under a constant tension. Being symbolic it is arbitrarily perfectible; but also it is arbitrarily changeable.
57. It is easier to change the specification to fit the program than vice versa.
58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.
59. In English every word can be verbed. Would that it were so in our programming languages.
60. In seeking the unattainable, simplicity only gets in the way.
61. In programming, as in everything else, to be in error is to be reborn.
62. In computing, invariants are ephemeral.
63. When we write programs that "learn", it turns out that we do and they don't.
64. Often it is the means that justify the ends: Goals advance technique and technique survives even when goal structures crumble.
65. Make no mistake about it: Computers process numbers - not symbols. We measure our understanding (and control) by the extent to which we can arithmetize an activity.
66. Making something variable is easy. Controlling duration of constancy is the trick.
67. Think of all the psychic energy expended in seeking a fundamental distinction between "algorithm" and "program".
68. If we believe in data structures, we must believe in independent (hence simultaneous) processing. For why else would we collect items within a structure? Why do we tolerate languages that give us the one without the other?
69. In a 5 year period we get one superb programming language. Only we can't control when the 5 year period will be.
70. Over the centuries the Indians developed sign language for communicating phenomena of interest. Programmers from different tribes (FORTRAN, LISP, ALGOL, SNOBOL, etc.) could use one that doesn't require them to carry a blackboard on their ponies.
71. Documentation is like term insurance: It satisfies because almost no one who subscribes to it depends on its benefits.
72. An adequate bootstrap is a contradiction in terms.
73. It is not a language's weakness but its strengths that control the gradient of its change: Alas, a language never escapes its embryonic sac.
74. Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to see it as a soap bubble?
75. Because of its vitality, the computing field is always in desperate need of new cliches: Banality soothes our nerves.
76. It is the user who should parameterize procedures, not their creators.
77. The cybernetic exchange between man, computer and algorithm is like a game of musical chairs: The frantic search for balance always leaves one of the three standing ill at ease.
78. If your computer speaks English, it was probably made in Japan.
79. A year spent in artificial intelligence is enough to make one believe in God.
80. Prolonged contact with the computer turns mathematicians into clerks and vice versa.
81. In computing, turning the obvious into the useful is a living definition of the word "frustration".
82. We are on the verge: Today our program proved Fermat's next-to-last theorem.
83. What is the difference between a Turing machine and the modern computer? It's the same as that between Hillary's ascent of Everest and the establishment of a Hilton hotel on its peak.
84. Motto for a research laboratory: What we work on today, others will first think of tomorrow.
85. Though the Chinese should adore APL, it's FORTRAN they put their money on.
86. We kid ourselves if we think that the ratio of procedure to data in an active data-base system can be made arbitrarily small or even kept small.
87. We have the mini and the micro computer. In what semantic niche would the pico computer fall?
88. It is not the computer's fault that Maxwell's equations are not adequate to design the electric motor.
89. One does not learn computing by using a hand calculator, but one can forget arithmetic.
90. Computation has made the tree flower.
91. The computer reminds one of Lon Chaney -- it is the machine of a thousand faces.
92. The computer is the ultimate polluter: its feces are indistinguish- able from the food it produces.
93. When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
94. Interfaces keep things tidy, but don't accelerate growth: Functions do.
95. Don't have good ideas if you aren't willing to be responsible for them.
96. Computers don't introduce order anywhere as much as they expose opportunities.
97. When a professor insists computer science is X but not Y, have compassion for his graduate students.
98. In computing, the mean time to failure keeps getting shorter.
99. In man-machine symbiosis, it is man who must adjust: The machines can't.
100. We will never run out of things to program as long as there is a single program around.
101. Dealing with failure is easy: Work hard to improve. Success is also easy to handle: You've solved the wrong problem. Work hard to improve.
102. One can't proceed from the informal to the formal by formal means.
103. Purely applicative languages are poorly applicable.
104. The proof of a system's value is its existence.
105. You can't communicate complexity, only an awareness of it.
106. It's difficult to extract sense from strings, but they're the only communication coin we can count on.
107. The debate rages on: is PL/I Bachtrian or Dromedary?
108. Whenever two programmers meet to criticize their programs, both are silent.
109. Think of it! With VLSI we can pack 100 ENIACS in 1 sq. cm.
110. Editing is a rewording activity.
111. Why did the Roman Empire collapse? What is Latin for office automation?
112. Computer Science is embarrassed by the computer.
113. The only constructive theory connecting neuroscience and psychology will arise from the study of software.
114. Within a computer natural language is unnatural.
115. Most people find the concept of programming obvious, but the doing impossible.
116. You think you know when you can learn, are more sure when you can write, even more when you can teach, but certain when you can program.
117. It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organizing thoughts, devoting attention to detail and learning to be self-critical?
118. If you can imagine a society in which the computer- robot is the only menial, you can imagine anything.
119. Programming is an unnatural act.
120. Adapting old programs to fit new machines usually means adapting new machines to behave like old ones.
Saturday, August 09, 2008
meaning of "powerful API"
Here is my interpretation of when I see "This language provides powerful API for this feature"
What does it mean: The language provides a rather long, non-intuitive, and most likely unusable set of APIs for this feature.
Try it yourself!
Sunday, July 27, 2008
Thursday, July 10, 2008
trends and search results vary?
Wednesday, July 02, 2008
Inflation
Amazing, how it can be so similar every year. Ofcourse, your opinion is as good as mine.
Saturday, May 17, 2008
Published by the Washington Post
When we were the Sick Man of Asia, We were called The Yellow Peril.
When we are billed to be the next Superpower, we are called The Threat.
When we closed our doors, you smuggled drugs to open markets.
When we embrace Free Trade, You blame us for taking away your jobs.
When we were falling apart, You marched in your troops and wanted your fair
share.
When we tried to put the broken pieces back together again, Free Tibet you
screamed, It Was an Invasion!
When tried Communism, you hated us for being Communist.
When we embrace Capitalism, you hate us for being Capitalist.
When we have a billion people, you said we were destroying the planet.
When we tried limiting our numbers, you said we abused human rights.
When we were poor, you thought we were dogs.
When we loan you cash, you blame us for your national debts.
When we build our industries, you call us Polluters.
When we sell you goods, you blame us for global warming.
When we buy oil, you call it exploitation and genocide.
When you go to war for oil, you call it liberation.
When we were lost in chaos and rampage, you demanded rules of law.
When we uphold law and order against violence, you call it violating human
rights.
When we were silent, you said you wanted us to have free speech.
When we are silent no more, you say we are brainwashed xenophobics.
Why do you hate us so much, we asked. No, you answered, we don’t hate you.
We don’t hate you either, But, do you understand us? Of course we do, you
said, We have AFP, CNN and BBC’s…
What do you really want from us? Think hard first, then answer…
Because you only get so many chances.
Enough is Enough, Enough Hypocrisy for This One World.
We want One World, One Dream, and Peace on Earth.
This Big Blue Earth is Big Enough for all of Us
Duo-Liang Lin, Ph. D.
Professor Emeritus of Physics
University at Buffalo
State University of New York
Sunday, April 20, 2008
Copyright: www.workers.org
Anti-China protests made in USA, not Tibet
Most noteworthy about the protests in London, Paris and San Francisco that targeted the Olympic Torch on its way to the Beijing Olympics was their character.
Take the events in San Francisco on April 9. The biggest numbers to turn out were not protesters. They were from the Chinese community—thousands according to an NPR report—and came to show their support for China. There may have been nearly as many police—more than 3,000 according to city officials.
The anti-China protests were small in numbers. The Guardian (British) reported about 300 in San Francisco; other wire reports said simply hundreds.
The small numbers might be a surprise if you’d followed the big news coverage leading up to the event. No protest in recent memory has received such major media coverage in the week or two before it happened. Such media coverage gives the impression that a big event is to take place.
The small numbers of anti-China protesters might be attributed to the fact that the protesters claimed to be representing the interests of the people of Tibet, but they were not themselves Tibetan. There were at most a handful of Tibetans.
Actually, there are few Tibetans outside Tibet. The exile community is small—estimates put it at 100,000 to 200,000 at most—and almost all are in Nepal or India. So it is not Tibetans who are in London, Paris or San Francisco, but non-Tibetans—mainly North Americans or Western Europeans—who are protesting against China, claiming that they speak for the Tibetans.
Maybe it wasn’t the size of the event that mattered to the big-business-controlled media in the U.S., but rather the message.
FAIR (Fairness and Accuracy In Reporting) has documented the censorship that dominates the U.S. media. It is a censorship imposed not by the government but by the owners of the media. The political message of an event determines whether it is covered in the news media or censored out.
Most glaring has been the lack of coverage of anti-war protests in all the U.S. media, from newspapers to television and radio.
Several FAIR reports showed the systematic way that the media have ignored or distorted all protests against the Iraq war, for example. Demonstrations that drew hundreds of thousands not only got no attention in the days or weeks leading up to them, but sometimes were never covered at all or were only barely mentioned.
The April 2003 FAIR magazine reported: “In its news coverage in the period before the invasion [of Iraq] began on March 19, the New York Times played down opposition to war and exaggerated support for George W. Bush’s Iraq policy—in ways that ranged from questionable to dishonest. ...
“After the invasion began, when more than 100,000 people in New York City demonstrated on March 22, it was front-page news the next day in the Washington Post and the Boston Globe. But the New York Times, whose offices are two blocks away from where the anti-war march started, placed the story on page B11,” FAIR concluded.
The contrast with the coverage of the anti-China protests today shows the political agenda being pursued by the U.S. media. It has nothing to do with the size of the protests.
The anti-China protests were planned in Washington, London and Paris, not in Tibet or the Tibetan exile communities.
In fact, Washington’s heavy role in the protests, using Tibet and Tibetans as a cover for an anti-China agenda, has spurred public criticism from no less than the former leader of the Free Tibet Campaign.
Patrick French, once the director of that group in London, wrote an opinion piece that the New York Times published on March 22. He said the exile community led by the Dalai Lama in India is making outlandish demands and claims.
For example, part of what he calls the Dalai Lama’s “Hollywood strategy” is to lay claim to a so-called Greater Tibet, demanding territory never considered part of Tibet.
Another example French gives is the claim made by the “Free Tibet” groups in London and Washington that 1.2 million Tibetans have been killed by the Chinese since the Dalai Lama regime was overturned in 1959. His own exhaustive research, he says, has turned up no evidence to back this claim.
Such distortions and misinformation are put forward not by Tibetans in Tibet, French says. They are put forward by those with a hidden agenda who are behind the “Free Tibet” campaign.
“The International Campaign for Tibet, based in Washington, is now a more powerful and effective force on global opinion than the Dalai Lama’s outfit in northern India. The European and American pro-Tibet organizations are the tail that wags the dog of the Tibetan government-in-exile,” French wrote.
Articles copyright 1995-2008 Workers World. Verbatim copying and distribution of this entire article is permitted in any medium without royalty provided this notice is preserved.
Wednesday, March 05, 2008
ebay financials
Hard to believe, but this home crisis induced recession still need to take its toll on ebay or other related sites.
Sunday, December 30, 2007
Everlasting
Everlasting
Let's have the wine
From the heart I am bleeding
Let's dance crazy
This pain is too unbelieving
Let's take a breath
With your kiss still lingering
Let's play with kids
The silver laughter once never ending
Why don't we run away
The beauty of the stranger that breathtaking
Oh, No! Let's not to cry
The tears for the lover too much bitter
Let's not to remember
the words echoed so unforgiving
Let's try to forget
this body felt so much perishing
Yes, let's do it all, Darling
Like seasons change without noticing
Like river runs with no returning
For you, My Love is Everlasting.
Jasmine Lili
Monday, December 24, 2007
Sunday, December 23, 2007
Not Invented Here (www.joelonsoftware.com)
In Defense of Not-Invented-Here Syndrome
By Joel Spolsky
Sunday, October 14, 2001
Time for a pop quiz.
1. Code Reuse is:
a) Good
b) Bad
2. Reinventing the Wheel is:
a) Good
b) Bad
3. The Not-Invented-Here Syndrome is:
a) Good
b) Bad
Of course, everybody knows that you should always leverage other people's work. The correct answers are, of course, 1(a) 2(b) 3(b).
Right?
Not so fast, there!
The Not-Invented-Here Syndrome is considered a classic management pathology, in which a team refuses to use a technology that they didn't create themselves. People with NIH syndrome are obviously just being petty, refusing to do what's in the best interest of the overall organization because they can't find a way to take credit. (Right?) The Boring Business History Section at your local megabookstore is rife with stories about stupid teams that spend millions of dollars and twelve years building something they could have bought at Egghead for $9.99. And everybody who has paid any attention whatsoever to three decades of progress in computer programming knows that Reuse is the Holy Grail of all modern programming systems.
Right. Well, that's what I thought, too. So when I was the program manager in charge of the first implementation of Visual Basic for Applications, I put together a careful coalition of four, count them, four different teams at Microsoft to get custom dialog boxes in Excel VBA. The idea was complicated and fraught with interdependencies. There was a team called AFX that was working on some kind of dialog editor. Then we would use this brand new code from the OLE group which let you embed one app inside another. And the Visual Basic team would provide the programming language behind it. After a week of negotiation I got the AFX, OLE, and VB teams to agree to this in principle.
I stopped by Andrew Kwatinetz's office. He was my manager at the time and taught me everything I know. "The Excel development team will never accept it," he said. "You know their motto? 'Find the dependencies -- and eliminate them.' They'll never go for something with so many dependencies."
In-ter-est-ing. I hadn't known that. I guess that explained why Excel had its own C compiler.
By now I'm sure many of my readers are rolling on the floor laughing. "Isn't Microsoft stupid," you're thinking, "they refused to use other people's code and they even had their own compiler just for one product."
Not so fast, big boy! The Excel team's ruggedly independent mentality also meant that they always shipped on time, their code was of uniformly high quality, and they had a compiler which, back in the 1980s, generated pcode and could therefore run unmodified on Macintosh's 68000 chip as well as Intel PCs. The pcode also made the executable file about half the size that Intel binaries would have been, which loaded faster from floppy disks and required less RAM.
"Find the dependencies -- and eliminate them." When you're working on a really, really good team with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else knows how to ship on time. When you're a cordon bleu chef and you need fresh lavender, you grow it yourself instead of buying it in the farmers' market, because sometimes they don't have fresh lavender or they have old lavender which they pass off as fresh.
Indeed during the recent dotcom mania a bunch of quack business writers suggested that the company of the future would be totally virtual -- just a trendy couple sipping Chardonnay in their living room outsourcing everything. What these hyperventilating "visionaries" overlooked is that the market pays for value added. Two yuppies in a living room buying an e-commerce engine from company A and selling merchandise made by company B and warehoused and shipped by company C, with customer service from company D, isn't honestly adding much value. In fact, if you've ever had to outsource a critical business function, you realize that outsourcing is hell. Without direct control over customer service, you're going to get nightmarishly bad customer service -- the kind people write about in their weblogs when they tried to get someone, anyone, from some phone company to do even the most basic thing. If you outsource fulfillment, and your fulfillment partner has a different idea about what constitutes prompt delivery, your customers are not going to be happy, and there's nothing you can do about it, because it took 3 months to find a fulfillment partner in the first place, and in fact, you won't even know that your customers are unhappy, because they can't talk to you, because you've set up an outsourced customer service center with the explicit aim of not listening to your own customers. That e-commerce engine you bought? There's no way it's going to be as flexible as what Amazon does with obidos, which they wrote themselves. (And if it is, then Amazon has no advantage over their competitors who bought the same thing). And no off-the-shelf web server is going to be as blazingly fast as what Google does with their hand-coded, hand-optimized server.
This principle, unfortunately, seems to be directly in conflict with the ideal of "code reuse good -- reinventing wheel bad."
The best advice I can offer:
If it's a core business function -- do it yourself, no matter what.
Pick your core business competencies and goals, and do those in house. If you're a software company, writing excellent code is how you're going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you're a pharmaceutical company, write software for drug research, but don't write your own accounting package. If you're a web accounting service, write your own accounting package, but don't try to create your own magazine ads. If you have customers, never outsource customer service.
If you're developing a computer game where the plot is your competitive advantage, it's OK to use a third party 3D library. But if cool 3D effects are going to be your distinguishing feature, you had better roll your own.
The only exception to this rule, I suspect, is if your own people are more incompetent than everyone else, so whenever you try to do anything in house, it's botched up. Yes, there are plenty of places like this. If you're in one of them, I can't help you.
Sunday, November 25, 2007
Thursday, November 08, 2007
(two weeks) installing IDLE on FC
[root@linux ~]# yum install tkinter
[root@linux ~]# yum install python-imaging
[root@linux ~]# yum install python-tools



