Thank you, thank you, thank you. I got quite a few great suggestions for a name for the new HiRISE stereo pair application I mentioned previously. Here they are:

Through Twitter:

  • Pairendipity
  • Opportune Viable Extraneous Results Lending to Awesome Parallax: OVERLAP
  • Over Observed Possible Stereoscopic: OOPS
  • Super Mega Ultra Hyper Stereo Seeker
  • Cyclic Redundant Observations Search for Stereo-Effect-Yielding Extra Data: CROSSEYED
  • Twin Hunter
  • RENA
  • HiDyad
  • Coke Bottle Glasses
  • Coincidental Binary Groupings
  • Cypress Hill

Through comments:

  • HiRISE Serendipitous Accidental Pairs (HiSAP)
  • HiRISE Serendipitous Observations Accidentally Recorded (HiSOAR)
  • HiRISE Advanced Research in Explorative Stereo Software (HiARESS)
  • HiRISE Software of Topographical Explorative Research in Extraterrestrial Observations (HiSTEREO)
  • HiRISE Stereo PRojection Interface TEchnology/TElemetry (HiSPRITE)
  • High-resolution Analysis of Data Exploration in Stereo (HADES)
  • Serendipity
  • MarsUpilami
  • HiThere
  • HiRISE Stereo Pair Inspector (HiSPI)
  • Marvin

Of all of these, my favorite is Pairendipity, suggested by @avdflight through Twitter. It was also the very first suggestion I got, and I immediately fell in love with it. It captures the accidental stereo nature of the software quite marvelously.

I predict one or two team members will groan, but I think the whole rest of the team will be as delighted as I am. Thanks a bunch everyone, and thanks especially to @avdflight!


Help Me Name a New HiRISE Application

I need your help. I have a new HiRISE application, and it desperately needs a name. There’s no prize for this, although if the name is particularly ridiculous or groan-inducing, you’ll have the satisfaction of knowing you’re making me smile every time a team member has to use the app or talk about it.

The application hunts through our database of acquired observations and tracks down accidental stereo pairs. By “accidental stereo pair,” I mean a pair of observations that were not planned as a stereo pair but which happen to make a decent set.

The easiest example to imagine is the case where we’ve done a seasonal repeat monitoring series of a particular location, where we might have two, three, four, or more observations of the same site that were taken at different look angles. Odds are high there’s a good stereo pair in there.

Less easy is the case where we took a couple of observations that happen to overlap significantly. Maybe we were putting together a mosaic, for example. Maybe there’s a nice stereo pair in there, too.

So what kind of name do I want, you’re wondering. The application we use for planning stereo pairs in advance is called HiSEAS: the HiRISE Stereo Effect Analysis Software. I like this name. It’s got a nice, adventurous feel to it that brings to mind exploration and, well, pirates. But it’s also got a horrible homophonous pun in the name related to vision. That’s a good name, but it can’t be the name of this software.

Right now, this new application is called Find_Stereo_Pairs, which is very dull. I want something better, and I want you to help me with it. It does not have to start with “Hi,” nor does it have to be an action phrase (“find stereo pairs”).

You can try commenting below with names, but probably the best way to get me a name is to tweet it at me: @HiCommander. Like I said, there are no prizes beyond the knowledge that a HiRISE team member will probably have to say it at some point. The deadline is Friday morning, January 11, 2013, at 10 AM US Mountain Standard Time (UTC-7:00).

By the way, when I say, “I have a new HiRISE application,” I mean a student programmer, Ashley in this case, wrote a new HiRISE application for me. Nice!

JFreeChart’s (Ab)Normal Distribution Function

I’ve got a long-running project that’s very nearly completed, in which I’m converting some old IDL code to Java for the modeling of Martian photometry as observed by HiRISE. I use JFreeChart in this project (and all of my projects that require charts, in fact).

I happened to be digging into the source code for the NormalDistributionFunction2D class and I found this piece of madness:

public double getValue(double x) {

  return Math.exp(-1.0 * (x - this.mean) * (x - this.mean)

    / (2 * this.std * this.std)) / Math.sqrt(2 * Math.PI

    * this.std * this.std);


“std” is the function’s standard deviation, set at construction.

The madness is in the denominator of the function: the square root of…a constant times the standard deviation squared. Isn’t that just the standard deviation times the square root of a constant? And the square root of a constant is itself a constant.

So why isn’t the denominator just a constant times the standard deviation? Why have four multiplications in there followed by a call to the math library? This expression is evaluated every single time the NormalDistributionFunction2D’s getValue method is called!

Because the standard deviation could be negative! Wait, what? No, it can’t. Even if there was some sense to it, the only computation in this code involves squaring the standard deviation, effectively stripping it of its sign. The denominator really ought to be a pre-computed constant times the standard deviation.

Also, since the class doesn’t let standard deviation be changed after construction, the entire denominator can be pre-computed at construction, as can the denominator of the exponent used in the numerator. Neither component ever changes once the object has been constructed.


This is in version 1.0.10 of JFreeChart, by the way. Maybe it’s been fixed by now. I probably ought to be a good open source citizen and submit a fix myself if it’s not been fixed.