Wataru, в диапазоне от 900 млн до мильярда находится примерно 4.5 миллиона простых.
Ну не знаю. Я-бы сделал бенчмарк. Тут по сути идет трейдофф. Так или иначе нам нужен
список простых делителей. А когда он ну нас есть - упрощается проверка последовательности.
Четные. И тройки можно учесть в цикле. Тоесть мы можем двигаться более длинными прыжками
чем просто последовательность. В этом смысле наивный брутфорс - более прост т.к. ничего в алгоритме
менять не надо. Мы просто его продолжаем. Для решета - нужно аллоцировать память.
Wataru, в этом случае - зачем вам решето? У вас есть коллекция простых. Проверяйте каждого кандидата на делимость. Тем болеее что найденых уже 90% и осталось "добить чутка".
Скорее всего это невозможно. Решето - это континуум. И чтобы продолжить с 900 миллинов до мильярда - тебе нужно предыдущее состояние этой системы а именно сведения о всех невычеркнутых числах от 2 до 9000.
Slavon7, найди книгу Шикин и Боресков - Комьютерная Графика образца где-то 90х годов. Она подробно описывала алгоритм и реализацию.
Если у тебя что-то где-то не рисует - то нужен анализ где чего не рисует. Любой алгоритм содержит утверждения. Например то что цикл прошелся по всему диапазону. Или то что при таких-то данных - что-то частично все таки работает.
Если ты говоришь что ничего не рисует - это звучит как "я маленький мальчик и ничего не знаю". Постарайся такого не говорить а докладывать хотя-бы о частичных успехах в habr.
Насколько я понимаю юзкейс Go-Lang не связан с интенсивными вычислениям. Все-таки язык создавался Google для обслуживание микро-сервисных задач. А это на 80% - Network/IO. О рендеринге графики или о транс-вычислительных задачах речи нет. А автор шутки ради зарядил возведение в степень и квадратный корень для длинных целых. Это - чистой воды троллинг Go-архитектуры.
for (size_t i = 0; i < N; ++i)
{
words[i].a = value + 1;
words[i].b = value + 2;
}
for (size_t i = 0; i < N; ++i)
halfs[i].c = value + 3;
halfs[i].d = value + 4;
}
Наверное имеет смысл всё писать на jq или JsonPath и только когда их возможностей не хватает - подключать языки разработки. Тут - такой же смысл как в регулярках. Берем краткий вариант описания логики пока этот краткий вариант работает и всем понятен.
Вот то, что printf долгая операция, спасибо, понял.
Это сильно зависит от ЯП и API. Но беда в том что если печать идет на живой экран - функция может
блокироваться и ждать скролла. Это уже не микро-секунды а милисекунды. На 3 порядка дольше.
Стадион - так стадион.