Вход на сайт
Поиск простого числа
08.11.06 07:54
Задача: найти простое число по его порядковому номеру в последовательности простых чисел, вот такая прога. Не хочет работать. Пожалуйста, тыкните в ошибку!
program prostoe;
const n=30000;
var
a:array[1..n] of integer;
chs:integer;
sum,num,i,b:integer;
function prov (c:integer):boolean;
var s:byte;
del:integer;
begin
s:=0;
for del:=2 to c do
begin
if c mod del=0 then inc(s);
if s<>0 then break;
end;
if s=0 then prov:=true;
end;
begin
readln(chs);
num:=1;
for b:=1 to chs do
begin
if prov(num)=true then a:=num;
inc(num);
end;
readln;
end.
Проблема в том, что массив при пошаговой проверке не заполняется, только первый элемент становится равным единице и все.
program prostoe;
const n=30000;
var
a:array[1..n] of integer;
chs:integer;
sum,num,i,b:integer;
function prov (c:integer):boolean;
var s:byte;
del:integer;
begin
s:=0;
for del:=2 to c do
begin
if c mod del=0 then inc(s);
if s<>0 then break;
end;
if s=0 then prov:=true;
end;
begin
readln(chs);
num:=1;
for b:=1 to chs do
begin
if prov(num)=true then a:=num;
inc(num);
end;
readln;
end.
Проблема в том, что массив при пошаговой проверке не заполняется, только первый элемент становится равным единице и все.
NEW 08.11.06 10:16
[Недоброжелатель сказал бы, что ошибка -- в днк прокладки:). Шутка:). Ничего личного:).] Пардон. Вычеркнуто после просмотра профиля спрашивавшего
А по сути -- алгоритм выбран странный, далёкий от оптимального. Перефразируя условие задачи -- нужно искать простые числа одно за другим, 1, 2, 3, 5, ... до тех пор, пока счётчик текущего найденного простого числа не сравняется с наперёд заданным значением, и это самое текущее простое число и будет ответом. "Шагать" по ряду натуральных чисел нужно с шагом 2 (чётные числа простыми не бывают), а для проверки на простоту -- делить только на уже найденные простые числа. Вот и вся любовь:).
В ответ на:
Пожалуйста, тыкните в ошибку!
Пожалуйста, тыкните в ошибку!
[Недоброжелатель сказал бы, что ошибка -- в днк прокладки:). Шутка:). Ничего личного:).] Пардон. Вычеркнуто после просмотра профиля спрашивавшего
А по сути -- алгоритм выбран странный, далёкий от оптимального. Перефразируя условие задачи -- нужно искать простые числа одно за другим, 1, 2, 3, 5, ... до тех пор, пока счётчик текущего найденного простого числа не сравняется с наперёд заданным значением, и это самое текущее простое число и будет ответом. "Шагать" по ряду натуральных чисел нужно с шагом 2 (чётные числа простыми не бывают), а для проверки на простоту -- делить только на уже найденные простые числа. Вот и вся любовь:).
NEW 08.11.06 10:29
в ответ scorpi_ 08.11.06 10:22
Думать здесь надо в первую очередь над алгоритмом.
------
Думать там надо ой как много над чем - над использоваными индентификаторами, над стилем написания, над алгоритмом, над реализацией алгоритма с точки зрения использования памяти, над... тем, об чем писал бармаглот...
Но все эти думания не дадут ответа на заданный вопрос.
------
Думать там надо ой как много над чем - над использоваными индентификаторами, над стилем написания, над алгоритмом, над реализацией алгоритма с точки зрения использования памяти, над... тем, об чем писал бармаглот...
Но все эти думания не дадут ответа на заданный вопрос.

