Skip to main content

C'est la Z

Category: Programming

Lanternfish and lots of data (AOC 2021 Day 6)

Today we had to model the growth of the lanternfish population (problem here). Lanternfish spawn new lanternfish every seven days. The trick is that the original starting population consists of fish at different points in the cycle. For instance, if your input data was 3,2,4 then each fish would spawn a new fish in three, two, and four days respectively. The new fish would set their timers to 8 and start counting down to their spawn date on the next day and the original fish would reset it's timer to 6.

One man's complex is another man's simple (AOC 2021 Day 5)

Yesterday I wrote about the virtues of a simple straightforward solution as opposed to a super "clever" one. Today reminded me that what seems simple to one person might be clever to another. Having successfully survived bingo with a giant squid, Today's challenge had us navigating our sub so as to avoid dangerous parts of the ocean. We were given a bunch of lines represented by endpoints as input.

Working code is better than clever code (AOC 2021 day 4)

I always tell my students that the cleverest program is worthless if it doesn't actually work. There are always some kids in class that all too often try to write the fanciest solutions. They're the ones that write int l(char *s){return !*s?0:(l(++s)+1);} instead of something like: int string_length(char *s){ int i = 0; while (s[i] != 0){ i=i+1; } return i; } to calculate the length of a string.

Work through the example!!!!!

It's that time of year again. Yep, you got it. Time for Advent of Code. I'm not feeling nearly as motivated as in past years but so far so good. Finished the first three days. Today I got a good reminder - work through your examples. You can find today's problem here. For part 1 you got a list of binary numbers and had to figure out how many ones and zeros there were in any given digit.

Coding For Problem Solving

Like most CS educators I'm a regular reader of Alfred Thompson's blog. Alfred's latest post is spot on but there was a line in it and a particular Twitter response that reminded me that we so often forget a big reason why people learn to code. Alfred mentions, as did that Tweet about coding to solve problems. What problem are you trying to solve. This is the mainstream push - programming helps you solve problems.

Back To Python

With summer right around the corner I'm hoping to spend at least a little time on some personal coding projects. There are a few work related tools I'd love to develop and just some random areas of CS I'd like to explore. If I finish them, the work projects will be web based. I was thinking about using this as an opportunity to do a deeper dive into Clojure having used it for some experiments and competitions like Advent of Code but at the end of the day I decided not to.

Give me a break (and a continue)

What can I do to discourage my students from using the "break" statement? That was more or less the gist of the comment and it elicited some good responses. This time the conversation was on Facebook but I've seen this one and participated in it many times before. I never liked the question when presented as a "how can I stop them" one. I equally dislike when the offered advice is basically "never use break no matter what" or something similar.

Globals Breaks And Returns, oh my

Never use global variables Never break out of a loop These are two "best practices" that are frequently touted in early CS classes both at the high school and college level. They came up a couple of times yesterday. Once in the Facebook APCS-A teachers group and once on Alfred Thompson's blog. Alfred post was topically on global variables. Actually it was deeper than just global variables.