Archive

Group by logarithmic count in SQL

The count() aggregate function in sql can be uses to get a histogram of the distribution of values in a table. Assume there is a table with customer data and you want to get a distribution of the distance to each customer:

select distance, count(distance)
from cust\_with\_dist
group by distance;

This will show the distance group be the exact values, which is not always desirable, f.e. when the dist column contains floating point data, this would yield the following result:

 distance | count
----------+-------
      0.0 |   142
      1.2 |   165
      5.5 |    24
      7.6 |    17
      8.3 |    11
      9.3 |    11
      9.4 |     6
...

Better would be to arrange the distance column in whole numbers:

select distance, count(distance)
from (select round(distance) as distance
           from cust\_with\_dist) as foo
 group by distance

This gives:

 distance | count
----------+-------
        0 |   142
        1 |   165
        6 |    24
        8 |    28
        9 |    17

Better for now, but if there is a large scale of values for the distance, e.g. 0 up to 1000km it dosn’t make sense to group the values from 100 to 200 into 1km intervals. A better grouping will be exponential or logarithmic grouping, e.g. into group up to 1, 10, 100, 1000km or 1, 5, 25, 125, 625km. This can be accomplished by transforming the dist column before grouping:

select dist, count(dist)
from (select round(pow(10,ceil(log(10,distance+0.0001))))
           as dist from cust\_with\_dist) as foo
group by dist

The distance is added 0.0001 to prevent log(0) exceptions, by using the ceil() function the data is grouped into intervals “up-to”, the floor() function would give “as least”. The result is

 dist | count
------+-------
    0 |   142
   10 |   235
  100 |   111
 1000 |     7

If you exchange “10″ by “5″ you’ll get distances intervals of 0, 5, 125, 625 and so on.

EJB 3.0 Annotations Cheat Sheet

Update: The Annotations Cheat Sheet got it’s own page here

I just made Version 1.0 of my EJB 3.0 Annotations Cheat Sheet - just download it from here as pdf or OpenOffice Document. I’d greatly appreciate any feedback about errors and possible improvements. The sheet is based on the EJB 3.0 early draft 2.

Preview of cheat sheet.

Update

Version 1.1 contains some formatting cleanup and fixes some typos. Thanks to Emmanuel Bernard for pointing out the typos. I checked the EJB 3.0 Peristence edr 2 but it reads that all collections except many-to-many are fetched EAGER by default. The links above were updated accordingly.

Second Update

Fixed broken links.

jga: Now, I see a use for 1.5 static method imports

For quite some time I’ve considered the static method import in java 1.5 rather useless and only usefull for lazy programmers who wanted to avoid typing “java.text.” in front of “NumberFormat”. The page
jga: using the java 1.5 forloop shows an application of jga’s generic functor objects. By making use of the static import feature the code is actually very easy to read and reminds me more of perl than of java:


for(PlantType f : unique(transform(fruitsByType, getType))) {
System.out.println(f);
}

The same code without static method import would lead to either artificially short method and class names or make the code unreadable:


for(PlantType f : Algorithms.unique(Algorithms.transform(fruitsByType, getType))) {
System.out.println(f);
}

Like every powerful feature, also static method import is tempting and likely to be over-used. Nevertheless it solves today’s problems.

Another example where static method import helps is JUnit. The Assert class wich provides a nice set of assert helper methods is extended by the TestCase class which all Test classes have to extend. This is annoying because JUnit dictates a implementation hierarchy just to have the possibility of calling assertEquals instead of Assert.assertEquals. The static import of all methods in Assert which are needed decouples the tests’ implementation hierarchy from the testing framework. TestNG, an alternative Java testing framework, is free from this coupling and relies on static method import. Please note that you can still extend the Assert class to your test case class if you dislike static method import or it’s not available.

Updated the 2nd example according the the comment received from “Complex Lex”.

Use static method to initialize classes before super class constructor is called.

Java does not allow to call any method before linking super() in a constructor for good reasons. Sometime this limitation hurst. Consider to the following case: In a subclass of a hypothetical class Message you want to mangle the message before using the super constructor. The following fails:


public class BrokenSpecialMessage extends Message {
public BrokenSpecialMessage(String name) {
Calendar cal = Calendar.getInstance();
cal.roll(Calendar.DAY_OF_YEAR, -1);
String newName = MessageFormat.format(
"Yesterday at {0,date}, the message {1} was created",
new Object[]{cal, name});
super(”At ” + newName);
}
}


/java/BrokenSpecialMessage.java
Error: line (11) Message(java.lang.String) in Message cannot be applied to ()
Error: line (17) call to super must be first statement in constructor

This is annoying because beside this simple case the “pre”-super logic cannot be collapsed into a easy statement. The solution is to use a static class method:


class SpecialMessage extends Message {
public SpecialMessage(String message) {
super("At " + formatMessage(message));
}

private static String formatMessage(String name) {
Calendar cal = Calendar.getInstance();
cal.roll(Calendar.DAY_OF_YEAR, -1);
String newName = MessageFormat.format(
“Yesterday at {0,date}, the message {1} was created”,
new Object[]{cal, name});
return newName;
}

}

Simple Log: The Simple Way To Log

I need to check this (simple-log) out. Simple log is 3 classes in a 18.2k .jar that might make happy:

The following example is stolen from the simple log website:

public class
HelloWorld
{
// Create a SimpleLogger:
private static final SimpleLogger log = new SimpleLogger(HelloWorld.class);

public static void
main(String[] argv)
{
try
{
// Use it!
log.entry(”main()”);
log.debug(”About to print ‘Hello World!’”);
String helloWorldString = “‘Hello World!’”;
log.dbo(DebugLevel.L6_VERBOSE, “helloWorldString”, helloWorldString);
log.db(DebugLevel.L7_LUDICROUS,
“I can’t believe this library has a level called ‘Ludicrous’!”);

System.out.println(helloWorldString);

log.debug(”Printed ‘Hello World!’”);
log.info(”Did you get that?”);
log.warn(”This example is very contrived.”);
}
catch (Throwable t)
{
// Just in case…
log.fatal(”Something really unexpected dropped by.”);
log.dbe(DebugLevel.L1_FATAL, t);
}
log.exit(”main()”);
}

What I like is the log.entry log.exit thing to log method entries and exits. A sample output look like

Fri 2004/11/26 21:10:32.618|>>>|main|HelloWorld|main()
Fri 2004/11/26 21:10:32.618| |main|HelloWorld|About to print ‘Hello World!’
Fri 2004/11/26 21:10:32.618|—|main|HelloWorld|helloWorldString|’Hello World!’
Fri 2004/11/26 21:10:32.618| |main|HelloWorld|I can’t believe this library has a level called ‘Ludicrous’!
‘Hello World!’
Fri 2004/11/26 21:10:32.618| |main|HelloWorld|Printed ‘Hello World!’
Fri 2004/11/26 21:10:32.618| |main|HelloWorld|Did you get that?
Fri 2004/11/26 21:10:32.618| |main|HelloWorld|This example is very contrived.
Fri 2004/11/26 21:10:32.618|< <<|main|HelloWorld|main()