Hollow knight хоть и написана на c# но в качестве фреймворка там юнити (mono или il2cpp), у них garbage collector не перемещает объекты, а в обычном .net более продвинутый который может перемещать.
Берешь сертификат о прививке с госуслуг. Заменяешь qr код на такой чтобы он вел на ту же страницу, но содержал ошибки кодирования. В ошибки кодирования кодируешь ключ.
В обычных нейросетях обучение требует на порядки больше вычислительных ресурсов чем просто анализ используя уже обученную сеть, так что в этом смысле для обычных запросов обычная сеть ничего не анализирует. GPT-4 правда не обычная сеть и скорее всего архитектура у нее сильно сложнее.
Бывают не только уязвимости но и особенности. Например в 5 версии андроида какое нибудь апи публичное, а в более новых оно требует отдельных разрешений. Если приложение написано для 5 версии то запрашивать разрешения оно не будет даже будучи запущенным под 10.
Поздравляю, вы изобрели хреновенький VLIW. Почитайте про его недостатки, и почему не взлетело. Ну а я просто пару пунктов:
Почему бы не пойти дальше и не оставить только одну команду, а операцию по подготовке данных оставим процессору. Он в железе это сможет реализовать быстрее и энергоэффективнее на несколько порядков. Вы думаете он там целый такт умножает число на 8 чтобы исполнить режим адресации "х*8"? Умножение числа на 8 (<< 3) в железе это вообще просто "проводочки перемапить", вряд ли такое будет хоть как то влиять на критический путь любой команды. Зачастую дополнительное время на исполнение более сложных команд вообще только за счет их размера и получается, а тут все команды гигантские.
А почему 4 субкоманды? И что будем делать когда возникнет нужда увеличить до 8? Программы то под 4 написаны. Сейчас есть такое что от нового cpu автоматически старые программы начинают работать чуть чуть быстрее, даже без поднятия тактовой частоты. А тут так не получится, под новый cpu все программы придется перекомпилировать, плюс как то еще интероп чтобы работал - из программы скомпилированной под 8 вызвать функцию (в другой библиотеке) скомпилированной под 4, и получить результат.
Когда все субкоманды предполагается менеджить программисту, на него перекладывается огромный головняк связанный с тем что данные которые мы уже начали считать для команды которая там будет через несколько операций, могли измениться. И компилятор очень часто не сможет просто доказать что эти два указателя никогда не будут ссылаться на одну область памяти например (чтобы начать вычисления над одним тогда как по второму вот вот произойдет запись). А у языков программирования есть модели памяти и прочие обязательства перед программистом. В такую модель команд будет просто не сделать нормальный (эффективный) компилятор с/с++, он будет просто постоянно вынужден прожигать циклы чтобы обеспечить корректность (завершать запись прежде чем начинать чтения для следующих команд). И опять же, в железе это сделать относительно просто, по крайней мере можно увидеть что мы поломали данные которые уже считали недавно и сбросить конвейер (начать заново), получить замедление в этом конкретном случае (в случае если произошел алиасинг), а в основном случае все будет хорошо запайплайнено.
Повторюсь, это все минусы VLIW архитектуры и причина почему она не взлетела.
Не хочу показаться занудным но "Богатство 1% людей превысило состояние остальных 99% жителей Земли" означает что 1% людей владеют >50% ценностей а не >99% ценностей.
Я сначала его пытался вопросами с подковыркой мучать и оно там сыпалось
но потом перешел на всякие креативные задания. Написать текст для квеста, сыграть в игру где он описывает ситуацию а я выбираю вариант действия, попросил имитировать линукс консоль где я походил по папкам и даже удалил кое что что потом отразилось на следующей ls команде.
Это сильно сложнее чем парсер текста. Ничего подобного ранее не было даже близко. Хотя конечное программиста не заменит, пишет код без компилятора бывает что с ошибками, а еще не умеет отвечать "не знаю" и если не знает придумает отсебятину - это пожалуй самый большой минус.
А монитор по дороге не офигеет если через него начнут гнать 200 ватт на подзарядку чего-нибудь? И на его скорости общения не скажется?
Проблема (ИМХО) юсб в том что там в один стандарт пытаются упихать и низкую латенси (для всяких мышек), и высокую скорость (для мониторов), и большие токи (для подзаряди)
А вообще то требования к пропускающей среде для этих трех типов нагрузки практически противоположные
В итоге получается что кабели и т.п. накладывают куда большие ограничения чем сам стандарт, кабель длиннее метров трех вообще найти проблема, а кабель который поддерживает всю спеку стоит как недорогой телефон.
Кроме того, с# не единственный язык в .net экосистеме, и в эти языки далеко не всегда добавляют фичи из с#, а общаться друг с другом они должны. И делают это через атрибуты.
Автор библиотеки сможет пометить так конструктор и свойства, и компилятор будет знать что при вызове этого конструктора можно не требовать задания свойств, а этого - нужно. При этом к содержимому конструктора доступа у него нет.
Ну вообще вероятность появления нового Оумуамуа помноженная на вероятность того что он рандомно попадет в землю куда меньше чем вероятность глобальной катастрофы от других источников и сравнима с вероятностью того что на этом новом астероиде сидят зеленые человечки и нацеливают его в Землю
Основной шанс столкновения с объектами которые постоянно вокруг летают, а не те что один раз залетают в субнептуновую часть солнечной системы.
Hollow knight хоть и написана на c# но в качестве фреймворка там юнити (mono или il2cpp), у них garbage collector не перемещает объекты, а в обычном .net более продвинутый который может перемещать.
в vr то прекрасно можно сфокусироваться на объекте. Потому что картинка, получаемая двумя глазами, отличается.
Читать в vr можно тоже нормально, если разрешение гарнитуры позволит
За нарушение пользовательского соглашения телевизоры меняются местами?
Берешь сертификат о прививке с госуслуг. Заменяешь qr код на такой чтобы он вел на ту же страницу, но содержал ошибки кодирования. В ошибки кодирования кодируешь ключ.
В обычных нейросетях обучение требует на порядки больше вычислительных ресурсов чем просто анализ используя уже обученную сеть, так что в этом смысле для обычных запросов обычная сеть ничего не анализирует. GPT-4 правда не обычная сеть и скорее всего архитектура у нее сильно сложнее.
Бывают не только уязвимости но и особенности. Например в 5 версии андроида какое нибудь апи публичное, а в более новых оно требует отдельных разрешений. Если приложение написано для 5 версии то запрашивать разрешения оно не будет даже будучи запущенным под 10.
У меня если поставить такую маленькую ширину то меню сбоку пропадает совсем, а появляется оно тогда когда места под контент достаточно.
Вот бы все редизайны так
Поздравляю, вы изобрели хреновенький VLIW. Почитайте про его недостатки, и почему не взлетело. Ну а я просто пару пунктов:
Почему бы не пойти дальше и не оставить только одну команду, а операцию по подготовке данных оставим процессору. Он в железе это сможет реализовать быстрее и энергоэффективнее на несколько порядков. Вы думаете он там целый такт умножает число на 8 чтобы исполнить режим адресации "х*8"? Умножение числа на 8 (<< 3) в железе это вообще просто "проводочки перемапить", вряд ли такое будет хоть как то влиять на критический путь любой команды. Зачастую дополнительное время на исполнение более сложных команд вообще только за счет их размера и получается, а тут все команды гигантские.
А почему 4 субкоманды? И что будем делать когда возникнет нужда увеличить до 8? Программы то под 4 написаны. Сейчас есть такое что от нового cpu автоматически старые программы начинают работать чуть чуть быстрее, даже без поднятия тактовой частоты. А тут так не получится, под новый cpu все программы придется перекомпилировать, плюс как то еще интероп чтобы работал - из программы скомпилированной под 8 вызвать функцию (в другой библиотеке) скомпилированной под 4, и получить результат.
Когда все субкоманды предполагается менеджить программисту, на него перекладывается огромный головняк связанный с тем что данные которые мы уже начали считать для команды которая там будет через несколько операций, могли измениться. И компилятор очень часто не сможет просто доказать что эти два указателя никогда не будут ссылаться на одну область памяти например (чтобы начать вычисления над одним тогда как по второму вот вот произойдет запись). А у языков программирования есть модели памяти и прочие обязательства перед программистом. В такую модель команд будет просто не сделать нормальный (эффективный) компилятор с/с++, он будет просто постоянно вынужден прожигать циклы чтобы обеспечить корректность (завершать запись прежде чем начинать чтения для следующих команд). И опять же, в железе это сделать относительно просто, по крайней мере можно увидеть что мы поломали данные которые уже считали недавно и сбросить конвейер (начать заново), получить замедление в этом конкретном случае (в случае если произошел алиасинг), а в основном случае все будет хорошо запайплайнено.
Повторюсь, это все минусы VLIW архитектуры и причина почему она не взлетела.
Не хочу показаться занудным но "Богатство 1% людей превысило состояние остальных 99% жителей Земли" означает что 1% людей владеют >50% ценностей а не >99% ценностей.
Только заминусованные комменты
Я сначала его пытался вопросами с подковыркой мучать и оно там сыпалось
но потом перешел на всякие креативные задания. Написать текст для квеста, сыграть в игру где он описывает ситуацию а я выбираю вариант действия, попросил имитировать линукс консоль где я походил по папкам и даже удалил кое что что потом отразилось на следующей ls команде.
Это сильно сложнее чем парсер текста. Ничего подобного ранее не было даже близко. Хотя конечное программиста не заменит, пишет код без компилятора бывает что с ошибками, а еще не умеет отвечать "не знаю" и если не знает придумает отсебятину - это пожалуй самый большой минус.
А монитор по дороге не офигеет если через него начнут гнать 200 ватт на подзарядку чего-нибудь? И на его скорости общения не скажется?
Проблема (ИМХО) юсб в том что там в один стандарт пытаются упихать и низкую латенси (для всяких мышек), и высокую скорость (для мониторов), и большие токи (для подзаряди)
А вообще то требования к пропускающей среде для этих трех типов нагрузки практически противоположные
В итоге получается что кабели и т.п. накладывают куда большие ограничения чем сам стандарт, кабель длиннее метров трех вообще найти проблема, а кабель который поддерживает всю спеку стоит как недорогой телефон.
Даже то что в с# коде не атрибуты зачастую является атрибутами в il. См. например learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.optionalattribute?view=net-6.0 или learn.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.extensionattribute?view=net-6.0 или даже learn.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.statemachineattribute?view=net-6.0
Кроме того, с# не единственный язык в .net экосистеме, и в эти языки далеко не всегда добавляют фичи из с#, а общаться друг с другом они должны. И делают это через атрибуты.
Автор библиотеки сможет пометить так конструктор и свойства, и компилятор будет знать что при вызове этого конструктора можно не требовать задания свойств, а этого - нужно. При этом к содержимому конструктора доступа у него нет.
Очевидно для случая когда тип, конструктор которого вызываем, уже скомпилирован и находится в сторонней библиотеке
... А еще список всех ранее повторявшихся позиций чтобы после 3 повторений можно было ничью объявить :(
почти наверняка там где получилось 0.30..04 все операции будут работать одинаково
А еще сложение в числах с плавающей запятой коммутативно, т.е. X + Y всегда равно Y + X (но не ассоциативно) (ну и если не брать в расчет NaN+NaN)
Основной шанс столкновения с объектами которые постоянно вокруг летают, а не те что один раз залетают в субнептуновую часть солнечной системы.