My family has taken to watching the Big Bang Theory, and while I am extraordinarily tired of the laugh track, I continue to watch.

Naturally, any show targeted at nerds is bound to draw the ire of nerds, who are famed for their desire to find flaws in the opinions and statements of others, especially those who consider themselves nerdy. Indeed, an all-consuming desire for intellectual one-upsmanship (cf. Stephen Potter’s excellent books on the topic) may perhaps be regarded as the sine qua non of nerdhood. This desire can also manifest itself in the needless selection of lengthier words at the expense of more concise ones, the tendency to cite obscure sources, and the general tendency to blather at length.

But I digress.

I would like to take issue on this occasion with the recurring incidence of the game “Rock, Paper, Scissors, Lizard, Spock.” It has a fine wikipedia page, and I won’t describe it here.

My issue is that this RPS variant—and indeed, all of the ones I’ve seen published—can concisely be expressed as simple games of modulo arithmetic. That is:

• You pick a number from one to five.
• I pick a number from one to five.
• Take my number minus your number, modulo five.
• If the result is one or two, I win.
• If the result is three or four, you win.
• If the result is zero, we tie.

Naturally, you can generalize this to any odd number.

It seems to me that this is at the same time simpler, more general, and more nerdy than the game played by those on the show, and I would hope that they would consider changing to my variant, which I call John Brinckerhoff Clements.

Yes, there’s a note on this in the Wikipedia page. Yes, I added it.

One final note: an even nerdier version of this game may be played, still with the fingers of one hand, by throwing any combination of one through four fingers, and interpreting this as a binary number from 0 through 15. I humbly suggest interpreting an extended finger as the digit 1, a non-extended finger as the digit 0, the index finger as the most significant, the little finger as the least significant, and “wrapping around” to regard all fingers extended as a zero.

In fact, this game allows direct comparison of several popular hand gestures. Specifically:

• “rock” beats “American f*** you”:

>

• “peace” beats “rock”:

>

• “Spock” beats the two prior:

>

• and “Englishman Drinking Tea” beats “Spock”:

>

This hand is not a game entry. If you see this shape, your opponent is not playing the game:

illegal hand

