Catmengi, как только массив примитивов покидает границы платформы (x86, Itanium, ARM)
у тебя появляется вопрос "endiannes", тоесть в каком порядке байты хранятся в машинном слове.
Стандарт С обходит этот вопрос стороной. Он - как-бы отдает это на откуп нижнему уровню
и ты должен заранее гарантировать что клиент и сервер будут не просто написаны на "C" но
и также будут иметь одинаковую архитектуру железа и порядка байтов в машинном слове.
вы - ошибаетесь. Банки, например его все еще используют. Более
того они его не спешат заменять на REST протоколы, потому что им
важно поддерживать механизмы описания спецификаций. И SOAP
все еще предоставляет такие механизмы.
Тут либо PHP плох, либо сам писатель. Следствием этой боли должен быть какой-то
SOAP клиент который решает задачу. Потому что со стороны это выглядит как
безсилие языка перед технологией.
Ну. Тема топика не про это. У вас может быть качественный JPEG и очень плохое,
прошедшее 100 преобразований PNG изображение. И тут недостаточно будет
мерять свойства конейнера изображения. Ну .. если-б я был автором вопроса
то меня как раз интересовало бы само изображение.
Для JPEG мы знаем эти артефакты. Есть размеры JPEG-фрейма (типа 8х8) и по этой границе
можно предполагать появление резких изменений уровня сигнала. И зная этот период
и частототу мы можем ее эффективно давить полосовым фильтром. И даже более
того, мы точно знаем фазу этого сигнала.
В наше время ИИ - (машинное зрение) это такой себе швейцарский ножик, который
можно везде прикрутить но в первую очередь я-бы спросил у производителя
игры, какие есть плагины или расширения и заложена ли возможность в саму игру
добавлять это.
Ну если ты будешь делить 100 рублей на 3 человека то у тебя выйдет 33 рубля и 33 копейки на рыло.
И еще одна копейка в остатке которую просто некуда деть. И нет решения у этого вопроса
как просто решение чисто организационное.
Для очент точного счета монет ты можешь создать дробно рациональный тип вида m/n
но толку тебе от него будет тоже мало. Если речь идет о выдаче монет то число монет
все равно будет целым как ни крути.
Я делал подобное на Java. Архив в целом изменить нельзя. По крайней мере те API
средства что я видел рассматривают любой архив как множество ReadOnly ZipEntities и какдая
Entity это stream из байтов. Можно прочитать весь архив и все файлы и на лету видоизменить
нужный файл и записать все это в новый zip архив а старый удалить.
Давать готовые исходники не буду. У меня их щас нет но я думаю с помощью умных чятов
вы найдете рабочий шаблон.
Ох и душный преподаватель. Ну тут как-бы вводить массив понятно как.
Но если допустим числа были 1,2,3,4,5 то при обратном ходе рекурсии из стека
мы их будем печатать так
5,4,3,2,1
Если бы в системе было 2 стека тогда можно былоб както перехитрить порядок вывода.
Да без какого-то грязного трюка с адресами - даже неясно что делать. Хачить стекфрейм?
Во многих технических заданиях на LLM никто никогда не ставит acceptance criteria.
Это означает что любой бредогенератор наподобие Марковской Сети тоже подходит
под данный топик.
Но нам здесь всем очевидно что между генератором бреда и ChatGPT все таки сущесвтует
разница.
И соотвественно возникает следующий вопрос, а можем ли мы написать такие SR, при
которых все таки для между генератором бреда и LLM которая обучена на дешевом процессоре
и малом датасете все таки сможем провести границу?
NSA-bot, она теоретическая в современной парадигме, потому что в схеме Алиса-Боб, оба участника
секретной переписки должны обладать этой книгой или блокнотом. Через что или через какой
протокол Алиса и Боб синхронизируют книгу - это открытый вопрос.
у тебя появляется вопрос "endiannes", тоесть в каком порядке байты хранятся в машинном слове.
Стандарт С обходит этот вопрос стороной. Он - как-бы отдает это на откуп нижнему уровню
и ты должен заранее гарантировать что клиент и сервер будут не просто написаны на "C" но
и также будут иметь одинаковую архитектуру железа и порядка байтов в машинном слове.
Иначе RPC не сработает.