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

[Not]

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

К сожалению   (попробую найти литературу) и это не гарантирует отсутствия ошибок.

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

[Not]

Выходит проблема тех, кто не прогуливал дискретку в том, что теперь за ее деревьями они не видят леса?  :twisted:

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

[zyxman]

В СССР было огромное количество бомжей

Ложь №1. Были возможно - как единичные исключения.

Бомжей в СССР было достаточно, чтобы ими милиция закрывала план по мелким правонарушениям.
Я это знаю не из газет/журналов, а от людей, которые работали в милиции.

и нищих тоже хватало

Ложь №2. Нищета была редким, исключительным явлением при развитом социализме.

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

бомжи есть в любой стране, даже в Японии.
И дело тут СОВСЕМ не в уровне доходов

ну-ну. и нищим нравится бедствовать

Это вы считаете что они бедствуют.
Вообще вы напоминаете янки из классики, которые не понимают никакого другого способа жизни кроме ихнего.
А на самом деле есть много других способов жизни, а не только классическая цивилизация, например Чукчи - они еще и сейчас пытаются жить как жили их предки, а при СССР их пытались заставить жить как цивилизация, буквально забирали детей из семей и увозили за тысячи километров в интернаты. Так эти дети сбегали из сытости и цивилизации интернатов, чтобы пройдя пешком эти тысячи километров жить традиционным укладом.
Еще есть дауншифтеры, есть Амиши и многие другие альтернативы, и бомжевание судя по классике вполне традиционная форма существования - вспомните Тома Сойера.

Зачем вообще становиться миллионером нормальному человеку? Есть достойное качество жизни, уверенность в будущем своем и своих детей - зачем стремиться к миллиардам?

А зачем жить? Зачем работать? - Можно ведь бомжевать :?

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

Вы именно что мелкий ограниченный человек.
Ибо я уже вам тут говорил, что не обязательно зарабатывать миллионы чтобы на них молиться.
В НОРМАЛЬНОЙ стране вы можете на эти деньги например построить мост, или школу, или фабрику, или еще что-то полезное, и так во многих случаях и происходит.
И собственно богатство западной цивилизации и бедность нашей как раз поэтому, что у нас СЛИШКОМ МНОГО людей руководствуется в жизни вашей примитивной одномерной позицией, выбирая либо поклонение золотому тельцу, либо псевдомессианство, а все другие измерения недоступны вашему примитивному мировоззрению.

[bs]

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

Я вас тоже очень уважаю!  :wink:

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

Слова не практика, но мужа!

Давайте я немного потыкаю вас в практику:

Код Выделить Развернуть


double foo( double a, double b, double c, double d )
{
    if( a > 0 )
    {
        return a + b * c - d;
    }
   
    return  2*a - b * c + d
}

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

[TAU]

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

Нет.

Не тратьте времени - отсутствие ошибок не гарантирует ни что. Я уже объяснял, о какой гарантии разговор.

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

[TAU]

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

Не нужно ничего искать, достаточно слегка напрячь мозги

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

[bs]

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

Нет.

Почему?

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

Ошибки бывают разные. От ошибок в спецификации и ошибок в логике работы системы гарантии получить не реально. Гарантировать, что программа работает согласно спецификации - вполне.

[Not]

Давайте я немного потыкаю вас в практику:

Потыкайте своего кота

Код Выделить Развернуть


double foo( double a, double b, double c, double d )
{
    if( a > 0 )
    {
        return a + b * c - d;
    }
   
    return  2*a - b * c + d
}

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

Начнем с того, что алгоритм в этой функции нелинейный (условный оператор). Продолжим тем, о чем подумал падишах, глядя на вторую клетку шахматной доски и закончим анализом реальной прошивки реальной БЦВМ (конец доски), где возникает экспоненциальная сложность. Ну и дополним тем, что ваш алгоритм некорректен в смысле отстутствия проверки на переполнение при умножении и сложении. То есть появляетя третья и четвертая, пятая и так далее ветви, на каждой некорректной арифметической операции. Разные процессоры ведут себя по разному. Одни генерируют аварийное прерывание. Другие присваивают значение NAN и умывают руки. Ну а вы, как программист чешете репу и пытаетесь понять, откуда взялись неучтенные ситуации.  :wink:

[TAU]

Бомжей в СССР было достаточно, чтобы ими милиция закрывала план по мелким правонарушениям.
Я это знаю не из газет/журналов, а от людей, которые работали в милиции

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

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

Перид "развитого социализма" - 1970е и 1980е.
Не надо передергивать и юлить, "нищенствующие возле церквей" - это зачастую не настоящие нищие. А вот бедности до нищеты среди народа практически не было.
Зато сейчас при капитализме - сколько угодно.

Вообще вы напоминаете янки из классики, которые не понимают никакого другого способа жизни кроме ихнего

например Чукчи

Господи, с кем я спорю... Сказано ведь...

