Recenberg 1/5th success rule applied to life..

For those who are not familiar, Rechenberg's 1/5 rule refers to adaptive mutation in evolutionary strategies (ES). It says that the ratio of successful mutations to all mutation should be 1/5. Deriving from this idea, if you get too successful (i.e., more than 1 out of 5 tries) then you're converging too fast to a local optima (aka safe options) and will result in stagnation later on. So, don't run after too many successes. Ideally, at-least according to Rechenberg, one should try 1 safe thing for every 4 risky things in life to optimally balance stagnation vs. growth.

Flaw with patent law?

Math functions cannot be patented. Imagine sin, cos being patented, that'd be crazy right. Ironically computer programs can be patented. It has long been proved that computer programs are equivalent to mathematical functions. Does anyone realize its the same as patenting math functions?

Kleiber's Law

Last week, I happened to read about Kleiber's law while browsing through literature on natural evolution. Its implications are really fascinating. It establishes a relationship between mass and metabolism as:

Metabolism is ultimately linked to the number of heartbeats (heart pumps oxygenated blood, which is responsible for metabolism). Therefore, #heartbeats is proportional to the mass. Also, smaller creatures have high metabolism (heat generated per unit volume) and therefore have faster heart rate.

Curiously, the number of heartbeats per lifetime tends to be constant. Thus, bigger animals live longer as their heart beats slower. Flies on the other hand have shorter lifespan because of high metabolism (smaller mass).

Come to think of it, if we have fixed number of heartbeats, wouldn't running/exercising make us die faster? We are spending more heartbeats per second and it makes perfect sense. Then why is it that people who exercise live longer? The answer is simple...I'll let you think about it.

The paradox...

Newton made calculus to simplify mathematics...a true paradox!

Adding class attributes at runtime :O

