Здравствуйте, eao197, Вы писали:

E>Алексей, может на "ты" перейдем? А то мне как-то неудобно, я здесь в форуме ко всем на "ты", а мне в ответах "вы", да еще с большой буквы.

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

AVC>>>>ИМХО, никакой иной "пользы", кроме того, что это все это проделано неявно для программиста, не видно.
E>>>Именно в этом задача и состояла -- нужно было повысить уровень абстракции.

Это интересная тема.
Как-нибудь наберусь времени рассмотреть ее подробнее.
Скажу только, что раньше полностью разделял твою точку зрения (что и претворял на практике; и что забавно — именно в матричных вычислениях).
А сейчас — с оговорками.

E>>>Выход за границы массива и потеря точности при вычислениях -- это совершенно разные вещи. В первом случае я получаю абсолютно точное значение, просто из-за моей ошибки оно оказывается не в том диапазоне. А реальная потеря точности, это когда в правильном выражении получается неправильный результат из-за ограничений платформы. Например: c/(a-b). Если a != b, то это выражение корректно и в математическом смысле всегда дает корректный результат. Но, если a и b являются вещественными числами, то корректность выражения начнет зависеть от величины (a-b). Если это довольно близкие значения, то их разность окажется слишком маленьким числом из-за чего c/(a-b) не сможет быть представлена.
E>>>Еще один пример неявной потрери точности обсуждался в форуме по C++.
AVC>>Обратите внимание: я говорил об ошибках в вычислениях, а Вы — о потере точности.
AVC>>ИМХО, Вы слишком сузили тему.
E>May be. Но выход за пределы массива, это явная ошибка, избежать которую позволяет даже минимальный уровень знаний. Более того, не нужно иметь серьезную математическую подготовку, чтобы найти ее. А вот с потерей точности дело гораздо сложнее. Во время учебы я сам сталкивался с тем, что не знание тонкостей применяемого вычислительного метода сложно получить работоспособную реализацию именно из-за органичений в представлении вещественных чисел.

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

E>>>В любой проблеме скрыта возможность ((С) американская поговорка).
AVC>>Угу. Особенно для американцев. И особенно — в чужих проблемах.
E>Ну можно к американцам по разному относиться, но то что, сейчас они остались единственной сверхдержавой, это факт. А вот мы все такие умные, что... Но это уже офтопик.

На самом деле, я уважаю американцев за некоторые их качества: упорство, инициативность, изобретательность. И др.
Некоторые американцы у меня вызывают искреннее восхищение. Например, Бенджамен Франклин. (Не за то, что он изображен на купюре. )
Претензии же у меня к США почти исключительно нравственного характера, но серьезные.
Ведут они себя как римляне в античные времена, следуя принципу divide et impera и зачастуя разжигая в людях рознь.
О ядерных бомбардировках, напалме, химическом оружии и т.д. я уже не говорю.
Впрочем, это уже и правда офтоп для программистского форума.

E>>>Так может тогда прогресс вообще остановить?
AVC>>А что такое прогресс?
E>Ну хотя бы создание того, что еще совсем недавно казалось невозможным.

По ряду пунктов мы как бы скатываемся в офтопик.
Правда, я уверен, что при обсуждении некоторых проблем это практически неизбежно и даже правильно.
Некоторые вещи можно понять только в связи с другими, вместе с которыми они составляют систему.
В противном случае, мы, прямо как узники платоновской пещеры, обречены видеть только мелькание теней на стене.
Конечн, при расширении темы важно не потерять из виду основной цели обсуждения и не сбиться на треп.
Что касается именно прогресса, то (ИМХО) не следует забывать, что приобретая что-то новое, мы также что-то и утрачиваем. И я не вижу никаких гарантий, что утраченное не окажется более ценным.
Например, в пору моего детства продукты в продовольственных магазинах не отличались большим разнообразием. Это, наверное, плохо и "непрогрессивно". Но практически все они были натуральными. А это хорошо. Что важнее? В последнее время мне бросается в глаза, что дети в массе стали болезненней, чем прежде. (Я уже не говорю о том, что и самих детей стало меньше.)
В отношении языков программирования наблюдается тенденция пренебрегать надежностью. Возможно, в пользу производительности, хотя подтверждающих это данных у меня нет. Наверное, пока мы остаемся в рамках офисных приложений, это экономически оправдано, т.к. цена ошибок и сбоев сравнительно невысока, а рост производительности может быть значительным (хотя это зависит и от организационных факторов).
Часто такой подход иллюстрируют таким примером: хотя автомобиль делает жизнь немного более опасной, люди пренебрегают этим риском ради дополнительных удобств (экономия времени, свобода передвижения и т.д.)
Но (ИМХО) было бы ошибочно переносить такой подход на все сферы жизни. Существует ряд отраслей (ядерная, военная и т.д.), чреватых глобальными катастрофами. Здесь приоритет следует отдать надежности, в том числе — надежности ПО. А надежность ПО включает в себя много составляющих, среди которых строгий контроль типов, простота языка и основанная на этом корректность компилятора играют далеко не последнюю роль.
Создание такого простого языка — трудная задача. На мой взгляд, Вирт с ней справился лучше и раньше других.
Что касается Ады, справедливо упомянутой Cyberax'ом, то, при многих достоинствах, она слишком сложна и тяжеловесна.
В своей тьюринговской лекции Хоар просил не доверять такому сложному языку. (Я не случайно упоминаю Хоара. Он не только изобретатель быстрой сортировки, исследователь в области параллельного программирования, автор языка Оккам и ряда привычных уже нам конструкций языков программирования, вроде case ... of (он же switch). Его влияние на Вирта в области языков программирования было так велико, что его можно назвать "крестным отцом" Паскаля и последующих языков Вирта. )
Что касается Си++, то когда-то мне нравился этот язык. Пока в него не решили запихнуть все-все-все и еще чуть-чуть, а фундамент оставили прежним. К языку Си у меня больших претензий нет. Как "высокоуровневый ассемблер" он вполне хорош. А вот распространение Си++ во все области ПО (которое упомянуто у Страуструпа и поразило тебя) меня откровенно пугает. Представь себе, что над тобой нависает покосившийся небоскреб, практически лишенный фундамента.

