Ответ на »сообщение 1814« (RBV)
___________________________

Вот здесь
http://www.yur.ru/science/computer/appro/monografia.htm
автор предлагает подход, который называет "аппроксиметикой".
Тут
http://www.yur.ru/science/computer/appro/predisl.htm
его (автора) страшно хвалят.
Но... смущает соавторство с Жириновским, особенно -- в "Азбуке секса" (?!). :)

Ответ на »сообщение 1814« (RBV)
___________________________


Погрешность накапливается в численных методах однозначно. На то они и численные :). Тип "значение и погрешность" не подойдет. Алгебру для него устанете создавать. Есть более простое решение - интервальное исчисление, с проработанной теорией. Но производительность, конечно, упадет.

Вообще не все задачи решаемые численными методами, правомерно ими решаются. А часто и вообще бездоказательно.

Тема заинтересовала.
Отчасти потому что сейчас встала задача обеспечить один из наших процов качественной математической библиотекой.
Я тут попросил одну нашу программистку написать несколько функций.
А когда программа зациклилась, то обнаружил примерно такую функцию (по памяти):

#define EPS 1E-5

float sqrt(float x)
{
    float y = 1, y0;
    do {
        y0 = y;
        y = (y0 + x / y0) * 0.5;
    } while (fabs(y-y0) >= EPS);
    return y;
}

Вообще (ИМХО) культура вычислений упала.
Вот вопрос: в каком учебнике современный программист найдет сoвет, как ему выбрать "эпсилон"?

Ответ на »сообщение 1805« (Сергей Перовский)
___________________________

Ответ на »сообщение 1804« (Jack Of Shadows)
___________________________
Не далее как вчера беседовал со специалистами по гидро-аэродинамике.
Я убеждал их, что в их численном методе возможно накопление погрешности и предлагал вместо стандартных чисел, для пробы использовать арифметику, учитывающую погрешность. Что стоит написать такой тип: "физическая величина", имеющий значение и погрешность?


Погрешность накапливается в численных методах однозначно. На то они и численные :). Тип "значение и погрешность" не подойдет. Алгебру для него устанете создавать. Есть более простое решение - интервальное исчисление, с проработанной теорией. Но производительность, конечно, упадет.

Вообще не все задачи решаемые численными методами, правомерно ими решаются. А часто и вообще бездоказательно.

Ответ на »сообщение 1812« (Geniepro)
___________________________

Возможно, претензии к отсутствию перечислимого типа ушли бы, если бы в Оберонах были типизированные константы.
Кстати, а почему их-то нет? В чём такое уж преимущество указания
CONST C = 5;
вместо
TYPE TColor = INTEGER;
...
CONST C : TColor = TColor(5);

или

CONST C : TColor = TColor(5);
Ну, прибавляется указание типа, ну и что?
Это же не трудно, зато повысится надёжность...

В виртовских языках константы и так (без специального описания) принадлежат к определенному типу.
Например

• 5 есть INTEGER
  
• 5.0 есть REAL
  
• TRUE есть BOOLEAN
  

Принцип такой: тип константы можно определить по ее виду.
Возможно, это спорный подход. Надо подумать.

Возможно, претензии к отсутствию перечислимого типа ушли бы, если бы в Оберонах были типизированные константы.
Кстати, а почему их-то нет? В чём такое уж преимущество указания

CONST C = 5;

вместо

TYPE TColor = INTEGER;
...
CONST C : TColor = TColor(5);

или

CONST C : TColor = TColor(5);

Ну, прибавляется указание типа, ну и что?
Это же не трудно, зато повысится надёжность...

Ответ на »сообщение 1804« (Jack Of Shadows)
___________________________

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

Ай-яй-яй, нехорошо смеяться над больными людьми! :о)

Мне в моих микроконтроллерных программах на С именно так и приходиться поступать!

Размер стека - несколько десятков байт, кучи - нет, доступная мне часть ОЗУ (регистрового файла) - меньше двухсот байт.
Локальные переменные в функциях моментально приводят к переполнению стека...
Хорошо, хоть в С есть union - хоть какое-то повышение уровня абстракции у многократно реюзанных ячеек памяти... :о)
За секунду - аж от 2 до 12 миллионов операций...

Ответ на »сообщение 1809« (Илья Ермаков)
___________________________


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

Или специализированный язык со встроенным соответствующим типом.
Наподобие расширения Оберона-2 для комплексных чисел.

Ответ на »сообщение 1805« (Сергей Перовский)
___________________________

Ответ на »сообщение 1804« (Jack Of Shadows)
___________________________
Что стоит написать такой тип: "физическая величина", имеющий значение и погрешность?
Они говорят - мы вылизываем и оптимизируем алгоритм под конкретный процессор чтобы за рабочий день успеть произвести хотя бы один расчет. А тут потеря на порядок. Мы так не играем.

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

Ответ на »сообщение 1795« (pepper)
___________________________


>>В принципе, так же, как это делает "посмертный отладчик".
(Т.е. опять-таки используем один механизм, а не плодим кучу механизм ad hoc.)
Берется frame pointer и т.д.

Картина маслом: "Физик-ядерщик берет frame pointer и раскручивает стэк".

Может быть, такая вот "пикча" -- "физик-ядерщик придирчиво инспектирует состояние стека после трапа" -- покажется более реалистичной? :)


Исключения в C++ раздувают бинарник в размере. О временных затратах я слышу первый раз от тебя. На популярных компиляторах ничего такого не наблюдается.

Просто представьте себе механизм обработки исключения.
Требуется найти первый подходящий обработчик, и чтобы отработали деструкторы автоматических объектов.
Для этого требуется некоторая информация.
В Си++ она как правило генерится в процессе выполнения программы.
Отсюда потери (говорят, в среднем процентов 20).
Конечно, этого можно избежать. Один способ мы уже знаем.
Не откажу себе в удовольствии отрывок из книги Страуструпа, написанный с характерной для него прямотой. :)

14.8. Исключения и эффективность

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


Если нужна моя интерпретация, то вот она -- Страуструпу трудно выдавить из себя фразу вроде "исключения требуют некоторого оверхеда". :)

Ответ на »сообщение 1805« (Сергей Перовский)
___________________________
Еще пример. Не так давно участвую в работе команды, делающей продукты для анализа текста (rco.ru). Они используют С++ (пока, я надеюсь :-) ). Пару лет назад я удивлялся - а почему не языки ИИ, вроде Лиспа и т.п.? В умных книжках читал заявления, что "писать системы ИИ на императивном языке - немыслимо" и т.п.
Как только стал работать - понял. То, что у них есть, прекрасно работает и применяется на практике, в отличие от многих лабораторных "коней в вакууме". Однако - они вылизывают множество мелочей, оптимизируют код - и все равно система работает очень и очень неспешно. Такова специфика алгоритмов - сложные свертки деревьев по синтаксическим правилам русского языка, перебор многих вариантов с отсечением и т.п. Казалось бы - рай для декларатива. Однако сколько бы система, написанная на Прологе, перемалывала коллекцию СМИ со всей страны, страшно представить...