Do One Thing, and Do It Well

This is the title of the third chapter of This book:Better, Faster, Lighter Java.

This chapter makes only one point: great software maintains focus on one task. To focus software, sharpen your ability to collect requirements and control your customers. If you're not careful, scope creep can confuse the basic theme of your software. When you've got a more complext problem, break each fundamental theme into a layer, or subsystem. In general, common layers are always evolving for Java technologies. Many of the accepted practices are sound, but others are suspect. Better layers share a common purpose and an effective interface.

Once you've designed effectively layered software and built clean software with a distilled purpose, maintain your clarity of purpose. To keep software focused on a central theme, you'll need to frequently refactor to loosen the coupling around tightly coupled components. Loose coupling is desirable at a lower level. Also, pay attention to coupling at a higher level, so that each major subsystem is as isolated as possible. You'll improve reuse and isolate one subsystem from changes in others.

The Basic Knowledge on Random Forest

In machine learning, a random forest is a classifier that consists of many decision trees and outputs the class that is the mode of the classes output by individual trees. The algorithm for inducing a random forest was developed by Leo Breiman and Adele Cutler. The term came from random decision forests that was first proposed by Tin Kam Ho of Bell Labs in 1995. The method combines Breiman's "bagging" idea and Ho's "random subspace method" to construct a collection of decision trees with controlled variations.

Learning Algorithm
Each tree is constructed using the following algorithm:
1. Let the number of training cases be N, and the number of variables in the classifier be M. (假设有N个训练样本，M个变量)
2. We are told the number m of input variables to be used to determine the decision at a node of the tree; m should be much less than M. （给定m个输入变量，用来确定树上一个节点的决策，m应小于M）
3. Choose a training set for this tree by choosing N times with replacement from all N available training cases(i.e. take a bootstrap sample)。 Use the rest of the cases to estimate the error of the tree, by predicting their classes.（从N个训练样本中随机重复取样N次得到一组训练集，即bootstrap取样）。预测剩余样本的类别，并用以估计决策树的误差。
4. For each node of the tree, randomly choose m variable on which to base the decision at that node. Calculate the best split based on these m variable in the training set.（对每个节点都随机选取m个基于此节点决策的变量。根据着m个变量计算其最佳分割方式）
5. Each tree is fully grown and not pruned(as may be done in constructing a normal tree classifier). （每棵树都会完整生长，不会像其他许多正常树分类器构建完成后经常做的那样被剪枝）

Advantages
The advantages of random forest are:

• For many data sets, it produces a highly accurate classifier (分类准确度高)
  
• It handles a very large number of input variables (处理大量输入变量)
  
• It estimates the importance of variables in determine classification(在决策类别时，评估变量的重要性)
• It generates an internal unbiased estimate of the generalization error as the forest building progresses(在构建森林过程中产生对泛化误差的内部无偏差估计)
• It includes a good method for estimating missing data and maintains accuracy when a large proportion of the data are missing （具有一个比较好的方法可以估计缺失值，并且如果有一大部分数据缺失，它仍可以维持准确度）
  
• It provides an experimental way to detect variable interactions（提供一种试验方法侦测变量之间的相互作用）
• It can balance error in class population unbalanced data sets（对于非平衡数据集中的分类数据，可以平衡误差）
• It computes proximities between cases, useful for clustering, detecting outliers, and(by scaling) visualizing the data(计算各种用例之间的相似性，对于聚类、侦测离群值和数据可视化（扩大或缩小）都非常游泳)
• Using the above, it can be extended to unlabeled data, leading to unsupervised clustering, outlier detection and data views （它也可被拓展到无标记数据的应用，形成非监督聚类、侦测离群值和数据可视化的方法）
  
• Learning is fast.（学习过程很快）

Reference:
Wiki for Random Forest
中文
Random Forest from Berkeley
RandomForest on the main page of Breiman

Junit

Chances are good that you're already using JUnit. If so, you can skip ahead to the next section. If you're not using JUnit, you need to be. JUnit is an automated testing framework that lets you build simple tests. You can then execute each test as part of the build process, so you know immediately when something breaks. At first, most developers resist unit testing because it seems like lots of extra work for very little benefit. They dig in their heels. Automated unit testing is foundational:
JUnit testing lets you run every test, with every build.
JUnit testing gives you the courage to try new things.
JUnit lets you save and use debugging code that you're going to write anyway.
JUnit forces you to build better code.

The above is from this book: Better, Faster, Lighter Java
Reference: http://junit.org

When 'JUNK' DNA meets with the p53 network

Yesterday The Molecular Systems Biology of NATURE published a paper in its News and Views column: 'Junk' DNA meets the p53 network.
The original article is addressed here.

[What is Junk-DNA]
A major part of the genome of higher eukaryotes consists of non-coding sequences. In former times, these sequences were called 'junk-DNA' as no specific function could not be attributed to them. More recent research has shown that small non-coding RNAs are contained in these parts of the genome. These non-coding RNAs have a fundamental role in gene regulation.

