Я не работал с таким микроскопом, но работаю с зашумлёнными рентгеновскими изображениями, и первое, что там делается для увеличения соотношения сигнал/шум — это интегрирование (усреднение) по нескольким изображениям. То есть вместо одного изображения, которое вы снимаете 40 секунд, вы набираете пятнадцать штук, так что одна "фотография" будет сниматься 10 минут, а потом складываете их вместе попиксельно и делите на количество. Обычно выбирают степени двойки — 2, 4 ,8 ,16, 32, чтобы делить сдвигом, так быстрее (хотя современному компу при таких размерах изображений и обычное деление норм). Это позволяет достичь очень хороших результатов, при условии, что все усредняемые картинки сделаны без смещений, конечно (а если и так, то можно попытаться это дело перед усреднением скомпенсировать). Из моей практики — усреднение до 64 картинок имеет смысл, дальше разница гомеопатическая, но скажем между одной и шестнадцатью картиками — отличие очень велико. Ну а алгоритмы используются только когда по каким-то причинам мы не можем усреднять, либо усреднения недотаточно (деталь в движении, требования по скорости захвата и т.д.). Из алгоритмов — понижение шума вейвлетами может дать неплохие результаты.
Физтех, начало девяностых, лаборатория Владимира Максимовича Тучкевича. Куча измерительных приборов и рабочих мест с ДВК (те, что клон PDP). На первое апреля местный программист, в совершенстве знающий ОС RT11 пошутил, модифицировав драйвер принтера так, что после каждой третьей запятой он выводил слово "блин". Ну не совсем "блин", но я уж не буду тут уточнять. Научные работы докторов наук и письма заиграли новыми красками. Не все же читают распечатки. Самое прикольное, что драйвер разошёлся по отделам и ещё долго удивлял коллег. Такой вот был юмор. Но ему потом отомстили - он занимался тяжёлой атлетикой и у него возле рабочего места стояли две пудовые гири. Как-то вечером коллеги налили в углубления внизу этих гирь густой эпоксидки и поставили их на линолеум как ни в чём не бывало. Когда он начал их поднимать, все начали глумиться - что-то ты ослаб, Валера. Он правда смог оторвать их от пола, но с кусками линолеулема. Эти две дырки долго напоминали о весёлых временах.
На немецкой винде надо использую "Administratoren"
Тоже работает (после перезагрузки будет одноразовое сообщение что пароль некорректен, но на работоспособность не влияет, после второй перезагрузки его не будет)
Про маразм двух переходов я в общем согласен, просто в данной реализации можно задать скажем одно условие перехода по достижении переменной значения 5, а второе, в другое состояние при 10, и установив значение в 15 мы фактически активируем оба перехода, но выполнится только один (просто я знаю, как оно под капотом устроено). В статике это никак не проверяется, тут это на этапе дизайна автомата отсекать надо. Кстати не факт, что асинхронная модель расширенной версии как раз отработает оба перехода и следующие состояния параллельно, мне просто лень древнюю LabVIEW расчехлять, чтоб проверить.
Табличное представление в теории возможно, но в общем не очень нужно, потому что из представления автомата (а там просто граф) можно сгенерить нативный графический код LabVIEW, то есть одно графическое представление перебрасывается в другое, эквивалентное, и мне, мыслящему категориями потоков данных LabVIEW оно даже в чём-то понятнее (котя этот код мне не очень нравится).
А так там чистая незамутнённая логика, никакой магии, божественности и недетерминированности нет и в помине (с маленькой поправкой на то, что Windows не является ОСРВ в некоторых частных случаях).
Что ж, я рад, что хоть чем-то удалось удивить. Я так понял, что в "ВКП" эти диаграммы нарисованы чуть ли не MS Visio, а здесь у нас примитивное "Visio" прямо на борту, с возможностью редактирования и отладки, пошагового исполнения и т.п., что переводит программирование автоматов в разряд "как слышится — так и пишется". Нужно новое состояние — значит "New State", а новый переход — "New Transition", а больше там ничего и нет. В бекэнде там работает цикл обхода графа — состояние->переход->состояние и т.д. Не помню, что будет, если сработают два перехода (этим воскресным утром у меня нет компа под рукой), скорее всего выполнится тот, кто был создан первым, у него выше приоритет. Довольно элегантно решён вызов начинки стейта — там абстрактные интерфейсы, собственно стейт понятия не имеет что он там внутри вызывает — для него что коммуникация с ПЛК, что анализ изображения — всё едино. Ну там ещё по мелочи — есть переменные, само собой, которые я могу писать в одном состоянии и читать в другом и ими же могу управлять переходами. Элементы интерфейса тоже отражаются на переменные. Можно запустить несколько автоматов параллельно (скажем один управляет подающим конвейером, а второй — анализирует изображения), но это редко бывает надо, обычно у меня ПЛК есть для этого.
Вы правы, это картинка (Picture Control в терминах LabVIEW), но есть нюанс — она интерактивная.
Вот как создаётся такой автомат. Изначально у меня есть состояния Start (откуда я влетаю в машину состояний) и End (куда я выхожу, но так-то я могу сидеть в автомате так долго, как хочу):
Допустим я хочу сделать гильотину, которая по команде юзера (или внешнему сигналу) отрежет мне несколько ломтей чего либо. Опуская обвес датчиками, мне нужно три состояния - ожидание внешнего сигнала, собственно отрез и инкремент счётчика (в принципе я могу и двумя обойтись, засунув инкремент в отрез, но пусть будет три для наглядности), назову их Wait, Cut и Inc :
Теперь мне надо организовать транзакции между состояниями, тут всё довольно очевидно (у любого стостояния должна быть как минимум одна дефолтная транзакция, по умолчанию она замкнута сама на себя, но я их растяну вот так)
Теперь я набросаю наипростейший ГУЙ, ну пусть будет хотя бы так:
После этого мне надо настроить условия транзакций, заодно я их могу переименовать, чтоб нагляднее было (хотя я могу, конечно сделать х4х6х12 и т.д., но пусть будут осмысленные имена). Мне собственно только три надо — переход из ожидания в "отрез" срабатывает когда юзер жамкает по "Старт", затем переход из отреза в ожидание, когда число отрезов достигнуто, ну и выход, а дефолтные транзакции мне трогать не надо, они срабатывают автоматом, если другие не триггерятся:
Почти готово Осталось настроить состояния - собственно мне достаточно просто инкрементировать счётчик, ну и показывать его на экране (так то мне надо управлять гильотиной, так что в реальной жизни я добавлю больше кода для управления, чтобы послать сигнал, и.т.д). Каждое состояние может иметь несколько акций, они выполняются последовательно в пределах одного состояния, к примеру Inc будет выполнять два действия - никрементировать счётчик и потом обновлять интерфейс
Ну и вот, до тех пор пока не нажата кнопка старт, срабатывает дефолт транзакция состояния Wait, а если начинается работа, то мы прыгаем между состояниями Cut и Inc, и потом возвращаемся в Wait.
Это режим отладки с подсветкой - активное состояние обводится рамочкой, а активная транцакция подсвечивается синеньким (где-то в гифке имена транцакций потерялись, ну и ладно).
Технически линии транзакций рисуются безье кривой, так что я могу немного править диаграмму машины по вкусу, позиции лейблов тоже можно подвигать ну и состояния размещать как мне нравится (размер овалов менять нельзя), чистая косметика:
В принципе на C#/WPF это не очень сложно реализовать. В LabVIEW это где-то с седьмой версии появилось, стало быть где-то 2003 год, эх, двадцать лет прошло, вот ведь время летит.
Что касается примера из коммента выше, то там в первом стейте выполняется загрузка картинки и классификация
Собственно классификация - это предобученный классификатор
А транцзакции срабатывают соответственно классам. Вся иделогия в том, что из состояний наружу торчат их результаты, которыми и триггерятся транзакции.
Ну и дальше стейт для шестерёнок считает зубчики поиском границ
А другой для колёсиков считает в них дырочки
Как я уже писал, мне в принципе не надо заводить отдельный стейт на инкремент счётчика, вот, к примеру есля я хочу проверять упаковки шоколадок, чтобы быть уверенным, что автомат кладёт туда 12 штук:
то мне достаточно вот такой машины состояний:
Ну и в реальности оно, конечно сильно быстрее бежит, чем я поазал в режиме отладки с подсветкой выполнения:
Тот код, который выполняется внутри стейтов - суть как плагины организован, есть библиотека из готовых кирпичиков как для процесинга изображений, так и для общения с внешними устройствами (Modbus, OPC, OPC UA, TCP, платы ввода вывода и т.д.), но можно и самому написать, конечно.
Это же просто цитата из книги. Там идёт отсылка на две работы, оригинальная 1972 года Hafele J.C., Keating R.E. Science, 177, 1972, p.166. и следом Spencer D.E., Shama U. A new interpretation of the Hafele-Keating experiment. //Проблемы исследования Вселенной, вып. 21. СПб, 1999, с.250. Но надо читать и разбираться, это да, согласен.
Сергей Альбертович Салль в книге "Истоки и заблуждения релятивизма" утверждает что
"Самая известная проверка замедления хода времени в макроскопических условиях была осуществлена Дж.Хафелем и Р.Китингом. В этом опыте четыре экземпляра цезиевых часов помещались на реактивных самолетах, облетевших вокруг Земли в восточном и западном направлениях. Сравнивались показания часов, бывших на самолетах, и эталонных часов, установленных в Морской обсерватории в Вашингтоне. В современных учебниках утверждается, что эффект замедления хода времени был подтвержден. Однако несколько лет назад Китинг инициировал новую процедуру пересчета результатов этого эксперимента, и оказалось, что предсказанный СТО эффект замедления хода часов отсутствует, а прежний вывод был связан с неправомерной линеаризацией экспериментальных данных. Иными словами, результаты эксперимента были подогнаны под выводы СТО." Это 2006 года книжка.
Я это не к тому, что эффекта нет, просто замедление при таком эксперименте ничтожно. Но на МКС время замедленно, это да, и если верить интернетам, то вроде за полгода убегает семь тысячных секунды, что вполне измеримо.
@AndreyDmitriev попробовал все, о чем он "подозревал", изложить именно на LabVIEW.
Теоретически можно и на LabVIEW гильотину измыслить, там в общем есть визуальные инструменты для создания автоматов. Хотя я вообще больше по части пром обработки изображений, ну вот к примеру, сортировка и проверка лего деталек:
Или проверка пинов:
Там довольно примитивно всё - есть состояния и есть транзакции-переходы между состояниями, которые срабатывают при наступлении определённых условий. Я притормозил немножко исполнение, чтоб нагляднее было.
Дело вкуса, но мне тоже кнопки удобнее. У меня есть Kindle Oasis с кнопками и Onyx Boox Nova 3 Color c Kaleido Plus а также reMarkable, оба без кнопок, так вот свайп на обоих читалках иногда спонтанно не срабатывает и это при вдумчивом чтении достаёт неимоверно. То ли у меня пальцы слишком сухие, если послюнявить, то заметно лучше получается. Так что читаю в основном на оазисе и каждый раз пользуясь другими, думаю "ну что вам стоило вкорячить сюда пару копеечных кнопок для перелистывания"?
А вы точно ничего не путаете? Туда ставятся патроны LC422, они вообще говоря чипованные и вроде для перезаправки не предназначенные, чтобы "Отвинтили крышечку, долили чернила, закрутили" надо купить соответствующие пустые патроны с чипами. Чипы к ним отдельно тоже продаются (и всё это неоригинал, естественно). А неоригинальные наполненные LC422XL тоже в районе 25 евро за комплект, так что так на так и выходит.
А, понял. Ну тут отчасти личные предпочтения — я пользуюсь hp уже больше 25 лет и в техническом плане меня пока эта техника не подводила. Раньше я вообще заряжал картриджи шприцем из бутылки, потом достало, сейчас toner kingdom покупаю, я б не сказал что барахло, ни внешне ни по качеству печати они от оригинала не отличаются. Не, я честно попытался переползти на другую марку, и купил то ли Эпсон то ли Кэнон, но он довольно быстро отказал, да и конструктивно мне не очень понравился. Из струйников А3 вероятно brother mfc-j6540dw можно было рассмотреть, но и там оригинал патроны комплект 60 евро, а XL комплект под сотню, и вот мы снова смотрим в сторону неоригинальных.
вы треть тысячи долларов заплатили только ради того, чтобы сказать, что у вас принтер от HP (и картриджи к нему неизвестного состава). В чем смысл?
Ну в то время, когда я его покупал, это было единственное приемлемое по цене предложение за дуплекс принтер формата А3. А цветной лазерник такого формата стоил каких-то невменяемых денег. В принципе я им доволен, он неприхотливый, достаточно компактный и на хорошей бумаге очень прилично (для офисного принтера) печатает.
Это из разряда "как отъять максимально возможное количество денег у покупателя, притом так, чтобы он был свято уверен, что ему это выгодно".
Вот смотрите, у меня дома МФУ HP Office Jet 7720, куплен осенью 2019, ему почти пять лет (53 месяца, если быть точным). Отдал я за него 180 евро по какой-то акции-распродаже. Картриджи 953XL оригинальные нынче на амазоне стоят 180(!) евро. Я беру неоригинал за тридцать (он их вполне принимает после даунгрейда). Сейчас установлен пятый комплект картриджей, суммарно расходы 180+30*5 = 330 евро за пять лет. Отечатано на нём по счётчику 3718 листов, это в среднем 70 страниц в месяц. Мне предлагают план за 17 долларов, и это будет 17*53 = 901 доллар, почти втрое дороже. Кроме того, нагрузка у него очень неравномерная, он может пару-тройку месяцев вообще почти не использоваться, а может неделю интенсивно (в основном он нужен детям-гимназистам и супруге - она учитель рисования). Доставка картриджа на следующий рабочий день — вообще смешно, если надо что-то срочно напечатать, а у меня всегда лежит запасной.
Только я хотел написать, что бабочка - это насекомое, а не животное, а оказалось — таки да, animals.
Кстати, для того чтобы снабдить консольное приложение интерфейсом, можно Nuklear воспользоваться. Это очень лекговесная и простая штука, но там можно много чего сделать.
Монорепозиторий - это в том числе про управление зависимостями. Насколько он применим - зависит в общем от структуры проектов. Я использовал такой подход ещё с конца девяностых, где-то до 2007 года. Тогда мы хранили код, используя Microsoft Visual SourceSafe, была такая штука (ни TFS ни Git в то время не было, они где-то в 2005 появились). Так вот в SourceSafe была такая фишка, которая называлась "Линки". У меня проекты были основаны на плагин-архитектуре. В монорепозитории эти плагины хранились все скопом, а вот для каждого отдельного проекта заводилась виртуальная папка, куда необходимые модули линковались из монорепозитория. Если там были файлы, специфические для конкретного проекта, то в монорепозиторий они не попадали. Это было очень удобно. Я мог посмотреть как историю по отдельным проектам, так и по монорепозиторию целиком. Когда я забирал из репозитория код проекта, то на диске у меня появлялиь лишь файлы, исполользованные в проекте и ничего лишнего. Важно было то, что отдельные модули были вообще никак не связаны, технически все вызовы отправлялись в микроядро, а межмодульные вызовы были строго запрещены. Общались модули между собой, устанавливая соединение в рантайме через именованные очереди. Модулей было около трёхсот, а проектов -где-то полтора десятка, какой-то проект мого использовать 50-70 модулей, а какой-то - 20-30, из из модулей проекты собирались как из кубиков Лего. Ну и когда добавлялся новый функционал, то это само собой автоматом распространялось на все проекты, в которых этот модуль использовался. Всё бы ничего, но MS VSS проект был закрыт, на смену пришёл TFS. И компания решила напрочь выпилить линки, потому что мало кто их использовал и вообще это "плохая практика". Это действительно может быть плохой практикой, устроив ад из зависимостей, но при слабой связанности - было самое то. Короче, была куча дискуссий, и в ответ производитель TFS лишь писал - ну нет проблем, сделайте линки на вашем диске, на клиентской стороне. Так можно, конечно, но это абсолютно неудобно. Мы перебросили код в TFS и как-то выкрутились, но линки жаль, у меня теперь весь монорепозиторий валяется на диске и при работе с конкретными проектами я постоянно натыкаюсь на "ненужные" мне в данный момент артефакты. Конкретно сейчас мы переезжаем с TFS в Git, надо будет разобраться, как там.
Я не работал с таким микроскопом, но работаю с зашумлёнными рентгеновскими изображениями, и первое, что там делается для увеличения соотношения сигнал/шум — это интегрирование (усреднение) по нескольким изображениям. То есть вместо одного изображения, которое вы снимаете 40 секунд, вы набираете пятнадцать штук, так что одна "фотография" будет сниматься 10 минут, а потом складываете их вместе попиксельно и делите на количество. Обычно выбирают степени двойки — 2, 4 ,8 ,16, 32, чтобы делить сдвигом, так быстрее (хотя современному компу при таких размерах изображений и обычное деление норм). Это позволяет достичь очень хороших результатов, при условии, что все усредняемые картинки сделаны без смещений, конечно (а если и так, то можно попытаться это дело перед усреднением скомпенсировать). Из моей практики — усреднение до 64 картинок имеет смысл, дальше разница гомеопатическая, но скажем между одной и шестнадцатью картиками — отличие очень велико. Ну а алгоритмы используются только когда по каким-то причинам мы не можем усреднять, либо усреднения недотаточно (деталь в движении, требования по скорости захвата и т.д.). Из алгоритмов — понижение шума вейвлетами может дать неплохие результаты.
Физтех, начало девяностых, лаборатория Владимира Максимовича Тучкевича. Куча измерительных приборов и рабочих мест с ДВК (те, что клон PDP). На первое апреля местный программист, в совершенстве знающий ОС RT11 пошутил, модифицировав драйвер принтера так, что после каждой третьей запятой он выводил слово "блин". Ну не совсем "блин", но я уж не буду тут уточнять. Научные работы докторов наук и письма заиграли новыми красками. Не все же читают распечатки. Самое прикольное, что драйвер разошёлся по отделам и ещё долго удивлял коллег. Такой вот был юмор. Но ему потом отомстили - он занимался тяжёлой атлетикой и у него возле рабочего места стояли две пудовые гири. Как-то вечером коллеги налили в углубления внизу этих гирь густой эпоксидки и поставили их на линолеум как ни в чём не бывало. Когда он начал их поднимать, все начали глумиться - что-то ты ослаб, Валера. Он правда смог оторвать их от пола, но с кусками линолеулема. Эти две дырки долго напоминали о весёлых временах.
Да просто прошивка шестой версии
А я вместо oobe\bypassnro в этом месте из консоли сразу пользователя создаю:
C:\Windows\System32>net.exe user "Andrey" /add
C:\Windows\System32>net.exe localgroup "Administrators" "Andrey" /add
C:\Windows\System32>msoobe.exe && shutdown.exe -r
На немецкой винде надо использую "Administratoren"
Тоже работает (после перезагрузки будет одноразовое сообщение что пароль некорректен, но на работоспособность не влияет, после второй перезагрузки его не будет)
Про маразм двух переходов я в общем согласен, просто в данной реализации можно задать скажем одно условие перехода по достижении переменной значения 5, а второе, в другое состояние при 10, и установив значение в 15 мы фактически активируем оба перехода, но выполнится только один (просто я знаю, как оно под капотом устроено). В статике это никак не проверяется, тут это на этапе дизайна автомата отсекать надо. Кстати не факт, что асинхронная модель расширенной версии как раз отработает оба перехода и следующие состояния параллельно, мне просто лень древнюю LabVIEW расчехлять, чтоб проверить.
Табличное представление в теории возможно, но в общем не очень нужно, потому что из представления автомата (а там просто граф) можно сгенерить нативный графический код LabVIEW, то есть одно графическое представление перебрасывается в другое, эквивалентное, и мне, мыслящему категориями потоков данных LabVIEW оно даже в чём-то понятнее (котя этот код мне не очень нравится).
А так там чистая незамутнённая логика, никакой магии, божественности и недетерминированности нет и в помине (с маленькой поправкой на то, что Windows не является ОСРВ в некоторых частных случаях).
Совсем забыл написать — они сдёрнуты с экрана при помощи ScreenToGif.
Что ж, я рад, что хоть чем-то удалось удивить. Я так понял, что в "ВКП" эти диаграммы нарисованы чуть ли не MS Visio, а здесь у нас примитивное "Visio" прямо на борту, с возможностью редактирования и отладки, пошагового исполнения и т.п., что переводит программирование автоматов в разряд "как слышится — так и пишется". Нужно новое состояние — значит "New State", а новый переход — "New Transition", а больше там ничего и нет. В бекэнде там работает цикл обхода графа — состояние->переход->состояние и т.д. Не помню, что будет, если сработают два перехода (этим воскресным утром у меня нет компа под рукой), скорее всего выполнится тот, кто был создан первым, у него выше приоритет. Довольно элегантно решён вызов начинки стейта — там абстрактные интерфейсы, собственно стейт понятия не имеет что он там внутри вызывает — для него что коммуникация с ПЛК, что анализ изображения — всё едино. Ну там ещё по мелочи — есть переменные, само собой, которые я могу писать в одном состоянии и читать в другом и ими же могу управлять переходами. Элементы интерфейса тоже отражаются на переменные. Можно запустить несколько автоматов параллельно (скажем один управляет подающим конвейером, а второй — анализирует изображения), но это редко бывает надо, обычно у меня ПЛК есть для этого.
Кстати, помимо простенького LabVIEW State Diagram Toolkit, о котором шла речь выше, был ещё одно время навороченный LabVIEW State Chart Module. Визуально он чуть иначе выглядит:
Анатомия там вот такая:
помимо классических состояний (2), инициирующих (1) и терминальных (12) псевдосостояний и переходов (4) были введены супер-состояния (5), суб-состояния (9), ортогональные регионы (7 и 8), форки (6) и джойны (11), история состояний (10), порты (3) и вообще чёрта в ступе, всё это как синхронно, так и асинхронно и всё такое.
Но этот "швейцарский нож" не зашёл совершенно, в 2018 году вроде как разработка была прекращена.
Вот любопытно, а про бесплатную утилизацию отработанного "устройства iPhone" надпись типа такой будет?
(впрочем за аутентичность фото не ручаюсь, оно стырено с просторов интернета)
Приятно снова пообщаться, Вячеслав.
Вы правы, это картинка (Picture Control в терминах LabVIEW), но есть нюанс — она интерактивная.
Вот как создаётся такой автомат. Изначально у меня есть состояния Start (откуда я влетаю в машину состояний) и End (куда я выхожу, но так-то я могу сидеть в автомате так долго, как хочу):
Допустим я хочу сделать гильотину, которая по команде юзера (или внешнему сигналу) отрежет мне несколько ломтей чего либо. Опуская обвес датчиками, мне нужно три состояния - ожидание внешнего сигнала, собственно отрез и инкремент счётчика (в принципе я могу и двумя обойтись, засунув инкремент в отрез, но пусть будет три для наглядности), назову их Wait, Cut и Inc :
Теперь мне надо организовать транзакции между состояниями, тут всё довольно очевидно (у любого стостояния должна быть как минимум одна дефолтная транзакция, по умолчанию она замкнута сама на себя, но я их растяну вот так)
Теперь я набросаю наипростейший ГУЙ, ну пусть будет хотя бы так:
После этого мне надо настроить условия транзакций, заодно я их могу переименовать, чтоб нагляднее было (хотя я могу, конечно сделать х4х6х12 и т.д., но пусть будут осмысленные имена). Мне собственно только три надо — переход из ожидания в "отрез" срабатывает когда юзер жамкает по "Старт", затем переход из отреза в ожидание, когда число отрезов достигнуто, ну и выход, а дефолтные транзакции мне трогать не надо, они срабатывают автоматом, если другие не триггерятся:
Почти готово Осталось настроить состояния - собственно мне достаточно просто инкрементировать счётчик, ну и показывать его на экране (так то мне надо управлять гильотиной, так что в реальной жизни я добавлю больше кода для управления, чтобы послать сигнал, и.т.д). Каждое состояние может иметь несколько акций, они выполняются последовательно в пределах одного состояния, к примеру Inc будет выполнять два действия - никрементировать счётчик и потом обновлять интерфейс
Ну и вот, до тех пор пока не нажата кнопка старт, срабатывает дефолт транзакция состояния Wait, а если начинается работа, то мы прыгаем между состояниями Cut и Inc, и потом возвращаемся в Wait.
Это режим отладки с подсветкой - активное состояние обводится рамочкой, а активная транцакция подсвечивается синеньким (где-то в гифке имена транцакций потерялись, ну и ладно).
Технически линии транзакций рисуются безье кривой, так что я могу немного править диаграмму машины по вкусу, позиции лейблов тоже можно подвигать ну и состояния размещать как мне нравится (размер овалов менять нельзя), чистая косметика:
В принципе на C#/WPF это не очень сложно реализовать. В LabVIEW это где-то с седьмой версии появилось, стало быть где-то 2003 год, эх, двадцать лет прошло, вот ведь время летит.
Что касается примера из коммента выше, то там в первом стейте выполняется загрузка картинки и классификация
Собственно классификация - это предобученный классификатор
А транцзакции срабатывают соответственно классам. Вся иделогия в том, что из состояний наружу торчат их результаты, которыми и триггерятся транзакции.
Ну и дальше стейт для шестерёнок считает зубчики поиском границ
А другой для колёсиков считает в них дырочки
Как я уже писал, мне в принципе не надо заводить отдельный стейт на инкремент счётчика, вот, к примеру есля я хочу проверять упаковки шоколадок, чтобы быть уверенным, что автомат кладёт туда 12 штук:
то мне достаточно вот такой машины состояний:
Ну и в реальности оно, конечно сильно быстрее бежит, чем я поазал в режиме отладки с подсветкой выполнения:
Тот код, который выполняется внутри стейтов - суть как плагины организован, есть библиотека из готовых кирпичиков как для процесинга изображений, так и для общения с внешними устройствами (Modbus, OPC, OPC UA, TCP, платы ввода вывода и т.д.), но можно и самому написать, конечно.
Где-то так.
Это же просто цитата из книги. Там идёт отсылка на две работы, оригинальная 1972 года Hafele J.C., Keating R.E. Science, 177, 1972, p.166. и следом Spencer D.E., Shama U. A new interpretation of the Hafele-Keating experiment. //Проблемы исследования Вселенной, вып. 21. СПб, 1999, с.250. Но надо читать и разбираться, это да, согласен.
Сергей Альбертович Салль в книге "Истоки и заблуждения релятивизма" утверждает что
"Самая известная проверка замедления хода времени в макроскопических условиях была осуществлена Дж.Хафелем и Р.Китингом. В этом опыте четыре экземпляра цезиевых часов помещались на реактивных самолетах, облетевших вокруг Земли в восточном и западном направлениях. Сравнивались показания часов, бывших на самолетах, и эталонных часов, установленных в Морской обсерватории в Вашингтоне. В современных учебниках утверждается, что эффект замедления хода времени был подтвержден. Однако несколько лет назад Китинг инициировал новую процедуру пересчета результатов этого эксперимента, и оказалось, что предсказанный СТО эффект замедления хода часов отсутствует, а прежний вывод был связан с неправомерной линеаризацией экспериментальных данных. Иными словами, результаты эксперимента были подогнаны под выводы СТО." Это 2006 года книжка.
Я это не к тому, что эффекта нет, просто замедление при таком эксперименте ничтожно. Но на МКС время замедленно, это да, и если верить интернетам, то вроде за полгода убегает семь тысячных секунды, что вполне измеримо.
Теоретически можно и на LabVIEW гильотину измыслить, там в общем есть визуальные инструменты для создания автоматов. Хотя я вообще больше по части пром обработки изображений, ну вот к примеру, сортировка и проверка лего деталек:
Или проверка пинов:
Там довольно примитивно всё - есть состояния и есть транзакции-переходы между состояниями, которые срабатывают при наступлении определённых условий. Я притормозил немножко исполнение, чтоб нагляднее было.
Дело вкуса, но мне тоже кнопки удобнее. У меня есть Kindle Oasis с кнопками и Onyx Boox Nova 3 Color c Kaleido Plus а также reMarkable, оба без кнопок, так вот свайп на обоих читалках иногда спонтанно не срабатывает и это при вдумчивом чтении достаёт неимоверно. То ли у меня пальцы слишком сухие, если послюнявить, то заметно лучше получается. Так что читаю в основном на оазисе и каждый раз пользуясь другими, думаю "ну что вам стоило вкорячить сюда пару копеечных кнопок для перелистывания"?
А вы точно ничего не путаете? Туда ставятся патроны LC422, они вообще говоря чипованные и вроде для перезаправки не предназначенные, чтобы "Отвинтили крышечку, долили чернила, закрутили" надо купить соответствующие пустые патроны с чипами. Чипы к ним отдельно тоже продаются (и всё это неоригинал, естественно). А неоригинальные наполненные LC422XL тоже в районе 25 евро за комплект, так что так на так и выходит.
А, понял. Ну тут отчасти личные предпочтения — я пользуюсь hp уже больше 25 лет и в техническом плане меня пока эта техника не подводила. Раньше я вообще заряжал картриджи шприцем из бутылки, потом достало, сейчас toner kingdom покупаю, я б не сказал что барахло, ни внешне ни по качеству печати они от оригинала не отличаются. Не, я честно попытался переползти на другую марку, и купил то ли Эпсон то ли Кэнон, но он довольно быстро отказал, да и конструктивно мне не очень понравился. Из струйников А3 вероятно brother mfc-j6540dw можно было рассмотреть, но и там оригинал патроны комплект 60 евро, а XL комплект под сотню, и вот мы снова смотрим в сторону неоригинальных.
Ну в то время, когда я его покупал, это было единственное приемлемое по цене предложение за дуплекс принтер формата А3. А цветной лазерник такого формата стоил каких-то невменяемых денег. В принципе я им доволен, он неприхотливый, достаточно компактный и на хорошей бумаге очень прилично (для офисного принтера) печатает.
Это из разряда "как отъять максимально возможное количество денег у покупателя, притом так, чтобы он был свято уверен, что ему это выгодно".
Вот смотрите, у меня дома МФУ HP Office Jet 7720, куплен осенью 2019, ему почти пять лет (53 месяца, если быть точным). Отдал я за него 180 евро по какой-то акции-распродаже. Картриджи 953XL оригинальные нынче на амазоне стоят 180(!) евро. Я беру неоригинал за тридцать (он их вполне принимает после даунгрейда). Сейчас установлен пятый комплект картриджей, суммарно расходы 180+30*5 = 330 евро за пять лет. Отечатано на нём по счётчику 3718 листов, это в среднем 70 страниц в месяц. Мне предлагают план за 17 долларов, и это будет 17*53 = 901 доллар, почти втрое дороже. Кроме того, нагрузка у него очень неравномерная, он может пару-тройку месяцев вообще почти не использоваться, а может неделю интенсивно (в основном он нужен детям-гимназистам и супруге - она учитель рисования). Доставка картриджа на следующий рабочий день — вообще смешно, если надо что-то срочно напечатать, а у меня всегда лежит запасной.
Бывает, некоторым платят именно за количество строк кода. ;) В данном случае можно теоретически даже как-то так уплотнить:
void Walls(){
SetColor(Blue , Black);
for(int m = 6; m < 14; m++){SetXY(15,m);cout<<"*"; SetXY(30,m); cout<<"*";}
for(int m = 15; m < 31;m++){SetXY(m,5); cout<<"*"; SetXY(m,14); cout<<"*";}
}
Но обычно в любой более-менее приличной компании у команды есть сложившиеся гайдлайны на форматирование, надо просто им следовать.
Только я хотел написать, что бабочка - это насекомое, а не животное, а оказалось — таки да, animals.
Кстати, для того чтобы снабдить консольное приложение интерфейсом, можно Nuklear воспользоваться. Это очень лекговесная и простая штука, но там можно много чего сделать.
Монорепозиторий - это в том числе про управление зависимостями. Насколько он применим - зависит в общем от структуры проектов. Я использовал такой подход ещё с конца девяностых, где-то до 2007 года. Тогда мы хранили код, используя Microsoft Visual SourceSafe, была такая штука (ни TFS ни Git в то время не было, они где-то в 2005 появились). Так вот в SourceSafe была такая фишка, которая называлась "Линки". У меня проекты были основаны на плагин-архитектуре. В монорепозитории эти плагины хранились все скопом, а вот для каждого отдельного проекта заводилась виртуальная папка, куда необходимые модули линковались из монорепозитория. Если там были файлы, специфические для конкретного проекта, то в монорепозиторий они не попадали. Это было очень удобно. Я мог посмотреть как историю по отдельным проектам, так и по монорепозиторию целиком. Когда я забирал из репозитория код проекта, то на диске у меня появлялиь лишь файлы, исполользованные в проекте и ничего лишнего. Важно было то, что отдельные модули были вообще никак не связаны, технически все вызовы отправлялись в микроядро, а межмодульные вызовы были строго запрещены. Общались модули между собой, устанавливая соединение в рантайме через именованные очереди. Модулей было около трёхсот, а проектов -где-то полтора десятка, какой-то проект мого использовать 50-70 модулей, а какой-то - 20-30, из из модулей проекты собирались как из кубиков Лего. Ну и когда добавлялся новый функционал, то это само собой автоматом распространялось на все проекты, в которых этот модуль использовался. Всё бы ничего, но MS VSS проект был закрыт, на смену пришёл TFS. И компания решила напрочь выпилить линки, потому что мало кто их использовал и вообще это "плохая практика". Это действительно может быть плохой практикой, устроив ад из зависимостей, но при слабой связанности - было самое то. Короче, была куча дискуссий, и в ответ производитель TFS лишь писал - ну нет проблем, сделайте линки на вашем диске, на клиентской стороне. Так можно, конечно, но это абсолютно неудобно. Мы перебросили код в TFS и как-то выкрутились, но линки жаль, у меня теперь весь монорепозиторий валяется на диске и при работе с конкретными проектами я постоянно натыкаюсь на "ненужные" мне в данный момент артефакты. Конкретно сейчас мы переезжаем с TFS в Git, надо будет разобраться, как там.