У меня есть небольшой оптимизм на счёт замены JS чем-то более приятным за счёт доминирования Chrome/Chromium-based. То есть если гугл сильно захочет, и вложится в свой Dart (как пример — я не агитирую за него) по полной, то это будет уже бОльшая часть рынка — миллиарды устройств. После этого останется дождаться падения «стены» на стороне Safari, и тогда все остальные будут вынуждены адаптироваться. То есть в какой-то мере браузерный монополизм может сыграть положительную роль в том, чтобы освежиться и отбросить легаси в виде не самого приятного языка.
1) В первом приближении таких же. Разве что функция суммации может быть изощренней из-за тех же свёрток, например. И да, чем глубже сеть, тем больше внимания уделяют функциям активации, наряду с другими ухищрениями (архитектурой, регуляризацией, инициализацией весов, нормировкой выходов слоёв и т.д.), чтобы обеспечить стабильную работу градиентного спуска.
2) Ничем. Многослойность говорит только о том, сколько слоёв нейронов соединены друг с другом.
3) Да, градиентные методы остаются наиболее универсальными. Разумеется у них много вариаций и улучшений по сравнению с самым наивным вариантом, но суть остаётся той же.
То есть выделяют сумму почти равную стоимости Coursera как компании на то, чтобы создать каталог бесплатных курсов? Причём не создавая сам контент, а просто разработав сайтик с авторизацией и ссылками? Штош…
Дальтонизм выявили в военкомате. С получением прав это проблемы не вызвало. Могу назвать буквально несколько постоянно встречающихся случаев, когда я вспоминаю о своём дальтонизме:
— Любые игры с цветными кружочками (типа «три в ряд»), где фон и цвет кружочков подобран недостаточно контрастно. Иногда мне даже приходилось переключаться в ч/б вариант, где вместо цветов были разные штриховки кружочков.
— Некоторые шутеры, где кому-то пришло в голову ники «своих» обозначать зелёным, а «чужих» — красным. Если эти ники на фоне, например, травы или голубого неба, то мне очень сложно их различать.
— Выделение текста или линии графиков светлыми цветами зелёного и красного. Вот честно, в мире столько цветов, но почему вы считаете, что именно эти два диаметрально противоположны?)
Не подстраивается ли? А по мне так как раз наоборот — последние лет 10-15 каждый новый язык пытается быть проще для входа и с как можно более плавной кривой обучения. Особенно если язык общего назначения и для общего же значения и используется. Читать спецификацию языка, чтобы писать без ошибок несложные программы — это очень странно и сейчас точно ни один из новых языков не предлагает себя изучать так.
Всё же от языков программирования в 2019-м году ожидают большую «человечность» и отсутствие необходимости штудировать документацию, чтобы не совершать ошибок в таких базовых вещах. Особенно для языка, который на каждом шагу называется самым простым и понятным в освоении, что его даже детям предлагают в школах изучать.
«Простое место» не в плане того, как оно работает на самом деле, а как оно преподносится сферическом новичку в вакууме. То есть если взять гипотетический курс «Python для вашего маркетолога», то там, когда дойдут до функций, расскажут про чудесные позиционные аргументы, keyword-аргументы и покажут пример мегаудобной фичи со значениями по умолчанию. И всё выглядит красиво и понятно, но потом тебе говорят, что если поставить дефолтным значением список, то всё будет плохо. А если не список, а множество (круглые скобочки вместо квадратных), то всё будет ок. А потом начинают жесть про мутабельность. А сверху присыпят тем, что передавая что угодно в функцию ты никогда не можешь быть уверен, что это что-то останется без изменений. И это чуть ли не в самом начале освоения языка, который все называют очень простым и понятным, что даже гуманитарии из маркетинга осваивают его.
Если честно, то всё это со стороны других языков (может, кроме JS) выглядит как ошибки в проектировании или реализации языка. Ну, то есть, поведение крайне неочевидно. Причём неочевидно в очень простых местах (типа мутабельных значений по умолчанию в аргументах). Если язык в самых базовых моментах требует от тебя понимания своей работы изнутри — что-то с этим языком сильно не так.
Имхо, конечно. И разумеется это не перечеркивает некоторые плюсы питона.
Ещё само предположение о независимости выборок можно поставить под сомнение. Сколько человек из 4к в 2014 поучаствовали в опросе в 2019 и попали в 8к? С учётом того, что опрос наверняка вёлся среди пользователей этого портала, что само по себе уже ставит под сомнение независимость выборок. Ведь для тех, кто принял участие в оба года, можно предположить, что за 5 лет их доход сильно вырос. А это нарушает предположение о независимости наблюдений.
При формулировании H0 совершенно неправильно посчитан доверительный интервал. Перцентили в выборке это совсем не то же самое, что доверительный интервал оценки среднего.
Также алгоритм бутстрепа странный… В оригинале делается N выборок из объединения ваших изначальных выборок. Мы пытаемся получить приближение распределения выбранной нами статистики при справедливости H0. Поэтому мы сэмплируем 10000 раз len(data) сетов из data. Затем берём из каждой семплированной выборки первые len(data_14) и следующие len(data_19) и считаем нашу статистику на этих данных — разницу средних в нашем случае. Спустя 10000 раз мы получим распределение. И далее уже на нём смотрим, какой шанс был получить такое же или большее значение статистики (т.е. p-value).
И вас чисто интуитивно не смущает, что при столь близких средних, довольно большом разбросе значений и не гигантских выборках вы получили p-value столь маленьким (а по сути равным 0 на 10000 бутстрапированных выборок)?
В жестоком реальном мире помимо «что на вход», «что на выходе» и «что делает» есть ещё потребность в описании возможных состояний системы. Даже если хочется делать 100% RESTful…
Если цель «не отдавать госденьги в руки иностранцев», то почему бы и не сформулировать закон как «требование к компаниям, претендующим на госфинансирование и инвестиции». А не как ограничение на абстрактные «значимые IT-ресурсы».
То есть двигаться от проблемы…
Да, отправитель может обработать это исключение. Там же наверное и таймаут ожидания ответа будет. Но ведь именно об этом Джо Армстронг и пишет ниже, ратуя за простоту обмена сообщениями, простоту самих процессов-акторов и обработку ошибок вне процессов. Т.е. такие «инфраструктурные» сложности противоречат тезису Джо о том, что перечисленные выше атрибуты необходимы для распределённых и надёжных систем. В этом контексте он и указал на это, как на минус Smalltalk'а.
Другое дело, что этот тезис можно поставить под сомнение. Но я не буду, так как скорее согласен с ним, да и Erlang/Elixir доказал, что на нём можно реализовывать такие системы малой кровью (сравнительно с другими).
И всё же такое поведение нельзя назвать синхронным. А если получатель упал не успев сообщить отправителю? В том-то и дело, что в Erlang асинхронность отправки сообщений между акторами является базовым вариантом, а уже синхронность эмулируется. Сообщения отправляются по принципу «выстрелил и забыл» и добавление любого ожидания ответа от получателя эту асинхронность ломает.
Мысль автора скорее в том, что передача сообщений должна быть такой, какую ожидает иметь отправитель — синхронной или асинхронной. Smalltalk видимо предоставил только первый вариант и в этом претензия к нему.
У всяких sbc есть важное преимущество — бОльшие возможности по доступу к сети. Тот же Orange Pi или сравнимый с ним имеет и Ethernet-порт, и wi-fi, и достаточно USB-портов, чтобы воткнуть модем. Это, кстати, тоже важный момент, так как зачастую от комнаты с оборудованием до ближайшего роутера может быть не проложен кабель, или интернета нет вообще и единственный вариант — мобильный интернет.
Для постоянного промышленного использования, т.е. когда диспетчеризация на года, то да. Но есть и кратковременные задачи, на которые так сильно раскошеливаться не согласится заказчик. Не только домашняя автоматизация.
2) Ничем. Многослойность говорит только о том, сколько слоёв нейронов соединены друг с другом.
3) Да, градиентные методы остаются наиболее универсальными. Разумеется у них много вариаций и улучшений по сравнению с самым наивным вариантом, но суть остаётся той же.
— Любые игры с цветными кружочками (типа «три в ряд»), где фон и цвет кружочков подобран недостаточно контрастно. Иногда мне даже приходилось переключаться в ч/б вариант, где вместо цветов были разные штриховки кружочков.
— Некоторые шутеры, где кому-то пришло в голову ники «своих» обозначать зелёным, а «чужих» — красным. Если эти ники на фоне, например, травы или голубого неба, то мне очень сложно их различать.
— Выделение текста или линии графиков светлыми цветами зелёного и красного. Вот честно, в мире столько цветов, но почему вы считаете, что именно эти два диаметрально противоположны?)
Имхо, конечно. И разумеется это не перечеркивает некоторые плюсы питона.
Также алгоритм бутстрепа странный… В оригинале делается N выборок из объединения ваших изначальных выборок. Мы пытаемся получить приближение распределения выбранной нами статистики при справедливости H0. Поэтому мы сэмплируем 10000 раз len(data) сетов из data. Затем берём из каждой семплированной выборки первые len(data_14) и следующие len(data_19) и считаем нашу статистику на этих данных — разницу средних в нашем случае. Спустя 10000 раз мы получим распределение. И далее уже на нём смотрим, какой шанс был получить такое же или большее значение статистики (т.е. p-value).
И вас чисто интуитивно не смущает, что при столь близких средних, довольно большом разбросе значений и не гигантских выборках вы получили p-value столь маленьким (а по сути равным 0 на 10000 бутстрапированных выборок)?
То есть двигаться от проблемы…
Другое дело, что этот тезис можно поставить под сомнение. Но я не буду, так как скорее согласен с ним, да и Erlang/Elixir доказал, что на нём можно реализовывать такие системы малой кровью (сравнительно с другими).