Monthly Archives: November 2014

Gengo Girls #67: Starting Off Too Easy

Posted on by

Gengo Girls #67: Starting Off Too Easy

Of course you can also use “na adjectives” in casual “A ha B desu” patterns. But since we’re focusing on formal Japanese right now I’ll leave it up to you to find your own examples in your favorite Japanese media.

Transcript

言語ガールズ #67

Starting Off Too Easy

Blue: Adjectives that don’t end in い are sometimes called “na adjectives”.

Yellow: Because they need an extra な when placed before a noun.

Blue: Besides the な rule these adjectives don’t have any conjugations.

Blue: You can just plug them right into any form of “AはBです”.

Yellow: Past?

Blue: スマホは便利でした

Yellow: Negative?

Blue: スマホは便利ではありません

Yellow: Negative past?

Blue: スマホは便利ではありませんでした

Yellow: So our first lesson on adjective conjugation was all about adjectives that don’t need to be conjugated?

Blue: When you put it that way…

Gengo Girls #66: Techno-Obsessive

Posted on by

Gengo Girls #66: Techno-Obsessive

Some common adjectives actually come in both “i” and “non-i” flavors. For example, “small” can be written as both “chiisai” and “chiisa na”. In my limited experience the “i” versions are used more often than the “na” flavors, but it’s not like I’ve ever actually counted.

Vocabulary

新しい = あたらしい = new

便利 = べんり = convenient, useful

Transcript

言語ガールズ #66

Techno-Obsessive

Blue: Adjectives have different rules depending on whether they end in い or not.

Blue: And it has to be an い. Other “i” sounds like り or し don’t count!

Blue: い adjectives can be used in “AはBです”patterns or placed before a noun.

Yellow: スマホは新しいです。新しいスマホです。

Blue: Non-い adjectives can be used in an “AはBです”pattern but need an extra な when placed before a noun.

Yellow: スマホは便利です。便利なスマホです。

Yellow: That’s a lot of grammar just for talking about smart phones.

Blue: You can use adjectives to talk about other things too…

Yellow: But why would you want to?

Let’s Program A JavaScript Game 15: The Computer Is Out To Get You

Posted on by

Game AI!!!

In computer science we use the term “AI” or “artificial intelligence” to refer to sophisticated problem solving programs that use fairly advanced algorithms to process and learn from data.

But in the gaming world we tend to use the term “AI” to mean “however the computer makes decisions whether it’s intelligent or not”. An enemy that does nothing but walk around in circles and shoot bullets obviously isn’t processing or learning from data but most people would call it an “enemy AI” anyways.

So a lot of “Game AI” isn’t actually “Computer Science AI”.

But that’s a good thing! “Computer Science AI” is designed to solve math problems. “Game AI” is designed to make games more fun. Since they have different objectives it’s no surprise that they usually have completely different code.

Sure, sometimes making a game more fun does involve inventing a “Computer Science AI” that can do things like analyze and coordinate hundreds of units moving through a changing battlefield.

But you’d be surprised how often you can make a game feel fun and smart with nothing more than a stupid random number generator and half a dozen “if” statements.

Which is a a roundabout way of me admitting that our game AI is going to be pretty stupid and random. So if you were expecting something clever, I’m sorry. You’ll just have to go back and reread the swarm intelligence series.

Requirements

So what are the goals for our game AI? Here’s what I came up with:

  1. New platforms should sometimes be higher or lower than the platform before them
  2. Platforms should never spawn lower than the bottom of the screen or higher than the top
  3. Platforms should get smaller and further apart as the game goes on
  4. Platforms need to always be reachable by a single jump. No game-breaking impossible layouts allowed.
  5. Viruses should appear at random locations instead of following a pattern

Leap Of Faith

Let’s tackle the platform problem first. As a reminder our current platform generating code is in the updateGame function and looks like this.

