Обновить
25
0
Alexey Plokhikh @Lelushak

Solution Architect

Отправить сообщение
Если верить этому тексту, то не совсем

Около 50% выручки кинотеатр отдаёт киностудии, которая в свою очередь вычитает из полученной суммы расходы на производство прокатных копий и рекламу. В 2007 году расходы на изготовление копий и рекламу одного фильма составили в среднем $40 млн., что превысило средний доход киностудии от проката фильма.

В 2007 году общий доход крупнейших киностудий составил $42,3 млрд., из которых лишь 10% поступлений обеспечили кассовые сборы кинотеатров. Остальная выручка была получена от продажи DVD-дисков, а также лицензий кабельным и сетевым телеканалам.
Вы вообще о чем? Почему вы считаете экономию в США через российские цены? Ничего не смущает?
>1. Это почти никогда не нужно. Большого количества подобных филдов не бывает обычно.

В приложениях с UI их очень много, взять хотя бы INotifyPropertyChanged.
Во-первых — под «европейским законом о защите персональных данных» подразумевается GDPR. Он действует только для Европейского Союза, и Россия де-факто не имеет к нему никакого отношения.

GDPR работает в отношении любой компании, которая обслуживает хотя бы одного гражданина ЕС, независимо от того, где он или она находятся территориально. Так что если российская компания не хочет получить штрафы в Европе, то GDPR исполнять она будет для всех, ведь точно сегрегировать пользователей из России по их гражданству у них вряд ли получится.

Да уж, и правда
Даже для исходного примера неправильно, как ниже заметил s_suhanov. Вроде удалось обобщить, проверил для 1 <= money <100000, 1 < price < 50, 2 < wrappers < 50— расхождений с итеративным алгоритмом нет. Буду рад, если кто-нибудь опровергнет.

Решение
Сначала нужно определить, сколько денег мы вообще можем потратить, так как обёртки в доллары не конвертируются.

На первой итерации каждый потраченный доллар гарантированно принесёт нам 1/price шоколадок. На второй: 1/price*wrappers и так далее. Снова получается геометрическая прогрессия. Первый шаг не зависит от wrappers, поэтому в прогрессию мы его не включаем. Теперь нужно посчитать s(n), — где n — это степень, при которой wrappers^n >= workMoney (по-хорошему, здесь должно быть просто «больше», но из-за потери точности даже в Decimal и округления вниз в некоторых ситуациях получается число вроде 47.9999999996 вместо 48), a0 = 1/wrappers * price.

Финальный шаг: сложим 1/price и s(n) и умножим на workMoney. Округляем в меньшую сторону.

Примеры:

money = 15, price = 1, wrappers = 3
workMoney = 15
n = 3, s(3)=1/3 + 1/9 + 1/27 = 14/27 ~ 0.4815
1 + 0.4815 = 1.4815

result = 15 * 1.4815 ~ 22.22 = 22

money=17, price = 3, wrapers = 5
WorkMoney = 15
n = 2, s(2) = 1/5*3 + 1/25*3 = 1/15 + 1/75 = 7/75
1/3 + 7/75 = 32/75 ~ 0.427

result = 15 * 0.427 ~ 6,3 = 6

Код:

private static int ChocolateCount(int money, int price, int wrappersPerOneChoco)
{
	var workMoney = money - (money % price);

	var stepsCount = 0;
	int wrappers = 1;

	while (wrappers <= workMoney)
	{
		stepsCount++;
		wrappers = wrappers * wrappersPerOneChoco;
	}

	var chokosPerDollar = 1 / (double)price;
	var additionalChokosByCurrentStep = 1 / (double)price;

	for (int i = 0; i < stepsCount; i++)
	{
		additionalChokosByCurrentStep = additionalChokosByCurrentStep / wrappersPerOneChoco;
		chokosPerDollar = chokosPerDollar + additionalChokosByCurrentStep;
	}

	return (int) (workMoney * chokosPerDollar);
}
Я не прав. В написанном выше не учитываются возможные остатки на разных итерациях. После исправлений удалось найти решение для частного случая данных условий, но обобщить не получается :(
Возможно.
Для примера из условия:

Доллар даёт одну шоколадку; шоколадка даёт одну обертку; одна обёртка даёт 1/3 шоколадки.

Тогда, при условии, что у нас бесконечное количество долларов, мы за каждый доллар получим:

1 + 1/3 + 1/9 + 1/27… шоколадок. Это убывающая геометрическая прогрессия. Если посчитать её сумму, то получим 1.5 шоколадки за каждый потраченный доллар.

Однако, у нас не бесконечное количество долларов. Для того, чтобы узнать, сколько шоколадок мы получим за один доллар, достаточно узнать, на каком шаге вычисления прогрессии мы остановимся:

x<=3: 1
3<x<=9: 1 + 1/3
9<x<=27: 1 + 1/3 + 1/9


Тогда решение задачи для примера из условия выглядит так:

x = 25
3^1 = 3 < x
3^2 = 9 < x
3^3 = 27 > x => нужно вычислить три шага

1 + 1/3 + 1/9 = 13/9

Теперь просто перемножаем: 15 * 13/9 = 21,6666666 ~ 21 (округляем всегда в меньшую сторону). Решение можно представить в обобщенном виде для любых «money, price, wrap».
Ручной перебор не представляет никакой опасности, разве что в совсем вырожденных случаях вроде «123456».

А вот у меня хром падает в аналогичной ситуации. Правда на стационарнике.

Немного дополню ваш ответ для любопытствующих: любой вызов метода от объекта происходит через обращение к сгенерированному для типа статическому классу, в который неявно отдаётся рабочий объект. Разница проявляется на уровне MSIL кода: для статических методов (в том числе extension) используется OP-код «call», который просто вызывает метод без каких-либо проверок, тогда как для обычных методов используется «callvirt» (при условии, что компилятор уверен, что проверка в данном контексте имеет смысл, иначе соптимизирует в call), который сначала проверяет объект на null и при случае выкидывает NullReferenceException.
Статические методы можно вызывать на объекте, который равен null.
Робо-ограбление робоконтейнеровоза робоковбоями
Логично != интуитивно
У вас очень радужное представление о качестве современного образования в отечественных(?) IT вузах. Могу вас заверить, что 99% айти выпускников знают про «алгоритм Хаффмана» и «Spray-деревья» не больше вашего, потому что их принципиально нет в курсах, либо они проходится мимолётом. Никаких действительно фундаментальных знаний, кроме основ высшей математики, вы там не получите. А математика закончится за два-два с половиной года и будет её относительно мало.

Не могу, правда, говорить за самые топовые российские университеты, может там дела обстоят получше.
>Вряд ли можно спорить с тем, что полноценный искусственный интеллект все таки будет изобретен в недалёком будущем

Можно спорить.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность