# Matt Might Matt Might's blog This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How to Change Habitual Behavior Using the Transtheoretical Model DevFeed: [How to Change Habitual Behavior Using the Transtheoretical Model]() Original publisher: [Read original article]() Published: 2024-01-14T18:14:05Z Content type: tutorial Language: en Sources: [Matt Might]() Topics: [Processes](), [maintenance]() Tags: [behavior](), [change](), [howto]() ### AI overview This tutorial explains the transtheoretical model of behavior change, which describes six stages: precontemplation, contemplation, preparation, action, maintenance, and relapse. It recommends tailoring interventions to the stage of change when introducing desired behaviors or eliminating undesired ones. ### Source excerpt In theory, behavior change should be easy. At first glance, it seems like you control your behavior. So, if you desire different behavior, why doesn't your behavior change as instantly as your desire to change it? In short, lasting change of habitual behaviors is a multi-stage process. In 1977, as psychologists James Prochaska and Carlo DiClemente were studying the behavior of smokers, they identified these stages. Their transtheoretical model of behavior change captures the process of behavior change in six different stages: (1) precontemplation; (2) contemplation; (3) preparation; (4) action; (5) maintenance; and (6) relapse. DALL-E's depiction of behavior change in the transtheoretical model. In the years since, this landmark model has been found to be applicable to many habitual human behaviors. The key takeaway is that the odds of successful long-term behavior change improve if you calibrate your strategy to the stage of change you're in. The goal of this article is to provide an actionable summary of this model and interventions for each stage, so that you can more effectively change your behavior in the long-term. Understanding the model may also help you to understand why you may have struggled with behavior change in the past. Disclaimer: This article is based on my survey of the scientific literature and my own lived experience. I am not a mental health professional, and if you are struggling with behavior change or any other mental health condition, please immediately consult a qualified professional. Click here to read the rest of the article ## Hello, Perceptron: An introduction to artificial neural networks DevFeed: [Hello, Perceptron: An introduction to artificial neural networks]() Original publisher: [Read original article]() Published: 2023-05-05T14:05:31Z Content type: tutorial Language: en Sources: [Matt Might]() Topics: [Neural Network](), [Artificial Intelligence](), [Generative AI](), [Algorithm](), [circuit]() Tags: [ai](), [algorithm](), [circuit](), [generative-ai](), [introduction](), [neural-networks]() ### AI overview This tutorial introduces artificial neural networks through Frank Rosenblatt's perceptron. It explains how a single perceptron can be trained to mimic the AND, OR, and NOT logical functions, then examines its inability to learn XOR as motivation for multilayer neural networks. ### Source excerpt Generative AI tools like ChatGPT and Midjournery are able to replicate (and often exceed) human-like performance on tasks like taking exams, generating text and making art. Even to seasoned programmers, their abilities can seem magical. But, obviously, there is no magic. These things are "just" artificial neural networks - circuits inspired by the architecture of biological brains. An AI-imagined image of a neural network (Midjourney) In fact, much like real brains, when broken down to their building blocks, these systems can seem "impossibly simple" relative to what they achieve. (Modern computing is also magical in that sense, in that all of what computers are able to do reduces to simple logical building blocks - gates that calculate basic operations with truth values, such as AND, OR and NOT.) The purpose of this article is to give programmers without much exposure to machine learning an understanding of the key building block powering generative AI: the artificial neuron. Toward that end, this article has three goals: to implement a perceptron - the simplest artificial neuron; to train perceptrons how to mimic AND, OR and NOT; and to describe the leap to full-fledged neural networks. Click here to read the rest of the article ## How to Use GPT-4 to Create Interactive Text-Based Adventure Games DevFeed: [How to Use GPT-4 to Create Interactive Text-Based Adventure Games]() Original publisher: [Read original article]() Published: 2023-04-01T15:48:44Z Content type: tutorial Language: en Sources: [Matt Might]() Topics: [Generative AI](), [Game engine](), [Development]() Tags: [game](), [generate](), [gpt](), [how-to](), [interactive](), [make](), [save](), [text]() ### AI overview This tutorial explains how to use GPT-4 as a game engine for interactive text-based adventure games by defining a fictional universe and designing a prompt to simulate gameplay. It also describes adding a save-game feature so players can save and resume the game state. ### Source excerpt Compared to prior versions, GPT-4 is more capable at writing fiction. Combined with its advances in reasoning, this allows it to maintain a consistent state in a fictional universe as it emulates a text-based adventure game like the classic Zork. In this article, I'll explain how to convert GPT-4 into a game engine for interactive text-based adventure games with just two simple steps: Create a descriptive lore to define the universe and the player Engineer a prompt to simulate a text-based adventure game You can even add a save game feature that allows you to save the state and resume play later. While GPT-3 works with these techniques, it tends to create worlds with less coherent states and the game has shallower narratives compared to GPT-4. The backstory Figuring out how to create these games emerged from my kids' bedtime. Before they go to bed, I like to spend 15-30 minutes doing something educational and entertaining, such as: reading a book or a graphic novel; doing simple crafts like paper airplanes; asking a question on their mind and searching for the result; choosing an object to have 3D printed by morning; or writing a small program or part of a larger program. Not surprisingly, generative AI expands what you can do in 15-30 minutes! For instance, this image took about 30 minutes from start to finish, combining Midjourney to generate a base image, Lensa to do touch-ups and change the background and then DALL-E to tweak parts of it and extend the borders: The opportunities for text-based gaming turn out to the just as rich! My daughter had created a fictional universe with friends at school, complete with its own lore. So, we dropped in the lore and then asked it to act like a role-playing game in that world. We ended up spending an hour exploring this world brought to life, completing the first "quest" it had imagined for us. Click here to read the rest of the article ## 26 programming languages in 25 days, Part 2: Reflections on language design DevFeed: [26 programming languages in 25 days, Part 2: Reflections on language design]() Original publisher: [Read original article]() Published: 2022-12-31T19:36:56Z Content type: opinion Language: en Sources: [Matt Might]() Topics: [Programming language](), [Functional programming](), [Programming](), [Data structures](), [Advent of Code]() Tags: [advent-of-code](), [algorithms](), [algorithms-and-data-structures](), [functional](), [programming](), [programming-languages]() ### AI overview The author reflects on completing Advent of Code 2022 with 26 programming languages in 25 days. They found that functional techniques, algorithms, and data structures generally mattered more than language performance, while language design choices such as syntax, typing, and purity affected readability, debugging, and development speed in different puzzle contexts. ### Source excerpt I recently wrote about completing Advent of Code 2022 using a different programming language (or two) every day for 25 days. That note focused on the strategy, tactics and logistics involved in using 26 languages in 25 days without saying much about the languages or the experience itself. Using so many languages in such a short span provided insight into tradeoffs in language design. Here are my two high-level reflections from the experience: Good program design in the first part of each puzzle - especially more functional techniques and abstractions - tended to make the second part easier. So, in general, functional languages seemed to have the advantage in the puzzles. Using better algorithms and data structures was more important than having a "faster" programming language. There was never a time where rewriting in another language felt like the right way to get better performance. Read on for more specific reflections on language design. Click here to read the rest of the article ## 26 programming languages in 25 days, Part 1: Strategy, tactics and logistics DevFeed: [26 programming languages in 25 days, Part 1: Strategy, tactics and logistics]() Original publisher: [Read original article]() Published: 2022-12-27T23:28:42Z Content type: article Language: en Sources: [Matt Might]() Topics: [Programming](), [Programming language](), [Advent of Code](), [Learning]() Tags: [advent-of-code](), [code](), [languages](), [learning](), [programming](), [strategy]() ### AI overview The author describes solving Advent of Code's 25 daily puzzles with a different programming language each day, using 26 languages in total. The article explains the strategy, language ranking, reserves, and lessons from learning unfamiliar languages during the contest. ### Source excerpt Since making a sudden leap from computer science to academic medicine about seven years ago, I haven't programmed as much. I love what I do in medicine and biology, and I love helping patients. But, I have missed programming - and programming languages. Then I came across the Advent of Code on Mastodon - a series of daily two-part puzzles for programmers that runs for 25 days. On a whim, I solved the Day 1 puzzle using awk. I solved Day 2 in TeX (which underpins LaTeX) to reboot an old skill. After that, I wondered if I could solve each of the 25 puzzles using a different programming language every day. So, I did. In the end: on 12 days, I had to learn a new programming language from scratch, and then use it to solve that day's puzzle; on 4 days, I used languages where I had very little experience; and on the other 9 days, I used languages I had known well at some point. In the end, I used 26 languages, because I combined two on Day 21 (sed and bc), turning the experience into a rapid-fire "breadth-first search" of programming language space. Learning how to learn a new language became the key meta-learning. If you'd like to try the breadth-first search yourself, I have distilled advice on the strategy, tactics and logistics involved in using a new programming language every day for 25 days. You will end up with an appreciation of the relative strengths and intended domains of different languages. Click here to read the rest of the article ## Career and Tenure Advice Through the Experience of Raising a Child with a Rare Genetic Disease DevFeed: [Career and Tenure Advice Through the Experience of Raising a Child with a Rare Genetic Disease]() Original publisher: [Read original article]() Published: 2015-08-18T16:33:03Z Content type: opinion Language: en Sources: [Matt Might]() Topics: [Computer science]() Tags: [academic](), [advice](), [career](), [computer](), [howto]() ### AI overview The article discusses academic tenure and career advice through the author's experience as a computer science professor raising a child who was diagnosed with NGLY1 deficiency. It describes how the family helped identify the rare genetic disease, found other patients online, and became involved in biological and medical research. ### Source excerpt Even before I got tenure, folks have told me they're "looking forward to an academic advice post on tenure." From how to get a Ph.D. to monthly resolutions for grad students, I've found it easy to write academic posts on just about every topic. Except this one. I got tenure over a year ago, yet every time I tried to sum up my views on tenure, I froze. Every path to tenure is inherently unique and non-repeatable. How could I possibly provide general advice? Plus, I wouldn't wish an exact repeat of the last seven years of my life on even Reviewer Number 3 - for reasons that will soon be obvious. And then, while walking to work in Boston on a recent summer morning, a question on Quora gut-punched me without warning: How can I minimize my chances of having a disabled child? I don't want an autistic or Downs child, for example. I am planning on having a strong career in computer science or medicine, and I want to marry someone who is doing the same and have kids some day, but I'm terrified that they'll be severely disabled, and my wife won't agree to abort the fetus. I (maybe naively) believe in love, so I wouldn't necessarily be able to leave my wife if I truly loved her and she refused to abort. Note that this is purely hypothetical. I am only 16 years old at the moment, but I have thought about this a lot. This question burrowed deep into my consciousness, a parasite sapping my ability to think about anything else. When I got to my office, the raw response below ejected out of my brain through my fingertips. And, in the course of answering, I ended up giving general advice on tenure. I've distilled specific thoughts on my experience with tenure below as well. Click here to read the rest of the article ## Counting hash collisions with the birthday paradox DevFeed: [Counting hash collisions with the birthday paradox]() Original publisher: [Read original article]() Published: 2015-07-17T03:33:41Z Content type: tutorial Language: en Sources: [Matt Might]() Topics: [hash](), [hashing](), [function](), [Network]() Tags: [hash](), [hashing](), [sequence](), [technical]() ### AI overview This technical note derives a closed-form formula for the expected number of hash collisions among n values when a uniform hash function has a range of D possible outputs. It explains the connection to the birthday paradox and clarifies that the formula counts sequential matching events rather than unique hits or collision pairings. ### Source excerpt The birthday paradox observes that in a room of 23 people, the odds that at least two people share a birthday is 50% The same logic that drives matching birthdays also drives the probability that one can find collisions with a hash function. In other words, if you have a uniform hashing function that outputs a value between 1 and 365 for any input, the probability that two hashes would collide in a set of 23 values is also 50% Another useful calculation is the expected number of collisions for a sequence of \(n\) values when the range of the hash function contains \(D\) hashes. The closed form solution is: \[ n - D + D \left( \frac{D-1}{D} \right)^n \] There are a few places online that have this (or an equivalent) closed form solution listed, but I couldn't find anywhere that included the derivation of this form, so I've rederived it and posted it here as a technical note. (My present interest in this calculation comes from the number of matches that will happen in a patient-matching network that attempts to match patients having the same disease, assuming the are \(D\) total diseases possible and \(n\) patients in the network.) Read below for the derivation in terms of generalized birthdays. Click here to read the rest of the article ## 12 resolutions for programmers DevFeed: [12 resolutions for programmers]() Original publisher: [Read original article]() Published: 2012-01-03T15:06:54Z Content type: article Language: en Sources: [Matt Might]() Topics: [Programming](), [Computer science](), [Mathematics](), [Security](), [Software](), [Programming language](), [data]() Tags: [advice](), [article](), [data](), [mathematics](), [programming](), [programming-language](), [security](), [software](), [technical]() ### AI overview This article presents twelve month-sized technical and personal resolutions for programmers, intended to prevent creative and technical stagnation. The suggestions include exploring analog activities, improving health, learning mathematics and theory, focusing on security, learning software and programming languages, and completing a personal project. ### Source excerpt It's important for programmers to continuously challenge themselves in order to avoid creative and technical stagnation. In the spirit of the new year, back in 2012, I compiled twelve month-sized resolutions to help avoid that stagnation. I've updated that list for 2023. Each month is an annually renewable technical or personal challenge: Go analog. Stay healthy. Embrace the uncomfortable. Automate. Learn more mathematics. Focus on security. Back up your data. Learn more theory. Engage the arts and humanities. Learn new software. Learn a new programming language. Complete a personal project. Read on for my suggestions. (If you enjoy this article, you'd likely also enjoy what every computer science major should know or possibly 12 resolutions for grad students.) Click here to read the rest of the article