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

За да получиш момент t+89898932 в общия случай трябва да минеш през всички състояния, започвайки от t0 и подавайки същите входни въздействия. Само тогава може да си 100% сигурен, че ще получиш същото, каквото и въпросния алгоритъм.
Иначе казано НЕ МОЖЕШ ДА ПРЕДВИДИШ с достатъчна сигурност какво ще направи произволен алгоритъм, без да го изпълниш 1:1 с цялата му предистория. Всякакви анализи се свеждат само до "прогнози" с някаква вероятност в зависимост дали алгоритъма не е частен случай и заложен в самия анализ.

Ние започнахме от тук:



В общия случай ядрото трябва да "мърда" когато има задачи (не е задължително да са нишки на RTOS). Някои задачи обслужват периферии и условно ги наричаме драйвери, често тия драйвери си приказват с нещо като стекове и т.н. Термините са от RTOS но пак казвам той не е задължителен.

Въпросът е че всички тия задачи/модули или както там ги наричаме са си автомати с памет.

И не може само по техния вход да определиш какво и кога ще изплюят на изхода си. Дори и да имаш някаква идея, тя ще е непълна и трябва задължително да ги изпълняваш. И няма значение дали на входа имаш хардуерен статус от периферия или софтуерен статус от друг модул. Няма значение, защото каквото и да се знае за входа, то е недостатъчно за да се ПРЕДВИДИ априори изхода и да се спести изпълнението. Само изпълнението на един модул може да доведе до промяна на неговия статус и ако от него зависи друг модул, трябва и той да се изпълни, след него друг и друг и друг и друг и тая поредица също е непредвидима без изпълнение.



Zdrav, разбира се, че автоматите не са само жици. Освен това има много видове автомати. Примерно първото изречение на тоя цитат намеква за нещо от сорта на краен автомат. Но второто е в малко по-широк контекст с тоя "non deterministic way"... Иначе човекът може и да знае много неща, не се сещам кой е. Но няма значение щото си му извадил думите от устата и не става ясно дали говори за състояние на някакъв автомат (какъв?), състояние на програма или за състояние на болен пациент. Състояние някакво

Гичо това е "автомат с памет", той се държи така както описваш. Проблемът е че ТИ не може да му предвидиш поведението. Единственият начин да "предвидиш" на 100% какво ще се случи след 3млрд събития е да ги проиграеш на реална платка или на достатъчно добър симулатор. Но това не е прогнозиране, това е проиграване, т.е. реално изпълнение.
От това следват много неща. Първото е че не можеш безпроблемно да го променяш. Значи ти тоя автомат го имаш в някаква форма. Дали ще е на схема + сорсове няма значение. Въпросът е, че по тая форма може да правиш автоматично само козметични промени. Примерно може да компилираш с друг компилатор. Но дори и при тази козметика има риск поведението да се промени. И за да разбереш как точно се променило след 3млрд. събития пак трябва да ги проиграваш.
И тъй като не всеки автомат с памет е краен автомат. Даже по-скоро рядко някой е. То "проиграването" е винаги непълно и винаги могат да се измислят някакви други 3млрд. или в различна последователност събития, които не си проиграл. Т.е. никога не можеш да си 100% сигурен че два автомата ще имат еднакво поведение, колкото и описанията им да си приличат. Няма 100% добър тест, няма 100% bug free няма куп неща все следствия на проблема с "предвидимостта"...

уфф, стига с тоя ПИД

За бонго


За Тони и останалите в дискусията за софтуера


п.с. мисля Миро ме разбра

"Състоянието" е това което е същественото при автомата с памет. Състоянието освен че може да се пази във физическа памет има и връзка с програмата, която изпълнява автомата. Зад "памет" в "автомат с памет" не стои просто някакъв сторидж, регистри например и толкова.

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