NEW 08.11.06 10:36
в ответ Murr 08.11.06 10:30
О да! Только задолбаться можно, следя за текущим счётчиком-вычёркивателем:).
Кроме того, мальчегу нужны "первые сто простых чисел", а не "простые числа из интервала от одного до ста", а значит априори сходу и не скажешь, до какого числа решетить. ИМХО "мой" алгоритм оптимален с точки зрения затрат на "думание". Ах да, делить конечно можно не на все найденные, а только на те, которые .LE. SQRT (iCurrCounter).
Кроме того, мальчегу нужны "первые сто простых чисел", а не "простые числа из интервала от одного до ста", а значит априори сходу и не скажешь, до какого числа решетить. ИМХО "мой" алгоритм оптимален с точки зрения затрат на "думание". Ах да, делить конечно можно не на все найденные, а только на те, которые .LE. SQRT (iCurrCounter).
NEW 08.11.06 10:47
в ответ Murr 08.11.06 10:40
Хи. Спорю на ящик пива, что для чисел, которые влезаютЪ в интеджер, 4 порядка -- гон. Это первоЕ.
Также прошу представить достоверный метод априорной оценки "длины" решета для наперёд заданного номера простого числа. Это второЕ.
Ну что, "Гиннес" против "Францисканера" :) ?
Также прошу представить достоверный метод априорной оценки "длины" решета для наперёд заданного номера простого числа. Это второЕ.
Ну что, "Гиннес" против "Францисканера" :) ?
NEW 08.11.06 10:58
Также прошу представить достоверный метод априорной оценки "длины" решета для наперёд заданного номера простого числа.
http://de.wikipedia.org/wiki/Primzahlsatz/
http://de.wikipedia.org/wiki/Primzahlsatz/
NEW 08.11.06 12:04
в ответ Murr 08.11.06 11:02
Ну что ж, из уважения к Вашим сединам
сыграю один раз по чужим правилам:).
Я писал о числах, влезающих в интеджер, т. е. до порядка 32 тысяч. В интервале 1..32000 лежит около 2500 простых. Таким образом, если оценивать сверху размером типа, при реализации решета вычеркнуть прийдётся где-то 29500 чисел.
Если, как я предложил, каждое нечётное делить на все простые, которые меньше квадратного корня из него, то делений прийдётся сделать не более чем 16000 умножить на количество простых, которые не превосходят корень из 32000 (это количество -- 41, но на самом деле результат будет меньше, это оценка сверху).
IDL> print, 1.6e4*41.
656000.
Теперь положим, что одно деление жрёт ресурса как 20 сложений, и поделим на заявленные четыре порядка::
IDL> print, 20.*1.6e4*41./1e4
1312.00
Итого:: если бы песня про четыре порядка была правильной, то решето в этом случае потребовало бы меньше, чем 1312 вычёркиваний.
Вердикт:: для типа интеджер четыре порядка -- гон, что и требовалось доказать. Гиннес прошу высылать в Мюнхен
. С моей стороны спор окончен.

Я писал о числах, влезающих в интеджер, т. е. до порядка 32 тысяч. В интервале 1..32000 лежит около 2500 простых. Таким образом, если оценивать сверху размером типа, при реализации решета вычеркнуть прийдётся где-то 29500 чисел.
Если, как я предложил, каждое нечётное делить на все простые, которые меньше квадратного корня из него, то делений прийдётся сделать не более чем 16000 умножить на количество простых, которые не превосходят корень из 32000 (это количество -- 41, но на самом деле результат будет меньше, это оценка сверху).
IDL> print, 1.6e4*41.
656000.
Теперь положим, что одно деление жрёт ресурса как 20 сложений, и поделим на заявленные четыре порядка::
IDL> print, 20.*1.6e4*41./1e4
1312.00
Итого:: если бы песня про четыре порядка была правильной, то решето в этом случае потребовало бы меньше, чем 1312 вычёркиваний.
Вердикт:: для типа интеджер четыре порядка -- гон, что и требовалось доказать. Гиннес прошу высылать в Мюнхен

NEW 08.11.06 12:21
в ответ barmaglot 08.11.06 12:04
Теперь положим, что
------
Там, при делении, примерно 350 тактов, против 16 при сложении. Но, там не только деление...
Ну а вычеркивание (рассылка) - одна машинная команда, плюс еще три на подготовку следующей...
Видишь ли, во времена первого пня я прогнал оба варианта, предварительно оптимизировав их до предела...
------
Там, при делении, примерно 350 тактов, против 16 при сложении. Но, там не только деление...
Ну а вычеркивание (рассылка) - одна машинная команда, плюс еще три на подготовку следующей...
Видишь ли, во времена первого пня я прогнал оба варианта, предварительно оптимизировав их до предела...

