Не всегда. Допустим в .Net Framework есть лимит на одновременно открытые соединения для сокета. И это значение равно 1000. При этом сервер вообще не загружен. Каждый запрос занимает от 1 до 100мс. Но из за этого лимита throughput очень маленький получается. Причем этот же лимит есть для nginx под виндой.
Т.е. если у нас нечетное число, нам в первую очередь надо его превратить в четное. Для этого надо отнять одну 5,если нет, то единицу.Для четных применяем жадный алгоритм до 5. А дальше 5-ку вычитаем одновременно или с другой 5-ой или с единичкой, чтоб остаток всегда был четным. Если остается одна пятерка, то его пропускаем дальше продолжаем жадный алгоритм. Вроде так правильно.
Спасибо большое, спасли от ненужных транзакций при конвертации монет ))
Самый последний пункт не совсем правильный. Допустим у меня есть монеты 2,5,5,5,1000, а надо получить сумму 1007.
Ваш алгоритм: 1007-5-2*5-2=990 нет решения
Вы правильно заметили, у нас есть 2 числа нечетных. Если они отсутствуют и заданное число нечетная, то решения нет.
В противном случае жадным алгоритмом доходим до 5(если 5 вообще нет, то до конца). И дальше несколько вариантов:
1. Остаток четный, тогда 5-ки отнимаем парами. Если осталась одна 5 и есть еще единица, тогда отнимаем 5-ку и единицу, если единицы нет, то пятерку игнорируем. Продолжаем жадный алгоритм.
2. Остаток нечетный. тогда отнимаем одну 5-ку и делаем остаток четным и переходим к варианту 1
Pflhaiku: Задача выглядит так: люди приходят в магазин, у каждого в кошельке есть купюры. У кого то много, у кого то мало. Есть крупные, так и мелкие купюры. Вам надо купить товар без сдачи. Надо выяснить, можете ли вы это сделать. Если да, то какие купюры использовали.
Армянское Радио: С учетом специфики задачи нашел способ обойтись без перебора. У меня есть купюра с достоинством 1, поэтому в любом случае могу разменять большую купюру на мелкие так, чтоб из большого получить несколько купюр, в сумме которые они дают мне нужное число. Так же в системе есть некий центробанк, с неограниченным количеством денег любого номинала. Из своего кошелька вычитаю как предложил Антон Федорян и допустим набралась сумма 8, нужно набрать 10,а у меня есть купюра номинала 5, я его размениваю в центробанке на мелкие купюры, с обязательным условием чтоб мог получить любым способом 2(скажем 1+1 или просто 2),центробанк мне высылает допустим монеты 2,2,1 и одну двойку я использую.
Олимпиадный вариант не подходит, там купюр не ограниченное количество. За наводку упаковки рюкзака спасибо. Один из подвидов этой задачи идентична с моей задачей
есть возможность консольку переписать как сервис. Поэтому там могут быть неограниченные права. Вопрос именно в том, как лучше тогда обмениваться сообщениями. Сейчас это происходит через файлы, мониторю изменение файла и это служит событием на какое то действие.
ih8write: Я же вам пишу, надо использовать цикл. Лучше всего for
Я бы мог написать вам весь код, но тогда это будет не правильно. Псевдокод есть, осталось превратить его в рабочий код.
Не совсем так. Во первых я использую не реляционную БД, а список событий(Event Store). Пополнение счета - это событие. Я могу сделать отдельную таблицу из событий, когда кем были пополнены счета и сравнить их с таблицей,которую могу получить из банка. Соответственно при выводе денег я и должен знать, откуда она появилась. Мне достаточно знать общую сумму, которую перечислили на счет в банке и сравнить его с суммами, которых внесли на счет клиентов. Как только появится разница, можно запустить проверку и найти "не правильные деньги".
Проверка опять же осуществляется легко, т.к. у меня изначально все события сохраняются и их не возможно удалить. Тут возможен другой случай: увели деньги клиента. Но деньги клиента может снять либо сама компания, либо сотрудники. У клиента будет история всех списаний, поэтому он может пожаловаться, мы проведем проверку и если услуга никакая не была выполнена, то компания эта и возместит ущерб.
По поводу зависаний. Перевод на другой счет - это одно событие. Поэтому если событие в базу записали, значит у кого то спишется, а у кого то прибавятся эти деньги.
Теперь по поводу "черного ящика". В моем случае ее и не должно быть. У каждого события есть уникальный ИД. Поэтому это будет работать примерно так:
1. клиент пополнил баланс на 100 руб - создали событие "баланс пополнен"
2. клиент заказал услугу на 50 руб -
а)пробегаемся по всем событиям и ищем,есть ли отдельная сумма у клиента 50 руб, таких нет
б)создали событие "разделить сумму", у события указываем родительское событие, и два числа, на которых разбили
в)создаем событие "заказана услуга", указываем ИД услуги, сумму и ИД события из п.А, т.е. оттуда сняли одно из чисел.
3.клиент заказал еще раз услугу за 50 руб -
а)пробегаемся по всем событиям и видм что есть отдельная сумма на 50 руб,которую получили в 2Б.
б)создаем событие "заказана услуга", указываем ИД услуги, сумму и ИД события из п.А
4.работники выполнили задачу и менеджер отмечает выполнено
а)создаем событие "задача выполнена", указываем сумму, ИД события с оплатой за эту работу
5.сотрудник хочет обналичивать деньги - пробегаемся по все событиям "задача выполнена" и для каждого создаем событие "деньги выданы", указав ИД события "задача выполнена". И эту сумму выдаем.
При этом менеджер по ИД может проследить всю цепочку, вплоть до пополнения счета.
И я какую-то часть программно могу проверить, не появились ли "левые" события.Например если за услугу деньги перевели 1 раз сотруднику и эту же операцию пытаются повторить еще раз.
Единственный случай, когда не смогу, это если взломщик восстановит всю цепочку, с момента покупки услуги до вывода денег разработчику. Но в этом случае клиент сам может заметить, что были списания с его счета и после проверок деньги свои он получит.