The word is fairly common in spoken English: “Move it just a skosh to the left.” “You’re a skosh off on that.” It means “a little bit,” and comes from the Japanese word sukoshi (少し). It apparently comes to us as a result of World War II, along with origami, teriyaki, shiatsu, and karate.

What stands out to me about this word in particular is that, unlike other borrowings from Japanese, we have retained the pronunciation but changed the spelling. Japanese words have a mixed heritage of making it into English unscathed; origami and teriyaki are pronounced fairly closely to the original, while karaoke and harakiri are quite far off. In the last case, a colleague of mine who was teaching English as a Second Language had shown Harold and Maude to her class. She then asked them if they recognized the word “harry-carry”; none of her Japanese students did, even with the context provided in the film.

In Japanese, the high vowels (i and u) are devoiced between voiceless consonants (p, t, k, s, h), or generally between such a consonant and the end of a word. Since we don’t have voiceless vowels in English, we tend to hear nothing at all, so “suk-” will be heard as “sk-.” Hence, skosh from sukoshi, where in main Japanese dialects both the u and the i will be voiceless (but articulated).

The relative rarity of skosh in print, as opposed to in spoken language, possibly explains how it fairly uniquely retained its pronunciation and lost its spelling, as opposed to the other way around. As, for instance, karate classes and karaoke were advertised around the U.S., people attempting to read the signs would change the pronunciation of the final “e” (in Japanese, they rhyme with lay, not with lee). The absence of a consistently visible spelling of sukoshi perhaps protected it from a similar mutation.

I was discussing with my wife today the issue that “racist” has become an increasingly broad, and hence useless, word. Liberals tend to use it to mean any sort of hostility or negativity based on people of a different skin tone, even if the skin tone is secondary to the real issue.

Specifically, we were discussing accusations that the Tea Party has a racist element. Part of this accusation is due to the overrepresentation of whites in the group, but I also think a significant part is the “English First” emphasis coupled with a preoccupation with illegal (Mexican) immigrants, as well as a moral certitude equating Muslims with terrorism.

I’m not convinced, however, that it’s all about “white” vs “non-white.” There have been times in the past in this country, after all, that the same sort of us-v-them divisiveness has been aimed at other white Europeans, such as the Irish and the Poles. For many, if not most, of the people who have such preoccupations, the issue may well be the “otherness” of Mexicans and Muslims, without regard to their skin tone.

The term “xenophobic” is sometimes used in place of “racist,” and I think it’s closer to the mark. But the word “xenophobic” shares the same low-level hum of a distraction that “homophobic” does: It implies fear, and in so doing allows critics of the term to deny such fear. Fear, after all, is a subjective emotion. If I call someone xenophobic, he can deny it by claiming he doesn’t fear other people, he just doesn’t want them around him (as Ryan Murdough is doing in response to accusations of racism).

The relevant issue is, certain people don’t want to be around people who are different from them, and actively want to remove the “other” from their environment.

I entertained myself briefly by considering calling this mindset “homophilia.” That is, after all, what it is. I decided, though, that the people who are nervous about gays in their environment would obtusely misinterpret the word.

Instead, I settled on “xenorepulsive”: Wanting to get rid of the Other, whoever that may be. “English First” mentalities are generally xenorepulsive; excessive nattering and hand-wringing about illegal immigration is generally xenorepulsive; NIMBY concerns about mosques are xenorepulsive.

To the last point, as a sidebar, I find myself having more empathy for Sarah Palin’s position on the Ground Zero mosque than I thought I would be able to muster. She’s taken to complaining about Imam Rauf’s specific interest and involvement in the case, and her civil discussion of same lead to apparent accusations of “hate speech.” I disagree with Palin, and think that if she’s entitled to her Free Speech, so was Rauf when he suggested that US foreign policy contributed to breeding anti-American terrorism, but I think it’s an abuse of the notion of “hate speech” to characterize her words in that way. Suggesting that because specific individuals have expressed specific opinions, they have abrogated certain privileges (like building a mosque in a particular place) is not xenorepulsive, racist, or hate speech.

However, it is xenorepulsive to suggest that no Muslims “deserve” a mosque near Ground Zero because some Muslims did a terrible thing. And that’s an important distinction.

This got me wondering about the two words that she’d apparently mashed together, refute and repudiate, which have vaguely similar meanings. Also, it’s worth pointing out that “f” and “p” are sometimes related historically (for instance, pipe and fife are related; cf. German Pfeife), so it’s not completely random that someone would confuse (compute?) the two words.

