In Which We Learn to Code
Feb. 13th, 2021 10:54 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
writerkitEver have those days where you are absolutely certain you have somehow messed up the process despite getting something that produces the answer the book asks for?
I am learning about lists and loops in my Python book. Logically this specific exercise is clearly an extension of the whole "x = x + 1" conceptual problem which I had to get Mathfriend to explain to me in very small words but have a good handle on now.
You are given a list: xs = [12, 10, 32, 3, 66, 17, 42, 99, 20]
The assignment is to find the product of the list using a loop.
This works:
total = int(1)
for xs in [12, 10, 32, 3, 66, 17, 42, 99, 20]:
total = int(total * xs)
print(total)
It produces the desired result. If you omit setting total to 1 at the beginning it complains about total being undefined farther down, which I get. It depends on itself; it needs to start at something. And setting it to start at 1 doesn't mess with the end result. (The previous exercise was addition and it started at zero.)
I cannot shake the feeling I am getting some part of this wrong in some way, possibly in this being the wrong approach to it, but I can't figure out another possible one with the terms the book has described so far. Especially when the addition exercise did explicitly say "set it to zero to start." I just feel like a more elegant way to do it should exist.
(Also welcome to the posts where I complain about my coding lessons. Particularly in self-teaching I find it easier to actually sit down to do things if I'm writing up a Dreamwidth post about them, so you'll be getting some chronicling of my Adventures in Code coming up.)
I am learning about lists and loops in my Python book. Logically this specific exercise is clearly an extension of the whole "x = x + 1" conceptual problem which I had to get Mathfriend to explain to me in very small words but have a good handle on now.
You are given a list: xs = [12, 10, 32, 3, 66, 17, 42, 99, 20]
The assignment is to find the product of the list using a loop.
This works:
total = int(1)
for xs in [12, 10, 32, 3, 66, 17, 42, 99, 20]:
total = int(total * xs)
print(total)
It produces the desired result. If you omit setting total to 1 at the beginning it complains about total being undefined farther down, which I get. It depends on itself; it needs to start at something. And setting it to start at 1 doesn't mess with the end result. (The previous exercise was addition and it started at zero.)
I cannot shake the feeling I am getting some part of this wrong in some way, possibly in this being the wrong approach to it, but I can't figure out another possible one with the terms the book has described so far. Especially when the addition exercise did explicitly say "set it to zero to start." I just feel like a more elegant way to do it should exist.
(Also welcome to the posts where I complain about my coding lessons. Particularly in self-teaching I find it easier to actually sit down to do things if I'm writing up a Dreamwidth post about them, so you'll be getting some chronicling of my Adventures in Code coming up.)
no subject
Date: 2021-02-23 06:59 pm (UTC)Modulo the code-style conversations above, no -- you've got it pretty much correct, at least for mutable code. (That is, conventional Python.) I could show you the Scala version, but it boils down to the same concepts.
Let's have a moment of Category Theory: this is a little deep for where you are so far, and feel free to ignore it, but you sometimes enjoy nerdy details and this is stuff that I often teach nowadays. Feel free to ping me with questions.
What you're seeing here is a concept that is known at the theoretical level as a Monoid. Don't worry about the name (there are reasons for it, but you have to draw graphs for them to make any sense) -- basically, it's the abstract-math concept of "plus".
The underlying notion is that you have a Monoid when you have a type (in this case, integers), a "combine" operator that takes two values of that type and results in another value of that type, and an "empty" value that, when combined with any other value leaves it unchanged.
So addition over integers is a Monoid, where the operation is "plus" and the empty is 0. Similarly, multiplication over integers is a Monoid, with an operation of "times" and an empty of 1. (The empty value is often called "zero"; I'm avoiding that here, in the interest of not defining "zero" as 1.) That's why your sum and product code needs different starting values: the different operators need different empties.
What makes this cool is that it allows you to abstract out those details: from this viewpoint, the "sum" and "product" of a collection of integers are exactly the same code, just changing which Monoid you are using. That's not an idle observation, either: in functional-programming languages like Scala, it's common to think in terms of those abstractions, and simply define that abstraction of "sum" once, and then you use that abstraction for all your Monoids.
Note that Monoids are actually really common. For example, think of Strings like "hello " and "world". Most programming languages allow you to say:
("hello " + "world") == "hello world"That makes sense because
+on String is another Monoid. (The "empty" value is the empty String, "".) I think that in Python you could write exactly your same code above with that Monoid, and it would just work.Anyway, enough theoretical nerding. Hope it isn't entirely confusing; questions welcome.