Slashdot Mirror

blenderking sent in this Wall Street Journal story about
Microsoft's new "Smart Tags" - auto linking to Microsoft
websites in any web page you visit.

...This program has performed an illegal operation and will be shut down. If the problem persists, please contact the program vendor for resolution.
_____________________________________ _

They're probably counting the separate red, green, and blue elements. These are separate pixels, as they are offset from each other. A special filter, known as a "demosaicing" filter, is required to correctly merge these offset images into the Y/Cb/Cr planes that are encoded in the final JPEG. The ratio isn't a factor of 3 as you might expect, as mosaic patterns tend to use more green than red or blue. (The patterns I've seen have 5 green to 2 red and 2 blue.)

This page describes mosaicing to some extent, in the context of reverse engineering a Kodak digital camera. This page at the same site offers some other details. And Ron Kimmel's page has some neat pictures showing different artifacts due to poor de-mosaicing.

They're probably counting the separate red, green, and blue elements. These are separate pixels, as they are offset from each other. A special filter, known as a "demosaicing" filter, is required to correctly merge these offset images into the Y/Cb/Cr planes that are encoded in the final JPEG. The ratio isn't a factor of 3 as you might expect, as mosaic patterns tend to use more green than red or blue. (The patterns I've seen have 5 green to 2 red and 2 blue.)

This page describes mosaicing to some extent, in the context of reverse engineering a Kodak digital camera. This page at the same site offers some other details. And Ron Kimmel's page has some neat pictures showing different artifacts due to poor de-mosaicing.

This is a link to the display subsystem that was powering that 9.2 million pixel display

http://www-graphics.stanford.edu/papers/lightning2 /

You'll be able to see it with some hopefully very cool imagery at this years SIGGRAPH It really has to be seen to be believed... beautiful!

The paper on the Lightning-2 hardware that drives the monitor is here.

See also WireGL and its associated paper, which was used to run Quake3 on the IBM display.

The paper on the Lightning-2 hardware that drives the monitor is here.

See also WireGL and its associated paper, which was used to run Quake3 on the IBM display.

The paper on the Lightning-2 hardware that drives the monitor is here.

See also WireGL and its associated paper, which was used to run Quake3 on the IBM display.

Very cool stuff that's just starting to get commercialized -- this is what you'll be seeing in your GeForce 4s or whatever.

Sure, I could find good independent music on the internet too, if I had the time to wade through lots of crap. Thus my question: how do you find good independent music without wading through lots of crap? Admittedly, having to wade through some crap is inevitable, as each person's definition of "crap" varies with taste. I'd like to listen to more independent music, but I don't have the time to listen to twenty bands I don't like in order to find one I do.

A lot of college radiostations are (still?) broadcast on the internet. Many of them are really independant: the DJs are largely free to follow their own interests. All you have to do is find one adventurous DJ whose taste you trust, and you've got a pipeline feeding you with more good, new stuff than you can possibly deal with.

(The station I'm involved with is KZSU, the Stanford radio station, but I'd need to know more about what kind of music you're after before I could recommend a particular show on the air.)

Another thing you can do is find a site/zine/magazine that you can more or less trust. Most of the slick glossies are pretty clearly sold-out to the crap machine, but even so I can think of things like The Wire (note, not "-ed"). This is a UK based magazine that in my opinion does a great job of covering interesting music almost without regard to genre (e.g. some recent issues have focused on Sigur Ros, Talvin Singh, and John Cale).

Another move of course, is to look for news groups and mailing lists that talk about stuff you're interested in. Just drop in and say "I like *Foo*, where do I find more?" (Though you need to be prepared to be flamed if you ask about "Nine Inch Nails" on rec.music.industrial or "Marilyn Manson" on alt.gothic).

The economy may not be a zero sum game but nature is. What you are describing a money flowing around in a closed system. Somewhere down the line either somebody prints more money (leading to money being worth less) or somebody takes something out of the earth and sells it. Even some low impact product like a software license requires natural resources. Programmer has to eat, drink, clothe himself, live in a heated house, and perhap even an office. He need a computer and electricity which required mining and drilling. The economy only grows at the expense of natural resources. Maybe they did not teach you that in econ 101 but it's true nevertheless. There is no such thing as free lunch.

If you want to look at some interesting web sites, take a look at this book by the late Julian Simon, or John McCarthy's page on human progress.

this definently isnt a first size wise, but power wise maybe. stanford have had the worlds smallest web server for quite a while now although it is a measly 44Mhz, but it runs linux! (of course!)

Gil Pratt took over the Leg Lab, and focused more on actuator design. Raibert's machines worked, but needed hydraulic, electrical, and pneumatic umbilicals. Better machine design has produced more compact robots.

The idea of springy joints has been around for a while. It's common to model muscles as springs and dampers for which the spring constant, neutral point, and damping factor are adjustable. It's well-known that in mammal running, most of the energy of each stride is stored as spring energy in muscles. (As I recall, about 80% of the energy is recycled for the next stride, so this is a big win.) There's been work at Stanford on flexible manipulators, although that's more related to arms. McGill has a small, high-efficiency hopping machine.

Unless you use pneumatic actuators, off the shelf components aren't well-matched for this approach motion control. That doesn't mean it can't be done, but you spend a lot of time on component development. That's what the Leg Lab has been focusing on under Pratt, and that's why the little dinosaur model was tough to build.

Rod Brooks from MIT also tried a robotic startup, IS Robotics, which produced a $100K robotic insect. Didn't sell. It's really hard to sell mobile robots; I've known several people with failed startups.

I work on this sort of thing for games and animation.

come off crisp and play up to the cynic
clean and schooled right down to the minute

You can view Stefan Savage (one of the paper's co-authors) giving a lecture on his findings at http://stanford-online.stanford.edu. The lecture is only about 50 minutes. Click on "View Free Seminars" and then on the link for "CS548 Internet and Distributed Systems Research Seminar". The lecture is from May 16th.

Sorry, the only format is streaming Windows Media.

-Sverker

From the Making the Macintosh website is this paper where Raskin describes a proposal for an Apple owned dial up network (years later AOL originated from Apple's AppleLink Personal Edition). He basically describes the internet as it exists today while the article is from 1979!

From the Making the Macintosh website is this paper where Raskin describes a proposal for an Apple owned dial up network (years later AOL originated from Apple's AppleLink Personal Edition). He basically describes the internet as it exists today while the article is from 1979!

To clarify, Lisp is the second oldest language still in use. I refer you to these comments:

Fateman, 1998
McCarthy, 1996
Walker, 1997
Reference to McCarthy and Lisp

See this table.

What whole body dose did these workers receive? What dose did they receive to their reproductive organs?

I don't find the BBC article very useful without knowing the doses received.

CS majors not only get a lifetime email address and web page forwarding URL, we also get a shell account for life! w00t!

Also, a paper in Bioinformatics was published recently which tries to extract protein interactions. They used a dictionary of words related to interactions, and then look for proteins which are mentioned in the same sentence that contain one of those dictionary words, along with part of speech analysis to improve accuracy.

Something like that.

Genome@home

Can I draw you attention to Donald Knuth's "Art of Computer Programming"- the definitive work on computer algorithms, which was named by Scientific American as one of the seminal works of the 20th Century (see Knuth's Home Page) putting him in the company of Albert Einstein, Russell and Whitehead, von Neumann, and Dirac.

In it he passionate argues that not only do you need source code to intelligably discuss algorithms, but you need *assembly code* (one short step shy of object code). And all of the algorithms are presented in assembly language.

Donald E. Knuth professor emeritus of computer science at Stanford University and author of the series of books The Art of Computer Programming , once said in an interview with Dr. Dobb's Journal: magazine:

The first thing I would say is that when you write a program, think of it primarily as a work of literature. You're trying to write something that human beings are going to read. Don't think of it primarily as something a computer is going to follow. The more effective you are at making your program readable, the more effective it's going to be: You'll understand it today, you'll understand it next week, and your successors who are going to maintain and modify it will understand it.

Donald E. Knuth professor emeritus of computer science at Stanford University and author of the series of books The Art of Computer Programming , once said in an interview with Dr. Dobb's Journal: magazine:

The first thing I would say is that when you write a program, think of it primarily as a work of literature. You're trying to write something that human beings are going to read. Don't think of it primarily as something a computer is going to follow. The more effective you are at making your program readable, the more effective it's going to be: You'll understand it today, you'll understand it next week, and your successors who are going to maintain and modify it will understand it.

Donald E. Knuth professor emeritus of computer science at Stanford University and author of the series of books The Art of Computer Programming , once said in an interview with Dr. Dobb's Journal: magazine:

The first thing I would say is that when you write a program, think of it primarily as a work of literature. You're trying to write something that human beings are going to read. Don't think of it primarily as something a computer is going to follow. The more effective you are at making your program readable, the more effective it's going to be: You'll understand it today, you'll understand it next week, and your successors who are going to maintain and modify it will understand it.

I'd like to point out how bad the I/O is in Lisp

LISP has had highly sophisticated I/O for many decades. This is why it's so widely used in parsers, text processors, editors and so on. The (Common LISP) I/O specification is here.

...and how hard it is to properly handle the myriad possible errors a program has to handle gracefully when working with humans

in fact, of course, LISP has a condition handling system at least as sophisticated as any other language. The specification is here.

Also, most lisp engines I've seen are interpreted (save for things like the Lisp Machine).

Originally LISP was a compiled language. However it is extremely easy to write a LISP interpreter in LISP, so most LISP systems area able to execute both interpreted source and compiled code. Furthermore, interpreted code can call compiled code and vice-versa. Documentation on the Common LISP compiler is here.

Only a few toy LISP systems lack a compiler.

Now this doesn't prevent you from doing very powerful very high level things with Lisp, but for the most part you can do them easier and faster with C

You really never have used the language, have you? If a programming problem can be solved easier by a good C programmer in C than it can by a good LISP programmer in LISP, it wasn't a problem in the first place. For example, I wrote a CASE tool for expert system design in LISP by myself in three months; it took a team of four programmers two years to produce the production C version of the same program.

Pride and Prejudice: Four Decades of Lisp

http://kmi.open.ac.uk/people/snw2/papers/prejudice /prejudice.html Floating Point Performance of Common Lisp

http://members.home.net/vogt/fft-paper.html John McCarthy's Home Page (the creator of Lisp)

http://www-formal.stanford.edu/jmc/

Except for FORTRAN, which still kicks C's ass on numerical applications because of the "pointer problem", and yes C++ can produce code as fast as C, but it's much more difficult due to the complexity of the language.

Standard C++ fixes some of the performance problems with earlier implementations. For an eye-opener, check out Blitz++, a numerical library written in C++. It performs on par with FORTRAN, sometimes even exceeding FORTRAN's vaunted numerical speed.

Standard C++ can also be much, much faster than C. The standard sorting algorithm is a typical example. std::sort is 250% to 1000% faster than qsort according to one benchmark. It is 20% to 50% faster than a hand-coded C quicksort for a particular data type. I have seen such results elsewhere -- this is just the first page Google turned up.

Yes, std::sort is using inlining to good advantage. That's not "cheating" as some may argue. C++ (and the standard library) provide the efficiency of inlining while maintaining genericity and separation. That's what templates do. It's an intrinsic part of the language. C++ and the standard library help you reduce programmer time (less code to write) and execution time in many important cases.

C++'s combination of static typing, polymorphism and generic programming while maintaining the ability to do "traditional" C-style structured programming is really, really nice. I have my choice of options for coding particular modules and I don't need to learn three different languages to do so. One could even argue that C++ supports a fourth model: with template metaprogramming, one can write C++ code in a style that almost looks like functional programming in the sense that recursion is used exclusively and the code implements functions that do not modify any values. Granted, this form of coding is limited to compile-time values, but it can be used in lots of surprising ways to do things like generate entire class heirarchies automatically.

--

Something related to this that is pretty darn cool is this project from Stanford involving using projectors to project textures, etc. onto 3-D objects. Lots of interesting applications and challenges.
--
George W. Bush
President, United States of America

The point of the project is to develop "a new distributed graphics system that is designed to allow an application to render to a large, tiled display." It is an OpenGL implementation that allows a cluster of one or more machines to render to a tiled display with one or more tiles. So the system allows a cluster of N computers to render a single image, and also allows one computer to render to a tiled display, and also allows N computers to render to M displays in a tiled display.

And, of course, it's OpenGL, so you can put together a rad tiled Quake demo just as easily as you can put together a rad JoesStupidOpenGLTestGame demo.

No HMDs, though.

laugh> I wish I got to see it..!

I'd never heard of "Category Theory" or commuting diagrams before; thank you for the reply..!

That would be "Principia Mathematica" by Russell and Whitehead.

See here.

If you understand and are comfortable with Simula there is the Smalltalk-72 emulation [1] created by Dan Ingalls you can file into Squeak.

Doug Engelbert pioneered the use of Graphic Human Tool Interface with bitmap displays starting in 1957 and going public with his oNLine System in the "MotherOfAllDemos" in 1968.

• [1] Smalltalk-72 ChangeSet for Squeak
  ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/goodies/ Smalltalk-72/
• [2] WikiWiki:TheMotherOfAllDemos
  http://www.c2.com/cgi/wiki?TheMotherOfAllDemos
• [3] RealAudio copy of the MotherOfAllDemos
  http://sloan.stanford.edu/MouseSite/1968Demo.html
• [4] The Augmented Knowlege Workshop - Chronology - 1964
  http://www.bootstrap.org/augment-101931.htm#6C

Here is a good summary of what one company has done to muck up radio stations in the San Francisco Bay Area as a result of the 1995 legislation.

It works better with a direct pointing device like a pen, less well with an indirect pointing device like a mouse, and badly with a velocity pointing device, like a joystick or force-sensing button. Basically, if you can't handwrite with the input device, gestural input will be a pain.

You are right that the genome does not contain all the information needed to specify an organism.

Here's a semi-fanciful essay that I wrote, describing how to make heritable changes without changing the DNA.

Robert Morris has a group working on overlay networks as an alternative to basic Internet path selection --- RON. They are concentrating on overlays as a means of allowing intelligent or policy-based routing decisions on a small scale effect decisions on the large-scale Internet.

Of course, multicast is only going to happen via overlay networks. There are many groups building scaleable overlay networks for content and data delivery today. I'd go so far as to say that multicast semantics are going to drive adoption for routed overlay technology, which will then be used to bridge NAT domains later on.

A valid question to ask in response to this article, though, is "what address exhaustion"? Does anyone have real, valid numbers + methodology for address depletion on the post-NAT Internet?

C++ is, like Perl, such a mess because the problem set is such a mess. That means it's pretty easy to shoot yourself in the foot--and given C++'s power, shots to the foot often take off everything below your waist.

If crossplatform, portable code is a necessity, then be very careful when using newer features such as templates. I've had the devil's own time taking code that works perfectly fine in GCC-2.96 (the Red Hat snapshot, which is a very fine C++ compiler), but breaks horribly under GCC-2.91. Code that compiles cleanly under MSVC++ will oftentimes break horribly in GCC-2.96, etc.

The fewer C++ features you use, the less chance you'll run into these gotchas. That's why the Mozilla team uses a restricted set of C++ functions, I think, far more than to enhance readability or whatnot--the simple fact is, the more C++ features you use, the harder it is to get it to compile under Foo compiler, because Foo doesn't properly implement such-and-such chapters of the Standard; and code written for the Foo compiler breaks on the Bar compiler, because Bar demands strict adherence to the spec, which Foo doesn't provide.

That being said: give consideration to at least using the inheritance features of C++'s class system. Inheritance is, if anything, the most useful feature of C++, and is well-supported by every compiler. Don't treat C++ like Ada83, where classes existed only to protect data as private and to create interfaces to other bits of functionality; let your C++ classes be hierarchial, let them inherit from base classes, and use that to your advantage.

After that, I don't have any recommendations. I'm personally a big fan of generic programming (templatized programming) and the STL. The STL is fearsomely efficient and fast. It's got a learning curve like the Matterhorn, but once you climb it, it's wonderful.

BTW, if anyone tells you to ignore templates on grounds that they cause bloat, please check out the home page of Amit Patel, a Doctoral student at Stanford (who, I believe, often reads Slashdot--if so, hi, Amit, drop me a line sometime) and friend of mine. According to benchmarks he provides on his page (click here), templatized code that makes use of the STL is often, if not almost always, of comparable executable size to an equivalent C program, and substantially faster.

Some compilers, such as Sun's, are absolutely awful with templates--that's probably how the nasty myth of templatized code being bloated and slow came to be. As a rule, though, there's no general truth to this myth; some compilers produce bloated code when using foo, bar and baz parts of the language, but it's not a characteristic of the language--just a characteristic of a crappy compiler.

Bayesian Netowrks

The future of the Internet is in what I call "rational programming" derived from a revival of Bertrand Russell's Relation Arithmetic. Rational programming is a classically applicable branch of relation arithmetic's sub theory of quantum software (as opposed to the hardware-oriented technology of quantum computing). By classically applicable I mean it is applies to conventional computing systems -- not just quantum information systems. Rational programming will subsume what Tim Berners Lee calls the semantic web. The basic problem Tim (and just about everyone back through Bertrand Russell) fails to perceive is that logic is irrational. John McCarthy's signature line says it all about this kind of approach: "He who refuses to do arithmetic is doomed to talk nonsense." More on this a bit later, but first some history, because he who fails to learn from history is doomed to repeat its nonsense:

When I invented the precursor to Postscript (an audacious claim that I can back up -- it started as a replacement for NAPLPS which I proposed while Manager of Interactive Architectures for Viewdata Corp of America back in November of 1981 -- the Xerox PARC guys found my approach of what they called a "tokenized Forth" communication protocol to be an intriguing way to encode text and graphics), I was interested in having a Forth virtual machine migrate into silicon (ala Novix) so it could evolve from mere graphics rendering into a distributed Smalltalk VM environment (ala Squeak) as videotex terminal/personal computer capacities increased. But I was _not_ interested in object-oriented programming as the long-term semantics of distributed programming environments. (I still have some of the hardcopy of the communiques with Xerox PARC and others from this period.)

Rather, relational semantics were what I saw as the ultimate direction for distributed programming. I had a bit of a go at Tony Hoare's "communicating sequential processes" paradigm and its Transputer realization because he was, at least, starting with the hard problem of parallelism rather than making like the drunk looking for his keys under the light post the way everyone else seemed to be doing (and still are, save for Mozart, since threads, etc. are always an afterthought). But, because there were other hard problems like abstraction, transactions and persistence that he ignored, I christened his approach "Occam's Chainsaw Massacre" in my communiques (in honor of his distributed programming language "Occam") and dropped it in favor of relational programming, which has inherent parallelism resulting from both dependency and indeterminacy. (BTW: Dr. Hoare seems to have finally come to his senses about this issue.)

Unfortunately, the only researcher doing hardcore work on relational programming (meaning, getting to the root of relational semantics in a way that Codd had failed to do) at the time was Bruce MacLennan, then, of The Naval Postgraduate School, and he just didn't have the glamour of Alan Kay at places like Xerox PARC to attract the attention of guys like Steve Jobs. Bruce had a bit of a blind-spot, too, when it came to transactions and persistence, which I attempted to remedy by bringing David P. Reed's work on distributed transactions for the ARPAnet to him, but although he wrote a white paper on a predicate calculus (close to a relational) implementation of Reed's thesis (MIT/LCS/TR-205), he didn't really "get it", IMHO. Reed and MacLennan abandoned their work for other pursuits (ironically, Reed was chief scientist at Lotus while Notes was being developed but did not contribute his ideas on distributed synchronization to that development despite the fact that we had a mutual acquaintance from my Plato days by the name of Ray Ozzie -- so, I share some of the blame for this failure) even as Steve Jobs botched the embryonic object oriented world by abandoning Smalltalk and giving us, instead, a lineage consisting of Object Pascal on the Lisa/Mac which begat Objective C on Jobs's NeXT which begat Java at Sun via Naughton and Gosling's experience with NeXT.

This brings us to the present -- a world in which Javascript-based technologies like Tibet promise to not only salvage the object oriented aspect of the Internet from the birth defects of Jobs's spawn, but actually provide an advance over Smalltalk in the same lineage as CLOS and Self. But it is also a world in which there is growing confusion over the proper role of "metadata" in the form of XML -- particularly when it comes to speech acts and distributed inference. I would call Tibet "the next major Internet advance" except for the fact that the basic idea for a Tibet-like system has been around and well understood since the early 1980's. When it is finally released, Tibet (or a system like it) will put the Internet back on track. I call that a "recovery", not an "advance".

We are now poised to move forward with type inference based on full blown inference engines, thereby dispensing with the nonterminating arguments over statically vs dynamically typed languages that allowed Steve Jobs's spawn to get its nose in the tent. If you want to declare a "type" in a declarative language, just make another declaration and let the inference engine figure out what it can do with that information prior to run time. See how easy that was? Well, there is more to it than that, but not that much: Assertions have implications and assertions made prior to run time have implications prior to run time. Live with it and don't repeat the mistakes of the past.

The confusion over semantic webs, and the reason Berners Lee et al will fail, is essentially the same as the confusion that has beleaguered all inferential systems such as logic programming and "artificial intelligence" over the years: logic is irrational and the real world demands rationality -- otherwise nothing makes sense. By "rationality" I mean that reasoning must literally incorporate "ratios" -- or, as John McCarthy would put it, doing arithmetic so things make sense. By making sense, I mean there is a sense in which one interprets the sea of assertions that clearly dominates for a particular purpose. With logic not only are you limited to 0 and 1 as effective quantities; you have no adequate theoretic basis from which to derive more accurate quantities with which to make sense by taking ratios and determining which inferences are dominant.

Fuzzy logic and expert systems incorporating probabilities have typically failed because they are not based in the first principles of probability and statistics. As Gauss, the premiere probability theorist put it, "Mathematics is the study of relations." He didn't say, "Mathematics is the study of multisets." There are good reasons that relational databases, and not set manipulation languages, have come to dominate business applications -- and Gauss was aware of these differences when he began to derive his laws of probability. Subsequent axiomatizations of mathematics based on set theory were similarly misguided and have led to the idea that "fuzzy sets" are the way to introduce rationality into programming. Rather than sets, relations are the foundation, not just of mathematics but of rationality in the same sense that Gauss realized when he derived his theory of probability from the study of relations.

Rationality allows for judgment which is recognized as inherently fallible -- but which allows one to procede without exponentiating all possible paths of inference. Judgment also allows various identities to limit sharing of information to that needed -- thereby creating speech acts and a basis for rational measures of credibility associated with those identities. Since credit-rating is a degeneration of credibility, it should come as no shock that the invention of negative numbers, originating as they did with the Arabic invention of double entry account keeping, has its analog in something that might be called "logical debt" with which negative probabilities are associated.

And now we have come to the "quantum" aspect of rational programming. It is precisely the "credibility debt" aspect of rational programming that corresponds, in mathematical detail, to the various equations of quantum mechanics and their negative probability amplitudes. (Von Neumann's quantum logic failed to properly incorporate logical debt which has led to much confusion.) Logical debt is important to distributed programming for the same reason debt is important to financial networks. Logical debt is a way of handling poor synchronization of information flow in the same way that financial debt is a way of handling poor synchronization of cash flow. As in any rational system, there are both limits to credit and limits to credibilty that influence one's judgments and actions, including speech acts.

The object oriented folks may, in a sense, have the last laugh here because when we divide up inference into identities that engage in speech acts, we are reintroducing the notion of objects that hide information via exchange of speech act messages that can be thought of as "setters" (assertions) and "getters" (queries). However, I believe it is only fair to recognize that the excellent intuitions of Johan Dahl and Kristen Nygaard did need the added insights and rigor of philosophers like J. L. Austin and T. Etter.

Embossed metal would be good.

No better. Metal gets corroded by water (worse yet: saline water), melted by fire, cracked by cold etc.

Besides rock, which has proven pretty good throughout the ages, there's one thing that could hold up the promise, and that's mineral paper. (Aka, asbestos paper.)

Karma karma karma karma karmeleon: it comes and goes, it comes and goes.

Nice, very good research there...

cu Lars

He pays US$2.56 for each error in his books. Do you have a reference for this exponetial thing?

I can't believe nobody's posted about Knuth yet. Donald E. Knuth is famous for writing high-quality software, and even proving some of it (all of it?) correct. He offers rewards to people who find bugs in his code. The reward for TeX and METAFONT is described here: http://www-cs-faculty.stanford.edu/~knuth/abcde.ht ml, under the heading "Rewards".

--Jim

They seem open to putting other video formats up. From the site in the article: "There have been a several reqests that we support other players, formats, and operating systems. It would be helpful to know what video support EE380 folks would like to see. CLICK HERE to send your video player wishlist. Be sure to tell us what OS you would be using."

So just send off an e-mail and they should put other formats. This worked when I sent in a request for a non-streaming copy of the Future of IP debate with Jack Valenti a while back at another Law School. They not only sent me one, but also put it on the web site.

No, it's nothing like a Turing machine. A turning machine is a state machine which can read & write to a long tape of data. A better description is here.

If you want to facilitate and accelerate progress towards the kind of future I imagine you are all interested in, then I suggest you stop arguing and find a distributed project which has a greater potential than SETI or this cancer project/scam. Your best bet is folding@home Why? When we solve this problem, we may quickly find a route to full-blown molecular nanotechnology. So what? This will: 1) Cure all diseases including aging (no need to waste time on the distributed cancer project/scam) 2) Launch real space exploration/space industry (then SETI can listen for ET on a receiver the size of the solar system while the rest of us just go find them) 3) Push computers and AI way past Moore's law (haven't you been infected with the Singularity meme yet?) 4) Provide us with (nearly) unlimited wealth of material and energy (then you can do nearly anything you imagine - hey you could even keep arguing and wasting time if you wanted!) For more info just check out Foresight and KurweilAI Net et. al.

You can see streaming video of this talk here.

btw many ppl dont know that pandegroup at stanford is running 2 projects, folding@home and genome@home. imo second one is much more interessting than the first one.....

btw many ppl dont know that pandegroup at stanford is running 2 projects, folding@home and genome@home. imo second one is much more interessting than the first one.....