And now it’s all this

I just said what I said and it was wrong
Or was taken wrong

Expanding

October 15, 2024 at 10:41 AM by Dr. Drang

Regular readers¹ know that I like to watch mathish YouTube videos from Numberphile, Stand-up Maths, and Mind Your Decisions. Unfortunately, this leads YouTube’s machine learning system to believe that I want to watch all math videos, no matter the level or quality. So it keeps pushing dull videos at me in which an overhead camera records the hands and pen of the presenter writing out line after line of elementary math. There are apparently an infinite supply of these things.

Occasionally, one of these videos has something in the thumbnail frame that catches my eye, and I click on it despite myself. Here’s a video I saw last night that pretends there’s a connection between a binomial expansion and Stephen Hawking. What it really does is solve what it says is a problem from a high school entrance exam. No Hawking at all.

The goal is to simplify this expression:

It could be argued that this is already in a pretty simple form—it’s certainly compact—but in this case, “simplify” means to get rid of the exponent.

If you can bear the tedium of the video, you’ll see that its solution goes through some algebra and various levels of substitution. It takes a very long time, and not just because the presenter insists on writing out every little step along the way.² The entire approach to solving the problem is inefficient.

Because this is an exam problem, getting the solution quickly is important. To my mind, the fastest solution is to expand the binomial directly. I don’t have the binomial coefficients memorized up to the 10th degree, but Pascal’s Triangle can be built in a jiffy:

                              1                                
                           1     1                            
                        1     2     1                         
                     1     3     3     1                     
                  1     4     6     4     1                  
               1     5    10    10     5     1              
            1     6    15    20    15     6     1           
         1     7     21   35    35    21     7     1         
      1     8    28    56    70    56    28     8     1      
   1     9    36     84  126   126    84    36     9     1   
1    10    45   120   210   252   210   120    45    10     1 

You know how to put this together, right? Each new row starts and ends with a 1, and the other terms come from the sums of the terms in the previous row diagonally to the left and right, e.g.,

and so on. Because of the symmetry, you only have to calculate about half the terms.

So the expansion of $(\sqrt{2}-1{)}^{10}$ is

where I’ve used identities like

and

to simplify each term in the expansion.

Now we can do the various multiplications and collect the terms with and without the $\sqrt{2}$ terms to get

which gives us the correct answer:

While there may be some cleverness to the YouTuber’s method of substitution and resubstitution, this is certainly more straightforward and less likely to generate algebra mistakes—both of which are important when you’re under pressure during a test. The main thing to remember is that the odd powers of $\sqrt{2}$ have negative signs and the even powers don’t.

I suppose it’s unfair for me to insult someone who’s trying to help students, but his slow solution isn’t going to be very helpful. And he shouldn’t pretend that his video has anything to do with Stephen Hawking.

Touch and run

September 24, 2024 at 12:21 PM by Dr. Drang

Here’s one last bit of followup on my Finder/Terminal tool posts. In the first post on the topic, I mentioned that I had created a bunch of zero-length JPEG files using the touch command. And in both the first and second posts, I talked about how long the sel command took when there were hundreds of files to select. I thought it worth a post on how I made hundreds of zero-length files to test out the script.

The short answer is this:

run -f 'img-{:03d}.jpg' 500 | xargs touch

which created, in the current directory, 500 files named img-001.jpg through img-500.jpg. We’ll turn this into a long answer by going through each part.

You won’t find the run command on your computer unless you read this post from a few years ago, in which I gave its Python source code. But I used run because I have it and like it. We’ll get to using commands that are on your computer further down.

The usage message for run is this:

Usage:
run [options] <stop>
run [options] <start> <stop>
run [options] <start> <stop> <step>

Generate a run of integers or characters. Similar to jot and seq.

Options:
    -f FFF   formatting string for number
    -s SSS   separator string
    -c       characters instead of integers
    -r       reverse the run
    -h       show this help message

The run of numbers can be integers or reals, depending on the values of start, 
stop, and step. The defaults for both start and step are 1. If -c is used, 
then start and stop must both be given as characters and step (if given) is an 
integer.

As you can see, I used run with an -f option to put each number generated into a string. The formatting code used in the argument to -f follows the Python format string syntax. Most of the code is repeated verbatim; the part inside the curly braces tells run to format each number as three characters long with leading zeros, if necessary. The output of the run command is

img-001.jpg
img-002.jpg
img-003.jpg
.
.
.
img-499.jpg
img-500.jpg

What we want to do is run the touch command with each one of these filenames as its argument, e.g.,

touch img-001.jpg

The main purpose of touch is to update the modification timestamp on the given file. But if the file given as the argument to touch doesn’t exist, a zero-length file of that name is created. It’s this feature we’re going to exploit.

