Mrrl

Решить задачу легко - заводите массив A[N,N], в каждой клетке [K,M] которого будет записано число лесенок из K кубиков, нижний слой которых состоит из M кубиков. Число будет ненулевым, когда M <= K <= M*(M+1)/2.
Массив заполняется начиная со строчки K=1 по формуле A[K,M]=sum(A[K-M,r],r=1..M-1). Сумма элементов в строчке K=N будет искомым числом.

В решении, ссылку на которое вы дали, последовательно вычисляется число лестниц из j кубиков, нижний ряд которых не длиннее, чем i кубиков. Чтобы найти это число, надо к уже найденным лестницам, нижний ряд которых не длиннее, чем i-1 кубик (их мы оставляем без изменения), прибавить лестницы из j-i кубиков с нижним рядом не длиннее, чем i-1 кубик (к ним мы добавим ряд из i кубиков). Что и делается во внутреннем цикле.

Надеюсь, что остаток берётся всё-таки от деления на 390, а не на 389 - иначе смысла в коде вообще не видно.
Итак, у нас есть 77 простых чисел, меньших 390. Четыре из них - 2,3,5,13 - не более, чем мусор, дающий лишние срабатывания алгоритма. В самом деле, если x%390==3, то x делится на 3, а значит, оно составное. Остальные 73 числа годятся.
Получается такая картина. Для простого x величина x%390 - некоторое число, взаимно простое с 390. Причём распределены эти остатки более-менее равномерно (на картинке они выглядят как красные столбики). Всего этих остатков 96.
Если x - простое число, то с вероятностью 73/96 остаток будет простым числом, и алгоритм честно скажет "скорее, простое". С вероятностью 23/96 - те самые 25% - остаток окажется составным, и алгоритм ошибётся.
Если x - составное, то вероятность того, что число объявят "скорее, простым" будет равна 77/390-1/ln(x) (первое слагаемое - вероятность того, что остаток оказался простым, а второе - доля простых чисел в окрестности x).
Можно легко избавиться от ошибки первого вида: для этого надо в массив charr положить не простые числа, а числа, взаимно простые с 390. Тогда если алгоритм скажет "составное", то так и есть.
Можно было вместо 390 взять N=30030=2*3*5*7*11*13. Если массив будет заполнен числами, взаимно простыми с N, то отсеиваться, как составные, будет 4 числа из 5, а ложных отсеиваний простых чисел не будет вообще.

Есть простое решение за (число сообществ)*(число связей "пользователь-сообщество").

Для каждого сообщества Y:
- заводим массив R[C], где C - число сообществ
- для каждого пользователя X из сообщества Y:
- - для каждого сообщества M, в которое входит пользователь X: R[M]=R[M]+1
- для каждого сообщества M: если M!=Y и R[M] > 1, то пара (Y,M) - ядро.

Быстрее пока не получается.

Зависит от проекции. Пусть широта точки равна u (измеряется в радианах, от -pi/2 до pi/2), а долгота v (от 0 до 2*pi).

Самая распространённая - равнопромежуточная цилиндрическая проекция. В ней карта имеет размер (2*pi) x pi, и координаты вычисляются как x=v, y=u+pi/2.

В проекции Меркатора ширина карты равна 2*pi, а высота может быть любой, вся планета всё равно не поместится. Допустим, высота равна 2*H, ширина - 2*pi. Тогда координаты будут x=v, y=ln(tan(u/2+pi/4))+H. Для некоторых точек (около полюсов) y выйдет за пределы диапазона (0,2*H), этих точек на карте не будет.

В равновеликой проекции Ламберта (сохраняющей площади) карта имеет размер (2*pi) x 2, и координаты вычисляются как x=v, y=sin(u)+1.

В равнопромежуточной азимутальной проекции (с центром в северном полюсе) карта умещается в квадрат со стороной 2*pi. x=pi+(pi/2-u)*cos(v), y=pi+(pi/2-u)*sin(v).

В центральной проекции (с центром в северном полюсе) на карте умещается только часть северного полушария. Допустим, карта - квадрат со стороной 2*M. Тогда x=M+ctg(u)*cos(v), y=M+ctg(u)*sin(v) (для u>0). Преимущество этой проекции - что кратчайшие пути между точками изображаются прямыми.

В стереографической проекции (с центром в северном полюсе) планета на карте тоже не поместится. Допустим, карта - квадрат со стороной 2*M. Тогда x=M+ctg(u/2+pi/4)*cos(v), y=M+ctg(u/2+pi/4)*sin(v)

Это первое, что пришло в голову (правда, три последних - не цилиндрические). А вообще, проекций (и алгоритмов) много. Вот краткий список (примерно 60 вариантов): https://en.wikipedia.org/wiki/List_of_map_projections

Если есть операция IndexOf для поиска элемента, то оптимальное число перестановок достигается так (превращаем L1 в L2):

for(int i=0;i < L1.Count;i++){
  while(L1[i]!=L2[i]){
     L1.swap(i,L2.IndexOf(L1[i]));
  }
}

