Ну если ты будешь делить 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, она теоретическая в современной парадигме, потому что в схеме Алиса-Боб, оба участника
секретной переписки должны обладать этой книгой или блокнотом. Через что или через какой
протокол Алиса и Боб синхронизируют книгу - это открытый вопрос.
ничем архитектурно не обоснован. Ты мог поставить и 1 милисекунду. И мог поставить 24 часа.
У тебя код работал бы в обоих случаях. Но в одном ты получил бы безсмысленную нагрузку
которую трудно обосновать. В другом случае сильный лаг для бизнеса например. Данные
изменились а реакция прилетела через сутки.
Так вот. Я не знаю как принято координировать процессы и потоки в DotNet. Но в идеале
те потоки которые модифицируют эти словари должны пробуждать твой поток ото сна.
И в этом случае будет какая-то логика реактивности.
Как это сделать - наверное много вариантов. Может какая-то BlockingQueue или другая
структура. Но этот позорный таймаут надо убрать.
Получается что ты сам решаешь в какой момент времени зарождается новая задача.
А в идеале тебе должна приходить какая-то нотификация из внешней системы.
Ну например из MQ.
Можно было-бы передавать строку через стек. Типа std::string и переворачивать ее на ходу.
Но это с друой стороны тоже коллекция символов.