"должен гарантировать одинаковый результат выполнения операций на любой платформе"
Не совсем уверен, что генератор псевдослучайных чисел должен гарантировать одинаковые числа даже на одной платформе
Rust имеет намного меньше платформ в поддержке, чем free pascal, более того Rust в последнее время понизил из тир 1 и тир 2 много платформ, в то время как fpc их поддерживает до сих пор актуальными, хотя имеет на порядок больше целей для сборки
Подумайте вот на чем, чтобы разогнать кирпич нужна сила, а какой природы? Могу ли я приложить силу инерции к этому кирпичу, чтобы его разогнать или остановить? Нет, только одну из фундаментальных сил, у всякой силы должен быть переносчик, бозон, пусть виртуальный, чтобы мы могли эту силу к чему-то приложить, как может выглядеть переносчик силы инерции?
Таких выдуманных сил, которых ни к чему не приложить - большинство в школьной физике, всякие силы ван-дер-вальса, реакции опоры, трения, центростремительные и прочее, они нужны только чтобы упростить расчёты, всегда можно найти систему отсчёта где такой силы не существует, в отличии от фундаментальных сил, которые существуют всегда и именно они являются причиной этих выдуманных сил
На мой взгляд бич Rust это отсутствие стандартизации, хочешь просто получить псевдослучайное число, что в паскале 1983-го даже было из коробки Random - пиши генератор или сторонний крейт, и вот пишешь под wasm, там штук 15 таких крейтов надо знать на всякую мелочь хотя бы как называются, какие-то pool_promise, gloo_timers... И каждый автор по своему трактует интерфейс
Это в смысле прям академические знания, как пример знаю одного сеньора C#, который мне заливали что общение с моей платой должно выглядеть так - он делает коннект, отправляет мне пакет и делает дисконнект и каждый пакет так, что такое listen он знать не знает, ему надо было после каждого пакета рвать соединение, на сколько это сильный программист на ваш взгляд?
Я пытался разобраться почему ему так надо, выяснил что у него там деструкторы зовутся при всякой маршелизации, я даже не стал ворошить это осиное гнездо, закончилось что я просто написал ему dll и so, которые адекватно работают
Начинать нужно с дискретной математики, теории алгоритмов, теории типов, основ кодирования, если мы говорим о практике то любой из системных языков - C, Pascal, Rust, C++, это база, мне ещё не встречался действительно сильный программист на Python, PHP или Java, обычно они варятся в какой-то своей проблематике, не способны определить сложность алгоритма, понять разницу между AoS и SoA, а от слов типа BWT-преобразование или коды Рида-Соломона падают в обморок
Мы всегда можем ехать до половины заряда, потом возвращаться по тому же пути на зарядку, чтобы нам не мешали препятствия по среди, потом запускать случайные блуждания снова, дело не в заряде, а во времени, но тут эстетически пользователь будет наслаждаться что постоянно происходит какая-то работа и возможно ничего не заподозрит... А мы к тому моменту выпустим патч
Если серьезно самое простое что мне приходит в голову вот с ходу, это как в лабиринте идти всегда прижавшись к стене и делая только правые повороты, пока не замкнется многоугольник, определить внутри или снаружи многоугольника, если внутри - применить любой алгоритм закраски многоугольника, если снаружи, то ехать от него в произвольную сторону и повторять пока не найдем внешнюю границу комнаты
Но если есть 40 минут, можно придумать что то лучше, наверное, сейчас возьму пивка, подумаю
Есть, это следствие теоремы о возвращении, если комната конечна, связана (т.е. достижимы все её точки) и нет никаких циклов при выборе пути, то рано или поздно вы побываете везде, если точнее - она утверждает что при таких условиях вероятность посетить любую точку стремится к 1
Судя по исходникам там два варианта - в одном она работает как шар предсказания, типа даёт случайную фразу в стиле "это не получится", в режиме llm травит историю в стиле продолжи "жили были дед да бабка"
Вся магия, если там история - ерунда, когда читаешь по буквам уже как с демоном общаешься, столько усилий и времени потрачено, что принципиально до конца идёшь)
Вы думаете что если насуёте мне 100500 минусов, будете чуть правее? Вообще нет, не думайте, что я не знаю что такое состояние гонки, псу своему рассказывайте, я попросил конкретный код, а то говорим ни о чём
У нас на работе принято snprintf, не знаю насколько она прожорливее, но точно безопаснее, но некоторые возмутятся зачем вообще копировать, если есть слайсы и Rust
Не знаю как у вас, в совсем запущенном случае в Rust есть барьеры, которые именно что и делают, что гарантируют порядок операций
А вообще дайте пример этого нетривиального случая однопоточного, посмотрим конкретику, а не пространные рассуждения и предположения, скорее всего это случай с какой-то кривой архитектурой, и средствами языка это не нужно решать, проблемы в голове программиста
В прошлом аппарате Therac-20 такая защита была и иногда срабатывала, когда пользовались новички, когда же вводили опытные операторы им не удавалось воспроизвести, не видя никакой системы в появлении бага - списывали на ошибку самой защиты, они прямо так и пишут, что ПО не подвержено деградации и всегда делает одно и то же, а вот аппаратная защита может глючить от излучения
Rust решает эту проблему, он заставляет явно обработать ошибки программиста, а не надеяться на когда-нибудь потом, состояние гонки там можно получить только умышленно и надо очень постараться
"должен гарантировать одинаковый результат выполнения операций на любой платформе"
Не совсем уверен, что генератор псевдослучайных чисел должен гарантировать одинаковые числа даже на одной платформе
Rust имеет намного меньше платформ в поддержке, чем free pascal, более того Rust в последнее время понизил из тир 1 и тир 2 много платформ, в то время как fpc их поддерживает до сих пор актуальными, хотя имеет на порядок больше целей для сборки
Подумайте вот на чем, чтобы разогнать кирпич нужна сила, а какой природы? Могу ли я приложить силу инерции к этому кирпичу, чтобы его разогнать или остановить? Нет, только одну из фундаментальных сил, у всякой силы должен быть переносчик, бозон, пусть виртуальный, чтобы мы могли эту силу к чему-то приложить, как может выглядеть переносчик силы инерции?
Таких выдуманных сил, которых ни к чему не приложить - большинство в школьной физике, всякие силы ван-дер-вальса, реакции опоры, трения, центростремительные и прочее, они нужны только чтобы упростить расчёты, всегда можно найти систему отсчёта где такой силы не существует, в отличии от фундаментальных сил, которые существуют всегда и именно они являются причиной этих выдуманных сил
На мой взгляд бич Rust это отсутствие стандартизации, хочешь просто получить псевдослучайное число, что в паскале 1983-го даже было из коробки Random - пиши генератор или сторонний крейт, и вот пишешь под wasm, там штук 15 таких крейтов надо знать на всякую мелочь хотя бы как называются, какие-то pool_promise, gloo_timers... И каждый автор по своему трактует интерфейс
Сила инерции вообще выдуманная сила, чтобы упростить расчёты, в списке фундаментальных сил её нет
У RISC-V есть режимы S, M, U, они позволят
Вообще отключилось функционирование с вашим алгоритмом, ушёл в отключку, на внешние раздражители не реагировал
Чего-то придумал, но что не помню
Вроде основная идея исходила из закона распространения волн...
Это в смысле прям академические знания, как пример знаю одного сеньора C#, который мне заливали что общение с моей платой должно выглядеть так - он делает коннект, отправляет мне пакет и делает дисконнект и каждый пакет так, что такое listen он знать не знает, ему надо было после каждого пакета рвать соединение, на сколько это сильный программист на ваш взгляд?
Я пытался разобраться почему ему так надо, выяснил что у него там деструкторы зовутся при всякой маршелизации, я даже не стал ворошить это осиное гнездо, закончилось что я просто написал ему dll и so, которые адекватно работают
Есть же крейт rust-decimal
Начинать нужно с дискретной математики, теории алгоритмов, теории типов, основ кодирования, если мы говорим о практике то любой из системных языков - C, Pascal, Rust, C++, это база, мне ещё не встречался действительно сильный программист на Python, PHP или Java, обычно они варятся в какой-то своей проблематике, не способны определить сложность алгоритма, понять разницу между AoS и SoA, а от слов типа BWT-преобразование или коды Рида-Соломона падают в обморок
Мы всегда можем ехать до половины заряда, потом возвращаться по тому же пути на зарядку, чтобы нам не мешали препятствия по среди, потом запускать случайные блуждания снова, дело не в заряде, а во времени, но тут эстетически пользователь будет наслаждаться что постоянно происходит какая-то работа и возможно ничего не заподозрит... А мы к тому моменту выпустим патч
Если серьезно самое простое что мне приходит в голову вот с ходу, это как в лабиринте идти всегда прижавшись к стене и делая только правые повороты, пока не замкнется многоугольник, определить внутри или снаружи многоугольника, если внутри - применить любой алгоритм закраски многоугольника, если снаружи, то ехать от него в произвольную сторону и повторять пока не найдем внешнюю границу комнаты
Но если есть 40 минут, можно придумать что то лучше, наверное, сейчас возьму пивка, подумаю
Есть, это следствие теоремы о возвращении, если комната конечна, связана (т.е. достижимы все её точки) и нет никаких циклов при выборе пути, то рано или поздно вы побываете везде, если точнее - она утверждает что при таких условиях вероятность посетить любую точку стремится к 1
"целый новый класс гигантских «обнажённых» чёрных дыр и переворачивает привычное учебниковое представление о молодой Вселенной."
Так и вижу как решается по учебникам уравнение Шварцшильда, если кто решал - зовите, посмеёмся
Судя по исходникам там два варианта - в одном она работает как шар предсказания, типа даёт случайную фразу в стиле "это не получится", в режиме llm травит историю в стиле продолжи "жили были дед да бабка"
Вся магия, если там история - ерунда, когда читаешь по буквам уже как с демоном общаешься, столько усилий и времени потрачено, что принципиально до конца идёшь)
Innovation это нечто новое, пока я вижу нишу Rust переписать что уже давно есть на Rust
Фига се библиотека, первый раз вижу, обычно anyhow и thiserror используют
Вы думаете что если насуёте мне 100500 минусов, будете чуть правее? Вообще нет, не думайте, что я не знаю что такое состояние гонки, псу своему рассказывайте, я попросил конкретный код, а то говорим ни о чём
У нас на работе принято snprintf, не знаю насколько она прожорливее, но точно безопаснее, но некоторые возмутятся зачем вообще копировать, если есть слайсы и Rust
Не знаю как у вас, в совсем запущенном случае в Rust есть барьеры, которые именно что и делают, что гарантируют порядок операций
А вообще дайте пример этого нетривиального случая однопоточного, посмотрим конкретику, а не пространные рассуждения и предположения, скорее всего это случай с какой-то кривой архитектурой, и средствами языка это не нужно решать, проблемы в голове программиста
В прошлом аппарате Therac-20 такая защита была и иногда срабатывала, когда пользовались новички, когда же вводили опытные операторы им не удавалось воспроизвести, не видя никакой системы в появлении бага - списывали на ошибку самой защиты, они прямо так и пишут, что ПО не подвержено деградации и всегда делает одно и то же, а вот аппаратная защита может глючить от излучения
Rust решает эту проблему, он заставляет явно обработать ошибки программиста, а не надеяться на когда-нибудь потом, состояние гонки там можно получить только умышленно и надо очень постараться
А где helix?