E>Но ведь в C++ мне не нужно писать LocalSearch для разных случаях, он уже написан.

Иногда написание "обвески" для его вызова съедает больше...
Но главная моя претензия в данном случае все же состоит в том, что язык разбухает. Требуется знать все больше и больше (о все меньшем и меньшем ).
Уже и тривиальный цикл написать нельзя. Говорят: используйте стандартные алгоритмы. Т.е. их все надо помнить...

AVC>>Говоря о find_if, Вы запамятовали упомянуть о некоторых деталях.
AVC>>Во-первых, использование find_if предполагает использование итератора, причем привязанного как к типу элемента, так и к типу контейнера. Что-то вроде:
AVC>>

AVC>>list<elem_type>::iterator i = find_if(l.begin(), l.end(), cond(v));
AVC>>if (i != l.end()) { ... }
AVC>>

E>Ну и что? В случае с контейнерами итераторы уже реализованы. Но find_if можно использовать и с векторами:
E>

E>int a[ 20 ];
E>int * pos = find_if( a, a + sizeof(a)/sizeof(a[0]), v );
E>if( pos != a + sizeof(a)/sizeof(a[0]) ) { ... }
E>

Наверное, здесь имелся в виду find, а не find_if?
Думается, простой код

for (int i = 0; i < sizeof a / sizeof a[0]; ++i)
    if (v == a[i]) {  ... }

проще и понятнее.
Но если уж начал применять STL, то, конечно, надо применять его везде — для выработки автоматизма.

AVC>>Во-вторых, Вы почему-то ничего не сказали о таких мелочах, как написании класса предиката, наследовании от unary_function или binary_function и т.д.
E>Для многих стандартных алгоритмов, в том числе и для find_if, это не обязательно.

Это мелочь, но и здесь можно немного поспорить.
Все алгоритмы, чье имя заканчивается на _if, предполагают получить в качестве параметра предикат.
Рассмотрим в качестве примера одно из определений find_if (для компилятора GNU C++):

template <class _InputIter, class _Predicate>
inline _InputIter find_if(_InputIter __first, _InputIter __last,
                          _Predicate __pred,
                          input_iterator_tag)
{
  while (__first != __last && !__pred(*__first))
    ++__first;
  return __first;
}

Предикатом может быть как булевская функция, так и соответствующий класс. По ряду причин, рекомендуют второе.
Может быть, ты имел в виду простой find?
(Или, чем черт не шутит, я уже совсем забыл стандартную библиотеку? Впрочем, она и правда могла у меня "атрофироваться" за ненадобностью.)

AVC>>В-третьих, сколько всей этой ерунды надо помнить...
E>Да, вот с этим сложно спорить.

Ага, ага, я победил...

E>>>Кстати, есть ли для Modula и Oberon стандарт? ANSI или ISO?

AVC>>Для Модулы-2 есть стандарт ISO (уже давно).
AVC>>Именно поэтому в аэрокосмической сфере применяются в основном Ада и Модула-2 — языки, имеющие стандарты ISO.

E>По существование ISO стандартов для Модулы и Ада не знал, спасибо.
E>Хотя, думаю, причина использования в этих областях Ада и Модула-2 не в этом.
E>Да и Ада применяется только на Западе

Да, у нас пишут на Модуле-2.

AVC>>Вот у меня на RSDN ник AVC. Все просто и ординарно — это инициалы: имя, отчество и фамилия.
AVC>>А как насчет eao? Ну, наверное, — ничего похожего...
E>Ну почему же? Все именно так, только еще рост в сантиметрах добавлен Причем именно такой ник получился из за ошибки: когда я себе делал первый почтовый ящик, то попросил администратора сделать логин eao195 (точное значение ), но он ошибся и сделал eao197. А потом уже менять не хотелось, чтобы почта не терялась
E>И не нужно меня обвинять в "сухости" и прагматизме -- я ведь не художник, а программист