богатство западной цивилизации и бедность нашей

Какое на хрен "богатство"? Что понимаете под "западной цивилизацией"? Рынок? Откройте глаза и посмотрите на карту мира - нерыночных стран почти и нет на ней. ВЕЗДЕ рынок. И почти везде бедность. Жирует "золотой миллиард" - в основном за счет исторического ограбления колоний.

По поводу моего якобы "примитивного" и "одномерного" мышления могу сказать вот что. Я имел возможность своими глазами понаблюдать, пожить и при развитом социализме, и в цитадели "свободного мира" - где Not сейчас - и в сегодняшней России. И достаточно много чего повидал. И могу сравнивать.
В частности - видел и чувствовал на себе маразмы "развитой цивилизованной западной страны". Которую - как мне кажется - вы идеализируете.

В общем, все это не имеет прямого отношения к БВК АМС.
Хочется подискутировать на эти темы - следуйте на глобальную авантюру.

[bs]

Ну, хотел для авторитетности  

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

[bs]

Начнем с того, что алгоритм в этой функции нелинейный (условный оператор).

А кто говорил, что линейный?

Ну и дополним тем, что ваш алгоритм некорректен в смысле отстутствия проверки на переполнение при умножении и сложении. То есть появляетя третья и четвертая, пятая и так далее ветви, на каждой некорректной арифметической операции. Разные процессоры ведут себя по разному. Одни генерируют аварийное прерывание. Другие присваивают значение NAN и умывают руки. Ну а вы, как программист чешете репу и пытаетесь понять, откуда взялись неучтенные ситуации.  :wink:

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

[Not]

Ну и дополним тем, что ваш алгоритм некорректен в смысле отстутствия проверки на переполнение при умножении и сложении. То есть появляетя третья и четвертая, пятая и так далее ветви, на каждой некорректной арифметической операции. Разные процессоры ведут себя по разному. Одни генерируют аварийное прерывание. Другие присваивают значение NAN и умывают руки. Ну а вы, как программист чешете репу и пытаетесь понять, откуда взялись неучтенные ситуации.  :wink:

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

В смысле соскок? Не вижу никакого соскока. Вы предложили проанализировать граф управления вашей функции. Я вам его нарисовал, исходя из предложенной информации, ни больше, не меньше. Обработки исключительной ситуации в вашем тексте я не вижу, из чего и расписываю ПОЛНЫЙ граф а не то что вы там себе вообразили из соображений здравого смысла. Проблема переполнения не настолько проста, насколько может показаться. Достаточно одного пробоя протоном чтобы в вашей переменной оказалось совсе не то, что вы ожидали увидеть. И никакие предварительные проверки тут не помогут.

[Дем]

Нищих как раз при развитом социализме не было. А при капитализме - сколько хочешь.

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

Зачем вообще становиться миллионером нормальному человеку? Есть достойное качество жизни, уверенность в будущем своем и своих детей - зачем стремиться к миллиардам?

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

И шансов реализовать своё хобби как Маск - не имел бы

Вообще, зачем "как Маск"? В Советском Союзе существовали свои пути, как раз множество НИИ функционировали. Даже поговорка была об "удовлетворении своего любопытства за государственный счет", помните?

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

Си также не имеет альтернативы если надо активно управлять и взаимодействовать с железом. А для очень высокоуровневых вещей можно создать спец. DSL с кодогенератором в Си. Классический пример это генератор парсеров YACC.

Взаимодействие с железом - это не более чем запись/чтение значений по неким адресам. Такое даже в бейсике было, ЕМНИП

[Not]

Взаимодействие с железом - это не более чем запись/чтение значений по неким адресам.

Ага. А программирование - это всего лишь упорядочивание символов друг за другом  

[avp]

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

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

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

Ява и Си не особо сильно различаются по выразительности.  Поэтому вероятность логических ошибок примерно одинакова

почитайте литературу

Аргументов не осталось?
Может тогда на C# переходить пора?

Ада помоему сейчас не особо актуальна

Ада успешно используется в настоящее время. Насколько я понимаю, кроме прочего - при написании ПО МКС.

Смотря для какого софта.
Неактуальность Ады в полностью новых проектах.

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

А можно - проблемно-ориентированный язык с прямой генерацией машинного кода   БЦВМ. Без промежуточной стадии.

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

[bs]

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

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

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

Обработки исключительной ситуации там быть не должно по уже обозначенным соображениям.

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

А что поможет? Формальная верификация? Или может анализатор логов, полученных прогонами на КИСе в тепличных условиях? :twisted:

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

Покажите мне, как можно добиться лучших результатов!

[Not]

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

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

1)

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

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

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

Покажите мне, как можно добиться лучших результатов!

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

[TAU]

Ну, хотел для авторитетности  

Мужики,

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

[Not]

Ну, хотел для авторитетности  

Мужики,

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

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

[Not]

Покажите мне, как можно добиться лучших результатов!

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