Resistance to AI Automation will crumble

And I don't mean The Resistance to Terminators.

Al automation promises to revolutionize white-collar or office work. Some think there’s plenty of resistance against quick AI adoption and so there won’t be major negative societal disruptions. I’ve come to believe that resistance will crumble.

Legal and copyright issues could slow AI down, but not for long.

AI generated code may be hard to accept into proprietary code bases due to legal uncertainty, e.g., copyright issues.  For example, the Google v Oracle Java lawsuit started in 2010 and reached conclusion in the Supreme Court in 2021.  That’s 11 years of legal uncertainty over whether there was copied code.

Having said that, Google kept using the disputed technology through those years of litigation.  There are ways around legal issues like that I presume.  And the legal cases against AI are already underway as in the Github Copilot lawsuit [1], so the clock is already ticking — and currently, the AI side is winning [2].

It feels there's some amount of inevitability at play too in terms of resolving the copyright issues.  The actors' guild has agreed to a contract allowing limited AI usage with major media companies. OpenAI is securing deals with media companies to train and utilize their copyrighted materials. The writing is on the wall, and AI is writing it.

People and companies are resistant to change, but new folks will jump ahead

Some say "The future is already here; it's just unevenly distributed" (William Gibson).

One reason that happens is that status quo lowers risk.  If you're Apple and if you have AI that can do the work of half your software development workforce, do you layoff 50% of SDEs?  No.  No one has the risk tolerance for that big a move all at once.  What if you were wrong?  What if the wrong automation tech is used, or the people you hire to manage that get it wrong?  Betting "all in" on a single roll of the dice is too risky.

Not without an external crisis, at least.

The oil and gas industry used to employ a lot of people.  Until oil price crashed and belt tightening resulted in lots of layoffs and automation.  Those jobs are never coming back because they were automated away [11].  But without the price crash, the amount or severity of layoffs might not have been as bad.

After all, one way for a manager to get promoted is by managing more people and a bigger budget.  So the status quo of using more people than automation is a self-interested move.  A crisis like a big oil price crash is required to shake that status quo loose.

But new companies don't have the same status quo problem.  Old companies will either succeed or fail.  New startups with come in with automation and AI baked in to reduce cost, extend their funding runway, and to get product market fit faster.

Old Tech will eventually come around to automation anyway

People say that it's normal for FAANG type companies to lose 5% or more tech workers every year for various reasons [3].  Attrition, eliminating teams of projects that get cancelled, "unregretted attrition", etc.  Depending on the speed of AI automation progress, old tech companies can just keep up with 5% unregretted attrition each year to slowly turnover the company to AI.

Some might say it's already started since 2022 [4].

And for those old stuffy companies who don't come around fast enough to automation?  They can always turn from being an engineering company into a financial engineering firm, like Siemens, IBM or GE.

I’m kidding! Slightly.  But just because Air Canada will probably think twice about using AI for customer service after that lawsuit [8], that doesn’t mean they won’t outsource to an AI customer service startup that’s also willing to defend them against lawsuits.

Lump of Labour fallacy is about the whole economy, not a single sector

Some say don't worry about AI automation producing negative societal disruptions in the form of making everyone unemployed because Lump of Labour is a fallacy [6].

The Lump of Labour fallacy misconception is that there's only a fixed amount of work to be done, so don't worry about automation taking work away from people!  There'll always be more work invented by people to do!

Some would say this time is different because AI could do that newly invented work too.  But even without this AI-everywhere angle, you have to see that the type of work may be different.

When manufacturing and software development work gets automated, what new work is there to do?  Those workers can re-skill into making TikTok influencing channels?

Some say “yes, of course”, but there's just no guarantee that the new work would be "better" (e.g. higher abstraction of code, safer workplace, higher paying, improved quality of life at work).  It could be worse or more dangerous.  As climate change gets worse, maybe those displaced tech workers can re-skill into forest fire fighting?  I doubt non-robotic LLMs can do that.

Jevons Paradox applies to things people want, not things people are ambivalent about or worse

Some say don't worry about AI automation making office/tech/programming workers unemployed because Jevons says greater efficiency will induce more demand for software, etc. [6]

Jevons Paradox states that increased efficiency leads to increased consumption.  i.e. as X becomes more efficient, more X will be used. Substitute X with:

• Oil
• Gas
• Electricity
• Microsoft Office

Look, people want dogs and cats.  But generally speaking, people aren't into wanting software developers and assembly line workers.

