Matt, On Mon, Apr 1, 2013 at 10:08 AM, Matt Mahoney <[email protected]>wrote:
> On Mon, Apr 1, 2013 at 5:35 AM, Steve Richfield > <[email protected]> wrote: > > Is Summly's algorithm described somewhere? > > Not really. http://summly.com/technology.html > > But the general idea is to remove the parts of the text that compress > easily, so you are left with low-frequency words and phrases from the > beginning of the document or that occur frequently in the document. > You can also use supervised learning to train the language model to > select the right features. How well all of this works depends on the > quality of the language model. Generally it would be an ensemble of > n-gram models, with parsing playing little or no role. > http://en.wikipedia.org/wiki/Automatic_summarization > This sounds pretty remote from our present parsing discussions. I don't see a connection. Do you? > > > Note a quirk of law: It is conceivable that Summly had adopted my > algorithm but kept it proprietary. As such, Yahoo would have NO claim on > the technology, and their work would NOT count as prior art. It happens all > the time - people validly patent things that it turns out someone else has > already developed. These patents are fully enforceable. > > Source code does not have much value unless you hire the developer. I > doubt that patents matters in this case, although I'm sure that Yahoo > will pursue them. > By "them" I presume you mean their patents. Now, I will soon have one of my own - or find myself in the middle of a battle at the USPTO over my method if Yahoo (or Google or ???) has already filed a patent in the same area - which seems unlikely. > > > However, my invention was NOT what to do, but how to do such things > faster. The combinatorial explosion from failed tests hangs over the head > of all NL "understanding" efforts. From what I can see, my method is the > ONLY presently known way of prospectively running fast enough, once the > rules/tables/DB are populated with all the information needed to process > everyday English (or other natural language). > > Your bold claims Which claim(s) are you challenging; 1. That failed tests are the major source of overhead in NL understanding? 2. That using my method will make systems run faster than not using my method? 3. That there aren't other known ways of eliminating this overhead? 4. That we should even be talking about a full implementation of English, when no one has yet done it? would be more credible if you had an actual working > system. This is obviously a multi-million-dollar team-effort project. Populating a knowledge base with rules is not so easy as you > think. Ask Doug Lenat. > Doug has gone WAY WAY WAY beyond "simply" defining a language - he is trying to define the whole damn world. Note that my target application does NOT require a full implementation of English, just those pieces that relate to specific problems and products that the application addresses, one by one, as new products are added. Sure this could eventually encompass pretty much all of the language, but just like in your plans, this would pay for itself as it was incrementally developed. eBay showed how it is possible to insinuate a computer into the sales process. Your plan shows how it might be possible to insinuate a computer into the entire economic process. I just supplied some implementation details to point a way to make this happen sooner rather than later, and in the process eliminate the chicken-or-egg problem with money - of needing a quadrillion dollars to make a quadrillion dollars. Steve ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
