При всей кажущейся привлекательности использование ENUM в конечном итоге оказывается скорее вредным, чем полезным. Требуется контроль изменений в базе и в коде, дополнительные проверки в базе, сложности при расширении ENUM и т.д. Проще использовать int или char(4) например, если нужно большей человекочитаемости. Источник изменений будет только один - код, ведь по сути элементы ENUM - константы и базе все равно, что там. Вся история с миграциями тоже уходит. Ну и в некоторых случаях очень удобно использовать uint + битовые маски для хранения флагов вместо ENUM.
с некоторым вдохновением от Pascal, Modula и Oberon для деклараций и пакетов.
Вся идея структур с привязкой методов с помощью приемников/ресиверов (receiver) в их объявлениях кажется цельнотянутой с Оберона(2). Ну один в один. Не только оператор присваивания ":="
дрейф нуля получите в любом случае, для того фильтры и придуманы, чтоб убирать.
высокоточное измерение ЭКГ никому не нужно, только исследовательский интерес на уровне хобби. Как бы профессионально ни была сделана аппаратура. Без хорошей системы анализа и без сертификации - не взлетают такие проекты. Я вот об этом написал.
Анализ ЭКГ, автоматическая интерпретация - не готовится в одиночку. Не реализуется на открытых базах сигналов. На них уже только ленивый не потоптался, статей просто море. Придется делать свою базу, собранную на своем устройстве на большой выборке больных. Но с несертифицированным устройством никто к больным не допустит.
Вы подходите к вопросу регистрации ЭКГ чисто технически -давайте повысим глубину/разрядность и частоту. Можно приспособить и звуковые ADC, получить 48бит/96кГц и выше - но зачем? Мне известна только одна особенность, которую может иметь смысл рассматривать на высокочастотной ЭКГ - расщепленный R-пик. Все остальное видно и на гораздо более простых сигналах, в большинстве случаев достаточно 12бит/500 Гц. По нынешним временам, чтоб совсем уж не позориться - можно взять 14бит/1000Гц. 2 бита на шум. Сигнал ЭКГ изменяется относительно медленно - 1000 Гц более чем достаточно. Кроме собственно регистрации сигнала требуется фильтрация помехи 50/60Гц, фильтрация помех от мышц, требуется его анализ - выделение пиков и интервалов. Но самое тяжелое - это автоматизированная интерпретация. Это займет даже не годы - десятилетия работы. Я знаю, что в РФ только 2-3 команды, которые могут это делать хорошо. Саровские разработчики, например. Суть в том, что добиться распознавания в 95% (кардиоимпульсов) относительно несложно, а вот 99% и выше - это нереально круто. Анализ вариабельности сердечного ритма - это вообще отдельный мир и определение R-пика с точностью 1 мс более чем достаточно. Не нужны там сигналы более 14бит/1000Гц вообще, нет смысла. Методики анализа такие, что толку от высокой точности не получите.
Вот и получается что супер высокоточная регистрация ЭКГ особо не нужна никому, только энтузиастам для хобби и исследователям (которым вообще-то тоже нужно сертифицированное оборудование)
Если Вы имеете в виду носимые системы для мониторнига вариабельности по одному отведению ЭКГ, то их уже хватает на рынке. Ссылки приводить не буду, их легко найти. Вот только три, с которыми я знаком вживую. С двумя из них - с разработчиками.. Прототип Ритмера даже Путину показывали, видео можно нагуглить. Монитор сердечной активности RITMER Кардиофлешка ECG Dongle Система скрининга сердца Кардиовизор
И еще огромная куча браслетов с той же функцией. Примеры российских, которые не хотят казаться российскими Corsano actenzo
К сожалению, само по себе железо не имеет большого значения, лишь бы работало. Таких устройств и у китайцев полно. Вся сложность в регистрации в Росздравнадзоре. Это сильно дороже любой разработки. Поэтому цена высока - не каждая компания преодолеет этот барьер. Врач/медучреждение же не будет работать с несертифицированным устройством, это запрещено.
Проект интересный. По мере чтения возник вопрос и не отпускал: а вы рассматривали вариант ESP32 вместо arduino + esp8266?
все коммуникации есть (usb, bluetooth+BLE, WiFi), подключить все те же датчики можно, прошивать по воздуху тоже можно. Модуль двухпроцессорный, ресурсов хватает.
Почему не упоминаете?
Прежде всего, синтаксис грамматических конструкций основывается на синтаксисе языка Си. Однако, существенное влияние оказал и язык DELPHI. Так, мы видим, что полностью убраны избыточные скобки, так сильно снижающие читаемость программы. Также язык содержит оператор ":=", присущий языку DELPHI.
На мой взгляд, значительно повлиял Oberon, хотя об этом говорят сильно меньше.
Структуры и методы, привязанные через ресиверы — это из Оберона.
Вообще, вся группа языков Н.Вирта оказала сильное влияние на Go. Впрочем, так же как и на Java, и на C#. Правда, джависты не признаются, за что Н.Вирт на них обижался. Он об этом говорил на своей лекции в Политехническом музее, когда приезжал в Москву.
Третью половину привлекает. С огромным интересом читал статью, так как в работе требуется именно расчет СПМ. Метод Уэлча написать осилил, а вот ARMA для меня совсем новое.
В идеале бы больше подробностей именно по алгоритмам вычисления. Ну и вообще супер — обзор существующих библиотек для обработки.
Имею опыт работы как с Go, так и с PHP (Laravel). Насколько красиво и удобно смотрится DI в Laravel, например, настолько неудобно и чужеродно подобный DI смотрится в Go. Понятно, что разная типизация и вот это все… Но хорошего DI для Go я так пока и не увидел.
И согласен, лучше, если код более явный, если хорошей «магии» из-за особенностей языка не применить.
недавно видел ролик про украинцев, которые собирают клубнику в Польше. 12 часовой рабочий день, без выходных. норма от 100 кг в день. Оплата — примерно 600 евро в месяц.
Собирать клубнику по 12 часов, не меньше 100 кг в день (в день, Карл!) в течение месяца (месяца!) — мне кажется, это подходит под определение «тяжелая работа»
Я бы лучше документацию по 8 часов писал.
В начале объектно-ориентированного программирования мы стартовали с идеи, реализованной в Pascal, согласно которой у нас есть запись, а затем мы связываем с этой записью функции, которые являются методами, действующими на элементы записи.
Похоже, это про Оберон, а не про Паскаль. Не помню, чтобы в классическом Паскале вообще ООП было, а вот в Обероне Вирт именно так сделал.
И кстати, в Go эта идея из Оберона перетекла, Пайк где-то упоминал.
Такая мода последние 2-3 года в IT кругах. Плохая калька с английского + наплевательское отношение к русскому языку. Часто встречаю в статьях, чуть реже в презентациях и в выступлениях.
Наверное, думают, что это как-то подчеркивает их «профессионализм». Лучше бы выучили как -тся/-ться пишется и когда ставится мягкий знак после ч|ш.
а методики ИМБП применяли? по Баевскому, по Флейшману?
не увидел в тексте, что странно.
С выходом slog имеет смысл писать о нем, либо о переходе на него.
Интересно, как?
Перед/совместно с чтением понимаю, но как проверить перед записью, не читая?
При всей кажущейся привлекательности использование ENUM в конечном итоге оказывается скорее вредным, чем полезным. Требуется контроль изменений в базе и в коде, дополнительные проверки в базе, сложности при расширении ENUM и т.д.
Проще использовать int или char(4) например, если нужно большей человекочитаемости.
Источник изменений будет только один - код, ведь по сути элементы ENUM - константы и базе все равно, что там. Вся история с миграциями тоже уходит.
Ну и в некоторых случаях очень удобно использовать uint + битовые маски для хранения флагов вместо ENUM.
Вся идея структур с привязкой методов с помощью приемников/ресиверов (receiver) в их объявлениях кажется цельнотянутой с Оберона(2). Ну один в один.
Не только оператор присваивания ":="
про звуковую карту я ни слова не писал ))
дрейф нуля получите в любом случае, для того фильтры и придуманы, чтоб убирать.
высокоточное измерение ЭКГ никому не нужно, только исследовательский интерес на уровне хобби. Как бы профессионально ни была сделана аппаратура. Без хорошей системы анализа и без сертификации - не взлетают такие проекты. Я вот об этом написал.
Анализ ЭКГ, автоматическая интерпретация - не готовится в одиночку. Не реализуется на открытых базах сигналов. На них уже только ленивый не потоптался, статей просто море. Придется делать свою базу, собранную на своем устройстве на большой выборке больных. Но с несертифицированным устройством никто к больным не допустит.
спорить смысла нет, согласен.
покупал, правда давно, за 3000р, валяется где-то
Кардиофлешка ECG Dongle цена неизвесна:
цена около 1600р
Вы подходите к вопросу регистрации ЭКГ чисто технически -давайте повысим глубину/разрядность и частоту. Можно приспособить и звуковые ADC, получить 48бит/96кГц и выше - но зачем? Мне известна только одна особенность, которую может иметь смысл рассматривать на высокочастотной ЭКГ - расщепленный R-пик. Все остальное видно и на гораздо более простых сигналах, в большинстве случаев достаточно 12бит/500 Гц. По нынешним временам, чтоб совсем уж не позориться - можно взять 14бит/1000Гц. 2 бита на шум. Сигнал ЭКГ изменяется относительно медленно - 1000 Гц более чем достаточно.
Кроме собственно регистрации сигнала требуется фильтрация помехи 50/60Гц, фильтрация помех от мышц, требуется его анализ - выделение пиков и интервалов.
Но самое тяжелое - это автоматизированная интерпретация. Это займет даже не годы - десятилетия работы. Я знаю, что в РФ только 2-3 команды, которые могут это делать хорошо. Саровские разработчики, например.
Суть в том, что добиться распознавания в 95% (кардиоимпульсов) относительно несложно, а вот 99% и выше - это нереально круто.
Анализ вариабельности сердечного ритма - это вообще отдельный мир и определение R-пика с точностью 1 мс более чем достаточно. Не нужны там сигналы более 14бит/1000Гц вообще, нет смысла. Методики анализа такие, что толку от высокой точности не получите.
Вот и получается что супер высокоточная регистрация ЭКГ особо не нужна никому, только энтузиастам для хобби и исследователям (которым вообще-то тоже нужно сертифицированное оборудование)
Если Вы имеете в виду носимые системы для мониторнига вариабельности по одному отведению ЭКГ, то их уже хватает на рынке. Ссылки приводить не буду, их легко найти. Вот только три, с которыми я знаком вживую. С двумя из них - с разработчиками.. Прототип Ритмера даже Путину показывали, видео можно нагуглить.
Монитор сердечной активности RITMER
Кардиофлешка ECG Dongle
Система скрининга сердца Кардиовизор
И еще огромная куча браслетов с той же функцией. Примеры российских, которые не хотят казаться российскими
Corsano
actenzo
К сожалению, само по себе железо не имеет большого значения, лишь бы работало. Таких устройств и у китайцев полно. Вся сложность в регистрации в Росздравнадзоре. Это сильно дороже любой разработки. Поэтому цена высока - не каждая компания преодолеет этот барьер. Врач/медучреждение же не будет работать с несертифицированным устройством, это запрещено.
все коммуникации есть (usb, bluetooth+BLE, WiFi), подключить все те же датчики можно, прошивать по воздуху тоже можно. Модуль двухпроцессорный, ресурсов хватает.
Почему не упоминаете?
На мой взгляд, значительно повлиял Oberon, хотя об этом говорят сильно меньше.
Структуры и методы, привязанные через ресиверы — это из Оберона.
Вообще, вся группа языков Н.Вирта оказала сильное влияние на Go. Впрочем, так же как и на Java, и на C#. Правда, джависты не признаются, за что Н.Вирт на них обижался. Он об этом говорил на своей лекции в Политехническом музее, когда приезжал в Москву.
В идеале бы больше подробностей именно по алгоритмам вычисления. Ну и вообще супер — обзор существующих библиотек для обработки.
И согласен, лучше, если код более явный, если хорошей «магии» из-за особенностей языка не применить.
Собирать клубнику по 12 часов, не меньше 100 кг в день (в день, Карл!) в течение месяца (месяца!) — мне кажется, это подходит под определение «тяжелая работа»
Я бы лучше документацию по 8 часов писал.
Похоже, это про Оберон, а не про Паскаль. Не помню, чтобы в классическом Паскале вообще ООП было, а вот в Обероне Вирт именно так сделал.
И кстати, в Go эта идея из Оберона перетекла, Пайк где-то упоминал.
Наверное, думают, что это как-то подчеркивает их «профессионализм». Лучше бы выучили как -тся/-ться пишется и когда ставится мягкий знак после ч|ш.