Проблема кодирования № 3

Добро пожаловать всем и каждому в третью часть моей серии задач по программированию. Сегодня я делаю кое-что немного другое: я буду включать живое видео о том, как я решаю задачу, в дополнение к моей обычной игре за игрой. Я решил, что разомну свои видео мышцы и начну знакомиться с настройкой видео.

Как обычно, я буду использовать платформу CodeWars, а задание можно найти здесь: Поход в кино.

Не стесняйтесь кодировать вместе! Видео можно найти здесь:

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

Подсказка:

Создайте функцию, которая принимает три параметра: стоимость карты (int), стоимость билета (int) и процент (float) и возвращает количество билетов, необходимых для того, чтобы «система B» стала более рентабельной, чем «система A». Итак, что это за системы? Ну, по сути, речь идет о покупке билетов в кино, которые имеют фиксированную стоимость. В «системе А» стоимость каждого билета не меняется. Например, если билет стоит 10 долларов, то после покупки 3 билетов вы потратите 30 долларов. «Система Б» позволяет покупателю снижать стоимость каждого последующего билета на заданный процент, однако при этом существует фиксированная стоимость карты (подумайте об этом как о членской карте). Например, если стоимость карты 100 долларов, билета 10 долларов, а процент 90%, то 1 билет стоит вам 100 долларов + (10 долларов * 0,9) = 109 долларов. После этого 2 билета стоят 109 долларов + (10 долларов * 0,9 * 0,9) = 109 долларов + 8,10 долларов = 117,10 долларов.

Итак, зачем кому-то тратить так много на «систему Б»? Что ж, как видите, со временем стоимость каждого билета приближается к $0 (бесплатно!). По сути, эта функция предназначена для определения точки перегиба, когда «система Б» начинает дешеветь, чем «система А». Для практических целей нет необходимости округлять доли копейки. Кроме того, в соответствии с инструкциями, при сравнении систем мы должны округлить «систему Б» до ближайшего большого значения.

Мозговой штурм: я уже думаю о создании цикла while для повторения каждой заявки до тех пор, пока «система Б» не станет лучше, чем «система А». Я также собираюсь отслеживать специфический нюанс «системы Б», используя ранее рассчитанную цену билета. Мой псевдокод выглядит примерно так:

  1. Установите переменные для подсчета тикетов и текущего подсчета для sys_a и sys_b.
  2. Продолжайте цикл, пока sys_b › sys_a
  3. Добавьте новую стоимость билетов в обе системы
  4. В конце концов цикл прерывается, и мы возвращаем количество билетов

В моей первой попытке я прошел первый из двух тестов, но в итоге получил ошибку для второго теста, у которого было другое значение для card.

Икота №1

В спешке я случайно жестко закодировал начальную стоимость sys_b в 500, что на самом деле должно быть ценой card. Через несколько минут я понимаю свою ошибку и оба теста проходят!

Икота № 2

Ну, я экспериментировал со знаком >=, но в итоге оставил только >, что означало провал финальных тестов. У меня было подозрение, что это была проблема сразу же, учитывая крайние случаи, которые я видел. Я также упростил свой код, чтобы немного сэкономить память. Эй, каждая мелочь помогает! Вот мое окончательное решение.

В общем, это была довольно прямая проблема. Давайте проверим одно из наиболее эффективных решений:

В ряде других решений использовались библиотеки Python, такие как itertools и scipy, что мне показалось несколько чрезмерным. Когда это возможно, я стараюсь использовать как можно меньше зависимостей. Хотя приведенное выше решение похоже на мое, я укажу на незначительную разницу между эффективностью памяти и эффективностью обработки/времени. С помощью моего метода я сохранил простую переменную предыдущей цены билета «системы Б». Это позволяет просто умножать процент на каждый дополнительный билет — экономия на обработке. Однако при вычислении (ticket * (perc ** num)) на каждой итерации часть памяти сохраняется, но за счет повторного вычисления одной и той же информации снова и снова.

Это все на данный момент! Была ли эта задача слишком простой или в самый раз? Вы решили эту задачу по-другому?

Теперь, когда мой поиск работы в самом разгаре, я думаю, что мой следующий пост будет связан с моим процессом поиска. До скорого!