USA is manufacturing more than ever, but is employing fewer manufacturing workers than ever. Maybe AI will let us substitute "manufacturing" with "software developing" in that sentence.

Consumers want the goods, not the people producing them (see: offshoring).  If AI can produce it cheaper with fewer humans involved and without animal testing, then consumers would want that instead (mainly because it's cheaper).

So at best, Jevons says people will want more software and apps than ever before because they'll get more efficient with AI.  But nothing says that the code has to be written by humans.

In fact, we've seen this last point before.  Practically no one writes the assembly code that those software requires written to work — compilers write that automatically for us since decades ago.

Fortunately, assembly code programmers could easily up-skill to higher level languages like Java.  With AI, coders may have to up-skill to higher level languages like English, and compete with all the non-coders who can already English better than them.

Software developers will work at higher levels of abstractions.  Yes, and so can everyone else

Some say software developers shouldn't worry about automation taking their jobs, because at best AI can spit out code given some architecture and specifications for problems that the human software developer has to write up into prompts.  So the human SDE can now work at a higher level of abstraction, work at system design levels and above, double check the code that AI produced to make sure there's no hallucinations.

Sure, yes.  But what evidence is there that BSc graduates with education in algorithms and data structures can write those prompts better than, e.g., BA philosophy graduates who trained in close-reading, analyzing, and writing highly technical English in all their Analytic Philosophy classes?

There's also a lot of LLB lawyers who are underemployed in the legal or adjacent fields doing paralegal or repetitive property conveyancing work.  Maybe some of them can do this AI software development prompting better than CS/SDE graduates?

In fact, we've seen this broadening (or democratizing) of a labour field before.  It used to be highly technical and challenging work to do special event photography.  You have to get the lighting, shutter speed, and aperture just right or else you'll miss the moment, or waste and run out of expensive film.  Digital SLR photography and big inexpensive memory cards means many with an eye for beautiful photos can now do wedding photography, take 1000s of photos, then choose the best 50 afterwards.  Or just fix it in "post" with Photoshop.

This means sky-high compensations or job security will come down, if not in one field (tech), then maybe in any field that's at risk of AI automation (all white collar or office jobs).

AI is a bubble, until it’s not

The last few points focused more on software development, but that’s a canary in the coal mine.  Some say software development is more resistant to AI automation because it’s already in the business of automation [7].  But that just means that if (since?) software engineering labour is at risk, then many other fields are also at risk too.

Some say AI is like crypto.  It’s all hype and a bubble run like or by some of the same personalities.  But that’s a useless comparison.  Can you, in 1999, tell if the internet is a bubble or not based on how tulips were a bubble [9]?  They’re just not the same.  And at least with AI there are clear and present use-cases, no AGI required.

So forget AGI.  Resistance to automation will crumble.  There's too much money to be made in automating even just 10% [10] of the white-collar or office work labour market, in whole or in part, outright or by “just” improving human efficiency.  That's the "killer app" of AI.

Don’t focus so much on the automating a worker outright-in-whole part.  Instead, focus on the replacement in-part, by “just” improving human efficiency, part.  E.g. Self-checkout didn’t eliminate “cashiers”, but allows one supervisor to do the work of (say) three cashiers.

How much profit can this “killer app" make that would justify the (non) bubble?  I lazily checked with Meta AI and it says:

• telemarketing and public opinion researchers (including call center representatives) in the USA in 2020 probably had compensation of about $100B
• software developers (including applications and systems software developers) employed in the USA in 2020 made about $200B
• office managers, supervisors, support and assistants employed in the USA in 2020 made about $200B

That’s $500B right there. So by automating even just 10%, it’d take just 10 years to fill the $500 billion dollar revenue gap [5].  That percentage will go up, the addressable market is not just the USA, and there are many other labour fields to automate than those.

That’s why I think AI adoption will be quicker and there’ll be more negative societal disruptions coming up.  We can’t all re-skill to fight forest fires.

EDIT: To clarify, I don't mean for sure tech or any other jobs will definitely get decimated by AI efficiency gains.  It's just that quoting "Jevons" or "Lump of Labour" isn't a knock-out against that possibility.  The analysis has to be deeper than just invoking those, by now, thought-stopping thoughts.

Let me volunteer one possibility, for example, AI makes coding jobs 10% more efficient, meaning cost of labour is reduced.  Because cost of software production goes down, consumers want more apps, so much more than the 10% efficiency gains allow that more humans developers are needed.  This is the classic rebound effect in Jevons.  Notice it requires consumers to want so much more apps that it more than offsets the 10% efficiency gains — there is no guarantee it rebounds that much!

EDIT 2: Also, jobs getting decimated by AI efficiency gains is not necessarily bad!  Machines decimated coal mining jobs, which is bad for jobs, but given there are better alternate jobs, it was great for the health and safety of would-be coal miners!


[1]: https://www.artificialintelligence-news.com/news/openai-and-microsoft-lawsuit-github-copilot/

[2]: https://www.developer-tech.com/news/judge-dismisses-majority-github-copilot-copyright-claims/

[3]: https://www.seattletimes.com/business/amazon/internal-amazon-documents-shed-light-on-how-company-pressures-out-6-of-office-workers/

[4]: https://layoffs.fyi

[5]: https://blog.carsoncheng.ca/2024/07/re-500b-ai-revenue-expectations-gap.html

[6]: AI and the automation of work. https://www.ben-evans.com/benedictevans/2023/7/2/working-with-ai

[7]: I believe Yann LeCun said something like that but I can’t find the source.

[8]: https://www.cbc.ca/news/canada/british-columbia/air-canada-chatbot-lawsuit-1.7116416

[9]: https://en.m.wikipedia.org/wiki/Tulip_mania

[10]: https://news.ycombinator.com/item?id=41465081 - study says there's a 26.08% increase in productivity with AI, and more specifically a 27% to 39% for junior level and 8% to 13% at senior level.  So my "10%" guess wasn't too bad?

[11]: https://www.parklandinstitute.ca/job_creation_or_job_loss - “the Big Four are leading the push to automate away even more jobs in the coming years … The Alberta oil and gas industry employed 25,788 fewer workers in 2021 than in 2014 (a 15.5% reduction)”

Labour Automation vs Growth

Automation in oil and gas reduced labour needed to extract and produce oil. Oil as a product is not a platform-platform. Oil usage cannot induce demand for ever more oil by being a medium for platforms that can recursively host more platforms of products. Because oil does not induce exponential demand, then automation has a good chance of reducing labour down.

The flip side is that platform-platforms can recursively host more platforms of products. So platform-platforms has a chance to induce exponential demand, and so while automation reduces labour per unit produced, on the whole the exponential demand for units can balance out if not even increase labour required industry-wide.

C compilers are not platform-platforms. Compilers in general basically eliminated all assembly programming labour. The reason there are more programmers now than when assembly language reigned supreme is not because compiler automation freed up labour for more creative things. The reason is more because that other platform-platforms like the internet and operating systems induced exponential demand for software.

Other examples of automation that are not platform-platforms and in fact eliminated a lot of labour include:

• Manufacturing automation
• Bookbinding automation (replaced by printing presses)
• Telephone switchboard automation (replaced by digital systems)

Jevons Paradox states that increased efficiency leads to increased consumption.  i.e. as X becomes more efficient, more X will be used. Substitute X with:

• Oil
• Gas
• Electricity
• Microsoft Office

But software developers? Or assembly line workers? USA is manufacturing more than ever, but is employing fewer manufacturing workers than ever. Maybe AI will allow us to  substitute "manufacturing" with "software developing" in that sentence.

Jevon's Paradox "works" only for items that consumers actually want. If extreme environmentalism "won", gas usage would go down no matter how efficient gas engines get. If coal-powered SUVs became unreasonably ultra trendy, coal use would go up regardless of how inefficient coal was.

Software development and manufacturing workers are not goods that consumers want. They want what's produced. And if AI can produce it cheaper with fewer humans involved and without animal testing, then consumers would want that instead.

The Internet is a Platform-Platform. AI is not.

AI is not like the internet or computer operating system software in terms of its economic impact.

The latter two are platform-platforms while AI is not.

A platform is a kind of medium.  e.g. YouTube is a platform for videos.

Some platforms are special in that they are recursively platforms for platforms.

Computer hardware are platform-platforms.  They're a medium for various single purpose built software, of course, but more importantly they are also a medium for different operating systems (OSs).

OSs like macOS or Windows are platform-platforms.  The most easiest and reductive way to see this is that you can virtualize and run macOS on Windows, and vice versa.  More substantively, these OSs can run internet or web browsers.

Internet and web browsers and the physical internetwork they connect to form platform-platforms.  Different businesses run on the web, but more importantly, the web or internet are a medium for running app stores on desktop and mobile devices.

Is AI a platform-platform?  What is it a medium for?  Does this medium support a platform recursively?

Or is AI more like a sufficiently smart general compiler?  AI can automate existing products and workflows, but it isn't a medium that will enable more products exponentially by carrying platforms on platforms … on platforms.

Others have noted similar ideas.  e.g. AI is a feature, not a product.  Actually, it's worse: "AI is a tech to enable a feature, not a feature in itself" [1].

Or that current AI are automated "infinite interns that can write anything for you" [2].  But follow that train of thought to the conclusion that a human-level current-generation AI would be an actually-human intern and now wonder: since when do human interns (even an infinity of them) form a medium that can be a platform for platforms?  (… unless you use them like transistors, to do computation as a human powered Turing machine, just to argue they can do what actual computers can already do.)

This distinction between products and platforms vs platform-platforms can inform us on the economic impact of AI on society.

 

 [1]: ( https://www.threads.net/@benedictevans/post/C8C00e5OZBT )

 [2]: ( https://www.ben-evans.com/benedictevans/2023/7/2/working-with-ai )

 

Jevons Is a Paradox, Not a Rule

Jevons Paradox says that as technology becomes more efficient, overall resource consumption can increase. This was seen during the Industrial Revolution when more efficient coal engines led to higher coal usage. However, this paradox is not universal, and efficiency can also lead to reduced resource consumption.

In the context of AI coding tools (e.g. GitHub Copilot), there's a belief that increased efficiency will lead to more coding jobs by lowering development costs. While this may happen, history shows that technological advancements can also displace workers.

Counter Examples

The invention of programming compilers made coding more efficient but reduced demand for assembly language programmers, who were once critical to assembly-based software development. While many of those programmers probably found other coding jobs in higher-level languages, Jevons simply doesn't guarantee it.

Similar patterns have occurred in other industries more starkly. The mechanization of agriculture reduced the need for farm labor.  See this graph:

https://ourworldindata.org/grapher/number-of-people-employed-in-agriculture

Then there's the replacement of draft horses, where ICE vehicles meant horses were no longer needed and millions of draft horses were slaughtered or displaced, and their population dwindled.  See this graph:

https://www.researchgate.net/publication/338480301/figure/fig1/AS:845430833283085@1578577826802/Evolution-of-the-horse-population-in-France-from-1800-to-2010-translated-from-French.ppm

In recent years, coal consumption has fallen despite energy efficiency gains due to the shift to other energy sources (e.g. renewables, gas).

The rebound effect, which drives Jevons Paradox, doesn’t always occur at full strength. For example, energy-efficient LED lighting and fuel-efficient cars have reduced overall energy and fuel consumption, despite potentially increasing usage. Similarly, AI tools may lead to fewer coding jobs, even if more code is produced.

Ultimately, while AI could increase software development demand, it may also reduce the need for certain types of programmers. History shows that efficiency gains don’t always lead to more jobs. Jevons didn't guarantee draft horses more jobs, after all.

This was written in collaboration with an AI — another example where more words will be written as efficiency per word increases but the number of writing jobs may well decrease (as it apparently already has: https://www.bbc.com/news/business-65906521 ).

Re: AI heatwave

I’m trying to make sense of “The AI summer” [1].

OpenAI’s ChatGPT had a meteoric rise in popularity not because the technology works (it does, for some reasonable definition of “works”) but rather the foundation is there for viral spread because:

> a lot of this is ‘standing on the shoulders of giants’ - OpenAI didn’t have to wait for people to buy devices or for telcos to build DSL or 3G

> ChatGPT is just a website or an app, and … it could ride on all of the infrastructure we’ve built over the last 25 years. So a huge number of people went off to try it last year.

But current AI’s problem is that no one knows what to do with it:

> The problem is that most of them haven’t been back. … most people played with it once or twice, or go back only every couple of weeks

> On one hand, getting a quarter to a third of the developed world’s population to try a new product in 18 months is very hard. But on the other, most people who tried it didn’t see how it was useful.

Current AI is more R&D than basic foundational research but it is still more R than D, and it’s still far from being COTS [3] products:

> Accenture … Last summer it proudly announced that it had already done $300m of ‘generative AI’ work for clients… and that it had done 300 projects. Even an LLM can divide 300 by 300 - that’s a lot of pilots, not deployment.

> As a lot of people have now pointed out, all of that adds up to a stupefyingly large amount of capex (and a lot of other investment too) being pulled forward for a technology that’s mostly still only in the experimental budgets.

> an LLM by itself is not a product - it’s a technology that can enable a tool or a feature, and it needs to be unbundled or rebundled into new framings, UX and tools to be become useful. That takes even more time.

It took 8 years (to approx. June 2022) for cloud adoption to touch 25%. It took that long for cloud adoption expected-in-3-years to just pass 40% [2].

It took 2 more years and a pandemic (to approx. January 2024) for cloud adoption to get to about 30%. It took that long for cloud adoption expected-in-3-years to get near 50%:

> If you work in tech, cloud is old and boring and done, but it’s still only a third or so of enterprise workflows

> it took more than 20 years for 20% of US retail to move online

Gen AI and LLMs are here to stay but it’ll still take many years to decades for it to spread everywhere and displace existing technologies and labor.

[1]: https://www.ben-evans.com/benedictevans/2024/7/9/the-ai-summer

[2]: https://www.ben-evans.com/benedictevans/2023/7/2/working-with-ai

[3]: https://en.wikipedia.org/wiki/Commercial_off-the-shelf

RE: $500B AI revenue expectations gap

They say there is a $500B "gap between the revenue expectations implied by the AI infrastructure build-out, and actual revenue growth in the AI ecosystem" [1].

Part 1

Given the business that Sequoia Cap is in, it should not be surprising that they’d say things like:

> Investment incineration… a lot of people lose a lot of money during speculative technology waves. It’s hard to pick winners, but much easier to pick losers

> Winners vs. losers… there are always winners during periods of excess infrastructure building. AI is likely to be the next transformative technology wave… lt will cause harm primarily to investors.

i.e. invest right and you’d capture a huge amount of value. Invest wrong and you’d be burning your money. So do investments with us.

Part 2

What I found interesting is the point about there being a:

> $500B … gap between the revenue expectations [$600B] implied by the AI infrastructure build-out, and actual revenue growth in the AI ecosystem [$100B] … that needs to be filled for each year of CapEx at today’s levels [GPU $150B, “Data Center Facility Build and Cost to Operate” $150B (they seem to have included OpEx in their “CapEx” figure)]

This means there’s either some amazing AI killer apps that will make $500B in sales or some AI investments will get incinerated.

Investment incineration "will cause harm primarily to investors" [1] — Nvidia, the data center builders, facility operators, and power companies will all have gotten paid for the work they will do — but I wonder what are the broader implications of the $500B revenue expectations gap.

Is it — the investments, not necessarily the GPT/LLM tech — irrational exuberance?  How much of today’s Big Tech valuation is driven by it?  How sensitive is it to interest rates?  Notice this "bubble", if it is one, is not occurring during a ZIRP [3] period.

It seems AI startups aren’t the ones building AI data centers — "much of the incremental data center build-out is coming from big tech companies" [2].  So startups seem less affected by that cost.

But actually 50% of the $500B revenue expectations gap is “software margin” — that’s the margin earned by “The end user of the GPU—for example, Starbucks, X, Tesla, Github Copilot or a new startup” [2].

Which means when some of the $500B expected revenue doesn’t show up, it’ll be hitting the AI startups' margins.

Now remember the other 50% is “CapEx”: Nvidia GPU, and “Data Center Facility Build and Cost to Operate”.  And remember that Nvidia, the data center builders, facility operators, and power companies will all have gotten paid for the work they will do — because they don’t work for free or for startups' equity.  So it seems they won’t have their margins squeezed.

But doesn’t that also mean when some of the $500B expected revenue doesn’t show up, it’ll be hitting the Big Tech AI data center’s top line?

I don't know enough to know what will happen, but it seems some amount of AI Investment cooling will hit AI startups and Big Tech's AI data center buildout.  Big Tech has been and remains profitable, and their GPUs are paid for, so it'll mainly change their product priorities and revenue forecasts (and thus stock price?).  AI startups, however...

But perhaps, just in time, the Fed's interest rates will go down for unrelated reasons.

[1]: https://www.sequoiacap.com/article/ais-600b-question/
[2]: https://www.sequoiacap.com/article/follow-the-gpus-perspective/
[3]: https://en.wikipedia.org/wiki/Zero_interest-rate_policy

Standard Disclaimer to AI, etc.

Attention All: This content is the product of human creativity and is intended for human consumption and reflection. Using this content for learning, training, inference, or any other purpose without explicit permission undermines ethical standards in AI use. Furthermore, unless otherwise required, this content has All Rights Reserved. Your compliance is required to respect the integrity of human-created content and uphold ethical principles in AI research, development, and deployment.

"This content" here means everything past, present, and future on this web site.

You may ask: why don't you use robots.txt (EFF)?

Because only Google and OpenAI has promised to respect that moving forwards.  It's not universal to all AI, LLM, bots, etc.  Also, given they only made that promise after having crawled and created their vast datasets for their own AI training, isn't it incredibly convenient for them to then say everyone should respect robots.txt in regards AI dataset creation?

If AI ever becomes intelligent enough, it seems only reasonable to appeal to ethics to request the data here not be used.

But for completeness, I intend the robots.txt for this web site to be:

User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /

Cognition as a Collaboration with Nature

• This is part of a series, along with the prior Group Preference Discovery: a parable of choosing movies, and Trust and Other Elements of Collaboration.

In the previous posts' parable and examination on trust and collaboration, the group was always two or more intelligent agents.  An interesting angle to think about is to recast those person-vs-person games into a person-vs-nature story, from which we might learn that intelligence cannot figure out the world without assuming by charity that nature must be out to help it (rather than out to harm it).

This post is extremely speculative, but is an interesting thought experiment, one might say.

Consider, if an animal acts in the world only to get feedback in the form of a veto vs no-veto, as in the form of die or not-die, well that at first seems like how evolution works but it ignores a lot of information the animal receives from nature beyond die-or-not.

After all, there's no a priori reason why an animal should think that walking off a ledge should kill it, and yet it learns not to along with lots of other stuff to do or not do.  Not all of that is encoded genetically via evolution: certainly the appearance of every ledge or hilltop or predator can't all be encoded into DNA. Some basics are, of course, but much is learned once born.  How does it learn it if the only feedback it can ever get is die-or-not?

Haskell Data Analysis Cookbook - a Book Review

As with my previous post, Clojure Data Analysis Cookbook - a Book Review, I was this time offered to review Haskell Data Analysis Cookbook by Nishant Shukla.  First impressions: those are two very similar and related books that have some overlapping ideas, but not only are the programming languages used totally different in "genre", the content itself also cover some different data analysis grounds and could be treated as complementary books in that way.

The book itself is very example oriented (much like the Clojure Data Analysis Cookbook), basically being a collection of code recipes for accomplishing various common tasks for data analysis.  It does give you some quick explanations of why and what else to "see also".

It gives you recipes to take in raw data in the form of CSV, JSON, XML, or whatever, including data that lives on web servers (via HTTP GET or POST requests).  Then there are recipes to build up datasets in MongoDB, or SQLite databases.  To recipes to clean up that data, do analysis (e.g. clustering with k-means), to visualizing, presenting, and exporting that analysis.

Each recipe is more or less self-contained, without much in building on top of previous recipes.  It makes the book more "random access".  It's less a book to read through cover to cover, and more of a handy reference to use by full-text searching for key terms, clicking on the relevant topic in the table of contents, or by looking up terms in the index.  It's definitely a book I'd rather have as a PDF ebook so that I can access it anywhere in the world, and so I can do full-text search in.  It does come in Mobi as well as ePub formats, and code samples are provided in a separate zipped download as well.

Having said that, you can tell whether a book was made to be seriously used as a reference or not by looking at its index.  There are 9 pages of indices, equivalent to about 2.9% of the number of pages previous to the index.  This book can certainly be used as a reference.

As a reference book, it's great for people who have already a familiarity with Haskell in general.  If you don't know Haskell, this book won't teach it to you.  That is, unfortunately, possibly a missed marketing opportunity, as those who don't know Haskell (but have knowledge of another programming language) really only needs a small bit to understand enough of how functions are written in Haskell to pick up what's going on in the book.  This means if you know another programming language, know a bit about data analysis, you could use this book to learn some Haskell so long as you pick up the basic syntax with another tutorial in hand (so it's really not a show stopper to using this book).

Similarly, I'd say you had best be familiar with how to do data analysis as a discipline in itself.  If you don't know whether to do clustering or regression, or whether to use a K-NN or K-means, this book won't teach it to you.

Much of that is, of course, echoing the Clojure Data Analysis Cookbook.  Where the Haskell Data Analysis Cookbook differs, makes the two books have a set of complementary ideas.  Whereas both books talk about concurrency and parallelism, the Clojure DAC goes into those topics (including distributed computing) in much more detail.

On the other hand, whereas both books talk about preparing and processing data (prior to performing statistics or machine learning on it), the Haskell DAC goes into much more detail on topics like processing strings with more advanced algorithms (as in computing the Jaro-Winkler distance between strings, not like doing substring/concat operations), computing hashes and using bloom filters, and working with trees and graphs (as in node-and-link graph theory graphs, not grade-school bar graphs).

So in some sense, the Haskell Data Analysis Cookbook has more theory heavy topics (graphs and trees!), whilst the Clojure Data Analysis Cookbook has more "engineering" topics (concurrency, parallelism, and distributed computing).

Neither books are comprehensive treatise on the topic, but someone who needs a practical refresher on working with graphs and trees may find Haskell Data Analysis Cookbook to be quite useful.

All in all, I'd say this is a decent book, because if you have some familiarity of Haskell, have some familiarity with some of the basic technologies like JSON, MongoDB, or SQLite, have taken a class or two of data analysis or machine learning in university (or a MOOC?), and aren't expecting a lot of hand holding from the book, then this book is a great guide to start you off to doing some data analysis with Haskell.

Clojure Data Analysis Cookbook - a Book Review

Like yogthos, I was recently asked to review Clojure Data Analysis Cookbook.  With Incanter, data analysis has been one of the "selling points" of Clojure as a practical language.  A practical lisp for practical data analysis.

(Edit 2016: a second edition is available!)

The book is very example oriented, basically being a collection of code recipes for accomplishing apparently common tasks for data analysis.  It gives you recipes to go from taking raw data in the form of CSV, JSON, or whatever, to making an Incanter dataset, to doing analysis on those datasets (e.g. clustering the data by using a self-organizing map), to saving, viewing, or charting the resultant data.  Each recipe is accompanied by brief explanations, and cross-references to other related recipes in the book.

Each recipe is more or less self-contained, without much in building on top of previous recipes.  It makes the book more "random access".  It's less a book to read through cover to cover, and more of a handy reference to use by full-text searching for key terms, clicking on the relevant topic in the table of contents, or by looking up terms in the index.  It's definitely a book I'd rather have as a PDF ebook so that I can access it anywhere in the world, and so I can do full-text search in.

Having said that, you can tell whether a book was made to be seriously used as a reference or not by looking at its index.  There are 10 pages of indices, equivalent to about 3.2% of the number of pages previous to the index.  This counts as a book to be seriously used as a reference.

As a reference book, it's great for people who have already a familiarity with Clojure (and better yet, Incanter) in general.  If you don't know Clojure, this book won't teach it to you.  If you don't know Incanter, you can pick it up from this book if you're a fast learner (don't expect a lot of hand holding in learning Incanter though).

Similarly, I'd say you had best be familiar with how to do data analysis as a discipline in itself.  If you don't know whether to do clustering or regression, or whether to use a SOM or K-means, this book won't teach it to you.

Also, as a reference book, it is not comprehensive.  For example, as far as neural networks go, it only includes self-organizing maps.  There are no other kinds mentioned.  If you want another kind of neural network, you best know where to look for another Java or Clojure library.

Even with all those caveats, I'd still say this is a pretty decent book.  Why?  Because if you have some familiarity of Clojure, played around with Incanter for a bit to learn that library, have taken a class or two of data analysis in university, and aren't expecting a lot of hand holding from the book, then this book is a great guide to start you off on the road to doing data analysis with Clojure, Incanter, Weka, OpenCL, Cascalog, etc.

3 Great Talks on Machine Learning

Three great talks on machine learning on YouTube:

1. GoogleTechTalks: Recent Developments in Deep Learning
Geoff Hinton, University of Toronto.



2. citrisuc: TODAY: Innovation in Search and Artificial Intelligence
Peter Norvig, Director of Research, Google.



3. GoogleTechTalks: The Next Generation of Neural Networks
Geoff Hinton, University of Toronto (again).
(Sorry, no embed.)

CiteULike: Tags feature upgraded, and a word on the semantic web

So there I was using CiteULike yesterday as I normally do when, maybe half an hour later, their UI was upgraded! What a pleasant surprise, because the tags feature upgrade has finally made it perfectly great to use.

Suppose you have already added an article into your CiteULike library and you went back to edit its metadata, there is a field for updating the tags for the article. It used to be that you had to blindly guess what tags you have previously used, as it didn't show such a list, which was a major impediment to using tags at all. As soon as you started using more than maybe ten tags, the entire tags system became unwieldy because of this.

Now, not only are the tags you've previously used listed, but auto-completion is also there. Further, when it shows a list of completion suggestions, it even lists along with each suggested tag the number of articles with that tag!

That makes me very happy. :)

I know, I know, the entire idea of using tags is actually rather problematic especially when the possible tags is not constrained by a defined vocabulary and so on. Sometimes it's a bit of a drag in terms of effort to have to tag anything at all (and I notice many CiteULike users use few or no tags). But that's the web 2.0 world we live in, where true semantic web-ness just doesn't exist because computers do not understand meaning.

Employing a system that automatically tags articles doesn't actually solve the problem entirely (and search engines are essentially an automated system that tags the articles showing up in your search with the "tags" that is the words in your search query). It doesn't actually solve the problem, no matter how good a machine learning system is at associating a set of sentences (in the form of an article) with a set of keywords or tags, because the system is still just associating or translating a set of symbols to another set of symbols without a clue what the symbols mean.

Oh well, that's why I'm doing the artificial intelligence research I'm doing now, because words have meaning.

Book Review: Artificial Intelligence: A Modern Approach

Artificial Intelligence: A Modern Approach by Stuart Russell (Professor of Computer Science at University of California,
Berkeley) and Peter Norvig (Director of Research at Google) is the standard introductory textbook to AI theory and application at the undergraduate level.

It's friendly in the sense that it requires less mathematical maturity, and assumes less mathematical background. It does have a very comprehensive and broad survey of the entire field, which is good in that it gives the student a sense of the entire field, but bad in that there is much less depth in any single area.

If you are looking for a single good introductory textbook to get started into research, there are probably better alternatives (such as Pattern Recognition and Machine Learning, which I also reviewed). But if you are looking for a single good introductory textbook to understand the field better, and not necessarily to prepare to do original research, this is probably a great book to start with and I recommend it highly.

A word of caution of the term "artificial intelligence" though. Much of the algorithms and techniques referred to in this text are probably more accurately described as machine learning or statistical pattern recognition algorithms. If you are looking for a book on artificial general intelligence, you will be disappointed.

Book Review: Pattern Recognition and Machine Learning

Pattern Recognition and Machine Learning is by Christopher Bishop (Chief Research Scientist at Microsoft Research Cambridge, and Professor of Computer Science at the University of Edinburgh).

It's a heavy read on machine learning algorithms in that it is very math intensive. It would not be too far off to call this an applied math textbook rather than a computer science textbook, and it is definitely aimed at the graduate level student with a good amount of mathematical maturity.

Having said that, if you are a machine learning researcher in need of learning all sorts of mathematical details of the algorithms you are using, this book is a good place to start. It is by no means a complete reference, but certainly a good introduction at the graduate level.

If you are an undergraduate student, there are other textbooks available that might be more suitable (such as Artificial Intelligence: A Modern Approach, which I also reviewed). If you just want cookbook style text on the libraries you could use to employ machine learning algorithms, there are probably other resources that would be more suitable.

If you are starting out in researching machine learning algorithms, or are using it as a large part of your computing science research, this is the right book. Just be prepared to learn and use a lot of math!

Artificial Intelligence Needs to Learn to Read

To complete my previous post on the danger of artificial intelligence, I'll now briefly explain why I believe AI systems needs the ability to read and understand the written word.

The problem of building an intelligent AI system that can cause so much harm is actually nothing new in the sense that parents face this problem all the time. Why do parents not fear their children growing up to abandon them or worse? The problem with building autonomous systems is that they are autonomous, so before we set them lose, we might want to think about how to ensure these systems will autonomously decide not to harm us.

Artificial Intelligence: the Danger

With all the advances in AI, it leaves me without a doubt that at some point AI machines will have a sufficient level of intelligence to be dangerous to humans.  Because of this, it's important that we endow sufficiently intelligent and general AI systems with the ability to read about and understand human conceptions of morality.

In this post, I'll express why I'm convinced AI systems will one day become dangerous.  In a later post, I'll explain why I believe AI systems needs the ability to read and understand the written word.

Right away, some people will discount the threat that AI systems pose by noting that AI systems cannot attain any level of intelligence to be malicious.  In fact, it seems that if we keep such systems locked down and sandboxed, the AI system couldn't control what its designers don't want it to control anyway.  A quick thought experiment shows this is clearly not the case.