"Астрономия на персональном компьютере" + CD

[Algen]

<BLOCKQUOTE><font size="1" face="tahoma, verdana, helvetica, arial cyr">quote:</font><HR>Цитаты из сообщения Anatoly:
"Для астронома" все эти возможности есть, знаю по собственному опыту и опыту коллег.
<HR></BLOCKQUOTE>

Этого тезиса я не понял.

<BLOCKQUOTE><font size="1" face="tahoma, verdana, helvetica, arial cyr">quote

О распространенности языка Си. В интернете распространен английский язык, так что, русский нужно выбросить, как малораспространенный и перейти на английский?

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

<BLOCKQUOTE><font size="1" face="tahoma, verdana, helvetica, arial cyr">quote

Мне очень нравился подход создателей Фортрана ... сохраняли все возможности первых версий языка, так как знали, что могут встретиться программы, в которых эти операторы использованы.

В Фортране это действительно было оправдано. Во-первых, с давних времен существовали хорошо прописанные стандарты языка. Во-вторых, на Фортране было (и есть) очень много фундаментальных наработок из области выч. методов. До первой половины 90-х по количеству написанного кода в мире лидировал Фортран, потом его обошел Си. Кстати, абсолютной совместимости снизу вверх все-таки не было даже у Фортрана; не даром у всех компиряторов есть ключик вроде -66.

<BLOCKQUOTE><font size="1" face="tahoma, verdana, helvetica, arial cyr">quote

Вот это действительно забота о пользователях, а не пренебрежительное заявление приверженцев Си относительно Паскалая.

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

С++ сохраняет высокую степень совместимости с Си (меньше, чем версии Фортрана, но неплохую). А предъявлять "приверженцам Си" претензии за снижение популярности Паскаля можно не более, чем американцам, за то что у них не столь популярен испанский язык, на котором говорил Колумб.

<BLOCKQUOTE><font size="1" face="tahoma, verdana, helvetica, arial cyr">quote

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

Позвольте с Вами полностью согласиться. Ведь именно этим аргументом руководствовались авторы, переходя на С++.

<BLOCKQUOTE><font size="1" face="tahoma, verdana, helvetica, arial cyr">quote

не следует ничего выкидывать, даже если это нечто не нравится автору. Добавлять и расширять - да, выкидывать - нет!

Так ничего и не выкинуто. Паскальные программы доступны на сайте. Более того, они доступны свободно, даже книжку не надо покупать [img]images/smiles/icon_smile.gif[/img]

[Algen]

<BLOCKQUOTE><font size="1" face="tahoma, verdana, helvetica, arial cyr">quote:</font><HR>Цитата из сообщения Pietro:
Нельзя сказать, что то или иное средство прото "лучше". Надо всегда уточнять, для чего именно.<HR></BLOCKQUOTE>

Согласен. Авторы достаточо убедительно аргументировали, почему в случае их книги переход на С++ оправдан.

<BLOCKQUOTE><font size="1" face="tahoma, verdana, helvetica, arial cyr">quote

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

Это только одна из сфер, где C++ дает преимущества, но не единственная. Другой случай - программы, которые должны работать на разных платформах. Третий - библиотеки, которые могут без труда использоваться в других приложениях.

<BLOCKQUOTE><font size="1" face="tahoma, verdana, helvetica, arial cyr">quote

А если речь идет о процедуре размером с полстранички, то кто будет городить огород со всеми этими виртуальными деструкторами, перегруженными операторами и прочими умными указателями? В книжных примерах главное--наглядность и читаемость, а перепрограммировать алгоритм по своему вкусу и на своем любимом языке это уже ваша работа.

А вот здесь нужно пояснить суть программ, приводимых в книге.

Во-первых, большинство программ занимают заметно больше полстранички.

Во-вторых, авторы не злоупотребляют специальными конструкциями С++; в этой части их позиция очень грамотная и умеренная. Но в той мере, в которой они все-таки используются, они резко упрощают чтение и понимание программ (речь, прежде всего, про векторно-матричные операции и, в меньшей степени, про форматный вывод).

В-третьих, главная цель авторов - избавить читателя от рутинного перепрограммирования базисных астрономичских задач - преобразования координат, расчета эфемерид, определения орбит. Программы написаны предельно ясно с расчетом на то, чтобы готовый код можно было использовать в своих целях, а не писать свой, глядя на формулы в книжке. А теоретические пояснения в основном предназначены для того, чтобы было понятно, как следует пользоваться программами, какова их точность и границы применимости и как адаптировать их к своей задаче.

Во, опять - какой язык лучше! А не все ли равно, господа хорошие? Что на Паскале, что на Си можно написать любую программу.

Издатели книжки борются за тираж -> за денюжку. И использовать в современном издании Паскаль было бы по меньшей мере глупо - факт, на данный момент он гораздо менее популярен. Правда у Паскаля есть еще шансы - тот же самый Kylix к примеру. Вам что лучше - книжка с сишным программами или отсутствие таковой, но зато с программами паскалевскими? [img]images/smiles/icon_biggrin.gif[/img]

