Summary of common problems encountered

The following records some of the problems/errors encountered in the process of doing the questions, as well as some common skills and routines that I have summarized.
ps. This is only my subjective understanding. If there is anything wrong, please point it out, thank you w~!


Some questions (tao) skill (lu)

Think more.

  • The data range is large, greater than or equal to 10 9 At the time, the formula could not be found, and it was not a problem that Du Jiao Sizhou Ge Si could solve. Consider pressing the root / 1 3 sub-category.
  • Some problems of jumping a few steps and jumping a few steps are usually solved by a multiplication table if the step by step is too slow.
  • For some strange digital problems, if there are very few things to be recorded, it is likely to be solved directly by bfs violence. //of course it is also very likely to be digital dp //fog
  • Some problems of finding the kth smallest/largest are converted into binary + count the number of numbers smaller/larger than the answer.
  • For some cumulative multiplication problems, if the result is particularly large, the logarithm can be converted into addition.
  • For some topics related to the shortest path , it is generally necessary to transform the way of building edges , and then directly run the shortest path.
  • bitset : STL necessary for high-end bit-pressing cards. //The complexity can be /32, which feels particularly useful and has been encountered many times.
  • When I see [ the largest edge weight of two points in an undirected graph is the smallest ], I think of kruscal. If there is a counting problem involving edge weights in the question, consider calculating the contribution when adding an edge .
  • Inclusion and exclusion : To solve the number of elements for the union of several sets, the key is to find the number of "at least..." .
  • Divide and conquer : Consider the influence of the left on the right.
  • Blocking : Data structure questions can be considered.
  • The contribution of the set is related to the size of the set . A common idea is to divide the contribution of the set to each element .

Dangerous/biased mistakes

Some strange errors encountered during debugging/generally some have been tuned for a long time, or have not been encountered before, or are more important:

  1. In sqrt, be sure to convert Long double!!! Because if it is long long, it will explode after multiplying. The default in sqrt() is double. Or you can write the two points by hand. Example: arc094 D.
  2. Initialization of dp! so important! The initial value of 0,1 must be written! Example: cf960 F, the initial value of the longest ascending subsequence is 1. If I do not set it to 1, the extreme data is crossed out. I didn't think about it anyway during the exam.
  3. When asking for log, just keep num/2, don't write two points, it seems to be too slow. Example: cf960 D.
  4. Note that when factorial and factorial inverse element preprocessing, be sure to for to 0. Example: bzoj 1951; …too many.
  5. Since the custom cmax is defined like this: #define cmax(x,y) (y)>(x)?(y):(x), it is equivalent to y will be executed twice when y>x is satisfied. If y is a line segment tree qry function, it will be tle. This problem should be paid attention to in various places in the future. Example: hdu 5306.
  6. Passing a lot of parameters in a function seems to be slow. It is best not to pass parameters to some topics discussed in classification, just write a few more functions, it doesn’t matter if the code is longer (Fog. Example: bzoj 4695.
  7. When multiplying modulo, pay attention that if a factor is greater than the modulo, it must be dropped first, otherwise be careful to explode long long.
  8. When FFT preprocesses w[0/1][i], w[1][i] can be obtained by w[0][ni], ie w[1][i]=w[0][n-i](i=0 to n-1). Note that i starts from 0 and needs to be calculated in advance w[0][n]=(comp){1,0}. Example: cf958F3.
  9. The product comparison of large numbers can be converted into an addition comparison after taking the logarithm, but pay attention to the precision problem! If the number is very large, it must be handwritten with high precision. And, for high-precision comparison, pay attention to starting from the high position, that is, the loop should be written backwards.

Examination room matters needing attention

  1. Be sure to read the topic carefully! Don't make mistakes like 5000 being 1000. //Then I wrote it when I wrote part of the score, but if (n<=1000){....}it was still packaged for evaluation, so there was no violence score. gg.
  2. It is best to write violence and various parts namespacein (clearly), use violence to run small data, and judge and write down the parts that you think are more stable.
  3. Read the excellent (board) don't write about fried! ! ! Especially when the samples are very small, they are all single digits, and no problems can be found.
  4. ifAnd whiledon't write the opposite.
  5. On long longDon't forget, and for numbers greater than the modulus, take the modulo first.
  6. Think clearly about various initializations, and don't be vague. Check it out again.
  7. I really can't think of a serious solution, you can try... messing around randomly? Guess the conclusion? Worth a try.
  8. For data structure questions/questions with a slightly larger amount of code/more details, you must remember to match the shots. Even if it's a data structure that feels very stable, because that's just what I feel...
  9. When you come across a question that you are scared to do at first glance, calm down, try the least violent score, and some 10/20 special quality scores that may be written in the middle may be easier to get.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326009002&siteId=291194637