[What is MicroRNA(miRNA)]
MicroRNAs(miRNAs) are a relatively recently indentified means for gene regulation. They are small, endogeous non-coding RNAs, between 19 and 25 nt in length. Unlike siRNA, miRNAs are of endogenous origin and alterations in their expression are associated with a number of diseases, including cancer.

Digest of 'Why extends is evil'

The original article is addressed in JavaWorld: Why extends is evil.
The extends keyword is evil, maybe not at the Charles Manson Level, but bad enough that it should be shunned whenever possible. The Gang of Four Design Patterns book discusses at length implementation inheritance (extends) with interface inheritance(implements).

Good designers write most of their code in terms of interfaces, not concrete base classes. This article describes why designers have such odd habits, and also introduces a few interface-based programming basics.

Interface versus classes

Losing flexibility
Why should you avoid implementation inheritance? The first problem is that explicit use of concrete class names locks you into specific implementations, making down-the-line changes unnecessarily difficult.

Many successful projects have proven that you can develop high-quality code more rapidly ( and cost effectively ) this way than with the traditional pipelined approach.

Rather than implement features you might need, you implement only the features you definitedly need, but in a way that accommodates change.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance.

Summing up fragile base classes
In general, it is best to avoid concrete base classes and extends relationships in favor of interfaces and implements relationships. My rule of thumb is that 80 percent of my code at minimum should be written entirely in terms of interfaces. I never use references to a HashMap, for example; I use references to the Map interface.(I use the word "interface" loosely here. An InputStream is effectively an interface when you look at how it's used, even though it's implemented as an abstract class in Java.)

The more abstraction you add, the greater the flexibility. In today's business environment, where requirements regularly change as the program develops, this flexibility is essential. Moreover, most of the Agile developement methodologies simply won't work unless the code is written in the abstract.

If you examine the Gang of Four patterns closely, you'll see that many of them provide ways to eliminate implementation inheritance, and that's a common characteristic of most patterns. The significant fact is the one we started with: patterns are discovered, not invented. Patterns emerge when you look at well-written, easily maintainable working code. It is telling that so much of this well-written, easily maintainable code avoids implementation inheritance at all cost.

The graph representation in JUNG

1. Network and graph data sets have often been described mathematically as matrices which are commonly implemented as 2D arrays. The represantation facilitates fast retrieval of the edges, which operations is called findEdge in JUNG.
However, this representation is generally not feasible for large-scale networks. First, it requires O(|V|2) space. Second, existing algorithms for network analysis, which involve matrix multiplication or matrix inversion, generally require O(|V|3) time on 2D arrays. Third, this representation is problematic for dynamic networks(those whose vertex set may grow larger or smaller) and for networks with parallel edges. Finally, large-scale networks are almost invariably very sparse, so almost all the the space in a 2D array representing such a network is wasted on representing absent links.
2. A common alternative representation for sparse graphs and networks is the adjacency list representation, in which each vertex maintains a list of incident edges (or adjacent vertices); this requires O(|V|+|E|) space. This representation does NOT permit an efficient implementation of findEdge.
3. Most of the current JUNG vertex implementations employ a variant of the adjacency list representation, which is termed as adjacency map representation: each vertex maintains a map from each adjacent vertex to the connecting edge(or connecting edge set, in the case of graphs that permit parallel edges). ( Separate maps are maintained, if appropriate, for incoming directed edges, outgoing directed edges, and undirected edges.) This uses slightly more memory than the adjacency list representation, but makes findEdge approximately as fast as the corresponding operation on the 2D array representation.

What's hypergraph

The definition of Hypergraph has puzzled me for a long time. Today I meet it in the Jung's tutorial, then I ask for the help of Google. Here is a slight digression: you can look up something's definition by entering "Define: xxx" in the search box of Google.

In mathematics, a hypergraph is a generalization of a graph, where edges can connect any number of vertices. Formally, a hypergraph H is a pair H=(X,E) where X is a set of elements, called nodes or vertices, and E is a set of non-empty subsets of X called hyperedges orlinks. Therefore, E is a subset of P(X)\{FI}, where P(X) is the power set of X. While graph edges are pairs of nodes, hyperedges are arbitrary sets of nodes and can therefore contain an arbitrary number of nodes.

A hypergraph is also called a set system or a family of sets drawn from the universal set X. Hypergraphs can be viewed as incidence structures and vice versa. In particular, there is a Levi graph corresponding to every hypergraph, and vice versa.

Unlike graphs, hypergraphs are difficult to draw on paper, so they tned to be studied using the nomenclature of set theory rather than the more pictorial descriptions(like 'trees', 'forests' and 'cycles') of graph theory. Special cases include the clutter, where no edge appears as a subset of another edge; and the abstract simplicial complex, which contains all subsets of every edge.

The collection of hypergraphs is a category with hypergraph homomorphisms as morphisms.

For the more details, please see the original page of wiki: Hypergraph



(The problem is that I am still puzzled by some conception, such as Levi graph, incidence graph and so on.)