Да в общем-то в классической механике мы их явно обычно и не задаём. В лучшем случае складываем кинетическую + потенциальную. Кажется в рамках ОТО иметь массу и скорость не возбраняется, так что не очень понимаю как его может не существовать как инварианта. Разные инерциальные системы вроде не заставляют их терять/добавлять энергию ни в рамках своей СО ни в СО наблюдателя. Подсчёт общей энергии осложняется, да, но потерять/добавить энергию вроде тоже не получится.
что введение подобной глобальной функции энергии вопрос не решенный
Как и вопрос конечности нашей вселенной или её настоящей топологии. И наличия состояния истинного вакуума. В этом смысле закон сохранения и является некоторой выбранной аксиомой, которую удобнее всего взять за истину, т.к. это ближе всего к тому что мы наблюдаем - пусть и с локальными искажениями. Мы можем помоделировать альтернативы, но для построения модели наблюдаемой вселенной оно вроде не слишком помогает.
Насчет же рождения энергии из "ничего", то в ОТО он решается тем, что гравитационная потенциальная энергия вообще-то отрицательная, так как гравитация есть сила притяжения.
Не до конца понимаю о чем речь. То есть если мы возьмём неизлучающую массу, то вместе с гравитацией общая энергия системы останется нулевой - "ничем", потому что гравитация будет компенсировать потенциальную энергию этой массы? В таком случае получаем всё то же постоянное количество энергии в глобальном масштабе и кучку флуктуаций в локальном. Энергия в такой системе из ниоткуда не возьмётся и масса не начнёт внезапно излучать или наоборот создавать энергетическую дырку.
Закон сохранения энергии принято считать аксиомой и вроде пока нет никаких причин, почему это не должно быть так. В противном случае известные нам законы термодинамики ломались бы и мы вероятно могли бы как-то пронаблюдать это нарушение. Пока никакие наблюдательные данные не показывают нарушений с законом сохранения.
Единственная проблема с этим - первые моменты до большого взрыва, которые приводят к бесконечным значениям плотности энергии/массы из-за бесконечно малого пространства, в котором была сконцентрирована конечная энергия-масса.
Ну и оценки количества энергии могут разниться, потому что мы не знаем полное состояние видимой и невидимой вселенной.
Подозреваю, что в этом случае можно реализовать алгоритм, которые очищает память объектов только при завершении работы
Именно так. Пулы объектов, арены, генерационные индексы, кастомизированные аллокаторы и прочие data driven прелести. Они, конечно, тоже имеют отдельный класс проблем, осложненный всё тем же отсутвием владения и времени жизни, но всё равно формализуется несколько проще т.к. границы определены некоторым набором классов имплементации всей этой системы. Есть, конечно, ещё вот такой доклад, где в некотором виде эти механизмы воспроизводят на шаблонах, но это скорее эксперимент нежели production ready решение, по крайней мере пока.
У вас же в readme RAII стоит первым принципом, поэтому обратил на этот момент ваше внимание. Отдельно стоит упомянуть подход используемый в go/zig/jai/odin с defer освобождением - фактически ещё вариант RAII, но более явный и чаще более чистый в сравнении с пелёнкой объявлений шаблонных параметров в умных указателях.
Чтобы проверять статические инварианты писать компилятор не нужно.
тут скорее это необходимо для формальной верификации всей системы. авторы, писавшие compcert рассказывали, что отправили немало баг репортов в компиляторы, которые естественным образом всплыли при написании собственного компилятора. Где-то генерация была кривая, где-то поведение компилятора было некорректным и приводило к некорректному поведению в уже скомпилированных програмах. Доставалось и GCC и Clang, однако это только часть про язык С. Спецификация языка С++ примерно в 10 раз больше чем у C и произведение множеств фич тоже растёт нелинейно, что может намекать о наличии аналогичных невыявленных багов. Такое простым плагином не решишь. TLA+ в теории можно сделать плагином, но вот насколько оно нужно тоже вопрос.
Отдельно стоит отметить, что похоже не все компиляторы имеют возможность использовать плагины. Clang/gcc имеют инфраструктуру, а msvc насколько я понимаю - нет, но это не точно. Насколько имеющиеся системы плагинов feature complete по сравнению друг с другом тоже вопрос открытый.
Можно пойти третьим путём и написать компилятор, который будет делать то же, что и компилятор Rust - проверять статические инварианты и при этом сам будет являеться формально-верифицируемым - аналог CompCert, но для плюсов.
Ну и есть другие нюансы касательно предлагаемой безопасности, которые не учтены. Для простых програм RAII обычно достаточно, но для высокопроизводительных это может быть довольно расточительным - одна только фрагментация сколько шуму наделает.
Другой момент связан с огромным количеством способов достичь UB - забыл проинициализировать bool - лови UB, шагнул итератором больше положенного - лови UB, Cкормил рэнжи в неправильном порядке - лови ещё приколов для отладки, хоть и не UB. И вот эти моменты сложно обезопасить без переделки языка.
Это секвенция для количества всех простых пар, складывающихся до некоторого заданного 2n - то есть явно показывает количество элементов в вашем палиндроме. Не считая 1+p, потому что 1 не является простым числом. Симметрия этих значений довольно проста и понятна и не требует каких-то слоев, затемнений и прочих и вычисляется гораздо проще. То бишь ваша работа - кривенькая подзадача в рамках данных из секвенции.
Вы бы хоть проверили его. Объявление и условие хотят по :.
Отдельный вопрос как выглядят оригинальное и шифрованные сообщения, чтобы их можно было передавать хоть в каком-нибудь виде. На массив байт это всё не похоже, как передавать и парсить массив интов, которые явно за пределами ascii -тоже непонятно.
Вы же в курсе, что habr поддерживает рендеринг формул? Почитайте как рисовать формулы через LaTeX.
Ну, а по поводу самой формулы там уже ниже пояснили проблемы. Претензии к магической десятке, делящей n, была ещё в самом первом комментарии. Проблемы округления там же. Ну, и количество вариантов кажется довольно нереалистичным при больших N, но т.к. вы ни проверяете, ни доказываете, то я уж и не знаю что вам ещё предложить
А где хоть какие-нибудь тесты всего этого дела? Ни в статье примеров исполнения на произвольной лямбде, ни в тестах хоть каких-нибудь тестов, что оно действительно работает.
прибор который смотрит состояния вакуума совершенно абстрактный и не существует в ральном мире. А приборы которые подтвеждали теорию флуктуаций вакуума не имели нужды в измерении рождённых частиц, насколько мне известно.
что в нынешнем она возникла в нынешнем размере еще в момент рождения.
где вы увидели какие-то утверждения о размере? материя и излучение фиксированы, а не пространство.
Больше интересно как поменялась ситуация за последние годы. А то раньше некоторые просто бухали некоторую сумму в рекламу и получали некоторый относительно стабильный возврат. Судя по свежим историям это всё сломалось и условные 50к рублей уходят в воздух с нулевым возвратом.
Как-то вы поскупились на код - функцию кодирования вы используете, но не стали приводить её код. Сначала там будет что-то простое типа char_to_code[int(char)] ан нет, там кортежи с кортежами - как их готовить-то?
Так вы в комментариях за значение 1/p говорите или за сумму ряда? Сумма ряда понятное дело расходится.
Ну и раз вы разницу рядов считаете, то должны были заметить, что растёт заметно быстрее чем и в какой-то момент их разница превысит 1, так что и тут косяк.
Да в общем-то в классической механике мы их явно обычно и не задаём. В лучшем случае складываем кинетическую + потенциальную. Кажется в рамках ОТО иметь массу и скорость не возбраняется, так что не очень понимаю как его может не существовать как инварианта. Разные инерциальные системы вроде не заставляют их терять/добавлять энергию ни в рамках своей СО ни в СО наблюдателя. Подсчёт общей энергии осложняется, да, но потерять/добавить энергию вроде тоже не получится.
Как и вопрос конечности нашей вселенной или её настоящей топологии. И наличия состояния истинного вакуума. В этом смысле закон сохранения и является некоторой выбранной аксиомой, которую удобнее всего взять за истину, т.к. это ближе всего к тому что мы наблюдаем - пусть и с локальными искажениями. Мы можем помоделировать альтернативы, но для построения модели наблюдаемой вселенной оно вроде не слишком помогает.
Не до конца понимаю о чем речь. То есть если мы возьмём неизлучающую массу, то вместе с гравитацией общая энергия системы останется нулевой - "ничем", потому что гравитация будет компенсировать потенциальную энергию этой массы? В таком случае получаем всё то же постоянное количество энергии в глобальном масштабе и кучку флуктуаций в локальном. Энергия в такой системе из ниоткуда не возьмётся и масса не начнёт внезапно излучать или наоборот создавать энергетическую дырку.
Закон сохранения энергии принято считать аксиомой и вроде пока нет никаких причин, почему это не должно быть так. В противном случае известные нам законы термодинамики ломались бы и мы вероятно могли бы как-то пронаблюдать это нарушение. Пока никакие наблюдательные данные не показывают нарушений с законом сохранения.
Единственная проблема с этим - первые моменты до большого взрыва, которые приводят к бесконечным значениям плотности энергии/массы из-за бесконечно малого пространства, в котором была сконцентрирована конечная энергия-масса.
Ну и оценки количества энергии могут разниться, потому что мы не знаем полное состояние видимой и невидимой вселенной.
Интересно можно ли таким макаром накатить какую-нибудь ReactOS
я не понимаю о чем вы спрашиваете. что энергия? да энергия.
Именно так. Пулы объектов, арены, генерационные индексы, кастомизированные аллокаторы и прочие data driven прелести. Они, конечно, тоже имеют отдельный класс проблем, осложненный всё тем же отсутвием владения и времени жизни, но всё равно формализуется несколько проще т.к. границы определены некоторым набором классов имплементации всей этой системы. Есть, конечно, ещё вот такой доклад, где в некотором виде эти механизмы воспроизводят на шаблонах, но это скорее эксперимент нежели production ready решение, по крайней мере пока.
У вас же в readme RAII стоит первым принципом, поэтому обратил на этот момент ваше внимание. Отдельно стоит упомянуть подход используемый в go/zig/jai/odin с defer освобождением - фактически ещё вариант RAII, но более явный и чаще более чистый в сравнении с пелёнкой объявлений шаблонных параметров в умных указателях.
тут скорее это необходимо для формальной верификации всей системы. авторы, писавшие compcert рассказывали, что отправили немало баг репортов в компиляторы, которые естественным образом всплыли при написании собственного компилятора. Где-то генерация была кривая, где-то поведение компилятора было некорректным и приводило к некорректному поведению в уже скомпилированных програмах. Доставалось и GCC и Clang, однако это только часть про язык С. Спецификация языка С++ примерно в 10 раз больше чем у C и произведение множеств фич тоже растёт нелинейно, что может намекать о наличии аналогичных невыявленных багов. Такое простым плагином не решишь. TLA+ в теории можно сделать плагином, но вот насколько оно нужно тоже вопрос.
Отдельно стоит отметить, что похоже не все компиляторы имеют возможность использовать плагины. Clang/gcc имеют инфраструктуру, а msvc насколько я понимаю - нет, но это не точно. Насколько имеющиеся системы плагинов feature complete по сравнению друг с другом тоже вопрос открытый.
Можно пойти третьим путём и написать компилятор, который будет делать то же, что и компилятор Rust - проверять статические инварианты и при этом сам будет являеться формально-верифицируемым - аналог CompCert, но для плюсов.
Ну и есть другие нюансы касательно предлагаемой безопасности, которые не учтены. Для простых програм RAII обычно достаточно, но для высокопроизводительных это может быть довольно расточительным - одна только фрагментация сколько шуму наделает.
Другой момент связан с огромным количеством способов достичь UB - забыл проинициализировать bool - лови UB, шагнул итератором больше положенного - лови UB, Cкормил рэнжи в неправильном порядке - лови ещё приколов для отладки, хоть и не UB. И вот эти моменты сложно обезопасить без пер
еделки языка.Это секвенция для количества всех простых пар, складывающихся до некоторого заданного 2n - то есть явно показывает количество элементов в вашем палиндроме. Не считая 1+p, потому что 1 не является простым числом. Симметрия этих значений довольно проста и понятна и не требует каких-то слоев, затемнений и прочих и вычисляется гораздо проще. То бишь ваша работа - кривенькая подзадача в рамках данных из секвенции.
Я просто оставлю это здесь
https://oeis.org/A002375
Огонь. Ещё бы на to_string тест
Вы бы хоть проверили его. Объявление и условие хотят по
:.Отдельный вопрос как выглядят оригинальное и шифрованные сообщения, чтобы их можно было передавать хоть в каком-нибудь виде. На массив байт это всё не похоже, как передавать и парсить массив интов, которые явно за пределами ascii -тоже непонятно.
Вы же в курсе, что habr поддерживает рендеринг формул? Почитайте как рисовать формулы через LaTeX.
Ну, а по поводу самой формулы там уже ниже пояснили проблемы. Претензии к магической десятке, делящей n, была ещё в самом первом комментарии. Проблемы округления там же. Ну, и количество вариантов кажется довольно нереалистичным при больших N, но т.к. вы ни проверяете, ни доказываете, то я уж и не знаю что вам ещё предложить
Так оно не было целью работы, зачем им их искать?
А где хоть какие-нибудь тесты всего этого дела? Ни в статье примеров исполнения на произвольной лямбде, ни в тестах хоть каких-нибудь тестов, что оно действительно работает.
прибор который смотрит состояния вакуума совершенно абстрактный и не существует в ральном мире. А приборы которые подтвеждали теорию флуктуаций вакуума не имели нужды в измерении рождённых частиц, насколько мне известно.
где вы увидели какие-то утверждения о размере? материя и излучение фиксированы, а не пространство.
Больше интересно как поменялась ситуация за последние годы. А то раньше некоторые просто бухали некоторую сумму в рекламу и получали некоторый относительно стабильный возврат. Судя по свежим историям это всё сломалось и условные 50к рублей уходят в воздух с нулевым возвратом.
Как-то вы поскупились на код - функцию кодирования вы используете, но не стали приводить её код. Сначала там будет что-то простое типа char_to_code[int(char)] ан нет, там кортежи с кортежами - как их готовить-то?
Окей, робот убедил что 1/pq for p > 7 будет расти быстрее пока 500 миллионов простых спустя разница не станет отрицательной.
Так а какая разница. с 1-7 у вас оно разойдётся в спустя пару тысяч простых, без них - ну пусть будет 20000, но все равно сломается.
Так вы в комментариях за значение 1/p говорите или за сумму ряда? Сумма ряда понятное дело расходится.
Ну и раз вы разницу рядов считаете, то должны были заметить, что
растёт заметно быстрее чем 
и в какой-то момент их разница превысит 1, так что и тут косяк.