(Now) Any IDIOT can (plainly) see that this formula is (trivial, and) self-explanatory.
	<pretend to change slide>
	Okay now wait a minute.
	I’ve always wondered what it feels like to be a “theory guy” and get away with glib remarks like that one.
	Now let me be precise for once in my life…
	The formula above gives the cardinality of the set of generated redispatching methods (bar D bar) given a generic function with a set of specialized parameters S1 through SN, the cardinality of each of which is indicated by bar S sub j bar.
	I was encouraged to typeset this by our distinguished / illustrious program chair (Andrew Black), and frankly am quite delighted / thrilled with the result. However, the formulation at the bottom may strike some as more accessible though. It may seem to sum that the number of generated methods might, in general, be quite large. In practice, both the number of specialized, polymorphic parameters, and the number of alternatives (one might call them alleles) will be relatively modest. Note that you can minimize the number of generated methods by redispatching to them out of order, and bouncing off the parameters whose sets of specializers have the smallest cardinalities first.
	I’m often / frequently asked, where did that factor of two in the last term on the bottom come from. That is present because the final destination / presentation methods can be made easier to read if you introduce on more dispatch to a presentation method in which the parameters are listed in the original order, thereby perhaps not exposing the “pinball bumper” methods to the user at all. This final ricochet can be elided for efficiency too.
	I thought about this for a long time, and it does in fact unfailing describe the number of methods we generate. I’ve never seen this published anywhere else (though that doesn’t mean it hasn’t been published elsewhere.) I’ll gladly pay the some of ONE GUINEA (cash-money) to the man or woman who can demonstrate that this formula is not correct.