A few months ago I seem to have become a green tea advocat, since I have realized that it is probably the most healthy beverage ever invented (including water).

The enormous study “Green Tea Consumption and Mortality Due to Cardiovascular Disease, Cancer, and All Causes in Japan” took 11 years with over 40.000 participants, and got the following result:

Green Tea Benefits in Woman

• 23% lower risk of dying from any cause
• 31% lower risk of dying from CVD
• 62% lower risk of dying from stroke

Green Tea Benefits in Men

• 12% lower risk of dying from any cause
• 22% lower risk of dying from CVD
• 42% lower risk of dying from stroke

On my quest for the perfect cup of tea, I have looked for scientific analysis and have found the enlightening paper “Factors Affecting the Caffeine and Polyphenol Contents of Black and Green Tea Infusions“. Here are the most important findings of it:

How to get the most out of a tea bag. The more extracted solids / catechins, the better.

Brewing

• doubling the bags doubles the extracted solids (which is good!)
• Increasing brewing time from 1 minute to 2 minutes doubles the catechins. 5 minutes tripple the catechins.

Teabags vs. loose leafes

• Loose leafes are better than teabags.
• When teabags are left floating, the flow resistance of the material blocks almost everything! this is very bad.
• Continuously dunk a tea bag and the extraction is 4 times better!
• Loose leafes are still about 20% better than dunked teabags, and after about 2 minutes the water is saturated (no need to wait any further)

Leafe size / packing

• loose leafes? extraction is faster with smaller leafes. No need for dunking.
• teabag with small leafes / tightly packed? Continuously dunk it
• teabag with large leafes / loosely packed? Leafe it static (the flows are driven by convection)

CONCLUSION

• loose leafes are the best. Brew for 2 minutes and you have everything they got.
• If you have to use teabags, dunking the bag gets you 4 times the catechins!

Here is the challenge. Create some Java code so that this JUnit test works:

public class EachMethodTest {

    /**
     * Simple test object.
     */
    public static class Fu {
        @Callable
        public int fu() {
            return 1;
        }

        @Callable
        public int bar() {
            return 2;
        }
    }

    /**
     * Call all methods that have the @Callable annotation.
     * The MethodsToProc works for ANY type of object, not just Fu.
     */
    @Test
    public void eachMethodTest() {
        final Fu fu = new Fu();

        int sum = 0;
        for (final Proc<Integer> c : new MethodsToProc<Integer>(fu)) {
            sum += c.call();
        }

        Assert.assertEquals(3, sum);
    }
}

Basically what I want to do is be able to automatically create wrappers for some object, so that each method with the @Callable can be called with a single common wrapper interface call(). It should be possible to specify the return type via Generics, and the ctor of MethodsToProc should be able to take any type of object.

See if you can do a general solution without cheating! The simpler, the better. You can post code snippets e.g. at snipit or gist. Have fun!

Even though I have an LCD monitor, I always have the subpixel hinting switched off because it is just painfully ugly to my eyes. Even when hinting is switched to maximum, the fonts are quite blurry (if you don’t believe me, type xmag and take a screenshot of your font. You can see red and blue linese everywhere). My eyes hurt when I see this.

Thanks to Johan Kivinemi I have just found out how to bring back the excellent legacy subpixel hinting engine. This has a much more crisp hinting, and uses subpixels only where it really is an improvement:

Just open these files in your home directory, and copy the content into them:

~/.fonts.conf

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
  <match target="font">
    <edit name="antialias" mode="assign">
      <bool>true</bool>
    </edit>
    <edit name="hinting" mode="assign">
      <bool>true</bool>
    </edit>
    <edit name="hintstyle" mode="assign">
      <const>hintfull</const>
    </edit>
    <edit name="lcdfilter" mode="assign">
      <const>lcdlegacy</const>
    </edit>
    <edit name="rgba" mode="assign">
      <const>rgb</const>
    </edit>
  </match>
</fontconfig>

~/.Xresources

Xft.antialias:  true
Xft.hinting:    true
Xft.hintstyle:  hintfull
Xft.lcdfilter:  lcdlegacy
Xft.rgba:       rgb

This should work in Ubuntu 8.04, 8.10, and 9.04 too, and makes all fonts much more crisp. Of course, your mileage may vary.

UPDATE: Comparison Screenshots

As promised on reddit, I got back from an awesome snowboard trip so I am able to put up extensive comparison screenshots of the two subpixel hinting engines. Move your mouse over the following images to see the differences. Watch especially out for letters like “m” where the spacing between the lines is very small. You might have to wait a bit for the image to load.

I have used all of the most important fonts that I usually use, and just for fun I have added “Dijkstra”, which just looks cool.

Sans Fonts

Mouse to see the same fonts with the legacy hinter.

Mono Fonts

Mouse to see the same fonts with the legacy hinter.

Zoomed Comparison Screenhots

Here is an excerpt with 400% magnifications. Mouse over the pictures to see the legacy hinter.

Zoomed Sans

Zoomed Mono

Here is an inheritence graph of some of the more important Java collection classes of Java 1.5. Instantiateable classes are blue and rectangular, abstract classes are just rectangular, and interfaces are elliptic. Click on the image for a printable size:

Java 1.5 Collections Hierarchy

As a sidenote, have written this post almost a year ago and just found it in my drafts. I have completely forgotten about it! So here it is anyways. And now I remember why I did not post it: becauseit contains only a minor subset of the collections! Thanks Artur Biesiadowski for reminding me about that…

Yesterday I have played a bit with reinventing a fast approximation for sqrt() in Java. This might be handy with J2ME. Wikipedia has a nice article about Approximations that depend on IEEE representation. My version works, and on my Intel Dual Core with an average error of 1.57%, maximum error 4.02% it is 3.5 times faster than the original sqrt. In addition, it is very simple to improve the precision to 0.000161% average error and 0.000775% maximum error which is then 1.56 times faster than Math.sqrt().

Sourcecode

I use floating point tricks based on my pow() approximation. Basically I just took the pow() formula and for a^b I substitued b with 0.5, then simplified this as much as possible. As it turns out the result is very simple and short. This initial approximation can be easily made more precise with Newton’s method:

    public static double sqrt(final double a) {
        final long x = Double.doubleToLongBits(a) >> 32;
        double y = Double.longBitsToDouble((x + 1072632448) << 31);

        // repeat the following line for more precision
        //y = (y + a / y) * 0.5;
        return y;
    }

Here is a comparison of the performance and accurancy versus the number of repetitions:

With 2 repetitions, the trouble is not worth the effort, as the approximation is already slower than the original Math.sqrt() which is more precise.