Working with the site

Theoretical materials

Some theoretical material is presented on many topics on the site. Before you start solving problems, read the relevant theory. For example, go to level 1A (inside level 1), there is a section "Arithmetic operations", and in this section there are two links — "Getting started with Python and Wing IDE" and "Problems on arithmetic operations". Here "Getting Started with Python and Wing IDE" — this is the relevant theory (in this case, the very basics of working on python, including basic arithmetic operations). Read this theory before solving the corresponding problems. (Of course, if you know the basics of your programming language, then it makes no sense to read the most basic theory, but then you probably start with the following topics, or at least skim the theory).

Problems

The main thing you will do in our classes is to solve problems. Most problems will require writing a program that reads (from the keyboard or from a file) some data, calculates new data from it, and displays the result on the screen or saves it to a file.

You can (and should) send the program you have written for verification. This site provides an opportunity to automatically check your programs — you immediately (usually within a couple of minutes) get the result of the check: your program is working correctly or not. In addition, I will see all your attempts that you send to the site, and I will be able to comment on them, write comments, etc., and you will be able to see these comments and improve your programs based on them.

Sample problem

Go to level 1A (inside level 1). There is a link "Problems for arithmetic operations". Go in there. You will see a list of problems: "Pears", "Pears too", etc., up to "After and before". This is a set of problems (they say "contest" in short) that you are invited to solve in order to consolidate knowledge on the first topic of the course — arithmetic operations.

All the names of the problems are links, they open the actual problem. Open the problem "Pears". You can see her condition: "N friends have K pears. They want to divide these pears among themselves so that everyone gets as much as possible, but at the same time so that all the guys have the same number of pears. How many pears will each have?" Below is an example: when entering data "7 26", the program should output "3".

The problem condition clearly describes what your program should do: for any values of N and K, it should calculate and output the answer to the problem. In more serious problems, the condition always specifies restrictions on the permissible N and K, but in the problems for beginners on this site it is considered that N and K are "reasonable" (in particular, they are fit into int data type in C/C++); "reasonableness" in this case also includes the fact that both numbers are positive.

The example is only needed to verify that you correctly understood the statement, the format of the input data, and to help you test the program on the simplest test. However, your program should work not only on the test from the example, but also on other valid tests.

Writing a solution

This problem is solved quite easily. Of course, we need to have two variables, N and K, read them from the keyboard, and output the incomplete quotient of dividing K by N (note that it is K by N, not N by K!). The program will look like this:

