Я, к сожалению, не знал, что она из этого курса — я ее нашел на каком-то непонятном портале три месяца назад, и банально не смог восстановить авторство :( Непонятно было, откуда она. И да, это одна гифка, не две.
То, что она была у Эндрю в курсе — попросту забыл, увы. Спасибо большое за ваше замечание.
Говоря по быстродействию:
1. по сравнению с операциями перемножения матриц для больших размерностей скорость работы функции активации ничтожна — несмотря на то, что разовое перемножение дешевле, O(n,m) в итоге на полносвязном слое куда дороже чем O(n) на слое активации.
2. Для маленьких сетей есть более полезные для обучения сеточек реализации — ломанная сигмоида и т.н. Leaky ReLU. Стоимость расчета примерно аналогичная, а обучение работает в большинстве случаев эффективнее (если не считать выходного слоя для задач классификации, там ReLU очень хорошо ложится).
3. Бенчмарки утверждают, что скорость V8 и Chakra в задачах математики на JIT-оптимизированных функциях (которые исполнились несколько сотен или тысяч раз) довольно сильно приближается к скорости аналогичного кода на сях
4. развивая мысль. Такие задачи все-таки обычно по возможности решаются на GPGPU — WebCL и OpenCL/CUDA в ноде.
Я очень рад, что могу где-то восполнить пробелы :)
В этом и была проблема, почему написал такую статью — есть куча «ну вот мы делаем на фреймворке», и есть очень крутые с точки зрения тех, кто уже понимает, как это работает, и они разжевывают вот так, например — https://geektimes.ru/post/277088/. Статья крутая, но она работает так же, как паттерны разработки — ты читаешь, киваешь головой, вроде все понимаешь, но реальное понимание приходит только потом, после опыта.
А я постарался по свежей памяти объяснить это все так, как объяснил бы самому себе, еще не знающему про то, как это работает, но при этом понимающему код.
И да. Переходите с brain, он мертв, в смысле deprecated :) Подключайтесь к Synaptic, я надеюсь, релиз в январе будет.
Если вы под hacker's guide подразумеваете то, что выложено на RunKit — то оно изначально делалось как на русском, так и на английском же, и ссылки обе есть. Или вы о чем?
ну а я о чем, что для нормальных мл задач жс не пригоден, вы сами это и доказываете, используя что то другое
я и не отрицаю, что в данный момент не годен, я расчитываю на него в перспективе. причем не через месяц или два.
это оценочное суждение, пруфов то нет, по моим знакомым 1 из 10 шарит, опять же смещенная выборка
угу, а почему тогда в Питере Papers We Love сделали два фронтэндщика и позвали выступать третьего про CRDT, а датасатанисты бегали и удивлялись, как это не они сами сделали? :)
А вообще — да, верно, 10% JS-еров шарят. Это те ребята, которые делают транспиляторы, синхронизацию между клиентами, статический анализ, фреймворки для webGL и так далее. Но фронтэндщиков в целом дохрена, и эти 10% в численном представлении не то чтобы сильно меньше, кмк, чем специалистов с аналогичным уровнем знаний, которые умеют в R модельки крутить, например.
а вот если вы занимаетесеь машинным обучением, по настоящему, а не сеточку на жс накидать, то на жс вы не то что бы страдать будите, вы просто не сможете им заниматься, вообще никак
Для реальных (ну насколько реальные вещи можно делать без аренды сервера в 100gb RAM) вещей я использую в основном XGBoost и Keras, плюс кучка вещей поменьше. Synaptic — это работа на перспективу в надежде, что получится принести ML в JS.
думаю вы плохо гуглите, таких статей море, и видюшек на ютубе и курсов на курсере
а то что сети используют матричные операции, это не просто так наверное, да?
в том-то и дело, что нет. Уровень «разжеванности» в статье выше, чем где-либо кроме увиденного, где была бы реальная реализация, а не абстрактный разговор, и несколько ребят из OpenDataScience это подтвердили.
Theano например полноценный фреймворк для глубокого обучения и написан почти полностью на питоне, и дифференцирование вычислительного графа и всякая другая наркомания, далее он генерит немного куда-си кода и компилит его, что бы все еще и н гпу работало
На один Theano, который почти без си, у нас есть TensorFlow, AutoML, XGBoost, Caffe, MXNet, которые работают как биндинги к сям. И это то что я вспомнил сходу, в реальности кроме theano и либ поверх него ничего не работает без нативного слоя.
что бы делать что то большее чем формочки для сайтов, нужно как минимум выучить матан и линейную алгебру, тогда не будет проблем с пониманием матричных вычислений, не будет возникать вопросов вообще о том почему нужно сразу писать правильно, и вообще будет выбираться сразу нужный инструмент
Я удивлю, но большое количество JS-разработчиков довольно хорошо шарят в матане. Алгоритмы и структуры данных — они везде нужны.
скажем сиквел тоже Тьюринг полный язык, но у вас не возникло желания написать сеть на нем, так же после осознания линейной алгебры, у вас не возникнет вопросов почему нужно юзать питон, эр или матлаб
Это у вас не возникло желания ;) Поверх Postgres, Neo4j, ну и вишенкой на торте — поверх Redis
я бы порекомендовал помимо курса выше разве что http://statweb.stanford.edu/~tibs/ElemStatLearn/. Но это очень тяжелая книга, хотя и одна из самых крутых. Первые 50 страниц я осиливал где-то две недели до полного понимания, например.
А если серьезно — то ответ на вопрос «зачем написать», я не видел ни одной статьи, где не было бы реально внятного объяснения без матричных операций.
А если вопрос «зачем на JS», то в реальности нет никакой разницы, с чем ты работаешь. R и Python с их супер-библиотеками на поверку оказываются тупо биндингами к C-шным библиотекам (окей, иногда с абстракциями), и чтобы начать работать с TensorFlow или XGBoost достаточно написать эти самые биндинги для Nodejs. Вся сила в экосистеме, и сделать эту экосистему не так сложно, как кажется — с учетом количества JS-разработчиков, желающих делать что-то большее чем формочки на сайтах
нейронные сети != deep learning. В сети с одним скрытым слоем не нужен механизм back propagation, при этом понимание того, как данные «текут» через узлы и почему нам нужны отдельно линейные преобразования и отдельно активации — куда более важно для понимания того, как сети работают. К тому же количество материала и так огромное получилось (если считать вместе с кодом, выложенным на runkit).
Планируется еще одна статья про сверточные сети (там уже backprop необходим) и, возможно, про LSTM/RNN.
Ну, это довольно корректное утверждение. Была история, как в 70-е (кажется), на волне увлечения перцептронами, какой-то НИИ объявил, что сможет распознать на фото танки, отличить их от всего остального. Это сейчас мы понимаем, что на тех мощностях это невозможно, но каким-то образом все в это верили.
Но почему-то у них это заработало. Все успешно сдали, но вдруг в реальных условиях она перестает работать. Все в паники, начинают разбираться.
Оказалось, дело было в том, что выборка была наведенной. Фото вражеских танков всегда делали в безоблачную погоду, а остальные картинки для обучения были сделаны как угодно. В итоге перцептрон видел небо и говорил «да, это похоже на те картинки, что вы мне подсовывали».
Поэтому большая часть работы — это корректная подготовка примеров для обучения, перетасовка, кроссвалидация, вот это все.
не обращайте внимания, это просто пример под впечатлением от этого видео. Я не очень хорошо разбираюсь в металлах, и был искренне впечатлен тем, что в «реальный сектор» настолько круто пришли технологии машинного обучения.
Моя фантазия слегка подвисла, пытаясь придумать хоть один нормальный пример линейной регрессии кроме соотношения рост-вес, поэтому была выдумана такая абсолютно некорректная, но довольно понятная история.
у Хабра, кажется, нет английской версии. Так что либо вы не учитываете сайты, либо вы воспользовались скрин-ридером, чтобы оставить этот комментарий, не _видя_ хабр.
Все корректно — Петька Антонов адово крутит перфоманс, и его реализация давным-давно известна за чудовищную эффективность. А вот почему его код не перенесли в v8 — для меня большой вопрос.
Лучше бы идиоты не пытались лезть в фронт. и в бэк. и вообще.
Потому что когда ты приходишь к бэкэндеру с фразой «у нас эндпоинт отдает данные 300 секунд, это неправильно» и получаешь ответ «ой да ладно тебе, как будто ты таймаут побольше выставить не можешь» хочется в лицо бить.
Каждый разработчик должен иметь знания смежных domain of knowledge на уровень ниже. То есть senior front-end должен иметь уровень хотя бы mid-backend, mid-ui, mid-content, mid-QA. Это тянет за собой junior DBA, junior devops, junior design+ux, junior stretegy. Иначе это бесполезный специалист, живущий в своем мирке и не смотрящий по сторонам.
К бэкэндерам это так же относится, только теперь для senior back-end нужно middle devops, middle dba, middle front-end, middle QA, junior UI, junior content.
Это не только про фронтэнд история, это про все. Все знать должны смежные области.
А иначе получится вечная история о том, как умный фронтэндер пришел и обосрал всю архитектуру, после чего пятерых разработчиков разогнали, потому что он оказался frontend/node.js fullstack. Или пхпшник оказался на самом деле сишником, который расширения для пхп уже 5 лет пишет. Или дизайнер оказался неплохим верстальщиком и все на него свалили. Сколько я этих историй уже насмотрелся…
То, что она была у Эндрю в курсе — попросту забыл, увы. Спасибо большое за ваше замечание.
Говоря по быстродействию:
1. по сравнению с операциями перемножения матриц для больших размерностей скорость работы функции активации ничтожна — несмотря на то, что разовое перемножение дешевле, O(n,m) в итоге на полносвязном слое куда дороже чем O(n) на слое активации.
2. Для маленьких сетей есть более полезные для обучения сеточек реализации — ломанная сигмоида и т.н. Leaky ReLU. Стоимость расчета примерно аналогичная, а обучение работает в большинстве случаев эффективнее (если не считать выходного слоя для задач классификации, там ReLU очень хорошо ложится).
3. Бенчмарки утверждают, что скорость V8 и Chakra в задачах математики на JIT-оптимизированных функциях (которые исполнились несколько сотен или тысяч раз) довольно сильно приближается к скорости аналогичного кода на сях
4. развивая мысль. Такие задачи все-таки обычно по возможности решаются на GPGPU — WebCL и OpenCL/CUDA в ноде.
В этом и была проблема, почему написал такую статью — есть куча «ну вот мы делаем на фреймворке», и есть очень крутые с точки зрения тех, кто уже понимает, как это работает, и они разжевывают вот так, например — https://geektimes.ru/post/277088/. Статья крутая, но она работает так же, как паттерны разработки — ты читаешь, киваешь головой, вроде все понимаешь, но реальное понимание приходит только потом, после опыта.
А я постарался по свежей памяти объяснить это все так, как объяснил бы самому себе, еще не знающему про то, как это работает, но при этом понимающему код.
И да. Переходите с brain, он мертв, в смысле deprecated :) Подключайтесь к Synaptic, я надеюсь, релиз в январе будет.
я и не отрицаю, что в данный момент не годен, я расчитываю на него в перспективе. причем не через месяц или два.
угу, а почему тогда в Питере Papers We Love сделали два фронтэндщика и позвали выступать третьего про CRDT, а датасатанисты бегали и удивлялись, как это не они сами сделали? :)
А вообще — да, верно, 10% JS-еров шарят. Это те ребята, которые делают транспиляторы, синхронизацию между клиентами, статический анализ, фреймворки для webGL и так далее. Но фронтэндщиков в целом дохрена, и эти 10% в численном представлении не то чтобы сильно меньше, кмк, чем специалистов с аналогичным уровнем знаний, которые умеют в R модельки крутить, например.
Для реальных (ну насколько реальные вещи можно делать без аренды сервера в 100gb RAM) вещей я использую в основном XGBoost и Keras, плюс кучка вещей поменьше. Synaptic — это работа на перспективу в надежде, что получится принести ML в JS.
в том-то и дело, что нет. Уровень «разжеванности» в статье выше, чем где-либо кроме увиденного, где была бы реальная реализация, а не абстрактный разговор, и несколько ребят из OpenDataScience это подтвердили.
На один Theano, который почти без си, у нас есть TensorFlow, AutoML, XGBoost, Caffe, MXNet, которые работают как биндинги к сям. И это то что я вспомнил сходу, в реальности кроме theano и либ поверх него ничего не работает без нативного слоя.
Я удивлю, но большое количество JS-разработчиков довольно хорошо шарят в матане. Алгоритмы и структуры данных — они везде нужны.
Это у вас не возникло желания ;) Поверх Postgres, Neo4j, ну и вишенкой на торте — поверх Redis
А если серьезно — то ответ на вопрос «зачем написать», я не видел ни одной статьи, где не было бы реально внятного объяснения без матричных операций.
А если вопрос «зачем на JS», то в реальности нет никакой разницы, с чем ты работаешь. R и Python с их супер-библиотеками на поверку оказываются тупо биндингами к C-шным библиотекам (окей, иногда с абстракциями), и чтобы начать работать с TensorFlow или XGBoost достаточно написать эти самые биндинги для Nodejs. Вся сила в экосистеме, и сделать эту экосистему не так сложно, как кажется — с учетом количества JS-разработчиков, желающих делать что-то большее чем формочки на сайтах
Планируется еще одна статья про сверточные сети (там уже backprop необходим) и, возможно, про LSTM/RNN.
Но почему-то у них это заработало. Все успешно сдали, но вдруг в реальных условиях она перестает работать. Все в паники, начинают разбираться.
Оказалось, дело было в том, что выборка была наведенной. Фото вражеских танков всегда делали в безоблачную погоду, а остальные картинки для обучения были сделаны как угодно. В итоге перцептрон видел небо и говорил «да, это похоже на те картинки, что вы мне подсовывали».
Поэтому большая часть работы — это корректная подготовка примеров для обучения, перетасовка, кроссвалидация, вот это все.
Моя фантазия слегка подвисла, пытаясь придумать хоть один нормальный пример линейной регрессии кроме соотношения рост-вес, поэтому была выдумана такая абсолютно некорректная, но довольно понятная история.
2. в каком диапазоне генерируется magic, рассматривали ли вариант «только простые числа» для него?
3. считали ли вероятность отказа при создании этого алгоритма из-за событий малой вероятности?
Заглавный регистр используется для надписей Wi-Fi и Bluetooth, являющихся именами собственными
Потому что когда ты приходишь к бэкэндеру с фразой «у нас эндпоинт отдает данные 300 секунд, это неправильно» и получаешь ответ «ой да ладно тебе, как будто ты таймаут побольше выставить не можешь» хочется в лицо бить.
Каждый разработчик должен иметь знания смежных domain of knowledge на уровень ниже. То есть senior front-end должен иметь уровень хотя бы mid-backend, mid-ui, mid-content, mid-QA. Это тянет за собой junior DBA, junior devops, junior design+ux, junior stretegy. Иначе это бесполезный специалист, живущий в своем мирке и не смотрящий по сторонам.
К бэкэндерам это так же относится, только теперь для senior back-end нужно middle devops, middle dba, middle front-end, middle QA, junior UI, junior content.
Это не только про фронтэнд история, это про все. Все знать должны смежные области.
А иначе получится вечная история о том, как умный фронтэндер пришел и обосрал всю архитектуру, после чего пятерых разработчиков разогнали, потому что он оказался frontend/node.js fullstack. Или пхпшник оказался на самом деле сишником, который расширения для пхп уже 5 лет пишет. Или дизайнер оказался неплохим верстальщиком и все на него свалили. Сколько я этих историй уже насмотрелся…