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.