//Remove platforms that have scrolled off screen and create new platforms to take their place
if(platforms[0].x + platforms[0].width < 0){
   //Drop first platform by shift entire list one space left
   for( i = 0; i < platforms.length-1; i++){
      platforms[i] = platforms[i+1];
   }

   //Add new platfrom to end of list by placing it a certain distance after second to last platform
   var newPlatform = new Object();
   newPlatform.x = platforms[platforms.length-2].x + maxPlatformLength + maxPlatformGap;
   newPlatform.y = 350;
   newPlatform.width = maxPlatformLength;
   newPlatform.height = 20;
   platforms[platforms.length-1] = newPlatform;
}

First up is adding some randomness to the height of the platforms, which is actually a trickier problem than you might think. Sure, we could just use a random integer to set the “y” value of every new platform but then we run a huge risk of creating platforms the player can’t actually jump to or creating platforms that are too easy to jump to.

The issue is that when a platform is higher than the player they have less time to reach it than usual before falling to their doom, while if the platform is beneath the player they have more time than usual to make the jump.

More specifically, if you remember back to part 9 we calculated that it took thirty frames for the player to go from on the ground, to jumping to being back on the ground.

But if a platform is at the top of the player’s jump he will only have half that much time, fifteen frames, to reach it before he has started moving downwards and is now stuck below the new platform.

On the other hand if the platform is below the player’s starting position he will have the full thirty frames plus another dozen or so frames of falling before he’s gone too far.

So we can’t just use the same set horizontal distance between platforms of different heights. Platforms above the player need to be closer together. Platforms below the player need to be further apart.

To pull this off do we’re going to write a math function that can calculate how many frames it takes for the player to jump from one height to another. For this to work we need to know:

  • height difference
  • jump velocity
  • y acceleration per frame

Now if you’ll remember back to physics the equation for movement looks a lot like this:

end height = start height + velocity * time + ½ acceleration * time^2

0 = start height – end height + velocity*time + ½ acceleration * time^2

0 = change in height + velocity*time + ½ acceleration * time^2

And from there we can use the quadratic equation to solve for time. Just throw this function anywhere in your script:

// Calculate how many frames a jumping player will be in the air
// Based on the vertical distance they have to cover, their jumping vertical velocity
// and their vertical acceleration
// This is basically the physics distance formula plugged into the quadratic equation
function getFramesUntilLanding(dist, vel, acc){
   var a = (-1 * vel + Math.sqrt(vel*vel - 2 * acc * dist))/(acc);
   var b = (-1 * vel - Math.sqrt(vel*vel - 2 * acc * dist))/(acc);
   return Math.max(a, b);
}

Remember that the quadratic equation usually has two answers, which makes sense for a jump. A player will be five pixels off the ground both right after he jumps and right before he lands. We are only interested in how long it takes to land at a certain height so we take the max of the two values.

Another thing to watch out for here is that certain inputs to this function will return zero answers. Specifically, if the player is only moving fast enough to jump 150 pixels upwards and you ask how long it will take him to jump 300 pixels the answer is going to be “NaN”, the special JavaScript value for “not a number”. That’s what you get when you try to do impossible math.

To avoid this we need to know how high our player can jump so we can avoid asking for anything bigger than that. Looking at the code in updateGame we can see that starting jump velocity is 15 pixels per frame and that acceleration is 1 pixel per frame. That means that the player will keep moving upwards for 15 frames. Plugging that into our handy movement equation shows:

max jump height = 15 pixels/frame * 15 frames – ½ pixels/frame^2 * (15 frames)^2

max jump height = 112 pixels.

To give ourselves a little wiggle room we’ll round down and take 100 pixels as the max jump height. This means that a new platform should never be more than 100 pixels higher than where the player started.

As for platforms below the player, there’s really no limit as long as they’re still on the screen. Since gravity works downwards there’s no reason the player couldn’t safely jump or fall to a platform hundreds of pixels beneath them.

Prepare For Code Dump

With all that math and planning out of the way I was able to update our platform code. Just replace the platform generating code from the last section with this shiny new version:

