Как-то так, да. Вроде и изобретение хорошее, но то часы на радиостанции неправильно выставлены (и сбивают часы на магнитоле — дело давнее, но было неприятно), то ещё что.
«Организовать с ключами» — понятное дело, если там сколько-нибудь заметное количество элементов — мало-мальски опытный программист туда воткнёт map. Но это совсем не бесплатно (казалось бы, Rust нужен, чтобы бесплатно или задёшево давать гарантии «ссылочной целостности» и т.п.)
Насчёт «во вторых» — ну да, вроде Rc, который упомянут в статье — вроде более-менее классический weak pointer получается (один из традиционных путей решения аналогичной задачи на C++). Но почему синтаксис такой страшный? Даже страшнее, чем в C++. Нельзя ли это переписать по человечески? (нутром чую, что можно)
Опять же, автор называет это решение «сложночитаемым» (я его понимаю) и рекомендует второе, дорогое — как «более правильное».
Возник интересный вопрос.
Думаю, многие здесь знают, что как только багтрекер начинают использовать для оценки работы программистов — он превращается в тыкву.
Так вот, вопрос: а такая сторонняя оценка тоже может стать проблемой или нет?
Можно подробнее про последний пример и "нормализацию"?
Что я вижу — она создаёт проблему по быстродействию. Как только вам понадобится список занятий для ученика — придётся перебирать общий список enrollments. В БД для того, чтобы делать это быстро — есть ключи и другие ухищрения, да и требования по быстродействию обычно не столь суровы, как к структурам данных в памяти, но всё равно порой разработчики сознательно идут на денормализацию базы.
Поставить задачу (на каких классах изображений вы работаете и какие результаты вам нужны). Разные алгоритмы сегментации применимы в разных задачах.
Оценить, какие алгоритмы препроцессинга могут подойти для вашей задачи и пробовать сегментацию после них. Предобработка может кардинально поменять ситуацию.
Если раскажете про свои задачи — постараюсь что-нибудь посоветовать. Я, правда, давно сменил работу, но 10 лет в области анализа изображений так просто из памяти не выкинешь, да и занятие увлекательное.
Там не «переписать» — там порядок построения стен другой и обрабатываемые объекты другие (не рассматриваются области, которые надо делить). Ну и алгоритм проще.
Так что это — как сказать, что поиск в ширину является по сути тем же, что поиск в глубину :-)
Не совсем: стена всегда строится от края до края лабиринта (что исключает рекурсию, там просто два цикла for).
Но действительно создаёт лишь подмножество множества лабиринтов, создаваемых методом рекурсивного деления.
Кстати, не могу не вспомнить другой, ещё более простой алгоритм генерации лабиринтов:
Окружаем лабиринт стеной, внутри пока пусто.
Случайно выбираем "кирпич" с чётной координатой на одной из сторон.
Начинаем строить от него стену — причём сразу после кирпича пропускаем одну позицию (оставляем проход)
Повторяем 1-2 в случайном порядке для остальных "чётных" кирпичей на всех 4 стенах.
(Получается, что в первой стене будет проход у края, в перпендикулярной ей — у края и у первой стены и так далее)
Не помню, в какой книжке я его вычитал в детстве, но работал на бейсике на тогдашних машинках (8-битный проц 8080, 2 мегагерца тактовая, от 4 тактов на инструкцию — т.е. эдак на 4 порядка медленней нынешних) довольно шустро.
Хотя алгоритм несколько примитивный.
Так имело смысл изучать реальный сигнал, чтобы построить более точную модель. Именно изучать, а не сразу пытаться на нём что-то сравнивать.
Причём вам нужна и модель шума (а для обучения нейронной сети — образцы… много образцов), т.е. шум тоже надо брать реальный. А то завтра у вас переобученная НС будет детектировать, к примеру, импульсные помехи как сигнал.
Для простоты можно задаться всего несколькими параметрами для сигнала:
Частота, возможное отклонение частоты (между экспериментами — например, уход частоты генератора из-за изменения температуры), возможное кратковременное отклонение (в течение импульса, который надо детектировать — например, джиттер)
То же для амплитуды.
Если пользоваться СФ — эти данные сразу изменят его параметры (придётся урезать "время наблюдения сигнала"). Причём после изменения фильтра окажется, что вместо треугольной огибающей он выдаёт на импульсе меандра трапециевидную — которую можно подать на другой фильтр (или просто померить по ней длину импульса, чтобы узнать, что это наш меандр, а не просто маленький кусочек из помех)
Не хотелось бы обижать, но статья вызывает некоторое недоумение:
(мелочь, но странная) Шум подмешивается программно, а генератор меандра зачем-то аппаратный. Не проще было всё сделать в цифре?
Задача выбрана такая, для которой известно, как её решать оптимально (по точности). Странно проводить на ней такое сравнение — лучше бы взять другую задачу (а лучше — пачку задач) без очевидного решения.
Опять же, раз известно, как решать (есть модели сигнала и шума, есть методы сравнения) — нейронные сети гарантированно проиграют специализированному алгоритму (как по точности, так и по быстродействию). Они интересны, когда нет готового метода решения.
"Всплывающие окна в два раза повышают количество подписавшихся через сайт" — плакал горючими слезами (спасибо за ссылку, кстати)
Интересно, так ли оно на самом деле (в смысле, не только у того автора), а если да — то каков процент тех, кто не будет читать приходящие от вас письма и процент тех, кто их пометит как спам (что может привести к тому, что и до других пользователей письма перестанут доходить)
Кстати, интересный компромисс — появление и исчезновение попапа при прокрутке (чтобы пользователю не приходилось искать кнопку закрытия).
2170 или 21700?
В любом случае жаль, что не самый распространённый 18650 — я надеялся, что они наладят производство и у нас будет много дешёвых и качественных 18650.
Насчёт "Для того, чтобы обрезать все, что лежит за границами звукового диапазона (20 кГц) и получить затухание под 40 дБ на 44 кГц" — могли бы просто поправить товарища — мол, резать-то надо не до частоты оцифровки, а до половины частоты, а разница 20-22 — совсем не то же самое, порядок фильтра запредельный получается.
Я правильно понял, что в основе — что-то вроде js-ctypes? Или получилось удобнее? (использование js-ctypes всё-таки включает в себя кучу возни и великолепные возможности для выстрела себе в ногу)
Это не начало 2000-х, у меня (пошёл в школу в 1982) тоже была шестидневка.
А лишний выходной в неделю и правда куда приятнее короткого дня: всё равно на продлёнке сидеть, родители же на работе...
Ну да, результат промежуточных вычислений будет иметь больше 16 бит. Но непонятно, почему это требует повышения разрядности ЦАП:
При тупом отбрасывании младших бит мы всё равно получаем выигрыш (кто делал subpixeling при рисовании во времена CGA-VGA — поймёт: наклонную линию можно сместить на долю пиксела даже без anti-aliasing).
Отброшенные биты необязательно терять — их можно подмешать к сигналу последующих отсчётов. Вроде в те годы алгоритм Флойда-Стейнберга был уже широко распространён в компьютерной графике, и поступить так же — естественно.
Т.е. вроде бы нет причин повышать разрядность АЦП, а можно и вообще понизить (как я понимаю, в итоге к этому и пришли, но это уже совсем другая история).
Как-то так, да. Вроде и изобретение хорошее, но то часы на радиостанции неправильно выставлены (и сбивают часы на магнитоле — дело давнее, но было неприятно), то ещё что.
Насчёт «во вторых» — ну да, вроде Rc, который упомянут в статье — вроде более-менее классический weak pointer получается (один из традиционных путей решения аналогичной задачи на C++). Но почему синтаксис такой страшный? Даже страшнее, чем в C++. Нельзя ли это переписать по человечески? (нутром чую, что можно)
Опять же, автор называет это решение «сложночитаемым» (я его понимаю) и рекомендует второе, дорогое — как «более правильное».
Возник интересный вопрос.
Думаю, многие здесь знают, что как только багтрекер начинают использовать для оценки работы программистов — он превращается в тыкву.
Так вот, вопрос: а такая сторонняя оценка тоже может стать проблемой или нет?
Можно подробнее про последний пример и "нормализацию"?
Что я вижу — она создаёт проблему по быстродействию. Как только вам понадобится список занятий для ученика — придётся перебирать общий список enrollments. В БД для того, чтобы делать это быстро — есть ключи и другие ухищрения, да и требования по быстродействию обычно не столь суровы, как к структурам данных в памяти, но всё равно порой разработчики сознательно идут на денормализацию базы.
Советую начать с начала:
Если раскажете про свои задачи — постараюсь что-нибудь посоветовать. Я, правда, давно сменил работу, но 10 лет в области анализа изображений так просто из памяти не выкинешь, да и занятие увлекательное.
Так что это — как сказать, что поиск в ширину является по сути тем же, что поиск в глубину :-)
Не совсем: стена всегда строится от края до края лабиринта (что исключает рекурсию, там просто два цикла for).
Но действительно создаёт лишь подмножество множества лабиринтов, создаваемых методом рекурсивного деления.
Кстати, не могу не вспомнить другой, ещё более простой алгоритм генерации лабиринтов:
(Получается, что в первой стене будет проход у края, в перпендикулярной ей — у края и у первой стены и так далее)
Не помню, в какой книжке я его вычитал в детстве, но работал на бейсике на тогдашних машинках (8-битный проц 8080, 2 мегагерца тактовая, от 4 тактов на инструкцию — т.е. эдак на 4 порядка медленней нынешних) довольно шустро.
Хотя алгоритм несколько примитивный.
Так имело смысл изучать реальный сигнал, чтобы построить более точную модель. Именно изучать, а не сразу пытаться на нём что-то сравнивать.
Причём вам нужна и модель шума (а для обучения нейронной сети — образцы… много образцов), т.е. шум тоже надо брать реальный. А то завтра у вас переобученная НС будет детектировать, к примеру, импульсные помехи как сигнал.
Для простоты можно задаться всего несколькими параметрами для сигнала:
Частота, возможное отклонение частоты (между экспериментами — например, уход частоты генератора из-за изменения температуры), возможное кратковременное отклонение (в течение импульса, который надо детектировать — например, джиттер)
То же для амплитуды.
Если пользоваться СФ — эти данные сразу изменят его параметры (придётся урезать "время наблюдения сигнала"). Причём после изменения фильтра окажется, что вместо треугольной огибающей он выдаёт на импульсе меандра трапециевидную — которую можно подать на другой фильтр (или просто померить по ней длину импульса, чтобы узнать, что это наш меандр, а не просто маленький кусочек из помех)
Насчёт двойных if — почитайте про операцию &&, будете приятно удивлены (она не вычисляет второй аргумент, если достаточно первого)
Не хотелось бы обижать, но статья вызывает некоторое недоумение:
Вам бы в "ассоциации" играть. Из "50 микрорентген в час" и "spb" в нике гранитная набережная сразу угадывалась :-)
"Всплывающие окна в два раза повышают количество подписавшихся через сайт" — плакал горючими слезами (спасибо за ссылку, кстати)
Интересно, так ли оно на самом деле (в смысле, не только у того автора), а если да — то каков процент тех, кто не будет читать приходящие от вас письма и процент тех, кто их пометит как спам (что может привести к тому, что и до других пользователей письма перестанут доходить)
Кстати, интересный компромисс — появление и исчезновение попапа при прокрутке (чтобы пользователю не приходилось искать кнопку закрытия).
2170 или 21700?
В любом случае жаль, что не самый распространённый 18650 — я надеялся, что они наладят производство и у нас будет много дешёвых и качественных 18650.
Ограниченная скорость нарастания выходного напряжения? (Я не настоящий сварщик, так что вопросы, наверное, детские)
А "плохой расклад" в данном случае — наличие хотя бы небольшой нелинейности в тракте?
Насчёт "Для того, чтобы обрезать все, что лежит за границами звукового диапазона (20 кГц) и получить затухание под 40 дБ на 44 кГц" — могли бы просто поправить товарища — мол, резать-то надо не до частоты оцифровки, а до половины частоты, а разница 20-22 — совсем не то же самое, порядок фильтра запредельный получается.
Я правильно понял, что в основе — что-то вроде js-ctypes? Или получилось удобнее? (использование js-ctypes всё-таки включает в себя кучу возни и великолепные возможности для выстрела себе в ногу)
Это не начало 2000-х, у меня (пошёл в школу в 1982) тоже была шестидневка.
А лишний выходной в неделю и правда куда приятнее короткого дня: всё равно на продлёнке сидеть, родители же на работе...
Ну да, результат промежуточных вычислений будет иметь больше 16 бит. Но непонятно, почему это требует повышения разрядности ЦАП:
Т.е. вроде бы нет причин повышать разрядность АЦП, а можно и вообще понизить (как я понимаю, в итоге к этому и пришли, но это уже совсем другая история).