So the next time someone gives you the finger, just point directly at them, and you win.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

  !================================================================================================================================
  !

  !>Initialises the interpolated point metrics for an interpolated point.
  SUBROUTINE FIELD_INTERPOLATED_POINT_METRICS_INITIALISE(INTERPOLATED_POINT,INTERPOLATED_POINT_METRICS,ERR,ERROR,*)

    !Argument variables
    TYPE(FIELD_INTERPOLATED_POINT_TYPE), POINTER :: INTERPOLATED_POINT !A pointer to the interpolated point to initliase the interpolated point metrics for
    TYPE(FIELD_INTERPOLATED_POINT_METRICS_TYPE), POINTER :: INTERPOLATED_POINT_METRICS !<On exit, a pointer to the interpolated point metrics that have been initialised
    INTEGER(INTG), INTENT(OUT) :: ERR !<The error code
    TYPE(VARYING_STRING), INTENT(OUT) :: ERROR !<The error string
    !Local Variables
    INTEGER(INTG) :: NUMBER_OF_XI_DIMENSIONS,NUMBER_OF_X_DIMENSIONS
    INTEGER(INTG) :: DUMMY_ERR
    TYPE(COORDINATE_SYSTEM_TYPE), POINTER :: COORDINATE_SYSTEM
    TYPE(VARYING_STRING) :: DUMMY_ERROR,LOCAL_ERROR

    CALL ENTERS("FIELD_INTERPOLATED_POINT_METRICS_INITIALISE",ERR,ERROR,*999)

    IF(ASSOCIATED(INTERPOLATED_POINT)) THEN
      IF(ASSOCIATED(INTERPOLATED_POINT_METRICS)) THEN
        CALL FLAG_ERROR("Interpolated point metrics is already associated.",ERR,ERROR,*998)
      ELSE
        NULLIFY(COORDINATE_SYSTEM)
        CALL FIELD_COORDINATE_SYSTEM_GET(INTERPOLATED_POINT%INTERPOLATION_PARAMETERS%FIELD,COORDINATE_SYSTEM,ERR,ERROR,*999)
        NUMBER_OF_X_DIMENSIONS=COORDINATE_SYSTEM%NUMBER_OF_DIMENSIONS
        NUMBER_OF_XI_DIMENSIONS=INTERPOLATED_POINT%INTERPOLATION_PARAMETERS%FIELD%DECOMPOSITION%MESH%NUMBER_OF_DIMENSIONS
        IF(NUMBER_OF_X_DIMENSIONS==SIZE(INTERPOLATED_POINT%VALUES,1)) THEN
          ALLOCATE(INTERPOLATED_POINT_METRICS,STAT=ERR)
          IF(ERR/=0) CALL FLAG_ERROR("Could not allocate interpolated point metrics.",ERR,ERROR,*999)
          ALLOCATE(INTERPOLATED_POINT_METRICS%GL(NUMBER_OF_XI_DIMENSIONS,NUMBER_OF_XI_DIMENSIONS),STAT=ERR)
          IF(ERR/=0) CALL FLAG_ERROR("Could not allocate interpolated point metrics convariant tensor.",ERR,ERROR,*999)
          ALLOCATE(INTERPOLATED_POINT_METRICS%GU(NUMBER_OF_XI_DIMENSIONS,NUMBER_OF_XI_DIMENSIONS),STAT=ERR)
          IF(ERR/=0) CALL FLAG_ERROR("Could not allocate interpolated point metrics contravariant tensor.",ERR,ERROR,*999)
          ALLOCATE(INTERPOLATED_POINT_METRICS%DX_DXI(NUMBER_OF_X_DIMENSIONS,NUMBER_OF_XI_DIMENSIONS),STAT=ERR)
          IF(ERR/=0) CALL FLAG_ERROR("Could not allocate interpolated point metrics dX_dXi.",ERR,ERROR,*999)
          ALLOCATE(INTERPOLATED_POINT_METRICS%DXI_DX(NUMBER_OF_XI_DIMENSIONS,NUMBER_OF_X_DIMENSIONS),STAT=ERR)
          IF(ERR/=0) CALL FLAG_ERROR("Could not allocate interpolated point metrics dXi_dX.",ERR,ERROR,*999)
          INTERPOLATED_POINT_METRICS%INTERPOLATED_POINT=>INTERPOLATED_POINT
          INTERPOLATED_POINT_METRICS%NUMBER_OF_X_DIMENSIONS=NUMBER_OF_X_DIMENSIONS
          INTERPOLATED_POINT_METRICS%NUMBER_OF_XI_DIMENSIONS=NUMBER_OF_XI_DIMENSIONS
          INTERPOLATED_POINT_METRICS%GL=0.0_DP
          INTERPOLATED_POINT_METRICS%GU=0.0_DP
          INTERPOLATED_POINT_METRICS%DX_DXI=0.0_DP
          INTERPOLATED_POINT_METRICS%DXI_DX=0.0_DP
          INTERPOLATED_POINT_METRICS%JACOBIAN=0.0_DP
          INTERPOLATED_POINT_METRICS%JACOBIAN_TYPE=0
        ELSE
          LOCAL_ERROR="The number of coordinate dimensions ("//TRIM(NUMBER_TO_VSTRING(NUMBER_OF_X_DIMENSIONS,"*",ERR,ERROR))// &
            & ") does not match the number of components of the interpolated point ("// &
            & TRIM(NUMBER_TO_VSTRING(SIZE(INTERPOLATED_POINT%VALUES,1),"*",ERR,ERROR))//")."
          CALL FLAG_ERROR(LOCAL_ERROR,ERR,ERROR,*998)
        ENDIF
      ENDIF
    ELSE
      CALL FLAG_ERROR("Interpolation point is not associated.",ERR,ERROR,*998)
    ENDIF

    CALL EXITS("FIELD_INTERPOLATED_POINT_METRICS_INITIALISE")
    RETURN
999 CALL FIELD_INTERPOLATED_POINT_METRICS_FINALISE(INTERPOLATED_POINT_METRICS,DUMMY_ERR,DUMMY_ERROR,*998)
998 CALL ERRORS("FIELD_INTERPOLATED_POINT_METRICS_INITIALISE",ERR,ERROR)
    CALL EXITS("FIELD_INTERPOLATED_POINT_METRICS_INITIALISE")
    RETURN 1
  END SUBROUTINE FIELD_INTERPOLATED_POINT_METRICS_INITIALISE