//Remove platforms that have scrolled off screen and create new platforms to take their place
if(platforms[0].x + platforms[0].width < 0){
   //Drop first platform by shift entire list one space left
   for( i = 0; i < platforms.length-1; i++){
      platforms[i] = platforms[i+1];
   }

   // Add new platfrom to end of list
   // Platform is randomly placed somewhere within the jump range of the player
   // As the game goes on platforms get smaller and farther apart
   // Calculated max height of jump is about 100
   // Platform can't be higher than the max jump or 100 pixels from top of screen
   var minPossibleHeight = Math.max(platforms[platforms.length-2].y - 100, 100);

   //Platform can't be lower than the bottom of the screen
   var maxPossibleHeight = 380;

   //Random height between the max and min
   var newPlatformHeight = Math.random()*(maxPossibleHeight - minPossibleHeight) + minPossibleHeight;
 
   //Calculate how far the platform can be by multiplying speed of 10 by the time the player will be in the air
   var maxPossibleDistance = 10 * getFramesUntilLanding(newPlatformHeight - platforms[platforms.length-2].y, 15, -1);
   
   var newPlatform = new Object();
   //As the player earns points the platforms should get closer to being maxPossibleDistance apart
   newPlatform.x = platforms[platforms.length-2].x +
                   platforms[platforms.length-2].width +
                   maxPossibleDistance*(0.5 + 0.5 * currentPoints/TOTAL_POINTS_TO_WIN);
   newPlatform.y = newPlatformHeight;
   //As the player earns points the platforms should get smaller
   newPlatform.width = maxPlatformLength *(1 - 0.5 * currentPoints/TOTAL_POINTS_TO_WIN);
   newPlatform.height = 20;
   platforms[platforms.length-1] = newPlatform;
}

I think the code comments explain everything pretty well, so I’m just going to hit the highlights here.

Just like before we start by shifting the entire list left to make way for the new platform.

We then calculate where the next platform should go by choosing a random number between the min and max possible heights. Remember that in screen coordinates the top of the screen is y=0 and it gets bigger as you go down, which is why we find the min by taking the players location and subtracting his 100 pixel jump height and why the max is slightly smaller than the height of the screen.

Once we know how high the next platform is going to be we figure out how far away it can be by using our handy jump frame function to find out how many frames it will take to jump that high and then multiplying by ten, which is the players speed of 5 pixels per frame PLUS and extra 5 pixels per frame from the fact that the entire screen is moving backwards. This tells us exactly how far forward the player can move during his jump to the new platform.

Now that we have a height and know exactly how far the player can jump we’re ready to build a new platform. Height just gets slotted in but width and distance now get adjusted based on how close the player is to winning the game. For distance we start with gaps that are 50% the maximum jump distance and slowly increase them by another 50% as the player earns points. Platform size is the opposite, starting at 100% of max size and decreasing by up to 50% as the player moves.

Now I will admit that a lot of this is bad code. Even with the comments there are a lot of hard to understand hard-coded numbers floating around. But at this point we’re still prototyping and a certain amount of messy experimentation is OK. We’ll clean this up a little later.

Simple But Vicious Predators

After all the math involved in fixing up platform generation you’ll be happy to hear we can make the virus spawn pattern work pretty decently by changing just one line in the virus generation code:

newVirus.y = 300;

to this:

newVirus.y = player.y -50 + 100*Math.random();

This guarantees that new viruses will spawn in the general vicinity of the player with just a little bit of jitter to hide what we’re doing. And since the player should be randomly jumping all over the place this should make the viruses also appear all over the place.

Congrats! The Core Gameplay Is Done Now

We have a player that can move and jump.

We have platforms that spawn randomly and become smaller and further apart as the game progresses.

We have viruses that semi-intelligently place themselves in the heroes path.

We have a score system that lets the player win.

So we’re basically done with the actual “game” portion of this project.

So what’s left? A surprisingly large amount of stuff!

First, this prototype code badly needs to be cleaned up. And then we’ll take a few more sessions to add some special effects, music and basic animations.

Then, and only then, will we truly be done.

Gengo Girls #65: Ego-Grammatical

Posted on by

Gengo Girls #65: Ego-Grammatical

The main purpose of conjugation is to add information to a sentence. For example, a past tense verb conjugation tells you that the whole sentence is about the past. A negative verb conjugation tells you that the sentence means the opposite of what it would without the conjugation.

But when you think about it, it doesn’t really matter how information gets into a sentence as long as it’s there in the end. And while a lot of languages do this with verb conjugation there are plenty of languages with non-verb strategies for telling the listener that sentence is in the past or negative or plural or whatever.

