How do you name the possibilities?

dimar has asked for the wisdom of the Perl Monks concerning the following question:

The Scenario

If you have been to McDonald's, you know there are numerous different ways to make a Big Mac(TM) Sandwich (for example, you can make it with cheese or without cheese). Furthermore, you know you can enumerate the total number of possible different sandwiches by counting the number of mutually exclusive variants per ingredient. For example:

    $cheese_variants    = 2; ## qw(with without)
    $bun_variants       = 2; ## qw(plain with_seeds)
    $bun_toast_variants = 3; ## qw(non_toasted light dark )

    ### limited to these ingredients, there are 2 * 2 * 3 ways
    ### to make a Big Mac(TM) sandwich
[download]

The Problem

The manager of an expirimental McDonald's outpost on the moon wants to develop a cash register that has a *single button* for every possible Big Mac(TM) sandwich. The manager wants to give each possible sandwich it's own unique "name" so that the clerks need only push one button in order to specify any of the possible sandwiches.

The Constraints

The "names" of the sandwiches have to be unique.
The "names" of the sandwiches have to be as few characters as possible, so they can fit on the small cash register.
The "names" of the sandwiches have 'human friendly' so the clerks can get a clue of the sandwiches they represent, with as little 'rote memorization' as possible.

The Attempts So Far

CheeseWithBunPlainToastedDark (too verbose)
C:Yes;B:Plain;T:Dark; (no good, ingredient abbrev may collide with new ingredient names in the future, also, we cannot use chars that wont fit into a perl variable name)
uuid_2004_dead_beef29ac_000 (no good, the clerks dont know what a uuid is, and the name should have at least *some* minimal connection to the sandwich content)
id_002 (each digit represents an ingredient variant. It is compact, but what if there are more than 16 variants per an ingredient? We run out of digits.)

The Question

What is considered 'best practices' for deriving a naming convention such as this? Has anyone tried something similar? What is the linguistic theory or CS research topic that covers this?

The Disclaimer

Big Mac(TM) is a trademark of McDonald's Inc. and is used only to illustrate the problem in a socially well-known context. The author neither endorses the products of, nor is afilliated with, nor makes any representation whatsoever regarding the business practices or policies of McDonald's Inc.
The 'real' reason for this question has nothing to do with McDonald's, it is an attempt to get input on a generic inventory problem, from the perspective of the folks reading this post.
Ignore the obvious 'real-world' problem that you would need an impractically large number of individual "names" to represent every possible sandwich. We don't care. The real goal is to come up with a compact naming system, not to make a better cash register.
This is just out of curiousity in order to rule out possibilities that have not yet been considered.
This is not a request for help with a homework problem.

Comment on How do you name the possibilities? Download Code

