Keenan Crane

“Fair dice” might make you think of perfect cubes with equal frequencies (say, 1/6 on all sides) 🎲

But “fair” really just means you get the frequencies you expect (say, 1/4, 1/4 & 1/2)

We can now design fair dice with any frequencies—and any shape! 🐉

hbaktash.github.io/projects/put...

YouTube video by CMU School of Computer Science Rethinking Fair Dice

Nicely produced clip by Matt Wein and Marylee Williams about our recent dice design project at @scsatcmu.bsky.social and @adobe.com

youtube.com/shorts/jD0ag...

🎲 🎥 🐉 🪙

Tangent-point energy works for (2).

To incorporate (1) I might (strongly) penalize the distance from each data point p to the *closest* point on the curve. This encourages at least one point of the curve to pass through each data point, without pulling on the whole curve.

Thanks for the thought-provoking example. 😊

Reminds me of the Kahneman and Tversky experiments (“Steve is more likely to be a librarian than a farmer.”) If LLMs are trained on human-generated text, it doesn’t seem reasonable to expect them to be smarter than the average text-generating human. (Though they sometimes are anyway.)

On the other hand, I was too dumb to recognize the subtlety on first glance. So maybe the model is “just as bad as a human?”

So, in the the absence of any priors or additional information, 1/3 is a reasonable-ish approximation. But I agree it would be far better if the model simply said “that’s hard to answer because there are many ambiguous factors” (as I have).

This one’s not so clear cut: “baby” is an ambiguous age range, and a baby can be a twin or triplet, born in any order. Even a newborn could have younger step siblings in rare cases.

We’re also presuming it’s a human baby, whereas other species have different life spans.

Not seeing it. What’s wrong with this answer? (There are six possible permutations, but the other two siblings are interchangeable…)

I adapted Unicodeit! (See the acknowledgment section on GitHub; also meant to mention that in the footer).

I had been using your website for years, but wanted something more integrated.

Thank you for contributing to open source. 😁

I got tired of mashing together tools to write long threads with 𝐫𝐢𝐜𝐡 𝑓𝑜𝑟𝑚𝑎𝑡𝑡𝑖𝑛𝑔 and ℳα†ℏ—so I wrote La𝑇𝑤𝑒𝑒𝑡!

It converts Markdown and LaTeX to Unicode that can be used in “tweets”, and automatically splits long threads. Try it out!

keenancrane.github.io/LaTweet/

(More seriously: if the geometry of the apples was well-captured by the artist, and the color is unique to that geometry, I would be willing to bet the answer is “yes.”)

If it began life as a drawing, is that question even well-posed?

Oh, you wrote a book on this stuff. I guess I didn't need to be quite so didactic in my response! ;-)

(But I take your point: it's hard to get all these different nuances across precisely in diagrams. That's why we also have mathematical notation to go along with the diagrams! :-) )

Well, f maps *any* point of the data space to the latent space, and g maps *any* point of the latent space to the data space. I.e.,

f : ℝⁿ → ℝᵏ,
g : ℝᵏ → ℝⁿ.

The point x is just one example. So it might in fact be misleading to imply that f gets applied only to x, or that ends only at x̂.

P.S. I should also mention that these diagrams were significantly improved via feedback from many folks from here and elsewhere.

Hopefully they account for some of the gripes—if not, I'm ready for the next batch! 😉

bsky.app/profile/keen...

Of course, there will be those who say that the representation diagram is “obvious,” and “that's what everyone has in their head anyway.”

If so… good for you! If not, I hope this alternative picture provides some useful insight as you hack in this space. 😉

[End 🧵]

If you want to use or repurpose these diagrams, the source files (as PDF) can be found at

cs.cmu.edu/~kmcrane/Aut...

(Licensed under CC0 1.0 Universal)

Likewise, here's a simpler “implementation” diagram, that still retains the most important idea of an *auto*-encoder, namely, that you're comparing the output against *itself*.

Personally, I find both of these diagrams a little bit crowded—here's a simpler “representation” diagram, with fewer annotations (that might anyway be better explained in accompanying text).

Finally, a natural question raised by this picture is: how do I sample/generate new latents z? For a “vanilla” autoencoder, there's no simple a priori description of the high-density regions.

This situation motivates *variational* autoencoders (which are a whole other story…).

It should also be clear that, unless the reconstruction loss is exactly zero, the learned manifold M only approximates (rather than interpolates) the given data. For instance, x does not sit on M, even though x̂ does.

(If M does interpolate all xᵢ, you're probably overfitting)

Another thing made clear by this picture is that, no matter what the true dimension of the data might be, the manifold M predicted by the decoder generically has the same dimension as the latent space: it's the image of R^k under g.

So, the latent dimension is itself a prior.

In regions where we don't have many samples, the decoder g isn't reliable: we're basically extrapolating (i.e., guessing) what the true data manifold looks like.

The diagram suggests this idea by “cutting off” the manifold—but in reality there’s no clear, hard cutoff.

Here's a way of visualizing the maps *defined by* an autoencoder.

The encoder f maps high-dimensional data x to low-dimensional latents z. The decoder tries to map z back to x. We *always* learn a k-dimensional submanifold M, which is reliable only where we have many samples z.

This picture is great if you want to simply close your eyes and implement something.

But suppose your implementation doesn't work—or you want to squeeze more performance out of your data.

Is there another picture that helps you think about what's going on?

(Obviously: yes!)

With autoencoders, the first (and last) picture we see often looks like this one: a network architecture diagram, where inputs get “compressed”, then decoded.

If we're lucky, someone bothers to draw arrows that illustrate the main point: we want the output to look like the input!

A similar thing happens when (many) people learn linear algebra:

They confuse the representation (matrices) with the objects represented by those matrices (linear maps… or is it a quadratic form?)

“Everyone knows” what an autoencoder is… but there's an important complementary picture missing from most introductory material.

In short: we emphasize how autoencoders are implemented—but not always what they represent (and some of the implications of that representation).🧵