NEW 08.11.06 12:49
в ответ barmaglot 08.11.06 12:27
Фактор четыре...
------
Ну хорошо.
Требование - найти простые числа в пределах... ну скажем... хммм... 2^82
Пиши оба варианта. Оптимизируй. Выставляй на общее обозрение для убивания неэффективностей... результаты - сравним, оценим, так сказать, фактор...
P.S. 2^82 дано с учем того, что какой-то из компайлеров поддерживает тип 2^80
------
Ну хорошо.
Требование - найти простые числа в пределах... ну скажем... хммм... 2^82

Пиши оба варианта. Оптимизируй. Выставляй на общее обозрение для убивания неэффективностей... результаты - сравним, оценим, так сказать, фактор...

P.S. 2^82 дано с учем того, что какой-то из компайлеров поддерживает тип 2^80

NEW 08.11.06 12:50
в ответ Murr 08.11.06 09:57
Отправитель: Murr
Заголовок: Re: Поиск простого числа
if prov(num)=true then a:=num;
-----
??? - что такое 'a' в этом контексте?
опечатка, там должно стоять a
мне пока не до идеальности алгоритма, хочу добиться чтобы он работал
я программированием занимаюсь с гулькин нос, так что не ругайте сильно
Заголовок: Re: Поиск простого числа
if prov(num)=true then a:=num;
-----
??? - что такое 'a' в этом контексте?
опечатка, там должно стоять a
мне пока не до идеальности алгоритма, хочу добиться чтобы он работал
я программированием занимаюсь с гулькин нос, так что не ругайте сильно
NEW 08.11.06 13:04
в ответ Murr 08.11.06 12:59
Код не требуется, была приведена оценка количества операций сверху.
Считаю Вас неблагородным человеком, не умеющим держать слово и от дальнейшей полемики отказываюсь. Ящик пива "Гиннес", который Вы мне проиграли, дарю любому из участников этого форума, который сможет его из Вас выдоить
.
Считаю Вас неблагородным человеком, не умеющим держать слово и от дальнейшей полемики отказываюсь. Ящик пива "Гиннес", который Вы мне проиграли, дарю любому из участников этого форума, который сможет его из Вас выдоить

NEW 08.11.06 13:17
в ответ barmaglot 08.11.06 13:04
Код не требуется, была приведена оценка количества операций сверху.
-----
на первом пне, для 32-битных целых, де факто, время счета при помощи деления - более двух месяцев, а Решетом - менее пяти дней... разница таки более трех порядков... хотя и двоичных...
P.S. Если не сложно - где именно было принято пари? Бо, в заведомо выигрышных(проигрышных) ситуациях Я не спорю...
-----
на первом пне, для 32-битных целых, де факто, время счета при помощи деления - более двух месяцев, а Решетом - менее пяти дней... разница таки более трех порядков... хотя и двоичных...

P.S. Если не сложно - где именно было принято пари? Бо, в заведомо выигрышных(проигрышных) ситуациях Я не спорю...