Ever taken a look at FORTRAN? Actually, I haven’t, either. FORTRAN is basically the oldest non-assembly language around, which is to say the oldest language where someone actually considered “what would programmers like to say?”, rather than “what should the machine be able to do?”

Also, this is FORTRAN 90, which is a much more recent update of FORTRAN. After a quick reading of the Wikipedia page, it looks like f90 (I’m just tired of writing in all caps) is the first update since 1977, which seems ancient but is in fact about halfway between the first invention of FORTRAN and the present day.

It removes many of the restrictions due to machine limitations (allowing free-form source code), and also allows recursive calls, something that the original FORTRAN didn’t—life is easy when you can statically allocate your stack frames!

It also has modules, and… gee whiz: dynamic allocation? Interesting: sounds like it would be much harder to compile f90 code into super-fast assembly than f77, but I suppose you’d have to ask an expert.

Hmmm… I wonder if there’s a formal semantics for more recent versions of Fortran 90? A quick google search suggests the answer is “no”. On the other hand, I’m not sure who would be interested in such a thing; you might be able to sell it as “this formal semantics could identify bugs in your optimization routines”. Anyone want to pay for this?

Okay, back to the source code. What’s going on here?

The first and most obvious thing here is that F90 clearly has a tradition of LONG_CAPITALIZED_VARIABLE_NAMES. COBOL had this going on too, and also an undergraduate classmate of mine named Celeste (RIP, no joke).

I personally find this fairly distracting; it means that a line of source code can’t contain more than two or three tokens, and means that computations have to be split over a whole bunch of lines. On the other hand, local variables apparently have to be declared at the top, so it’s hard to split a large computation into small ones by giving good names to intermediate values.

I think there’s a fairly large split in the world between people who believe that variables should be declared at the top of functions and those who believe that they should be able to appear anywhere; I think that the decls-only-at-top people are imperative people who are planning on doing all kinds of horrible mutation everywhere, and declaring things at the top is their way of preparing themselves for the horror below. The decls-anywhere people (can you tell which I am?), on the other hand, don’t mutate their bindings; these bindings are just a way of giving meaningful names to parts of computation, and there’s no need to hoist them all to the top.

So F90 has the pull toward decls-anywhere that stems from long identifier names, but it’s used by super-imperative people. How do they get any work done? Okay, now I’m just being snide. Sorry. I should point out here that Fortran is clearly one of the massive success stories of language design; it’s one of the first languages, and still in hugely widespread use, thanks in large part to the total 90-degree turn taken by the scientific computing community into C, which is simultaneously the fastest and least optimizable/maintainable language. See Fran Allen’s comments here! Sorry, off topic.

Other, more minor comments: the error-checking code following the dynamic allocation looks like it could easily be abstracted away, especially considering that the error messages aren’t parameterized over the context in any way that I can see.

Broadly speaking, I think I would make local declarations legal anywhere, and shorten up those variable names. Otherwise, looks nice!

Three different ways to sum string lengths:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

