Common Misunderstandings about Artificial Intelligence

[Copernicus]

I was an engineer. At the end of the day it comes down to a problem and a solution.

Categories are generally created by those looking in from the outside. Media reporting on AIi s all over the place with refernces to what what one person or another says about AI. It is also about how AI is marketed.

I assume tha in AI today there are general common structures, approaches and methods to AI. That does not change anything.

A gernealized parser for a software language with a fixed lexicon was difficult enough. I suppose a compiler could be classified as AI.

Based on a general definition for me the question is what is not AI when it comes to software? All coding represents how a human reasons through a problem.

I did take a class in Theory Of Computation. Language generation and parsing, trees and graphs. It turns out a generalized parser can not be implemented by traversing a logic tree. For example imbedded bracess can not be parsed with logic alone. It requires push down automaa, IOW a Turing Macjhine with a stack.

AI is concerned with simulating human reasoning and behavior, but engineering is concerned with practical applications of theory. So the two have very different goals.

Bear in mind that there are essentially three types of human reasoning: deduction, induction, and abduction. Deduction is essentially math and logic--arriving at an inference that is consistent with a set of premises. So we deduce that adding two and two yields four. Induction is based on observation--arriving at an inference based on what can be tested. So we infer that a car has sufficient fuel by checking the gas gauge. Abduction is based on world knowledge--arriving at an inference on the basis of general knowledge we have acquired about the world. So we infer that someone has recently been at a location and left if we find a lit cigar still burning at that location.

Computer programs are pretty good at deductions, and ok at many types of induction, but they are terrible at abduction. Programs that deduce things aren't considered AI, and people debate over whether something like an expert system should be counted as a form of AI. However, we normally have to program computer programs with all the world knowledge they have, unless they can learn things on their own and then apply that new knowledge to making inferences. AI is particularly concerned with the field of machine learning these days for precisely that reason. There simply isn't any straightforward solution to the implementation of abduction, and nothing we have will scale up to human-level world knowledge. Hence, it is particularly impressive that we can now build walking robots that can navigate mazes or drive cars through traffic without human guidance. What is particularly difficult is getting an autonomous vehicle to infer that another vehicle is driving erratically and possibly out of control because it didn't stop for a traffic light. Programmers can't think of all the things that could go wrong, and computer programs can't easily gain new insights into how things work by building on experience. We're working on it.

 

[steve_bank]

In the ancient world the development of water proof concrete, understanding the strength of wooden beeams and arches were revolutionary. It had a material impact on civilization.



In the late 19th century Maxwell’s electromagnetics and quantum mechanics led to electronics which had a major impact on civilization. Not the least of which is 24/7 global Internet.


I just don’t see any major impact of AI. A public domain medical AI that given inputs can provide a range of diagnosis would be beneficial.

AI that looks for stock market patterns for investors is not exactly a wide scope benefit. In fact in the 80s AI caused a Chicago commodities market exchange to collapse. AI software used by traders told a lot of peole to sell at the same time.

Autonomous self driving AI is more of a a novelty but not all that important. AI just does not live up to the hype.

One of the first tools to create computer;languages and compilers was YACC and LEX and I think they are still available. YACC -Yet Another Compier Compiler, LEX – Lexical Analyzer. Together theytake a language definition and create a parser that translates text like C code to assembly language for a target processor.

I expect AI is similar, languages or scripts and compiler functions. To me nothing mysterious or profound or Earth shattering. A natural evolution.

AI is the application of logic using rules and axioms and theorems. As is engineering. It is all the same mental processes and problem solving.


I was not a dedicated software enineer bur I wrote code. Embedded digital signal processing and numerical math code. AI to me is just anoter dscipline that I would laarn if I had a need to.

 

[Copernicus]

...I was not a dedicated software enineer bur I wrote code. Embedded digital signal processing and numerical math code. AI to me is just anoter dscipline that I would laarn if I had a need to.

Sadly, in my quarter century experience as an employee at Boeing, I discovered that a great many engineers, perhaps the majority, had this naive view of what it took to become an AI researcher. So I'm not the least bit surprised that you would say that. However, a pragmatic, positive attitude and programming expertise are not enough to cut it in the field of AI. You also have to have a mix of other skills, some of which you can only get from the soft sciences and humanities. Otherwise, you can easily go down a well-worn garden path with solutions that have been tried and failed in the past as you become familiar with what you don't know about language, vision, hearing, touch, volition, and other subjects. It is a lot easier to try to simulate behavior that you know something about. I've worked with some really excellent engineers, who have taken the time to educate themselves better in the subject matter.