NEW 08.11.06 17:55
Каким образом? Мы генерируем простые числа начиная с трёх...
Вот собственно -
Вот собственно -
В ответ на:
#include <iostream>
#include <vector>
#include <ctime>
const unsigned long MAX_PRIME = 0x19999998;
unsigned long get_prime_by_sieve( unsigned long number )
{
if ( number == 1 )
return 2;
std::vector<bool> sieve = std::vector<bool>( number * 10, 0 );
unsigned long i = 0;
size_t sieve_size = 2 * sieve.size();
for( unsigned long counter = 1; counter < number; ++counter )
{
while( sieve[ ++i ] );
unsigned int np = 2 * i + 1;
for( unsigned long j = np * np; j < sieve_size; j += np )
if ( j & 1 )
sieve[ j >> 1 ] = true;
}
return 2 * i + 1;
}
unsigned long get_prime_by_barmaglot( unsigned long number )
{
if ( number == 1 )
return 2;
std::vector<unsigned long> found_primes( 1, 2 );
found_primes.reserve( number * 10 );
unsigned long i = 3;
for( unsigned long counter = 1; counter < number; i += 2 )
{
unsigned long j = 0;
for( ; j < found_primes.size(); ++j )
if ( i % found_primes[j] == 0 )
break;
if ( j == found_primes.size() )
{
found_primes.push_back( i );
++counter;
}
}
return i - 2;
}
int main()
{
std::cout << "Berechnung der millionsten Primzahl" << std::endl;
clock_t start = clock();
unsigned long prime = get_prime_by_sieve( 1000000 );
double elapsed = (double)( clock() - start ) / CLOCKS_PER_SEC;
std::cout << "Sieve, Primzahl: " << prime << " time elapsed: " << elapsed << std::endl;
start = clock();
prime = get_prime_by_barmaglot( 1000000 );
elapsed = (double)( clock() - start ) / CLOCKS_PER_SEC;
std::cout << "Barmaglot, Primzahl: " << prime << " time elapsed: " << elapsed << std::endl;
}
NEW 08.11.06 18:04
Итого:: если бы песня про четыре порядка была правильной, то решето в этом случае потребовало бы меньше, чем 1312 вычёркиваний.
Гыыыыы, извини, ты о теории сложности хоть какое-нибудь представление имеешь? Решето это O(n*log n), а твой алгоритм O(n^2), поэтому коэффициенты (которые весьма не в твою пользу, ибо в решете сплошь однотактовые операции, а у тебя дорогостоящее деление) считать излишне.
PS Сорри, не заметил ограничения по корням. Тогда O(n^1.5) - всё равно хуже чем O(n*log n).
PPS Я писал о числах, влезающих в интеджер, т. е. до порядка 32 тысяч. - всё ещё на 8086 сидишь?
Бедненьий... У меня так интеджер 64-битовый
Гыыыыы, извини, ты о теории сложности хоть какое-нибудь представление имеешь? Решето это O(n*log n), а твой алгоритм O(n^2), поэтому коэффициенты (которые весьма не в твою пользу, ибо в решете сплошь однотактовые операции, а у тебя дорогостоящее деление) считать излишне.
PS Сорри, не заметил ограничения по корням. Тогда O(n^1.5) - всё равно хуже чем O(n*log n).
PPS Я писал о числах, влезающих в интеджер, т. е. до порядка 32 тысяч. - всё ещё на 8086 сидишь?


NEW 08.11.06 18:22
в ответ scorpi_ 08.11.06 17:55
Каким образом?
-----
За счет префиксного декремента, устанавливающего флаг равенства нулю. Правда для того, чтобы оценка (0.10) была верной там должен быть только развернутый код.
Вместо:
for( unsigned long counter = 1; counter < number; ++counter )
for( unsigned long counter = number; --counter; /* no */ )
И так же со вторым циклом.
-----
За счет префиксного декремента, устанавливающего флаг равенства нулю. Правда для того, чтобы оценка (0.10) была верной там должен быть только развернутый код.
Вместо:
for( unsigned long counter = 1; counter < number; ++counter )
for( unsigned long counter = number; --counter; /* no */ )
И так же со вторым циклом.
NEW 08.11.06 19:40
А, я его постинга сразу не заметил... Тогда да, О(n^1,5), первоначальный вариант кстати был конечно же О(n^2), а не в куб.
Короче вот -
Даёт ответ за 15сек, против 0.85 для решета (number =1000000)
Короче вот -
В ответ на:
unsigned long get_prime_by_barmaglot( unsigned long number )
{
if ( number == 1 )
return 2;
std::vector<unsigned long> found_primes( 1, 2 );
found_primes.reserve( number );
unsigned long i = 3;
for( unsigned long counter = number - 1; counter; i += 2 )
{
for( unsigned long j = 0; j < found_primes.size(); ++j )
if ( i < found_primes[j] * found_primes[j] || i % found_primes[j] == 0 )
break;
found_primes.push_back( i );
--counter;
}
return i - 2;
}
Даёт ответ за 15сек, против 0.85 для решета (number =1000000)
NEW 09.11.06 09:54
в ответ scorpi_ 08.11.06 18:04
Лень мне вникать во всё написанное. Ты опроверг утверждение про четыре порядка для простых до 32 тысяч? Если вдруг да (весьма сомнительно
) -- вечером как будет время напишу и проверю сам.
Что касается
то "сижу" я на таком (http://www.rzg.mpg.de/computing/IBM_P5/hardware.html), от чего знающему человеку впору захлебнуться слюнями
.

Что касается
В ответ на:
всё ещё на 8086 сидишь? Бедненьий...
всё ещё на 8086 сидишь? Бедненьий...
то "сижу" я на таком (http://www.rzg.mpg.de/computing/IBM_P5/hardware.html), от чего знающему человеку впору захлебнуться слюнями

