Why does codeforces dislike real numbers so much? Obviously, problem 2020/E, like any other similar one, should be calculated in a real numbers. Well, or rational, but since the denominator is very large, we have to limit ourselves to real calculations. However, we should outut the answer in a very strange form. After all, nature deals with real numbers (length, mass), and not at all with discrete ones. We do not count the number of molecules of water in a cup; we will be completely satisfied with the answer accurate to the gram if we drink it ourselves, or up to one billionth of a gram, if we suddenly do a very precise physical experiment. So let's use quite natural real calculations in such probability problems. After all, we do not intersect circles in algebraic numbers, and we usually find even the point of intersection of straight lines in real, not rational form.

No comments. Only the results. Today I conducted a completely anonymous survey among students of a Russian university about their attitude to all these events. I used the following scale from 0 points — no war to 9 points — I support the special operation. The result is an average value of 3.4 for a sample of 47 students. Draw your own conclusions.

Может кто знает ответ на этот вопрос?

Во второй раз сталкиваюсь с тем, что при переполнении массива вместо RE получаю TL. Первый раз это было на совершенно другой тестирующей системе, тогда все это удалось быстро обнаружить, а сейчас — нет, из-за чего в целом правильное решение задачи 482B упало. Тогда мне так и не объяснили, в чем дело, может кто здесь подскажет. Тем более на Codeforces до этого все было совершенно адекватно — TL так TL, RE так RE.

Большая просьба-если это возможно, конечно, — передвинуть codeforces на несколько часов, чтобы не было наложения.

Столкнулся со следующей неприятной особенностью Delphi — долгое посимвольное прибавление к строке символов из другой строки. Решение на Delphi задачи C с последнего контеста получает Time Limit, а оно же на FPC без малейших изменений работает 0.7 сек. Кто пояснит, почему оно так?? Ранее сталкивался, что очень долго (почти в 10 раз дольше, чем в FPC) работает деление int64, как мне объяснили, из-за корявого переделывания деления с 32-битного на 64-битное. А здесь в чем дело??

Много раз пытался сдать 198B - прыжки по стенам. Вроде бы вполне осмысленное решение  -

• код ниже — получает RE на 12 тесте. Но это не самое интересное — я поглядел 12 тест и
  обнаружил, что на том же тесте с длиной прыжка 56465 все нормально, а при длине 56466 — уже RE. Но и это не все. Мистика (для меня) состоит в том, что при чистке кода я обнаружил, что при удалении ненужных (нигде не используемых) переменных это самое число 56465 изменяется на несколько сотен. Я, естественно, понимаю, что один дурак может задать столько вопросов, что тысяча мудрецов не ответит, но все же, может кто что подскажет... (Для меня это — третья по счету задача с использованием рекурсии, а может и не в рекурсии дело). Заранее благодарен за подсказку.

program pr1;

{$APPTYPE CONSOLE} var n,k,i,j:longint; t:array[0..1,0..1000000] of int64; flag:boolean; marked: array [0..1,0..1000000] of boolean; sss:array[0..1] of string;

procedure dfs(num,pl,shag:longint); var i,p:longint;

begin if shag<pl then begin marked[num,pl]:=true; inc(shag); t[num,pl]:=shag; if not marked[1-num,pl+k] and (sss[1-num,pl+k]='-')and(pl<=n) then dfs(1-num,pl+k,shag); if not marked[num,pl+1] and (sss[num,pl+1]='-')and(pl<n+k) then dfs(num,pl+1,shag); if not marked[num,pl-1] and (sss[num,pl-1]='-')and(pl>1) then dfs(num,pl-1,shag); end;

end;

begin {assign (input,'input.txt');reset(input); assign (output,'output.txt'); rewrite(output); } readln(n,k); readln(sss[0]);readln(sss[1]); for i:=1 to 100000 do sss[0]:=sss[0]+'-'; for i:=1 to 100000 do sss[1]:=sss[1]+'-'; for i:=0 to n+k do begin t[0,i]:=1000000; t[1,i]:=1000000; end; t[0,1]:=0; dfs(0,1,0); flag:=false; for i:=n+1 to n+k do if (t[1,i]<1000000) or (t[0,i]<1000000) then begin flag:=true; end; if flag then write('YES') else write('NO'); close(output); end.