Self-numbers

For any given base, a number is called as Self-number, if it cannot be represented as a sum of another integer and the sum of this integer's digits. Hmm... seems like a pretty simple coding-task. Indeed it is! Sat for about half-an-hour and here (released under GNU-GPL) is the program which can generate first 'n' self-numbers for base 10. I profiled this code and given below are the results:

$ make profile
printCpuInfo.sh
Processor Information:
processor       : 0
vendor_id       : GenuineIntel
model name      : Intel(R) Xeon(R) CPU           E5450  @ 3.00GHz

selfnumber -nooutput -profile -limit 1000001
Found 0 self-numbers among first '1000000' integers.
Took 0.004973 seconds to search for self-numbers among these integers.

selfnumber -nooutput -profile -limit 10000001
Found 0 self-numbers among first '10000000' integers.
Took 0.060016 seconds to search for self-numbers among these integers.

selfnumber -nooutput -profile -limit 100000001
Found 0 self-numbers among first '100000000' integers.
Took 0.597042 seconds to search for self-numbers among these integers.

selfnumber -nooutput -profile -limit 1000000001
Found 0 self-numbers among first '1000000000' integers.
Took 5.440813 seconds to search for self-numbers among these integers.

~5ms for 1 million numbers seems like pretty fast. Isn't it?


UPDATE1:
I moved this program to github. Read-only access for this is at git://github.com/teju85/Self-Numbers.git. I also optimized the inner loop to perform modulus operations only for one in 100 numbers. This way, I was able to reduce the run-time to 2ms for 1 million numbers!

$ make profile
printCpuInfo.sh
Processor Information:
processor       : 0
vendor_id       : GenuineIntel
model name      : Intel(R) Xeon(R) CPU           X5355  @ 2.66GHz

selfnumber -nooutput -profile -limit 1000001
Found 97786 self-numbers among first '1000000' integers.
Took 0.002037 seconds to search for self-numbers among these integers.

selfnumber -nooutput -profile -limit 10000001
Found 977787 self-numbers among first '10000000' integers.
Took 0.018121 seconds to search for self-numbers among these integers.

selfnumber -nooutput -profile -limit 100000001
Found 9777788 self-numbers among first '100000000' integers.
Took 0.185008 seconds to search for self-numbers among these integers.

selfnumber -nooutput -profile -limit 1000000001
Found 97777789 self-numbers among first '1000000000' integers.
Took 1.789393 seconds to search for self-numbers among these integers.

FindBin equivalent in bash

Perl has a really useful module called 'FindBin'. Using this module, one can find the actual directory of the current script and also can find the real name of the script (when the current script is just a symlink). What's the equivalent of it in bash? Answer is 'FindBin.sh'.

I wrote this bash script to imitate the behavior of both $FindBin::RealBin and $FindBin::RealScript. You can find this script here. I uses the environment variable 'PATH' to figure out the dir name and actual name of the current script.

How use it?

It's really simple! 'FindBin.sh' currently accepts 2 command line options: '-bin' and '-script'. '-bin' is equivalent to FindBin::RealBin and '-script' is to 'FindBin::RealScript'. After these commandline options, just pass the name of the current script. (which is generally stored in $0).

Example: myRealBin=`FindBin.sh -bin "$0"` 

Help?
Use the '-h' option with this script in order to know about its usage.

Happy coding!

Not all colors are showing in gnome-terminal (and xterm)!?

This incidence happened to me on my office vnc session (on 64b CentOS, kernel Version 2.6.29.4). I was in a vnc session and I typed ls --colors=always. I was expecting the output to be colorized as per the values set by 'dircolors'. But to my surprise I saw that the output was not colorized! I googled on this issue and saw some suggestions in many of the linux forums. I kept on trying each one of these solutions below:

• Setting TERM=xterm
• Setting TERM=xterm-color
• Setting force_use_color=yes
• Changing (and playing with) the values for gnome color palette.

But, none of them gave back the colors! Frustrating!
However, to my surprise, on a ssh session on the same machine, I was able to get the colors displayed! So, this definitely seemed to be an issue with the vnc session. (Indeed it was :D). I then checked the command used to create this vnc session and it was created with '-depth 8' (8bpp, bits per pixel). Somehow, gnome-terminal (as well as xterm) do not display (multiple) colors when you are in an 8bpp vnc session. But you know, even in that situation (8bpp), 'konsole' was able to display the colors!

By now, you'd have figured out the solution ;).
Yes! the solution is to start a vnc session using the option '-depth 24' to the command 'vncserver'.

Happy coding!

PS: If you set the depth to be 24bpp, then the bandwidth consumption of vnc viewer would increase. A solution for that is to set your vnc viewer to work with lesser colors. EG: 'Low (64 colors)'.

TouchUtils.clickView too slow!?

Here's the scenario...

• You have written an android test-suite for your application.
• Your test cases use 'TouchUtils.clickView' class by android, in order to simulate clicking the buttons on your view.
• However, time between each click is slow to the extent that it has become the bottleneck in your test-suite! 

In the implementation of TouchUtils.clickView, there's a sleep of 1000ms (1sec) after every call made to this function. This is the reason for the delay you've been seeing.

 So, I went ahead and copied the code for 'clickView' and created my own class for providing users with programmable delays. This would help the verification guys to fine tune the delays between each clicks. Hence, trying to keep the runtime of the test-suite under control.

 This class 'MyTouchUtils' can be found here. Just save this file to your project and 'import' this class into your test files. Then, if you want to simulate a click event with 200ms of delay after the click, just do the following:MyTouchUtils.myClickView(this, view, 200);

 Of course there's a trade-off involved between the time given for your program to settle down, digest your click event and produce the results; and the total runtime of your test-suite. So, you have to make the decision accordingly.

Happy Coding!

Android Instrumentation Testing

This article will talk about a strange "permission denial" issue which occurs when  trying to run android instrumentation on eclipse. Of course it'll also disclose the solution to it :).

So, what's the problem?

Whenever you try to run the android test-suite for your application, you see an error message like the following in the 'Console' area of your eclipse IDE.
"Test run failed: Permission Denial: starting instrumentation ComponentInfo{<testPackage>/android.test.InstrumentationTestRunner} from pid=123, uid=123 not allowed because package <testPackage> does not have a signature matching the target <targetPackage>"

Reason?

The error message is pretty self-descriptive. As you might have figured out, it's basically due to a signature mismatch between the <targetPackage> and <testPackage>. In simple words, eclipse is using different certificates for signing up your application and for it's test-suite.

Solution?

Generally, when you are running test-cases on your application, you would want to use debug certificates. Eclipse, by default uses debug certificates. So, best way to solve this is to start from scratch. For that, just do the following. In the 'Package Explorer' right click on your target application -> Source -> Clean up. Repeat the same thing for your test application as well. After this, rebuild both of them. Then you'll be right back on the track.

Happy coding!