"В правом столбце удваивайте число столько раз, сколько цифр содержит число в левом столбце" Зачем вводить читателей в заблуждение? Так не работает. Умножаем 25 на 25
25 - 25 12 - 100 (удвоили дважды, потому как к левом столбце две цифры) 6 - 200 3 - 400 1 - 800
Ответ 800+400+25=1225. Да?
На самом деле удваивать надо всегда только один раз. Сам метод - хорошее упражнение для обучающихся программированию на инвариант цикла. Ну или для детей, изучающих математику - на индукцию. Доказывать удобнее, если представить, что сложение мы ведем по мере добавления строк и работаем с тройками чисел x, y, z. Вначале полагаем, что x и y наши множители, а z=0. Дальше делаем следующее:
при четном x уполовиниваем x, удваиваем y, переписываем z.
при нечетном x делаем то же, но дробную часть x отбрасываем, а z увеличиваем на y из предыдущей строки
Тогда в каждой строке x*y+z равно произведению первоначальных чисел. Поскольку в конце x=1, нам остается только подсчитать y+z. База индукции очевидна, шаг при четном x - тоже, шаг при нечетном x предоставляется читателю в качестве самостоятельного упражнения :)
Сомневаюсь, чтоб сильный программист такое заметил — просто потому, что это неверно (когда прямоугольники для колец перекрываются, см пример В), о чем частично и был спич.
увы, но программа это далеко не точное отображение реальности
Конечно, нет. И вообще программа и реальность — вещи, слава богу, разные пока. Речь была о том, что придумывание отображения программы в реальность помогает оценить непротиворечивость объектной модели, поскольку непротиворечивоть реальности тогда за нас. Я б сказал, что это такой brain design pattern — concept reuse: мы придумываем привязку к тому, про что уже известно, что оно работает, и тем самым экономим ресурсы мозга (не тратя их на всесторонний анализ чего-то совершенно нового).
При этом да, вариантов проекции в реальность может быть более одного. По поводу Вашего варианта (в пределах этой игрушечной задачи) я имею такие сомнения:
1. Ваш test case демонстрирует задачу, которая в принципе не имеет решения (как выглядит финальная картинка?). Кейс, о котором шла речь в статье, имеет решение — финальная картинка понятна, просто надо не испортить ее по дороге.
2. Ваша проекция — это не проекция в реальность, это проекция в другой программистский опыт (что за бэкап на реальном объекте, типа деревянного кружочка?).
3. Если уж говорить про бэкап, использование одного и того же места и для бэкапа и для работы — вряд ли хорошая практика (см. первую букву в слове SOLID).
Ага. По-моему у Дейстры в «Дисциплине программирования» этот принцип сформулирован — сначала сделаем программу работающей, а уж потом работающей быстро.
Спасибо за детальную рецензию. Возможно, и вправду стоит написать более подробную мораль в конце этой истории, просто опасаюсь переборщить — статья и так-то вышла довольно морализаторская. Если коротко:
«Мы» (по отношению к тупым программам) — это, допустим, тимлиды, которых задолбала демонстрация изобретательности, ведущая к нетривиальным багам. А ежели не тимлиды, то буквально мы все, на которых эти баги потом высыпаются в виде неработающего чего угодно (ибо внутри этого чего угодно в наше время наверняка сидит какая-нибудь такая программа).
«Сильный» программист просто знает правильный порядок…
мне сложно представить мысли человека, выбравшего В или С
Все так и есть. Но тот факт, что мысли для случаев В, С представить сложно не спасает от появления таких программ. То есть то, что этому сильному «просто», другому, оказывается, совсем непросто (даже в таком, казалось бы, игрушечном случае). Вопрос как раз в том, можно ли это вот «просто» как-то вербализовать и поделиться с теми, кому непросто? Ну вот ровно это я и попытался сделать.
Ну вот как-то на той планете, где я живу это далеко не самый страшный оверхед. Вы ж понимаете, что просто щелкая какой-нибудь DoubleBuffering в WinForms Вы мгновенно получаете двойной оверхед. Вот когда кто-нибудь невзначай забабахивает квадратичный (а то и кубичный) алгоритм вместо линейного — это да, жесть. И то живет порой в релизе до поры до времени.
"В правом столбце удваивайте число столько раз, сколько цифр содержит число в левом столбце"
Зачем вводить читателей в заблуждение? Так не работает. Умножаем 25 на 25
25 - 25
12 - 100 (удвоили дважды, потому как к левом столбце две цифры)
6 - 200
3 - 400
1 - 800
Ответ 800+400+25=1225. Да?
На самом деле удваивать надо всегда только один раз. Сам метод - хорошее упражнение для обучающихся программированию на инвариант цикла. Ну или для детей, изучающих математику - на индукцию. Доказывать удобнее, если представить, что сложение мы ведем по мере добавления строк и работаем с тройками чисел x, y, z. Вначале полагаем, что x и y наши множители, а z=0. Дальше делаем следующее:
при четном x уполовиниваем x, удваиваем y, переписываем z.
при нечетном x делаем то же, но дробную часть x отбрасываем, а z увеличиваем на y из предыдущей строки
Тогда в каждой строке x*y+z равно произведению первоначальных чисел. Поскольку в конце x=1, нам остается только подсчитать y+z. База индукции очевидна, шаг при четном x - тоже, шаг при нечетном x предоставляется читателю в качестве самостоятельного упражнения :)
Конечно, нет. И вообще программа и реальность — вещи, слава богу, разные пока. Речь была о том, что придумывание отображения программы в реальность помогает оценить непротиворечивость объектной модели, поскольку непротиворечивоть реальности тогда за нас. Я б сказал, что это такой brain design pattern — concept reuse: мы придумываем привязку к тому, про что уже известно, что оно работает, и тем самым экономим ресурсы мозга (не тратя их на всесторонний анализ чего-то совершенно нового).
При этом да, вариантов проекции в реальность может быть более одного. По поводу Вашего варианта (в пределах этой игрушечной задачи) я имею такие сомнения:
1. Ваш test case демонстрирует задачу, которая в принципе не имеет решения (как выглядит финальная картинка?). Кейс, о котором шла речь в статье, имеет решение — финальная картинка понятна, просто надо не испортить ее по дороге.
2. Ваша проекция — это не проекция в реальность, это проекция в другой программистский опыт (что за бэкап на реальном объекте, типа деревянного кружочка?).
3. Если уж говорить про бэкап, использование одного и того же места и для бэкапа и для работы — вряд ли хорошая практика (см. первую букву в слове SOLID).
«Мы» (по отношению к тупым программам) — это, допустим, тимлиды, которых задолбала демонстрация изобретательности, ведущая к нетривиальным багам. А ежели не тимлиды, то буквально мы все, на которых эти баги потом высыпаются в виде неработающего чего угодно (ибо внутри этого чего угодно в наше время наверняка сидит какая-нибудь такая программа).
Все так и есть. Но тот факт, что мысли для случаев В, С представить сложно не спасает от появления таких программ. То есть то, что этому сильному «просто», другому, оказывается, совсем непросто (даже в таком, казалось бы, игрушечном случае). Вопрос как раз в том, можно ли это вот «просто» как-то вербализовать и поделиться с теми, кому непросто? Ну вот ровно это я и попытался сделать.