Four hundred students are gathered in the school auditorium. I go up on stage to speak to them and try to explain what programming is. “How many of you know what programming is?”, I ask, with a lot of hope that at least I will see a hundred hands in the air – I just see twenty. It surprises me. This is a school in India and is a reputed one, very few have a clue about what programming is. The scene reminds me of the code.org video where no student says that he or she wants to be a programmer when they grow up. But, I see a lot of talent here. Later, into the talk I pose questions like the Seven Bridges of Konisberg, a popular problem in Computer Science taught to undergraduate students in university, quite a few of them are able to comprehend the solution and some are able to reason out the correctness of it as well. I think, “Well, there’s a lot of talent that is not being realized in schools in India, and programming can be a huge key to teaching kids a thought process”. With loads of eyes looking at me with a certain spark, I end my jargon speak asking “So, how many of you are now interested in programming?” and ninety percent of the crowd raises its hands – success!
It can get really taxing to introduce a new topic to a crowd that has never even heard of it. As one becomes more specialized in a field, it becomes even harder to generalize your topic of interest and explain it to a junta which is younger yet extremely interested and enthusiastic. My experiences with introducing programming to school students in two different schools were quite similar. I realized the challenges behind explaining something new to a crowd that was still starting off their explorations in the world of math and computer science. Hence, I outline here my experience with the entire ordeal along with a few points of advice that might help any volunteer on the way.
I was interested in sharing my programming experience with schools as I felt I missed out on knowing about a competition like IOI while I was at school. I felt that programming is a wonderful skill that teaches one how to think in an organized way and would really grab the attention of students still studying in school. Hence, I went up to the principal of my Alma Mater, Mr. Gautam Gupta from the Aditya Birla Public School and he allowed me to give regular lectures to the students of classes X-XII. I found out that CodeChef was also working on a similar idea and I asked them if they would like to collaborate. Hence, I signed up for being a volunteer with them.
I took two introductory sessions at two different schools – The Aditya Birla Public School, Renusagar and The Delhi Public School, Vidhyanagar. I hail from a place called Renusagar in Uttar Pradesh. Major challenges in this area are availability of a stable internet connection and the remote location which makes it hard for people to know about new happenings in the outside world. But, the principals of both schools were really receptive.
Both schools have CBSE as the board at the secondary and senior secondary levels. In fact, Dr. Janardan Pandey, principal, DPS, Vidhyanagar asked me about the differences between Python and C++ knowing that CBSE is planning to make a shift to Python for the computer science syllabus for classes XI and XII. He clearly realizes the importance of programming as being the next big thing and in fact, was really happy to see posters for LunchTime that I handed over to him. The posters were immediately scanned and emailed to all parents on the same day making it possible for parents to understand as well. I had a wonderful experience interacting with him.
At the Aditya Birla Public School, Renusagar, which is my Alma Mater, the principal, Mr. Gautam Gupta agreed to let me take regular mentoring sessions after selecting students from an interaction session that I took. The students have been quite regular and enthusiastic about these sessions that take place on the Saturday every week.
I will describe my experience with DPS, Vidhyanagar here, as the session at the ABPS, Renusagar was quite similar. The session was held in the school auditorium and was jam packed with students from class 9th to 12th. The crowd was really receptive and enthusiastic about everything that I talked about and it was fun to receive a nice round of questions in the end. The presentation began with the principal giving my introduction. Later, I stepped up on stage and introduced myself as well – telling the students my name, my school and my college.
Next, I asked the students if they knew what programming was, if they had prior experience with a programming language and if they loved mathematics. The response wasn’t huge in this aspect as most students actually didn’t know what programming was. I told them that programming is a way to instruct a computer to carry out certain tasks and gave examples how programming can be used by a biologist (to predict the epidemic of swine flu) or by musicians to compose music as well. I played the 1-min long video from code.org for the students and asked them to identify each person featuring on the video. It was a pleasure to see so many students laughing and getting excited when I asked them if they knew who Mark Zuckerberg or Bill Gates was. I also talked to the students about the movies, The Terminator and The Matrix, since students find it easy to relate concepts to these movies as almost all of the crowd had seen these movies and found them fascinating.
I told them about International Informatics in Olympiad (IOI) and how nobody has won a Gold Medal at it and about CodeChef promising to reward cash prizes to anyone who achieves the feat first from the country. I also told them about the posters for LunchTime that would soon be posted on their school notice boards. I told them about the Zonal Informatics Olympiad (ZIO) /Indian Computing Olympiad (ICO) and the camp as well and the nearest center for writing the examination.
It might seem impossible in the beginning to introduce things like graphs or binary search in the first session itself. But, I realized that examples of these ideas serve as good appetizers for students to get interested and they might want to start reading them up by themselves. One need not introduce data structures and any programming language in particular to give a taste of these topics. It was risky to do so and I did succeed in both the schools with two problems that I gave to the students – they understood and took them really well.
The first problem that I introduced was the following :
“Given a stack of coins, you can take out 1 coin or 2 coins from the stack at each turn that you are given. In how many ways, can a person empty the stack given a way is a distinct sequence of the number of coins remaining at each step till the stack goes empty”.
I went on to explaining Fibonacci numbers to the students, showing them what a tree looked like and how it can be used to count the number of ways. It always helps to give some hints at each step and let them figure it out. I took a small number for the number of coins in the stack (5) and asked them to solve for the same. Once some students shouted out “8”, I drew the tree and explained the solution to everyone else.
It was even more fun discussing the seven bridges of Konisberg and why an Euler walk can’t exist on a certain graph that I drew on the board. I didn’t specify the exact term “graphs” to them but rather preferred talking in terms of cities and roads or circles and lines. It became easier for the students once I took the names of neighbouring cities in this area. I allowed students to figure out an Euler walk for a graph that didn’t have one (all vertices with an odd degree) and it was nice to see students walking away with a smile realizing why their solution was wrong. Ultimately, when I announced that a solution didn’t exist, and on asking why so, one of the students pointed out that each circle (vertex) had an odd number of lines (edges) associated with it.
The session ended with a round of questions from the students and a vote of thanks from the principal. It was amazing to see such enthusiasm from students and on asking in the end, how many of the students were now interested in programming and learning more about it, about 90 percent of the crowd raised their hands – that was really overwhelming for me.
Embedded are a few pictures and a video of the presentation. Hope you find the concept of CodeChef for Schools really interesting!
I can be contacted at +91-9670623389 on weekdays till the end of September as I am joining Google, Mountain View in October and will be moving to USA. The CodeChef for Schools team is available at +91-2230797709 on weekdays from 9 AM to 6 PM.
Link for the video : CodeChef for Schools at Delhi Public School, Vidhyanagar
Just like a small baby, our Lunch Time programming contest series is also growing with every passing moment. The August Lunch Time 2013, was the third edition of the contest and we have already started seeing the number of school students in the rank tables go up. This is equally pleasing and encouraging for everyone.
The August Lunch Time was prepared by Sergey Kulik, donning double hats of editorialist and problem setter. While making his presence felt in second straight Lunch Time Roman Rubanenko, took the responsibility of problem testing. And they both poured all their experience into making the contest exciting enough for our young brigade. With everything in place, it was only upto the participants to come and enjoy the contest.
After the last two Lunch Times, we were expecting the participation number to go a slight up and it did went up. Although, the numbers were not record breaking high, but it is nice to see them go up. Let us have a look at all the numbers that mattered, starting with the rank table.
and the Final stats of the contest.
While the contest saw decent overall participation, the users from schools were almost the double of what we had in the second Lunch Time. We hope that number keeps growing exponentially, as there are plenty of talented school kids waiting their chance to compete with programmers from all over the world. If you participated in the August Lunch Time 2013, but somehow could not crack up all the problems, do give them a shot in the practice session. And to understand how to go about them in an expert manner, go check out the editorials for the problems here.
We hope all you budding programmers would have learnt something new during our Lunch Time contest, as it has been our primary motive. We will see you all with yet another competitive lesson in the form of our September Lunch Time 2013. So, mark your time tables and do not forget to join in for yet another fun-n-learning Sunday.
If you have any queries, feedback, or you want to ask us anything feel free to get in touch with us at firstname.lastname@example.org.
Till next lunch, its TA TA from all of us here at CodeChef.
August Cook-Off 2013, was supposed to be yet another fast paced, action packed Cook-Off, that we have been observing for past few months. However, in no way was it like any of them. August Cook-Off kept us all on the edge of our seats for different reasons every time.
Before we take you through the entire course of the contest, let us thank the people behind the nicely balanced and enticing problem set of August Cook-Off. Our problem setter rustinpiece, setting up problems that appealed every participant equally and problem tester Rubanenko, who ensured that the problems are testing enough for the participants. And finally, the editorialist utkarsh_lath, who wrote the easy to understand and elaborate editorials. Without these gentlemen we would not have had such a great contest.
The preparations for the contest were all in place and we were all good to go. But a lot of aspiring participants from different parts of the world were ready as well. The contest opened up amid great anticipation among the participants, causing a sudden increase in load on our servers and crashing them within the first five minutes of the contest. Now, we have experienced such incidents in the past, but nothing in recent past. So, just like you all, we were also balled over. And, it took us 25 minutes to get the servers up and running as usual. And once we came back, everything went smooth from there onwards.
To give everyone a fair shot at the problems, we increased the contest duration by 25 minutes. And, what a contest it was since then. After the high participation of August Challenge, the August Cook-Off also got lots of love from the participants and saw highest participation for any Cook-Off. But among all those participants who secured the top ten slots in the rank tables, let us tell you.
The global top ten winners are:
Now, the top five Indian users:
Congratulations to all the winners.
Some other useful stats for the August Cook-Off are as follows:
The bump in the beginning of the contest did upset the participants initially, but by the end, the contest got its fair share of love from the participants and eventually turned out to be one of the best Cook-Offs we had on CodeChef in terms of participation. We hope you too have enjoyed the contest as much as we did. And if there is still some problem that is still bugging you about the contest or if you want to find out the best approach about any problem, go check out the editorials for the contest here. You even might find a better approach towards the solution to the problems.
That concludes the story of the August Cook-Off 2013. If you have any suggestion or feedback about the contest or in general, feel free to send them to us at “email@example.com”.
Till next time, TA TA from CodeChef.
See you at the contests.
The August Challenge 2013 became a special contest for a lot of reasons. And that is all the more reason why there should not have been a delay in putting up this post. We regret the delay, and as soon as we had things in place, we sat down and the post here we are trying to put together the entire gist of the contest. We hope you will overlook the delay and enjoy it.
The August Challenge gave us all those fantastic memories, and we would like to thank you all for those. Also, let us thank our problem setting panel featuring furko, ballon_ziq, sereja, vinayak garg, witua, kaushik_iska, cgy4ever, vamsi_kavala and kuruma for their tempting problem set, which was adeptly tested by white_king. And let us not forget the ever present gamabunta, who prepared the mouthwatering dessert in the form of the editorials to all those problems.
With August Challenge 2013, in alignment with the objective of our CodeChef for Schools initiative, we decided that as a motivation we will also be giving goodies to the top 5 high school/middle school students globally as well as Indian students. So, this time, the school students too had something additional to play for. And they played hard for it. High five, to all the young masters. These young minds along with the overwhelming participation from programmers across the globe, contributed in making the August challenge a special one as it saw the highest participation in any of our long challenges till date. As the cherry on top, we got kgstar, topping the rank tables in only his second long challenge appearance, surpassing the more seasoned campaigners like mugurelionut. A big applause for the gentleman topping the rank table. Now, let us move towards the rank tables of the contest and see who all stars in it.
Firstly, the Global Top 10:
And, the top 20 gentlemen from Indian rank tables:
Now, let us welcome the new addition to our winner tables, the students from high/middle school:
Firstly, the top five global school students:
And, the Indian school kids.
Now come the special top three achievers from global as well as Indian rank tables, who have the highest scores for the challenge problem, apart from those who already appear in the winners’ list:
The Global top three:
And, the Indian top three:
Heartiest congratulations to all the winners.
But, those are not the only numbers that made the August Challenge such an immensely successful contest. Here are the other numbers that matter.
The problems of August challenge saw immense love of the participants. And, if for any reason you were not able to crack a problem or two, you should check out the editorials here. You will definitely learn a lot from these editorials and will be better prepared for any such problems from next time onwards.
That concludes our August Challenge 2013. If you have any feedback or suggestion, do send them our way at “firstname.lastname@example.org”. We always love hearing from you guys.
Till next time, ciao from CodeChef.
See you at the contests.
In the wonderful world of CodeChef, a competition is the best tuition one can get. Some might say otherwise, but we believe in it. We have always considered our competitions as teachings for the participants. And our July LunchTime 2013, was just another lesson for it’s young participants.
The contents for the July LunchTime 2013 came from young problem setter Utkarsh Lath, editorialist Bruno Oliveira, and problem tester Roman Rubanenko. The problem set was suppose to gather more love of the school students than the seasoned players, however, nothing like that happened. In fact, the dominant ACRush was seen in for an early lunch. And within first forty minutes of the contest, he had solved all four problems and was off to a Sunday outing or something. But not before we found out a little secret about him. During the course of his stay we came to know his codejam strategy: “Start with the harder problems, so that people think they’re doable. Also make wrong submissions on easier ones, so that people think they’re harder than they are” We think that’s a smart strategy, isn’t it?
Now, let’s see how our school participants did. In terms of participation, the July LunchTime wasn’t much different from the June LunchTime. However, there were some new names flashing in the rank tables. While the new names brought joy, the missing names did made us a bit sad. We love having you young geniuses going all out in our contests, so we’ll be waiting for you all to show up in big numbers in the August LunchTime 2013.
For now, let’s join hands for the winners of our July LunchTime 2013:
The total stats for the contest were as follows:
As we move towards the August Lunch Time 2013 we are expecting those numbers to go further up. So, all you young geniuses start sharpening your coding skills. We have got the editorials for the July contest ready for you, here. They will significantly enhance your programming skills and will help you better your performance.
We will see you at the August Lunch Time 2013 with yet another lesson to help grow as a skilled programmer. Till then keep coding.
If you have any feedback, suggestion, or query regarding our July Lunch Time, feel free to write to us at email@example.com
Till next time, it’s adios from CodeChef.
It’s been quite a while since the July Cook-Off 2013 got over. But it’s sweet memories are still fresh as dew with us. After a long gap (after 24 Cook-Offs), we saw the return of ACRush to the CodeChef Cook-Off. While his return spiced up our Cook-Offs, the regulars in raveman, al13n, and acmonster made sure that it’s not an all-ACRush show.
We saw great competition among the participants, while playing with the problem set of our wonderful problem setter Tuan Anh. The problem set were adeptly tested by Keshav Dhandhania, ensuring that the problem set has all the key ingredients to keep the contestants busy till the very last moment of the contest. And the changing names in rank table established it. Let’s have a look at the final rank table of the July Challenge-2013
The top-ten Global winners are:
The top 5 Indian winners are:
We hope you had enjoyed the July Cook-Off 2013 to the fullest. But, if you had tough times cracking the problem set, our young editorialist Utkarsh Lath has written elaborate editorials for all the problems of the contest. You can check them here. These editorials not only will help you understand the problems, but also will help you learn more about solving them.
That sums up the CodeChef July Cook-Off 2013, from our side. If you have some queries, suggestions, or feedback for us, feel free to write to us at “firstname.lastname@example.org”.
Till next time, it’s adios from CodeChef.
See you at the contests.
It took us some time to pen down the July Challenge 2013 blog, but somehow we did it. And, now that we’ve done it, let’s take you straight to contest.
The problems for July Challenge came from our adept problem setters, Roman Furko, Jay Pandya, Sergey Nagin, Vinayak Garg, Hiroto Sekido, Vitalij Kozhukhivskij, Vamsi Kavala, Ivan Zdomsky and Kaushik Iska; while the problem tester and editorialst was Shilp Gupta.
The contest saw serious competition among the participants. Emerging atop the global rank table was the mighty ACRush, while the Indian rank tables had djdolls enjoying the top rank. Who else featured on the rank tables, lets have a look.
Firstly, the global rank tables:
And now the Indian:
Now, a special mention to the users with highest scores for the challenge problem other than the winners.
The top three global scorers are”
And the top three Indian scorers are:
Here are the stats for the July Challenge 2013.
The detailed explication for each problem of July Challenge 2013 has been provided by our editorialist Shilp Gupta. Go savor them now, they will help you learn the best approach to solve them problems.
With that, we’d wrap up the tale of the July Challenge 2013.
We’ll see you again with a new contest and a new tale. But till then do keep sending us your feedback, suggestions, and queries that you might have at “email@example.com”.
Till next time it’s adios from everyone here at CodeChef.
See you at the contests.
There was a certain uncertainty in the air when we sat down for our first CodeChef LunchTime. It wasn’t the first contest that we were conducting, it wasn’t the first time we were witnessing programmers from across the globe go up against each other. We have been doing this for quite sometime now. But suddenly, after 4 years of hosting contests, it was as if we were new to everything. With butterflies in our stomach and a mild sense of diffidence at the back of our mind, it was one more Sunday for us, in office.
The problem set for the first LunchTime came from Vamsi Kavala and Roman Rubanenko, while Bruno Oliveira penned the editorials. The LunchTime contest was aimed at middle and high school students to persuade them develop interest towards competitive programming. And, to have Roman, who has been to International Olympiad of Informatics 2013 and Vamsi, who has been to ACM ICPC Asia regionals three time , we had the apt problem setting panel.
We were expecting an easy problem set for the schools kids to enjoy. However, the problem set that they crafted proved out to be a tough nut to crack. But, all the participants who participated went all out to solve the problems. The participation although was on the lower side, but we are expecting those figures to go up in the future.
Let’s have a look at all the figures for the contest, starting with the rank tables.
Heartiest congratulations to all the winners and to all the bright minds who participated in the contest.
Here are the overall final stats of the contest.
If you had tough times cracking the problems, you could check out the elaborate editorials for all the problems here. These editorials will help you understand the problem and it’s solution. They will also help you develop the correct approach towards solving such problems in near future, whenever you come across them. For anyone who’s new to programming, these editorials are great help.
It is just the first step towards our ultimate aim of establishing programming as a fundamental skill among the school students. But we are determined to grow leaps and bounds with all you wonderful people by our side. If you have any suggestions or feedback about the contest, do let us know them at firstname.lastname@example.org. We will be pleased to have them from you.
Till next time, it’s goodbye from CodeChef.
Every month we receive huge contribution from all you wonderful people, showing your kindheartedness and ‘will’ to volunteer your time to help others. We have decided to acknowledge it. And, we have dedicated a page to all our top contributors as a token of appreciation. We also will be acknowledging the top 5 contributors of every month with special CodeChef goodies.
If you haven’t already, check out our new top contributor page now, at ‘discuss.codechef.com/top/users‘.
Now, let’s tell you how to feature atop the top contributor page.
The only way to feature among the top contributors is by “contributing.” If you love programming and want to help others who do so, then jump into our forum. You can answer a question, ask a question, take part in existing conversations, or can simply show your appreciation for others’ contribution by up voting their replies. Your act of kindness in the forum will earn you some “Karma Points,” which will be the building blocks for your position on the contributors table. The more the Karma the upper will you be placed.
If you are a newbie to CodeChef, you can check out the current Top Contributors in the forum. You can look at their posts to understand their posting styles, to get started. Doing this will give you an insight on the top contributors’ approach towards contributing to community and the reference resources (if any) they use for answering questions. This will help you learn from their knowledge.
There also are some basic practices that can make you an imperative part of the process determining the top contributors. Firstly, if you have got the right answer to your question, accept it and vote it up. It acknowledges the contributors’ hard work and repute among the community. You can help others by finding the best answer to their question by voting up or voting down, the replies given to their queries. And, lastly you can contribute to the community by maintaining a friendly conduct. You can find some useful tips about using the forum efficiently in our meta tags.
CodeChef community is driven by passionate programmers like you and the more you contribute the more you help fellow programmers. Extend your helping hands to let each other evolve as a better programmer.
Till next time, ciao.
This is a truly interesting question, and I thought it would be a great way to have this opened to the CodeChef community so that we can get their views on various styles, as well as what works and what doesn’t. I’d also like to particularly invite other Editorialists (Anton, Shilp etc.) to describe their process and their reasoning etc.
All of these have their own unique style of Editorials.
Now, I’ll put in some of my views on what makes a good Editorial, and how I’ve learnt over the past few months.
This, I believe, is something worth striving for. Personally, I tend to often take up a very conversational tone in my Editorials (imagining that I am explaining everything from scratch). This tends to make my Editorials unnecessarily verbose. I fear that although the tone is light, I would lose the engagement of an experienced coder. And if its too verbose, I would even lose an intermediate one, while a beginner may wonder “why is this being mentioned”. Having said that, if it is made too technical, then anyone who doesn’t know what’s going on would stop reading. There needs to be a balance between what needs to be said, what is said, and what isn’t said – and striking this balance may not be easy.
In particular, I tend to provide justification after each assertion, while I think it is often better to leave the reader to try out justifying some of the things as he reads them, and if he fails, to find justification later on in the Editorial.
Try not to beat about the bush!
This is not contradictory to what I said earlier about it being non-verbose. When I say thorough, I mean that it should give a complete description of anything related to the problem. Things like “related problems”, “tutorials” on other sites, “mathematical concepts” from other sources – anything related to the problem and its solution should ideally be packaged under the one same Editorial. Imagine reading the solution to a problem on Heavy-light Decomposition. The next thing you need, is somewhere to practice. Imagine having an entire network of Related Problems from which you can shift and browse and practice one by one!!
However, the flipside is that the Editorialist needs to be aware of various resources, and should be able to call them up from memory as required. Again, calling up past problems from memory, is another personal failing (heck, in TC matches, I have often forgotten the 250 pointer by the time I get done with the 500!!).
Add as much information as possible under the one encapsulated Editorial.
Here, “Top-down” style is where the Solution starts with the problem, and then step by step talks about what is required and how each subproblem gets fixed. The “Bottom-up” style on the other hand, first describes the solutions to the subproblems and then puts them together to show you the solution to the whole problem.
Almost always, I’d say the Top-down style is better. It keeps the reader motivated instead of wondering (“why are we doing this”). It also tends to make the solution look simple. By saying “Okay, so X is the problem – that means we need Y – so how do we get it, lets say if we could have Y1, then we could get Y by Z. That just leaves getting Y1 – so lets try to do PQR…”, you are at each step making every requirement and consequent solution seem natural.
Compare that with saying, “First, let us consider Y1. To solve Y1, lets do PQR… Now, finally, you should see that you can get Y from Y1 using Z, and that means you have solved X.” Here, the reader is left wondering “whats up with Y1? Ouch, here comes PQR”.
As a concrete example, consider the following “Tutorial” on Heavy-Light Decomposition:
Problem: You have a tree, where each node has a weight. You can either change the weight of a node, or are asked to query the sum of weights on nodes along a path in the tree. You need O(logN^2) time per operation.
First, find the size of the subtree rooted at each node. Also, we will need to answer LCA queries, so fill in information for that too.
Then, for each node, let us call the edge to the largest (by number of nodes in subtree) child a “heavy” edge. Ties are broken arbitrarily. All other edges are called “light” edges. The set of heavy edges now forms a set of disjoint paths in the tree.
We count the number of different paths from a node to the root. Since you shift from one path to another only through light edges, and since each shift atleast doubles the size of the subtree, you would have shifted only at most log(N) times.
Now, consider each path as a segment tree, so when you update the weight of a node, it takes O(logN) time. Finally, for finding the sum of weights along the path between nodes u and v, first find the LCA w, and then find the sum of weights along the path from u to w, and v to w. Since from any node there are atmost log(N) different paths, overall complexity is O(logN^2).
Let us suppose our tree was a path. Then we could easily solve the problem using a segment tree.
Now, if instead our tree were divided into a set of disjoint paths, and consider each path as a segment, then an update will just take O(log(path_length)) time. And we know path_length <= N.
To answer a query (u, v), let us first find the LCA w, and then divide the path from u to v into u to w and w to v. Then, we just go across each of our segments and take the sum along the way.
Thus, if there are K segments along the path from u to w or v to w, we would like that K is small: since our query will take O(K logN) time.
Finally, if we were to make our segments in such a way that the largest subtree gets to continue the segment, then from any node, along the path to the root, we would shift segments only when doubling our subtree size. Hence, under this scheme, K is always O(logN).
This was to illustrate (hopefully) how the Top-down approach maintains motivation by assuming the least and filling in gaps only as they appear.
Now, I’ve noticed, atleast while learning, that when things look simple, they’re taken to be simple. And when things are taken to be simple, a lot of the intricacies are often taken for granted. In which case, the next time something like this comes up, one might not be able to reconstruct the whole picture by oneself. Thus, in cases where a technique can be applied widely, it might be better to describe it in bottom-up fashion. (One can illustrate use of Binary Indexed Tree by taking the example of dynamic prefix sums being required – or one can start with what Binary Indexed Trees are, and then show how they solve a dynamic prefix sum problem; the latter being favoured although it is bottom-up in this case).
This is just my personal opinions, and if you feel differently, do say so and explain why.
Its always nice to see the entire solution at one stretch. It gives you an overview of what to do, where you failed, how to get the whole thing, all in one picture. Thats what Quick Explanation is for. As far as possible, I’d prefer to have Quick Explanation + Detailed Explanation used. The Quick Explanation should indeed cover all aspects of the solution, and shouldn’t just be about dropping hints (that’s in some sense what “pre-requisites” is for).
In some cases however, just Explanation is good enough. These would be when either the problem is so simple that the Quick Explanation is the entire explanation, or when the problem is so hard, that the solution cannot be summarized without leaving large loopholes.
Whenever possible, Editorials should have a summarized Quick Explanation.
This idea I had picked up from a comment on one of my Editorials. It said, (paraphrased), “Often, it is easier to understand what is going on from the pseudocode rather from the explanation.” In some sense, it is saying that you can say “do this – do that” as much as you like, but it won’t hit home as well as the same thing in pseudocode. The way Mathematics has its own set of symbols: ∀. ∃, ∑ etc. which help clearly and concisely state things, Algorithms uses the language of Pseudocode to convey its ideas succinctly.
Key points of the solution should be written in pseudocode.
During the (Indian) IOI Training Camp last year (2012), we had a set of “coding commentaries” which concentrated not so much on the solution itself, as much as on the various bugs that people had made, and on all the points where the code could have been made neater and easier to debug. It would be great if we could have such sections in the CodeChef Editorials as well (they would largely help reduce the number of “what is wrong with my code” questions being posted after all).
The logistics of running this in a IOITC vs on codechef are very different: in one, you have twenty students coding in a two hour window, on the other you have hundreds-thousands of coders submitting solutions. As such, there is scope for such sections during short contests, wherein the “cooks” browse through a whole load of random submissions, spot bugs, find commonalities and add them to the Editorial. Tips on coding style are relatively harder due to the large and varied range of submissions (20 students writing varied shades of clean/dirty code is different from thousands writing varied shades of “code”: harder to classify dirt from cleanliness). In Long Contests, unless the setting panel made testcases to beat various bugs or suboptimal solutions, it is hard to browse through even “random” codes of people over 10 days and glean knowledge of bugs worth mentioning. Also, the fact that the short contests are far more high energy on the setting side during the course of the contest makes this section relatively more viable in such cases.
As important as it is to describe what works, it is also important to describe what doesn’t!
Editorials are the Editorialist’s labour of love.
Generally, when the Editorialist sees the problem, he first tries to find the solution himself. Alternately, he follows discussions between Setter and Tester and makes sense of the solution from there. Or, he looks at the codes of the Setter/Tester, and justifies what is being done from that point. And if all these aren’t enough (which is the case for the Hard problems a lot of the time), he takes the direct help of the Setter/Tester.
When he arrives at the solution himself, it is then often presented well.
However, in a lot of other times, what can happen (and what should be avoided) is that the solution is presented from the point of view of the setter. One of the comments that I got on one of my Editorials, was “This is just a description of the Setter’s code, and not a solution itself”. The point was very valid, and the fact was that since I hadn’t arrived at the solution myself, I did not outline the thought process of someone who is attacking the problem from scratch. What I had done was present justification for why what the setter had done works.
The Editorialist, by being privy to the solutions, should put in his own effort in making them palatable. His job boils down to answering “Given that this is the solution, and that I know it, how do I make someone who doesn’t know it see it?”
The use of diagrams esp. for Geometry problems, although it takes a little more effort, can speak a thousand words, and would consequently form a bond between the Editorial and the Editorialist (I always enjoy viewing my TRIQUERY Editorial, with the use of its colour-coded lines etc. and I’m sure Utkarsh would do the same for his TAACUTE Editorial).
If the Setter cooks the dishes, and the Tester tastes them, then it is the Editorialist who serves the dessert!
If you have any further suggestions on how to make Editorials better, do post them as answers in the discussion forums.
I hope this post opens discussions on what to do, and how to do all-things-editorials.
[If you merely agree/disagree with any point, post those as comments rather than separate answers].
I hope that this would grow into a “Guidelines/FAQ for Editorialists” or something in time.