Both of these words are interesting for a few reasons. First, they represent cranberry morphemes: Neither fute nor pudiate are words in their own right.

According to the Online Etymology Dictionary, fute only occurs elsewhere in English in confute; the Latin source is futare, “to beat.” Meanwhile, the similar-sounding words refuse and confuse come from a verb form of Latin fundere, “to pour”: Meaning that confuse and confound are closely related, while confute isn’t related to either. Isn’t Latin fun?

Pudiate comes from Latin pudium, which (per the Online Etymology Dictionary) may be related to the foot (Latin ped, Greed pod, cf. English podiatrist). It appears to be a total cranberry morpheme, in that it doesn’t appear in any other words (such as *compudiate).

These words also use the prefix re- meaning “away” or “back” rather the more expected “again.” The former meaning of re- is common enough, though. Here are some pairs, where re- means “away” or “back” and con- means “with”:

• Refute/confute
• Revoke/convoke
• Refuse/confuse
• Refund/confound
• Restrain/constrain
• Remit/commit

The last example demonstrates another interesting pattern shown in the Latin prefixes con- and in-: Assimilation with the following consonant. Specifically, English inherited the following rules from Latin.

• Before p, b, and m, use im- and com-: Im-portant, im-bibe, im-mortal, com-pose, com-bine, com-mute
• Before l, use il- and col-: Il-licit, col-lect
• Before r, use ir- and cor-: Ir-reverent, cor-rect
• Otherwise, use in- and con-: In-tensive, in-ane, con-flate, con-sanguine, in-con-gruous

Going back to the original confounded confusing conflation, refute derives from “beating back” while repudiate derives (perhaps) from “kicking back,” not wholly unrelated concepts, certainly conceptually closer than their modern English descendants.

Procrastinate comes from Latin. Pro- means toward or for. Cras means tomorrow, while crastinus is the possessive. -Ate is a standard plural imperative ending in Latin, and is common in English verbs of Latin origin (e.g., state, dictate, rotate, navigate). Hence, procrastinate means save it for tomorrow; the action (save it) is implied by its status as a verb.

The relevant pieces for hypothetical related verbs are straightforward. Consulting Cassell’s Latin Dictionary, we find:

• ante, previous
• nunc, now
• heri (or here), yesterday
• hesternus, of yesterday
• hodie, today
• hodiernus, of today

Most of these pieces are present as morphemes in modern English.

As a prefix, ante- refers to what comes before or first, as in antebellum (the period before a war, usually the US Civil War), antechamber (the room just outside a main room, used for greeting guests), and just plain ante (a bet made before playing cards are dealt out).

Nunc descends into now, as well as appearing in the archaic quidnunc, another word for a gossip that literally means “What now?”, i.e., “What’s new?”

Heri is vaguely related to the various modern words related to inheritance. Hesternus is related to yesterday and yesteryear.

Hodie is a contraction of hoc die. Die has since become day (and also lives on in diary and diurnal), while hoc is the ablative masculine singular of hic, this, as in the Latin phrases ad hoc (for the moment) and post hoc (after the fact). Thus, hodie means on this day.

Now that we have the pieces, the question becomes how to put them together.

The most obvious analog to procrastinate for doing it today would be prohodiernate. A commentator elsewhere expresses the concern that such a word would be awkward in the past tense. However, given that procrastinate has lost its explicit reference to tomorrow, I don’t see why prohodiernate would have its explicit reference to today.

On the other hand, a problem I perceive with prohodiernate is that its pro- suggests a putting off, just not on as large a scale as with procrastinate. Prohodiernation might mean, “I’ll do it today, but not necessarily right away.” This in itself is a useful concept: “It’s on my list of things to do, I’ll make sure it’s done, but it’s not my first priority.”

Dropping pro- gives us hodiernation, which is one of the aforementioned commentator’s suggestions, although in my view this still lacks an implication of immediacy.

Nuncate would be interpretable as to do now, although it’s unclear whether an Ancient Roman would concur.

The aforementioned commentator suggests the possible need for a clarifying prefix, either fac(i)- or effec(i)- (related to Latin verbs meaning to do and to accomplish, respectively). However, I concur with that individual that facinuncate and effecinuncate are nightmarish options. Since we’re building a word, we do have enough flexibility to toss out utterly unworkable options, regardless of the opinions of putative, long-dead Romans.

