В среде Mathcad 13 появилась возможность работы с относительными шкалами температур – см. рис. 1. Поэтому пункт 7 в разделе 1.4 нужно переписать или совсем убрать, вставив вместо него такой текст.
Еще одна причина отказа от работ с единицами измерения в среде Mathcad связана с тем, что разработчики этого пакета непрерывно меняют «правила игры» с отдельными инструментами и, в частности, с «физическими» переменными. Так, функция (оператор) if в некоторых версиях Mathcad допускает разноразмерные величины в разных ветвях альтернативы (Mathcad 11), а в некоторых (12 и 13) – нет (см. рис. 2).
Заперт на разноразмерность в ветвях альтернативы (не вникая в некие «внутремашинные разборки» – механизм static unit checking) имеет то основание, что по идее конкретная переменная (на рис. 2 – это переменная b) в рамках одного расчета не имеет права принимать значение разных (физических) величин – длины и массы, как показано на рис. 2. С другой стороны, данный запрет должен распространяться и на тип переменной в среде Mathcad – булева, целочисленная, вещественная, комплексная, текстовая, символьная… Ведь, во многих языках программирования перед вводом в расчет переменной ее нужно определить (некие «крестины» переменной) – дать ей имя и задать тип данных, которые она будет хранить и который нельзя менять по ходу расчета.
Резон здесь в том, что булева переменная занимает меньше места в памяти машины, чем, например, целочисленная или тем более комплексная. Более того, был запрет, например, на складывание вещественной переменной с целочисленной – последнюю перед этой операцией нужно было конвертировать в вещественную с помощью специальной функции. Все эти операции преследовали в первую очередь вышеупомянутую цель – экономию памяти компьютера, которая в старые времена да и порой нередко сейчас является лимитирующим параметром при решении задач. Mathcad этих ограничений не имеет, но их рецидивы случаются – см. рис. 2.
Другой пример смены «правил игры» – это возможность возведения в дробную степень тех же размерных величин. Как правило, степень единицы измерения – это целочисленная величина от 1 до 3 или в крайнем случае до 4: площадь – это длина в квадрате, объем – в третьей степени, ускорение – длина, деленная на квадрат времени и т.д. Но есть задачи и с дробной степенью единиц измерения. Вот одна из них – довольно известная задача оптимизации.
Требуется определить крейсерскую скорость судна – скорость, при которой удельные затраты на единицу пути будут минимальны. На рис. 3 (отсканированный отрывок из знаменитого учебника Г.М.Фихтенгольца) показано «ручное» решение этой задачи, где единицы длины, времени и скорости как бы полуприсутствуют – где-то их нет, а где-то они есть. В среде Mathcad, как понимает читатель, такое «полуприсутствие» не допускается – единицы в формуле или есть или их нет, и эта категоричность, кстати, может быть еще одним препятствием в использовании этого инструмента. При разумном упрощении и формализации задачи (при построении математической модели) выделяют два слагаемых этих затрат на движение судна. Первое слагаемое пропорционально времени нахождения судна в пути. Оно включает зарплату экипажа, амортизационные отчисления от первоначальной стоимости судна и т.д. Второе слагаемое (стоимость топлива и др.), зависит от скорости судна. Обычно тут для упрощения принимают, что скорость в данной зависимости возводится во вторую степень – см. рис. 3.
Как видно из рис. 3, в данном «классическом» решении довольно хитро («эмпирически») обходится вопрос о единицах измерения (рубли, мили, км, часы), присутствовавших в задаче: в самом расчете их вроде нет, но они всплывают в ходе решения задачи и в ответе.
Давайте перерешаем эту задачу в среде Mathcad – включим в решение единицы измерения (они, как мы
знаем, позволяют избегать некоторых ошибок, которые могут возникнуть при
составлении самой матмодели, и дополняют решение очень уместными комментариями)
и заодно будем считать, что скорость возводится не во вторую степень, а в
степень n
(переменная, а не константа).
Можно предположить, что двойка в степени скорости – это некое допущение, направленное на упрощение решения задачи через взятие производной (рис. 3). Ведь, стоимость топлива зависит и от его расхода (известный принцип «Оптовому покупателю скидка»), а расход топлива – от режима работы двигательной установки (его мощности). Мощность же двигателя определяет его скорость по довольно сложному закону, предельное упрощение которого дает вышеотмеченный квадрат (рис. 3). Мы почему так подробно описываем эту зависимость – ниже будут приведены примеры, вернее, даны подходи к построению еще более слабоформализованных, если так можно сказать, задач оптимизации.
На рис. 4 показано решение задачи о крейсерской скорости судна. Задача выложена на MAS по адресу http://twt.mpei.ac.ru/MAS/Worksheets/Opt_velosity.mcd, что дает возможность читателю «поиграть» переменными a, b и n и видеть результат – числа и точки на графике. Как мы уже отметили, в «классическом» варианте решения задачи о скорости судна (рис. 3), вопрос о размерности переменных а и b, «дипломатично» обойден, но в среде Mathcad мы этого делать не будем. На рис. 5 показана область (Area), скрытая в расчете на рис. 4, где исходным величинам приписываются нужные единицы измерения. Все хорошо, но документ, показанный на рис. 4 и рис. 5, работает в среде Mathcad 11, но перестает работать в Mathcad 12 и 13. Суть возникающей при этом ошибки раскрывает рис. 6 – в Mathcad 12 и 13 дробная степень единицы может быть записана только константой.
Далее автор переходит к специфическим тексам, по поводу которых один
читатель высказался так: «Вопрос от простого смертного по книге Mathcad 12.
Зачем в книге по ходу описания операторов и функций напихано куча сравнений с
другими программами, которые возможно не знакомы для читателя, а если даже и
знакомы, то большинство примеров бесполезны и только забивают голову и
отвлекают внимание от самой сути. Зачем давать примечания, которые забегают по
теме на несколько глав вперед? Зачем выражаться "базарным" языком,
чтобы потом нагромоздить книгу объемными сносками?». Немного отвлечем внимание
читателя.
Проблему поиска оптимума, зависящего от двух конфликтующих составляющих (часовые и «километровые» расходы, если вернуться к нашей задаче о крейсерской скорости судна – см. рис. 4), можно преломить и на другие случаи, даже несколько экзотические.
Наблюдая за судьбой одаренных актеров в наше непростое перестроечное и постперестроечное время, можно отметить, что некоторые из них часто теряют свое артистическое лицо, любовь и уважение зрителей.
Талантливый артист может в трудное для него время начать хвататься за любые, даже непритягательные роли в «мыльных» сериалах, в рекламе, в различных TV ток-шоу и т.д., что часто ведет к его деградации, если не как актера, то как художника – человека, обладающего не только талантом и профессиональными навыками, но и некой артистической харизмой. С другой стороны, полный отказ от предлагаемых не очень престижных ролей может увести артиста в полное забытье. Нужно уметь проплыть между этими «Сциллой и Харибдой» – сниматься оптимальным образом.
Другой пример, более близкий к теме поиска оптимума в среде математических пакетов. Фирма MathSoft – это, как уже отмечалось в предисловии книги, сугубо коммерческая организация, основная цель которой – получение прибыли. Прибыль же в значительной степени зависит от ценовой политики фирмы – от стоимости «дешевого» пакета Mathcad и дорогого (без скобок) пакета Mathcad Application Server (MAS). Эти два пакета неким образом конфликтуют друг с другом. Появление на рынке MAS должно в какой-то степени снизить стоимость пакета Mathcad. С другой стороны, снижение цены MAS в целях повышения объема продаж, может снизить объем продаж основного продукта фирмы MathSoft – пакета Mathcad.
Коллективный пользователь (некая инженерная фирма) может либо купить n пакетов Mathcad для своих сотрудников, проводящих расчеты или создающих расчетные документы в среде Mathcad, либо купить один MAS для корпоративной (локальной) сети и пару-тройку самих пакетов Mathcad для разработчиков расчетных документов. Другой вариант – MAS вообще не покупается, а расчеты ведутся на чужом сервере по документам, разработанным другими людьми или разработанными самой данной инженерной фирмой и установленные на чужом сервере за некую арендную плату. Из этого «туманного» описания проступает вполне четкая оптимизационная задача, где целевая функция – это прибыль фирмы MathSoft, а переменные оптимизации – стоимость пакетов Mathcad и MAS. В настоящее время Mathcad 13 стоит 1300 US $, а MAS – 15000 US $ плюс 2500 US $/год (некая продажа в кредит) и эти значения, по-видимому, далеко не оптимальное. Оптимума можно достичь не только изменением цен на два основных программных продукта, но за счет перехода к трем переменным оптимизации: Mathcad, так сказать, для личного пользования, Mathcad для разработки расчетных документов в том числе и для установа на MAS и сам MAS.
На рис. 7 показан проект Mathcad-документа, по которому можно было бы оптимизировать цены на Mathcad и MAS. В расчете отсутствует «самая малость» – целевая функция Profit_ MathSoft.
Оптимизацию можно приложить и к проблеме защиты программ от несанкционированного доступа и копирования. «Глухая защита» – защита всех копий всех версий программы часто приводит к тому, что о ней потенциальные пользователи мало чего узнают и ее вряд ли купят. С другой стороны, продажи программ могут упасть, если они никак не защищены.
А вот еще одна также слабо формализованная оптимизационная задача под условным названием «Судьба программиста». Она касается уже не только некой абстрактной программистской фирмы, но и отдельных ее работников.
Программист, работающий индивидуально или в составе небольшой фирмы, должен кроме своих основных («программистских») обязанностей выполнять и обязанности (функции) менеджера, пекущегося о коммерческом успехе предприятия. Часто эти обязанности вступают в некое противоречие. Нередко программисты стараются всяческими способами «отлынить» от обязанностей менеджера проекта. Для них обязанности программиста – это никакие не обязанности, а сплошное удовольствие. Тому находится и оправдание в том смысле, что успех проекта, мол, определяется в основном качеством программы, а не ее «упаковкой». Прирожденные же менеджеры возражают в том плане, что успех проекта во многом, если не в основном, зависит от этой самой «упаковки». Мол, программу может написать каждый, пардон, дурак. А ты вот попробуй продать ее. Этот тезис применим, конечно, но только к программам, но и ко всяким другим «продуктам». В этой связи, если в качестве целевой функции рассматривать прибыльность предприятия (проекта), то оптимизирующим параметром будет процент времени автора проекта или коллектива разработчиков, уделяемого его этой самой «упаковке».
