Domain: clusty.com
Stories and comments across the archive that link to clusty.com.
Comments · 120
-
The beard!!!
What do you say about your beard, psycho? That's all we care about. Get back to us when you've had the appropriate amount of psychotherapy.
-
Re:Wolfenstein
Silas Warner does deserve limited credit for the first FPS game -- but not for Wolfenstein. See Spsim.
-
Look up prolog tabling.See prolog tabling.
It is simply a matter of how eager the evaluation is, but the table can be generated prior to execution if the predicates are known at compile time. If you dislike how efficient the tabling mechanism is in, say, XSB prolog, then you always have the option of building an optimizer for a particular machine.
-
Re: Exceptional programmingThe only logic applied to the failure case is that which the programmer codes.
Indeed, failure cases can be thought of as default behaviors. You might have multiple options for default behaviors -- and the question is what priority you give these defaults.
You are also missing the core premise of systems coding - to be close to the hardware, which necessarily precludes prolog.
Programming close to the hardware merely means you are modeling the hardware and that model, rather than being compiled into code, is physically realized by hardware. Model theory is exactly what you need and predicate calculus is the way most mathematics express models.
-
Exceptional programmingIf you want to optimize exception handling then choose an exception-based execution model. Most people -- particularly Perl programmers -- are familiar with the short-circuit "or" and short-circuit "and" style of programming. "and" binds more tightly than "or" so that a sequence of "and" looks like a normal execution thread with no exceptions, whereas a sequence of "or" looks like a cascade of exception handlers (if all the prior expressions in the "or" sequence fail then you take the next one as an exception handler).
When I say "thread" above I'm not just throwing around an ad hoc term -- you can use this to provide the basis for parallel execution in an OS or language.
There is an entire school of thought built around this idea called logic programming and it is based on the most widely used foundation for mathematics -- the predicate calculus.
I don't know why people spend so much time and energy optimizing things that are less powerful.
As for object oriented programming, As I've said before:
Almost all the Object Oriented stuff people layer on predicates are, at best, an ad hoc, and poor, means of optimizing execution speed.
Let me explain.
One of the principles of polymorphism is that the same method has the same abstract meaning regardless of the kind of object. A predicate considered as a method subsumes such polymorphism by simply trying the various possible implementations of the method and committing to only those that succeed. If more than one succeeds then so be it -- that's the whole idea of relations as opposed to functions.
So, one reason you want all this OO stuff is the inheritance hierarchies keep you from going through all possible interpretations of a given method when the vast majority of them will fail for a given object.
Another, related, problem is that inheritance provides defaults without requiring a lot of thinking on the part of the computer. What I mean by "thinking" here is the sort of thing that is done by statistical imputation of missing data via algorithms like expectation maximization (EM) [clusty.com] or multi-relational data mining via inductive logic programming .
So, the other reason you want all this OO stuff is so you can avoid mining a background database to provide reasonable defaults for various aspects of the data.
Some might be concerned that over-riding isn't absolute in such a system -- that you don't absolutely block, say, more generic methods when you have more specific ones present, and they're right. You don't block those methods -- you lower their priority by lowering the probability of those implementations via the statistical methods of imputation and/or induction. In a microthreading environment they most likely won't get any resources allocated to them before other higher priority implementations have succeeded. In a single threaded/depth-first environment they will be down the list of desired alternatives -- but they won't be discarded until something equivalent to a prolog cut operation kills them off.
However, and this is the important point, the work that has been expended toward OO facilities has vastly outstripped the effort that which has been put toward more parsimonious ways of optimizing predicate systems.
One of the better predicate calculus systems out there -- more promising due to its use of tabling to avoid infinite regress on head-recursive definitions and its optimization of queries using some fairly general theorems of predicate calculus -- is XSB . It has an interface to odbc and a direct interface to Oracle, but it would be better if it had something like a
-
Exceptional programmingIf you want to optimize exception handling then choose an exception-based execution model. Most people -- particularly Perl programmers -- are familiar with the short-circuit "or" and short-circuit "and" style of programming. "and" binds more tightly than "or" so that a sequence of "and" looks like a normal execution thread with no exceptions, whereas a sequence of "or" looks like a cascade of exception handlers (if all the prior expressions in the "or" sequence fail then you take the next one as an exception handler).
When I say "thread" above I'm not just throwing around an ad hoc term -- you can use this to provide the basis for parallel execution in an OS or language.
There is an entire school of thought built around this idea called logic programming and it is based on the most widely used foundation for mathematics -- the predicate calculus.
I don't know why people spend so much time and energy optimizing things that are less powerful.
As for object oriented programming, As I've said before:
Almost all the Object Oriented stuff people layer on predicates are, at best, an ad hoc, and poor, means of optimizing execution speed.
Let me explain.
One of the principles of polymorphism is that the same method has the same abstract meaning regardless of the kind of object. A predicate considered as a method subsumes such polymorphism by simply trying the various possible implementations of the method and committing to only those that succeed. If more than one succeeds then so be it -- that's the whole idea of relations as opposed to functions.
So, one reason you want all this OO stuff is the inheritance hierarchies keep you from going through all possible interpretations of a given method when the vast majority of them will fail for a given object.
Another, related, problem is that inheritance provides defaults without requiring a lot of thinking on the part of the computer. What I mean by "thinking" here is the sort of thing that is done by statistical imputation of missing data via algorithms like expectation maximization (EM) [clusty.com] or multi-relational data mining via inductive logic programming .
So, the other reason you want all this OO stuff is so you can avoid mining a background database to provide reasonable defaults for various aspects of the data.
Some might be concerned that over-riding isn't absolute in such a system -- that you don't absolutely block, say, more generic methods when you have more specific ones present, and they're right. You don't block those methods -- you lower their priority by lowering the probability of those implementations via the statistical methods of imputation and/or induction. In a microthreading environment they most likely won't get any resources allocated to them before other higher priority implementations have succeeded. In a single threaded/depth-first environment they will be down the list of desired alternatives -- but they won't be discarded until something equivalent to a prolog cut operation kills them off.
However, and this is the important point, the work that has been expended toward OO facilities has vastly outstripped the effort that which has been put toward more parsimonious ways of optimizing predicate systems.
One of the better predicate calculus systems out there -- more promising due to its use of tabling to avoid infinite regress on head-recursive definitions and its optimization of queries using some fairly general theorems of predicate calculus -- is XSB . It has an interface to odbc and a direct interface to Oracle, but it would be better if it had something like a
-
Exceptional programmingIf you want to optimize exception handling then choose an exception-based execution model. Most people -- particularly Perl programmers -- are familiar with the short-circuit "or" and short-circuit "and" style of programming. "and" binds more tightly than "or" so that a sequence of "and" looks like a normal execution thread with no exceptions, whereas a sequence of "or" looks like a cascade of exception handlers (if all the prior expressions in the "or" sequence fail then you take the next one as an exception handler).
When I say "thread" above I'm not just throwing around an ad hoc term -- you can use this to provide the basis for parallel execution in an OS or language.
There is an entire school of thought built around this idea called logic programming and it is based on the most widely used foundation for mathematics -- the predicate calculus.
I don't know why people spend so much time and energy optimizing things that are less powerful.
As for object oriented programming, As I've said before:
Almost all the Object Oriented stuff people layer on predicates are, at best, an ad hoc, and poor, means of optimizing execution speed.
Let me explain.
One of the principles of polymorphism is that the same method has the same abstract meaning regardless of the kind of object. A predicate considered as a method subsumes such polymorphism by simply trying the various possible implementations of the method and committing to only those that succeed. If more than one succeeds then so be it -- that's the whole idea of relations as opposed to functions.
So, one reason you want all this OO stuff is the inheritance hierarchies keep you from going through all possible interpretations of a given method when the vast majority of them will fail for a given object.
Another, related, problem is that inheritance provides defaults without requiring a lot of thinking on the part of the computer. What I mean by "thinking" here is the sort of thing that is done by statistical imputation of missing data via algorithms like expectation maximization (EM) [clusty.com] or multi-relational data mining via inductive logic programming .
So, the other reason you want all this OO stuff is so you can avoid mining a background database to provide reasonable defaults for various aspects of the data.
Some might be concerned that over-riding isn't absolute in such a system -- that you don't absolutely block, say, more generic methods when you have more specific ones present, and they're right. You don't block those methods -- you lower their priority by lowering the probability of those implementations via the statistical methods of imputation and/or induction. In a microthreading environment they most likely won't get any resources allocated to them before other higher priority implementations have succeeded. In a single threaded/depth-first environment they will be down the list of desired alternatives -- but they won't be discarded until something equivalent to a prolog cut operation kills them off.
However, and this is the important point, the work that has been expended toward OO facilities has vastly outstripped the effort that which has been put toward more parsimonious ways of optimizing predicate systems.
One of the better predicate calculus systems out there -- more promising due to its use of tabling to avoid infinite regress on head-recursive definitions and its optimization of queries using some fairly general theorems of predicate calculus -- is XSB . It has an interface to odbc and a direct interface to Oracle, but it would be better if it had something like a
-
Would've enjoyed testing it..but
It doesn't seem to like Netlimiter. It won't install. Too bad. I won't uninstall Netlimiter just because Google's Search Tool doesn't like it.
If I remember correctly Altavista put out something like this in their golden years? Let's not hope Google won't go down the drain (I hate hitting "google farms", and I do that too often). Focus Google.. I'm sure Clusty and AllTheWeb would like a share of the market, and if you don't fix your primary service (your beloved search engine) - you'll probably fade away. -
Predicate ImputationI've been watching the way relational calculus has been studiously ignored by both academia and industry for over 20 years now. Date and Darwen make some noise about recognizing that SQL's foundation is the application of predicate calculus to set theory but don't really do much of anything that would be recognizable to Pierce, Russell or Whitehead. Moreover, their "manifestos" about things like the object-relational paradigm don't do much to get to the heart of the issue from first principles.
Almost all the Object Oriented stuff people layer on predicates are, at best, an ad hoc, and poor, means of optimizing execution speed.
Let me explain.
One of the principles of polymorphism is that the same method has the same abstract meaning regardless of the kind of object. A predicate considered as a method subsumes such polymorphism by simply trying the various possible implementations of the method and committing to only those that succeed. If more than one succeeds then so be it -- that's the whole idea of relations as opposed to functions.
So, one reason you want all this OO stuff is the inheritance hierarchies keep you from going through all possible interpretations of a given method when the vast majority of them will fail for a given object.
Another, related, problem is that inheritance provides defaults without requiring a lot of thinking on the part of the computer. What I mean by "thinking" here is the sort of thing that is done by statistical imputation of missing data via algorithms like expectation maximization (EM) or multi-relational data mining via inductive logic programming.
So, the other reason you want all this OO stuff is so you can avoid mining a background database to provide reasonable defaults for various aspects of the data.
Some might be concerned that over-riding isn't absolute in such a system -- that you don't absolutely block, say, more generic methods when you have more specific ones present, and they're right. You don't block those methods -- you lower their priority by lowering the probability of those implementations via the statistical methods of imputation and/or induction. In a microthreading environment they most likely won't get any resources allocated to them before other higher priority implementations have succeeded. In a single threaded/depth-first environment they will be down the list of desired alternatives -- but they won't be discarded until something equivalent to a prolog cut operation kills them off.
However, and this is the important point, the work that has been expended toward OO facilities has vastly outstripped the effort that which has been put toward more parsimonious ways of optimizing predicate systems.
One of the better predicate calculus systems out there -- more promising due to its use of tabling to avoid infinite regress on head-recursive definitions and its optimization of queries using some fairly general theorems of predicate calculus -- is XSB. It has an interface to odbc and a direct interface to Oracle, but it would be better if it had something like a recoverable virtual memory substrate to support its roll-back semantics.
-
Predicate ImputationI've been watching the way relational calculus has been studiously ignored by both academia and industry for over 20 years now. Date and Darwen make some noise about recognizing that SQL's foundation is the application of predicate calculus to set theory but don't really do much of anything that would be recognizable to Pierce, Russell or Whitehead. Moreover, their "manifestos" about things like the object-relational paradigm don't do much to get to the heart of the issue from first principles.
Almost all the Object Oriented stuff people layer on predicates are, at best, an ad hoc, and poor, means of optimizing execution speed.
Let me explain.
One of the principles of polymorphism is that the same method has the same abstract meaning regardless of the kind of object. A predicate considered as a method subsumes such polymorphism by simply trying the various possible implementations of the method and committing to only those that succeed. If more than one succeeds then so be it -- that's the whole idea of relations as opposed to functions.
So, one reason you want all this OO stuff is the inheritance hierarchies keep you from going through all possible interpretations of a given method when the vast majority of them will fail for a given object.
Another, related, problem is that inheritance provides defaults without requiring a lot of thinking on the part of the computer. What I mean by "thinking" here is the sort of thing that is done by statistical imputation of missing data via algorithms like expectation maximization (EM) or multi-relational data mining via inductive logic programming.
So, the other reason you want all this OO stuff is so you can avoid mining a background database to provide reasonable defaults for various aspects of the data.
Some might be concerned that over-riding isn't absolute in such a system -- that you don't absolutely block, say, more generic methods when you have more specific ones present, and they're right. You don't block those methods -- you lower their priority by lowering the probability of those implementations via the statistical methods of imputation and/or induction. In a microthreading environment they most likely won't get any resources allocated to them before other higher priority implementations have succeeded. In a single threaded/depth-first environment they will be down the list of desired alternatives -- but they won't be discarded until something equivalent to a prolog cut operation kills them off.
However, and this is the important point, the work that has been expended toward OO facilities has vastly outstripped the effort that which has been put toward more parsimonious ways of optimizing predicate systems.
One of the better predicate calculus systems out there -- more promising due to its use of tabling to avoid infinite regress on head-recursive definitions and its optimization of queries using some fairly general theorems of predicate calculus -- is XSB. It has an interface to odbc and a direct interface to Oracle, but it would be better if it had something like a recoverable virtual memory substrate to support its roll-back semantics.
-
Predicate ImputationI've been watching the way relational calculus has been studiously ignored by both academia and industry for over 20 years now. Date and Darwen make some noise about recognizing that SQL's foundation is the application of predicate calculus to set theory but don't really do much of anything that would be recognizable to Pierce, Russell or Whitehead. Moreover, their "manifestos" about things like the object-relational paradigm don't do much to get to the heart of the issue from first principles.
Almost all the Object Oriented stuff people layer on predicates are, at best, an ad hoc, and poor, means of optimizing execution speed.
Let me explain.
One of the principles of polymorphism is that the same method has the same abstract meaning regardless of the kind of object. A predicate considered as a method subsumes such polymorphism by simply trying the various possible implementations of the method and committing to only those that succeed. If more than one succeeds then so be it -- that's the whole idea of relations as opposed to functions.
So, one reason you want all this OO stuff is the inheritance hierarchies keep you from going through all possible interpretations of a given method when the vast majority of them will fail for a given object.
Another, related, problem is that inheritance provides defaults without requiring a lot of thinking on the part of the computer. What I mean by "thinking" here is the sort of thing that is done by statistical imputation of missing data via algorithms like expectation maximization (EM) or multi-relational data mining via inductive logic programming.
So, the other reason you want all this OO stuff is so you can avoid mining a background database to provide reasonable defaults for various aspects of the data.
Some might be concerned that over-riding isn't absolute in such a system -- that you don't absolutely block, say, more generic methods when you have more specific ones present, and they're right. You don't block those methods -- you lower their priority by lowering the probability of those implementations via the statistical methods of imputation and/or induction. In a microthreading environment they most likely won't get any resources allocated to them before other higher priority implementations have succeeded. In a single threaded/depth-first environment they will be down the list of desired alternatives -- but they won't be discarded until something equivalent to a prolog cut operation kills them off.
However, and this is the important point, the work that has been expended toward OO facilities has vastly outstripped the effort that which has been put toward more parsimonious ways of optimizing predicate systems.
One of the better predicate calculus systems out there -- more promising due to its use of tabling to avoid infinite regress on head-recursive definitions and its optimization of queries using some fairly general theorems of predicate calculus -- is XSB. It has an interface to odbc and a direct interface to Oracle, but it would be better if it had something like a recoverable virtual memory substrate to support its roll-back semantics.
-
Bioinformatics linksYesterday wrapped up over a week of intense Bioinformatics seminars, poster sessions, exhibitions, and brainbusting studying at Bio Japan in Tokyo and related links. I just saw a presentation on the H-Invitational database which though in Japan also combines the content of foreign databases. It is extremely impressive, and they combine lots of online calculators and results visualizers that are really impressive.
Also figuring out biology seems to be a lot harder than figuring out networking, at least there are all kinds of nefarious things but also serendipitous things found. Like one presentation I just heard had a U.S. scientist who announced that they had discovered an entire signalling network in human cells that was like the one found in yeast cells. And apparently more proteins can be encoded than the number of genes, because of alternate orderings (counting from different displacements in the gene, I think, ask a real bioinformatics expert). One talk I heard a year ago that stuck with me was a scientist who had devised a way to find signalling pathways in cells quickly; by forcing the cell to die if certain requirements were not met, he created a parallel computer that allowed him to discover a whole swath at once. There is also a lot of math and statistics, as well as a lot of biological knowledge behind it, it is not strange to see various statistical tests, references to different computer programs they used for analysis, or a mention of simulated annealing (well maybe that one not so often, came up yesterday though).
One interesting thing is that they (the H-Invitational people / Japan Bioinformatics Consortium) have I believe twice held what they call annotation jamborees, much like a hackfest! In 2002 they had 120 scientists gather (mostly Japan but from all over the world) in a big room with a computer per person. They locked them in for 10 days, and annotated IIRC over 20,000 genes, basically doing a figure some man years of work in a week, inputting data so it can be searched, analyzed, and crossreferenced.
They do have a comparison between mouse and human genome there, I wonder if something similar could be done in open source in terms of annotating and indexing a libary of open source code in different languages, really all in one pseudo language would be more useful perhaps. Anyway biologists are learning from computer scientists learning from mathematicians, and someone famous has said that in the future, all science will be computer science.
Bioinformatics people are doing text mining and data mining, but also there are many flavors and types of analysis programs designed to penetrate and match up information as encoded by tiny molecules, folded proteins, genes, and so on. Here are some links to get started. Also note the perl for bioinformatics books, and there was a big oreilly bioinformatics conference archived from 2003 and other links too (see bio.oreilly.org link below).
I cannot speak for everyone, but I can convey what I have heard, that there have long been communication gaps that have held back some of this, actually cultural differences. For example physicists like pure math and biologists deal in dirty, wet things.. when people successfully combine different perspectives in this area [more] discoveries start getting made. In Japan at least they are trying to figure out how to grow more bioinformaticists, since students tend to go only towards either biology or towards computer science (why study twice as hard). But there seems to be a lot of interesting stuff in there for both sides.
-
This search engine *IS* better than Google
I am the top hit for my own name. Clearly Clusty is superior -- on Google, some lame journalist comes up first, but, c'mon, who cares about him? Clusty properly files him as the second choice. The better results on this very vital search prove that everyone should switch now. Thanks.
-
Re:is going to try and take Google head-on.
http://clusty.com/search?query=Clusty
Did you mean Lusty
They don't even have their own name in their word list. -
The slashdot search doesn't work...
-
The slashdot search doesn't work...
-
I kicked coffee accidentally with creatineI was a 6 cup a day coffee addict when I decided to start using creatine for other reasons. In the directions they give you for creatine, they tell you to stop caffine intake. I'd never been able to stop caffine intake without withdrawl symptoms, but this time, loading creatine doses of 5 heaping teaspoons a day, I suffered no noticable withdraw.
I'm now taking 1 heaping teaspoon of creatine a day and on those occasions I drink coffee at all it is about 1/2 to 1 cup early in the morning.
-
Hooray! Hooray! Hooray! It puts Wikipedia first!
Finally, a search engine that correctly bubbles wikipedia above the spam clones (and read the reply to this post too). Google doesn't even show wikipedia at all on the first page, even if expanded. Kudos, you've won your first (?) customer!
-
Some problem with the encoding or something?
Arabic results display alright here (firefox 0.9.3 on windows) but you can't click on them. Other UTF-8 encoded sites display just fine; can anyone else replicate this odd behavior?
Look here for an example. Something with the bidi functionality, perhaps? Any hebrew users?
--
The Egyptian LUG -
Klutsy?
New Clustering Search Engine to battle Google
More like New Clustering Search Engine goes Beta. Let's wait until it's production stable before talking about who it's going to take down in a fist fight reminiscent of the Spock/Kirk battle in Amok Time.
Clusty by Vivisimo? Did I even spell that right? They need to consider naming things that people can:
A) pronounce
B) spell
C) are actual words or at least close to words that qualify for both A & B.
Clusty sounds like something you would call the fat cheerleader. It also will be often mispronounced as Klutsy, so it's a very bad name for a search engine (of all things).
The search engine uses Overture for it's results but offers new features such as an encyclopedia search, clustered results, and a gossip search.
This is a Microsoft tactic: add features to get market share, and it's an evil tactic because nothing new comes out of it, except bloat and bad karma. The fact this is based on Overature leads me to believe that it won't be able to take Google head-on at all. Clusty uses the Google interface but shows sponsored results first (evil), and displays 404 pages in the results. (FYI dteam was the first 3d design guild that is no longer)
I don't think they really have a hope of competing with Google. If it ain't broke don't fix it, so most people will just continue to use Google.