Должна быть гарантированно решена проблема первичности получаемой личности — переживший «смерть» должен остаться изначальной личностью, а не копией или имитацией.
Не согласен с этим тезисом. Мне кажется, это в очередной раз борьба с ветряными мельницами.
В случае имитации все, разумеется, понятно — это не личность.
А вот по поводу копии — нет никакой «изначальной» и «настоящей» личности, это абстракция. Если копия будет достаточно точной — разницы не будет. Если имитация искусственными нейронами будет неточной — не важно, копированием или миграцией будет осуществляться переход, разница все равно будет заметна.
В остальном — понейронное копирование живого мозга ничем не отличается от разрушающего копирования или неинвазивного копирования, кроме иллюзии цельности.
Важен исключительно технологический вопрос — какой метод будет проще и надежнее.
Само понятие «личности» как объекта — это естественное следствие нашего абстрагирования. Из него растет парадокс корабля Тесея.
На самом деле ты сам каждый миг — своя «неточная» копия. Твое сознание угасает каждую ночь и воскресает вновь. Из-за особенностей нашего мозга/тела ты лишен возможности видеть свои копии — поэтому наличие своей копии кажется тебе ненастоящим «Я», а смерть оригинального носителя — его смертью. Как дикарь, которому показали телефон и он не может осознать концепцию передачи голоса — ему кажется, что человека спрятали в трубку.
Если ты хочешь бессмертия — нужно развеять эти иллюзии. Наоборот, удобно видеть и осознавать свои копии, понимать, что они — это ты и твоя смерть — это смерть нескольких дней памяти, которыми вы отличаетесь от своей копии. Это даст новые возможности.
Правовые вопросы, вопросы надежности копирования, вопросы этики, вопросы злоупотреблений (а вдруг твоя копия — не твоя, ее тайно модифицировали и теперь она выглядит как ты а на самом деле тайный промоутер кока-коллы!) — так или иначе не относятся к теме, могут и будут решены, пусть это и изменит общество до неузнаваемости. Опять же — кока кола модифицирует твой мозг прямо сейчас, наживую, только неинвазивно — и никто не жалуется.
Ну идея хорошая, многим нравится, но есть и скепсис.
Все же объяснение натыкается раз за разом на то, что вот смотрите, как мы хорошо утилизируем кеш процессора и обрабатываем батчи объектов.
А люди ценят юнити за быстрое прототипирование, удобный редактор и готовые компоненты.
Всем пофиг на эффективность.
В общем сложно все. Сейчас выглядит как сбоку приклеенное к архитектуре Unity. Хорошо что оно есть и можно использовать, но не выглядит как решение всех проблем, а рекламируют именно так.
В общем мы пробовали делать матч 3 на ECS Entitas и результаты неочевидные.
Вроде неплохо, но в игровой логике довольно запутанно и склонно к ошибкам.
Возможно, если бы мы писали на классическом ООП, были бы те же проблемы, только сбоку — проблемы были с большим разнообразием взаимодействующих механик.
Можно, конечно, назвать их тупыми, только нас это никуда не приведет. При разработке приложения, рассчитывай, что им будут пользоваться и младенцы, и бабушки в 90 лет.
Сами себе противоречите.
Очевидно, что нужно прежде всего рассчитывать, что приложением будет пользоваться целевая аудитория в самом широком смысле. Для них и нужно делать, а не для младенцев и бабушек. Если конечно они в нее не входят.
Интересная методика.
В целом она пересекается с другими рекомендациями по созданию кода — многие рекомендуют сосредоточиться в первую очередь на читаемости. Тут и именование, и корректное использование терминов, и декомпозиция ради понятности.
Принцип похож на создание «языка предметной области», на основе которого создаются программные сущности.
В ходе обсуждения и создания как можно более понятных терминов естественным образом структура программы и взаимодействия приходят к более понятному виду.
А сравнивали подход с типичными реализациями пересечений? Геометрическое пересечение всех ребер и проверка, что точки внутри выпуклого многогранника?
Тяжело интуитивно представлять такие вещи, но с виду для простых фигур (трех-четырехугольников) там банально меньше операций получится.
Греция.
В Греции евро по понятным причинам вытеснило национальную валюту. После этого из-за собственных косяков, ряда особенностей работы местных банков и случайности (из-за особенностей Греция стала хорошим местом размещения средств) Греция получила большую ответочку от чужого (общемирового) кризиса.
В обычных условиях с такими проблемами в экономике происходит автоматическая девальвация — это выравнивает ставки по счетам.
Греция не могла воспользоваться этим механизмом, поэтому проблемы там до сих пор, хотя вроде как всей Европой решают.
Я, если что, профан в экономике такого уровня, но вот есть подкаст, там освещают научно-популярные аспекты экономики и разбиралась эта тема. news.tut.by/economics/455286.html
Мне кажется, что ребята, делающие навигаторы и карты для них и так в теме — разгрузка улиц делается на основе как данных реального времени, так и статистических данных (иначе при планировании длительных маршрутов информация бы устаревала), кроме того, пробки в нетипичных местах так же будут видны для них и они могут это учитывать.
Если для текущей инфраструктуры возможно распределить нагрузку и уменьшить общее количество пробок ценой периодических пробок в нетипичных местах — так и нужно делать.
Невнимательности водителей из-за использования телефонов — отдельная проблема, с которой да, нужно бороться.
Что касается управления инфраструктурой — по идее городские службы должны сотрудничать с навигационными сервисами. Что значит мешают.
Факт заключается в том, что пропускную способность дорог не обманешь, а городская инфраструктура в большинстве городов не проектировалась под такое количество машин.
Обычно мешает то, что квадрат не соблюдает контракт прямоугольника для многих операций.
Наследование должно удовлетворять требованию X является Y, а квадрат выполняет его не всегда.
Нет, цель абстракции как раз в том, чтобы не разбираться как оно работает.
От программиста требуется только понять, что эта сущность должна сделать и какие ей нужны для этого данные.
Я описывал примеры слабости системы типов питона. Речи о формальном определении ее строгости/слабости не шло.
Но вообще Я не уверен в том, что утиная типизация все же относится к сильной проверке типов. Ошибки с динамической типизацией в этом смысле очень похожи на ошибки некорректных данных, характерные для слабой типизации.
У нас в практике был прекрасный случай, когда одинаковый метод отложенного запуска, переопределенный, принимал в int — миллисекунды, а во float — секунды.
WaitUntil(1) и WaitUntil(1f) имели разное в 1000 раз поведение.
Мне кажется, что при проектировании кода нужно регулярно думать даже о защите от самого себя в будущем, что уж говорить о коллегах.
Дело не в доверии к коллегам, все ошибаются, входящие данные врут, нужно пытаться обеспечивать отказоустойчивость на всех возможных уровнях, насколько это возможно.
Утиная типизация объектов, возможность передать объект, еще не имеющий нужного интерфейса (или просто другой объект) в метод, рассчитывающий на этот интерфейс. Иногда — в рантайме.
Возможно вы имели в виду конкретные фреймворки для реализации DI контейнеров?
DI можно сделать без фреймворков явно через конструкторы, с честным composition root
Если под «моделью» вы понимаете меш и текстуры — из основного потока можно вытащить сами расчеты — то есть создание списков точек для меша и битмапа для текстуры.
Для процедурно генерируемых это основная часть расчетов.
А создавать сам меш и текстуру — в основном.
Не согласен с этим тезисом. Мне кажется, это в очередной раз борьба с ветряными мельницами.
В случае имитации все, разумеется, понятно — это не личность.
А вот по поводу копии — нет никакой «изначальной» и «настоящей» личности, это абстракция. Если копия будет достаточно точной — разницы не будет. Если имитация искусственными нейронами будет неточной — не важно, копированием или миграцией будет осуществляться переход, разница все равно будет заметна.
В остальном — понейронное копирование живого мозга ничем не отличается от разрушающего копирования или неинвазивного копирования, кроме иллюзии цельности.
Важен исключительно технологический вопрос — какой метод будет проще и надежнее.
Само понятие «личности» как объекта — это естественное следствие нашего абстрагирования. Из него растет парадокс корабля Тесея.
На самом деле ты сам каждый миг — своя «неточная» копия. Твое сознание угасает каждую ночь и воскресает вновь. Из-за особенностей нашего мозга/тела ты лишен возможности видеть свои копии — поэтому наличие своей копии кажется тебе ненастоящим «Я», а смерть оригинального носителя — его смертью. Как дикарь, которому показали телефон и он не может осознать концепцию передачи голоса — ему кажется, что человека спрятали в трубку.
Если ты хочешь бессмертия — нужно развеять эти иллюзии. Наоборот, удобно видеть и осознавать свои копии, понимать, что они — это ты и твоя смерть — это смерть нескольких дней памяти, которыми вы отличаетесь от своей копии. Это даст новые возможности.
Правовые вопросы, вопросы надежности копирования, вопросы этики, вопросы злоупотреблений (а вдруг твоя копия — не твоя, ее тайно модифицировали и теперь она выглядит как ты а на самом деле тайный промоутер кока-коллы!) — так или иначе не относятся к теме, могут и будут решены, пусть это и изменит общество до неузнаваемости. Опять же — кока кола модифицирует твой мозг прямо сейчас, наживую, только неинвазивно — и никто не жалуется.
Все же объяснение натыкается раз за разом на то, что вот смотрите, как мы хорошо утилизируем кеш процессора и обрабатываем батчи объектов.
А люди ценят юнити за быстрое прототипирование, удобный редактор и готовые компоненты.
Всем пофиг на эффективность.
В общем сложно все. Сейчас выглядит как сбоку приклеенное к архитектуре Unity. Хорошо что оно есть и можно использовать, но не выглядит как решение всех проблем, а рекламируют именно так.
В общем мы пробовали делать матч 3 на ECS Entitas и результаты неочевидные.
Вроде неплохо, но в игровой логике довольно запутанно и склонно к ошибкам.
Возможно, если бы мы писали на классическом ООП, были бы те же проблемы, только сбоку — проблемы были с большим разнообразием взаимодействующих механик.
Похоже что так и есть.
Чужую статью, впаривающую dots
Сами себе противоречите.
Очевидно, что нужно прежде всего рассчитывать, что приложением будет пользоваться целевая аудитория в самом широком смысле. Для них и нужно делать, а не для младенцев и бабушек. Если конечно они в нее не входят.
В целом она пересекается с другими рекомендациями по созданию кода — многие рекомендуют сосредоточиться в первую очередь на читаемости. Тут и именование, и корректное использование терминов, и декомпозиция ради понятности.
Принцип похож на создание «языка предметной области», на основе которого создаются программные сущности.
В ходе обсуждения и создания как можно более понятных терминов естественным образом структура программы и взаимодействия приходят к более понятному виду.
Тяжело интуитивно представлять такие вещи, но с виду для простых фигур (трех-четырехугольников) там банально меньше операций получится.
В Греции евро по понятным причинам вытеснило национальную валюту. После этого из-за собственных косяков, ряда особенностей работы местных банков и случайности (из-за особенностей Греция стала хорошим местом размещения средств) Греция получила большую ответочку от чужого (общемирового) кризиса.
В обычных условиях с такими проблемами в экономике происходит автоматическая девальвация — это выравнивает ставки по счетам.
Греция не могла воспользоваться этим механизмом, поэтому проблемы там до сих пор, хотя вроде как всей Европой решают.
Я, если что, профан в экономике такого уровня, но вот есть подкаст, там освещают научно-популярные аспекты экономики и разбиралась эта тема.
news.tut.by/economics/455286.html
То, что это тяжело представить и вообразить, не меняет факта.
Если для текущей инфраструктуры возможно распределить нагрузку и уменьшить общее количество пробок ценой периодических пробок в нетипичных местах — так и нужно делать.
Невнимательности водителей из-за использования телефонов — отдельная проблема, с которой да, нужно бороться.
Что касается управления инфраструктурой — по идее городские службы должны сотрудничать с навигационными сервисами. Что значит мешают.
Факт заключается в том, что пропускную способность дорог не обманешь, а городская инфраструктура в большинстве городов не проектировалась под такое количество машин.
Наследование должно удовлетворять требованию X является Y, а квадрат выполняет его не всегда.
От программиста требуется только понять, что эта сущность должна сделать и какие ей нужны для этого данные.
Но вообще Я не уверен в том, что утиная типизация все же относится к сильной проверке типов. Ошибки с динамической типизацией в этом смысле очень похожи на ошибки некорректных данных, характерные для слабой типизации.
WaitUntil(1) и WaitUntil(1f) имели разное в 1000 раз поведение.
Дело не в доверии к коллегам, все ошибаются, входящие данные врут, нужно пытаться обеспечивать отказоустойчивость на всех возможных уровнях, насколько это возможно.
DI можно сделать без фреймворков явно через конструкторы, с честным composition root
Для процедурно генерируемых это основная часть расчетов.
А создавать сам меш и текстуру — в основном.