The problem with the way touch works is that it doesn’t take the filename from standard input—it needs it to be an argument. So we can’t just pipe the output of run into touch. Luckily, the xargs command is available. It constructs an argument list from standard input (the list of img-nnn.jpg file names) and executes the given utility (touch) with that argument list. Boom. On my M1 MacBook Air, it takes about a tenth of a second to create all the files.

But run isn’t necessary. There are two commands already on your Mac, jot and seq, that do much the same thing as run. I wrote run because I don’t like the syntax of either jot or seq, but they’re both fine for this simple case. We can create the same files as above with

jot -w 'img-%03d.jpg' 500 | xargs touch

or

seq -f 'img-%03.0f.jpg' 500 | xargs touch

Both jot and seq use printf-style formatting codes, which are the parts that start with percentage signs. Note that jot uses -w instead of -f as the option and that seq treats the numbers as floating point values instead of integers. This latter is why its number formatting bit has to be %03.0f instead of the simpler 03d. These minor annoyances are some of the reasons I wrote run.

Unsurprisingly, jot and seq are faster than run, but they’re all so fast I had to use the time command to learn the difference between them. My preference for the syntax of run far outweighs its tiny additional runtime.

touch img-{001..500}.jpg

echo img-{001..020}.jpg

Improved Finder/Terminal tools

September 20, 2024 at 4:32 PM by Dr. Drang

A couple of days ago, I got an email from Loren Halter, who had some improvements to my Finder/Terminal tools. I was going to add another update to that post, but realized I had more to say about Loren’s stuff than would fit comfortably in an update. So here we are with a new post.

First, Loren put his work in this gist, so you can review and copy them for your own use. There are three functions Loren includes in their .zshrc dotfile¹ to ease the use of the Finder and Terminal together. They are lsf, cdf, and sel, and we’ll go through each of them in turn.

lsf is a variant of the ls command that lists, in the Terminal, the contents of the front Finder window. I can’t say that I foresee myself using this function, as the Finder window itself shows its contents. Presumably, Loren uses this to feed a list of file names to another command, but I prefer doing that sort of thing with my Terminal’s working directory set to the directory that contains the files of interest; in such cases, ls suffices. But it may be just the thing for you.

Next comes cdf, which changes your working directory to that of the front Finder window. It is essentially the cd command combined with my ;dir abbreviation. While it’s not a huge timesaver, I do this combination enough that I decided to add it to my .bashrc. As I was scrolling through the file to find a good place to put it, I found a function called cdff, which was apparently a long-forgotten attempt on my part to do the same thing (I assume the ff part meant “front Finder”). I won’t show it to you, because both the AppleScript and shell scripting aspects of it were a horrible mess. I suspect it didn’t even work, which is why I don’t remember anything about it.

Anyway, I decided to take Loren’s idea for cdf and make my own version of it:

bash:
1:  function cdf() {
2:    target=$(osascript -e 'tell application "Finder" to return POSIX path of (target of front Finder window as alias)')
3:    cd "$target"
4:  }

Comparing Loren’s version with mine, you’ll see the error handling code in theirs that I’ve not included in mine—I’m just an outlaw, I guess. What I wanted was for my cdf to work exactly as combining cd with ;dir would, and I don’t really see much danger in not including the try/on error code.

(What Loren’s code handles that mine doesn’t is the case in which there are no open Finder windows. Loren’s cdf will then cd into the Desktop folder; mine will belch out an error message. I don’t want that protection because my goal is to never work in the Desktop directory. In my experience, doing so, even “temporarily,” leads to a clutter of files on the Desktop that sit there far longer than they should. If you’re more disciplined than I am, by all means, use Loren’s version.)

Which leaves us with sel. I mentioned in my earlier post that my version of sel could take several seconds to run if it’s selecting hundreds of files. In my tests, Loren’s code runs in about a third of the time as mine. That considerable reduction in runtime came from changing the way AppleScript constructs the list of files to select. You may recall that my version of sel generates AppleScript that looks like this

applescript:
tell application "Finder"
    set theFolder to target of front window as alias
    set theFiles to {}
    tell folder theFolder
            set end of theFiles to file "20240915-001.jpg"
            set end of theFiles to file "20240915-002.jpg"
            set end of theFiles to file "20240915-003.jpg"
            set end of theFiles to file "20240915-004.jpg"
            set end of theFiles to file "20240915-005.jpg"
            set end of theFiles to file "20240915-006.jpg"
            set end of theFiles to file "20240915-007.jpg"
            set end of theFiles to file "20240915-008.jpg"
            set end of theFiles to file "20240915-009.jpg"
            set end of theFiles to file "20240915-010.jpg"
        end tell
    select theFiles
    return