Ако новия компилатор е променил поведението В ЗОНАТА НА ДЕФИНИРАНО поведение то това значи че той е сбъркал при превода и е направил различен алгоритъм (или обратното - първия компилатор е сгрешил, а втория е прав). Това не променя смисъла - това че описанието и инструментариума имат бъгове няма отношение към дискусията. Ако е променил времеви характеристики може да измени споменатите contrain-и за дефинирана зона.
И тези неща с другия компилатор, са характерни за определени езици, който за съжаление са основните в арсенала на ембедед програмистите. Което показва че те не са 100% дефинирани и допускат такива неточности, които се гонят с разни подходи за уточняване на нещата, недоизмислени в стандарта (misra и сие).
Не знам дали има език който да е 100% свободен от такива двусмислия, позволяващи тълкувание - предполагам че дори в математиката след хилядолетия работа има някъде малки дупки, така че едва ли има начин да сме сигурни за далеч по-скорошни области.

А, не - не ми вменявай неща които не съм казал - говорихме за "първите" 3 млрд събития и не съм твърдял че БЕЗ АЛГОРИТЪМА ще успея да извадя C кода на твоето приложение - ако ще говорим за други 3млрд то само потвърждаваш факта че тяхната промяна ще доведе до разлика - т.е. пак има степен на "предвидимост". Въпросът беше дали ако щракнем ресета и пусне същите 3млрд ще получим пак същия резултат (ако не сме флашнали нов фирмуер междинно)?

Да погледнем от друга страна - как би постигнал защита от клониране на кода ти, примерно в микроконтролерна система? Масовият подход е да се ограничи достъпа до кода - компилирания и сорса. Айде сорса лесно се пази, но дори само ако оставиш readout защитата на флаша на чипа и си готов конкуренцията да бълва абсолютно същия продукт като твоя, даже прилагайки копие от твоята документация и дори ти не би могъл да хванеш кое е клонинг по поведението му! Липсата на сорс не пречи да клонират, а затруднява модифицирането, но аз не говорех за модифициране на алгоритъма - говорех за един определен алгоритъм, в един коя си версия на фирмуера, и произволна, но дефиниран последователност от стимули. Смяната и на един бит във кода на фирмуера може да промени поведението, но докато не смениш поне един бит няма да видиш разлика. Смяната и на един стимул (като съдържание или време) може да смени поведението, но докато не смениш поне един стимул няма да видиш разлика в поведението!

Едит: забравих:

За това ще се съглася, но не мисля че това значи че тестовете са безсмислени - защото така излиза ако твърдението идва да покаже че няма как някакъв test case да даде предвидим резултат, по който да се каже "ОК" или не? Това че не 100% теста значи едно просто нещо - не са хванати 100% от възможните ситуации - т.е. комбинации от състояние и входни събития.
Дори да има 100% coverage на теста това не гарантира че са хванати всички ситуации, понеже през един и същ клон на кода може да се мине с различни данни много пъти, а coverage-а гарантира че е минато "поне веднъж".

gicho, ако не познавах щях да си помисля че се ебаваш с мен

Един виц по темата - един човек си поръчал да му ушият костюм. Отива на проба и вижда че единия ръкав по-дълъг от другия. Пита шивача и той му казва че ако си държи едната ръка така пък другата еди как си няма да се забелязва. Гледа яката крива, шивачът му обяснява как да си държи главата, кръста и така нататък. Човекът послушал шивача, облякъл костюма а хора по улицата си казали "брей какъв хубав костюм пък какъв идиот го носи"

Та и твоята работа... аз ти обяснявам, че има проблем, а ти ми казваш как да се правя на идиот

Не може да предвидиш поведението на произволен автомат с памет. Няма значение как, просто не можеш. Проблемът не е въпрос на точност, не е въпрос на качество на автомата. Просто НЕ МОЖЕШ.
Колко пъти и на какъв език да ти го кажа, че да ме разбереш?

