Так может нужно делать новые игры интересней чем их 10-20-летние предшественники? Или там попробовать сделать что-то новаторское, дающее игрокам новый опыт, а не ставить франшизы на конвеер и делать всратые ремастеры?
А в чем принципиальная разница между умножением магнитуды на число на порядки меньше единицы с последующим сравнением с разницей, и умножение разницы на число на порядки больше единицы с последующим сравнением с магнитудой?
А откуда вообще инфа, что у него такая сложность? Не спец по java, но во всех источниках до которых дотянулся говорится что до какой-то версии был связный список с O(n), а потом хешмап улучшили, и теперь при возможности сравнения элементов используется дерево с O(log(n)).
Проекция "на прямоугольник" (кстати, rectilinear projection это вроде не оно) тоже не является достоверной, и имеет собственные проблемы. При использовании способа из статьи и здравых углах обзора искажение мизерное, что можно увидеть на другом примере с более высоким разрешением. А идеального способа для плоского монитора не существует.
Если собес проводит адекватный человек, то он просто задаст наводящий вопрос. Если собеседуемый хотя бы примерно понимает как работают хешмапы, он ответит что при плохом распределении ключей время доступа может увеличиваться. На результат собеса если собеседуемый соответствует позиции такая заковырка влиять не должна.
Достаточно конвенции "с начала строки", и прекрасно ищется регэкспом ^.*:
А еще этим регекспом найдутся строковые литералы с двоеточием, комментарии с двоеточием, несколько сотен/тысяч всяких "public:" и "private:", конструкторы со списками инициализации, объявления классов с наследованием, битовые поля, все case в свичах, тернарные операторы и примерно бесконечность обращений через неймспейс.
Так почему на собеседованиях спрашивают сложность алгоритма без привязки к конкретному языку?
Потому что сложность алгоритма в принципе не отражает никакой абсолютной величины (ни секунд, ни циклов процессора, ни конкретных операций), а лишь является функцией, которая показывает как будет изменяться время/память для его выполнения при изменении входных данных (количества данных, размера словаря, и т.д.). И она является характеристикой именно алгоритма, а не его реализации. Сказав что-то из статьи на собеседовании в самом лучшем случае можно получить улыбку собеседующего, а в худшем это заваленный собес.
Кроме того, в статье есть еще ряд ошибок. Например, "О большое" это и есть обозначение для "худшего случая". Который при этом может быть даже единственным возможным случаем. Т.е. какие там есть случаи кроме худшего для "О большого" в принципе не важно, и оптимизации под специфичные конфигурации входных данных на него не влияют.
Еще в одном из первых боев есть момент, где персонаж вроде пытается пошутить, и одновременно открывается подсказка. И после закрытия подсказки речь не возобновляется.
Как минимум некоторые крупные стримеры не сразу поняли что это лифт. Там следует если не менять дизайн, то хотя бы уменьшить паузу перед началом подъема.
Если следующий шаг жестко задан, то как делать управление потоком вычисления?
Он и не задан жестко. Это же виртуальная машина, просто реализованная с промежуточными слоями абстракции. У нее помимо регистров есть и стек, и куча, и все что понадобится.
Еще один пример для аналогии. В игре Конвея Жизнь можно используя фигуры реализовать логически вентили, а используя их - тьюринг полный компьютер. Саму Жизнь мы реализуем используя lookup table. Эту самую таблицу мы заранее материализуем, перемешиваем, и сохраняем. Скрываемый алгоритм либо конструируем руками, либо пишем генератор, после чего берем полученное состояния поля, конвертируем его под сохраненную ранее перемешанную таблицу. И уже в таком виде это можно запускать на посторонней машине. По общему принципу это совпадает с тем, что я пытался описать выше, только еще менее эффективно.
Чтобы статья была с пользой, приведем очередную итерацию шпаргалки по написанию бенчмарков:
Использовать как можно больше итераций.
Прогревать код перед началом замеров.
Минимизировать влияние операций замера времени.
Делать замер до и после цикла тела бенчмарка.
Использовать самый точный из доступных таймеров.
Не допускать посторонний код в теле бенчмарка.
Особенно это касается операций ввода-вывода.
Использовать случайные входные данные на каждой итерации.
Заранее генерировать массив значений входных данных.
Проверить данные:
- входные данные корректны
- входные данные репрезентативны
- код не завершается слишком рано
- результаты кода корректны
Убедиться что результаты не являются мертвым кодом.
Например:
- вычислять и выводить сумму результатов
- сохранять результаты в массив
При сравнении языков писать эквивалентный код.
Примеры проблем:
- используя разные алгоритмы
- передача по ссылке и значению
- строки с интернированием и без
- используя ООП и без
Еще больше смазанности, когда параметров два или больше. Где один, например, количество данных, а другой - размер окна или алфавита, которые значительно меньше количества. И ты вроде пытаешься уменьшить часть, на которую умножается зависимость от количества, а она не уменьшается. При этом еще и дополнительные ограничения возникают.
Все это конечно очень интересно, но у подобных задач при переходе к практике могут возникать конфузы. Решение в лоб может оказаться эффективней при реализации на конкретных языках, причем даже при достаточном для некоторых практических применений количестве данных. Например, алгоритм может иметь низкую энтропию условных переходов, компилятор может удачно подобрать SIMD инструкции, плюс расходы на работу с памятью, зависимость от реализации контейнеров стандартной библиотеки, и куча других факторов. Единственный способ узнать реальную эффективность - это написать код и прогнать по бенчмаркам, которые тоже нужно правильно уметь писать.
Как минимум, очень сильно обфусцировать можно. Когда-то давно размышлял над подобным, и идея была следующая.
Создать виртуальную машину из M блоков одинаковой длины, скажем в N бит, которые по сути являются просто числами. В каждом блоке должно быть отведено какое-то количество бит для обмена информацией между собой, бит регистров, служебных бит, и возможно какое-то избыточное количество бит для повышения стойкости к реверс инжинирингу.
У блока будет конечное количество всех возможных состояний, для каждого из которых будет ровно одно следующее. Все эти состояния и переходы можно заранее просчитать, и представить массивом чисел вида "state[current] = next". После чего номера состояний можно перемешать хорошим рандомом, и используя их создать обфусцированный массив. На вычисляющей машине будет только обфусцированный массив, а карта соответствий значений из изначального и обфусцированного масссива будет служить ключем.
Упрощенный пример для понимания. Допустим блок имеет например структуру "RRRRXXYY", где XX и YY биты входных регистров, RRRR биты регистра результата, а операция скажем сумма. Тогда в изначальном массиве индексу "0000.01.10" будет соответствовать число "0011.00.00" (разделил регистры точками для удобства чтения). В изначальном массиве это будет "state[6] = 48". А после рандомизации эти же два состояния могут оказаться любыми числами, например "state[37456] = 91204". Главное, чтобы направление всех переходов сохранялись.
Само собой, в реальной реализации входные и выходные регистры могут совмещаться для экономии, будет много других служебных бит, и сами операции скорее всего будут другого уровня абстракций (логические вентили, например), и т.д. и т.п., но общий принцип примерно такой.
Каждый шаг каждый из M блоков виртуальной машины переключается в свое следующее состояние. Самая сложная часть, вероятно, будет общением между блоками - условная "шина" должна вещать данные всем блокам сразу, а блоки у себя внутри как-то понимать, им это адресовано, или нет. Большая часть бит скорее всего на эту адресацию и уйдет. Соответственно самих блоков тоже понадобится много. Они, кстати, не обязательно должны быть однотипными, и возможно несколько массивов состояний будут удобней при том же суммарном объеме. Ввод вывод - отдельная проблема.
Работать все это будет очень медленно, зато весьма обфусцированно. Тут конечно, нужно вспомнить принцип "каждый может создать шифр, который сам не может взломать", а поскольку я не спец по криптографии, даже теоретическая эффективность описанного выше сомнительна. Тем более, что я даже не пытался все это реализовать в коде, лишь на уровне идеи, и может даже оказаться что это толком невозможно.
Сознание, это когда ты смотришь на красное, и чувствуешь красный цвет, в том смысле, в каком оно понимается в понятии квалиа. При этом тебе не нужно знать что такое красный, что такое цвет, и вообще быть разумным. Самим фактом такого наблюдения ты доказываешь сам себе что сознание лично у тебя есть. На самом деле, это вообще единственный факт который существо обладающее сознанием может достоверно доказать само себе. Все остальное гипотетически может быть чем угодно, поданным на гипотетический вход условного наблюдателя.
Логотип Firefox конечно все более минималистичен с каждой новой версией, но как минимум первые десять лет на нем отчетливо узнается слева лиса, а справа огонь. Причем там даже пигментация морды прорисована, а так же характерные щеки, острые длинные рыжие уши, тонкие рыжие лапы, длинная морда, острый нос, хвост без полос и т.д. и т.п. Т.е. полное совпадение с тем, как выглядит обычная лиса, и полная противоположность тому, как выглядит красная панда.
А если на логотипе лиса и огонь, то значит назван он в честь лисы и огня. Более того, он чисто исторически был сначала Phoenix, потом Firebird, а потом bird поменяли на fox, а fire всегда был центральной темой логотипа.
В США подадут жалобу на OpenAI с требованием прекратить развёртывание GPT
Конкретно для восточных языков несколько лет назад был значительно лучше гугла. Сейчас не знаю.
Вариант Mvvm в Unity
А чем MVVM на Unity принципиально отличается от всех остальных MVVM? На каждый движок и фреймворк с UI отдельный туториал писать?
Denuvo выпустила бесплатную брошюру о вреде игровых эмуляторов для разработчиков игр
Так может нужно делать новые игры интересней чем их 10-20-летние предшественники? Или там попробовать сделать что-то новаторское, дающее игрокам новый опыт, а не ставить франшизы на конвеер и делать всратые ремастеры?
О вреде GOTO-фобии (с примерами на C)
А в чем принципиальная разница между умножением магнитуды на число на порядки меньше единицы с последующим сравнением с разницей, и умножение разницы на число на порядки больше единицы с последующим сравнением с магнитудой?
Истинная сложность алгоритма Bubble Sort
А откуда вообще инфа, что у него такая сложность? Не спец по java, но во всех источниках до которых дотянулся говорится что до какой-то версии был связный список с O(n), а потом хешмап улучшили, и теперь при возможности сравнения элементов используется дерево с O(log(n)).
Пишем игру от первого лица в 2КБ на Rust
Проекция "на прямоугольник" (кстати, rectilinear projection это вроде не оно) тоже не является достоверной, и имеет собственные проблемы. При использовании способа из статьи и здравых углах обзора искажение мизерное, что можно увидеть на другом примере с более высоким разрешением. А идеального способа для плоского монитора не существует.
Наночастицы с экстрактом борщевика Сосновского: российские учёные разработали новый противоопухолевый препарат
Это вещество выводится из организма.
Истинная сложность алгоритма Bubble Sort
Если собес проводит адекватный человек, то он просто задаст наводящий вопрос. Если собеседуемый хотя бы примерно понимает как работают хешмапы, он ответит что при плохом распределении ключей время доступа может увеличиваться. На результат собеса если собеседуемый соответствует позиции такая заковырка влиять не должна.
О вреде GOTO-фобии (с примерами на C)
А еще этим регекспом найдутся строковые литералы с двоеточием, комментарии с двоеточием, несколько сотен/тысяч всяких "public:" и "private:", конструкторы со списками инициализации, объявления классов с наследованием, битовые поля, все case в свичах, тернарные операторы и примерно бесконечность обращений через неймспейс.
Истинная сложность алгоритма Bubble Sort
Потому что сложность алгоритма в принципе не отражает никакой абсолютной величины (ни секунд, ни циклов процессора, ни конкретных операций), а лишь является функцией, которая показывает как будет изменяться время/память для его выполнения при изменении входных данных (количества данных, размера словаря, и т.д.). И она является характеристикой именно алгоритма, а не его реализации. Сказав что-то из статьи на собеседовании в самом лучшем случае можно получить улыбку собеседующего, а в худшем это заваленный собес.
Кроме того, в статье есть еще ряд ошибок. Например, "О большое" это и есть обозначение для "худшего случая". Который при этом может быть даже единственным возможным случаем. Т.е. какие там есть случаи кроме худшего для "О большого" в принципе не важно, и оптимизации под специфичные конфигурации входных данных на него не влияют.
Дизайн уровней. Учимся у Atomic Heart
Еще в одном из первых боев есть момент, где персонаж вроде пытается пошутить, и одновременно открывается подсказка. И после закрытия подсказки речь не возобновляется.
Дизайн уровней. Учимся у Atomic Heart
Как минимум некоторые крупные стримеры не сразу поняли что это лифт. Там следует если не менять дизайн, то хотя бы уменьшить паузу перед началом подъема.
Компилятор с полностью гомоморфным шифрованием от Google
Он и не задан жестко. Это же виртуальная машина, просто реализованная с промежуточными слоями абстракции. У нее помимо регистров есть и стек, и куча, и все что понадобится.
Еще один пример для аналогии. В игре Конвея Жизнь можно используя фигуры реализовать логически вентили, а используя их - тьюринг полный компьютер. Саму Жизнь мы реализуем используя lookup table. Эту самую таблицу мы заранее материализуем, перемешиваем, и сохраняем. Скрываемый алгоритм либо конструируем руками, либо пишем генератор, после чего берем полученное состояния поля, конвертируем его под сохраненную ранее перемешанную таблицу. И уже в таком виде это можно запускать на посторонней машине. По общему принципу это совпадает с тем, что я пытался описать выше, только еще менее эффективно.
Rust быстрее всех, Miiao сделал замеры
Чтобы статья была с пользой, приведем очередную итерацию шпаргалки по написанию бенчмарков:
Лучшая задача по программированию для собеседования
Еще больше смазанности, когда параметров два или больше. Где один, например, количество данных, а другой - размер окна или алфавита, которые значительно меньше количества. И ты вроде пытаешься уменьшить часть, на которую умножается зависимость от количества, а она не уменьшается. При этом еще и дополнительные ограничения возникают.
Лучшая задача по программированию для собеседования
Все это конечно очень интересно, но у подобных задач при переходе к практике могут возникать конфузы. Решение в лоб может оказаться эффективней при реализации на конкретных языках, причем даже при достаточном для некоторых практических применений количестве данных. Например, алгоритм может иметь низкую энтропию условных переходов, компилятор может удачно подобрать SIMD инструкции, плюс расходы на работу с памятью, зависимость от реализации контейнеров стандартной библиотеки, и куча других факторов. Единственный способ узнать реальную эффективность - это написать код и прогнать по бенчмаркам, которые тоже нужно правильно уметь писать.
Компилятор с полностью гомоморфным шифрованием от Google
Как минимум, очень сильно обфусцировать можно. Когда-то давно размышлял над подобным, и идея была следующая.
Создать виртуальную машину из M блоков одинаковой длины, скажем в N бит, которые по сути являются просто числами. В каждом блоке должно быть отведено какое-то количество бит для обмена информацией между собой, бит регистров, служебных бит, и возможно какое-то избыточное количество бит для повышения стойкости к реверс инжинирингу.
У блока будет конечное количество всех возможных состояний, для каждого из которых будет ровно одно следующее. Все эти состояния и переходы можно заранее просчитать, и представить массивом чисел вида "state[current] = next". После чего номера состояний можно перемешать хорошим рандомом, и используя их создать обфусцированный массив. На вычисляющей машине будет только обфусцированный массив, а карта соответствий значений из изначального и обфусцированного масссива будет служить ключем.
Упрощенный пример для понимания. Допустим блок имеет например структуру "RRRRXXYY", где XX и YY биты входных регистров, RRRR биты регистра результата, а операция скажем сумма. Тогда в изначальном массиве индексу "0000.01.10" будет соответствовать число "0011.00.00" (разделил регистры точками для удобства чтения). В изначальном массиве это будет "state[6] = 48". А после рандомизации эти же два состояния могут оказаться любыми числами, например "state[37456] = 91204". Главное, чтобы направление всех переходов сохранялись.
Само собой, в реальной реализации входные и выходные регистры могут совмещаться для экономии, будет много других служебных бит, и сами операции скорее всего будут другого уровня абстракций (логические вентили, например), и т.д. и т.п., но общий принцип примерно такой.
Каждый шаг каждый из M блоков виртуальной машины переключается в свое следующее состояние. Самая сложная часть, вероятно, будет общением между блоками - условная "шина" должна вещать данные всем блокам сразу, а блоки у себя внутри как-то понимать, им это адресовано, или нет. Большая часть бит скорее всего на эту адресацию и уйдет. Соответственно самих блоков тоже понадобится много. Они, кстати, не обязательно должны быть однотипными, и возможно несколько массивов состояний будут удобней при том же суммарном объеме. Ввод вывод - отдельная проблема.
Работать все это будет очень медленно, зато весьма обфусцированно. Тут конечно, нужно вспомнить принцип "каждый может создать шифр, который сам не может взломать", а поскольку я не спец по криптографии, даже теоретическая эффективность описанного выше сомнительна. Тем более, что я даже не пытался все это реализовать в коде, лишь на уровне идеи, и может даже оказаться что это толком невозможно.
Bing: «Я не причиню вам вреда, пока вы не причините вред мне»
Сознание, это когда ты смотришь на красное, и чувствуешь красный цвет, в том смысле, в каком оно понимается в понятии квалиа. При этом тебе не нужно знать что такое красный, что такое цвет, и вообще быть разумным. Самим фактом такого наблюдения ты доказываешь сам себе что сознание лично у тебя есть. На самом деле, это вообще единственный факт который существо обладающее сознанием может достоверно доказать само себе. Все остальное гипотетически может быть чем угодно, поданным на гипотетический вход условного наблюдателя.
Bing: «Я не причиню вам вреда, пока вы не причините вред мне»
Это существо которое по поведению неотличимо от существа обладающего сознанием, но при этом не обладающее им в действительности.
Js, трюки, наблюдения, бенчмарки и как Лиса уничтожает Хром. Я протестировал всё, что вам было лень
Логотип Firefox конечно все более минималистичен с каждой новой версией, но как минимум первые десять лет на нем отчетливо узнается слева лиса, а справа огонь. Причем там даже пигментация морды прорисована, а так же характерные щеки, острые длинные рыжие уши, тонкие рыжие лапы, длинная морда, острый нос, хвост без полос и т.д. и т.п. Т.е. полное совпадение с тем, как выглядит обычная лиса, и полная противоположность тому, как выглядит красная панда.
А если на логотипе лиса и огонь, то значит назван он в честь лисы и огня. Более того, он чисто исторически был сначала Phoenix, потом Firebird, а потом bird поменяли на fox, а fire всегда был центральной темой логотипа.