Особенности программирования БВК АМС

[bs]

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

Ну вот, я же говорил, что я волшебник. Из бесконечности сделали три. Рад за вас.

Классическая ошибка, которая однажды привела к самоуничтожению Ариан-5. Тоже наверное разработчики были с чрезмерным самомнением

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

Давайте допустим, что программист, писавший код для Ариан-4, сделал бы обработку случая с переполнением (хотя это было бы совершенно бессмысленно). Вы считаете, что приемлемый вариант обработки такого случая для Ариан-4 подошел бы для Ариан-5? Т.е. отсечка по каналу управления из-за предельных значений 16-разрядного параметра не привела бы к катастрофе? Не рад за вас!

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

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

Конечно не дошло. Темный я. Только правда в том, что я получаю надежность системы, а вы отрекаетесь от нее, ссылаясь на чрезмерную сложность.

За парту! Начать с дискретной математики.

Уже бегу!

[Not]

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

Ну вот, я же говорил, что я волшебник. Из бесконечности сделали три. Рад за вас.

Смотрите пункт 2. Там не бесконечность, но экспоненциальность, что одно...эээ... лампово

[dmdimon]

профессионально программированием не занимаюсь уже лет 15 - но вопрос возник.
а вот _функциональное_ написание "сверху вниз" с использованием модульного подхода и жестко формализованными(в том числе по допустимым значениям) связями/ресурсозатратами на асме - при использовании аппаратного контроля данных и при необходимости - аппаратной многозадачности - это просто немодно или плохо?

[Not]

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

Я лишь следовал вашей спецификации. Ваша ошибка заключается в неполноте этой спецификации. Казалось бы мелочь - но мы помним про Ариан, где эта мелочь аукнулась так что будь здоров! Программирование высоконадежных систем - это в первую очередь полное описание спецификации функции. Design by contract - слышали наверное? Это в ту сторону. Интервалы переменных - всего лишь малая часть оных. А еще конкурентность, темпоральность, и так далее.

[Not]

профессионально программированием не занимаюсь уже лет 15 - но вопрос возник.
а вот _функциональное_ написание "сверху вниз" с использованием модульного подхода и жестко формализованными(в том числе по допустимым значениям) связями/ресурсозатратами на асме - при использовании аппаратного контроля данных и при необходимости - аппаратной многозадачности - это просто немодно или плохо?

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

[bs]

Кое-что нашел. В. Кулямин с примерами:
http://panda.ispras.ru/~kuliamin/lectures-mbt/Lecture03.pdf

Очень хорошо! Я понял, о чем вы. Но давайте вспомним, что я говорил:

Представьте себе такой план тестирования, который заставляет отработать каждый линейный (детерминированный) участок кода минимум один раз и зафиксировать ожидаемый результат.

Я очень тщательно подбирал слова, все до последнего. Фиксация ожидаемого результата в данном случае эквивалента "покрытию ветвей" в статье. Со всеми вытекающими бонусами.

[Not]

Кое-что нашел. В. Кулямин с примерами:
http://panda.ispras.ru/~kuliamin/lectures-mbt/Lecture03.pdf

Очень хорошо! Я понял, о чем вы. Но давайте вспомним, что я говорил:

Представьте себе такой план тестирования, который заставляет отработать каждый линейный (детерминированный) участок кода минимум один раз и зафиксировать ожидаемый результат.

Я очень тщательно подбирал слова, все до последнего. Фиксация ожидаемого результата в данном случае эквивалента "покрытию ветвей" в статье. Со всеми вытекающими бонусами.

Почитайте ту статью внимательно. Точное покрытие вычислительно сложно в общем случае. Неточное покрытие бессмысленно. Т.е. всегда существует некий компромисс между желаниями и возможностями.

[dmdimon]

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

[Not]

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

Да пожалуйста, кривой GOTO у которого переменная в качестве смещения. И таких вариантов в Ассемблере пруд пруди. А формально проверить невозможно вследствие огромного количества состояний ассемблерной программы. Мода тут непричем. Причем тут непрактичность больших ассемблерных программ.

[TAU]

Представьте себе такой план тестирования, который заставляет отработать каждый линейный (детерминированный) участок кода минимум один раз и зафиксировать ожидаемый результат

