Tuesday, November 21, 2017

Updates from last 3 weeks or so...

I took part in Codechef's November Challenge (which stretched from 3rd till 13th of Nov.) intermittently solving some of the tough problems (not necessarily quickly) to keep a track of my progress and increase my comfort in solving problems in a long contest setting.

Ranked at 2856 out of 7024 who submitted at-least one problem partially or completely correct, I'd say it was an slight better than average performance. My long-contest rating saw a big boost, but I simultaneously saw a drop in my overall codechef rating [performance graphs]. Solved 3 problems successfully, tried fourth and fifth one but couldn't figure out the problem so didn't attempt and saw wrong answer for a submission for the sixth problem. For the remaining four, I didn't even get a chance to go through given the limited time I had (this happens when you manage your job while stealing some time out for your hobby. ;) )

Successful submissions are open to public post closure of the contest:

I am yet to up-solve those 7 problems which I couldn't solve during the contest.


The following week, I got my free time busy with the 35th Week of Code by Hackerrank.
Ranked at 3181 out of 9289, I'd say I performed better than average among the participants but there is still a huge gap between my score (59) and that of the highest scorer (290).

Here, I solved the first 3 problems successfully.

The fourth problem, Matrix Land, was a show-stopper! I really recommend it! I spend 3 evenings on it and still was not able to come up with a working solution. I was trying to figure out a modification of Bellman-Ford algorithm (which is a Dynamic Programming algorithm) to solve it with some decent efficiency but was getting nowhere as there was no way to mark visited vertices...
It turns out, reading the insightful problem editorial, one could solve it using a bunch of dynamic programming equations.

I went through the 5th and 6th problems too which were number crunching problems and they despite of being hard and expert level, seemed easier than the 4th one but didn't get much time to think them through their solutions.

Again, I have yet to up-solve the unsolved ones.

Saturday, October 28, 2017

[Problem4 SPOJ:PT07Z and Problem5 SPOJ:LABYR1] More on mazes

PROBLEMShttp://www.spoj.com/problems/PT07Z and http://www.spoj.com/problems/LABYR1

I set out to solve LABYR1 last early this week and found that PT07Z would act as a good precursory problem so solved that first.

There are a lot of forests on this way <= Does that ring a bell as to which road we should take?

Well, coming to the hints and note taking part...

I came across this article [ https://cptalks.quora.com/Diameter-of-a-Tree ] which claims to be an optimization I am yet to analyse.

A classic textbook lemma exists for such problems which I applied here.  I used DFS twice.

and https://github.com/glassrose/CPP_Problem_Solving/blob/master/SPOJ-LABYR1.cpp

Tested herehttp://www.spoj.com/status/PT07Z,chandniverma/
and http://www.spoj.com/status/LABYR1,chandniverma/

Complexities in the worst case:

For Problem 4
: Time is O(N) where N is the no. of nodes in the tree.
Space needed is O(N) where N= no. of nodes in the tree.

For Problem 5: Time for each test case is O(R*C) where R and C=no. of rows and columns in the labyrinth respectively.
Space needed is O(R*C)

Saturday, October 21, 2017

[Problem3 SPOJ:ROBOTGRI] A problem for lovers of mazes!


This was a tough nut!

Its a graph problem. Its actually a combination of 2 problems in one! I have voted it as hard and given it my recommendation.

I went through the following resources (none has the actual solution but all serve as hints) to finally come up with a solution for it:


Tested and Accepted: http://www.spoj.com/status/ROBOTGRI,chandniverma/

Time complexity in the worst case: O(n^2 + E)
where n = number of rows (or columns) in the grid
and E = number of edges in the connected graph containing the starting cell 'S'.

Space complexity: O(n^2)

Wednesday, October 11, 2017

[Problem2 SPOJ:JNEXT] Next Lexicographical Permutation Algorithm; Ad-Hoc

PROBLEM: http://www.spoj.com/problems/JNEXT/

I was solving SPOJ-JNEXT, and from the comments section I came across this page:


Nice explanation but there's a caveat to keep in mind to understand the working better-

It mentions:
If there is no such element – i.e. the entire sequence is non-decreasing – then this is already the last permutation.
It should rather be "non-increasing" instead of "non-decreasing".

[UPDATE: It has been corrected on the website nayuki.io. The author personally wrote a thank you note to me confirming  the error and rectifying it.]

My approach to solving this problem was similar so I won't bore you with another copy of how the algorithm works here: you may use the explanation in nayuki.io link above (with the correction in mind).

Tested and accepted: http://www.spoj.com/status/JNEXT,chandniverma/

Time Complexity of get_next_perm() in worst case: O(n) where n is the number of digits in each test case in the input.
Space complexity: O(n)

Tuesday, October 10, 2017

[Problem1 SPOJ:STPAR] Stacks use case; Ad-hoc

Starting last weekend I have started picking up problems from the certification syllabus of the Codechef Certified Data Structure & Algorithms Programme: CCDSAP ( https://www.codechef.com/certification/prepare ). I would definitely recommend solving the practice material even if you are not willing to go for the certification.

I'll solve these in increasing order of difficulty and not necessarily sequentially while skipping the cake-walk ones and also probably the ones that I have done previously.
This way I can ensure this series of self-paced hackathon-cum-blogathon will eventually come to an end, with an end to the problems in this syllabus.


I had done this problem earlier so it was a good candidate for an ice-breaker. I first (sometime in 2010) solved this in Java. This time in C++ using an on-the-fly algorithm that doesn't store all inputs before processing them but processes each input as it comes in a single pass.

Tested and accepted at : http://www.spoj.com/status/STPAR,chandniverma/

The time complexity is O(n).
Space needed is O(n) (actually only n).

Friday, October 6, 2017

Blogging after a long time... turning my blog into an algorithmist's blog solving this world's time and memory efficiency problems in computing.

... Since I cannot talk much about what things I work on as part of my day job and since I feel that's making my blog boring and making the viewers wait a lot between my blogging sessions, I've decided to start blogging about algorithmic programming skills which every computer software engineer should be good at!

I'll do this because I like spending my free time in sharpening my algorithmic skills and while I take notes, why not should someone-on-the-web learn something out of it?

I'll post codes into a Github public repository which will have C++ solutions (why C++? due to it's speed, presence of STL and intuitiveness of Object Orient-ism) tested by online judges and if I learn something triggering an Aha moment, I'll jot down a quick blog post with links to an actual runnable code and the problem it solves.

You all can send thank you notes and suggestions for improvements my way, as always!

Sounds fun?
Watch this space!

Thursday, November 17, 2016

Making lshw, IBM PowerPC compliant

Dear Linux Community,

The first tool that comes to mind when we think of obtaining hardware inventory on a computer is lshw, a concise tool leveraging C++ capabilities which already generates good results when run on a number of platforms, including x86.

lshw, like other cross-platform tools has generic code portions which are same across all platforms and some platform-specific code portions.

I am glad to tell that efforts to make lshw display correct and accurate platform-specific results when run on IBM PowerPC server systems running Linux are paying off as code-changes are getting merged upstream:

My other notable commits(despite of not retaining the Author name and signoff tag) include:

I'd like to thank lshw maintainer, Lyonel Vincent, here for acknowledging and accepting the changes.

Research is ongoing on abilities that are required but are lacking in the generic code as well and some of those require deep knowledge of ioctls, SCSI, SAS etc. and their workings. We're seeing how to expose more of those hardware inventory (encapsulated by certain subsystems) along with their location-codes and Vital Product Data (VPD) to the users so watch the above spaces and keep your systems updated!

Happy Hacking!

Wednesday, August 24, 2016

Learning Python!

Here are my first few basic Python programs (before my first Python assignment consuming and processing perf samples). :)