int numChars(char* word)
{
   int i, j, sum = 0;

   for(i = 0; word[i][j] != '\0'; i++)
   {
      for(j = 0; word[i][j] != '\0'; j++)
      {
         sum++;
      }
   }
   return sum;
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

int numChars(char * strings[], int len) {

  int sum = 0, i;

  for (i = 0; i < len; i++) {
    sum += strlen(strings[i]);
  }

  return sum;
}

1
2
3
4
5

int numChars(char * strings[], int len) {

  sumOf(lengths(strings));

}

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118

/**************************************************************
 * 
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 * 
 *   http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 * 
 *************************************************************/



package org.openoffice.xmerge.merger;

/**
 *  This is an interface used by the {@link
 *  org.openoffice.xmerge.merger.DiffAlgorithm
 *  DiffAlgorithm} and {@link
 *  org.openoffice.xmerge.merger.MergeAlgorithm
 *  MergeAlgorithm} to access a <code>Document</code>.
 *
 *  @author smak
 */
public interface Iterator {


    /**
     *  Move to next element in the sequence.
     *
     *  @return  The <code>Object</code> of the next element in the sequence.
     *           If there is no next element, then return null.
     */
    public Object next();


    /**
     *  Move to previous element in the sequence.
     *
     *  @return  The <code>Object</code> of the previous element in the sequence.
     *           If there is no previous element, then return null.
     */
    public Object previous();


    /**
     * Move to the beginning of the sequence.
     *
     * @return  The <code>Object</code> of the first element in the sequence.
     *          If it is empty, then return null.
     */
    public Object start();


    /**
     * Move to the end of the sequence.
     *
     * @return  The <code>Object</code> of the last element in the sequence.
     *          If it is empty, then return null.
     */
    public Object end();


    /**
     * Return the current element <code>Object</code> content.
     *
     * @return  The <code>Object</code> at current position.
     */
    public Object currentElement();


    /**
     * Return the total element count in the sequence.
     *
     * @return  The total element count.
     */
    public int elementCount();


    /**
     *  A method to allow the difference algorithm to test whether the
     *  <code>obj1</code> and <code>obj2</code> in the
     *  <code>Iterator</code> are considered equal.  As not every
     *  <code>Object</code> in the <code>Iterator</code> can implement its
     *  own equal method, with this equivalent method, we can allow
     *  flexibility for the <code>Iterator</code> to choose a custom way
     *  to compare two objects.  Two objects can even be compared based on
     *  the position in the <code>Iterator</code> rather than by 
     *  the content via this option.
     *
     *  @param  obj1  The first <code>Object</code>.
     *  @param  obj2  The second <code>Object</code>.
     *
     *  @return  true if equal, false otherwise.
     */
    public boolean equivalent(Object obj1, Object obj2);


    /**
     *  <p>A method to force the <code>Iterator</code> to transverse the tree
     *  again to refresh the content.</p>
     *
     *  <p>It is used mainly for <code>Iterator</code> objects which take a snap
     *  shot instead of dynamically transversing the tree.  The current
     *  position will be set to the beginning.</p>
     */
    public void refresh();
}

Here’s another one, randomly chosen from the source for Apache OpenOffice’s 800K lines of Java (I should point out that there are something like 10M lines of C++ in the project).

A few seconds makes it clear that this is … the iterator interface. Minus the horrible “remove” call, and plus a bunch of other ones, generally fairly inoffensive.

Honestly, I can’t say too many bad things about this file: it’s clear and useful; this is the kind of file you’d like to see when you go looking for information. I had hoped for something more… complex? But the random number generator does what it wants. Darn random number generator!

One point here is that I probably shouldn’t have excluded .h files from my random C file excerpt; in Java, interface files aren’t distinguished from “source” files in the same way they are in C.

Questions for the audience:

• What is this code?
• How does it work?
• Could it be cleaner?
• What parts of the code are easy to understand, and what parts are hard?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

/*
 * Copyright (C) 2008 Freescale Semiconductor, Inc.
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version
 * 2 of the License, or (at your option) any later version.
 */

#include <linux/device.h>	/* devres_*(), devm_ioremap_release() */
#include <linux/gfp.h>
#include <linux/io.h>		/* ioremap_prot() */
#include <linux/export.h>	/* EXPORT_SYMBOL() */

/**
 * devm_ioremap_prot - Managed ioremap_prot()
 * @dev: Generic device to remap IO address for
 * @offset: BUS offset to map
 * @size: Size of map
 * @flags: Page flags
 *
 * Managed ioremap_prot().  Map is automatically unmapped on driver
 * detach.
 */
void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset,
				 size_t size, unsigned long flags)
{
	void __iomem **ptr, *addr;

	ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
	if (!ptr)
		return NULL;

	addr = ioremap_prot(offset, size, flags);
	if (addr) {
		*ptr = addr;
		devres_add(dev, ptr);
	} else
		devres_free(ptr);

	return addr;
}
EXPORT_SYMBOL(devm_ioremap_prot);

In 2011, Charlotte Clews organized either the Maine Mountain challenge or the Granite Womon challenge or the Long Island challenge or whatever the heck we’re going to call it. It was a resounding success, as evidenced by this picture that Charlotte took:

Granite Woman Swimmers 2011

The swimmers, from left to right, possibly out of order?:

• Charlotte Clews
• Bahia Yackzan
• Louise Bourne
• Kim Parrot
• Mary Clews
• Moira McMahon

Charlotte writes:

What an awesome morning! All six women (Kim Parrot, Mary Clews, Bahia Yackzan, Louise Bourne, Moira Mahon and me) swam from Long Island to Sculpin Point in less than 2 hrs! We rock. And so do our support crew - it took a last minute fuel-line switcharoo, a last-minute boat put-in in South Blue Hill, and a last-minute kayak paddler to pull it off but we did, and the longer we waited the calmer the water got - and ultimately the current seemed just right. Let’s remember that timing for next year. (By the way, if you weren’t there this year, this email is your recruitment email for next year).