Я очень тщательно подбирал слова, все до последнего. Фиксация ожидаемого результата в данном случае эквивалента "покрытию ветвей" в статье

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

И еще. В случае упрвляющих алгоритмов для КА ситуация весьма осложняется за счет наличия "внешних" по отношению к ПО условий - показаний датчиков, контролирующих БА, и пр. Причем эти условия меняются со временем.

[bs]

Я лишь следовал вашей спецификации. Ваша ошибка заключается в неполноте этой спецификации.

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

Казалось бы мелочь - но мы помним про Ариан, где эта мелочь аукнулась так что будь здоров!

Не, не, не... Дэвид Блейн. Ариан-5 - жертва глупости проектировщиков. Программист сделал свое дело (по спецификациям Ариан-4), программист может уходить

Программирование высоконадежных систем - это в первую очередь полное описание спецификации функции. Design by contract - слышали наверное? Это в ту сторону. Интервалы переменных - всего лишь малая часть оных. А еще конкурентность, темпоральность, и так далее.

Ну было бы все просто - не было бы интереса к таким задачам.

[bs]

то-есть в основном немодно, т.к. про в том числе "проверку диапазонов" я как-бы упомянул?

Нет, не немодно, а сложно, затратно, не надежно (т.е. конечно можно сделать очень надежно, но будет очень не эффективно, по сравнению с более "модными" средствами).

[Not]

Представьте себе такой план тестирования, который заставляет отработать каждый линейный (детерминированный) участок кода минимум один раз и зафиксировать ожидаемый результат

Я очень тщательно подбирал слова, все до последнего. Фиксация ожидаемого результата в данном случае эквивалента "покрытию ветвей" в статье

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

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

[TAU]

при развитом социализме - нищими были все. Иначе не ломанулись бы за колбасой

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

Миллион (баксов) - это на самом деле не так уж и много. Столько рядовой работник за несколько лет зарабатывает

А тратит сколько за это время? На жилье?

[bs]

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

Вы все правильно поняли! Но уже который раз пропускаете неотъемлемое - фикасацию ожидаемого результата. По примеру в статье - тестируем функцию, фиксируем резльтат. Слово "нечетное" в результате отсутствует. Его нет - ошибка обнаружена, результат не соответствует ожидаемому.

И еще. В случае упрвляющих алгоритмов для КА ситуация весьма осложняется за счет наличия "внешних" по отношению к ПО условий - показаний датчиков, контролирующих БА, и пр. Причем эти условия меняются со временем.

Безусловно! Но это не значит, что мы должны смириться с этим. Ищем, находим и применяем способы адекватной их отработки.

[TAU]

Но это не значит, что мы должны смириться с этим. Ищем, находим и применяем способы адекватной их отработки.

Ну конечно мы не смирились!

Иначе бы мы здесь не сидели  

[TAU]

Дело не безопасности...

ну-ну. спор можно с вами на этом заканчивать

Это капитуляция?

ничего подобного. это констатация.

[dmdimon]

Нет, не немодно, а сложно, затратно, не надежно (т.е. конечно можно сделать очень надежно, но будет очень не эффективно, по сравнению с более "модными" средствами).

позволю себе с вами не согласиться - из моей практики - моя реализация на асме на равном железе была на 2 порядка (!) быстрее, ей _всегда_ хватало ресурсов и она решала при этом более полную задачу (больше объем данных, сложнее структура), чем "фирменный" продукт на плюсах. И задача была нетривиальна. Правда, мне не заплатили в результате...

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

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

[Not]

Нет, не немодно, а сложно, затратно, не надежно (т.е. конечно можно сделать очень надежно, но будет очень не эффективно, по сравнению с более "модными" средствами).

позволю себе с вами не согласиться - из моей практики - моя реализация на асме на равном железе была на 2 порядка (!) быстрее, ей _всегда_ хватало ресурсов и она решала при этом более полную задачу (больше объем данных, сложнее структура), чем "фирменный" продукт на плюсах. И задача была нетривиальна. Правда, мне не заплатили в результате...

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

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

Да на здоровье. Пишите. Может и заплатят... когда нибудь. Но большие проекты на ассемблере давно уже не пишут, по вышеозвученным причинам.

[avp]

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

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

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