I'm familiar with YACC and LEX, of course, because they are excellent tools for working with text patterns. However, they are no substitute for high level languages like LISP in AI. The brain is a giant connectionist analog computer, so a list processing language starts you off with a convenient means of processing linked lists right out of the box. The advantage is that all of the memory management is already taken care of very efficiently and you don't have to worry about the nasty buffer overflows that can plague programmers working with structures of indeterminate size. There are other programming languages that work well for AI applications (e.g. Prolog), but none of them are as rich or bulletproof as the one that has been in constant use and development the longest.

 

[lpetrich]

I'm familiar with YACC and LEX, of course, because they are excellent tools for working with text patterns. However, they are no substitute for high level languages like LISP in AI. The brain is a giant connectionist analog computer, so a list processing language starts you off with a convenient means of processing linked lists right out of the box. The advantage is that all of the memory management is already taken care of very efficiently and you don't have to worry about the nasty buffer overflows that can plague programmers working with structures of indeterminate size. There are other programming languages that work well for AI applications (e.g. Prolog), but none of them are as rich or bulletproof as the one that has been in constant use and development the longest.

Memory bugs are a problem with C and C++, but in no other widely-used high-level languages, as far as I know. That's because C uses pointers to memory, with no control over what is a valid access and what is not. So unless one is very careful, one will get lots of memory bugs.

C++ is an overlay on C with lots of ways to avoid using pointers explicitly. Call by reference uses pointers behind the scenes, as do the Standard Template Library container classes. Object classes have destructor methods, for cleaning up when an object goes out of scope. These methods are inserted automatically where needed, so one does not have to put them in by hand.

Most other high-level languages don't have pointers, though they do have object references and array references.

But if C is so troublesome, then why use it? Performance. It has essentially zero object-management overhead, unlike (say) Java, which has a little, and (say) Python, which has a lot. With C++, one can the performance of C without many of its awkward and dangerous features.

 

[steve_bank]

There were a number of C compilers and some were buggy. Anybody remember Franklin? In the 80s and early 90s I used Borland.

There was no C standard and implementations were nor always the same and there were extensions specific to a vendor.

C++ came abut in part because code size became large and hard to debug and maintain. One odf the C problems was unrestriced pointers that allowed errant ponters to crash a system or corrupt data. Data and code inside an object can be made invisible to outside code. One way I used C++ was managing large data sets and calibration tables for test and measurement systems.

The point about YACC and LEX is that AI is just another discipline that has evolved with a set of tools. Nothing out of the ordinary as things go.

Digital Signal Processing is far more widespread than AI. You will never see a media report on DSP.

Digital audio is based in DSP.

The Chicago commodities excange is an example of relyingtoo much on AI to do your thinking for you. Peole with no knowledge of comoodit trading using software that analyzed the market and tells you what and when to buy or selll.

 

[Loren Pechtel]

Memory bugs are a problem with C and C++, but in no other widely-used high-level languages, as far as I know. That's because C uses pointers to memory, with no control over what is a valid access and what is not. So unless one is very careful, one will get lots of memory bugs.

Even in managed-memory languages you can have memory leaks.

class Tree
{
   TreeNode Root;
}

class TreeNode
{
   TreeNode Sibling;
   TreeNode Child;
   Tree Head;
}

 

[Jarhyn]

Memory bugs are a problem with C and C++, but in no other widely-used high-level languages, as far as I know. That's because C uses pointers to memory, with no control over what is a valid access and what is not. So unless one is very careful, one will get lots of memory bugs.

Even in managed-memory languages you can have memory leaks.

class Tree
{
   TreeNode Root;
}

class TreeNode
{
   TreeNode Sibling;
   TreeNode Child;
   Tree Head;
}

Something I have had to deal with a number of times, one of the most annoying of all the families of bugs, are memory usage bugs.

In managed languages, it is particularly annoying because all the "easy" tooling is wasteful and makes a bunch of allocation assumptions.

For instance you can't specify the allocation model or system for the majority of boilerplate operations like string copies so you can't do it in fast userland contexts, and interspersing variable width or growing width allocations with small allocations can cause memory to get turned into a chopped up swiss cheese. An inability to gather sufficient contiguous blocks is doom for many systems.

Worse, massively parallel string operations (or string operations on long buffers) can end up utterly destroying the memory allocation, too: they don't all get reference counted and returned at the earliest opportunity because that would lead to increased overhead for system calls, but then you can run out when you are parsing a 40 megabyte buffer with a sentiment analysis engine.

