Skip to main content

Java - Algorithms (Part 2)

Reversion:  It may be amazing that a method can call itself, but why shouldn't it be able to? A method call is a transfer of  control to the start of the method. This transfer of control can take place from within the method as well as from outside.

All this may seem like passing the bulk. Someone tells me to find the 9th triangular number. I know this is 9 plus the 8th triangular number, so I called Martin and ask him to find 8th number.When I hear back from him, I'll add 9 to whatever he tells me and that will be the answer. Martin will ask 7th number from other person. This process continues with each person passing the buck to another one. Where does this buck-passing end? Someone at some point must be able to figure out an answer that doesn't involve asking another person to help them.

The Characteristics of Recursive methods:
. it calls itself
. when it calls itself, it does so to solve a smaller problem. In each successive call of a recursive method to itself, the argument becomes smaller(or perhaps a range described by multiple arguments becomes smaller), reflecting the fact that the problem has become "smaller" or easier.
. There's some version of the problem that is simple enough that the routine can solve it, and return, without calling itself.

Is recursion Efficient? Calling a method involves certain overhead. control must be transferred from the location of the call to the beginning of the method. In addition, the arguments to the method, and the address to which the method should return, must be pushed onto an internal stack so that the method can access the argument values and know where to return.

Towers of Hanoi algorithm:
1. move the subtree consisting of the top n-1 disks from S(source Tower) to I(Intermediate tower)
2. Move the remaining (largest) disk from S to D(Destination Tower)
3.Move the subtree from I to D
public static void doTowers(int topN, char from, char inter, char to){
if(topN ==1)
log.info("Disk 1 from " + from + " to " + to);
else{
doTowers(topN-1,from,to,inter); // from --> inter
log.info("Disk " + topN + "from " + from + " to " + to);
doTowers(topN-1,inter,from,to);
}
}



Comments

Popular posts from this blog

Quicksort implementation by using Java

 source: http://www.algolist.net/Algorithms/Sorting/Quicksort. The divide-and-conquer strategy is used in quicksort. Below the recursion step is described: 1st: Choose a pivot value. We take the value of the middle element as pivot value, but it can be any value(e.g. some people would like to pick the first element and do the exchange in the end) 2nd: Partition. Rearrange elements in such a way, that all elements which are lesser than the pivot go to the left part of the array and all elements greater than the pivot, go to the right part of the array. Values equal to the pivot can stay in any part of the array. Apply quicksort algorithm recursively to the left and the right parts - the previous pivot element excluded! Partition algorithm in detail: There are two indices i and j and at the very beginning of the partition algorithm i points to the first element in the array and j points to the last one. Then algorithm moves i forward, until an element with value greater or equal

Live - solving the jasper report out of memory and high cpu usage problems

I still can not find the solution. So I summary all the things and tell my boss about it. If any one knows the solution, please let me know. Symptom: 1.        The JVM became Out of memory when creating big consumption report 2.        Those JRTemplateElement-instances is still there occupied even if I logged out the system Reason:         1. There is a large number of JRTemplateElement-instances cached in the memory 2.     The clearobjects() method in ReportThread class has not been triggered when logging out Action I tried:      About the Virtualizer: 1.     Replacing the JRSwapFileVirtualizer with JRFileVirtualizer 2.     Not use any FileVirtualizer for cache the report in the hard disk Result: The japserreport still creating the a large number of JRTemplateElement-instances in the memory        About the work around below,      I tried: item 3(in below work around list) – result: it helps to reduce  the size of the JRTemplateElement Object        

Stretch a row if data overflows in jasper reports

It is very common that some columns of the report need to stretch to show all the content in that column. But  if you just specify the property " stretch with overflow' to that column(we called text field in jasper report world) , it will just stretch that column and won't change other columns, so the row could be ridiculous. Haven't find the solution from internet yet. So I just review the properties in iReport one by one and find two useful properties(the bold  highlighted in example below) which resolve the problems.   example: <band height="20" splitType="Stretch" > <textField isStretchWithOverflow="true" pattern="" isBlankWhenNull="true"> <reportElement stretchType="RelativeToTallestObject" mode="Opaque" x="192" y="0" width="183" height="20"/> <box leftPadding="2"> <pen lineWidth="0.25"/>