Да, как мне кажется, преобразование Фурье, по 2D массиву высот, может дать интересный результат. Может быть даже удастся, как то связать спектральную плотность с необходимыми параметрами аналитически, или использовать ее для более простых статистических методов.
Знакомо, у меня тоже ухудшилась память с возрастом, возможно не так сильно. Лайфхаки: записная книжка на телефоне, и распечатанные куски кода с пометками.
Да, и? Для краевого значения будет всегда истина, но обычно это константа или переменная, код для которой пишется в общем виде. Вопрос, в том какого типа должна быть NUM если это константа, и если это переменная. А то так, даже банальный цикл while (i < NUM) работать не будет, без расширения в более длинные типы, которых нативно может и не быть.
Странный аргумент, против -1, для 64 битных чисел, если ssize_t должно хватить всем. А вот то,что из-за граничных случаев, компилятор не может лучше оптимизировать код, такое вполне себе случается.
У использования нуля и адресации с единицы появляется противоположная сторона, заключающаяся в том, что INT_SIZE_MAX - 1 перестают быть представимыми в рамках заданного "бинарного" типа. В результате абстракции все равно текут.
Еще интересный случай это работа с граничными значениями. Если сравнивать границы для байтов, то можно написать i <= NUM при этом NUM тоже будет байтом, если прибавить единичку это все сломается.
Мешает. Этот синтаксис работает, только для массивов с известной размерностью на момент компиляции. Каким образом это должно работать с динамической размерностью? (хинт: на этапе компиляции вы не знаете размерности, чтобы вычислить индекс элемента)
Нет их там и никогда не было, нативные окошки по ссылке это совсем под другое. По сути Qt это просто "рисовалка", ей нужен лишь достаточный механизм, чтобы нарисовать собственный растр в окошке и обработать ввод.
На самом деле сисколы в линуксе обратно совместимы, поэтому если заморочится только на системных вызовах, или статически слинковать libc, то почему бы и нет...
Для типичного кейса разработчика(один раз собрал, исправил или подтянул изменения из гита), инкрементальная сборка почти всегда будет быстрой. У меня был проект, который собирался полностью за 2 часа на 12 ядернике и M.2 SSD, и инкрементально за пару минут, но там был ninja.
Да, как мне кажется, преобразование Фурье, по 2D массиву высот, может дать интересный результат. Может быть даже удастся, как то связать спектральную плотность с необходимыми параметрами аналитически, или использовать ее для более простых статистических методов.
Знакомо, у меня тоже ухудшилась память с возрастом, возможно не так сильно. Лайфхаки: записная книжка на телефоне, и распечатанные куски кода с пометками.
Да, и? Для краевого значения будет всегда истина, но обычно это константа или переменная, код для которой пишется в общем виде. Вопрос, в том какого типа должна быть NUM если это константа, и если это переменная. А то так, даже банальный цикл while (i < NUM) работать не будет, без расширения в более длинные типы, которых нативно может и не быть.
Странный аргумент, против -1, для 64 битных чисел, если ssize_t должно хватить всем. А вот то,что из-за граничных случаев, компилятор не может лучше оптимизировать код, такое вполне себе случается.
У использования нуля и адресации с единицы появляется противоположная сторона, заключающаяся в том, что INT_SIZE_MAX - 1 перестают быть представимыми в рамках заданного "бинарного" типа. В результате абстракции все равно текут.
Еще интересный случай это работа с граничными значениями. Если сравнивать границы для байтов, то можно написать i <= NUM при этом NUM тоже будет байтом, если прибавить единичку это все сломается.
Мешает. Этот синтаксис работает, только для массивов с известной размерностью на момент компиляции. Каким образом это должно работать с динамической размерностью? (хинт: на этапе компиляции вы не знаете размерности, чтобы вычислить индекс элемента)
В C нет из коробки многомерных динамических массивов, те же матрицы произвольной размерности надо эмулировать через одномерные массивы.
В тех же плюсах сделать массивы с произвольными диапазонами(аналог array), совсем не проблема, просто это особо не кому не нужно.
Только тогда компилятор покупался раз и навсегда, да и gcc, уже в начале нулевых появился в достаточно адекватном виде.
PS: хотя при отсутствии свободных альтернатив, к чему могла бы привести фантазия майкрософта тоже вопрос.
Там надо не количество вызовов рандома оптимизировать, а сходимость у данного метода, которая достаточно паршивая и пропорциональна sqrt(n).
PS: https://en.wikipedia.org/wiki/Quasi-Monte_Carlo_method
Как раз ISA(система команд) вполне подлежит лицензированию, и чтобы делать процессоры с ARM ISA, необходима лицензия(архитектурная).
Думаете у программиста ABAP с этим проще?
Может быть я, что-то не понимаю, но по ссылке из виджетов, есть только нативный тулбар.
Нет их там и никогда не было, нативные окошки по ссылке это совсем под другое. По сути Qt это просто "рисовалка", ей нужен лишь достаточный механизм, чтобы нарисовать собственный растр в окошке и обработать ввод.
Сейчас меня закидают, но tar умеет в блэклисты и дергать по крону.
Qt идет с исходным кодом, можно делать коммерческую разработку под LGPL. Qt это огромный фреймворк-комбайн сопоставимый по функционалу с .NET
На самом деле сисколы в линуксе обратно совместимы, поэтому если заморочится только на системных вызовах, или статически слинковать libc, то почему бы и нет...
Для типичного кейса разработчика(один раз собрал, исправил или подтянул изменения из гита), инкрементальная сборка почти всегда будет быстрой. У меня был проект, который собирался полностью за 2 часа на 12 ядернике и M.2 SSD, и инкрементально за пару минут, но там был ninja.
Эм, ну убить инкрементальную сборку, так себе вариант. И подозреваю, что проблема ни только в количестве файлов, но и количестве строк кода.