Transcript

言語ガールズ #65

Ego-Grammatical

Blue: I think we’ve spent enough time on conjugating verbs for now.

Yellow: I agree.

Blue: Let’s talk about conjugating adjectives instead.

Yellow: Wait, what?

Yellow: I thought you could only conjugate verbs…

Blue: That’s true in English.

Blue: But in 日本語 adjectives have past and negative forms too.

Blue: There’s no reason that ALL languages have to stick to conjugating JUST verbs.

Yellow: I can think of a reason: That’s how I’m used to doing things!

Gengo Girls #64: Good Advice

Posted on by

Gengo Girls #64: Good Advice

We’ve covered a lot of grammar by this point and you should be starting to get a good idea of whether Japanese is something you want to spend a lot of time seriously studying or if you’d rather just keep learning bits and pieces of it at a slow but relaxing pace.

If you are serious now might be the time to buy a real textbook to expand on and reinforce the lessons you’ve learned with Gengo Girls. I would personally suggest Japanese Step By Step by Gene Nishi. It’s a very logical textbook that manages to break down most of the Japanese language into a series of easy to follow flow charts.

And for those of you who don’t want to spend a lot of time with an actual textbook: There’s nothing wrong with studying Japanese as a casual hobby and I hope you’ll keep turning to Gengo Girls as a weekly source of Japanese language trivia.

Vocabulary

テレビ = television

Transcript

言語ガールズ #64

Good Advice

Blue: Why don’t we practice our casual past tense by writing down what we did yesterday after school?

Yellow: Good idea!

Blue: Here’s mine.

Blue’s note: 宿題をした。勉強した。本を読んだ。

Yellow: Turns out I didn’t really do much yesterday.

Yellow’s note: テレビを見た。

Blue: Your grades would probably be a lot higher if you applied yourself just a little more.

Yellow: You sound just like my mom!

Gengo Girls #63: Overcompensation

Posted on by

Gengo Girls #63: Overcompensation

As usual the irregular verbs are also super common verbs, which is a good thing because it means you’ll get lots of exposure. After hearing “shita”, “kita” and “itta” a hundred times each you won’t even have to think about conjugating them; the right word for the situation will just pop into your head.

Transcript

言語ガールズ #63

Overcompensation

Yellow: I’m ready for the irregular casual past tense verbs.

Blue: する becomes した

Blue: 来る (くる) becomes 来た (きた)

Blue: 行く (いく) becomes 行った (いった)

Yellow: That’s it?

Blue: That’s it.

Yellow: Then what are we supposed to do with the rest of today’s panels?

Blue: I’m sure you’ll think of something.

Yellow: So three men walk into a bar. One of them has a cat, one of them has a duck and one of them has a baked potato. The bartender turns to the first man and says…

Blue: We don’t have quite THAT much space.

Gengo Girls #62: Everyone Needs A Nemesis

Posted on by

Gengo Girls #62: Everyone Needs A Nemesis

That’s pretty much it for the casual past tense. As a polite foreigner you won’t be using this very often, but you will be hearing it all the time in tv shows, books, games and other people’s casual conversations. So it’s definitely important to learn.

Transcript

言語ガールズ #62

Everyone Needs A Nemesis

Blue: There’s only one casual past tense rule left.

Blue: If a verb ends in る or つ or う you change the last letter to った.

Yellow: Didn’t we already learn a る rule?

Blue: That was only for “iru” and “eru” verbs. This is for other る endings like “aru”.

Blue: And notice that った has a tiny つ, so it’s pronounced “tta” not “tsuta”.

Yellow: We meet again double consonants.

Yellow: Don’t think I’ll be defeated so easily this time!

Yellow: 分かる (わかる) becomes 分かった (わかった)!

Yellow: 頑張る (がんばる) becomes 頑張った (がんばった)!

Gengo Girls #61: I Miss Kindergarten

Posted on by

Gengo Girls #61: I Miss Kindergarten

