Мне интуитивно всегда казалось, что ДНК - это достаточно защищенное хранилище, своего рода надежный бекап исходников организма, и повреждать ее могут только штуки, вроде радиации.
Несколько раз в статье упоминается, что вирус встраивается в геном человека. На этом месте я немного подзавис. Не могли бы Вы раскрыть тему? Для человека далекого от микробиологии, это звучит почти эквивалентно с "встраивается в ДНК", что кажется совсем не безобидно.
Вы, вероятно, правы. Но объясню свою логику, которая привела меня к такому предположению: Допустим у нас редуктор 1 к 5, т.е. на 5 оборотов мотора, вал после редуктора совершает один. Точность магнитного энкодера заявляется подярка 0.1 градуса (12 бит), но в реальности, после сглаживания, думаю, можно рассчитывать на ~ 1 градус. Таким образом, если мы ставим энкодер до редуктора, то знаем положение детали с точностью до 1/5 градуса + люфт. Я не учитываю тут возможность ошибиться на целый оборот мотора, т.к. не ожидаю в задачах для сервоприводов таких скоростей вращения детали. Если же энкодер стоит после редуктора, то погрешность измерения положения составит целый градус, что кажется значительно менее точным. На самом деле, даже если мы знаем точное положение детали, то это не значит что мы можем им управлять так же точно. Наличие люфта не позволит. Именно поэтому, насколько я это себе представляю, в оптических стабилизаторах для видео/фото камер (двух- или трехосных) используют BLDC непосредственно на осях, без редукции. Но если бы реализовать редукцию без люфта, то кажется, энкодер на валу двигателя был бы значительно точнее. Так что это, кажется, вопрос отношения люфта к точности энкодера: при разных значениях, выгоднее может оказаться тот или иной вариант.
К примеру абсолютный магнитный енкодер AS5600 стоит чуть более 100 рублей. Точность, конечно, пониже, но если ставить до редуктора - то в 0,1 градуса привода можно уложиться. т.е. это уже сопоставимо с дребезжанием самого редуктора.
А нельзя ли использовать вместо потенциометра магнитный энкодер? В идеале даже два - один непосредственно на валу, второй после всех редукторов. Тогда можно вообще добиться прецизионной точности, КМК.
ИХМО, речь пойдет о списке адресов, которые делегируются российскими регистраторами, и владельцы которых предоставили регистратору паспорт РФ, или заключили письменный договор, где указан ИНН/КПП, если юр. лицо.
Вероятно, после выполнения сегментации, используются другие нейросети для опознания конкретного объекта в сегменте. Но качество сегментирования, на приведенной Вами картинке, конечно - мое почтение.
С интересом читал о Segment anything model, тогда стало очень интересно, сложно ли ее прикрутить для каких-то практических задач. Я никогда не занимался нейросетями, но для кругозора почитать всегда интересно. Особенно о применении новейших технологий в DIY проектах, которые можно потянуть в одно лицо. Не пробовали использовать саму эту модель, или их публичные датасеты?
Не знаю, как БЯМ должна оценить, где там вода, а где соль, но как минимум, при тезисном пересказе, было бы круто оставлять якорные ссылки на абзац, начиная с которого этот тезис раскрывается.
Про применение - я хочу, в первую очередь, заменитель кучи домофонных кнопок и ключей и ИК-бластер
Такую штучку я бы купил. Автономный агрегатор ключей домофонов, пропусков СКУД и прочих NFC, кажется востребованной штукой, причем в широком кругу пользователей, не только энтузиастов. Но хотелось бы, конечно, избежать возни с подключением к телефону каждый раз при использовании. Если только при обновлении пула ключей - тогда ок
Очень напомнило цикл "Хмель и Клондайк" от Андрея Круза и Павла Корнева. Там один из двух главных героев, собственно Хмель, был владельцем пивбара в фэнтазийном мире. Очень атмосферным получился этот персонаж. После прочтения, мысль о таком интересном амплуа тоже сидит где-то в подкорке.
Если все awaitable объекты завершены успешно, то результатом является совокупный список возвращенных значений этих объектов.
Если я правильно понял, это как ОжидатьЗавершенияВыполнения(), который используется для ожидания завершения последнего из списка фоновых заданий, только для обещаний. Вероятно, подобный синтаксис появится в скором времени и для Ждать. Но это в любом случае, не про сбор результата распараллеленного запроса из кучки результатов. Тут без костылей, даже не знаю, как обойтись.
Мне кажется Вы путаете асинхронность и многопоточность. Это связанные, но не тождественные понятия.
> без костылей
На самом деле, оптимизаторы внутри СУБД обычно хорошо справляются с такой задачей, и без участия прикладного разработчика. Оптимизатор, исходя из построенного плана, часто разбивает "тяжелый" запрос на кучу параллельно выполняющихся запросов. В MS SQL это настраивается с помощьюmax degree of paralrllism, в PostgreSQL, кажется, тоже была какая-то настройка. Но это уже тонкие материи, в области знаний DBA. Иногда, даже в СУБД возникают с такой параллельностью проблемы (гуглить CXPacket). А Вы хотите чтобы прикладной разработчик смог сам это захардкодить, без доступа к статистикам, сразу и правильно, не став причиной регресса, да еще и в несколько строчек кода? Может быть есть примеры сред разработки (языков), где такая задача решается легко и просто?
1С Фреш [...] Поскольку конфигуратор не предусматривается, то допилить решение для потребностей бизнеса нельзя.
Не то чтобы совсем нельзя. Есть же механизм расширений. Да, нужно пройти аудит, да есть требования и ограничения, но в целом - можно. Еще и зарабатывать потом, продавая это расширение другим пользователям.
Я так понимаю, речь о динамических списках, и невозможность потянуть за ползунок. Это ж известная проблема. Мне известны всего три альтернативы:
Получать выборку сразу и целиком тащить на клиент (мы же не рассматриваем этот вариант всерьез, да?)
сделать функциональный ползунок и получить лютые тормоза на highload, вычисляя размер ползунка и его положение при каждом получении порции данных (ведь для этого нужно оценить количество элементов списка до и после текущей порции, что по сути означает запрос с анализом всей таблицы).
разные ухищрения, когда настоящего ползунка нет, но есть какая-то заглушка. В 1с это безразмерный (всегда одинакового размера) ползунок, который находится посредине, если только мы не в начале или конце выборки.
Вообще, мне не попадалось системы, рассчитанной на "большие данные", где бы был реализован п.2. Всегда используются разные ухищрения, типа кнопки "загрузить еще", или что-то подобное.
Проблема не во вложенных попытках как таковых. Проблема в том что транзакция испорчена. Не каждая ошибка в транзакции приведет к такому эффекту. Например, обращение к несуществующей процедуре в попытке не приведет к "протуханию" транзакции. А вот ошибки, связанные с обращением к данным - приведут, даже если исключение перехвачено. В этом случае, любое следующее действие внутри транзакции приведет к "В данной транзакции уже происходили ошибки". Т.е. сама ошибка возникла ранее, но выстрелила в каком-то рандомном коде, который попытался выполнить действие в контексте протухшей транзакции. Это делает дебаггинг этой ошибки одним из самых неприятных.
Кстати, обратите внимание: мотоцикл подруливает передним колесом во время баланса. Предварительно, меняется угол наклона рулевой оси - таким образом еще сильнее смещается центр пятна контакта переднего колеса от оси поворота. Интересно, есть ли в этом агрегате вообще какой-то балансир/гироскоп, или все делается рулем?
Я бы обратил внимание на то, что точка контакта переднего колеса с поверхностью немного не совпадает с продолжением оси руля. т.е. при зажатом переднем тормозе, поворот руля немного сдвинет вбок всю систему байк-райдер. Возможно, при очень точном гироскопе (датчике) и очень точных движениях поворота руля, это может позволить удерживать баланс. Кроме того, в мото- и велотриале есть понятие статического баланса. Райдер удерживает баланс стоя на двух колесах. Обычно это делается с повернутым колесом. Вероятно, немалая часть этого баланса достигается за счет малозаметных движений тела райдера, но точно известно, что с повернутым колесом баланс держать сильно проще.
Мне интуитивно всегда казалось, что ДНК - это достаточно защищенное хранилище, своего рода надежный бекап исходников организма, и повреждать ее могут только штуки, вроде радиации.
Несколько раз в статье упоминается, что вирус встраивается в геном человека. На этом месте я немного подзавис. Не могли бы Вы раскрыть тему? Для человека далекого от микробиологии, это звучит почти эквивалентно с "встраивается в ДНК", что кажется совсем не безобидно.
Вы, вероятно, правы. Но объясню свою логику, которая привела меня к такому предположению:
Допустим у нас редуктор 1 к 5, т.е. на 5 оборотов мотора, вал после редуктора совершает один.
Точность магнитного энкодера заявляется подярка 0.1 градуса (12 бит), но в реальности, после сглаживания, думаю, можно рассчитывать на ~ 1 градус.
Таким образом, если мы ставим энкодер до редуктора, то знаем положение детали с точностью до 1/5 градуса + люфт. Я не учитываю тут возможность ошибиться на целый оборот мотора, т.к. не ожидаю в задачах для сервоприводов таких скоростей вращения детали.
Если же энкодер стоит после редуктора, то погрешность измерения положения составит целый градус, что кажется значительно менее точным.
На самом деле, даже если мы знаем точное положение детали, то это не значит что мы можем им управлять так же точно. Наличие люфта не позволит.
Именно поэтому, насколько я это себе представляю, в оптических стабилизаторах для видео/фото камер (двух- или трехосных) используют BLDC непосредственно на осях, без редукции.
Но если бы реализовать редукцию без люфта, то кажется, энкодер на валу двигателя был бы значительно точнее. Так что это, кажется, вопрос отношения люфта к точности энкодера: при разных значениях, выгоднее может оказаться тот или иной вариант.
К примеру абсолютный магнитный енкодер AS5600 стоит чуть более 100 рублей. Точность, конечно, пониже, но если ставить до редуктора - то в 0,1 градуса привода можно уложиться. т.е. это уже сопоставимо с дребезжанием самого редуктора.
Справедливости ради, показания магнитного сенсора тоже шумят. Может меньше, но фильтровать тоже придется.
А нельзя ли использовать вместо потенциометра магнитный энкодер? В идеале даже два - один непосредственно на валу, второй после всех редукторов. Тогда можно вообще добиться прецизионной точности, КМК.
ИХМО, речь пойдет о списке адресов, которые делегируются российскими регистраторами, и владельцы которых предоставили регистратору паспорт РФ, или заключили письменный договор, где указан ИНН/КПП, если юр. лицо.
Вероятно, после выполнения сегментации, используются другие нейросети для опознания конкретного объекта в сегменте. Но качество сегментирования, на приведенной Вами картинке, конечно - мое почтение.
С интересом читал о Segment anything model, тогда стало очень интересно, сложно ли ее прикрутить для каких-то практических задач. Я никогда не занимался нейросетями, но для кругозора почитать всегда интересно. Особенно о применении новейших технологий в DIY проектах, которые можно потянуть в одно лицо. Не пробовали использовать саму эту модель, или их публичные датасеты?
Не знаю, как БЯМ должна оценить, где там вода, а где соль, но как минимум, при тезисном пересказе, было бы круто оставлять якорные ссылки на абзац, начиная с которого этот тезис раскрывается.
Такую штучку я бы купил.
Автономный агрегатор ключей домофонов, пропусков СКУД и прочих NFC, кажется востребованной штукой, причем в широком кругу пользователей, не только энтузиастов. Но хотелось бы, конечно, избежать возни с подключением к телефону каждый раз при использовании. Если только при обновлении пула ключей - тогда ок
Очень напомнило цикл "Хмель и Клондайк" от Андрея Круза и Павла Корнева. Там один из двух главных героев, собственно Хмель, был владельцем пивбара в фэнтазийном мире. Очень атмосферным получился этот персонаж. После прочтения, мысль о таком интересном амплуа тоже сидит где-то в подкорке.
Если все awaitable объекты завершены успешно, то результатом является совокупный список возвращенных значений этих объектов.Если я правильно понял, это как
ОжидатьЗавершенияВыполнения(),который используется для ожидания завершения последнего из списка фоновых заданий, только для обещаний. Вероятно, подобный синтаксис появится в скором времени и дляЖдать. Но это в любом случае, не про сбор результата распараллеленного запроса из кучки результатов. Тут без костылей, даже не знаю, как обойтись.Мне кажется Вы путаете асинхронность и многопоточность. Это связанные, но не тождественные понятия.
> без костылей
На самом деле, оптимизаторы внутри СУБД обычно хорошо справляются с такой задачей, и без участия прикладного разработчика. Оптимизатор, исходя из построенного плана, часто разбивает "тяжелый" запрос на кучу параллельно выполняющихся запросов. В MS SQL это настраивается с помощью
max degree of paralrllism, в PostgreSQL, кажется, тоже была какая-то настройка. Но это уже тонкие материи, в области знаний DBA. Иногда, даже в СУБД возникают с такой параллельностью проблемы (гуглить CXPacket). А Вы хотите чтобы прикладной разработчик смог сам это захардкодить, без доступа к статистикам, сразу и правильно, не став причиной регресса, да еще и в несколько строчек кода?Может быть есть примеры сред разработки (языков), где такая задача решается легко и просто?
Не то чтобы совсем нельзя. Есть же механизм расширений. Да, нужно пройти аудит, да есть требования и ограничения, но в целом - можно. Еще и зарабатывать потом, продавая это расширение другим пользователям.
Я так понимаю, речь о динамических списках, и невозможность потянуть за ползунок.
Это ж известная проблема. Мне известны всего три альтернативы:
Получать выборку сразу и целиком тащить на клиент (мы же не рассматриваем этот вариант всерьез, да?)
сделать функциональный ползунок и получить лютые тормоза на highload, вычисляя размер ползунка и его положение при каждом получении порции данных (ведь для этого нужно оценить количество элементов списка до и после текущей порции, что по сути означает запрос с анализом всей таблицы).
разные ухищрения, когда настоящего ползунка нет, но есть какая-то заглушка. В 1с это безразмерный (всегда одинакового размера) ползунок, который находится посредине, если только мы не в начале или конце выборки.
Вообще, мне не попадалось системы, рассчитанной на "большие данные", где бы был реализован п.2. Всегда используются разные ухищрения, типа кнопки "загрузить еще", или что-то подобное.
Проблема не во вложенных попытках как таковых. Проблема в том что транзакция испорчена. Не каждая ошибка в транзакции приведет к такому эффекту. Например, обращение к несуществующей процедуре в попытке не приведет к "протуханию" транзакции. А вот ошибки, связанные с обращением к данным - приведут, даже если исключение перехвачено.
В этом случае, любое следующее действие внутри транзакции приведет к "В данной транзакции уже происходили ошибки". Т.е. сама ошибка возникла ранее, но выстрелила в каком-то рандомном коде, который попытался выполнить действие в контексте протухшей транзакции.
Это делает дебаггинг этой ошибки одним из самых неприятных.
Полезно будет упомянуть, что на ИТС есть стандарт описывающий работу с транзакциями , рекомендую к ознакомлению.
Кстати, обратите внимание: мотоцикл подруливает передним колесом во время баланса. Предварительно, меняется угол наклона рулевой оси - таким образом еще сильнее смещается центр пятна контакта переднего колеса от оси поворота.
Интересно, есть ли в этом агрегате вообще какой-то балансир/гироскоп, или все делается рулем?
Я бы обратил внимание на то, что точка контакта переднего колеса с поверхностью немного не совпадает с продолжением оси руля. т.е. при зажатом переднем тормозе, поворот руля немного сдвинет вбок всю систему байк-райдер. Возможно, при очень точном гироскопе (датчике) и очень точных движениях поворота руля, это может позволить удерживать баланс.
Кроме того, в мото- и велотриале есть понятие статического баланса. Райдер удерживает баланс стоя на двух колесах. Обычно это делается с повернутым колесом. Вероятно, немалая часть этого баланса достигается за счет малозаметных движений тела райдера, но точно известно, что с повернутым колесом баланс держать сильно проще.
Поговаривают, что в аду есть отдельный котел для тех, кто меняет цвета колонок на диаграммах в докладе.