n = int(input())
k = int(input())
print(k // n)

Pay attention to the following features (it may not agree with your textbook — you need to do as it is written here, and not in the textbook. Perhaps you won't understand some of the things described here - then just skip this point).

• We don't output any "prompts" like print("please enter N"). The problem condition clearly states what exactly our program should display on the screen, and there is nothing said about the fact that it is necessary to display prompts. Therefore, any extra output to the screen will be considered as a violation of the output format.
• There are no "fool checks", for example, there is no check "what if N = 0?", or "what if they didn't enter a number?". Similar to the previous one, this is not required in our problems. In more serious problems, there will be restrictions on the permissible values of N in the condition, and no one will test your program with N that does not meet these restrictions. In this problem, it is assumed that N>0 is always.
• We don't put an empty input() (or getch(); in c++) or other delay at the end of the program. This is also not required; the information displayed on the screen is still saved and can still be viewed.
• We calculated and immediately output the answer without saving it to an intermediate variable. It was possible to save:

  ans = k // n
  print(ans)
  

  In this simple program, it is easier to output immediately, but if the expression is more complicated, then you can save it.

Save this program to some file. Remember both the file name and the directory (folder) where you saved the file.

Now test the program. Run it and try different tests.

To start, enter the test from the example: "7 26" (in different lines, like in the example) and make sure that it outputs 3.

In this problem, the answer to each test is uniquely determined (for example, the answer to the example from the statement can only be 3). There are problems when there may be several correct answers for each test, in such problems the condition usually says "if there are several solutions, output any" or there is some similar phrase. In this case, your program is not obliged to give an answer that exactly matches what is specified in the example — it is enough that it is one of the correct ones. Similarly, in the future, when your program will be tested on the website (see below), any of the correct answers for each test will be allowed.

Come up with some more examples for this problem. Try to make them diverse: so that there are different N, K, and different answers. For example, enter "5 25" and check that the answer is 5. Come up with a few more examples yourself. Important: before entering each example into the program, first calculate the answer in your mind, and only then run the program and check that it has output exactly what you expected. Try to always know the answer to your example BEFORE starting the program.

If the program is written correctly, then it will work correctly on your tests. Then it can be submitted for verification to the site (we say "submit / send for testing to the testing system" or simply "submit to the system").

Sending for testing

Go back to the page with the problem statement. Below the statement there is a section "Submit a solution" (it is only there if you are registered on the site and logged in). Click the file selection button and select the file with your solution. Make sure you select the file .py or .cpp (with source code), not .pyc, .o or .exe (already compiled program)! Make sure that the correct language is selected in the drop-down list next to it, and click the "Send" button.

Your program is sent to the server, which checks it by running on several test cases. These test cases are unknown to you, but they are always the same in each specific problem (i.e. if you send several times, the test cases will be the same each time). So, the testing system will run your program several times, each time it will simulate keyboard input of the values N and K from the next test cases, and check that your program outputs the correct answer.

Under the submission form there is a table listing all your attempts (also called "submissions" or "submits") for this problem. Initially, of course, there is no table there. After you have submitted your solution, it will appear in this table. The "Status" column displays the result of testing your program. Immediately after you have submitted the program, you can see there "Compiling" or "Testing", which means that your problem is being tested. The table is updated automatically, wait until the final result of the check appears in the "Status" column.

The main results of the check that you can see:

• OK — your program has passed all the tests correctly, hooray!
• Compilation error — your program was not compiled
• Partial solution — your program didn't pass all the tests (maybe it didn't even pass any). So, your program is not working quite right (or works completely wrong), try to find mistakes.
• There are also "Accepted" and "Ignored" statuses, but they are not set automatically, see about them below.

You can click on each line in the submission table, after which a window with detailed information about the submission will open. Firstly, there will be the full code of your program, so you can always check whether you have sent exactly what you wanted; if you had been solving problems from school, then when you come home, you will be able to see the codes of all your programs, etc.

Secondly, in the window that opens there is a tab "Protocol", where the test protocol of your program is displayed. If your program was not compiled (the status is "Compilation error"), then there will be a compilation protocol: errors found in the program will be indicated. If your program was compiled, then there will be a test protocol: for each test, information will be provided about whether this test passed (OK) or not. There are only 8 tests in the problem "Pears", so there should be 8 rows in the table. If your submission has received the status "OK", then all 8 lines will be OK; otherwise, some tests will have a different status (it is usually clear from the name of the status what this means).

Thus, you can see which (by numbers) tests you have passed and which have not. But you can't find out the contents of the test (in our problem, which N and K are exactly there). This is done so that you learn to test your solution yourself and find examples on which it does not work, and not consider the testing system as a magic box that gives you examples on which your program does not work. Therefore, if your program does not work, then try to find the examples on which it is wrong. If you can't find them, then contact me, we'll try to figure it out together. As a last resort, I have access to all the test data, so if I can't find an error just by looking at your program's code, I can see what kind of test your program doesn't work on.

But in general, try to check the problem before sending it to the system (and we will learn this separately). Treat failed attempts as a real failure, and try to make as few failed attempts as possible. In general, at many programming contests you will have only one opportunity to submit the problem, and if it does not pass some tests, then you will no longer have the opportunity to improve!

Accepting and ignoring submits, comments on submits

I will review all your solutions: if I have time, all submissions in general, including unsuccessful ones, or if I have little time, and there are a lot of submissions, then only submissions with the OK status.

In successful submissions, I will review your code for the following:

• First, I will look to see if there are any errors in the code that the tests of the testing system did not catch. It happens that there is some completely unexpected error in the code, and the testing system may miss it (although the tests in the testing system are usually well prepared, and as a rule all errors in the code manifest themselves during testing) - I will see if you have such errors.
• I will also look to see if I have any comments on the code, even if they are not errors, but are general wishes. For example, maybe something can be done easier, or something should be done differently, etc.

If I have any comments or comments on your program, I will write them and you will be able to see them. Firstly, they will appear on the site in the right column in the "Comments" section; secondly, in each submission, in the window opened by clicking the submit link, there is a special "comments" tab; finally, there is a separate Comments section in the lefthand menu. Accordingly, as soon as I comment on your package, you will see a comment. Usually I try to view all the submissions during the day, although sometimes there are long delays, up to several days.

In addition to actually writing a comment, I make a decision on each of your submissions — either I accept this submit (albeit with small comments), or I will require you to rewrite this submit taking into account my comments. In the first case, I change the status of the submission to "Accepted" (i.e. you will see exactly "Accepted" instead of "OK" in the table with your submissions), in the second case I change the status to "Ignored". Accordingly, in the first case, just take note of the comments that I wrote (and it happens that I do not write any comments), although you can rewrite the solution if you want. In the second case, be sure to rewrite the solution taking into account these comments.

(Read more about why I ignore solutions (in Russian).)

In the summary table, the "OK" solutions (i.e., which I haven't looked at yet) are displayed with a yellow background, the "Accepted" solutions (i.e., which I have accepted) are displayed with a green background, ignored solutions are not taken into account in the total number of problems you have solved, just the corresponding problem in the summary table is displayed with a blue background.

I will also try to write comments on your unsuccessful submissions — to point out an error or advise where to look for it, etc. Of course, I will not always write them as soon as I see your attempt, and I will not always fully report the error found — after all, it will usually be useful for you to find the error more-less independently, I will try to give you suggestive advice (but, of course, it depends on the error). In general, if you tried to do a problem, but it does not pass the tests, then perhaps within a day I will write you a tip in the comments to your submission.

Sometimes I may not have time to review all your unsuccessful submissions, or I do not write a comment for some other reasons. In that case, if you want to get a comment on any of them, just contact me.

Good solutions

After I accept your solution (I set the status "Accepted"), you have access to "good solutions" for the corresponding problem — on the problem page, above the form for submitting the solution, a link to "good solutions" appears.

"Good solutions" are several (up to 5) solutions that were submitted by other students of the course, and which, in my opinion, are written quite well and can be considered an example of solving this problem. Watch them, especially for those problems where I have accepted with any comments (but in general it is useful to watch "good solutions" and for all accepted problems in general). Compare the "good solutions" with your solution, perhaps you will see that something can be done easier, or even find other useful ideas.

I try to keep the balance of different languages in the "good solutions" as much as possible (i.e., as a rule, there are solutions in different languages among the "good solutions"). But look at the solutions in your language, and in other languages that you don't even know — as a rule, you can understand the algorithm even in languages that you don't know at all. On the other hand, you can also find some interesting purely linguistic subtleties and techniques for your language in "good solutions".

In addition, often in "good solutions" I show different approaches to solving the problem, often there are generally different algorithms. If you see that a "good solution" is very different from yours, it is useful to understand how it works in general.

At the same time, understand that in fact, hundreds of solutions have already been submitted for many problems on the site, and in fact there are dozens of "good" ones, if not more. You see a maximum of five of them, simply because there is no point in reading dozens of more or less identical solutions. You will see some five of them which were lucky that I marked them as "good", but this "luck" is often determined by chance, well, and the principles mentioned above about the diversity of languages and approaches. That is, you don't see the top-five best solutions, but five random ones from among those that are sufficiently good.

Therefore, do not assume that if your personal submit did not get into the "good" ones, then it is worse than the "good" ones. It can be just as good, or even something better than the "good" ones, it's just unlucky. If you see that the "good" solutions are written as cleanly and clearly as yours, then yours could also be "good". Conversely, if your solution is in the "good", it does not mean that it is much better than all the others :) For the same reason, the authors of "good solutions" are not signed.

On the other hand, if you have looked at the "good solutions" and think that your solution is noticeably better than all the "good" ones, write to me, maybe I will add your solution to the "good" ones. (Although I usually designate a solution as "good" at the same time as I count it, so if your solution is really noticeably better than other good ones, as a rule, I will make it "good" even before you can see "good solutions" :) .)

Rankings tables

All your submissions for our problems are displayed in rankings tables, links to which are in the site menu. Namely, each cell in the main part of this table indicates the statistics of submissions from a particular student for a specific problem. If there is a "+" sign in the cell, it means that the problem was done successfully ("OK" or "Accepted"), if "-" — it means that the person tried to pass the problem, but did not pass all the tests. The number after the icon (if any) indicates the number of unsuccessful attempts (if any). For example:

• An empty cell indicates that the student did not attempt on the problem at all;
• "+" indicates that the problem was solved successfully on the first attempt;
• notation "-" does not happen;
• "+2" means that the problem was solved on the third attempt (two unsuccessful attempts and then a successful one);
• "-2" means that there were only two unsuccessful attempts on the problem and that's it.

The background of the cell indicates the status of the problem relative to the verdicts "Accepted" and "Ignored":

• Yellow background — status "OK", i.e. I haven't looked at this problem yet;
• Green background — status "Accepted";
• The blue background indicates the status "Ignored", while the ignored attempt itself is considered neither successfull nor unsuccessful.

The last two columns of the table indicate the total number of solved problems and the total number of unsuccessful ("penalty") attempts (only those problems for which the correct program was eventually obtained are taken into account, ignored attempts are not taken into account). The table is sorted by the total number of solved problems, and with an equal number of solved problems — by the number of penalty attempts.

The table also has the following feature: only students who meet two requirements at once appear in it: first, I have to activate their account, and secondly, the student must have at least one attempt to complete the problem. Therefore, if you have not tried to take anything yet, do not be surprised that you are not in the table. If you have already tried to take something, but you are not in the table, then write to me - perhaps I forgot to activate you.

Similarly, problem sets (contests) they appear in the summary table only when at least someone submits some solution for some problem of this contest.

Terminology

Above I have already introduced some specific terminology that is used in programming contests, just in case I will repeat it here:

• A contest is any set of problems that is somehow grouped and separated from the rest. Within the contest, the problems are usually numbered (1, 2, 3, ... or A, B, C, ... etc.) It can be a separate round of some competition, or a set of problems for some class or on some topic, etc. As part of our classes, we call a "contest" a set of problems available on each individual link from a page of the appropriate level. For example, "Problems on arithmetic operations" is a separate contest.
• A submission (synonyms: attempt, submit) is your separate attempt to submit a problem to the testing system; also the program that you submitted in this attempt.
• A penalty attempt (usually in the context of a summary rating) is an attempt that did not pass all the tests.
• The test is a separate test case prepared by the authors of the problem in order to test your programs on it. Usually, for each problem, the author of the problem prepares from 5 to 60 tests, and the programs that you submit for verification are checked in turn on all these tests. On our site, in order for the attempt to be considered successful, it is necessary that the program passes all the tests, i.e. it gives the correct answer to all the tests. (Other contests may have different rules.)