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

Fitting an ellipse to point data

Some time ago I wrote an R function to fit an ellipse to point data, using an algorithm developed by Radim Halíř and Jan Flusser 1 in Matlab, and posted it to the r-help list . The implementation was a bit hacky, returning odd results for some data. A couple of days ago, an email arrived from John Minter asking for a pointer to the original code. I replied with a link and mentioned that I'd be interested to know if John made any improvements to the code. About ten minutes later, John emailed again with a much improved version ! Not only is it more reliable, but also more efficient. So with many thanks to John, here is the improved code: fit.ellipse <- function (x, y = NULL) { # from: # http://r.789695.n4.nabble.com/Fitting-a-half-ellipse-curve-tp2719037p2720560.html # # Least squares fitting of an ellipse to point data # using the algorithm described in: # Radim Halir & Jan Flusser. 1998. # Numerically stable direct least squares fitting of ellipses
2 comments
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 <- 200 limits <- c(-50, 50) inset <- diff(limits) / 3 rmax <- 20 xyr <- data.frame( x = runif(ncircles, min(limits) + inset, max(limits) - inset), y = runif(ncircles, min(limits) + inset, max(limits) - inset), r = rbeta(ncircles, 1, 10) * rmax) # Next, we use the `circleLayout` function to try to find a non-overlapping # arrangement, allowing the circles to occupy any part of the bounding square. # The returned value is a list with elements for
5 comments
Read more

Graph-based circle packing

The previous two posts showed examples of a simple circle packing algorithm using the packcircles package (available from CRAN and GitHub ). The algorithm involved iterative pair-repulsion to jiggle the circles until (hopefully) a non-overlapping arrangement emerged. In this post we'll look an alternative approach. An algorithm to find an arrangement of circles satisfying a prior specification of circle sizes and tangencies was described by Collins and Stephenson in their 2003 paper in Computation Geometry Theory and Applications. A version of their algorithm was implemented in Python by David Eppstein as part of his PADS library (see CirclePack.py ). I've now ported David's version to R/Rcpp and included it in the packcircles package. In the figure below, the graph on the left represents the desired pattern of circle tangencies: e.g. circle 7 should touch all of, and only, circles 1, 2, 6 and 8. Circles 5, 7, 8 and 9 are internal , while the remaining circles are exter
Post a Comment
Read more