And now it’s all this

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

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.

---

Finder/Terminal tools

September 16, 2024 at 2:58 PM by Dr. Drang

When I’m working at my Mac, some things are most effectively done using the Finder’s GUI and some are best done through the command line in the Terminal.¹ I switch between the two with the help of a handful of simple automations. I know I’ve written about one of them before, but I don’t think I’ve written about the others. Certainly not as a collection. So here are four little tools I use to go back and forth between the Finder and the Terminal.

open .

The open command is one of Apple’s (originally NeXT’s) great contributions to the integration of the command line and the GUI (the others are pbcopy and pbpaste). It can be used to open documents, but I use it most often this way:

open .

This command, when invoked in the Terminal, activates the Finder and opens a window to the current working directory (that’s the dot). It’s smart enough to know if there’s already a Finder window showing that directory; if so, it just brings that window to the front instead of creating a new one.

Terminal Here

The converse of open . is a Keyboard Maestro macro I wrote called Terminal Here. When the Finder is active, invoking Terminal Here via the ⌃⌥⌘T keyboard shortcut opens a new Terminal window and sets its working directory to the one shown in the frontmost Finder window. Because it was written by me, not Apple, it isn’t as smart as open . in that it will open a new Terminal window even there’s already one open and set to that directory. In the many years I’ve used this macro, I haven’t found that lack of intelligence a problem, so I haven’t put any effort into making it smarter.

You can download the macro or just build it yourself. Here’s what it looks like in the Keyboard Maestro editor:

It’s just a single step that runs this AppleScript:

applescript:
1:  tell application "Finder"
2:    tell front Finder window
3:      set myPath to POSIX path of (target as alias)
4:    end tell
5:  end tell
6:  
7:  tell application "Terminal"
8:    activate
9:    do script "cd " & quote & myPath & quote
10:  end tell

The first stanza, Lines 1–5, gets the path to the directory shown in the front Finder window. The second stanza, Lines 7–10, activates Terminal and cd’s into that directory. Pretty simple, and you can easily change the second stanza to work with iTerm if that’s your terminal emulator of choice.

;dir

Let’s say I’m working in the Terminal and I want to change to a new directory. That’s what the cd command is for, of course, but typing the path to the new directory can be tedious—even when taking advantage of tab completion. If you have a Finder window open to the directory you want to change to, Apple has a cute way around the tedium: drag the proxy icon from the Finder window’s title bar into the Terminal after typing cd and the path will be inserted at the caret.

What’s the proxy icon? It’s the little picture of a folder that appears next to the window’s title.

This icon used to be a permanent part of the Mac’s title bars but was stupidly changed in Big Sur to be a peekaboo feature—it would normally be hidden but would appear if you put the mouse pointer over the title and waited a bit. The following year, Apple showed that it sometimes does listen to reason by adding an Accessibility preference that lets you make proxy icons permanently visible.

Anyway, while I like the idea of dragging proxy icons, it isn’t especially efficient. So I created a TextExpander snippet, triggered by typing ;dir, that would insert the path of the frontmost Finder window. When I switched from TextExpander to Typinator, I migrated it over. Both TextExpander and Typinator (and other utilities like them) have an option for running an AppleScript when an abbreviation is typed. Here’s the AppleScript that’s run when I type ;dir:

applescript:
tell application "Finder" to get quoted form of POSIX path of (target of front Finder window as alias)

It’s kind of long because of AppleScript’s “this of that of the other” syntax.

sel

The previous three automations are really simple, and I use them quite often. This last one was the most difficult to build, and I rarely use it. But when I do use it, it’s very handy. It’s a shell script named sel that’s meant to be run at the end of a pipeline. It expects a list of files to be passed into it via standard input and then opens a Finder window in the current working directory and selects those files. For example,

ls *.png | sel

will activate the Finder, open a Finder window in the Terminal’s working directory, and select all the files that end with .png.

The idea behind sel is that I want to use the Finder to do something with a bunch of files, but it’s easier to select the files with a shell command than it is by using the GUI. Suppose, for example, I have a directory filled with photos. The name of each JPEG file starts with the date on which the photo was taken in yyyymmdd format. If I want to select all photos taken on a certain date (perhaps because I’m going to attach them to an email or copy them to another folder) I could drag or shift-click my way through them, but it’s faster and more accurate to run

