January 2019

M T W T F S S
 123456
78 910111213
14 151617181920
21222324252627
28293031   

За стиль благодарить

Развернуть метки

No cut tags
Wednesday, November 28th, 2007 01:57 pm
Задачу см. http://taki-net.livejournal.com/335594.html

Правильный ответ на первый вопрос дали почти все в разных вариациях: надо заранее посчитать любым способом (можно очень долго) простые числа до миллиона, вывести в файл, потом включить этот файл в программу в качестве начальных значений элементов массива (их около 72000), дальше организовать просмотр этого массива (хоть двоичным поиском, хоть линейно) и посчитать количество элементов этого массива, больших k и меньших n (он при этом даже не обязан быть сортированным). Вторая программа (с заранее созданным массивом) и была сдана. Кодится (не для любого компилятора) также такое решение: заранее посчитать массив от 1 до 1000000, в котором на i-м месте лежит кол-во простих чисел, меньших i. Программа состоит из одной строчки - вычитания из n-го эл-та массива k-го.

На второй вопрос - ответ под катом.

Жюри подразумевало, что участники должны реализовать решето Эратосфена "честно", не путем деления на все вообще числа меньшие корня (т.е. 1000) - это дает миллиард операций, а у нас в запасе только 200000000, и деление - дорогая операция, а путем правильно сделанного прореживания массива - удаления элементов, кратных простым числам, меньшим тысячи.

Другое возможное решение - тупым псевдоэратосфеном (деление на все до корня из верхней границы) найти все простые до 1000 - это 32000 делений и потом 1000 присваиваний, потом также тупо найти все простые до 1000000 - это около 145 млн. делений и миллион присваиваний потом. Но тут все уже зависит от "цены" деления. Может и не хватить времени.
Wednesday, November 28th, 2007 12:20 pm (UTC)
Хм. Мое решение не принято?

Среди чисел, меньших m, каждое второе делится на два, каждое третье - на три, каждое четвертое - на четыре и так далее.

Следовательно, количество непростых чисел, меньших m, равно:

SUM(m%2 + m%3 + m%4 + ... + m%int(sqrt(m)))

Неоптимальный метод требует двух вычислений частных сумм, оптимальный - одного. В любом случае, вичисление требует не более, чем 2*sqrt(10"6) - 2000 итераций.
Wednesday, November 28th, 2007 12:32 pm (UTC)
Неоптимальный алгоритм

int count(int val)
{
   int retval = val;
   dlim = int(sqrt(val));

   for (d=2; d<dlim; d++)
      retval -= val % d;

   return retval;
}

int main()
{
   k = lolim;
   n = hilim;

   printf("%d\n", count(n) - count(k));
}
Wednesday, November 28th, 2007 12:42 pm (UTC)
А как быть с числом 60? Оно ведь будет посчитано и среди делящихся на 2 и среди делящихся на 3, и на 4, и на 5, и на 6.
Wednesday, November 28th, 2007 08:09 pm (UTC)
Вообще говоря, идею можно допилить до работоспособного состояния. Если посчитан набор простых чисел от 2 до sqrt(N) P[1..k], то количество простых чисел от 1 до N можно вычислить и так:

N + k
- N/P[1] - N/P[2] - N/P[3] - N/P[4] - ...
+ N/(P[1]*P[2]) + N/(P[1]*P[3]) + N/(P[2]*P[3]) + ...
- N/(P[1]*P[2]*P[3]) - N/(P[1]*P[2]*P[4]) - ...

То есть надо взять все наборы из P[1..k], поделить нацело N на произведение чисел набора и результат отнять от N + k (если множителей в наборе нечетное количество) или прибавить (если четное). (Лишнее k взялось оттого, что N/P[i] - это количество всех чисел, делящихся на P[i], включая само P[i].)

Звучит на первый взгляд ужасно - наборов 2^k штук; но спасает возможность не рассматривать наборы с произведением, большим N. Это позволяет довольно хорошо обстричь рекурсию, и реальное количество делений будет не таким большим - для N = 10^6 я намерил 153192 деления, при том что честное решето дает 2197837 вычеркиваний. Правда, на Питоне решето все равно по скорости оказалось быстрее в полтора раза :-).