And then as you note, circular reference blocking GC identification.

And then there's the whole issue of address space mutilation in 32 bit systems.

In some ways I like how C++ makes you clean up your own damn messes. There are a few HTM projects on a C++ platform, but all the high level organization is done in Python.

All the really core control processes usually end up being some loosely typed, highly mutable, simple-to-use script style elements. It's almost like...

 Moravec's paradox

 

[lpetrich]

Memory bugs are a problem with C and C++, but in no other widely-used high-level languages, as far as I know. That's because C uses pointers to memory, with no control over what is a valid access and what is not. So unless one is very careful, one will get lots of memory bugs.

Even in managed-memory languages you can have memory leaks.

How do such memory leaks happen?

 

[steve_bank]

It happems when you do not deallocate memory when it is no longer needed. In the good old days with 64k memory C was powerful because you could dynamically allocate memory and use pointers most anywhere, but it required diligence.

Fragmentation. If you are dynamically allocating and deallocating multiple numerical arrays for which you do not know size before hand you can run out of room for an array. The same thing happens on disk.

In C++ one of features is dynamically spawning objects as well.

I am used to calling code to defrag memory a 'garbage collector'.

The compiler should allow you to see the symbol table. It tells you where everything is located.


When you dynamically allocate memory and an array such as a string you should be able to get the address from the pointer.

The OS probably sets the size of the heap but there may be ways to increase it.

Garbage collection (computer science) - Wikipedia

en.wikipedia.org

n computer science, garbage collection (GC) is a form of automatic memory management. The garbage collector attempts to reclaim memory which was allocated by the program, but is no longer referenced—also called garbage. Garbage collection was invented by American computer scientist John McCarthy around 1959 to simplify manual memory management in Lisp.[2]

Garbage collection relieves the programmer from performing manual memory management where the programmer specifies what objects to deallocate and return to the memory system and when to do so. Other similar techniques include stack allocation, region inference, memory ownership, and combinations of multiple techniques. Garbage collection may take a significant proportion of total processing time in a program and, as a result, can have significant influence on performance.

Resources other than memory, such as network sockets, database handles, user interaction windows, file and device descriptors, are not typically handled by garbage collection. Methods for managing such resources, particularly destructors, may suffice to manage memory as well, leaving no need for GC. Some GC systems allow such other resources to be associated with a region of memory that, when collected, causes the work of reclaiming these resources.

 

[Copernicus]

If one is interested in Artificial Intelligence, the last thing one wants to worry about is garbage collection and other low level details. However, if you want to spend all your time pulling weeds rather than planting a garden...

 

[steve_bank]

If one is interested in Artificial Intelligence, the last thing one wants to worry about is garbage collection and other low level details. However, if you want to spend all your time pulling weeds rather than planting a garden...

Good to know. Nice metaphor.

Is there anything pro or con on how AI is misunderstood or misrepresented in pop culture?

 

[Copernicus]

If one is interested in Artificial Intelligence, the last thing one wants to worry about is garbage collection and other low level details. However, if you want to spend all your time pulling weeds rather than planting a garden...

Good to know. Nice metaphor.

Is there anything pro or con on how AI is misunderstood or misrepresented in pop culture?

I think that Emily's article cited in the OP is a good place to start. The current state of the art will not scale up to real intelligence, but the problem is not just that AI is overhyped. People have a very strong tendency to project themselves into the way they model reality, so they find it difficult not to think of even very simple, stupid computer programs as smart and socially interactive. Byron Reeves and the late Cliff Nass did a number of experiments in the 1990s on this subject that dramatically demonstrated the effect of what they called  The Media Equation. Even programmers, who ought to know better, are not immune to the effect. Their early work inspired Microsoft's development of "Clippy the Paperclip" in an early attempt at an intelligent interface called  Office Assistant. Byron and Cliff quite vociferously denounced Clippy and denied all responsibility for it in their presentations, which made a point of proudly emphasizing their connection to it. But, given this propensity, it is no wonder that the field of AI would inspire such a distorted view of what computers are capable of.

 

[steve_bank]

There also marketing to pomote AI based products.

Most today who did not live pre PCs do not realize the original MS Office suite actually reduced what were good paying skilled and semi skilled jobs. Few today would have adnistrative assitants to do typing, hnadle communicatiosns and the like. Most trype communications for themselves and emil.