The use is kind of hard to describe. In some situations, it makes more sense to add attributes to an instance at runtime. One example would be to perform optimizations at runtime (Maybe I'll describe a solid example at a latter time).

The trick is to use a HashMap to store property name and value pair. For ease of use, I defined a class 'Bufferable' with this capability. Any class extending 'Bufferable' should inherit dynamic attribute feature.

/**
* A Utility class to support addition of new properties to a java bean
* at the runtime. Extend your class with this to make it bufferable. It is
* useful if you want to associate certain properties with an object and
* maintain the OOP nature of your code.
*
* 
This class extends AbstractSerializableBean
* for serialization and property change support.
*
* @author Ragha
* @see AbstractSerializableBean
* @version 1.0
*/
public class Bufferable extends AbstractSerializableBean
{
  private static final long serialVersionUID = 506835437375346326L;

  /**
   * This map is used to store property name and object as key-value pairs.
   */
  private HashMap buffer = new HashMap();

  /**
   * This method is used as a getter for the associated property in the
   * buffer.
   *
   * 
You must typically create the property using
   * {@link #createPropertyInBuffer(java.lang.String) createPropertyInBuffer(...)} method
   * before using this method.
   *
   * @param property The property to be used
   * @return The value of the property.
   * @throws java.lang.IllegalArgumentException If there is no such property.
   */
  public Object getValueFromBuffer(String property)
          throws IllegalArgumentException
  {
      if(buffer.containsKey(property))
          return buffer.get(property);
      else
      {
          throw new IllegalArgumentException("Property: '"+property+"' " +
                  "does not exist...");
      }
  }

  /**
   * This method can be used as a setter for the associated property.
   * in the buffer.
   *
   * 
You must typically create the property using
   * {@link #createPropertyInBuffer(java.lang.String) createPropertyInBuffer(...)} method
   * before using this method.
   *
   * @param property The property value to be set
   * @param Value The value to be set
   * @throws java.lang.IllegalArgumentException If there is no such property
   */
  public void putValueInBuffer(String property, Object Value)
          throws IllegalArgumentException
  {
      if(buffer.containsKey(property))
          buffer.put(property, Value);
      else
      {
          throw new IllegalArgumentException("Property: '"+property+"' " +
                  "does not exist...");
      }      
  }

  /**
   * Creates a new property in the buffer. Once the property is created,
   * it can be get or set using the
   * {@link #putValueInBuffer(java.lang.String, java.lang.Object) putValueInBuffer(...)} and
   * {@link #getValueFromBuffer(java.lang.String) getValueFromBuffer(...)} methods
   *
   * 
It is recommended that you use Classname-property name as property
   * string to avoid conflicts with other existing property names...
   *
   * @param property The property name to be associated with the buffer.
   * @throws java.lang.IllegalArgumentException If the property name already exists.
   */
  public void createPropertyInBuffer(String property)
          throws IllegalArgumentException
  {
      if(buffer.containsKey(property))
      {
          throw new IllegalArgumentException("Property: '"+property+"' " +
                  "already exists...");
      }
      else
      {
          buffer.put(property, new Object());
      }
  }

  /**
   * This method can be used to check if a given property already exists.
   * @param property The property to be checked.
   * @return true, if the property exists.
   */
  public boolean isPropertyInBuffer(String property)
  {
      return buffer.containsKey(property);
  }

  @Override
  public boolean equals(Object obj) {
      if (obj == null) {
          return false;
      }
      if (getClass() != obj.getClass()) {
          return false;
      }
      final Bufferable other = (Bufferable) obj;
      if (this.buffer != other.buffer && (this.buffer == null || !this.buffer.equals(other.buffer))) {
          return false;
      }
      return true;
  }

  @Override
  public int hashCode() {
      int hash = 3;
      hash = 79 * hash + (this.buffer != null ? this.buffer.hashCode() : 0);
      return hash;
  }  
}

Everything should look pretty obvious except for why i am extending my class with AbstractSerializableBean. Well, this is done in order to make the class Serializable. The code for AbstractSerializableBean should make things clearer.

/**
* This subclass enhances {@code AbstractBean} by implementing the
* {@code Serializable} interface. {@code AbstractSerializableBean} correctly
* serializes all {@code Serializable} listeners that it contains. Implementors
* that need to extends {@code AbstractBean} or one of its subclasses and
* require serialization should use this class if possible. If it is not
* possible to extend this class, the implementation can guide implementors on
* how to properly serialize the listeners.
*
* @see AbstractBean
* @author Ragha
*/
public class AbstractSerializableBean extends AbstractBean implements Serializable
{
  private static final long serialVersionUID = -3459406004204097480L;

  protected AbstractSerializableBean()
  {
      super();
  }

  private void writeObject(ObjectOutputStream s) throws IOException {
      s.defaultWriteObject();

      for (PropertyChangeListener l : getPropertyChangeListeners()) {
          if (l instanceof Serializable) {
              s.writeObject(l);
          }
      }
      s.writeObject(null);
  }

  private void readObject(ObjectInputStream s) throws ClassNotFoundException,
          IOException {
      s.defaultReadObject();

      Object listenerOrNull;
      while (null != (listenerOrNull = s.readObject())) {
          if (listenerOrNull instanceof PropertyChangeListener) {
              addPropertyChangeListener((PropertyChangeListener) listenerOrNull);
          }
      }
  }
}

That's it...pretty straight forward isn't it..

Predicting hand position on the keyboard by observing random text \m/

Today, I was just typing some nonsense keys on my keyboard and happened to observe something interesting. Below is a uniform random sample of what I typed:

gh

jgh

jg

hjg

hjg

hjg

hjg

hjg

hkg

hjg

hg

jg

hjg

hjg

hg

hjg

hg

hjg

h

gh

gh

ghj

ghj

ghj

g

hjg

khg

hg

hg

hg

hjg

hjg

hjg

hjg

h

ghj

Notice how 'h' repeats a lot of times. It so happens that my middle finger was on 'h'. So, is frequency somehow linked to the length of finger? Turns out I was right. See table below. I used the keys G, H, J, K. My index finger was on G, middle on H, ring finger on J and little finger on K.

Character (Ordered by frequency)	Actual Finger on char	Finger (Ordered by length)
H	Middle	Middle
J	Ring	Ring
G	Index	Index
K	Little	Little

You can try this on your own. Place your fingers on the keyboard (horizontally, any other orientation complicates the situation as relative length changes).

Probability theory says that the chance of occurrence of G, H, J or K is 1/4. But I think that in this case, probability is somehow weighted, in a sense that it is proportional to the length of the finger.

So, what's the use of all this?

1. I wasted your time...haha!
2. You can predict the hand position based on random text...duh!
3. Its cool!
4. See 1

Is it of any use?

I guess not, that explains the label 'lame observations'. But who cares?

P vs NP solved?

Vinay Deolalikar, an Indian scientist @ HP Labs claims to have proved P != NP. This is a significant breakthrough and is of great importance to Computer Scientists. A detailed problem description can be found at http://www.claymath.org/millennium/P_vs_NP/pvsnp.pdf

Deolalikar's proof can be found at http://www.hpl.hp.com/personal/Vinay_Deolalikar/Papers/pnp_8_11.pdf

Note: This is not the final version and is currently undergoing intense peer review.

If his claim holds true, two clay math problems will have been solved! This is exciting!