При каждом обмене текущий элемент L1[i] ставится на то место, на котором он стоял бы в списке L2, и больше с этого места не уходит.

В общем, делается так.
Пусть фигура задана набором треугольных граней с известной ориентацией. В каждом ребре сходится чётное число граней (возможна, например, фигура из двух тетраэдров, склеенных по ребру), и при обходе любого ребра ориентации граней, сходящихся в нём, чередуются (например, идут грани ABC, BAD, ABE, BAF). Даже если в исходной модели таких странных рёбер нет, они могут возникнуть на промежуточном этапе.
Выбираем любые две грани со следующими свойствами:
- у них есть общее ребро AB;
- при обходе этого ребра они являются последовательными
- внутренний угол между этими гранями меньше 180 гр.
Такие грани найдутся всегда. Пусть это ABC и BAD.
Рассмотрим тетраэдр ABCD. Проверим, нет ли у него внутри других вершин. Если нет - заменим грани ABC и BAD на CAD и BCD (вырезав, тем самым, ABCD из модели). Если есть - возьмём ту вершину E из них, которая ближе всего к грани ABC, и заменим грань ABC на три грани ABE, AEC, EBC.
После этого просмотрим грани, и если оказалось, что какая-то грань встречается дважды с противоположными ориентациями (ABC и ACB) - выбрасываем обе копии.
Процесс повторяем, пока все грани не исчезнут.
Всё.

Я не уверен, можно ли решить эту задачу, если документ состоит из 97 девяток.
Ещё одна девятка будет в левом столбце таблицы. Какая-нибудь из цифр от 0 до 8 вряд ли встретится 9 раз. Так что девяток будет 98+ число девяток в последней клетке таблицы. Вот и получается:
Если в последней клетке 0 девяток, то в ней число 98+0=98
Если в ней одна девятка, то в ней 98+1=99
Если в ней две девятки, то в ней 98+2=100
Во всех случаях получаем противоречие.

UPD. Задача решается довольно просто.
Пусть у нас уже собрана статистика о числе разных цифр в теле документа (B[0] нулей, B[1] единиц...)
Сразу прибавим к этим числам по единичке, чтобы учесть левый столбик.
Оценим сверху число цифр в правой части таблицы. Например, как S=10*(log_10(B[0]+..+B[9])+2).
Каждая цифра в полном документе встретится не более B[n]+S раз, значит, в правой части таблицы для неё будет число, лежащее от D0[n]=B[n] до D1[n]=B[n]+S.
Прооптимизируем диапазоны D0..D1. Для этого для каждой цифры переберём все числа от D0[n] до D1[n], посмотрим количество разных цифр в каждом из этих чисел, возьмём минимальное и максимальное значение вхождений. Например, если D0[n]=997, D1[n]=1013, то в клетке, соответствующей n, 0,1 и 9 могут встретиться от 0 до 3 раз, а остальные цифры - 0 или 1 раз.
Просуммируем полученные диапазоны по всем n - получим новую таблицу диапазонов D0n,D1n. Пересечём их с D0,D1.
Есть 3 варианта.
Все полученные диапазоны совпали с D0..D1. Выходим из цикла.
Один из новых диапазонов пуст. В этой ветке решений нет, возвращаемся из функции.
Какой-то диапазон изменился. Продолжаем оптимизировать.

После того, как диапазоны стабилизировались, смотрим их длины. Если все они длины 1 (т.е. D0=D1), то мы нашли решение. Если нет - то берём самый короткий диапазон длины больше 1, перебираем все его значения D0[n]<=u<=D1[n], подставляем каждое из них в копию таблицы диапазонов (D0n[n]=D1[n]=u) и рекурсивно вызываем функцию оптимизации.
Перебор оказывается небольшим, вот примеры (ncall - число рекурсивных вызовов):

For 1 2 3 4 5 6 7 8 9 10
0->5 1->7 2->5 3->5 4->6 5->10 6->9 7->10 8->10 9->12
ncall=696

For 1 1 1 0 0 0 0 0 0 0
0->2 1->7 2->5 3->1 4->1 5->2 6->1 7->2 8->1 9->1
ncall=486

For 0 0 0 0 0 0 1 0 0 0
ncall=464

For 0 0 0 0 0 0 0 1 0 0
0->1 1->7 2->2 3->3 4->1 5->1 6->1 7->3 8->1 9->1
0->1 1->6 2->3 3->3 4->1 5->1 6->2 7->2 8->1 9->1
0->1 1->6 2->4 3->1 4->2 5->1 6->2 7->2 8->1 9->1
ncall=482

For 3997 19995 5677 998 799996 392 7 94 8998 99985
0->4014 1->20000 2->5679 3->1000 4->800001 5->394 6->10 7->96 8->9000 9->99994
0->4013 1->20001 2->5679 3->1001 4->800000 5->394 6->10 7->96 8->9000 9->99994
ncall=47356