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 порядка дольше.
Idwln, я говорю не о сумме всех неизбыточных. А просто о простых числах. Вот меня интересует этот шаг.
Давай сверим часы. У меня была старая функция котора считает что-то на интервале. Вот от 2 до 28123 у меня 3069 простых чисел. А от двух до 2_000_000 я нашел 148934 простых. Проверь пожалуйста. Заодно и я себя проверю. Вдруг ошибся.
. Окно. Форточка. Как будет угодно. В данном случае
эта метафора тоже лежит вне плоскости языка Си. И мы читая глазами код не может точно сказать окно тут или не окно. В противоположность в SQL есть коробочные окнонные функции которые если есть то уж точно есть.
Wataru, да согласен. Но в некой "итераторной" постановке нам нужно будет просто видеть текущий элемент и предыдущий. А никаких индексов нет. Впрочем это я фантазирую. Можно забить на это.
Тут - аккурано нужно. При массовом скачивании у нас есть 2 простые стратегии. Первое - качать линки строго последовательно. Но при этом какая-то недоступная линка будет надолго блокировать всю очередь. Второе - качать все параллельно но при этом надо помнить об ограничениях на сокеты и количество процессов в linux. Вобщем обе простые стратегии - плохие. В более гибком варианте - нам нужен пул процессов закачки но мне кажется что это выходит за рамки grep + wget и надо звать в топик программиста чтоб написал нормальное приложение с пулом.
Если у тебя что-то где-то не рисует - то нужен анализ где чего не рисует. Любой алгоритм содержит утверждения. Например то что цикл прошелся по всему диапазону. Или то что при таких-то данных - что-то частично все таки работает.
Если ты говоришь что ничего не рисует - это звучит как "я маленький мальчик и ничего не знаю". Постарайся такого не говорить а докладывать хотя-бы о частичных успехах в habr.