If I understand the idea behind qubits, then it should be possible to build a computer that can implement a nondeterministic finite automata. An NFA would permit the solution of a class of problems that are considered NP complete -- they can only be solved in exponential time (prime number factorization being only one application of this). This quantum computer would then be able to solve NP-Complete problems in polynomial time.
Some examples of these types of problems are planning and routing, Operations Research generally, and general search.
Many techniques explored in AI have that NP-completeness characteristic, which AI researchers try hard to control/avoid. Could quantum computing be more important for AI/MI than for anything else? (Once we have enough bits to work with, that is...)
While a work remains in print, the copyright does not expire, since those associated with creating the printings usually take the few step required to maintain it. Tolkiens work is likely to remain in print for hundreds of years since it is one of the few truly great works of the past century (IMHO ).
Those works are at least available. My greatest frustration is with copywritten books that are out of print such as The Anatomy of LISP. If I don't find a used copy, I don't read the book at all (I did manage to find a copy of Anatomy, but it took a year or so). Those that are hardest to find are those that cover woodworking techniques of the 17th, 18th and 19th centuries. The best copies of these I can find are phototypeset from copies, and the pages are frequently slightly askew or damaged or even missing. This represents a real loss of information, since those skills are not practiced widely anymore.
While PG has dealt with the likes of Shakespear, there has been almost no work on those technical works of the past. Not that I have any answers, it is just a problem that I see as a woodworker and blacksmith (in addition to computer geek).
The problem that one tries to solve with JIT based language (say Java) is not the same problem that one tries to solve with a systems programming language (say, C) is not the same problem that one tries to solve with an AI language (say LISP).
I would not try to write device drivers in anything but C -- assembly is too unportable. I would not try to write an AI program in C unless I had an essentially unlimited budget -- LISP is much better suited to that task. If I want to interact with a WWW user -- Java is the best choice thus far. As to effeciency of the resulting program, the speed of assembly code is irrelevant in 99.99% of code, since the program spends most of its time in that 0.01% (OK -- I'm exaggerating, but not that much;-). Ease of programming and maintenance is much more valuable -- that observation led to the decision to use C to implement UNIX in the first place.
"So what" you ask? While we talk about JIT and code morphing vs. compilation vs. hand assembly, we need to compare similar things. Language characteristics are nearly unrelated to performance (*implementation* is a whole other story...) In any HLL there must be some translation from strings of bytes to executable things, whether byte codes (emacs lisp), VM codes (Java), or machine code (any of the above under an alternate translator).
JIT tries to solve the problem of bridging the gap between one (abstract) instruction set to another. Code morphing does the same thing. Compilation does the translation from HLL to machine code in one block. The time available to a compiler to explore different register allocation strategies and branch orderings is much larger, but less information about the typical case is available than for the JIT. However, branch prediction is the only place where repeated JIT/morphing has an advantage.
BUT: I repeat -- they solve different problems. Compilers create programs to execute on a chip. JIT/morphing makes a program written for one chip executable on another.
The use/non-use of garbage collection does not tell us a-priori that a program will be slower than the same program without GC -- that depends on the allocation behaviour. There is considerable literature (both theory and practice) on this topic, for languages such as C (gasp!), C++, and LISP. Probably Java too, by now.
Compilers may miss optimization opportunities occasionally but the assembly code they generate is usually pretty good, and it is free of human-errors.
Finally -- Alan Cox mentioned the microkernel performance mistake. I think that it applies here, but not in the way you might expect. It is really easy to miss the real cause of performance problems. In my experience, choice of algorithm and data structure (even in OO code) have a much greater impact on performance than any other single factor (or even several other factors together). You should use language features to help with your task -- but don't be sloppy with them. That always leads to bad, buggy code, and poor performance.
Godel's proof is about undecidability. If a formal system has enough expressive power, there will be statments whose truth in that formal system cannot be assertained in that system. It most assuredly does not require complete formal systems to contain contradictions.
Godels proof, Turing's incompleteness theorem (aka the halting problem), and the Church-Rossier (sp?) theorem are all equivalent statements of that idea. It places limits on computation, and prevents us from ever having a perfectly constructed and provabily correct mathematical logic (some uncertainty will always remain), but we can be free of contradiction -- thank God. With a single contradiction, you can prove anything.
Having said this -- I agree that Carter has wandered a long way from a solid theory. At least the Mapper/Packer distinction could be tested (and I am astisfied that it is a real phenomon).
Perhaps our feedback will assist in the refinement of the ideas into real theories that work to Godel's limits. Perhaps not;-)
I think that you mis-read the dispute. I understood the issue to be one of continued stability on the one hand (rms, et.al.) vs inclusion of new optimization strategies, better implementation of some increasingly important C++ features (and tracking the C++ standard), and the addition of some new front-end languages that required some back-end support on the other hand. What was appeared to be happening was that the changes to support things like a non-broken template instantiation mechanism were not being included in the 2.7.x releases, and 2.8 was taking *way* too long (18 months or so at the time of the initial fork IIRC).
egcs gave the folks who wanted the new features a place to hack, and check their results. The egcs team has done such a good job with these enhancements, that they have become the GCC maintainers.
I view this as a Good Thing.
Let us judge this announcement on its technical merit, and on its openness and free(dom)ness, and leave personalities at the door.
I recall that in the golden age of hackerdom at MIT, one did not call oneself a hacker. One hacked up elegant code, and others observed its beauty and said "That's a neat hack". One was referred to as a hacker only when one had the reputation for consistently creating such code. Calling oneself "hacker" marked one as a hacker-wannabe. In this, Hacker and Guru are similar.
Therefore, I cannot reject Guru anymore than I reject Hacker, except that the term hacker contains a bit of self-deprecation or modesty, which guru lacks.
I have suggested that the title on my business cards read "Lord High Wizard, defender of the Design, keeper of the Source, and a fit consort for Her Majesty, My Wife", but so far, they aren't buying it -- they claim that it is too long to fit.;-)
Slashdot Mirror
I haven't seen anyone mention this explicitly...
If I understand the idea behind qubits, then it should be possible to build a computer that can implement a nondeterministic finite automata. An NFA would permit the solution of a class of problems that are considered NP complete -- they can only be solved in exponential time (prime number factorization being only one application of this). This quantum computer would then be able to solve NP-Complete problems in polynomial time.
Some examples of these types of problems are planning and routing, Operations Research generally, and general search.
Many techniques explored in AI have that NP-completeness characteristic, which AI researchers try hard to control/avoid. Could quantum computing be more important for AI/MI than for anything else? (Once we have enough bits to work with, that is...)
Hmmm......
While a work remains in print, the copyright does not expire, since those associated with creating the printings usually take the few step required to maintain it. Tolkiens work is likely to remain in print for hundreds of years since it is one of the few truly great works of the past century (IMHO ).
Those works are at least available. My greatest frustration is with copywritten books that are out of print such as The Anatomy of LISP. If I don't find a used copy, I don't read the book at all (I did manage to find a copy of Anatomy, but it took a year or so). Those that are hardest to find are those that cover woodworking techniques of the 17th, 18th and 19th centuries. The best copies of these I can find are phototypeset from copies, and the pages are frequently slightly askew or damaged or even missing. This represents a real loss of information, since those skills are not practiced widely anymore.
While PG has dealt with the likes of Shakespear, there has been almost no work on those technical works of the past. Not that I have any answers, it is just a problem that I see as a woodworker and blacksmith (in addition to computer geek).
The problem that one tries to solve with JIT based language (say Java) is not the same problem that one tries to solve with a systems programming language (say, C) is not the same problem that one tries to solve with an AI language (say LISP).
;-). Ease of programming and maintenance is much more valuable -- that observation led to the decision to use C to implement UNIX in the first place.
;-)
I would not try to write device drivers in anything but C -- assembly is too unportable. I would not try to write an AI program in C unless I had an essentially unlimited budget -- LISP is much better suited to that task. If I want to interact with a WWW user -- Java is the best choice thus far. As to effeciency of the resulting program, the speed of assembly code is irrelevant in 99.99% of code, since the program spends most of its time in that 0.01% (OK -- I'm exaggerating, but not that much
"So what" you ask? While we talk about JIT and code morphing vs. compilation vs. hand assembly, we need to compare similar things. Language characteristics are nearly unrelated to performance (*implementation* is a whole other story...) In any HLL there must be some translation from strings of bytes to executable things, whether byte codes (emacs lisp), VM codes (Java), or machine code (any of the above under an alternate translator).
JIT tries to solve the problem of bridging the gap between one (abstract) instruction set to another. Code morphing does the same thing. Compilation does the translation from HLL to machine code in one block. The time available to a compiler to explore different register allocation strategies and branch orderings is much larger, but less information about the typical case is available than for the JIT. However, branch prediction is the only place where repeated JIT/morphing has an advantage.
BUT: I repeat -- they solve different problems. Compilers create programs to execute on a chip. JIT/morphing makes a program written for one chip executable on another.
The use/non-use of garbage collection does not tell us a-priori that a program will be slower than the same program without GC -- that depends on the allocation behaviour. There is considerable literature (both theory and practice) on this topic, for languages such as C (gasp!), C++, and LISP. Probably Java too, by now.
Compilers may miss optimization opportunities occasionally but the assembly code they generate is usually pretty good, and it is free of human-errors.
Finally -- Alan Cox mentioned the microkernel performance mistake. I think that it applies here, but not in the way you might expect. It is really easy to miss the real cause of performance problems. In my experience, choice of algorithm and data structure (even in OO code) have a much greater impact on performance than any other single factor (or even several other factors together). You should use language features to help with your task -- but don't be sloppy with them. That always leads to bad, buggy code, and poor performance.
Hmmmm -- still on topic? You decide
Um -- I doubt that email (via SMTP) would be affected by a UDP (which is NNTP).
Sorry -- I can't let this pass.
;-)
Godel's proof is about undecidability. If a formal system has enough expressive power, there will be statments whose truth in that formal system cannot be assertained in that system. It most assuredly does not require complete formal systems to contain contradictions.
Godels proof, Turing's incompleteness theorem (aka the halting problem), and the Church-Rossier (sp?) theorem are all equivalent statements of that idea. It places limits on computation, and prevents us from ever having a perfectly constructed and provabily correct mathematical logic (some uncertainty will always remain), but we can be free of contradiction -- thank God. With a single contradiction, you can prove anything.
Having said this -- I agree that Carter has wandered a long way from a solid theory. At least the Mapper/Packer distinction could be tested (and I am astisfied that it is a real phenomon).
Perhaps our feedback will assist in the refinement of the ideas into real theories that work to Godel's limits. Perhaps not
I think that you mis-read the dispute. I understood the issue to be one of continued stability on the one hand (rms, et.al.) vs inclusion of new optimization strategies, better implementation of some increasingly important C++ features (and tracking the C++ standard), and the addition of some new front-end languages that required some back-end support on the other hand. What was appeared to be happening was that the changes to support things like a non-broken template instantiation mechanism were not being included in the 2.7.x releases, and 2.8 was taking *way* too long (18 months or so at the time of the initial fork IIRC).
egcs gave the folks who wanted the new features a place to hack, and check their results. The egcs team has done such a good job with these enhancements, that they have become the GCC maintainers.
I view this as a Good Thing.
Let us judge this announcement on its technical merit, and on its openness and free(dom)ness, and leave personalities at the door.
I recall that in the golden age of hackerdom at MIT, one did not call oneself a hacker. One hacked up elegant code, and others observed its beauty and said "That's a neat hack". One was referred to as a hacker only when one had the reputation for consistently creating such code. Calling oneself "hacker" marked one as a hacker-wannabe. In this, Hacker and Guru are similar.
;-)
Therefore, I cannot reject Guru anymore than I reject Hacker, except that the term hacker contains a bit of self-deprecation or modesty, which guru lacks.
I have suggested that the title on my business cards read "Lord High Wizard, defender of the Design, keeper of the Source, and a fit consort for Her Majesty, My Wife", but so far, they aren't buying it -- they claim that it is too long to fit.
One grey-beards opinion.