до того, как начнется подбираться rs — он участвует в вычислении err30, но значение rs в этот момент не зависит от того, какой окажется итоговая сумма.
Пропуск равных слагаемых уменьшит кол-во итераций, но никак не катастрофически.
В коде C++ есть стока
if (pow5[rs] == sum)
Т.е. rs используется для поиска e в уравнении a^5+b^5+c^5+d^5=e^5
Но без фиксации d не получится зафиксировать остаток mod30 для е, и наоборот — пока мы не знаем остаток mod30 для e — мы не знаем какой будет остаток mod30 для d. Мне кажется, что C++ код неправильно использует остаток mod30.
Что-то я не понял этот код. Они ссылаются на код С, но в С трюк mod-30 используется по другому — там перебирается четыре числа, и проверка 5-го происходит с фильтрацией по остатку mod 30.
А в коде C++ перебираются 3 числа (x0, x1, x2) и затем почему-то делается сдвиг x3 для коррекции остатка, хотя без фиксации пятого числа это не имеет смысла — какой бы остаток mod 30 не был у x3 — всегда найдется 5-я степень с таким же остатком mod 30, как и суммы x0^5+x1^5+x2^5+x3^5, без этой коррекции.
5-я степень по модулю 30 может иметь все возможные остатки — от 0 до 29 включительно. Проверкой по модулю 30 нельзя отсечь ни числа, не являющимися суммой двух пятых степеней (сумма двух пятых степеней может иметь любой остаток по модулю 30), так и ни отсечь одно из слагаемых этой суммы (например, большее число может иметь тоже любой остаток по модулю 30, независимо от значения остатка суммы).
Допустим, Вы рассматриваете число, потенциально являющееся суммой двух пятых степеней. Если Вы будете перебирать большее из чисел с шагом два (и проверять разницу на предмет того, является ли она пятой степенью), то можете пропустить решение.
Триллион кадров в секунду это уже не про одноразовый експеримент.
Там одно и то же явление повторяется много раз и делается снимок каждый раз с новой задержкой (относительно начала явления).
Собственно экспозиция занимает не все время работы пикселя матрицы — часть времени уходит на обнуление перед экспозицией, и на передачу данных после. Поэтому на один логический пиксель информация попадает с нескольких физических — пока один снимает, другой передает данные, а третий готовится к съемке.
Плюс сама экспозиция может длиться и дольше требуемых 1/1000000с, главное — иметь возможность запускать и останавливать её с такой точностью на разных физических пикселях, а дальше немного математики — и можно посчитать какая доля света пришла в какой интервал. Грубо говоря, если у нас есть кол-во света за интервал [0, 10] и [1,10] — то мы можем вычислить сколько света пришло в интервале [0,1], хотя экспозиции были 10 и 9 длительностей интервала соответственно.
При 1000 FPS очень большое значение играет скорость процессора — матрицы то давно умеют снимать данные с нужной скоростью, а вот закодировать — та ещё задача. Не редкость ситуация, когда при бОльшем разрешении видео реальная детализация хуже, чем при меньшем разрешении, т.к. проц не успевает все обработать.
Я пользуюсь K&R style, и часто после закрывающей скобки ставлю дополнительную пустую строку — мне так проще группировать код по функциональности. Отдельная открывающая скобка занимает столько же места, сколько пустая строка — и для меня выглядит, что if() стоит одинаково отдельно от кода, что ниже, и от кода, что выше, т.е. строка с if() как бы сама по себе. Дело привычки, наверное, но мне ломает встроенный парсер ).
В любом случае, отступы прекрасно помогают (опять же, лично для меня) выделять уровни кода, дополнительная строка с открывающей скобкой мне ни к чему от слова «вообще».
Не спорю. Мне просто не удалось сразу таких нагуглить
В Go Вы обязаны использовать camel style (K&R) — иначе код не скомпилируется вообще (компилятор считает, что каждая строка заканчивается ';', а компиляция конструкций вида if(..); {… } не предусмотрена). Многие из-за этого сильно ругают Go, кстати ;)
А мне кажется, что этот «стандартный шарповый стиль» получил распространение в компаниях, где платят за количество строчек кода, а не его лаконичность и выразительность.
А то 64 бита заканчиваются очень быстро.
Моё замечание касается вставки
до того, как начнется подбираться rs — он участвует в вычислении err30, но значение rs в этот момент не зависит от того, какой окажется итоговая сумма.
В коде C++ есть стока
Т.е. rs используется для поиска e в уравнении a^5+b^5+c^5+d^5=e^5
Но без фиксации d не получится зафиксировать остаток mod30 для е, и наоборот — пока мы не знаем остаток mod30 для e — мы не знаем какой будет остаток mod30 для d. Мне кажется, что C++ код неправильно использует остаток mod30.
А в коде C++ перебираются 3 числа (x0, x1, x2) и затем почему-то делается сдвиг x3 для коррекции остатка, хотя без фиксации пятого числа это не имеет смысла — какой бы остаток mod 30 не был у x3 — всегда найдется 5-я степень с таким же остатком mod 30, как и суммы x0^5+x1^5+x2^5+x3^5, без этой коррекции.
И в чем смысл этого rs, мне совсем не понятно.
Там одно и то же явление повторяется много раз и делается снимок каждый раз с новой задержкой (относительно начала явления).
И за какое же время Ваша программа находит все решения (кратные 144^5=...) для N <= 7131 (корень пятой из 2^64, т.е. все числа помещаются в uint64)?
Плюс сама экспозиция может длиться и дольше требуемых 1/1000000с, главное — иметь возможность запускать и останавливать её с такой точностью на разных физических пикселях, а дальше немного математики — и можно посчитать какая доля света пришла в какой интервал. Грубо говоря, если у нас есть кол-во света за интервал [0, 10] и [1,10] — то мы можем вычислить сколько света пришло в интервале [0,1], хотя экспозиции были 10 и 9 длительностей интервала соответственно.
В смысле, не дошли до следующих совпадений, таких как
54^5+168^5+220^5+266^5=288^5
?
В любом случае, отступы прекрасно помогают (опять же, лично для меня) выделять уровни кода, дополнительная строка с открывающей скобкой мне ни к чему от слова «вообще».
Больно видеть, как однотредовые приложения загибаются на сервере, при простаивающих десятках ядер.
Загляньте тогда на Project Euler )