Pull to refresh
195
0
Михаил Бахтерев @mikhanoid

ИММ УрО РАН

Send message

Это же нейросети, на которые существуют "однопиксельные атаки". Как можно что-то исключать? Кроме того, раз из Сбера и прочих подобных корпораций рекой утекают данные пользователей, то почему бы не утечь и нейросетям? А дальше дело техники организовать компрометирующую атаку так, чтобы или по фоточкам, или каким абстрактным избражениям нейросеть распознавала то, что нужно злоумышленнику.

Почему не даёт? Можно для пустого множества задать произвольный элемент. Другое дело, что это не позволит гомоморфизм между свободным моноидом списков и полугруппой установить. Но гомоморфность не всегда нужна.

Математическая формула не корректна. У Вас написано (ab)c = (ac)b, а должно быть (ab)c = a(bc).

Во вселенной Expanse Марс технологически лучше развит (Росинант - марсианский фрегат), марсиане более мотивированы, их жизнь более осмыслена. Иногда приходится ходить строем, но это не особо мешает заниматься всякой фигнёй в свободное от строевой подготовки время. Почему жизнь землян лучше?

Создавать матрицы доверия с людьми? Ходить на вечеринки подписи gpg-ключей?

🤷🏼‍♂️ я просто исходники посмотрел

Есть такая функция https://docs.rs/futures/0.3.5/futures/future/fn.join_all.html Отличие в том, в какие очереди эти задачи будут записаны, и как эти очереди будут обработаны. Соответственно, могут быть иными и объёмы необходимой памяти. join_all, например, кучу Box создаёт.

Парадигма с promise/future везде примерно одинаковая. Что помешало автору на других языках сохранить futures в массив и точно так же их потом последовательно дождаться? Или почему он в программе на Rust не воспользовался join_all?

Можно. Но ресурсов это потребляет заведомо меньше.

Важно, как именно всё выполняется. В реализации на Tokio сначала все таймеры записываются в список ожидания, а потом цикл с await проверяет каждый таймер на срабатывание, сравнивая текущее время с тем, что записано в списке ожидания. Естественно, все таймеры окажутся сработавшими, когда сработает первый await в цикле. И общее время работы составит 10 секунд.

WaitAll - более сложная операция, скорее всего, выполняемая на пуле потоков, по которым планировщик раскидывает очереди таймеров, для параллельного их отслеживания. Для этого нужно больше памяти, синхронизаций и работы планировщика.

Поэтому прямое сравнение таких вариантов кода не имеет смысла. Это не означает, что при корректном сравнении Tokio и Rust не будут выигрывать у JS. Но нужно измерять примерно одно и то же, а не выполнять для сравнения на одной из систем заведомо более сложный алгоритм.

Зачем же так недооценивать умы 19-го века? Они до квантовой механики додумались и дифференциальной геометрии. Из-за феномена "цифровой деменции" да и вообще деградации науки, как социального института, не уверен, что современные учёные смогли бы до таких вершин мысли подняться. Кто знает, что в 19 веке смогли бы извлечь из мобильного телефона?

Вот едут учёные изучать реликтовые племена (условно) Амазонки. И что? У них всё оборудование с протоколами самоуничтожения? Зачем это нужно?

Это просто прекрасно: сравнивать последовательный await задач с waitall. GPT - программирование, не приходя в сознание, - сегодня в тестах, завтра в production!

Будут ли у конечных пользователей деньги, после того, как их погонят с работы под лозунгом "ИИ может лучше!"? Ставка на ИИ с экономической точки зрения странная, потому что сокращает платёжеспособный спрос.

Это так не работает. Кодирование инструкций для CISC может потребовать больше байтов для эквивалентной программы, даже если самих инструкций нужно меньше.

А каким образом изолированная система (мы же в физическом смысле, да?) может воспринимать паттерны окружающей среды?

Спасибо за статью, но возник следующий глупый вопрос. Вот есть огромные затраты на продвижение, которые надо окупать. Кроме того, чтобы пришёл инвестор, игры должны обладать определённой структурой, разработчики и художники ограничены в своём творчестве, во времени. Игры превращаются в скучный штампованный ширпотреб. И так далее, и тому подобное, и прочие негативные последствия.

Спрашивается: а зачем всё это? Если разработчикам достаётся малая доля денежного потока, то почему бы не перестать ставить целью завоевать аудиторию в миллионы пользователей? По идее, не нужно же заработать все деньги мира, а нужно заработать достаточно, чтобы содержать своё домохозяйство (скажем так), и иметь ресурсы для развития игры.

Не разумнее ли в этом случае просто привлечь меньше игроков, но более интересным продуктом? В итоге сработает сарафанное радио, аудитория появится. Почему это не работает? Ну, с большими корпорациями понятно, конечно, они все больны болезнью Паркинсона на разных стадиях. Но для небольших команд, кажется, стратегия "мы хотим завоевать весь мир" не особо разумна.

Есть не правильное и не неправильное :)

Вокруг так много новых языков, но так мало практичных... Мне кажется, это показатель.

Information

Rating
Does not participate
Location
Екатеринбург, Свердловская обл., Россия
Registered
Activity

Specialization

Backend Developer, Научный сотрудник
Applied math
System Programming
Machine learning
Compilers
Scheme
C
Assembler
Linux
Clojure
Haskell