Of these options, the most attractive in my perspective is nuncate. It does have the minor weakness of being close in spelling to nunciate, but that’s tolerable.

Nuncate would mean do right away, but what of getting done something before it’s expected, anticipated, or even asked for, a la M*A*S*H’s Radar? We have two obvious options: Get it done before today, or get it done yesterday.

Getting it done before today would be to antehodiernate, that is, do it in the time period closely preceding today. To do it yesterday would be to hesternate. Strictly speaking, both of these have the same problem as ordering someone to “get it done yesterday!”–it’s a logical impossibility.

To be utterly logical, which is what some Romans loved trying to be, the form would need to be based on the perfect imperative, a verb tense that doesn’t exist (for obvious reasons). The perfect infinitive uses -iss-, along with other root changes.

Keeping in mind, then, that we are now moving admittedly farther off the reservation,  I nonetheless put forth hesternissate, that is, to have gotten done yesterday. While hesternissate may seem like a mouthful, at least it’s less atrocious than antehodiernissate (especially if, as a purist, you pronounce -dier- as two syllables).

To summarize, then, my suggestions are:

• Prohodiernate: To do something in the short term, but not immediately
• Nuncate: To do something immediately
• Hesternissate: To do something before it’s expected

Sample uses:

• Don’t worry, I’m prohodiernating my weekly timesheets, but I have a client issue I’m attending to right now.
• I have to nuncate my homework, so I don’t have it on my mind when I’m watching the show tonight.
• As soon as I sign up for classes, I buy the books and read the first chapter. I realize it’s hesternissation, but I enjoy having the head start.

For the autosolver, I spent the better part of a programming day working on a blind alley of an approach, placing the 4-ship, then the 3-ships, and so on. I’m not sure where the algorithm went awry, but it consistently failed to work as expected. Then it occurred to me to simply solve the puzzles in a brute force variation of what I use on the harder puzzles:

• Fill in the easy cells.
• For the first empty cell, create a test version where it’s a ship, and another where it’s water.
• Repeat these steps for each of the two test versions.
• Repeat until all test versions have been completed or ruled out.

I use a List of possible solutions, creating a second List by iterating through the first one, then copying the second List back to the first one and repeating.

Now that the autosolver works, I’m now thinking about adding a puzzle designer so the user can design, test, and save their own puzzles (although I think I’m going to first take some time off from this project to get some other things done).

Standard English doesn’t distinguish between singular and plural in the second person, nor does it distinguish between formal and informal, so it makes sense that we wouldn’t have those distinctions. That leaves the speaker-inclusive form.

I was taught that the speaker-inclusive form of the English imperative is “Let’s” plus the infinitive, but it seems to me that “Let’s” is (at least historically) a contraction of “let us”; that is, “Let’s go” is not technically a speaker-inclusive imperative in the same sense as “Gehen wir,” but is rather a standard second-person imperative.

I say “at least historically” because “let’s” feels at least partially fossilized as a grammatical token rather than a semantically meaningful element. In general, “us” is ambiguous between an audience-inclusive and an audience-exclusive interpretation; “us” merely means “me and at least one other person,” and context is needed to determine whether “you” is included.

However, “let’s” is not ambiguous in this manner; it includes the speaker and the audience (and possibly others). In contrast, “let us” is ambiguous, and weakly implies an audience-exclusive interpretation:

1. Let's go!
2. Let us go!

Of these, only (2) can be used in a hostage situation where captives are pleading for their release to a captor. Likewise, (2) is at least somewhat stilted in a situation where the speaker is trying to urge someone to leave with him.

In German, this distinction is made by using either the first-person imperative or the second-person passive imperative:

1'. Gehen wir!
2'. Lassen Sie (lass/lasst) uns gehen!

(although in the sense of being released from captivity, “Befreien Sie mich!” would be more appropriate).

One reason why this is interesting to me is that I feel strongly that the words and structures that we choose to use in a language has an effect on how we perceive. In English, when we were developing our imperative, we apparently felt that it was implicit in a communal imperative that the speaker would be involved, and therefore the first person imperative is a form of a request: “Will you allow us to do X?” German, meanwhile, makes no such implication; the imperative is a command to both the audience and the speaker.

