Oberon space
General Category => Общий раздел => Тема начата: valexey от Июнь 06, 2012, 08:32:46 am
-
Чтобы было понятно о чем речь, небольшое вступление:
Мы создаем некий програмно-аппаратный комплекс. Ну, как комплекс.. Сенсор + цифровой мозг (микроконтроллер, плата) + bluetooth low energy по которому эти данные передаются на какой-нибудь iPhone, или персоналку, и где они затем в реальном времени забавными численными методами обрабатываются. Решение околомедицинское (ну, то есть не для реанимации, но для фонового мониторинга пациентов, для людей вообще следящих за своим здоровьем, для тех кто занимается фитнесом в том числе, для тех кто любит полазить по горам).
У сенсора есть некий параметр, которым можно рулить как с микроконтроллера, так и с iPhone/PC. Параметр критически важный, если его выставить не правильно, то процесс измерения нарушится.
Буквально пару дней назад внезапно обнаружилось странное: выставляем одно значение этого параметра, а сенсор нам говорит, что выставлено на самом деле совсем другое. Ну, то есть скажем выставили параметр в единицу, а он говорит, что нифига, тройка там. Плюс были еще некие странности с непосредственно данными получаемыми от собственно процесса измерений. Начали разбираться. На стороне iPhone проверили - все ОК, тут ошибки нет. Пошли разбираться с микроконтроллером. Посмотрели код - все вроде бы хорошо. Пошли дебажить протокол обмена между ним и сенсором. Дебаггер там конечно никак не поможет, поэтому воткнули осцилограф, пошли битики считать на нем. Там вроде тоже все хорошо. Пародоксальная ситуация - все хорошо, а параметр выставляется не правильно!
Ладно, пошли шагать в дебагере по коду микроконтроллера, а ну как там ошибка? Ошибки в коде не обнаружилось, зато обнаружилось, что после того как байт с сенсора принят, в момент посылки сигнала STOP по I2C, принятый байт портится. Если в байте было число n, то становится 2*n+1 (ну, или (n << 1) | 1 ). А поскольку значения-результаты измерений у нас были двух байтовые, то вместо числа 10, мы получали число 277, а вместо 1 мы конечно же получали 3 (тот параметр однобайтовый). Кода отвечающего за это поведения просто нет - ошибка на уровне камня. (а камень у нас от всем известной американской компании широко известной в том числе научными калькуляторами и микроконтроллерами). Воткнули код для обхода этой ошибки, теперь у нас все работает корректно.
При чем тут циклы? А циклы тут не при чем, как и в случае всех остальных ошибок которые я видел как минимум за последний год в нашей команде. Процентов 70-80 ошибок которые вылезают имеют характер подобный вышеописанной ошибке.
PS. И пошаговый отладчик, логгирование и осцилограф помогает отловить именно такие вот ошибки, которые другими методами отловить просто не реально (а таких ошибок, повторю, процентов 70-80). А циклы в отладчике никто не гоняет, в них ошибок просто не бывает.
-
И... что вы хотели этим примером сказать? Лично я вижу следующее... на вход в вашу систему поступают неверные (в контексте вашей модели обработки) данные. Вы модифицировали (расширили) модель их обработки и стало все ОК... банальщина... или я что то не улавливаю?
Циклы тут действительно не причем.. но также не причем и Прометей, коровник, и ежик в тумане..
-
И... что вы хотели этим примером сказать? Лично я вижу следующее... на вход в вашу систему поступают неверные (в контексте вашей модели обработки) данные. Вы модифицировали (расширили) модель их обработки и стало все ОК... банальщина... или я что то не улавливаю?
Дело в том, что и сенсор и микроконтроллер и алгоритмы на чем-то мощном (тот же iPhone) - это все наша система. Целиком и полностью. Если проводить аналог, для тех кто привык к десктопам, представьте себе, что ваш процессор при сложении некоторых чисел стал выдавать удвоенный результат.
Нет, модель обработки не меняли (точнее меняли, это был промежуточный вариант, но это приводило к естественному падению разрешающей способности - вместо 16ти бит получалось 14ть бит, что мало), проблему получилось обойти на уровне кода микроконтроллера. Теперь данные не теряются, имеем полные 16ть бит.
А что хотел сказать, я сказал уже в PS, не вижу смысла повторять.
-
а это что такое "Воткнули код для обхода этой ошибки, теперь у нас все работает корректно." - в моей системе понятий это и есть уточнение модели.
-
а это что такое "Воткнули код для обхода этой ошибки, теперь у нас все работает корректно." - в моей системе понятий это и есть уточнение модели.
Код микроконтроллера. Ведь его тоже программируем мы. Этот воткнутый код - типичный workaround. Логически он ниоткуда не следует. В следующей ревизии камня он будет, видимо, бесполезен либо вреден.
-
Далее, что за фигня
PS. И пошаговый отладчик, логгирование и осцилограф помогает отловить именно такие вот ошибки, которые другими методами отловить просто не реально (а таких ошибок, повторю, процентов 70-80). А циклы в отладчике никто не гоняет, в них ошибок просто не бывает.
ВАШУ проблему вполне решает ПОНИМАНИЕ задачи и куча следующих из этого
ассертов на входе... (не инфо21 в чем то увы прав.... :( )
-
А я согласен с valexey. Я пошаговый отладчик запускаю в ровно тех же случаях, когда ошибка возникает слоем ниже моего кода.
В своем коде обычно ошибки и так видно. Я писал и по 1,5к строк не запуская отладчик вообще.
Написал, запустил, словил исключения, поправил опечатки, опять запустил... и т.д.
А точки останова использую, чтобы посмотреть переменные в определенный момент пространства/времени. И чаще в чужом коде конечно.
-
Далее, что за фигня
PS. И пошаговый отладчик, логгирование и осцилограф помогает отловить именно такие вот ошибки, которые другими методами отловить просто не реально (а таких ошибок, повторю, процентов 70-80). А циклы в отладчике никто не гоняет, в них ошибок просто не бывает.
ВАШУ проблему вполне решает ПОНИМАНИЕ задачи и куча следующих из этого
ассертов на входе... (не инфо21 в чем то увы прав.... :( )
Гм. Ну, придумай ассерт для данного случая. Алсо, в какой код будешь ассерт втыкать? В код микроконтроллера? :-D
-
И про циклы... А откуда у info21 вообще взялась статистика об ошибках в циклах у проф. кодеров?
В моей практике нетривиальные циклы попадаются очень редко. Подавляющее большинство циклов - это форычи и всякие разновидности линейного поиска. Один единственный раз в жизни мне показалось что хорошо подходит дейкстра, но в итоге я понял что он у меня вылез как следствие индусскости общего решения, и был заменен на линейный поиск.
И вообще имхо нетривиальный цикл в большинстве случаев - следствие недопонимания задачи.
-
Для статистики:
Вот прямо сейчас правлю модуль 6к строк. (расчет себестоимости)
Форычи - 137 штук
Форы - 9 штук
Вайлы - 0 штук
Ну и Ифы до кучи - 240 штук
-
И вообще имхо нетривиальный цикл в большинстве случаев - следствие недопонимания задачи.
Либо это какой-то хитрозакрученный алгоритм/численный метод.
-
Да, да. А сложная математика имхо ваще должна писаться в виде отдельной библиотеки с особой тщательностью и прилежностью. И еще вопрос должен ли быть программист при этом математиком.
Мое имхо - программист и математик должны быть в разных лицах, и каждый должен хорошо знать именно свое дело.
А еще лучше использовать сторонние библиотеки, которые уже годами тестируются.
-
Да, да. А сложная математика имхо ваще должна писаться в виде отдельной библиотеки с особой тщательностью и прилежностью. И еще вопрос должен ли быть программист при этом математиком.
Мое имхо - программист и математик должны быть в разных лицах, и каждый должен хорошо знать именно свое дело.
Ну, как минимум это должен быть алгоритмист с навыками промышленного программирования.
А еще лучше использовать сторонние библиотеки, которые уже годами тестируются.
Кстати, не всегда. По крайней мере, по нашему опыту если судить, то доморощенное работает как минимум не хуже библиотечного (для данной конкретной задачи). Тем более что появляется возможность заточки алгоритмов под конкретно нашу задачу. А иногда просто не получается найти библиотеку умеющую что нужно и применимую там где нужно.
Но конечно в большенстве случаев, если есть возможность, то лучше код не писать, а использовать готовый оттестированный. Это экономит время и позволяет быстрее выкатить прототип и пробежаться по другим, принципиальным, граблям.
-
При чем тут циклы? А циклы тут не при чем, как и в случае всех остальных ошибок которые я видел как минимум за последний год в нашей команде. Процентов 70-80 ошибок которые вылезают имеют характер подобный вышеописанной ошибке.
С одной стороны, это верно. Если суммировать все то дерьмо, с которым приходится сталкиваться, то процент проблем от циклов там ничтожен.
Но не равен нулю. А если кто-то не видит проблем, то, возможно, ему просто нечем их видеть.
С другой стороны, мне непонятен объем усилий, направленных на обоснования того, что не нужно владеть этим элементом ремесла.
Ну что ж, это выбор каждого.
-
С одной стороны, это верно. Если суммировать все то дерьмо, с которым приходится сталкиваться, то процент проблем от циклов там ничтожен.
Но не равен нулю. А если кто-то не видит проблем, то, возможно, ему просто нечем их видеть.
С другой стороны, мне непонятен объем усилий, направленных на обоснования того, что не нужно владеть этим элементом ремесла.
Ну что ж, это выбор каждого.
С третьей стороны, возможно у нас этих ошибок нет, или почти нет, потому, что мы умеем правильно строить циклы? :-)
-
С третьей стороны, возможно у нас этих ошибок нет, или почти нет, потому, что мы умеем правильно строить циклы? :-)
Ошибок может быть и нет, но вторая часть неверна абсолютно, судя по сообщениям в соседней теме :)
-
С третьей стороны, возможно у нас этих ошибок нет, или почти нет, потому, что мы умеем правильно строить циклы? :-)
Ошибок может быть и нет, но вторая часть неверна абсолютно, судя по сообщениям в соседней теме :)
А может мы их строим альтернативно-верным способом? :-) Вообще, где математически коректное доказательство того, что именно тот способ построения циклов является единственно верным?
-
Да чего толочь воду в ступе, свой выбор вы сделали.
-
А кто в соседней теме написал цикл неправильно?
И я не про эффективность, а именно про правильность.
-
Да чего толочь воду в ступе, свой выбор вы сделали.
Какой выбор и выбор чего?
Вообще все вокруг такое сырое и разное, что, по моим наблюдениям, нет какого-то Единственно Верного Конкретного пути и метода делать хорошо.
Кстати неоднократно на форумах проскакивала мысль, что программисты это такие недоинженеры, что программирование слишком молодо еще, и что программистам еще учиться и учиться у настоящих инженеров, вот например у инженеров которые проектируют электронное оборудование (платы, чипы, всякие схемы). Так вот, немного окунувшись в тот сказочный мир, могу сказать, что багов там ничуть не меньше чем в ПО где стоимость ошибки и сложность продукта примерно сопоставима. То есть ошибок (критических и около того) в каком-нибудь микроконтроллере (именно камне, не прошивке) примерно столько же сколько в софтверной библиотеке сопостовимой сложности. И задокументировано это все ничуть не лучше.
В том софте что на виду ошибок больше просто потому, что цена ошибки и исправления ошибки тут крайне низка при достаточно большой сложности. Цена эта примерно такая же как в чем-то спаянном на коленке, при этом сложность софта этого несопоставимо выше.
-
А кто в соседней теме написал цикл неправильно?
И я не про эффективность, а именно про правильность.
Если что - я там циклов вообще не писал, я писал решение задачи без циклов :-)
-
Ну если я там ничего не пропустил, то всего ошибки было две.
Ну Kemet ошибся по невнимательности да (неудачный рефакторинг там :))
И я вроде как... (только не в цикле) Но в свое оправдание скажу что в условии не оговорено, как должен реагировать алгоритм если элементов в массиве меньше двух. Потому я предположил, что инвариант LEN > 1 обеспечивается снаружи.
-
Гм. Ну, придумай ассерт для данного случая. Алсо, в какой код будешь ассерт втыкать? В код микроконтроллера? :-D
Ассерты нужны для того чтобы разделить (изолировавать) - "надежную" подсистему от ненадежных данных..В вашем случае -использование этой техники позволяет не заниматься проверками алгоритмов и .т.д. , а сразу перейти к рассмотрению проблемной части. - не заниматься проверками циклов и т. д. в расчетной части а сразу сконцентрироваться на "проблематичной части" - железо , либо прошивка микроконтроллера ( если она выделяется в "неблагонадежную" подсистему). Вот и все... Эта метода работает всегда..когда можно ее применить.... в последней фразе есть и слабость этого подхода(он требует понимание системы перед созданием реализации).. в реальности (в особенности на продвинутых задачах) эволюция представлений о системе происходит вместе с реализацией и поэтому полную систему ассертов (как и инвариантов описывающих эту систему) создать затруднительно или невозможно (исполняющему лицу)...т.е комментировать "Гм. Ну, придумай ассерт для данного случая. Алсо, в какой код будешь ассерт втыкать? В код микроконтроллера? :" по словно у меня желания нет.
-
В данном случае, от этой ошибки железяки никаким ассертом защититься нельзя просто потому, что данные всегда идут непредсказуемые (любое число от 0 до 0xffff), точнее не зависящие от ПО, а в основном зависящие от внешних условий (физических факторов) + на это еще накладывается белый шум (хотя тут в цвете шума могу ошибаться).
Единственный вариант - это копить толстую статистику по данным и смотреть отклонения от предполагаемой статистической модели по множеству факторов (например один из факторов можно придумать - распределение четных и не четных чисел, но этот фактор на ум приходит уже ПОСЛЕ того как ошибку отловили другими методами). Но это все уже существенный оверкилл.
Поэтому assert тут вообще не вариант. Просто не удастся придумать логическое условие для assert'а и не получится придумать место куда его воткнуть (даже если предположить, что assert в коде микроконтроллера может сделать что-то полезное).
-
В данном случае, от этой ошибки железяки никаким ассертом защититься нельзя просто потому, что данные всегда идут непредсказуемые (любое число от 0 до 0xffff), точнее не зависящие от ПО, а в основном зависящие от внешних условий (физических факторов) + на это еще накладывается белый шум (хотя тут в цвете шума могу ошибаться).
Да... на практике это вопрос решается поверками оборудования (гоняют оборудование на тестовых образцах в контролируемых условиях)- по этому железо считается заведомо "подозрительной" подсистемой... в совковские времена существовали метрологические институты.. сейчас на этой "ниве" запитывается куча частных контор.Алексей к чему я это говорю. метода вокруг которой водят хороводы "коровцы" полезная и рабочая. Но во многих практических ситуациях трудно применимая - отказ от ее применения должен быть вполне сознательным и обусловленным грамотно. :)
-
С другой стороны, мне непонятен объем усилий, направленных на обоснования того, что не нужно владеть этим элементом ремесла.
Ну что ж, это выбор каждого.
Да нет никаких контр-усилий. Есть одностороннее проталкивание конкретной формальной методики (цикл Дейкстры и Ко) конкретным адептом данной методики (info21). Причем все достоинство данной методики сосредоточено исключительно в ее формальности. Вещь в себе. Когда смотришь на отражение этой методики в результирующем коде с позиции читателя, то видишь что-то от "нафига так сложно" до полного "говнокода" (в зависимоти от конкретного примера). Когда указанному адепту говоришь, что результирующий код не читабельный, то в ответ слышишь:
- зато код автоматом пишется
- в коде нет ошибок
- вы просто не понимаете мою методику
- гнилые аналогии с другими формальными методиками (матан), доказавшими свою состоятельность на практике (в отличие от)
Вполне естественна ответная реакция:
- без данной методики люди успешно обходятся (не вляпываясь в проблемы, которая эта методика, якобы, решает)
- важность проблемы, решаемой методикой, сильно преувеличениа (если смотреть в промышленных масштабах)
-
Это. конечно, не моё дело, но как-то мало верится, что микроконтроллер имеет такой баг в таком месте . Это же не экзотика какая-то (I2C) для областей применения таких камней( наверное типа MSP430). Может быть это отмазка хардварщиков (лажанулись где-нибудь) или не срюхали нюансы. Сам я не спец (но когда-то давно имел некоторое отношение к схемным делам) , потому с лёгкостью предпоЛАЖения делаю:)
-
Это. конечно, не моё дело, но как-то мало верится, что микроконтроллер имеет такой баг в таком месте . Это же не экзотика какая-то (I2C) для областей применения таких камней( наверное типа MSP430). Может быть это отмазка хардварщиков (лажанулись где-нибудь) или не срюхали нюансы. Сам я не спец (но когда-то давно имел некоторое отношение к схемным делам) , потому с лёгкостью предпоЛАЖения делаю:)
А что это меняет с точки зрения людей которые занимаются чисто обработкой сигнала поступающего с железяки?
-
Агрессивно не принимать "отмазки". Требовать "железных" доказательств :)
Железка чай доморощенная, не пришлая.
-
Те упираются рогами в свою позицию , и что дальше?
-
Дальше пусть верхи бодаются.
Ладно бы устройство было для ядрёного реактора, а то ж медицина!
-
Дальше пусть верхи бодаются.
Ладно бы устройство было для ядрёного реактора, а то ж медицина!
а как же премия в квартал?
-
Это. конечно, не моё дело, но как-то мало верится, что микроконтроллер имеет такой баг в таком месте . Это же не экзотика какая-то (I2C) для областей применения таких камней( наверное типа MSP430). Может быть это отмазка хардварщиков (лажанулись где-нибудь) или не срюхали нюансы. Сам я не спец (но когда-то давно имел некоторое отношение к схемным делам) , потому с лёгкостью предпоЛАЖения делаю:)
На msp430 как раз все нормально (если бы у нас не было нашего же аналогичного решения на msp430 с тем же самым сенсором где идет общение по тому же самому протоколу, ловля бага была бы более занятной и длитиельной). А баг в свежем микроконтроллере (точнее его версии), который совсем не msp430. Если что, на него пока даже ерраты от производителя нету (если ты имел дело с микроконтроллерами, то это должно сказать о многом :-) ).
-
на него пока даже ерраты от производителя нету (если ты имел дело с микроконтроллерами, то это должно сказать о многом :-) ).
Можно сказать, что не имел (рядом немного посидел:) , но после слов об отсутствии ерраты сочувственно умолкаю.
-
Да нет никаких контр-усилий. Есть одностороннее проталкивание конкретной формальной методики (цикл Дейкстры и Ко) конкретным адептом данной методики (info21).
Это совершенно неверно.
Во-первых, Info21 элементарно не владеет методикой, о чем я неоднократно писал.
Во-вторых, он, натурально, шизанулся на цикле Дейкстры. Это, кстати, следствие пункта 1.
К тому, что я говорю Info21 вообще не имеет никакого отношения.
-
А может мы их строим альтернативно-верным способом? :-) Вообще, где математически коректное доказательство того, что именно тот способ построения циклов является единственно верным?
Между прочим, valexey, попробуйте со своей командой сделать простой эксперимент. Надеюсь, все читали про двоичный поиск. Решение задачи о голландском нац. флаге (сортировка чисел от 1 до 3), тоже, без сомнения, видели. Попробуйте восстановить по памяти эти программы, они очень короткие. Надеюсь, память у вас не фотографическая, и программы придется построить. Альтернативно-верным или любым другим способом.
-
В качестве стёба, "цикл" в честь голландского флага на МАМПСе.
Arrange(flag)
N bardak,colour
S bardak=flag,flag=""
F colour=0,1,2 S $P(flag,colour,$L(bardak,colour))=""
Q
-
В задаче оказывается есть ограничения на допустимые операции (только перестановка двух элементов).
Так что мой предыдущий пост - мимо кассы :(
-
А может мы их строим альтернативно-верным способом? :-) Вообще, где математически коректное доказательство того, что именно тот способ построения циклов является единственно верным?
Между прочим, valexey, попробуйте со своей командой сделать простой эксперимент. Надеюсь, все читали про двоичный поиск. Решение задачи о голландском нац. флаге (сортировка чисел от 1 до 3), тоже, без сомнения, видели. Попробуйте восстановить по памяти эти программы, они очень короткие. Надеюсь, память у вас не фотографическая, и программы придется построить. Альтернативно-верным или любым другим способом.
Ну, поставил эксперимент на себе. Пока двоичный поиск (заодно немного плюсы вспомнил):
template<typename I, typename T>
I search(const I begin, const I end, T what) {
assert(begin<end);
auto first = begin;
auto last = end-1;
for (size_t i=0; i<(size_t)log2(std::distance(begin, end))+1; ++i) {
auto current = first+std::distance(first,last)/2;
if (*current == what) return current;
else if (*current < what) first = current+1;
else last = current;
if (first == last) return end;
}
assert(false);
return end;
}
Очень надеюсь, что здесь есть ошибка.