Что если менять колеса в два раза чаще? Решит ли это проблему водителя с пропуском очередной смены покрышек?
Это может уменьшить неоптимальность износа, все зависит от того, по какой причине он пропускает смену. Если у него, например, стоит какая то напоминалка и он одну из них пропустил, то минимизирует, а если он просто забыл, то это не поможет. Но если есть еще какой то запас, то после того как он вспомнил, он может скорректировать план по смене колес…
И можно еще придумать много если, и потом придумывать много сложных алгоритмов оптимизации, поэтому предлагаю лучше сделать все что бы не допустить такую забывчивость (а следовательно и не допустить усложнение кода, тестирование, потенциальные ошибки, трату ресурсов — мы же говорим о задачи для программиста). Сделаем напоминание и контроль за выполнением, а может и вообще сделаем замену колес за него.
P.S. Но это все таки уже другая задача…
Нет, если проморгал, то максимум уже не получится. С другой стороны, если говорить о реальном мире, тогда вопрос: «Выйдет ли покрышка из строя проехав ровно свой ресурс?». Это риторический вопрос, предлагаю дальше не раздувать тему…
Именно так. Сколько он сделал за предыдущий первому? 0!
С чего вы это взяли? По условию задачи он все таки делал какую-то работу и делал он ее с двукратным приростом, так что в 18-ый день он полностью (100%) ее закончил.
Это (100%) опять же по условию задачи, ваш расчет (0%×2=0%) противоречит данному условию, оно бы никогда не выполнилось.
Важно, с какой доли он начал. Если с нуля, то он никогда не кончит.
Человеку дается задание...
Логично предположить что начал он его с 0 и в первый день сделал какую то часть работы.
Я не вижу здесь никакого подвоха…
Никакой ловушки. Он увеличивает прогресс вдвое, за предыдущий день, поэтому брать надо достигнутый прогресс на конец дня. А вообще тут не важно сколько он сделал за день…
Ответ
Считать надо с конца:
18 дней: 100%
17 дней: 100% / 2 = 50%
16 дней: 50% / 2 = 25%
Ответ: 16 дней
Меняя по очереди каждое колесо можно проехать 25000 миль.
Посчитать можно например так: полный ресурс всех пяти колес делим на износ всех колеса-мест, получаем сколько будет износ на колесо-месте и умножаем на износ одной шины.
(100000/80000)*20000=25000
100000/80000=1,25 — эти 0,25 это то превышение нормального износа, через сколько надо менять очередное колесо (20000*0,25=5000)
Какое-то замысловатое объяснение у меня получилось…
Вы можете проверить конфликт брендов по всемирной базе брендов WIPO.
Зашел на сайт, попробовал несколько слов, на каждое слово по несколько страниц зарегистрированных брендов… Как узнать что можно использовать, а что нет? Или остается только: Суперпупербрендкоторогонетвсписках?
Воду пьет норвежец, это вычисляется довольно легко с помощью таблички, или даже в уме.
А вот зебру сразу однозначно с ходу не вычислить, только методом подстановки возможных вариантов, не представляю как это делать в уме без таблички…
Зебру держит японец.
Я вот не пойму, почему нельзя взять лучшее из уже имеющихся эргономичных клавиатур и сделать нормальную. Берем например Sculpt Ergonomic Desktop, добавляем 2 сантиметра справа и делаем не ужатый блок стрелок и home/end/… Убрать тупой переключатель и сделать нормальные функциональные клавиши(можно меньшего размера), esc-f12 сделать нормального размера. Цифровой блок оставить отдельный, выкинуть num lock, дополнительно к стандартным клавишам добавить туда вызов калькулятора, backspace, скобки. Индикаторы подобные caps lock сделать прямо на клавишах, кстати caps lock вообще под сомнением, кто-нибудь им пользуется? Оставить разделенный пробел с возможностью backspace. Дырку по середине можно не делать, там можно разместить что-нибудь полезное, или ничего не размещать. Нормальную защиту от проливания. Ну и конечно без всяких смайлов.
Для полного шика механические клавиши и встроенный аккумулятор с зарядкой от usb, но это только если цена из-за этого не станет заоблачной…
Вот мой рецепт идеальной клавиатуры…
Если утилитарный класс содержит только одну функцию — нужно избавиться от этого утилитарного класса
SOLID (The Interface Segregation Principle)
если функция состоит только из одной строчки — нужно стоит избавиться от этой функции
Это еще почему? А потом исправить ошибку только в одном месте?
если в компоненте находится только 10 строчек кода — нужно удалить этот компонент, если в папке только один файл — нужно избавиться от этой папки, и так далее.
А это почему? Сегодня 1, завтра 100… А компонент у меня еще в 10 местах используется…
И когда несколько тысяч таких, казалось бы незначительных изменений складываются вместе, то в результате получается красивый, лаконичный и минималистичный код, который очень просто читать.
Страшно представить что тогда получится(представил: огромная портянка в которой не видно сути, но зато все детали на виду)…
Дальше не читал… По-моему, Вы отталкиваетесь не от того. Я не против избавления от избыточности, но исходить все-таки надо от другого: будущая поддержка, расширяемость, понятность логики, и др…
Это может уменьшить неоптимальность износа, все зависит от того, по какой причине он пропускает смену. Если у него, например, стоит какая то напоминалка и он одну из них пропустил, то минимизирует, а если он просто забыл, то это не поможет. Но если есть еще какой то запас, то после того как он вспомнил, он может скорректировать план по смене колес…
И можно еще придумать много если, и потом придумывать много сложных алгоритмов оптимизации, поэтому предлагаю лучше сделать все что бы не допустить такую забывчивость (а следовательно и не допустить усложнение кода, тестирование, потенциальные ошибки, трату ресурсов — мы же говорим о задачи для программиста). Сделаем напоминание и контроль за выполнением, а может и вообще сделаем замену колес за него.
P.S. Но это все таки уже другая задача…
С чего вы это взяли? По условию задачи он все таки делал какую-то работу и делал он ее с двукратным приростом, так что в 18-ый день он полностью (100%) ее закончил.
Это (100%) опять же по условию задачи, ваш расчет (0%×2=0%) противоречит данному условию, оно бы никогда не выполнилось.
Логично предположить что начал он его с 0 и в первый день сделал какую то часть работы.
Я не вижу здесь никакого подвоха…
Желтым — колесо в запасе. К концу пути все колеса имеют 100% износ.
18 дней: 100%
17 дней: 100% / 2 = 50%
16 дней: 50% / 2 = 25%
Ответ: 16 дней
Посчитать можно например так: полный ресурс всех пяти колес делим на износ всех колеса-мест, получаем сколько будет износ на колесо-месте и умножаем на износ одной шины.
(100000/80000)*20000=25000
100000/80000=1,25 — эти 0,25 это то превышение нормального износа, через сколько надо менять очередное колесо (20000*0,25=5000)
Какое-то замысловатое объяснение у меня получилось…
Зашел на сайт, попробовал несколько слов, на каждое слово по несколько страниц зарегистрированных брендов… Как узнать что можно использовать, а что нет? Или остается только: Суперпупербрендкоторогонетвсписках?
А вот зебру сразу однозначно с ходу не вычислить, только методом подстановки возможных вариантов, не представляю как это делать в уме без таблички…
Зебру держит японец.
Для полного шика механические клавиши и встроенный аккумулятор с зарядкой от usb, но это только если цена из-за этого не станет заоблачной…
Вот мой рецепт идеальной клавиатуры…
А у тестеровщиков была возможность сказать, что эти клавиши шлак ненужный?
SOLID (The Interface Segregation Principle)
Это еще почему? А потом исправить ошибку только в одном месте?
А это почему? Сегодня 1, завтра 100… А компонент у меня еще в 10 местах используется…
Страшно представить что тогда получится(представил: огромная портянка в которой не видно сути, но зато все детали на виду)…
Дальше не читал… По-моему, Вы отталкиваетесь не от того. Я не против избавления от избыточности, но исходить все-таки надо от другого: будущая поддержка, расширяемость, понятность логики, и др…