I continued the challenge with a bike ride to the base of Cadillac Mountain’s North Ridge Trail - it was 38 miles on my odometer and I stopped for a snack at John Edwards, so it took me 2.5 hrs and I only got side-swiped once - on the last mile of the Park Loop Road …. Otherwise it was a pretty nice bike ride. The (barefoot) hike up Cadillac felt super easy after the long swim and ride. It’s 2.2 miles and only took an hour with Jerome talking the whole way.

There are a whole bunch of pictures in Andy’s flickr set for this year.

As I write this, the 2010 Granite Mon is still in progress. This morning at 6:00 AM, a hardy crew of four swimmers and a nearly-as-hardy crew of chase-boaters gathered at the KYC dock, and on a spectacularly sunny and smooth day set out on one of the warmest swims on record. Andy—the only one without a wet suit—exited the water when he got too cold, but Charlotte, Justin, and John stuck really close together for a near-simultaneous arrival at the Becton’s dock.

Andy has a bunch of pictures in his flickr set of the swim. This is one of the whole crew, before the swim:

Pre-swim 2010

Participants:

• John Clements
• Charlotte Clews
• Justin Pollard
• Andy Wanning

Later, Andy wrote:

As for this year - successful! JP, Charlotte and I completed the 108.7 mile trek to Medway, Maine, arriving at 11:15pm. In a slight twist, we elected to do the last part along the route where Ben got lost all those years ago - a little longer, but flatter. Unfortunately, pretty bumpy, which was a quite literal pain in the ass in the dark, but still not bad. A big shout out to Charlotte’s mom Retta, who met us twice for food drop offs etc. during the ride, and Charlotte’s husband Jerome, who met us at the hotel with all our gear and supplied transportation from then on.

So this year was nigh-luxurious (though mitigated by the late bike arrival) in that one can now register online for a parking permit - so we just had to arrive in the parking lot by 7:30am to claim our space. So we got up at 5:30 rather than 3:45 or 4:00, and made our way to the Roaring Brook parking lot. Then we made a rather quick ascent & descent, since we had started later (8:00) and had to return by 5:00 so that Charlotte & Jerome could get back to their kids. We were definitely feeling the ol’ legs and knees (hell, I’m still feeling my thighs) after that bike ride, but all in all it wasn’t so bad and we conquered that darn mountain.

So…huge congrats to Charlotte for being the first Granite Maiden/Lady/Beef (Jamaican term) to do the whole thing. I almost did it too, but as you pointed out I had to bail halfway through the swim for cold / lack of a wetsuit. Oh well. And JP did the whole thing for the 3rd or 4th time (?)

Here’s a picture from his flickr set of the climb:

Climbers at top of Katahdin

John Clements swam early and short with Erin Taylor from Jim Point (on Long Island) across to High Head (on the South Blue Hill shore).

Wing took pictures. Here’s one of them:

Erin and John swimming

About his Granite Mon experience, Andy writes:

Hurricane Billy was threatening to hit shore on the morning of August 29, but nevertheless Justin and Andy roused themselves and met chaseboater Steve Neuhauser at the KYC in the early morn. Unfortunately, Billy started making his presence known quite stridently as they arrived, silencing even JP’s indomitable will to swim, so they gave up and went back to bed. The end.

Andy and Justin, victorious

I think this was the year of the gorgeous fogged-in tour of the harbor, wherein it was deemed far too dangerous to try to make it to Long Island, much less back again. The water was incredibly warm, though, so we settled for a swim out to the nun, then over to Lappahanink, then to one of the inner-harbor cans, then back to the KYC.

Participants:

• Mark Read
• Ben Walker
• John Clements
• Andy Wanning (Andy, can you confirm this?)
• Justin, were you there?

Andy Writes:

For ’08, yes I was there, but I was just a chaseboater, along with Lena (Kulikova) and Mark’s friend Will Etundi. There was no other biking/climbing that time, ’cuz it was Matt’s wedding day. JP might have done that stuff later on in the year though.

Ed. Note: Andy’s notes and my notes don’t exactly line up. It’s probably me that’s wrong.