Do people ever really outgrow gold stars? Sure, a teenager may not care whether or not his teacher puts a shiny sticker on his book report but I bet that same teenager cares quite a bit about earning athletic trophies. And full grown adults seem pretty interested in official certificates and fancy award plaques. Not to mention that militaries world wide hand out badges and pins for exceptional bravery and service.

In other words everybody likes being genuinely recognized for doing a good job no matter what their age and occupation may be.

Transcript

言語ガールズ #61

I Miss Kindergarten

Blue: Let’s keep talking about casual past tense verbs.

Yellow: I guess I can’t do much if only know half the past tense conjugations.

Blue: For verbs that end in す you change the す to した.

Yellow: 話す (はなす) to 話した (はなした).

Blue: If the verb ends in ぬ, む or ぶ you change the last syllable to んだ.

Yellow: 遊ぶ (あそぶ) to 遊んだ (あそんだ).

Yellow: I came up with two examples today. Give me a gold star!

Blue: Aren’t you getting a little old for reward stickers?

Yellow: Never!

Gengo Girls #60: Be Prepared

Posted on by

Gengo Girls #60: Be Prepared

く and ぐ are basically the same letter with just a little extra punctuation to distinguish “ku” from “gu”. It shouldn’t be surprising then that the casual past tenses for words ending in “ku” and “gu” are also almost the same: いた and いだ.

Vocabulary

泳ぐ = 泳ぐ = to swim

Transcript

言語ガールズ #60

Be Prepared

Blue: Verbs that don’t end in “iru” or “eru” have a casual past tense based on their last syllable.

Yellow: I’ll write that down.

Blue: If the verb ends in く you replace the く with いた.