An afterthought: I’m also intrigued that German imperative requires the use of the pronouns “Sie” (formal) and “wir” (first person plural) but not “du” (informal) or “ihr” (plural). I don’t know what the historical reason for this is, but it does occur to me that the Sie and wir forms are always the same, and hence dropping the pronouns would create potential ambiguities, while the du and ihr forms are usually if not always different.

• If a row has n remaining water cells and n remaining empty cells, all the remaining cells have to be water. Ditto for columns, ditto for ships.
• If a cell has a ship segment, then the neighboring four corners have to be water.
• Certain neighboring cells can be filled in based on clued ship segments.

These generally solve the easiest “Seaman” Battleships puzzles, and go a long way to solving the harder ones. The harder ones require an additional bit of programming through trial-and-error placement, which I’m still mulling around in my mind. The simplest bits, though, are rote enough that I added a command to the program to process it.

Since I was tooling around in the program, I decided to make a few other tweaks as well. One was adding an undo. It occurred to me that, because the data was of a different sort, undo and save weren’t interrelated in the same way as with Canfield. With Canfield, undo required recording the entire state of the card deck, including which piles everything was located on, so saving was a variation on that theme.

However, with Battleships, undo only requires recording the state of the grid; so long as I didn’t need to undo across loading a puzzle, the clues themselves don’t need recording. Save would require recording the state of the grid, the clues, and the source of the puzzle (so that if the saved file is later loaded and finished, that fact can be recorded). Since undo was simpler, I decided to allow for multiple undo steps.

First I created a list of arrays:

List<int[,]> alSnapshots = new List<int[,]>();

I had intended to simply assign a new list to the current grid status before making any changes to the grid:

alSnapshots.Add(iCellStatus);

One thing I was reminded of quickly was that equating arrays results in a reference assignment, not a value assignment. That is, the code above results in a list populated with pointers to iCellStatus, so when it changes, each member of the list changes as well. That obviously wasn’t what I desired, so I had to get a bit more explicit:

private void TakeSnapshot()
{
    int[,] iSnapShot = new int[GridSize, GridSize];
    for (int x = 0; x < GridSize; x++)
    {
        for (int y = 0; y < GridSize; y++)
        {
             iSnapShot[x, y] = iCellStatus[x, y];
        }
    }
    alSnapshots.Add(iSnapShot);
    if (alSnapshots.Count > 20) // Only save 20 steps
    {
        alSnapshots.RemoveAt(0);
    }
}

I arbitrarily chose 20 as the max number of undoes; each snapshot doesn’t take up that much memory.

This illustrates how to create and use a List consisting of arrays (in this case, a two-dimensional integer array). I have an additional method to clear the array, when a new puzzle is loaded:

private void ClearSnapshots()
{
    alSnapshots.Clear();
}

Allowing for redo would require a small modification to TakeSnapshot.

I also added a toolbar, using some free icons; the revised program is available on my website.

May

“May” as a modal is ambiguous between permission and possibility:

1. You may have some dessert if you finish your meal.
2. It may rain tomorrow.

It’s easy enough to conceptualize how this ambiguity started. Both senses are actually forms of permissibility: In (1), the speaker is granting permission; in (2), the universe is granting permission. However, pragmatically, the second sense has a feeling of conjecture, implying that the speaker believes that there’s a decent likelihood of the event happening (it would be strange, for instance, to hear [2] in Juneau in January, since the likelihood of rain instead of snow would be very low, even though the sentence would be semantically true).

More curiously, the scope of “not” is different based on the sense. In the case where permission is being granted, “not” has greater scope than “may” (unless the context is forced):

3. You may not have any pie because ....
-> NOT (ALLOWED (you have pie))...

while the probabilistic version of “may” has greater scope than “not”:

4. He may not call tonight.
-> COULD BE (NOT (he calls tonight))

In (3), what is negated is the permission to do something, as opposed to having permission to not do something, which is a possible but fairly forced use of “may”:

3a. Child: What if I don't want to eat my spinach?
Parent: Well, you may not eat your spinach, but if you don't,
you won't get any dessert.
-> ALLOWED (NOT (you eat your spinach))

In this case, the scope is the same as the probabilistic “may.” Note that the probabilistic “may” cannot combine with “not” such that the latter has scope, that is, there is no way to parse (4) in such a way that it is not possible that he could call.

Can

“Can” as a modal is ambiguous between ability and permissibility. In the latter sense, it’s roughly synonymous with the first sense of “may”:

5. I can lift half my own weight.
2a. You can have some dessert if you finish your meal.

