Про важность правильных циклов.

[Peter Almazov]

С третьей стороны, возможно у нас этих ошибок нет, или почти нет, потому, что мы умеем правильно строить циклы? :-)

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

[valexey]

С третьей стороны, возможно у нас этих ошибок нет, или почти нет, потому, что мы умеем правильно строить циклы? :-)

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

А может мы их строим альтернативно-верным способом? :-) Вообще, где математически коректное доказательство того, что именно тот способ построения циклов является единственно верным?

[Peter Almazov]

Да чего толочь воду в ступе, свой выбор вы сделали.

[ilovb]

А кто в соседней теме написал цикл неправильно?
И я не про эффективность, а именно про правильность.

[valexey]

Да чего толочь воду в ступе, свой выбор вы сделали.

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

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

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

[valexey]

А кто в соседней теме написал цикл неправильно?
И я не про эффективность, а именно про правильность.

Если что - я там циклов вообще не писал, я писал решение задачи без циклов :-)

[ilovb]

Ну если я там ничего не пропустил, то всего ошибки было две.
Ну Kemet ошибся по невнимательности да (неудачный рефакторинг там
И я вроде как... (только не в цикле) Но в свое оправдание скажу что в условии не оговорено, как должен реагировать алгоритм если элементов в массиве меньше двух. Потому я предположил, что инвариант LEN > 1 обеспечивается снаружи.

[DIzer]

Гм. Ну, придумай ассерт для данного случая. Алсо, в какой код будешь ассерт втыкать? В код микроконтроллера? :-D

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

[valexey]

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

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

Поэтому assert тут вообще не вариант. Просто не удастся придумать логическое условие для assert'а и не получится придумать место куда его воткнуть (даже если предположить, что assert в коде микроконтроллера может сделать что-то полезное).

[DIzer]

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

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

[vlad]

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

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

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

[albobin]

Это. конечно, не моё дело, но как-то мало верится, что микроконтроллер имеет такой баг в таком месте  . Это же не экзотика  какая-то (I2C) для областей применения таких камней( наверное типа  MSP430). Может быть это отмазка  хардварщиков  (лажанулись где-нибудь) или не срюхали нюансы.  Сам я не спец (но когда-то давно имел некоторое отношение к схемным делам) , потому с лёгкостью предпоЛАЖения делаю:)

[DIzer]

Это. конечно, не моё дело, но как-то мало верится, что микроконтроллер имеет такой баг в таком месте  . Это же не экзотика  какая-то (I2C) для областей применения таких камней( наверное типа  MSP430). Может быть это отмазка  хардварщиков  (лажанулись где-нибудь) или не срюхали нюансы.  Сам я не спец (но когда-то давно имел некоторое отношение к схемным делам) , потому с лёгкостью предпоЛАЖения делаю:)

А что это меняет с точки зрения людей которые занимаются чисто обработкой сигнала поступающего с железяки?

[albobin]

Агрессивно не принимать "отмазки". Требовать "железных" доказательств
Железка чай доморощенная, не пришлая.

[DIzer]

Те упираются рогами в свою позицию , и что дальше?