Okay, so last time we had a little bit of a discussion about how to work with tuples

because tuples are boring. Remember, if you want to return several values from function,

usual way to do this is via tuple. Of course, you can also return on this, but then this

is one object, but to have several objects in a return statement, you need a tuple. Now

you can unpack tuples, which is a very convenient operation in Python. And unpacking means nothing

else than to redistribute whatever is in the tuple to individual variables. You're basically

copying it out. It's not a reference to what is in the tuple, but you're copying it out.

And you noticed last time, because it's very common in Python when you have a function

returning a tuple, that you actually do it like that way. You know that the function

returns a couple of variables, and then you can do it like this and directly unpack the

tuple. But what it does actually is to do this unpacking operation. So if you provide

as many individual variables as you know there are elements in the tuple, then you can just

directly assign. So this is what you see most of the time. But of course, internally, this

is a tuple. It's an immutable tuple. And I hope you still remember what it means to be

mutable and immutable. So in this, you cannot directly modify the variables that come back

here in this tuple. But you can those, because they're just copies of whatever came out here.

So the tuple that comes out here is actually lost forever. It's just assigning here, and

then you haven't assigned a tuple directly like here. So that tuple, yeah, I mean, if

you don't care later on in your program code, that's totally fine. But very often you see

something like this. So just going through this, define a tuple. I unpack the tuple,

and then I print the individual variables, which is one, two, three, in this case, just

the elements of the tuple. And if I print the tuple directly, the print will also tell

me what it is. But in the same semantic notation as Python, so tuple will be with the parenthesis.

If it would be a list, you would see the square brackets and all of these. And then now here

in this case, you see if I print these individual variables, it's again individual variables,

but copies of it. So you can manipulate them, of course, on their own. They are, of course,

different, but you can do this. Okay. So let's check. Double check. We are recording. We

are recording. Yes. So you see my screen. I don't see the... So, okay, there's only

one left in the other meetings, so perhaps that one can end the meeting. Okay. So it

says I'm sharing and it says I'm recording. Yeah, I'm recording. So it should be all fine.

I can't see you guys online now. So if I have a question, just shout out. The meeting hour

is loud enough, so I'll hear you. Okay. So today we'll talk about two interesting concepts.

One is a programming concept, recursion. And the other one is probably remaining data structure.

We haven't discussed it in Python. Dictionaries are not part of a kind of general programming

paradigm, but they are very powerful in Python because they are part of the base language.

In most other languages, you would need to implement that data structure if you want

to use something like that. Okay. So who knows who has already heard about recursion here?

Nobody. That's very good. That's very good. So this is a very, very fundamental concept.

Every computer science student will learn in turn one. Yeah, that's the 101 of computing

because it's probably the one concept that links math directly to computing. The concept

is relatively simple. It's based around the idea of divide and conquer or decrease and

conquer. So you try to make a large problem. You try to split it up into a trivial case

and a smaller problem. I'll show you in a moment what this actually means. So what you

want to achieve is to reduce the problem to a simple version of the same problem. And

if some of you started something math related, you will come across this law in math, actually,

because any sequence or all of these sort of things, continuous functions are usually

defined in that way. And you say, okay, the next value is evaluate that function, which

is a simpler version of that function. So in semantically, so in programming, there

comes the bummer. If you define a function, you can call that function within the body

of that function. That's crazy, right? So you define function, whatever, and within