Относно входните стимули. Ако не познаваш автомата няма значение дали ще му подадеш 3 или 3млрд. стимула. Така или иначе нищо не правиш. Ако не знаеш каква е логиката на автомата няма как да я определиш според реакцията му на входни стимули. Затова и като е заключен един процесор и не знаеш какво трябва да прави - не можеш да го клонираш. Колкото искаш и каквито искаш стимули да му подаваш е все тая.
Стимулите към един автомат с памет по дефиниция са безкрайно множество. На практика не можеш да работиш с безкраен брой стимули, защото според науката Вселената все пак има някакъв ограничен живот. Примерно ако имаш конзолно приложение няма как да му напишеш всички възможни глупости на stdin. Винаги може да се напишат още мнооооого, безкрайно мноооого.
Винаги когато говорим за стимули на практика, се има предвид някаква безкрайно малка извадка. Ако тази извадка е направена на случаен принцип, то само се бъзикаш и нищо не правиш. За да не е случайна извадката обаче, трябва да познаваш логиката на конкретния автомат. Т.е. за да има някакъв смисъл от упражнението трябва И логиката да ти е известна И стимулите да не са случайни. Ако това не е изпълнено, упражнението не ти носи никаква информация. Всъщност то и като е изпълнено пак нямаш нова информация, по-скоро може да провериш/тестваш (донякъде) информацията с която вече разполагаш.

Относно "предвидимостта"...
Значи под предвидимост очевидно се има предвид да предвидиш нещо, което не знаеш. В случая говорим за стимули, логика и поведение. Трябва да предвиди едно от тия три неща по останалите две. Но както обясних по-горе възможните стимули са безкрайно множество. Не е нещо което би могъл да предвидиш в крайно време. Логиката също не може да се предвижда, щото ако не я знаеш си в ситуация "заключен чеп". Нямаш полезни ходове. Остава поведение... То изглежда като предвидимо при дадени стимули и логика. За определени логики поведението даже може да се предвиди и за безброй стимули. За съжаление обаче тъй като логиката като цяло е непредвидимо нещо няма как да се провери дали тя позволява поведението само за определени стимули или за всякакви стимули. Демек трябва ни допълнителна информация за логиката за да кажем дали може да се правят прогнози за поведението. В примерите които сме коментирали дотук такава информация няма и няма как да бъде "предвидена".

След тия обяснения мисля че и сам би трябвало да можеш да си отговориш на въпросите, но за всеки случай:

Има значение... методът ти изисква да знаеш входните събития/стимули. А те както казахме са безкрайно нещо, така че няма как да приложиш тоя метод за всички възможни комбинации съответно "предвижданията" ти ще са непълни.


За предвиждането на една конкретна ситуация - не. Но прочети вица за идиота и костюма


Не, проиграваш защото не можеш по друг начин да предвидиш/получиш нищо... Няма контролируемо ползване - виж отново вица за идиота


Няма значение кой, какво, как и защо е променил. Щом има и един бит промяна си във филма. Това е потенциална промяна на логиката.


Естествено... логиката не може да се предвижда/отгатва ей така...

Миро, ти разглеждаш автомата като черна кутия (аз също) и много ясно, че от входните въздествия и изходните резултати бяма как да предвидиш какво ще излезне от черната кутия при произволни входни въздействия. Гичо обаче не го разглежда така и в последните постове постоянно повтаря как не само че му знае входните въздействия и изходните резултати, но му имал и сорс кода и алгоритъма и съдържанието на паметта също. Много ясно че тогава може да предвиди какво ще излезне. Демек вкараха се нагласистики и в спора що е то автомат с памет

Т.е. ако не е черна кутия, не е автомат с памет?!?
Аз мислех че говорим за какъвто и да е софтуер, но такъв който се проектира и прави от нас. Последно за какво говорим? За ривърс енжиниъринг? За black box testing?
Сериозно питам щото това което чета е объркващо освен ако мотивацията на дискусията не е: "да не оставим gicho да се измъкне".

Аз определено си мисля, че тука някой се опитва да смени условията. Разбира се че като казвам "програма" нямам предвид картинка с блокче с надпис "програма", а описание на конкретната програма, или по-друг начин казано, описание на която и да е програма, независимо дали е автомат с памет или комбинаторно. Да напомня че спора започна дали това твърдение за предвидуемостта е валидно и за автомат с памет, или само за комбинаторна.