i = raw_input()
print i

T = int(raw_input())
print "Range of t is", range(T)
for i in range(T):
    print i
    ans = 42
    print "Case #%d: %d" % (i+1, ans)
T = int(raw_input())
for i in range(T):
    line = raw_input()
    N, J = line.split()
    N, J = int(N), int(J)
    print "N = %d, J = %d" % (N, J)   

T = int(raw_input())
i = 1
while i<=T:
    tmp = raw_input()
    N = int (tmp.split()[0])
    J = int (tmp.split()[1])
    print N, J
    print 2**N
    print 2**N-1
    print bin(2**N-1)
    i +=1   

#program 5
T = int(raw_input())
i = 1
while i<=T:
    tmp = raw_input()
    N = int (tmp.split()[0])
    J = int (tmp.split()[1])
    print N, J
    print 2**N
    print 2**N-1
    print bin(2**N-1)
    s = bin(2**N-1)[2:]
    print int(s, 2)
    print int(s, 3)
    print int(s, 4)
    print int(s, 10)

#program 6
#defining functions
def factorial(n):
    ret = 1
    for i in range(n):
        ret *= i+1
    return ret
print factorial(5)
print factorial(4), factorial(3)

Friday, July 15, 2016

Secure C/C++ Coding practices

Dear Software Engineers and Amateur Programmers,

In today's scenario, writing secure code is not a choice anymore, it's a necessity.

As a result of me attending Paul Ionescu's webcast "Inside the mind of a Hacker" (https://t.co/YjqiJpn7lE) (where he talks about how crackers crack their way through your code and what loopholes and vulnerabilities they exploit) and being trained overtime with strong review comments from peers laying emphasis on secure programming, I've begun giving a keen eye to best coding practices.

One such link I googled for yesterday and thought of sharing is:

The following usage in the correctly marked answer there:
strncpy(buff, "String 1", BUFFER_SIZE - 1);
buff[BUFFER_SIZE - 1] = '\0';
is actually correct and not incorrect as pointed out by one of the commenters. See for yourself to know why!
(I couldn't add a comment there due to lack of enough points to comment on StackOverflow.)

I found many instances of insecure invocation of strncpy in the open source package I am currently working on like
strncpy(buff, "String 1", sizeof(buf));
and wanted to give a alert to the maintainers/programmers if they are using such lines often in their code so that they stop making this mistake.

Will keep posting updates in this space with more such important links.

Till then,
Cheers and Happy Coding!