Replies are listed 'Best First'.
Re: How do you name the possibilities? by japhy (Canon) on Jul 07, 2004 at 18:55 UTC
You simplify the issue by allowing defaults to pass through. If the default burger has no cheese on a seeded, untoasted bun, then it'd be "Brg". Then, for each modification, use a Geek Code-like agglutinating scheme: "Brg+Chz++Tst" would be a burger with cheese, on a darkly toasted bun. "Chk++Pkl" would be a chicken sandwich with extra pickles. As for "fitting into a valid Perl variable name", you've got that ALL wrong. Use a hash. Use a hash. Use a hash. _____________________________________________________ Jeff `japhy` Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and `perl` hacker `s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;`	[reply]
Re^2: How do you name the possibilities? by japhy (Canon) on Jul 07, 2004 at 19:05 UTC
What I tell you three times is true. _____________________________________________________ Jeff `japhy` Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and `perl` hacker How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart	[reply]
Re^2: How do you name the possibilities? by Anonymous Monk on Jul 07, 2004 at 19:41 UTC
Point well taken. I wrote that as a lazy way of saying 'use only alphanumeric chars plus underscore' without considering the underlying connotations it would carry regarding bad coding practice -- also to avoid having to explain the 'real' reason for the constraint. One more reason to say what u really mean ... Next time it will suffice to just say `m/[A-Za-z0-9_]/`	[reply] [d/l]
Re: How do you name the possibilities? by jZed (Prior) on Jul 07, 2004 at 18:44 UTC
Hmm, interesting. There's been a lot of work done on classification of abbreviations in the medical field. In terms of avoiding rote memorization, the thing that helps people memorize is structure. So for the Mac, one assumes that there is a certain order used in creating the sandwhich (bun,meat,cheese, toppings? I dunno, I'm a vegetarian :-)). If the specifications go in the same order as the construction of the sandwhich the user has an automatic leg up on memorization. This is where knowing the knowledge domain you are dealing with becomes relevant and generic BigMac examples fall down - what is there in your domain that is already structured and how can you make use of that structure in deciding on a nmaing scheme?	[reply]
Re^2: How do you name the possibilities? by Anonymous Monk on Jul 07, 2004 at 19:15 UTC
In terms of avoiding rote memorization, the thing that helps people memorize is structure. ... what is there in your domain that is already structured and how can you make use of that structure in deciding on a nmaing scheme? Excellent observation. Although the sandwich example was contrived in order to make the question more understandable, the original problem domain that motivated the question was musical compositions. The problem is, there are infinitely many ways to deconstruct any composition. Hence the sandwich example. Also, it seems like using a fake problem domain generates more enlightening responses, such as your medical abbreviation link. As you identified, there are trade-offs when choosing how to pose the question.	[reply]
Re^3: How do you name the possibilities? by jZed (Prior) on Jul 07, 2004 at 19:26 UTC
using a fake problem domain generates more enlightening responses For sure! Metaphoric thought is a basic strategy of all thought. I think you used the fake domain very well to pose an easily understandable question. I was exapnding on it, not criticizing it :-) Please keep us updated, this is quite interesting.	[reply]
Re: How do you name the possibilities? by wfsp (Abbot) on Jul 07, 2004 at 19:12 UTC
In a previous incarnation I spent 24 years as a quality engineer for an aero engine manufacturer. Inventory and names was a big deal. Their method was to have a general name for each component (shaft, gear, casing) and an alpha/numeric identifier. Letters at the begining indicate which engine and then 6 numbers. I was always astonished at design meetings hearing designers shout 6 digit numbers at each other. If it's what your working with all day every day it becomes second nature. If the inventory is/will be large, trying to get short descriptive names will difficult and possibly more difficult to remember. The number becomes a name and it quickly becomes associated with the object. Like hearing a persons name and thinking of the person. McDonald's have pictures of all their meals. You can point to it (look it up). The cafe I goto has the menu on the wall against numbers. You walk in and shout "number 15" without even looking at the wall! I'd be interested in hearing how you get on. If inventory is big though, cut straight to numbers! It will be quicker and easier in the long run. wfsp	[reply]
Re^2: How do you name the possibilities? by dimar (Curate) on Jul 07, 2004 at 19:48 UTC
The numbers strategy seems like the only realistic approach, underneath the surface, this really is just a question on how to generate a Base N numbering system in a new 'language' where that language is heavily influenced by the particulars of any given problem domain. I worked for an organization that used a similar strategy for issuing e-mail addresses to new employees. People would refer to each other by their e-mail 'codes' rather than names. It got very strange after a while how easily they were interchangeable.	[reply]
Re: How do you name the possibilities? by TrekNoid (Pilgrim) on Jul 07, 2004 at 18:49 UTC
The problem that I'm having is that the example you use has some implications that a more generic inventory system won't have. For this example, it's easy to reduce name size by assuming 'Plain, not Toasted, no Cheese' as the default, and then only identify the necessary additions: `Plain - Plain, non-toasted, no cheese Cheese - Plain, non-toasted, cheese Lt - Plain, Lightly-toasted, no cheese CheeseLt - Plain, Lightly-toasted, cheese Dk - Plain, Darkly-toasted, no cheese CheeseDk - Plain, Darkly-toasted, cheese Seeds - Seeds, non-toasted, no cheese SeedsCheese - Seeds, non-toasted, cheese SeedsLt - Seeds, Lightly-toasted, no cheese SeedsCheeseLt - Seeds, Lightly-toasted, cheese SeedsDk - Seeds, Darkly-toasted, no cheese SeedsCheeseDk - Seeds, Darkly-toasted, cheese` [download] You could probably even subsitute 'Ch' for 'Cheese', and make it even smaller... In a larger, more generic system, this probably won't work, because there's not a 'default' build that is standard to the whole. Trek	[reply] [d/l]
Re: How do you name the possibilities? by stvn (Monsignor) on Jul 07, 2004 at 18:24 UTC
The "names" of the sandwiches have to be as few characters as possible, so they can fit on the small cash register. The "names" of the sandwiches have 'human friendly' so the clerks can get a clue of the sandwiches they represent, with as little 'rote memorization' as possible. These seem (to me) to be conflicting requirements? Would it not be better to use some kind of compact format for the sandwich "configuration", which could then be "expanded" into the full human readable/digestable name of the sandwich? I assume it needs to be small because it needs to fit in a database ("small cash register") and it is obvious why you want to make it human readable. But it is not obvious to me why they both have to be the same thing. Could you possibly expand upon your reasoning for this? It might help to understand why you made this design decision. -stvn	[reply]
Re^2: How do you name the possibilities? by superfrink (Curate) on Jul 08, 2004 at 01:50 UTC
During school I worked at a place that dealt with clothing and I don't know how many inventory counts I did. Anyway there were coats labeled like GBF93-2332 for example. `GB` - George Bond (suppliers name) `[WPMF]` - Winter, sPring, suMmer, Fall `[0-9]{2}` - low 2 digits of the year, eg 93 was 1993 `[23]` - 2 = mens, 3 = womens `[0-9]{3}` - style code. The point is I had a fair bit of trouble because the codes were so simillar and I didn't know what they ment until I asked where they came up with the codes. After that the codes made a lot more sense and explained why the GBF92-2332 looked just like the GBF93-2332 to me. In particular after that those were the only codes that made sense. Most vendor's codes were just numbers which is fine for the computer but not so easy for people. Then again after a while I knew 12 or 13 digit SKUs off by heart. (SKU = Stock Keeping Unit if you're ever wondering. They look like a UPC, barcode and all. Yes I've had customers ask.)	[reply] [d/l] [select]
Re^2: How do you name the possibilities? by Anonymous Monk on Jul 07, 2004 at 18:46 UTC
You already guessed the intuition for 'human readability', the brevity constraint is simply to handle situations that seem to come up a lot ... (for example, the "configuration name" has to appear on a cell phone screen, or on the readout of a portable mp3 player) some kind of compact format for the sandwich "configuration", which could then be "expanded" That's a nice paraphrase of what this question is really all about. What would the 'compact' format look like? Perhaps the constraints are mutually incompatible, but perhaps they're not. Hence the question.	[reply]
Re^3: How do you name the possibilities? by stvn (Monsignor) on Jul 07, 2004 at 19:07 UTC
To start with, I think jZed has some good suggestions, structure is helpful. And Roy is right too, you are only limited to the character set you choose. He gives an example of 0-9a-z, but there are even more characters than that in the ASCII set (not counting the unprintable ones of course). the brevity constraint is simply to handle situations that seem to come up a lot ... (for example, the "configuration name" has to appear on a cell phone screen, or on the readout of a portable mp3 player) Hmmm, this is an issue. At that point I would consider different outputs for different devices. We did some experimentation in the early days of WAP at the Ad agency I worked for. We did an example site-let with one HTML (browser on a PC) interface, and one WAP (for those early Nokia's) interface. The copy-writers wanted to put a lot of information on the screens, and we (and the usability guy) had to explain to them that it just wouldn't work for both, and would make the WAP version virtually unusable. We eventaully convinced them to re-write the copy for the WAP version and forgo some of the more flowery wording. Not everything can be like Java (write once, run everywhere) (yes, that is heavy in sarcasm :) What would the 'compact' format look like? Well, i assume your items need to be unique. In that case I would put some kind of unique ID, maybe some MD5 digest based off of some "random" input. This gives you your uniqueness. After that, its kind of like a bit-string, but you use Roy's idea of 0-9a-z as your "bit"s. Perhaps the constraints are mutually incompatible, but perhaps they're not. That's business logic, you should not put that in your data. -stvn	[reply]
Re: How do you name the possibilities? by Roy Johnson (Monsignor) on Jul 07, 2004 at 18:43 UTC
what if there are more than 16 variants per an ingredient? We run out of digits. No you don't. You aren't limited to base-16. You can use 0-9a-z as your "digits". You can also know when a particular component requires more than one digit space, and use as many as you need. UpdateIf you need your system to be expandable, you can use _ as a field separator, so your keys for a three-component inventory might look like: `id_0_1c_z id_0_0_0` [download] We're not really tightening our belts, it just feels that way because we're getting fatter.	[reply] [d/l]
Re: How do you name the possibilities? by TilRMan (Friar) on Jul 08, 2004 at 03:31 UTC
Pizza delivery places do something like this (never worked at one, but I've received more pies than is good for me): Start with a plain cheese pizza, "". Then you start adding toppings: "P" for pepperoni, "A" for anchovies, "N" for pineapple because "P" was taken. If you have more than 26 ingredients you start adding lowercase letters: "Bp" for banana peppers, "Bq" for barbeque sauce, "Bl" for bay leaves. (You can probably take away the cheese with "Z" or perhaps "Nc".) Chemists do this too in the periodic table. You will probably need to define the order in which elements can appear. For example, a classic "hawaiian" pizza would be "HN" (ham and pineapple) and never "NH". You might want to sort by either alphabet or by popularity. Then you need to arrange the keys on the register so that it "respects" that ordering. If you pick very good names up front, you can use simple abbreviations. For instance, "C" for cheese, "W" for white (non-toasted). This is very hard to do, as you pointed out, especially when the options change over time. Paradoxically, you can get away with less intuitive names if the system is more heavily used. Memorization is your friend in this case. As already suggested, take the most common cases as defaults. When you have binary "present-or-not" decisions (like cheese), a "C" means cheese and an absence of "C" means no cheese. But when you must select one (or more) from a list, only put a default if one selection is far more frequent than its alternatives. Here's how I might do it. I make the assumption that most customers like their buns lightly toasted (or that the restaurant will serve them that way unless instructed otherwise). I also assume that plain buns and seeded buns are both popular. `Cheese: "C": with "": without Bun: "P": plain "S": seeds Toast: "W": white "": light "D": dark` [download] I'd list them in that order too, since they seem to make sense that way. So my lightly-toasted seeded Big Mac with cheese is "CS".	[reply] [d/l]
Re: How do you name the possibilities? by EvdB (Deacon) on Jul 08, 2004 at 08:45 UTC
You might have some luck with defining a standard product and then only specifying the deviations from it. For example you could order a BigMac ( BigMac ), or a BigMac with no cheese ( BigMac-Nc ). Hopefully this would lead to the common orders being simple ( BigMac ) whilst the complicated orders get longer ( BigMac-NcEgPbNt: BigMac, no cheese, extra gerkins, plain bun, not toasted ). As the odd orders are rare it does not matter that they are longer. Feel free to adapt to your problem domain. --`tidiness is the memory loss of environmental mnemonics`	[reply] [d/l]


Think about Loose Coupling
	PerlMonks