PPF Interest Rate History Since its Inception in 1968

Here is the PPF interest rate history since its launch by Ministry of Finance in 1968. Please note that PPF interest rates are 0.25% higher than the average yield of 10 year government bond. Prior to 2016, PPF interest rates were revised annually. But after 2016, PPF interest rates are revised quarterly.

PPF interest rate history
Year Rate of interest (p.a.)
Oct, 2018 – Dec, 2018 Yet to declare
Jan, 2018 – Sep, 2018 7.6%
Jul, 2017 – Dec, 2017 7.8%
Apr, 2017 – Jun, 2017 7.9%
Oct, 2016 – Mar, 2017 8.0%
Apr, 2016 – Sep, 2016 8.1%
Apr, 2013 – Mar, 2016 8.7%
Apr, 2012 – Mar, 2013 8.8%
Dec 2011 – Mar 2012 8.6%
Mar, 2003 – Nov 2011 8%
Mar, 2002 – Feb 2003 9%
Mar 2001 – Feb, 2002 9.5%
Jan, 2000 – Feb, 2001 11%
Apr, 1986 – Jan, 2000 12%
Apr, 1985 – Mar, 1986 10%
Apr, 1984 – Mar, 1985 9.5%
Apr, 1983 – Mar, 1984 9%
Apr, 1981 – Mar, 1983 8.5%
Apr, 1980 – Mar, 1981 8%
Apr, 1977 – Mar, 1980 7.5%
Aug, 1974 – Mar, 1977 7%
Apr, 1974 – Jul, 1974 5.8%
Apr, 1973 – Mar, 1974 5.3%
Apr, 1970 – Mar, 1973 5%
Apr, 1968 – Mar, 1970 4.8%

We hope this complied data regarding PPF interest rate history will help you making decision regarding investment in PPF.

What is Heisenbug?

As a QA, Heisenbug has been a trouble for me. In response to a reported crash, the developer would say that he can’t reproduce the bug. The software is working fine at developers’ machines. But same bug is appearing at QAs’ machine regularly. These are real testing times for a QA. If the steps to reproduce etc are mentioned accurately, then most probably the bug is Heisenbug.

Now the question is : What is Heisenbug? The Heisenbug falls under a class of software bugs that are considered exceptionally difficult to understand and repair.

A heisenbug (named after the Heisenberg Uncertainty Principle) is a software bug that disappears or alters its characteristics when an attempt is made to study it. Heisenberg’s Uncertainty Principle states, “it is fundamentally impossible to predict the position and momentum of a particle at the same time”.

One common example is a bug that occurs in a program that was compiled with an optimizing compiler, but not in the same program when compiled without optimization (e.g., for generating a debug-mode version). Another example is a bug caused by a race condition. A heisenbug may also appear in a system that does not conform to the command-query separation design guideline, since a routine called more than once could return different values each time, generating hard-to-reproduce bugs in a race condition scenario.

One common reason for heisenbug-like behaviour is that executing a program in debug mode often cleans memory before the program starts, and forces variables onto stack locations, instead of keeping them in registers. These differences in execution can alter the effect of bugs involving out-of-bounds member access or incorrect assumptions about the initial contents of memory. Another reason is that debuggers commonly provide watches or other user interfaces that cause additional code (such as property accessors) to be executed, which can, in turn, change the state of the program. Yet another reason is a fandango on core, the effect of a pointer running out of bounds. In C++, many heisenbugs are caused by uninitialized variables.

So if something is working on developer’s machine but not at staging/QA environment/server, then look around carefully, it might be a heisenbug.