A minority complaint about loans is being denied a koan based on AI that looks at databases without any human interaction. Bis of many kinds can and do find its way into how an AI lie that works. A simple example weighting a home loan by zip code.

Business will use AI to reduce coast of labor.

There is a tool that analyzes voice and facial expressions to build a psychological profile for use by a hiring manager. To me a scary aspect of AI.

There is also concern over autonomous AI used for weapons.

 

[Loren Pechtel]

Something I have had to deal with a number of times, one of the most annoying of all the families of bugs, are memory usage bugs.

In managed languages, it is particularly annoying because all the "easy" tooling is wasteful and makes a bunch of allocation assumptions.

For instance you can't specify the allocation model or system for the majority of boilerplate operations like string copies so you can't do it in fast userland contexts, and interspersing variable width or growing width allocations with small allocations can cause memory to get turned into a chopped up swiss cheese. An inability to gather sufficient contiguous blocks is doom for many systems.

I've got the source for a program around here that has a memory allocator that has really annoyed me. I can find nothing in it that should have more than a few hundred megabytes, I can't get anything to admit to any allocations I don't see--but at about 10,000 entries it basically brings my machine to a halt due to thrashing the page file. Unfortunately, it's not my code and I'm not sure what some bits are doing.

 

[Loren Pechtel]

Memory bugs are a problem with C and C++, but in no other widely-used high-level languages, as far as I know. That's because C uses pointers to memory, with no control over what is a valid access and what is not. So unless one is very careful, one will get lots of memory bugs.

Even in managed-memory languages you can have memory leaks.

How do such memory leaks happen?

Look at the example I gave: https://iidb.org/threads/common-misunderstandings-about-artificial-intelligence.26127/post-1013699