In the case of “can,” the normal scope of negation is the same as with the first sense of “may,” that is:

5'. I can't lift half my own weight.
-> NOT (ABLE (I lift half my own weight.))
2a'. You can't have any dessert.
-> NOT (ALLOWED (You have dessert.))

However, a potential for confusion is in the use of “cannot” vs “can not.” “Cannot” is unambiguous with regards to scope, as is “can’t”; “can not” is ambiguous between this scope and the opposite one, which requires a context, as with “may,” but is more common in the forced context:

6. Child: Well, what can I do when all my friends are smoking?
Parent: You can not join them, simple as that.

In (6), the parent is not telling the child what they cannot do, but rather offering a suggestion of what they can do, specifically, they can fail to join their friends in smoking. Without the space (and the corresponding emphatic breath in the spoken version), the parent would indeed be denying permission:

6'. Child: Well, what can I do when all my friends are smoking?
Parent: You cannot join them, simple as that.

Must

“Must” is also ambiguous. Its two main senses, parallel to those of “may,” are those of obligation and likelihood:

7. You must finish your dinner.
8. He must see me, because he waved.

However, “not” does not behave as we would predict from “may.” In the case of obligation, the scope is the opposite:

7'. You must not finish your dinner.
-> REQUIRED (NOT (You finish your dinner.))

Effectively, that means “must not” and “may not” are synonymous, inasmuch “you are required not to…” means the same as “you are not allowed to….”

With the probabilistic sense of “must,” it’s not definitive what the scope is, because “it’s not likely that it’s the case that…” and “it’s likely that it’s not the case that…” mean generally the same thing, particularly to the sort of binary likelihoods normally referred to in this context (such as in [8]).

Have to

In the positive sense, “have to” and “must” are interchangeable:

7". You have to finish your dinner.
8'. He has to see me, because he waved.

Pragmatically, “have to” is generally more colloquial than “must,” and hence is more likely to appear in casual frames (as in “I have to go now” vs the stiffer-sounding “I must go now”).

More interestingly (and consternating, no doubt, for the second language learner), “must not” is not interchangeable with “don’t have to.” In the obligatory sense, each is unambiguous, and they have opposite scopes, and therefore different meanings:

7"'. You don't have to finish your dinner.
-> NOT (REQUIRED (You finish your dinner.))

That is, while 7′ forbids the audience (“you”) from finishing dinner, 7″‘ merely removes obligation from the audience to finish dinner.

Another interesting point is that, while “haven’t” is acceptable English, “not” cannot be inserted in “have to,” hence the use of “don’t.” Alternatively, “not” could be placed after “have to,” although this is awkward and usually works best in the context where someone is responding to a positive use of “have to”:

9. Child: What do I have to do to get you off my back?
Parent: You have to not watch TV when you're supposed
to be doing your homework.

This is a pragmatically tricky case, though, because while it semantically means about the same as “you must not watch TV…,” the focus is on the obligation to avoid doing something as opposed to an overt prohibition.

Meanwhile, the probabilistic sense of “have to” in the negative form is non-standard:

10. He must not see me, because he didn't wave.
10'. *He doesn't have to see me, because he didn't wave.

However, “have to” can be used if the scope is explicit, and with a minor change to tense:

10". He has to have not seen me, because he didn't wave.
-> LIKELIHOOD (NOT (he saw me)) ...

This is particularly interesting given the note under discussion of “must” that the scope between likelihood and negation is semantically trivial.

In this case, I had broken my large and increasingly complex ResetGrid method into several smaller ones. I have a boolean variable, blnAllDone, which indicates whether the current puzzle has been solved. I created the subroutines which count the remaining cells and the remaining ships to return a boolean value, which would be true if the remaining cells or ships is zero,  false otherwise. This was the original code:

bool blnAllDone = CalcRemainVals();
blnAllDone = blnAllDone && CalcRemainShips();

However, the CalcRemainShips method only ran if the puzzle was complete. As soon as I looked again at the code, I realized why: C# stops assessing x && y if x is false (since x && y can’t be true if x is false), and returns false. Likewise, c# stops assessing x || y if x is true, and returns true. This is a useful feature if you want to shortcut situations where a variable might not be set, for instance, but in this case it led to unexpected results.

I made a minor change, and all was well with the world again:

bool blnAllDone = CalcRemainVals();
blnAllDone = CalcRemainShips() && blnAllDone;