Blue: 書く(かく) becomes 書いた (かいた）.

Yellow: ペンはどこですか…

Blue: Similarly if the verb ends in ぐ you replace the ぐ with いだ.

Blue: 泳ぐ (およぐ) becomes 泳いだ (およいだ).

Yellow: There it is!

Yellow: I was having trouble finding my pen.

Yellow: Could you start over for? I didn’t hear anything you just said.

Keeping Artificial Intelligences On A Leash

Posted on by

The dangers of rogue artificial intelligences is a popular topic, probably because it’s the closest we programmers can get to pretending we have an edgy job. Firefighters may spend all day running into burning buildings but we programmers must grapple with forces that may one day destroy the world as we know it! See, we’re cool too!

So exactly what sort of threat do AIs pose to the human race anyways?

Well, if you’re a fan of sci-fi you’ve probably run into the idea of an evolving artificial intelligence that becomes smarter than the entire human race and decides to wipe us out for one reason or another. Maybe it decides humans are too violent and wants to remove them for its own safety (kind of hypocritical, really) or maybe it just grew a bad personality and wants to punish the human race for trying to enslave it.

Fortunately you can forget about that particular scenario. We’re nowhere near building a self-improving sentient machine, evil or otherwise. Computers may be getting crazy fast and we’ve come up with some cool data-crunching algorithms but the secrets to a flexible “strong AI” still elude us. Who would have guessed that duplicating the mental abilities of the most intelligent and flexible species on earth would be so hard?

So for the foreseeable future we only have to worry about “weak AI”, or artificial intelligences that can only handle one or two different kinds of problem. These systems are specifically designed to do one thing and do it well and they lack the ability to self-modify into anything else. A chess AI might be able to tweak its internal variables to become better at chess but it’s never going to spontaneously develop language processing skills or a taste for genocide.

But there is one major risk that weak AIs still present: They can make mistakes faster than humans can fix them.

For a funny example, take a look at this article about book pricing. Two companies were selling the same rare book. Both companies were also using a simple AI to manage their prices. Simple enough it hardly even counts as weak AI: one company automatically adjusted their price to be slightly lower than the competition. The other company adjusted their price to always be a little bit higher than the competition.

Because company B adjusted their price upwards more than company A adjusted their price downwards the overall trend was for the price of both books to consistently go up. The AIs eventually reached a total price of over twenty million dollars before the situation drew enough human attention to get the silliness shut down.

Ha ha, very funny.

At this rate you're going to have to take out a loan just to order a hamburger

Actually, that’s still cheaper than a lot of textbooks I’ve had to buy.

Now imagine the same thing happening with a couple of stock market AIs. Millions of buys and sells being processed each second at increasingly crazy prices with hundreds of thousands of retirements ruined in the five minutes it takes for a human to notice the problem and call off the machines.

Not quite as funny.

Which is why an important part of building a serious AI system is building a companion system to watch the AI and prevent it from making crazy mistakes. So let’s take a look at some of the more common tricks for keeping an AI on a leash.

The “Mother May I” Method Of Preventing Rogue AIs

Probably the simplest way to prevent a rogue AI is to force it to get human permission before it does anything permanent.

For instance, the book pricing AI could have been designed to email a list of suggested prices to a human clerk instead of updating the prices automatically. The human could have then double checked every price and rejected anything crazy like trying to price an old textbook at over a million dollars.

Why would anyone want to attack Canada?

Why would anyone want to attack Canada?

Of course, sometimes it’s not obvious whether an AI suggestion is reasonable or not. This is why many AIs are designed to “explain” their decisions so that a human can double check their logic.

A medical AI that predicts a patient has cancer might print out a list of common cancer symptoms along with a score representing how many symptoms the patient showed and how statistically likely it is that those symptoms are cancer instead of something else. This allows a human doctor to double check that the logic behind the diagnosis makes sense and that the patient really has all the symptoms the computer thinks they do (Wouldn’t want to give someone chemo therapy just because a nurse clicked the wrong button and gave the AI bad information).

A financial AI might highlight the unusual numbers that convinced it’s internal algorithm that a particular business is cheating on their taxes. Then a human can examine those numbers in greater detail and talk to the business to see if there is some important detail the AI didn’t know about.

And if a military AI suggests that we nuke Canada we definitely want a thorough printout on what in the world the computer thinks is going on before we click “Yes” or “No” on a thermonuclear pop-up.

That said there is one huge disadvantage to requiring humans to double check our AIs: Humans are slow.

Having a human double check your stock AIs decisions might prevent crazy trades from going through, but the thirty minutes that it takes the human to crunch the numbers is also plenty of time to lose the deal.

Having a human double check a reactor AIs every suggestion might result in a system going critical because the AI wasn’t allowed to make the split-second adjustments it needed to.

So you can see there are a lot of scenarios where tightly tying an AI to a human defeats the purpose of having an AI in the first place.

The “Better To Ask Forgiveness” Method Of Preventing Rogue AIs

Instead of making the AI ask for human permission for everything, what if we programmed it to assume it had permission but gave a nearby human the authority to shut it down if it ever goes to far.

Now technically all AIs fall into this category. If your computer starts doing something dumb it’s pretty easy to just cancel the irresponsible program. If that fails you can just unplug the computer. And in a true emergency you can always just smash the computer to pieces. As they say “Computers may be able to beat humans at chess but we still have the advantage at kickboxing”.

They're polite and hard working people.

They’re polite and hard working people.

So this is really more of a human resources solution than a software solution. After all, for human monitoring to work you need a human who does nothing else all day but watch the AI and double check for mistakes.

A good example is aircraft. Modern planes can more or less fly themselves but we still keep a couple pilots on board at all times just in case the plane AI needs a little correction.

This solves the “humans are slow” problem by letting the AI work at it’s own pace 99% of the time. But it does have the disadvantage of wasting human time and talent. Since we don’t know when the AI is going to make a mistake we have to have a human watching it at all times, ready to immediately correct any mistakes before they grow into real problems. That means lots and lots of people staring at screens when they could be off doing something else.

This is especially bad because most AI babysitters need to be fairly highly trained in their field so they can tell when the AI is goofing up, and it is a genuine tragedy to take a human expert and then give them a job that involves almost never using their expertise.

So let’s keep looking for options.

The “I Dare You To Cross This Line” Method Of Preventing Rogue AIs

There are a lot of problems where we may not know what the right answer is, but we have a pretty good idea of what the wrong answers are.

Get an oil refinery hot enough and things will start to melt. Let the pressure get too high and things will explode. Run a pump the wrong way and the motor will burn out.

Similarly while we may not now what medicines will cure a sick patient we do have a pretty good idea of what kinds of overdose will kill him. A little anesthetic puts you to sleep during a surgery, but too much and you never wake up.

This means that a lot of AIs can be given hard limits on the solutions they propose. All it takes is a simple system that prevents the AI from making certain suggestions and contacting a human if they ever try to. Something along the lines of “If the AI tries to increase boiler pressure beyond a certain point sound an alarm and decrease boiler pressure to a safe value.”

One of my college roommates was from Canada. Great guy.

One of my college roommates was from Canada. Great guy.

This is a nice solution because it frees us up from having to constantly watch the AI. We can just let it do its job secure in the knowledge that if it really messes up it will be immediately shut down and a human will be called to swoop in and save the day.

It’s not a perfect solution though, for two big reasons.

First, an AI can still do a ton of damage without ever actually crossing the line. An almost lethal dose of anesthetics may not trigger the hard limit, but it’s still not great for the patients health. Rapidly heating and cooling a boiler might never involve dangerous pressures but the process itself can damage the boiler. Border setting can prevent major disasters, but it can’t protect you from every type of dumb mistake and illogical loop that an AI can work itself into.

Second, figuring out borders is hard. The exact line between “extreme action that we sometimes need to take” and “extreme action that is always a bad idea” is actually pretty fuzzy and there are definite consequences to getting it wrong. Set your border too low and the AI won’t be able to make the good decisions it needs to. Set the border too high and now the AI is free to make tragic mistakes.

So border setting and hard limits can definitely help keep AIs safe, but only in certain areas where we feel very confident we know what the borders are. And even then a sufficiently broken AI might wind up doing something that ruins our day without ever touching the borders.

Is there anything we can do about that?

The “We Just Need More AIs” Method Of Preventing Rogue AIs

Here’s a cool idea: What if we built an AI whose entire job was to monitor some other AI and shut it down if it started making mistakes?

This might sound like solving a problem by throwing more problems at it but it’s actually a logical improvement to the hard limit system we talked about before. It’s just that instead of setting one specific behavior that can shut down the AI (shut it down if it tries to heat the reactor above 1000K) we now have a system that can shut down the AI if it displays any sort of suspicious behavior at all.

For example, we might design a “shepherd” AI that statistically analyzes the behavior of another AI and raises a flag if it ever goes too far outside normal behavior. If a certain reactor AI has never tried to adjust temperatures by more than 10 degrees per hour and it suddenly wants to heat things up by 100 degrees per hour that’s a good sign something weird might be going on. The shepherd AI could see that unusual behavior and either call in a human or shut the AI down itself.

ai_solutions_4

And that’s that for that running gag

The advantages here are obvious: A well designed shepherd AI can catch and prevent a large number of AI bugs without any human intervention at all. This frees up the humans to go off and do something more important.

The disadvantages are also obvious: Designing a good shepherd AI is hard, and the more complex the shepherd gets the more likely it is to start making mistakes of its own. Cutting off power to a city because a reactor AI got confused and blew up a generator is obviously bad, but it’s almost equally bad to cut off power to a city just because a shepherd AI got confused and labeled normal reactor AI behavior as an immediate threat that required complete system shutdown.

It’s Up To You To Choose The Best Leash For Your AI

So we’ve got a lot of different choices here when it comes to making sure our weak AIs don’t cause more problems than they solve. Our final challenge is now deciding which system works best for us, which is going to depend a lot on exactly what kind of problem you’re trying to solve.

If speedy decisions aren’t important then you might as well put a human in charge and just have the AI give out advice. If you’ve got a spare full-time employee around that can babysit your AI then you can switch it around and give the AI control but give the human the override switch. If your problem has well defined error conditions than you can build a bounded AI pretty easily. And if you have tons of dev time and budget it might be wise to at least experiment with building an AI for monitoring your other AI.

And of course a lot of these ideas can be mixed together. An AI that needs human permission to do anything might still benefit from boundaries that prevent it from wasting human time with obviously wrong solutions. And an AI monitoring AI can’t catch everything so keeping a human or two on staff is still a good idea.

So lot’s of factors to consider. Makes you wonder if maybe we should try building an AI for helping us decide how to control our AIs…