ls 20240915*.jpg | sel

and immediately see the results:

(If you’re wondering why all these JPEG files are zero bytes long, it’s because I made them using the touch command specifically for this example.)

I probably wouldn’t use sel if I had only ten files to select, but definitely would if I had dozens or hundreds.

By the way, I’m not thrilled with the sel name. I’d rather it were select, but there’s already a built-in bash command named select. For a while, I called my script fselect but found that I was forgetting the initial f. Time will tell if this shorter name sticks with me.

Oh, you want to see the code for sel? Here:

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 theFolder to target of front window as alias
13:    set theFiles to {}
14:    tell folder theFolder
15:    '
16:  
17:  # 2. Add all the files from stdin to theFiles list
18:  while read f; do
19:    applescript+="    set end of theFiles to file \"$f\"
20:    "
21:  done
22:  
23:  # 3. Stop telling theFolder and select theFiles. Return nothing.
24:  applescript+='  end tell
25:    select theFiles
26:    return
27:  end tell'
28:  
29:  # Run the AppleScript.
30:  echo "$applescript" | osascript -

After opening a Finder window in Line 7, it constructs an AppleScript that does the selecting of files. The exact form of the AppleScript depends on the filenames passed into sel. For the example above, the AppleScript will be

applescript:
 1:  tell application "Finder"
 2:    set theFolder to target of front window as alias
 3:    set theFiles to {}
 4:    tell folder theFolder
 5:        set end of theFiles to file "20240915-001.jpg"
 6:        set end of theFiles to file "20240915-002.jpg"
 7:        set end of theFiles to file "20240915-003.jpg"
 8:        set end of theFiles to file "20240915-004.jpg"
 9:        set end of theFiles to file "20240915-005.jpg"
10:        set end of theFiles to file "20240915-006.jpg"
11:        set end of theFiles to file "20240915-007.jpg"
12:        set end of theFiles to file "20240915-008.jpg"
13:        set end of theFiles to file "20240915-009.jpg"
14:        set end of theFiles to file "20240915-010.jpg"
15:      end tell
16:    select theFiles
17:    return
18:  end tell

The loop in Lines 18–21 of the shell script creates all the lines in the tell folder section of the AppleScript.

After the AppleScript is built and saved in the applescript variable, Line 30 then runs it by passing it to the osascript command.

I should mention a few things:

1. sel has to be run from the directory with the files you want to select. Being able to go up or down a folder hierarchy is beyond my coding skills. This limitation has never got in my way.
2. sel can take a few seconds to run if it’s selecting hundreds of files. The Finder window will appear immediately, but it will take a little while before the files are selected. AppleScript isn’t especially fast.
3. I’ve put zsh in the shebang line of sel because zsh is the Mac’s default shell, but the script runs the same under bash. If you want to translate the script to tcsh, you’re on your own.

---

Two things in ninety-nine minutes

September 10, 2024 at 10:09 PM by Dr. Drang

One of the best things about not being an Apple blogger is that I don’t feel compelled to comment on everything Apple does. I was reminded of this when I read Stephen Hackett’s roundup of yesterday’s event. It was my favorite post of the day, and he came up with a great angle on the presentation, but I really felt his struggle to get it done and off his to-do list.

It turns out, though, that I actually do have something to say about yesterday’s announcements—two of the announcements, anyway. I’m not sure it was really worth 99 minutes¹ of my remaining life to watch it in real time, but that’s an issue I’ll consider before the next event.

The first item of importance to me has to do with the two new versions of the iPhone Pro. I’m currently using an iPhone 13 Pro, so I’ve long planned to upgrade this fall. Even though, as lots of people have pointed out, the differences between the regular and Pro versions are perhaps smaller this year than usual, I still want the Pro because I take lots of photos outside in which the subject is pretty far away and needs to be brought in by as much optical zoom as the camera can muster. Piyush Pratik’s’ valiant effort (starting about 57 minutes into the presentaton) to make the non-Pro’s camera seem like it had enough zoom fell flat with me.

