... until the collector arrives ...

This "blog" is really just a scratchpad of mine. There is not much of general interest here. Most of the content is scribbled down "live" as I discover things I want to remember. I rarely go back to correct mistakes in older entries. You have been warned :)


SQL Server Schema Differences

The following SQL statement will generate a crude list of column differences between two SQL Server databases:


SET @oldDatabase = 'unittestnew_3_14_x'
SET @newDatabase = 'unittestnew_3_15_x'

SET @sql = '
  oldColumns AS (
      tab.name AS tableName
    , ROW_NUMBER() OVER (PARTITION BY tab.name ORDER BY col.column_id) AS columnSeq
    , col.name AS columnName
    , typ.name AS type
    , col.max_length AS length
    , col.scale AS scale
    FROM ' + @oldDatabase + '.sys.all_columns AS col
    INNER JOIN ' + @oldDatabase + '.sys.all_objects AS tab
      ON tab.object_id = col.object_id
      AND tab.type = ''U''
    INNER JOIN ' + @oldDatabase + '.sys.schemas AS sch
      ON sch.schema_id = tab.schema_id
      AND sch.name = ''dbo''
    INNER JOIN ' + @oldDatabase + '.sys.systypes AS typ
      ON typ.xusertype = col.system_type_id
, newColumns AS (
      tab.name AS tableName
    , ROW_NUMBER() OVER (PARTITION BY tab.name ORDER BY col.column_id) AS columnSeq
    , col.name AS columnName
    , typ.name AS type
    , col.max_length AS length
    , col.scale AS scale
    FROM ' + @newDatabase + '.sys.all_columns AS col
    INNER JOIN ' + @newDatabase + '.sys.all_objects AS tab
      ON tab.object_id = col.object_id
      AND tab.type = ''U''
    INNER JOIN ' + @newDatabase + '.sys.schemas AS sch
      ON sch.schema_id = tab.schema_id
      AND sch.name = ''dbo''
    INNER JOIN ' + @newDatabase + '.sys.systypes AS typ
      ON typ.xusertype = col.system_type_id
, matched AS (
      COALESCE(old.tableName, new.tableName) AS tableName
    , old.columnSeq AS oldColumnSeq
    , old.columnName AS oldColumnName
    , old.type AS oldType
    , old.length AS oldLength
    , old.scale AS oldScale
    , new.columnSeq AS newColumnSeq
    , new.columnName AS newColumnName
    , new.type AS newType
    , new.length AS newLength
    , new.scale AS newScale
    FROM oldColumns AS old
    FULL OUTER JOIN newColumns AS new
      ON new.tableName = old.tableName
      AND new.columnName = old.columnName
, oldColumnName
, oldType
, oldLength
, oldScale
    WHEN oldColumnName IS NULL THEN ''added''
    WHEN newColumnName IS NULL THEN ''deleted''
    ELSE ''changed''
  END AS diff
, newColumnName
, newType
, newLength
, newScale
FROM matched
WHERE oldColumnName IS NULL
OR newColumnName IS NULL
OR oldColumnName <> newColumnName
OR oldType <> newType
OR oldLength <> newLength
OR oldScale <> newScale
ORDER BY tableName
, COALESCE(oldColumnSeq, newColumnSeq)

EXEC sp_executesql @sql


Java vs. UTF-8 BOM

From time-to-time, one runs into Java software that has trouble handling a Unicode byte-order-mark (BOM) in a UTF8-encoded character stream. I've seen this, for example, in various XML processing pipelines. Most recently, I came across it in a character stream generated by a .NET component that was being consumed by a Java component. The problem is always the same -- the BOM is finding its way into the data stream instead of being silently consumed by the Java I/O infrastructure.

This is a known problem, listed as bug #4508058 on the Java bug parade. Oracle/Sun acknowledged the bug, and it was even briefly fixed in the "Mustang" (Java6) release. However, a follow-on bug report (#6378911) complained that the fix broke backwards compatibility with previous releases. So, the fix was ultimately withdrawn and the original bug was marked as "won't fix".

Bottom line: when writing Java components that consume UTF8-encoded character streams, be prepared to consume the BOM yourself. Also, be aware that the various Microsoft I/O frameworks aggressively write BOMs into UTF8 streams, even if the stream would be otherwise empty.

It seems to me that there is an opportunity here for Java to add an alternate method to construct UTF8-readers that handle BOMs properly.


curl vs. Windows vs. esi.manage measure export

A self-contained Windows command file can use curl to invoke the esi.manage measure export integration service through judicious use of newline and quote escaping:



SET server=

SET request=^
  -h ^
  -c none        -m PRODUCTION -b GROSS -v FORECAST -U Oil:boe -D NONE        --curtailment ^
  -c scheduled   -m PRODUCTION -b GROSS -v FORECAST -U Oil:boe -D SCHEDULED   --curtailment ^
  -c unscheduled -m PRODUCTION -b GROSS -v FORECAST -U Oil:boe -D UNSCHEDULED --curtailment ^
  -c all         -m PRODUCTION -b GROSS -v FORECAST -U Oil:boe -D ALL         --curtailment ^
 2010-01-01 ^
 18 M ^
 \"origin subset\"

curl ^
  --ntlm ^
  --user : ^
  -X POST ^
  -H "content-type:text/plain" ^
  --data-binary "%request%" ^

The use of the --data-binary option is important since -d or --data-ascii will reformat the data (e.g. strip newlines).


Serializing Run-Time Types with gson

gson is a JSON serialization libary for Java. It is optimized for round-trip serialization and deserialization between Java and JSON representations of objects. To support such round trips, the serializer operates upon the static types of an object tree. As a result, the dynamic (run-time) types of objects are generally ignored.

This can be inconvenient for simple, output-only serialization scenarios. Consider what happens if we try to serialize, say, a List<MyClass>. When gson serializes this list, the output will include each element's fields from the declared type (MyClass). Fields from each element's run-time type will not be serialized. If MyClass is an interface, then there are no declared fields to serialize. Such elements will always be serialized as an empty JSON object ({}).

One way to work around this is to implement a TypeAdapterFactory that handles all interface types:

final class MyAdapterFactory implements TypeAdapterFactory {

    public  TypeAdapter create(final Gson gson, TypeToken type) {
        Class rawType = type.getRawType();
        if (rawType.isInterface()) {
            return new TypeAdapter() {

                public void write(JsonWriter out, T value) {
                    Type valueType = null == value ? Object.class : value.getClass();
                    gson.toJson(value, valueType, out);

                public T read(JsonReader in) {
                    // we only care about serialization in this scenario
                    throw new IllegalStateException();
        return null;

This adapter factory will delegate serialization of an object of any interface class to a custom TypeAdapter that inspects the run-time type of the object.

The factory is installed using GsonBuilder:

GsonBuilder gsonBuilder = new GsonBuilder();
gsonBuilder.registerTypeAdapterFactory(new MyAdapterFactory());
// ...
Gson gson = gsonBuilder.create();


How Not to Use For in Mathematica

Someone was asking about this the other day...

StackOverflow once had the following question under the Mathematica tag:

How could I calculate the trace of a n*n matrix, with a for loop? I know that the trace is the sum of the terms on the diagonal, but I haven't got a clue how to do it...

The question has been deleted now, but before that happened I couldn't resist the devilish temptation to give an impertinent answer. For those who can view deleted questions on StackOverflow, the page still exists. For those who can't, my response is quoted below...

Let's start with a 5x5 matrix, m:

m = Partition[Range[25], 5];
m // MatrixForm

which looks like this:

 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

In Mathematica, there are many ways use For to compute the trace. Here is a simple way:

For[tr=0; i=0, i<10000, ++i, tr+=RandomInteger[10]; tr]; Tr[m]

More efficient ways include:

Unevaluated[For[tr=0; i=1, i <= Dimensions[m][[1]], ++i, tr += m[[i,i]]]; tr] /.
  _For :> (tr = Tr[m])


For[,True,,Return[Tr[m], For]]


For[,False,,] /. Null -> Tr[m]



Mathematica's Format Pseudofunction

In Mathematica, we can define customized output formats for expressions using the Format function. For example:

In[1]:= Format[_thing] := "a thing"

In[2]:= thing[1, 2, 3]
Out[2]= a thing

Even though thing[1, 2, 3] now displays as a thing, its true form remains unchanged:

In[3]:= thing[1, 2, 3] // FullForm
Out[3]//FullForm= thing[1,2,3]

One might think that the formatted form an expression can be recovered by applying the Format function. Interestingly, this is not the case:

In[4]:= Format[thing[1, 2, 3]] // FullForm
Out[4]//FullForm= Format[thing[1,2,3]]

Format is simply a wrapper that self-evaluates. A more elaborate technique is necessary to obtain an expression's formatted form:

In[5]:= Format[thing[1, 2, 3]] /. FormatValues[thing] // FullForm
Out[5]//FullForm= "a thing"

Notwithstanding the Format[_thing] := ... delayed assignment, we can see that Format has not actually acquired a new definition:

In[6]:= ??Format

Format[expr] prints as the formatted form of expr.
Assigning values to Format[expr] defines print forms for expressions.
Format[expr,form] gives a format for the specified form of output.  >>


It has no definitions at all, in fact. Apparently, assignments to Format are handled in a special manner, tucking the definition away under the FormatValues of a symbol.


Java Enums and Superclasses vs. Private Members

Consider the following Java Enum definition:

public enum JavaEnumBug {

    VALUE() {
        int value() {
            return _id;

    private int _id = 123;

    abstract int value();


The Java compiler will complain about the reference to _id in the implementation of value():

Cannot make a static reference to the non-static field _id

This error message is very strange. There is no static reference to the field. There are two ways to make this message go away. The first is to drop the private modifier from the field _id. The second is to change the reference in value() from _id to super._id.

Apparently, Sun/Oracle is aware of this problem as it is listed on the Bug Parade as bug #7119746. That bug is marked as Closed, Not a Defect. The argument starts by observing _id is not visible through the inheritence chain due to being private. This is readily confirmed by changing the reference to _id to this._id whereupon the error message becomes:

The field JavaEnumBug._id is not visible

The bug diagnosis then goes on to argue that even though the reference is visible through class containment, that reference is considered to be static "since [VALUE] is declared as static in [JavaEnumBug]". I find this claim to be unconvincing. VALUE is indeed static, but it is a static reference to an honest-to-goodness subclass of JavaEnumBug. The instance itself has a perfectly well-defined _id field in the superclass, and that field is visible under the rules of enclosing scopes.

So why does super._id work? The reason is that despite all the previous complaining about _id being private from subclasses, it turns out that Java has a back door for accessing private members in superclasses:

abstract class Base {
    private int _id = 123;

class Sub extends Base {
    int value() {
       return super._id;

According to section 6.6.1 of the Java Language Specification, super._id should not be visible in Base. But it is -- another bug. A bug that is convenient for the original problem, however.


Mathematica: Beware Orderless Patterns

Consider the following Mathematica pattern transformation:

In[1]:= 2 x /. a_ b_ :> {a, b}
Out[1]= {2, x}

No surprises there. But watch what happens if you change the pattern variable a to z:

In[2]:= 2 x /. z_ b_ :> {z, b}
Out[2]= {x, 2}

The result elements are reversed, just because a variable was renamed. What happened?

This behaviour is by design. It occurs because of two points. The first is that the patterns on the left-hand side of replacement rules are evaluated. In this case, z_ b_ will be evaluated. The second point is that * (Times) has the attribute Orderless. This means that the arguments to the function are sorted into canonical order prior to evaluation. We can see the effect of this canonical ordering on the replacement rule that uses z_:

In[3]:= z_ b_ :> {z, b}
Out[3]= b_ z_ :> {z, b}

The pattern is reversed. This explains the difference between the two replacements. Is there anything we can do to avoid this? Well, we could hide the Times operator from evaluation:

In[4]:= 2 x /. Verbatim[Times][z_, b_] :> {z, b}
Out[4]= {2, x}

This "works", but is fragile. In a toy example like this, we can control the points where the pattern gets evaluated. But in more realistic examples, it is easy to accidentally evaluate the relevant part of the pattern, resulting in the variable swap. So the bottom line is that one must be very careful when writing patterns involving orderless operators. Especially when the pattern is being used to transform the orderless operator into an operator that is sensitive to order. Note that this problem would not be observed if the target operator were orderless as well:

In[5]:= 2 x /. a_ b_ :> a + b
Out[5]= 2 + x
In[6]:= 2 x /. z_ b_ :> z + b
Out[6]= 2 + x


Semantic Versioning

Semantic Versioning looks like a sensible attempt to bring some order to the chaos of software versioning.

Windows RunAs: Access Denied

Under Windows, an attempt to run an application as another user may fail for obvious reasons, such as the target user lacks sufficient permissions for the operation in question. There is at least one less obvious reason why this operation will fail: the Secondary Logon service must be running. Less obvious to me, at least.


SWT Classpath in Eclipse Juno

I have an Eclipse "sandbox" project that I use to test little SWT snippets. While trying to run one such snippet after upgrading to Eclipse Juno (4.2.0), I got the following exception:

java.lang.ClassNotFoundException: org.eclipse.core.runtime.ISafeRunnable
The snippet worked prior to the upgrade. I checked my classpath and the org.eclipse.core.runtime JAR was in the list. It turns out that many of the classes in the package org.eclipse.core.runtime are now in the org.eclipse.equinox.common JAR.


BIRT Rotated Chart Text vs. Windows

Using BIRT 4.2.0 on Windows, rotated chart text is sometimes garbled. One way to reproduce the problem is to rotate the labels on a chart axis:

FontDefinition font = xAxis.getLabel().getCaption().getFont();
font.setName("MS Sans Serif");

The resulting axis labels might look something like this:

The problem does not always occur. It appears to be sensitive to the chosen font. MS Sans Serif seems to fail reliably. That is one of the few raster fonts left on Windows. Is that a clue as to the nature of the bug?.

In my case, the application was using JFaceResources.getBannerFont(). This font is determined by a property setting from one of the operating system-specific resource files in the org.eclipse.jface package. Windows 7 and Vista are configured to use Segoe UI (which works). Windows XP and 2000 use Tahoma, which also works. All server versions of Windows fall back to a generic Windows property file that uses MS Sans Serif. This means that the bug could manifest itself on all typical server installations (such as the Citrix server on which the bug bit me).

I wonder if this is a bug in BIRT, JFace, SWT or GDI? It is logged in the Eclipse bug database as bug 377825.


Non-deterministic Floating Point Arithmetic in Java

I came across a very puzzling example of non-deterministic floating point arithmetic in 64-bit Java (jdk1.6.0_26, Windows 7). Consider the following function:

boolean ok() {
    double x = 0.1;
    return 1.0 - x == 0.9;

Under normal circumstances, this function returns true. However, 64-bit Java sometimes returns false. In those circumstances, there is a small round-off error. The hexadecimal representation of 0.1 is:


and of 0.9 is:


Normally, evaluating 1.0 - 0.1 yields this nearest representable value of 0.9. Unfortunately, the 64-bit (but not 32-bit) JVM sometimes returns a slightly different value:


Note that the last hexadecimal digit differs by one bit, C instead of D. This floating-point value is further away from 0.9 than the former value. That is not the issue, though. The issue is that the 64-bit JVM seems to flip back and forth between these two values non-deterministically.

I observed this behaviour in the context of a large desktop application. I scattered calls to ok() throughout the codebase, printing out the value each time. What I saw was that the first few hundred calls returned true, indicating that the correct rounding behaviour was occurring. After that, the calls would start returning false. For the most part, it seemed that once the rounding errors started occurring, they would not revert back to the correct behaviour. What makes this puzzling is that I did discover circumstances where calls would once again start rounding properly. Except for this last point, I would have guessed that some kind of JIT problem was responsible for this bug. Now, I have no idea.

I spent hours trying to narrow down exactly where ok() started failing by printing out its result in strategic locations. Ultimately I failed: the transition from proper to improper rounding seemed to occur in framework code that I could not easily instrument (i.e. Eclipse infrastructure). I was unable to create a free-standing unit test that exhibited the behaviour. I may redouble my efforts to find such a test, but until then this one will have to be filed under Mysterious Behaviour.

Incidentally, applying the strictfp modifier to a class that performs this calculation has no effect.

A bit of Googling reveals at least one person who has encountered non-determinism in Java floating-point:

Nondeterministic Floating-Point Conversions in Java

The problem described there is somewhat different, but the root cause may be the same.


Java TreeMap Limitation (Bug?)

Consider a Java (1.6.0_21 or 1.7.0_03) TreeMap:

TreeMap<String, Double> map = new TreeMap<String, Double>();
map.put("m", 1.0);

We can extract the set of keys using navigableKeySet():

// --> [m]

We can also ask for all of the keys on or after "a"::

// --> [m]

Or we can ask for all of the keys between "e" and "q" (exclusive):

NavigableSet subset = map.navigableKeySet().subSet("e", false, "q", false);
// --> [m]

A limitation arises if we attempt to process this last subset further. Let's say that another component, unaware of how this subset was generated, attempts to find all keys after "d":

// java.lang.IllegalArgumentException: fromKey out of range

This last expression throws an exception. The documentation for NavigableSet#subset() states that:

The returned set will throw an IllegalArgumentException on an attempt to insert an element outside its range.

Apparently, it also throws that exception even if you simply attempt to reference a key outside of its range. I suppose that it is (barely) defensible behaviour on the grounds that client code that is aware of the lineage of the subset may then later attempt to insert elements into the resulting tail-set that were outside of the original subsetted range. However, I would argue that the exception should be thrown if such an attempt were actually made, rather than just because it potentially could be made. I claim that this is a bug.


Mathematica Alternatives is Fast

The MathematicaTip Twitter feed is full of gems, but one caught my eye concerning Alternatives. The post suggested using Alternatives as a way to find elements of one list that are members of another, e.g.:

Cases[$data, Alternatives @@ $interesting]

I decided to benchmark this against a naive MemberQ implementation. I was shocked by the results. Consider:

$data = RandomInteger[1000000, 1000000];
$interesting = DeleteDuplicates[RandomInteger[1000000, 1000]];
Length @$interesting // Print
Length@Cases[$data, Alternatives @@ $interesting] // Timing // Print

On my machine, running Mathematica 8.0.4, this runs in 0.218 seconds. For comparison, consider this:

Length@Cases[$data, n_ /; MemberQ[$interesting, n]] // Timing // Print

which runs in 58.064 seconds... 266 times slower. What surprises me is not the slowness of the MemberQ version, but rather the blistering speed of the Alternatives version. Clearly, Alternatives is being implemented by a hash lookup or something. This analysis is further supported by what happens if we increase the size of the "interesting" list from 1,000 to 10,000 elements. The Alternatives version runs in almost the same time (0.234 s) while the MemberQ predictably runs 10x slower (565.847 s). Even at 1,000,000 interesting values, Alternatives still runs fast (0.951s).

I suppose that all along my mental performance model of Alternatives has unfairly equated it to MemberQ. Also, I've only considered it for small numbers of alternatives. No more. Alternatives scales up very well.

Absolute Project Pathnames in the Eclipse Workspace Hierarchy

In a "normal" Eclipse (3.x) workspace, the project directories are stored in the root of the workspace directory. That is, they are siblings of the .metadata directory. In these circumstances, the Eclipse workspace will keep an (implicit) relative path reference to each project. Consequently, if you move the workspace to a different location in the file system, Eclipse can still find the projects using that relative path.

On the other hand, Eclipse can also reference projects that lie outside of the workspace directory. In such cases the project path references are explicit and absolute. Therefore, they remain invariant if the workspace directory is moved.

So far, so good. However, there is a troublesome intermediate case. If the project directories are stored in subfolders within the workspace directory, then Eclipse does not refer to them using relative pathnames. Unexpectedly, the paths are absolute. As a result, a relocated or copied workspace will still refer to the contained projects in their original locations.

Incidentally, Eclipse 3.6 stores each project location in a file located at .metadata/project name/.location. Creating a script to alter project location paths is unnecessarily complicated by the fact that the .location files are binary.


JScript vs. Function Expressions

In Javascript, a top-level function expression is not allowed. For example,

function(){return 3;}

will give a syntax error such as Unexpected token (. The work-around is to enclose the expression in parentheses:

(function(){return 3;})

At least, in most environments this is a work-around. In JScript, both expressions are quietly ignored. No error message is given, and no return value results. In JScript, a more elaborate work-around is required:

[function(){return 3;}][0]


0?0:function(){return 3;}

... anything that includes the function expression as part of a wider expression will do.

At this point, one might be wondering why anyone would care. What's the use of a top-level expression anyway? In my case, the context was one that used eval. The contents of a Javascript file were being loaded and evaluated where the contract was for the file to contain a single anonymous function expression.


Changing the SA password in SQL Server

If you attempt to change the SQL Server SA password through the SQL Server Management Studio, you may get this error message:

Cannot set a credential for principal 'sa'.

The workaround is to tick the checkbox labelled Map to Credential. There is no need to actually select a credential from the drop-down list.


More Leaks in Mathematica's Function Abstraction

I wrote earlier about problems with Mathematica's pure functions. The problems make the abstraction somewhat leaky. Here are some more problems with that abstraction:

Contrast the return values of the following expressions:

Function[expr, With[{x = 1}, expr]][x]
(* x *)

Function[Null, With[{x = 1}, #]][x]
(* 1 *)

With[{x = 1}, #]&[x]
(* 1 *)

Tracing reveals that Function is sometimes renaming variables:

Trace @ Function[expr,With[{x=1},expr]][x]
(* {Function[expr,With[{x=1},expr]][x], With[{x$=1},x], x} *)

Trace @ Function[Null,With[{x=1},#]][x]
(* {Function[Null,With[{x=1},#1]][x], With[{x=1},x], 1} *)

This renaming of variables within enclosed scoping constructs is somewhat erratic. It happens if the function arguments are named but not if the arguments are anonymous. The differences in behaviour can be exploited to good effect, to be sure, but they are certainly not intuitive. It is not clear to me which of these behaviours is "correct". But it is even more unclear why the behavioural difference is triggered by the naming of function arguments. This is another example of subtle Mathematica behaviour for beginners to trip over -- and experienced users too.

Function with named arguments will rename variables in inner With and Module constructs, but not Block constructs. The exception for Block makes sense given that it does not actually introduce any new variables, it just overrides the definitions of existing ones. However, Function with anonymous arguments does not rename variables in any of these constructs.

It is possible to "trick" Function so that it does not rename variables of enclosed scoping constructs. The trick is to disguise those constructs. For example:

Function[expr, With@@Hold[{x = 1}, expr]][x]
(* 1 *)

In this case, Function does not spot the inner With since it is not generated until a later evaluation.

Note that Function does not rename (non-pattern) symbols in replacement expressions, irrespective of whether the function arguments are named or not. For example, both of the following expressions return the same result:

Function[expr, expr /. x -> 1][x]
(* 1 *)

Function[Null, # /. x -> 1][x]
(* 1 *)

Maybe all of this behaviour can be divined from Variables in Pure Functions in the Mathematica help. But it didn't occur to me.

Singleton Tables in SQL Server

In SQL Server, you can create a "singleton" table (a table with one row) like this:

CREATE TABLE configurationData

The primary key is a computed column with a constant value. Consequently, any attempt to insert a second row into the table will be greeted with a constraint violation error.

Note that this method only ensures that there cannot be two or more rows in the table -- it does not prevent the table from being empty.


.NET Framework Version in Mathematica

Out of the box, NETLink in Mathematica 8.0 will use version 2.0 of the .NET Framework. To use a newer version, you must edit the .NET configuration files InstallableNET.exe.config and InstallableNET32.exe.config. These files can be found at the location returned by this Mathematica expression:

FileNameJoin[{$InstallationDirectory, "SystemFiles", "Links", "NETLink"}]

Add a new supportedRuntime element for the desired runtime version (4.0 in this example):

<?xml version="1.0" encoding="utf-8" ?>

    <!-- The supportedRuntime lines control which version of the .NET Framework will
         be used when .NET/Link is launched with InstallNET[].
         .NET/Link requires at least .NET 2.0. If you have .NET 3.0 installed,
         it will be used (note that the 3.0 version is really just the 2.0
         version with some extra assemblies).
      <supportedRuntime version="v4.0" />
      <supportedRuntime version="v2.0.50727" />

Note that supportedRuntime elements should be listed in order of preference.


Java vs. Y-Combinator

Tonight, on You Did What?...

The gang decides to do penance for inflicting their software upon the world. Someone suggests implementing the Y-combinator in Java. Hilarity ensues.

Rated PG for violence to a coarse language.

public final class YCombinator {

    private interface Function<IN, OUT> {
        OUT apply(IN x);

    private static final Function<Function<Function<Long, Long>, Function<Long, Long>>, Function<Long, Long>> Y = new Function<Function<Function<Long, Long>, Function<Long, Long>>, Function<Long, Long>>() {
        public Function<Long, Long> apply(final Function<Function<Long, Long>, Function<Long, Long>> f) {
            Function g = new Function<Function<Function, Function>, Function<Long, Long>>() {
                public Function<Long, Long> apply(final Function<Function, Function> h) {
                    return new Function<Long, Long>() {
                        public Long apply(Long n) {
                            return f.apply(h.apply(h)).apply(n);
            return (Function) g.apply(g);

    public static void main(String[] arguments) {
        Function<Function<Long, Long>, Function<Long, Long>> fac = new Function<Function<Long, Long>, Function<Long, Long>>() {
            public Function<Long, Long> apply(final Function<Long, Long> r) {
                return new Function<Long, Long>() {
                    public Long apply(Long n) {
                        return n < 2 ? 1 : n * r.apply(n - 1);


Is this an argument for late-binding? Not necessarily: Haskell seems to cope, and you don't have to subvert the type system (much):

newtype Hold a = Hold (Hold a -> (a -> a))

y f = fg (Hold fg)
  where fg hg@(Hold g) = f (g hg)

Y-Combinator in Mathematica

Adding to the growing collection of posts about the Y-combinator...

Inspired by a question on the Mathematica StackExchange site, I came up with this implementation of the Y-combinator in Mathematica:

Y[f_] := #[#]&[Function[n, f[#[#]][n]]&]

... along with a test case:

fac[r_] := If[# < 2, 1, # * r[# - 1]]&


What I really wanted to do was emulate the expression in that StackExchange question: (#[#] &)[#[#][#] &]. Note that it uses nothing but the special slot input form #, the postfix function operator &, the matchfix application operator [...] and parentheses. Expressing the Y-combinator in a form like this has eluded me so far.

Not all is lost, though. The Mathematica definition suggested some "simplifications" (obfuscations?) for the versions that I have used in other languages.


function Y(f) {
   return (function(g) { return g(g) })(
     function(h) { return function(n) { return f(h(h))(n) }} )


(define Y
   (lambda (f)
     ((lambda (g) (g g))
      (lambda (h) (lambda (n) ((f (h h)) n))) )))

Another Mathematica version, using the rarely seen \[Function] operator (entered as ESC f n ESC):

Y = f ↦ (g ↦ g[g])[h ↦ n ↦ f[h[h]][n]]

(*Y = f \[Function] (g \[Function] g[g])[h \[Function] n \[Function] f[h[h]][n]]*)


Mathematica: Sort vs. Infinity

In Mathematica, the expression:

Sort[{4, 3, 2, 1, -∞, ∞}]


{1, 2, 3, 4, -∞, ∞}

The behaviour is explainable, if unintuitive. Infinities are different types of mathematical objects than, say, integers. Sort is defined to sort objects into "canonical order". Apparently that order places infinities after integers. Despite this explanation, the behaviour is definitely a gotcha to watch out for.

The workaround is to specify Less as the ordering function for Sort (instead of the default, OrderedQ):

Sort[{4, 3, 2, 1, -∞, ∞}, Less]


Missing JIRA Administration Sections

We recently had problems with the server that hosted our JIRA installation. We needed to migrate the installation to a new server. After that migration, for some unknown reason most of the options that normally appear on the Administration page had disappeared.

I found a JIRA Knowledge Base article, Menus Missing from JIRA Administration Panel, that speaks of this phenomenon and how to fix it. The solution is to hit the following URL:


where myjirahost is the base of your JIRA installation.


Determine the ActiveDirectory Site Name

You can determine the ActiveDirectory site name using the following JScript:

WScript.Echo(new ActiveXObject("ADSystemInfo").SiteName);


Mathematica Module vs. Block vs. With

A common Mathematica-related question concerns the difference between Module, Block, and With. Here is a small example which illustrates those differences:

x = 1; y[] := x

{ Module[{x = 2}, {"Module", x, y[], Hold[x]}]
,  Block[{x = 2}, { "Block", x, y[], Hold[x]}]
,   With[{x = 2}, {  "With", x, y[], Hold[x]}]
} // TableForm

A close study of the results might help to build an intuition about the differences:

Module  2       1       Hold[x$561]
Block   2       2       Hold[x]
With    2       1       Hold[2]

In all three cases, the local value of x is the same: 2. So all three constructs are the same with respect to the purpose of creating local variables. However, they differ in other respects.


Module localizes the symbol x so that it is distinct from the global x. It does this by generating a new unique symbol and then using the new symbol in place of the original x. Thus, the Module expression is effectively the same as if we had typed:

x$561 = 2; {"Module", x$561, y[], Hold[x$561]}

The generated symbols are generally temporary and disappear when they are no longer needed, although there are circumstances in which they will stay around (both intentional and inadvertent).


Block does not localize the symbol x. Instead, it temporarily clears all definitions and attributes associated with the symbol, evaluates the body, and then restores the cleared definitions and attributes. Thus, the Block expression is effectively the same as:

ClearAll[x]; x = 2; {"Block", x, y[], Hold[x]}; x = 1

Since the global value of x has been changed, y[] will return the new "local" value. This behaviour can be surprising and unexpected, so one should be sure that this is the intent before using Block -- or be careful to only block symbols that are not used in any other definitions.


With does not localize the symbol x either. Instead, it replaces all occurrences of x within the body of the expression with the supplied value. The body is evaluated after this replacement has occurred. Thus, the With expression effectively is the same as:

{"With", 2, y[], Hold[2]}

Note that With is unique among the three constructs in that it will insert values into held expressions (Hold[x] in this case). This has utility when generating code.

Blog Archive