И вообще - на вкус и цвет товарищей нет. А тут как раз дело вкуса. Я раньше на паскаль плевался как только мог (вот подумал - на чистый паскаль стоит продолжать плеваться [img]images/smiles/icon_razz.gif[/img]), считал, что С - rulez и forever! А потом пришлось Delphi использовать, и ничего, нормально все. Ломки были, но не смертельные.

FBS--я как раз таки против языковых войн, если Вы читали внимательно.
Algen--ну в общем мы поняли друг друга, не видя книги трудно что-то говорить. У меня есть Astronomical Algorithms Мееуса (своего рода библия по этому предмету) и пособие по JPL-эфемеридам не помню кого, там в примерах никакого С, и я с этим согласен, не нужен он там. Я не соглашусь с Вами в одном--в книге все-таки не место готовым программам: на языках программирования там описываются *алгоритмы*, а не программы. Каждый программист все равно запрограммирует по-своему. Насчет векторных операций согласен, я не подумал, здесь Вы правы и С++ действительно удобен.

[Algen]

<BLOCKQUOTE><font size="1" face="tahoma, verdana, helvetica, arial cyr">quote:</font><HR>Цитата из сообщения Pietro:
Я не соглашусь с Вами в одном--в книге все-таки не место готовым программам: на языках программирования там описываются *алгоритмы*, а не программы. Каждый программист все равно запрограммирует по-своему.<HR></BLOCKQUOTE>

Не будем забывать, что книга выпускается вместе с диском. Так что это не просто главы из теории, а рабочий инструмент. Из каких соображений следует ограничивать возможности этого инструмента (не рассматривать программы) мне не совсем понятно. Ведь большинство-то читателей как раз не будет писать программы сами, а воспользуются готовыми.

Зачем же заставлять людей повторять весьма трудоемкую (и главное труднопроверяемую) работу по кодированию вычислительных алгоритмов, когда можно освободить время для гораздо более полезной деятельности - например, для написания графического интерфейса или интерпретатора языка запросов астрономических эфемерид [img]images/smiles/icon_smile.gif[/img]

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

Переписали мы прогрммы на Паскале. Теперь понятно высказывание Algen: "Паскаль в меньшей степени чем C и гораздо хуже чем Фортран поддается оптимизации кода." Так неоптимально написанная программа просто не поддается оптимизации при компилировании, как бы ни гениален был создатель компилятора. Если от языка требовать исправлять программистские небрежности - то распространенность Си-подобных языков, вероятно, обусловлена тем, что авторам компиляторов удалось решить эту проблему: на этих языках, вероятно, можно создавать крайне неэффективные программы, а компилятор все исправит.

Что касается программ на Паскале, то они требуют доработки с точки зрения оптимального программирования. Если авторы программ на Си и Паскале одни и те же, то ... ???

[ 20-12-2001: Сообщение редактировал: Anatoly ]

[Algen]

Ну, что ж, Anatoly, не хотите по-хорошему, будем по-плохому (с) "Пятый элемент"

Начнем с разъяснения, что оптимизация в программировании бывает разная: алгоритмическая, глобальная, циклов, общих подвыражений, регистровая, машинно-зависимая (и это еще не все). На языках высокого уровня свободно можно заниматься только алгоритмической оптимизацией (например, использовать быструю сортировку вместо пузырька), ну, может быть, иногда - глобальной. Все остальные виды оптимизации должен выполнять компилятор, поскольку программист, работающий на ЯВУ, не может гибко управлять кодовыми конструкциями, которые генерирует компилятор. Можно, конечно, декомпилировать программу, узнать, как именно компилятор реализует ту или иную конструкцию, но это знание будет ограничено данным компилятором, работающим в данной ОС и на данном процессоре.

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

Проще всего говорить о машинно-зависимой оптимизации. Как известно, все современные процессоры имеют многоуровневый кэш для данных и программ. Во многих из них есть элементы конвейерной архитектура. Оптимизирующий компилятор знает и учитывает такие параметры процессора, как размер кэша (это сказывается, например, на размерах циклов и использовании inline-подстановок), длительность выполнения разных операций (в тактах), возможность параллельного выполнения некоторых операций (например, обычных и с плавающей точкой). Такой компилятор знает, что некоторые операции (например, переходы) очищают конвейер, учитывает, что в некоторых случай возможна оптимизация за счет спекулятивного выполнения команд (еще до определения условия перехода за счет суперскалярной архитектуры процессора начинаются вычисления по обеим веткам условия, а потом лишняя отбрасывается).

Регистровая оптимизация тесно связана с оптимизацией общих подвыражений и циклов. Многие программисты думают, что код, в котором они вручную "оптимизировали" общие подвыражения (запихав их в переменные) или вытащили константные подвыражения из цикла будет работать лучше. На самом деле эти действия только затрудняют работу оптимизирующего компилятора, который мог бы разместить значения подвыражений на регистрах (вместо ячеек памяти) или сосчитать на этапе компиляции константу и встроить ее в код программы (вместо добывания ее из ячейки памяти).