Which gets to the concern I had before the event. Last year, the 5X camera came on the Pro Max only, and I was wondering what I’d do if that held true this year, as well. Luckily, the 5X camera came down to the Pro (about an hour and twenty minutes [whew!] into the presentation) and I’m not faced with the prospect of buying a phone that’s bigger and more expensive than I would otherwise need.

The other item of interest was the addition of mapping to paddling workouts (about 18 minutes into the presentation) in the Workout and Activity apps. This was mentioned during WWDC, and I was glad to see that it’ll be in next week’s updates to watchOS and iOS. No waiting until “later this fall/year.”

I complained about the lack of mapping for paddling in Workout/Activity back in May. I mentioned in that post that I was going to try Strava. I did and took an instant dislike to it.² After that, I used WorkOutDoors and Paddle Logger. They both work well—I’m using Paddle Logger now—but have one serious deficiency: they chew through my watch’s battery like nobody’s business.

For example, a couple of days ago I went for a longish kayak trip on the Hennepin Canal in western Illinois. I was out on the water for about 2½ hours, and my watch’s battery went from 100% (I had charged it fully in the car during the drive to the canal) down to somewhere near 35%. I say “somewhere near” because I forgot to check it when I stopped paddling. It was at 35% about an hour later when all I had done in the meantime was drive.

My hope is that Apple’s history of battery consciousness will hold and that the paddling workout will be as parsimonious as the walking and biking workouts. I will gladly give up the extra data Paddle Logger provides if I don’t have to worry about charging my watch before every kayaking workout.

OK, there was one other part of the presentation that caught my attention: the extension of the AirPods Pro into a kinda sorta hearing aid (starting at about the 33 minute mark). Now, the AirPods Pro already have Conversation Boost, but I guess this new thing goes beyond that. I know I have hearing loss at high frequencies—more than normal for my age—but I’ve never had to boost the volume on my TV or my car stereo to a point that makes people with me uncomfortable. Still, the idea of having music adjusted to make up for my hearing deficiencies is pretty intriguing. We’ll have to wait to learn what “this fall” means for this feature.

---

Kilometers and the golden ratio

September 3, 2024 at 8:38 AM by Dr. Drang

Regular readers know I enjoy reading John D. Cook’s blog and often comment on it here. But I was a little creeped out by it a couple of days ago. It started off with something I’ve been thinking about a lot over the past several weeks, and it was as if he’d been reading my mind.

The post is about how the conversion factor between miles and kilometers, $1.609\dots$, is close to the golden ratio, $\varphi =1.618\dots$. To convert kilometers to miles, you can make a good estimate by multiplying by $\varphi$, which means that you can convert in the other direction by multiplying by $1/\varphi =0.618\dots$.

You may think multiplying by an irrational number is a pain in the ass, and you’d be right. Cook gets around this by approximating $\varphi$ by the ratio of consecutive Fibonacci numbers, so you can, for example, convert from miles to kilometers by multiplying by 21 and dividing by 13. Similarly, you can use consecutive Lucas numbers in the same fashion, multiplying, say, by 29 and dividing by 18.

The problem with these calculations is that I’m not John D. Cook, and I can’t do multiplications and divisions like this in my head without losing digits along the way. So my conversion method is much cruder: to go from miles to kilometers, I multiply by 16; and to go in the opposite direction, I multiply by 6. In both cases, I finish by shifting the decimal point to divide by 10. If I need more precision than this, I pull out my phone, launch PCalc, and use its built-in conversions.

By the way, the main reason I’ve been converting between miles and kilometers lately is that I recently switched the units I use in the Activity/Fitness app¹ from miles to kilometers. I now often find myself in the middle of one of my walking routes wondering how long it is in kilometers. I know the lengths of all my routes in miles but haven’t memorized their lengths in kilometers yet. It was while doing conversions like this that I noticed that the conversion factor was close to $\varphi$ and started doing a lot of multiplication by 16.

If you’re wondering why I bothered switching units, it’s because I enter 5k races a few times a year and I like my time to be under 45 minutes. To keep myself in shape for this, every couple of weeks I push myself to do my first 5k in that time. It’s much easier to look at my watch and know that my pace should be about 9:00 per kilometer than 14:29 per mile. Also, it’s easier to know when I’m done—marking my time at 3.11 miles is as much a pain in the ass as multiplying by $\varphi$

---

Newer posts 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