Миро, казвам нещо, ти после ми казваш "обратното не е вярно" - как да го разбирам това? Аз ти говоря че факта че чрез изчитане на кода от незащитен чип ще успея да накарам нещо да спазва абсолютно същата логика идва да покаже че тази логика си е много предвидима, строго зависима от тоя код, а ти ми казваш че ако е защитен чипа няма да мога? Да де, трябва ли да пиша и else-овете навсякъде.

И ти си го написал кои са трите променливи, да го уточня че говоря за следното:



Ако смяташ че има други аргументи, дай да ги включим или да изчистим понятията. За да подскажа ще кажа че тук под логика разбирам програмата (сорс, бинари) а под стимули разбира стриймовете от събития, влизащи в системата (пак да кажем, че това има смисъла от момента Treset до текущия момент). В смисъл не е снимка на текущите стойности на входовете (freeze frame).
Ясно е че някъде се разминаване в разбиранията - надявам се че това е в дефиницията на "стимули" - та затова натъртвам че е стрийма от входните събития към програмата (логиката), започвайки от ресета до текущия момент.

Не можеш!
Приказката тръгна от това, че Гичо можел да си спести изпълнението на кода, защото можел да предвиди какъв ще е резултата. Не може!



При софтуера в горната формула под "логика" се има предвид *изпълнението* на някакъв код при някакво състояние на паметта. В общия случай тази "логика" не може да бъде представена по друг начин, някаква друга форма така че без да изпълняваме нищо директно да предвидим какъв ще е резултата. Ако искаме да знаем какъв ще е резултата от дадена програма трябва да се изпълни. Няма друг вариант.
Това дали имаш или нямаш сорс/hex/bin/exe в случая няма значение. Няма универсален алгоритъм по който от произволен сорс или код да генерира нещо, което да дава резултат без изпълнение. Ей така директно - хоп резултатче. То ако имаше нямаше да се налага да щракат толкова много тригерите на ядрата. Не можеш да си спестиш щракането...
Не може принципно! Може в частни случай където зяпаш сорса, шляпаш се по челото и те осенява гениална идея как може да стане по друг начин. Но в общия случай може само да се шляпаш по челото, но без идеи

Гичо, никакви условия не съм подменял... От самото начало ти обяснявам че като имаш някакъв код, който зависи от нещо на входа си и генерира някакъв изход. Не може да си спестиш изпълнението му. Не може да предвидиш какъв ще е резултата без да го изпълниш. И това не е защото кодът бил зле написан, не е заради фазите на луната и т.н. Принципно НЕ можеш!
Няма значение дали входа е променен статус на периферия или нещо друго. Това касае само въпросния код. Резултатът от изпълнението на кода е непредвидим без изпълнението му, дори да знаеш входните стимули, дори да имаш сорсове и т.н.

Тука стана баси и кашата .
Миро, ако след като знаем входните въздействия към черната кутия и знаем съдържанието на паметта и алгоритъма в черната кутия (демек тя вече не е черна) ако не можем да предвидим какъв ще е резултата тогава аджеба как сме го написали тоя алгоритъм и най-вече защо сме го написали?

Ааааа, за вас не знам

Аз когато мога да предвидя резултата, пиша направо него. Програми и алгоритми ползвам, само ако не мога директно да кажа какъв ще е резултата

Предполагам Миро има в предвид че ти не можеш да знаеш какъв е резултата, просто защото за да го знаеш, трябва да знаеш точно какво е ставало във всички предходни моменти така до самото начало.
Ето пример PID-а, получаваш грешка 0.5 но ти не можеш да предвидиш какъв ще е изхода ако не знаеш какво е била преди това.

Въпросът е как ще определиш изхода. Ако резултата го получаваш по същия алгоритъм и ти трябват същите данни както и на PID програмата, то това не е "предвиждане". Това си е изпълнение на същата програма само че на различен "хардуер".
Същината на спора беше че един автомат с памет не може да се шунтира или замени с нещо друго. Няма значение какво знаеш или не знаеш. Това което изкарва на изхода си тоя автомат няма как да го получиш по друг по-ефективен начин. А пък ако има по-добра алтернатива както пита и Dimitar за чий е сложен тоя автомат там