end tell

and then runs it. Loren’s sel generates AppleScript that looks more like this:

applescript:
tell application "Finder"
    set theFiles to {}
    set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-001.jpg" as alias
    set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-002.jpg" as alias
    set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-003.jpg" as alias
    set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-004.jpg" as alias
    set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-005.jpg" as alias
    set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-006.jpg" as alias
    set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-007.jpg" as alias
    set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-008.jpg" as alias
    set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-009.jpg" as alias
    set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-010.jpg" as alias
    select theFiles
    return
end tell

Now, I think my code is more elegant looking, and it takes advantage of some nice AppleScript features; but again, Loren’s runs in about a third of the time. Loren believes this speedup comes from his code using the full path to each file, eliminating the work AppleScript has to do in the tell folder block of my code. I agree.

When faced with the choice between elegant but slow autogenerated code that no one sees and cruder but speedy autogenerated code that no one sees, I know which one I’m going to take. I still preferred having sel as a command script rather than a function, and I also wanted it written in my style to make it easier to update if necessary. So I incorporated Loren’s insight into my sel, giving me this:

bash:
 1:  #!/bin/zsh
 2:  
 3:  # Open Finder window to the current directory and select all the files
 4:  # in that directory whose names are passed to this script via stdin.
 5:  
 6:  # Open a Finder window to the current directory. 
 7:  open .
 8:  
 9:  # Construct the AppleScript in three parts.
10:  # 1. Initialize variables and start telling theFolder.
11:  applescript='tell application "Finder"
12:    set theFiles to {}
13:  '
14:  
15:  # 2. Add all the files from stdin to theFiles list
16:  while read f; do
17:    thisFile="$PWD/$f"
18:    applescript+="  set end of theFiles to POSIX file \"$thisFile\" as alias
19:  "
20:  done
21:  
22:  # 3. Stop telling theFolder and select theFiles. Return nothing.
23:  applescript+='  select theFiles
24:    return
25:  end tell'
26:  
27:  # Run the AppleScript.
28:  echo "$applescript" | osascript -

The key is in Lines 17–18, where the full path to each file is assembled using the PWD environment variable.

Again, Loren’s code has error handling that mine doesn’t, although in this case the error handling basically just throws up a dialog box telling you what the failure is. In my sel, error messages are printed in the Terminal by the system.

Thanks to Loren for the code improvements and a better understanding of AppleScript.

Am I blue?

September 17, 2024 at 12:23 PM by Dr. Drang

The popular “Is my blue your blue” game is questionable as a test of color perception, in that monitor settings and lighting conditions differ, but it presents its results in a way that I really like.

The game fills your screen with a series of colors along a blue-green spectrum and asks you whether the displayed color is blue or green. The colors get closer together as the game proceeds until it has enough answers to tell you the boundary between your ideas blue and green. If you’re like me, the last few colors should all have been answered “neither,” but that’s not a choice. The idea is to insist on a binary choice and find your boundary between the two.

I played it yesterday on my iPhone and got these results:

What I like about the graph is that it’s both clever and self-explanatory. When you look at it, these are the things you know immediately:

1. The horizontal axes represents the hue, which has been spread across the entire background of the graph. This is a much better way of presenting the hue than using a value.
2. Your threshold between green and blue is the dashed vertical line. This comes from both the graph and the text below it.
3. The vertical axis represents the fraction (or percentage) of people who categorized all colors to the left of the given color as blue. We know that because the jagged S-shaped curve, called the “threshold distribution” in the little legend at the bottom right corner, starts out low at the green end and runs up to the top as it moves toward the blue end. Also, the text says my boundary was at the 57% mark, and the vertical line intersects the jagged curve somewhat above the center of the graph.

Those of us who remember our probability and statistics class would call the jagged curve the cumulative distribution function (CDF) of the population’s blue/green threshold. But you don’t need to know this to figure out what the jagged curve means. I assume that the “population” in this case is the people who’ve played the game and that the CDF curve gets updated with every play.

So what we have is a game that presents statistical information at a glance without any long-winded explanation.¹ The only improvements I would make are:

• Replace the hue value (173) in the text with a square filled with my threshold color, paralleling what’s done with turquoise. Hue values weren’t used in the game or along the horizontal axis; there’s no need for them in the results text.
• Make the “threshold distribution” line in the legend the same thickness as the CDF. It shouldn’t be the same thickness as the dashed vertical line.

Older posts

Site search

Meta

• drdrang at leancrew
• Blog archive
• RSS feed
• JSON feed
• Mastodon
• GitHub repositories

Recent posts

Credits

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.

© 2005–2023, Dr. Drang