I'm not aware of a garbage collector that can clean that up. It is a very common scenario when you're dealing with graphs (note that I'm using this in the mathematical sense.) Some languages have the concept of a weak reference to deal with things like--the children pointing at the parent aren't counted as references to keep the parent alive. I have not looked into the details because I've never had an occasion to care--the only times I've had to deal with graph type structures the data is loaded once and remains in memory, the fact that it won't clean up properly is irrelevant.

Note that you can also leak external resources. Say, database connection handles.... And just because it's a garbage-collected language doesn't mean everything it does is garbage collected. Real world example:

        public static bool SendStringToPrinter(string SzPrinterName, string SzString)
        {
            IntPtr PBytes = Marshal.StringToCoTaskMemAnsi(SzString);
            try
            {
                return SendBytesToPrinter(SzPrinterName, PBytes, SzString.Length);
            }
            catch (Exception Ex)
            {
                throw new Exception($"Printer = {SzPrinterName}\n{Ex.Message}");
            }
            finally
            {
                Marshal.FreeCoTaskMem(PBytes);
            }
        }

Yeah, some Hungarian crap in there--while I've cleaned up the original a fair amount I didn't clean everything. Note that the memory pointed to by PBytes will not be garbage collected, if I didn't clean it up in the finally it would leak. In hindsight I see that the conversion from string to IntPtr should have occurred in SendBytesToPrinter rather than here. The device on the other end of this is an industrial label printer (about the size of a PC, but shorter and fatter), I don't know if it supports a standard device canvas but a standard canvas certainly does not support some of the things it can do--hence "I" speak to it in it's language. (Actually, I'm cheating--my code knows nothing of how to speak to it. Rather, the guy who actually uses it uses the design program that came with the printer to make a label, except for the most part the text is things like %jobname%. He prints that label to a file, I read the file in making the substitutions and send it on to the printer. Neither of us actually know the command set, there's been no need to figure it out.)

 

[Jarhyn]

Something I have had to deal with a number of times, one of the most annoying of all the families of bugs, are memory usage bugs.

In managed languages, it is particularly annoying because all the "easy" tooling is wasteful and makes a bunch of allocation assumptions.

For instance you can't specify the allocation model or system for the majority of boilerplate operations like string copies so you can't do it in fast userland contexts, and interspersing variable width or growing width allocations with small allocations can cause memory to get turned into a chopped up swiss cheese. An inability to gather sufficient contiguous blocks is doom for many systems.

I've got the source for a program around here that has a memory allocator that has really annoyed me. I can find nothing in it that should have more than a few hundred megabytes, I can't get anything to admit to any allocations I don't see--but at about 10,000 entries it basically brings my machine to a halt due to thrashing the page file. Unfortunately, it's not my code and I'm not sure what some bits are doing.

This is one of the most frustrating things... Also the circular reference issue.. gross!

@lpetrich the reason this happens is that there is a piece of code around reference and dereference operations that counts how many references there are to the underlying allocation object.

Because the member points to the head, the head will not reach zero references until all children are cleaned up, which never happens because the idiot programmer will likely only free and null the pointer to the head of the list, or worse just let it drop off the stack.

The fact there are still active references to the head keeps the head from being deleted, and the head referencing the child keeps the child alive, and then all the way down the child chain.

Without head and reverse pointers in the list, the head reference hits zero, then the first child, then all the way down.

All doubly linked lists as a result need to have their pointer tree nulled out for them to go back to GC.

(Actually, I'm cheating--my code knows nothing of how to speak to it. Rather, the guy who actually uses it uses the design program that came with the printer to make a label, except for the most part the text is things like %jobname%. He prints that label to a file, I read the file in making the substitutions and send it on to the printer. Neither of us actually know the command set, there's been no need to figure it out.)

That's completely and utterly disgusting, and absolutely par for the course in most programming I've seen.

I have one for you: allocation for Google Protobuff structtures occur into an internally managed memory pool.

That pool then is garbage collected, even in C++ implementations using reference counts, because all allocations tend to be small and it doesn't want to be in a situation to expose that kind of nickle-and-dime bullshit to the system call stack.

But if you're shoving a lot of data through that, fast, well... It ends up growing the high water mark because it doesn't cycle through to GC fast enough.

The result is that it completely occupies the pagefile with cache page allocations to the Protobuff stack, just because it's being asked to allocate faster than the GC can keep up.

The end result is that if you send too much too fast, it chokes the GC, the program gets a sigabort of Segfault, and throws you out.

 

[Loren Pechtel]

(Actually, I'm cheating--my code knows nothing of how to speak to it. Rather, the guy who actually uses it uses the design program that came with the printer to make a label, except for the most part the text is things like %jobname%. He prints that label to a file, I read the file in making the substitutions and send it on to the printer. Neither of us actually know the command set, there's been no need to figure it out.)

That's completely and utterly disgusting, and absolutely par for the course in most programming I've seen.

You pass something directly to the Windows API without going through the .Net framework and you have to provide an actual pointer--and that means an allocation outside the framework to guarantee the garbage collector doesn't move it while Windows is working with it.

I have one for you: allocation for Google Protobuff structtures occur into an internally managed memory pool.

That pool then is garbage collected, even in C++ implementations using reference counts, because all allocations tend to be small and it doesn't want to be in a situation to expose that kind of nickle-and-dime bullshit to the system call stack.

But if you're shoving a lot of data through that, fast, well... It ends up growing the high water mark because it doesn't cycle through to GC fast enough.

The result is that it completely occupies the pagefile with cache page allocations to the Protobuff stack, just because it's being asked to allocate faster than the GC can keep up.

The end result is that if you send too much too fast, it chokes the GC, the program gets a sigabort of Segfault, and throws you out.

I don't have any throughput problems--if I never cleaned up those strings it would never cause a crash anyway because the amount of data is small. The biggest file is about 4k (and that because it contains some sort of graphic) and most are under 1k--and there's no station out there that's going to do even a thousand of them before the computer is turned off for the night.

 

[Jarhyn]

(Actually, I'm cheating--my code knows nothing of how to speak to it. Rather, the guy who actually uses it uses the design program that came with the printer to make a label, except for the most part the text is things like %jobname%. He prints that label to a file, I read the file in making the substitutions and send it on to the printer. Neither of us actually know the command set, there's been no need to figure it out.)

That's completely and utterly disgusting, and absolutely par for the course in most programming I've seen.

You pass something directly to the Windows API without going through the .Net framework and you have to provide an actual pointer--and that means an allocation outside the framework to guarantee the garbage collector doesn't move it while Windows is working with it.

I have one for you: allocation for Google Protobuff structtures occur into an internally managed memory pool.

That pool then is garbage collected, even in C++ implementations using reference counts, because all allocations tend to be small and it doesn't want to be in a situation to expose that kind of nickle-and-dime bullshit to the system call stack.

But if you're shoving a lot of data through that, fast, well... It ends up growing the high water mark because it doesn't cycle through to GC fast enough.

The result is that it completely occupies the pagefile with cache page allocations to the Protobuff stack, just because it's being asked to allocate faster than the GC can keep up.

The end result is that if you send too much too fast, it chokes the GC, the program gets a sigabort of Segfault, and throws you out.

I don't have any throughput problems--if I never cleaned up those strings it would never cause a crash anyway because the amount of data is small. The biggest file is about 4k (and that because it contains some sort of graphic) and most are under 1k--and there's no station out there that's going to do even a thousand of them before the computer is turned off for the night.

Yeah if the system has a chance to clear cache before it needs to reallocated there's no malfunction at all. The error got fixed by just making the structure less spammy.

Now it only sends finalized data and only once it finalizes the measurement, and it eats... Well, I'm pretty sure it's a factorial less of data.

 

[lpetrich]

For the last half-century, AI has had a war between the neats and the scruffies.  Neats and scruffies and What is Neats Vs Scruffies? - Definition from Techopedia

The “neats” prefer to advance in a way that is completely documentable and provable, in a method that is clear and logically supported. “Scruffies,” on the other hand, may embrace “fuzzier,” more diverse, or more ambiguous methods that support results. Neats vs. scruffies has also been described as “logical versus analogical” and “symbolic versus connectionist.”

... Experts point out that due to the deep philosophical differences between neats and scruffies, neats may view scruffies’ methods as happenstance or insufficiently built, where scruffies might see neats’ methods as being restrictive and limiting to the exploration of the goals in question.

AI started out with "neat" methods - symbol manipulation. That was good for programming-language translation and for computer algebra, but not for much else. For those two applications, one needs results that are provably correct, not just a best fit, though optimization can be a bit scruffy in what methods one uses.

But much recent AI has been "scruffy", starting in the 1980's with the revival of connectionism as artificial neural networks. The best natural-language translation has been done in a scruffy fashion, with statistical models, even though in the early years of AI, it seems very suited for neat methods. But natural languages are often very complicated, and that's what's given the success of scruffy methods there.

 

[Copernicus]

For the last half-century, AI has had a war between the neats and the scruffies.  Neats and scruffies and What is Neats Vs Scruffies? - Definition from Techopedia

The “neats” prefer to advance in a way that is completely documentable and provable, in a method that is clear and logically supported. “Scruffies,” on the other hand, may embrace “fuzzier,” more diverse, or more ambiguous methods that support results. Neats vs. scruffies has also been described as “logical versus analogical” and “symbolic versus connectionist.”

... Experts point out that due to the deep philosophical differences between neats and scruffies, neats may view scruffies’ methods as happenstance or insufficiently built, where scruffies might see neats’ methods as being restrictive and limiting to the exploration of the goals in question.

AI started out with "neat" methods - symbol manipulation. That was good for programming-language translation and for computer algebra, but not for much else. For those two applications, one needs results that are provably correct, not just a best fit, though optimization can be a bit scruffy in what methods one uses.

But much recent AI has been "scruffy", starting in the 1980's with the revival of connectionism as artificial neural networks. The best natural-language translation has been done in a scruffy fashion, with statistical models, even though in the early years of AI, it seems very suited for neat methods. But natural languages are often very complicated, and that's what's given the success of scruffy methods there.

My comment on this is that Roger Schank's brilliant work focused on dialog analysis, which is very useful for some types of language analysis, but not others. The "neat" types of analysis included some really pioneering work in statistical analysis that was exceptionally useful in processing monologues--i.e. texts by single authors intended for a large audience rather than limited interchanges between individuals. So Schank's metaphor was particularly unhelpful, because it did not address the very different types of language problems that both approaches tried to address. After the 1980s, when this metaphor was an active topic of discussion in AI, it was discovered that statistical and mathematical approaches to text analysis failed to scale up to the kinds of problems that people wanted to address--for example, human-robot command and control or detection of sensitive information in text. The "neat" statistical approaches could highlight paragraphs that might contain sensitive information, but they failed to detect a lot of sensitive detail at the level that would be useful for, say, a security analyst. The point here is that different AI techniques have limited usefulness for specific problems, but real intelligence is able to do both "scruffy" and "neat" analysis of language.

In the kinds of applications that I specialized in--for example, the enforcement of clear writing standards--statistical language checkers were extremely unhelpful in pinpointing language that violated the standard. Customers for that type of application, i.e. technical writers, needed to see specific constructions that violated the standard. The statistical parsers that attempted to help only looked at statistical frequencies of words within a text window, not at the grammatical structures that were called out in the standard. OTOH, our deep-grammar analysis of sentences was not as efficient or useful in text mining applications that were used to identify, say, recurring patterns of mechanical failures in huge databases of reported mechanical failures. Different solutions for different problems.