> Если позволить сети самостоятельно расти, то она и дорастет до размера, когда количества весов будет достаточно, чтоб просто «запомнить» все обучающие примеры.
Кстати, абстрагируясь от исходной темы, благодаря которой «мы все тут сегодня собрались», именно превышение количества параметров НС над величиной обучающей выборки (aka сверхпараметризованные решения) оказывает (иногда) очень благотворное влияние на качество модели. См. arXiv:1812.11118 “Reconciling modern machine learning practice and the bias-variance trade-off” Mikhail Belkin et.al
Есть ещё, имхо, весьма недооценённые SELU активации с правильной иницализацией весов, которые существенно облегчают, если не вообще решают вопрос vanishing/exploding gradients. Ну и другие менее публичные методы :)
Ну, вот я разработал не то, что бы много, но вот эту библиотеку, нопремер, из опубликованного. И позвольте вам заметить, что благородные доны в коментах выше правы. Данная статья — ахинея чуть более, чем полностью, увы.
Сравнивая результаты с прошлыми годами единственным вроде как бесспорным достижением видится лишь уменьшение числа больничных (да и то с оговоркой, что если люди «болели» в этот дополнительный день отдыха, составляющий 20% рабочего времени, то 23%-20%=3% снижения достоверности не имеет). Во всех остальных случаях в данных присутствует настолько отчётливый тренд, что надо быть совсем дураком, чтобы поверить в достоверность декларируемых «результатов». Отдельно доставляет выборочность сравнения то с 2016 годом, то с 2018.
Немного напомнило анекдот про парикмахера-инженера, придумавшего устройство для автоматического бритья. Когда его спросили, «ну позвольте, ведь у всех разные головы!» он ответил: «в первый раз — да».
Так вот,
Не будут они делать это платным, смысла нет.
Они — да, не будут.
А вот за наших находчивых я бы не был так уверен. Ещё и удивительным образом стоимость будет у всех примерно одинаковая, как с мегабайтом трафика без доп.планов было/есть.
Не интересно комментировать остальное, кроме вот этого:
Тоже не скажу за всех, но Segmentation Fault на моей памяти самая частая причина почему падает плюсовое приложение.
1. разных возможностей уронить процесс вообще не так уж и много, и неправильная работа с памятью — это самая широкая из них. Поэтому не удивительно, что программы с ошибками падают чаще всего именно на памяти. Ну не ud2 же им падать?
2. любая безопасная работа требует чёткого понимания когда конкретно с чем конкретно работаем. Тогда пиши хоть на асме — не будет никаких проблем. Юниксы и прочие Линуксы, написанные на самых небезопасных С/С++ с годами аптайма тому пример (Винда диапазона NT4.0-2000-7 тоже совсем не так дурна на самом деле, как её любят представлять, и там точно микс С/С++ даже в kernel mode драйверах, но никсы в примере канонiчнее, конечно).
3. Программер может купить гарантии безопасности памяти с помощью языка, но это возможно сделать исключительно продав весьма много дополнительной ран-тайм нагрузки.
Отсюда простой вывод — неча на зеркало пенять, коли рожа крива когда прозводительность любого минимально сложного решения на первом месте, то, в общем случае, альтернативы всё равно нет.
К тому же, безопасность работы с памятью — это устранение, ну… наверное 95% ошибок при программировании на С++?
Вот сильно не уверен. Не скажу за всех, но лично мне очень кажется, что страшилки про «небезопасность работы с памятью в С++» сильно преувеличены. Уже давно придумана масса вполне надёжных техник, которые от этой проблемы избавляют. По крайней мере лично в моём опыте я даже не вспомню, когда в последний раз меня это кусало… Может разве что лет 20 назад, когда только учился, да и то не факт, поскольку переход на С/С++ после ассемблера очень облегчён.
Но вот всякие хитропопые undefined behaviour или х10 ускорение после разборки с data aliasing и т.д. и т.п. — вот это периодически случается и сейчас. Про пример в посте вообще не вспоминаю, — это ж поседеть можно, пока допрёшь что за фигня, если не сталкивался.
Главная беда, С++, имхо абсолютно не работа с памятью (она вполне безопасна и комфортна после некоторого уровня понимания), а адски замороченный стандарт с «кучей условий мелким шрифтом, сносками и звёздочками», что как раз демонстрирует пример этого поста… Но главная беда этой главной беды в том, что она, скорее всего, практически не излечима, просто потому, что заменив сложность на простоту почти всегда неминуемо проиграешь в конечном итоге в эффективности, поскольку вся эта сложность сделана с единственной целью — позволить компилятору выжимать максимум возможной эффективности из кода.
Нет, ни в коем случае. В этом и есть важнейшая мякотка шаблонов, — они с помощью одного кода позволяют создавать принципиально разные алгоритмы, которые при этом полноценно собираются ещё в момент компиляции (что и позволяет генерить очень эффективный код)
O_O
… афигеть… просто нет слов.
Я уже даже перестал нервно смеяться, когда слышу что-нить вроде «С/С++? Да, чо там, простые же языки»…
Не тот язык назвали brainfuck, ох не тот… Хотя всё равно люблю его, но это какой-то капец
Я не интересовался вопросом так глубоко, чтобы мониторить пабмед.
Напомню только, что отсутствие пруфов негатива на нынешнем этапе вовсе не означает, что серьёзного негатива вообще не существует. Достаточно примеров когда годами, если не десятилетиями считали нечто только исключительно полезным, пока наконец не находили недвусмысленные проблемы при неправильном применении. Витамины и радиация — только самые очевидные примеры.
Да, насчёт «Учитывайте, что не весь мелатонин из таблетки всасывается» — вы для начала прочтите текст, написанный в исходном коменте по английски. Там про уровень гормона в крови.
Если я правильно помню, то эндогенный мелатонин вырабатывается в количестве порядка всего лишь 0.5мг за сутки (хотя вики говорит вообще про 0.03мг). А в таблетке (мелаксен) от 3мг и больше. То есть даже пол-таблетки это по меньшей мере втрое (!!!) больше того, что в норме достаточно организму для прекрасного здорового сна. (Taking a typical dose (1 to 3 mg) may elevate your blood melatonin levels to 1 to 20 times normal. [src])
Так что считать, что потреблять экзогенный мелатонин нормально и безопасно — ошибка. И есть подозрения, что как и любая попытка играться с гормональной регуляцией, она может весьма дорого обойтись (желающие пусть разбираются с другой функцией мелатонина — регуляцией репродуктивной системы).
Все эти очки (не пробовал), будильники (пробовал), экзогенный мелатонин (тоже пробовал) и прочее в конечном итоге суть костыли, призванные замаскировать существование главной проблемы — у их потребителя что-то сильно съехало в настройках организма, отчего он не может вовремя засыпать и вовремя просыпаться.
Качественный сон имеет фундаментальное значение для здоровья всего организма, но это чрезвычайно сложное явление, которое невозможно настроить одним волшебным пенделем.
Решать эту проблему надо комплексно, по сути меняя и полностью перестраивая вокруг неё свою жизнь. Конкретно в моём случае единственно надёжно и стабильно работающим оказалась одновременная тройка: правильное питание, выдерживание режима дня (в первую очередь, надо регулярно ложиться так, чтобы к моменту нужного просыпания спать не менее 8 часов, при этом крайне желательно, чтобы основное время сна приходилось на период с 22 по 06 часов, причём начало этого интервала важнее всего) и так же регулярные тяжелые физ.нагрузки в спортзале. Всё остальное (даже соляризация, хотя она в целом где-то близко подпирает этот ТОП-3) вторично. Но зато теперь сам легко просыпаюсь в 6-7 утра, даже если (разово-аварийно!) пришлось лечь в первом часу ночи. Больше эффективно, стабильно и без нежелательных побочных эффектов не работает ничего! И если честно, — я думаю, что это вполне универсальный вывод.
Монументальный разбор!
Про метапрограммирование — обязательно попробуйте подружиться с либой boost::hana. Это совершенный отвал башки! Огромное множество ранее сложных и неудобных для С++ задач внезапно начинают решаться очень легко и элегантно. Вроде её собирались в std включать, кстати, так что в любом случае пригодится.
Итак, продолжаем тему.
После получения ответа Стефана я внёс в статью необходимые поправки и уточнения.
Главные следствия вкратце:
cone-filter не имеет ни малейшего отношения к фильтрам мат.морфологии, а есть ни что иное, как простейшее взвешенное среднее с ядром, линейно зависящим от расстояния до текущей точки. Принципиальных причин использовать его, а не какой-нибудь Gaussian Blur (отличие просто в том, что в Gaussian Blur ядро фильтра — тот самый колокольчик, а здесь просто конус), насколько я понимаю, нет. Просто он даёт другое сглаживание.
Соответственно, конечно же, никакой (существенной) регуляризации это не даёт, поэтому та моя гипотеза, что он влияет на паутину, совершенно не валидна (более того, он же используется и во всех бейслайн методах, сильно более активно генерящих паутину).
Поэтому именно эффект сверточной сети в убирании паутины максимален.
Теперь, что касается Вашей идеи:
Ограничение на толщину эелемента вполне себе убивает фрактальность (это не мой мопет — выше так назвали, но мы то знаем о чем мы говорим, да?).
Наверное, мы можем придумать и добавить в целевую функцию слагаемое, которое будет отвечать за «ажурность» конструкции, штрафуя мелкие элементы. Такой себе регуляризатор… Вполне. Однако я здесь вижу две тонкости, которые… скажем так… не делают очевидными мне пользу этого подхода:
Мы получаем ещё один набор гиперпараметров, которые надо подбирать — по меньшей мере это один скаляр, характеризующий минимальную нештрафуемую толщину, и ещё один скаляр, составляющий величину штрафа. Лишние гиперпараметры — лишний геморрой.
А что будем делать, когда нам может быть полезна ажурность? Мелкие элементы ведь могут быть совершенно полноценными, нужными и полезными частями решения в ряде случаев. Нас то волнует именно ненужная паутина, а не мелкость, но убирая таким образом паутину, мы вообще не сможем получить нужного решения. Оно просто будет перештрафовано и никогда не появится.
зы офф: я так понимаю, теперь можно ожидать появление nickname22 и новой порции отжигов…
Уже получил ответ от первого автора, Stephan Hoyer (вот это я понимаю подход к работе!). Сейчас нет времени разбирать всё подробно, в течение пары-тройки дней сделаю. Кратко — да, я правильно нашёл описание cone-filter, это именно он, и да, они использовали его с одинаковыми параметрами в каждом алгоритме, что уже само по себе делает гипотезу о его (существенном) влиянии на паутину, в общем, скорее неверной. Но ещё подумаю, потом напишу апдейт.
зы: ещё Стефан сказал, что они планируют скоро выложить код работы на Гитхаб. Снова могу только сказать «вот это я понимаю подход к работе!» :) Пока это ещё не стало нормой, и очень круто, что они проталкивают и эту тему.
Какой смешной))))
Юноша, Вы, совершенно очевидно, не в себе, поэтому ни на какие Ваши коменты я больше отвечать не буду. Хотя, конечно, запретить Вам продолжать мусорить я не могу, но посмотрим, как на это всё будет реагировать сообщество, — говорят, оно тут немного саморегулирующееся.
Кстати, абстрагируясь от исходной темы, благодаря которой «мы все тут сегодня собрались», именно превышение количества параметров НС над величиной обучающей выборки (aka сверхпараметризованные решения) оказывает (иногда) очень благотворное влияние на качество модели. См. arXiv:1812.11118 “Reconciling modern machine learning practice and the bias-variance trade-off” Mikhail Belkin et.al
Щто? Что вы называете «потоковыми задачами»?
Так вот,
Они — да, не будут.
А вот за наших находчивых я бы не был так уверен. Ещё и удивительным образом стоимость будет у всех примерно одинаковая, как с мегабайтом трафика без доп.планов было/есть.
1. разных возможностей уронить процесс вообще не так уж и много, и неправильная работа с памятью — это самая широкая из них. Поэтому не удивительно, что программы с ошибками падают чаще всего именно на памяти. Ну не ud2 же им падать?
2. любая безопасная работа требует чёткого понимания когда конкретно с чем конкретно работаем. Тогда пиши хоть на асме — не будет никаких проблем. Юниксы и прочие Линуксы, написанные на самых небезопасных С/С++ с годами аптайма тому пример (Винда диапазона NT4.0-2000-7 тоже совсем не так дурна на самом деле, как её любят представлять, и там точно микс С/С++ даже в kernel mode драйверах, но никсы в примере канонiчнее, конечно).
3. Программер может купить гарантии безопасности памяти с помощью языка, но это возможно сделать исключительно продав весьма много дополнительной ран-тайм нагрузки.
Отсюда простой вывод —
неча на зеркало пенять, коли рожа кривакогда прозводительность любого минимально сложного решения на первом месте, то, в общем случае, альтернативы всё равно нет.Вот сильно не уверен. Не скажу за всех, но лично мне очень кажется, что страшилки про «небезопасность работы с памятью в С++» сильно преувеличены. Уже давно придумана масса вполне надёжных техник, которые от этой проблемы избавляют. По крайней мере лично в моём опыте я даже не вспомню, когда в последний раз меня это кусало… Может разве что лет 20 назад, когда только учился, да и то не факт, поскольку переход на С/С++ после ассемблера очень облегчён.
Но вот всякие хитропопые undefined behaviour или х10 ускорение после разборки с data aliasing и т.д. и т.п. — вот это периодически случается и сейчас. Про пример в посте вообще не вспоминаю, — это ж поседеть можно, пока допрёшь что за фигня, если не сталкивался.
Главная беда, С++, имхо абсолютно не работа с памятью (она вполне безопасна и комфортна после некоторого уровня понимания), а адски замороченный стандарт с «кучей условий мелким шрифтом, сносками и звёздочками», что как раз демонстрирует пример этого поста… Но главная беда этой главной беды в том, что она, скорее всего, практически не излечима, просто потому, что заменив сложность на простоту почти всегда неминуемо проиграешь в конечном итоге в эффективности, поскольку вся эта сложность сделана с единственной целью — позволить компилятору выжимать максимум возможной эффективности из кода.
… афигеть… просто нет слов.
Я уже даже перестал нервно смеяться, когда слышу что-нить вроде «С/С++? Да, чо там, простые же языки»…
Не тот язык назвали brainfuck, ох не тот… Хотя всё равно люблю его, но это какой-то капец
Напомню только, что отсутствие пруфов негатива на нынешнем этапе вовсе не означает, что серьёзного негатива вообще не существует. Достаточно примеров когда годами, если не десятилетиями считали нечто только исключительно полезным, пока наконец не находили недвусмысленные проблемы при неправильном применении. Витамины и радиация — только самые очевидные примеры.
Да, насчёт «Учитывайте, что не весь мелатонин из таблетки всасывается» — вы для начала прочтите текст, написанный в исходном коменте по английски. Там про уровень гормона в крови.
Так что считать, что потреблять экзогенный мелатонин нормально и безопасно — ошибка. И есть подозрения, что как и любая попытка играться с гормональной регуляцией, она может весьма дорого обойтись (желающие пусть разбираются с другой функцией мелатонина — регуляцией репродуктивной системы).
Все эти очки (не пробовал), будильники (пробовал), экзогенный мелатонин (тоже пробовал) и прочее в конечном итоге суть костыли, призванные замаскировать существование главной проблемы — у их потребителя что-то сильно съехало в настройках организма, отчего он не может вовремя засыпать и вовремя просыпаться.
Качественный сон имеет фундаментальное значение для здоровья всего организма, но это чрезвычайно сложное явление, которое невозможно настроить одним волшебным пенделем.
Решать эту проблему надо комплексно, по сути меняя и полностью перестраивая вокруг неё свою жизнь. Конкретно в моём случае единственно надёжно и стабильно работающим оказалась одновременная тройка: правильное питание, выдерживание режима дня (в первую очередь, надо регулярно ложиться так, чтобы к моменту нужного просыпания спать не менее 8 часов, при этом крайне желательно, чтобы основное время сна приходилось на период с 22 по 06 часов, причём начало этого интервала важнее всего) и так же регулярные тяжелые физ.нагрузки в спортзале. Всё остальное (даже соляризация, хотя она в целом где-то близко подпирает этот ТОП-3) вторично. Но зато теперь сам легко просыпаюсь в 6-7 утра, даже если (разово-аварийно!) пришлось лечь в первом часу ночи. Больше эффективно, стабильно и без нежелательных побочных эффектов не работает ничего! И если честно, — я думаю, что это вполне универсальный вывод.
Про метапрограммирование — обязательно попробуйте подружиться с либой boost::hana. Это совершенный отвал башки! Огромное множество ранее сложных и неудобных для С++ задач внезапно начинают решаться очень легко и элегантно. Вроде её собирались в std включать, кстати, так что в любом случае пригодится.
После получения ответа Стефана я внёс в статью необходимые поправки и уточнения.
Главные следствия вкратце:
Теперь, что касается Вашей идеи:
Наверное, мы можем придумать и добавить в целевую функцию слагаемое, которое будет отвечать за «ажурность» конструкции, штрафуя мелкие элементы. Такой себе регуляризатор… Вполне. Однако я здесь вижу две тонкости, которые… скажем так… не делают очевидными мне пользу этого подхода:
зы офф: я так понимаю, теперь можно ожидать появление nickname22 и новой порции отжигов…
Уже получил ответ от первого автора, Stephan Hoyer (вот это я понимаю подход к работе!). Сейчас нет времени разбирать всё подробно, в течение пары-тройки дней сделаю. Кратко — да, я правильно нашёл описание cone-filter, это именно он, и да, они использовали его с одинаковыми параметрами в каждом алгоритме, что уже само по себе делает гипотезу о его (существенном) влиянии на паутину, в общем, скорее неверной. Но ещё подумаю, потом напишу апдейт.
зы: ещё Стефан сказал, что они планируют скоро выложить код работы на Гитхаб. Снова могу только сказать «вот это я понимаю подход к работе!» :) Пока это ещё не стало нормой, и очень круто, что они проталкивают и эту тему.
Юноша, Вы, совершенно очевидно, не в себе, поэтому ни на какие Ваши коменты я больше отвечать не буду. Хотя, конечно, запретить Вам продолжать мусорить я не могу, но посмотрим, как на это всё будет реагировать сообщество, — говорят, оно тут немного саморегулирующееся.