Skip to main content

Measures of confusion with JSR-275

I love the idea behind JSR-275, a units of measurement API for Java (see here for a background article by Jean-Marie Dautelle, the lead author) but I wish there were more examples out there about how to use it properly.

I'm presently writing some code for a spatial simulation. I want the user to be able to specify constraints on spatial entities such as their maximum area, width, movement over time and so forth. Bringing JSR-275 to bear on this means that I can use a consistent set of units within the code while leaving the user free to express their input data in whatever units are convenient for them.

The theory is beautiful but my, alas, my code is ugly.

Take this snippet for example...
// get a constraint from the user
Constraint constraint = ...

// get the unit used internally for this constraint (e.g. "m")
Unit<?> stdUnit = ... 

// the value for the constraint (in the user's units)
double value = constraint.getValue();

// get the label for the user's units (e.g. "ft")
String unitName = constraint.getUnitLabel(); 

// match the label to a jsr-275 class
Unit<?> unit = Unit.valueOf(unitName);

if ( !unit.isCompatible(stdUnit) ) { 
 // e.g. mixing up length and area units
 // throw an exception
}

if (!unit.equals(stdUnit)) {
 /*
    * The user is exercising their freedom to use a different unit
    * to us (curse them) so we convert their value to one
    * expressed in our units.
    *
    * (This is where it gets ugly)
    */
   UnitConverter converter = null;  

   // is it an area constraint ?
   if (unit.isCompatible(Area.UNIT)) {
       converter = unit.asType(Area.class).getConverterTo( 
               stdUnit.asType(Area.class) );

   // is it a length constraint ?
   } else if (unit.isCompatible(Length.UNIT)) {
       converter = unit.asType(Length.class).getConverterTo( 
               stdUnit.asType(Length.class) );

   // bummer - it was something else I forgot to allow for
   } else {
       throw new RuntimeException("Constraint system doesn't allow for "
               + unit.toString());
   }

   value = converter.convert(value);


Now I'd like to avoid the if-else block that says Is it an area ? Is it a length ? and just say...
   converter = unit.getConverterTo(stdUnit);

...but the compiler isn't happy with this. It wants the Unit references to be fully parameterized.

If I was only working with length, for instance, things would be simple...
   Unit<Length> stdUnit = ... // our standard unit (e.g. m)
   Unit<Length> unit = ...  // the user's unit (e.g. cubits)
   UnitConverter converter = unit.getConverterTo( stdUnit );


That's concise and elegant. But since I want to allow constraints to be applied to different quantities (length and area at the moment; later possibly others) I seem stuck with the if-else alternative parameterizations above.

I'm sure I must be missing something here. So, dear reader, if you are a JSR 275 guru please enlighten me !
Labels:

Comments

Post a Comment

Popular posts from this blog

Circle packing with R

To visualize the results of a simulation model of woodland trees within R, I needed an algorithm that could arrange a large number of circles within a rectangle such that no two circles overlapped by more than a specified amount. A colleague had approached this problem earlier by sorting the circles in order of descending size, then randomly dropping each one into the rectangle repeatedly until it landed in a position with acceptable overlap. I suspected a faster and more robust algorithm could be constructed using some kind of "jiggling the circles" approach. Luckily for me, I discovered that Sean McCullough had written a really nice example of circles packing into a cluster using the Processing language. Sean's program is based on an iterative pair-repulsion algorithm in which overlapping circles move away from each other. Based on this, and modifying the algorithm a little, I came up with an R function to produce constrained random layouts of a given set of circles. ...
Post a Comment
Read more

Circle packing in R (again)

Back in 2010 I posted some R code for circle packing . Now, just five years later, I've ported the code to Rcpp and created a little package which you can find at GitHub . The main function is circleLayout which takes a set of overlapping circles and tries to find a non-overlapping arrangement for them. Here's an example: And here's the code: # Create some random circles, positioned within the central portion # of a bounding square, with smaller circles being more common than # larger ones. ncircles
5 comments
Read more

Homogeneity analysis of hierarchical classifications

I've spent more years than I care to remember analysing vegetation survey data (typically species abundances in plots) using a variety of software including my own algorithms coded in FORTRAN and C++. A recent query on the r-help list, about how to determine the number of groups to define in a hierarchical classification produced with the hclust function, prompted me to unearth one of these algorithms, homogeneity analysis 1 , which can help to visualize how different levels of grouping partition the variability in a distance matrix. This algorithm is extremely simple. The classification is progressively divided into groups, with all groups being defined at the same dendrogram height. At each level of grouping, the average of within-group pairwise distances is calculated. Homogeneity is then defined as: H = 1 - Dav within-group - Dav total where Dav total is the average pairwise distance in the dataset as a whole. For data were there exist well-defined clusters of values, a...
6 comments
Read more