In this video, I'm going to finish the 
larger predicate. 
And the function itself is mostly 
straightforward, but there's two 
interesting things that come up here. 
One is an interesting point about writing 
tests for functions that consume two of 
the same type of data. 
And the other is the pretty fun point 
where you've built up a whole chain of 
helpers, going from an initial function 
to a helper to a helper to a helper. 
And you finally finish that last helper, 
and bang, bang, bang, bang, bang. 
And if you're lucky the whole thing 
works. 
Okay. 
Now, I need to finish the larger 
predicate and the examples are what I 
need to do next. 
And I'm not going to use the name 
Constance I defined for the last 
function. 
I'll show you why. 
Let me just get started, check-expect 
larger. 
It's really easy in a function like this. 
Here's function that consumes two images. 
And it's going to have to get the width 
and height of both images. 
And it's really easy in a function like 
this to make a mistake, where, for 
example, you used the same image twice. 
Or you used the width twice instead of 
the width and the height. 
And so what I'm going to do is I'm 
going to use numbers for my images. 
But are very sensitive to making any one 
of those mistakes. 
So watch this, I'll say 3 by 4, solid and 
red. 
Oops, I mean, rectangle, I was thinking 
so hard about the numbers, I forgot to 
make the rectangle. 
Rectangle 3, 4, solid, red and rectangle 
2, 6, solid, red. 
Now the area of both of those is the 
same, it's twelve, so that should be 
false. 
Now we can make the other four cases 
where we'll vary each of the numbers a 
little bit. 
So now, let's make this be 5. 
Now the first rectangle is bigger. 
We'll make this be 5. 
First rectangle is also bigger. 
We'll make Res ?? 
B5. 
Second rectangle is definately bigger, in 
other words, the first rectangle is 
definately not bigger. 
And for this last one, we'll make six be 
seven. 
The first rectangle is defiuntaely not 
bigger. 
So those are examples run to make sure 
it's well formed. 
It is. 
Lots of tests are failing. 
Now, let's see. 
This is a function operating on two 
primitive atomic data. 
So we have to make the template for 
ourselves. 
The template is defined. 
Larger question mark, img 1. 
Img2 and if it was just img2, that would 
be the template, but we have an 
additional atomic parameter, so we add 
img1. 
There we go. 
Now what do I need to do? 
Well, I need to get the area. 
Of one of them. 
So that's the width times the height, and 
I'll copy here, because I was very 
careful about that. 
So now I've got the top line is the area 
of image 1. 
The bottom line is the area of image 2. 
And 1 is bigger than 2 if that's a 
greater than, and I had to fix the 
indentation, run. 
Wow. 
All at once, only one test is failing. 
Let's go see which test this is. 
If I insert I3 into cons I2, I3. 
Oh, this is just wrong, I made this test 
wrong. 
This was supposed to be the test. 
Where I was inserting I3 into a list that 
already had I1 and I2. 
That was just a broken test. 
If I insert I3 in that list, it should go 
at the end. 
Cons I1, cons I2, cons I3. 
Empty is the result. 
Now let's run it. 
All 17 tests passed. 
So here you're seeing a thing that 
happens all the time, when you start 
designing more complicated functions. 
And you have to have more and more 
helpers. 
Is you get to the end, and it kind of all 
comes together. 
And if you're lucky, every single test 
passes. 
In that one final moment every single 
test now passes. 
You're not usually that lucky. 
You're almost never that lucky. 
Usually what happens is you get that 
final piece done and a bunch of tests 
start working. 
But sometimes what happens is there's 
some tests that are broken. 
Like in this case where there was a 
broken test. 
Other times, what happens is that the 
tests are broken. 
But that some function along the way 
actually isn't correct. 
And then things will only partially work, 
or not work at all. 
This was a pretty good case. 
We finished the last function in the 
chain of helpers. 
And we had only one broken test that we 
had to go fix. 
But whether it all works in one fell 
swoop or not isn't so much the real 
issue, as much as that now going back to 
this picture, what happens is all at 
once, all our boxes get checked off 
because we finished the helper larger 
which basically finishes insert. 
Which basically finishes sort, which 
basically finishes arrange-images. 
Bang, bang, bang, bang, bang. 
We check off the whole chain of functions 
that were waiting on this last helper to 
be done. 
So, from these lectures for the first 
part of this week, two main lessons. 
One is some more helper rules. 
The rule about function composition. 
The rule about operating on arbitrary 
size data. 
The rule about a changing knowledge 
domain. 
The other is this more macro notion that 
often when we design more complicated 
functions, we end up having to design a 
bunch of helper functions, as we use 
different helper rules to split the work 
the main of the function out. 
These rules have an effect Similar to the 
effect that the reference rule has, but 
in this example we've seen some 
additional rules. 
Whenever you're designing functions, for 
the rest of this course and in the rest 
of your life, keep these helper rules in 
mind. 
They're good guidelines for where to put 
in a helper function. 
Some programmers will adopt their own 
style for using rules in other places, 
but these are good general principles for 
where to put helper functions.