Идея оптимизировать код на ЯВУ вручную в расчете, что от этого улучшится машинный код, тянется с 70-х годов, когда теория оптимизации кода была еще в зачаточном состоянии, а программы писались и оптимизировались под одну платформу. Совершенно невозможно целенаправленно влиять на машинно-зависимую оптимизацию, меняя конструкции ЯВУ. Более того, пытаясь действовать подобным образом, можно только помешать работе хорошего оптимизирующего компилятора.

Теперь вернемся к Паскалю. Он изначально создавался с тем расчетом, чтобы компилятор генерировал не машинный код, а некий универсальный P-код, который затем надлежит преобразовывать в машинный код. Идея здравая, т.к. сокращает затраты на реализацию компилятора. Но она практически убивает возможность оптимизации, т.к. к P-коде утрачена информация о структуре программ и взаимозависимости ее частей.

Для Фортрана изначально предлагался иной способ компиляции, позволяющий учитывать (хотя и не очень просто) взаимозависимости участков кода и их потребности в ресурсах (в первую очередь, в регистрах). Поэтому для Фортрана уже в конце 70-х были созданы великолепные оптимизирующие компиляторы.

Помню, как еще на ЕС ЭВМ я пытался соревноваться с оптимизирующим компирятором FORTRAN H в компактности и скорости программ. Так вот, он построил тестовый цикл на одну команду более компактно, чем я независимо написал на ассемблере. Я в дальнейшем принял во внимание использованный компилятором трюк с регистрами.

Современные процессоры имеют архитектуру и систему команд на порядок (если не на два) более сложную, чем ЕС ЭВМ. Поэтому легко может получиться, что конструкция, которая кажется оптимальной на ЯВУ в коде будет далеко не оптимальна. ЯВУ придуманы для того, чтобы на них записывать программы в стиле понятном и удобном для человека. Попытки оптимизации (кроме алгоритмической) идут вразрез с этой целью. К сожалению, не у всех компиляторов/языков есть/возможны хорошие оптимизаторы. В таком случае приходится заниматься шаманством. Только вот не надо это шаманство выдавать за высокий программистский класс. Это элементарная борьба с конструктивными недостатками используемых инструментов.

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

Algen, спасибо за разъяснение, некоторых вещей я не знал.

Что касается обсуждаемой программы, так тут много нелепостей с точки зрения элементарной логики.

Например, зачем все угловые величины сначала переводить в градусную меру, а затем использовать собственные процедуры взятия тригонометрических функций от градусной меры? Гораздо экономнее использовать не коэффициент перевода в градусы, а сразу в радианы и использовать стандартные функции языка. Вряд ли компилятор способен исправить такое.

Ну и жуткое количество мелких процедур из одного-двух операторов. Может компилятор и подставляет операторы таких процедур в тело программы, а если нет?

И так далее...

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

[Algen]

О! Здорово! Достигли взаимопонимания. А я уже морально готовился к длительной осаде [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE><font size="1" face="tahoma, verdana, helvetica, arial cyr">quote:</font><HR>Цитата из сообщения Anatoly:

Например, зачем все угловые величины сначала переводить в градусную меру, а затем использовать собственные процедуры взятия тригонометрических функций от градусной меры? Гораздо экономнее использовать не коэффициент перевода в градусы, а сразу в радианы и использовать стандартные функции языка. Вряд ли компилятор способен исправить такое.<HR></BLOCKQUOTE>

Согласен. Подобного безобразия в новом издании нет.

Хотя, не исключено, что для такого подхода были причины. Например, могла не устраивать точность реализации стандартных процедур в библиотеке компилятора. Ведь насколько я помню, в тех версиях Паскаля, которые были в ходу в 1991 году, когда вышло первое (немецкое) издание книги, величин с двойной точностью не было.

<BLOCKQUOTE><font size="1" face="tahoma, verdana, helvetica, arial cyr">quote

Ну и жуткое количество мелких процедур из одного-двух операторов. Может компилятор и подставляет операторы таких процедур в тело программы, а если нет?

Вроде и с этим стало лучше, хотя С++ (и вообще ООП) как раз ориентирован на подобный стиль программирования.

Которкие процедуры при программировании обычно появляются на местах сшивки разных концептуальных моделей, использованных при проектировании системы. Взять, например, любую оконную библиотеку - там большинство методов представляют собой просто обращения к функциям API. Это классический пример стыка между ОО и не-ОО частями системы.

В вычислительных задачах подобные стыки (но уже другого типа) тоже встречаются. На этих местах всегда возникают маленькие процедурки-адептеры. Конечно, если их становится слишком много, это говорит о непроработанности архитектуры системы. Новое издание, по крайней мере, на мой взгляд, от подобного греха избавлено.

Давайте лучше дождемся, когда книга на руках будет. Вот тогда можно конкретно критиковать.

Да и не думаю я, что листинги настолько сложны и запутаны, что начинающему программисту в них будет невозможно разобраться и переделать на свой лад (читай - в паскаль перевести) - не тот случай.
Тем более, что эта книга первая в своем роде. Если бы был выбор, тогда можно было бы нос воротить и говорить "фи! пойду куплю другую"

Кстати, вроде и конвертеры есть такие. В Линуксе вроде точно видел пакет конвертера из паскаля в Си. Но это отдельный вопрос.