Это не переобучение. Это просто случайность. Возьмите 100 случайных чисел, постройте их график. Потом возьмите эти 100 случайных чисел и случайно прибавьте к каждому число, например, от -5 до 5. И постройте график новых 100 чисел поверх старых. Графики точно так же будут близки друг к другу. И именно это и делает модель — предсказывает следующую точку по одной предыдущей. Не удивлюсь, что простая baseline-модель «завтра цена будет как сегодня» дала бы большую точность. Короче, модель и рассуждения совершенно мимо.
Но за старание можно плюсик поставить. Чтобы не просто критиковать, то могу посоветовать смотреть на кривые обучения и давать их в качестве иллюстрации, а не табличку с последними 5 эпохами, а также чуть лучше освоить pandas — читать код больно, многие вещи, которые сделаны в 5+ строк кода делается одной.
А кто-то может назвать хотя бы 5 блокчейн-проектов, чьи токены продавались через ico/ieo или торгуются на биржах и в итоге их продукт/проект/что-там-у-них стал хоть сколь-нибудь популярен и работоспособен, известен и используется за пределами коммьюнити, а в идеале на слуху у среднего образованного обывателя и освещается не только профильными ресурсами про крипту/блокчейны. Если этот проект — платформа, то такая, на основе которой есть хоть одно известное и популярное приложение. Я могу вспомнить только криптокотов, уж простите, но и то, скорее популярность из-за абсурдности.
Я к тому, что со времён первых ICO прошли уже годы. Для стартапов, задача которых во взрывном росте, это очень много. Но что-то я не слышал и не встречал успешных выходцев из блокчейнов… Может кто-то откроет мне глаза.
Ссылки в поддержку этих довольно голословных утверждений есть? Не про обнаруженные лики в данных, что случается, а именно про «прощупывание» тестового сета, «взломы бд», «загонку в модель», и что везде сидят «скраперы».
Как минимум претензии в том, что, соглашаясь на участие в соревновании, ты соглашаешься с правилами его проведения, где чёрным по белому написано, что «Publicly, freely available external data is permitted, excluding data found on the PetFinder.my website. The source of any external data must be posted to the official competition forum prior to the Entry Deadline.» Нарушены были оба пункта. Причём с явным умыслом и изощренностью.
Причём делается всё по принципу компота. Берут разную муть, чушь всякую собирают, если это касается меня, то про моих знакомых и людей, про которых я вообще никогда не слышал, про места, где я бывал, и про места, о которых я тоже никогда не слышал. Собирают бумажки, фотографии, одежду. Потом создают продукт и предъявляют его.
«Нас» рассматривать бессмысленно, это очевидно. У «них» же есть практика выделения гранта на поддержку какой-нибудь опенсурсной штуки. Разумеется, если она не про что-то прямолинейное и несложное, а желательно близкое к науке, в т.ч. CS.
Например, вот тут в первые же секунды рассказывается на какие деньги человек по сути работает, разрабатывая numpy www.youtube.com/watch?v=tjEdQyZH6lA
В анализе данных великолепие Питона не в самом Питоне, а в огромном количестве библиотек. Библиотек вылизанных, больших, некоторые из которых даже можно называть полноценными инструментами. И пока критическая масса таких библиотек не будет доступна в похожем виде на любом другом языке X — никто в анализе данных не пересядет на этот язык X. Как только это случится, то думаю не ошибусь, если скажу, что многие будут рады покинуть территорию Питона.
Что интересно, думаю, большинство этих крупных библиотек для анализа данных и машинного обучения развиваются не благодаря Питону, а вопреки — вынося по сути весь свой core-функционал в код на C/C++, либо даже на Fortran'е.
В конце истории автор пишет, что рассказал про «тайный проект» вице-президенту (куда уж менеджеру топовее). А тот посмеялся с него. Выходит топ всегда был в курсе.
Автор правильно мыслит, что может он не видит всей картины в целом и что-то от него скрыто. А скрытым может быть многое. Возможны ситуации, когда разработка продуктов и их состояние на самом деле не так важно, как может показаться разработчикам этих продуктов. Например, в контексте этой истории, тот новый «скрытый» продукт мог быть озвучен перед инвесторами и на него получены огромные деньги. А может ещё больше удастся привлечь вот-вот со дня на день. А может полученная на основе объема инвестиций стоимость компании позволит привлечь внимание того, кто её купит. А значит весь топ-менеджмент обогатится. А вы тут со своими багами в CSS… Автор может был просто занозой в заднице на пути к процветанию.
Был опыт работы в похожей организации у нас, где весь топ-менеджмент были друзьями/знакомыми/однокашниками основателя. И со стороны выглядели некомпетентными и многие решения были вредными. По крайней мере вредными для одной конкретной цели — разработки и продвижения продукта. И также многие пытались «достучаться», проявлять инцииативу, идти в обход. Всё бесполезно. В итоге почти все уволились в течение полугода. И до сих пор я не знаю — было ли действительно всё настолько плохо, или я просто упускал из виду всю картину, которая возможно большей частью лежала в области инвестиций и финансов, а не в области разработки продукта… Возможно, время покажет.
Хотел бы я увидеть массовый отток ИТ-специалистов, каждый из которых в какой-то мере обязан если не NGINX'у, то open source-сообществу точно, из Рамблера по этому поводу. Или там выражение протеста с плакатиками, как на загнивающем западе в загнивающем гугле… Эх, мечты, мечты…
Да, первое знакомство и базовые вещи на уровне содержимого книжки «Learn You a Haskell for Great Good» оставляет исключительно положительные впечатления.
Но потом ты пишешь первую неучебную программу и ловишь segfault от сжирания всей памяти, пытаясь обработать какой-нибудь файлик в 500 Мб. Понимаешь всю цену «ленивости» языка, и что хоть Haskell по умолчанию ленивый, но программы рекомендуется писать по умолчанию строгими. Читаешь про BangPattern'ы, deepseq, разницу между Lazy и Strict (а потом value-strict и spine-strict) версиями структур данных, про unboxed типы — во многих книгах этого просто нет.
Затем смотришь на то, как применяют Haskell для реальных больших приложений, а не просто «типа скриптов» — например, в веб-фреймворках. Открываешь описание работы Servant'а и понимаешь, что все те описания монад, трансформеров и прочих typeclass'ов в книжках было лишь самой вершиной айсберга и тебе не рассказали про 101 pragm'у языка, каждая из которых добавляет новые возможности языка, поверх которых строится функционал каждого второго реального приложения на Haskell. И эти прагмы неожиданно сложные — даже не в плане того, как они реализованы, а в плане того, что они тебе дают. Например, попробовать сразу после LYHS разобраться в содержимом статьи wiki.haskell.org/GHC.Generics — гиблое дело.
И тут становится очевидной главная, имхо, проблема Haskell'а — очень большой gap между книжками и реальным production-использованием. И это на фоне действительно большей сложности языка по сравнению с другими мейнстримными. Если взять сферический rails, то после 1-2 книжек ты сможешь без особых сложностей освоить RoR на отличном уровне и быстро разбираться в новых возможностях, пролистывая доку/исходник. А с Haskell это не так. Радует только то, что эта сложность абсолютно логична и объяснима, чего иногда нет в других языках. В Haskell действительно очень многие вещи делаются абсолютно иначе, чем в привычных императивных языках и здесь совсем другая, более фундаментальная и вместе с тем очень утилитарная роль типов.
Если бы он ещё наряду с «возможностями» давал «ограничения» и «гарантии») Хотя всегда есть возможность использовать транспайлеры типа Elm и PureScript.
Шанс того, что ошибёшься и возьмёшь старый объект, не больше, чем в императивном стиле. Если программист кладёт старое значение в переменную, а потом новое значение в другую переменную, то вероятность ошибки есть всегда и не зависит от того, как писать.
Иммутабельность не про это, а про то, что объект X всегда остаётся неизменным с момента создания. И если, например, X был передан в поток A, то он никак не изменится, что бы не происходило в потоке B.
С корзиной да, всё так же. Единственное, что, конечно, есть разумные оптимизации компилятора. Например, нет смысла повторно выделять память, чтобы хранить копию тех же самых данных — можно просто сослаться на данные старого объекта, если они те же. Иммутабельность позволяет делать это без опасений. Ну, и разумеется сборщик мусора.
Отвечая на второй вопрос. Если брать классические паттерны из «банды четырёх», то в мире ФП они все немного теряют в своей ценности и перестают быть каким-то артефактом правильной разработки, которые необходимо знать от и до. Какие-то реализуются элементарно просто за счёт полиморфизма/функций высшего порядка/частичного применения. Какие-то целиком укладываются в возможности монад. Какие-то просто теряют смысл в парадигме ФП. При этом более высокоуровневые паттерны («архитектурные», типа MVC и т.д.) остаются вполне актуальными.
Касаемо первого абзаца. Вот цитата про функцию из теории категорий в книжке Category Theory for Computer Scientists:
A function f is a mathematical entity with the fol-
lowing properties:
F–1 f has a domain and a codomain, each of which must be a set.
F–2 For every element x of the domain, f has a value at x, which is an
element of the codomain and is denoted f(x).
F–3 The domain, the codomain, and the value f(x) for each x in the domain
are all determined completely by the function.
F–4 Conversely, the data consisting of the domain, the codomain, and the
value f(x) for each element x of the domain completely determine the
function f.
The domain and codomain are often called the source and target of f,
respectively.
От F-3 и F-4 до упрощенного термина «чистая функция» в контексте программирования — 1 шаг. Поэтому о какой-то притянутости чистоты/неизменности состояния говорить не стоит — это заложили не основоположники ФП по своей прихоти, а естественным образом вытекает из той области абстрактной математики, на основе которой ФП и основано.
Речь идет о том, что в RPC можно в одном запросе выполнить вызов сразу нескольких процедур. Например, создать пользователя, добавить ему аватар и в том же запросе подписать его на какие-то топики. Всего один запрос, а сколько пользы!
Действительно, если у вас будет всего одна нода backend, это будет казаться быстрее при batch-запросе. Потому, что три REST запроса потребуют в три раза больше ресурсов от одной ноды на установку соединений.
Вот в этом тезисе, от которого строятся дальнейшие размышления (которые вообще верные), видится небольшая манипуляция. REST не для вызова процедур, но его мерят этой линейкой. Если отталкиваться от этого примера, то если в сервисе есть кейс, где нужно «создать пользователя, установить аватарку, подписать его на что-то», то нужно задуматься о возможности в момент создания пользователя сразу передать все требуемые данные. По сути это Resource Expansion работающий для создания ресурса. Как экстремальное развитие идеи Resource Expansion можно рассматривать GraphQL. Вы же не сравниваете RPC с GraphQL по линейке количества вызовов процедур?
На мой взгляд главная проблема этого эксперимента — проведение его в Японии. Там настолько своеобразное отношение к работе и трудоголичность, что возможно даже сократив рабочую неделю до 1 дня, они не заметили бы падения производительности) Экстраполировать результаты на генеральную совокупность я бы точно не стал.
Но за старание можно плюсик поставить. Чтобы не просто критиковать, то могу посоветовать смотреть на кривые обучения и давать их в качестве иллюстрации, а не табличку с последними 5 эпохами, а также чуть лучше освоить pandas — читать код больно, многие вещи, которые сделаны в 5+ строк кода делается одной.
Я к тому, что со времён первых ICO прошли уже годы. Для стартапов, задача которых во взрывном росте, это очень много. Но что-то я не слышал и не встречал успешных выходцев из блокчейнов… Может кто-то откроет мне глаза.
классика…
Например, вот тут в первые же секунды рассказывается на какие деньги человек по сути работает, разрабатывая numpy www.youtube.com/watch?v=tjEdQyZH6lA
Что интересно, думаю, большинство этих крупных библиотек для анализа данных и машинного обучения развиваются не благодаря Питону, а вопреки — вынося по сути весь свой core-функционал в код на C/C++, либо даже на Fortran'е.
Был опыт работы в похожей организации у нас, где весь топ-менеджмент были друзьями/знакомыми/однокашниками основателя. И со стороны выглядели некомпетентными и многие решения были вредными. По крайней мере вредными для одной конкретной цели — разработки и продвижения продукта. И также многие пытались «достучаться», проявлять инцииативу, идти в обход. Всё бесполезно. В итоге почти все уволились в течение полугода. И до сих пор я не знаю — было ли действительно всё настолько плохо, или я просто упускал из виду всю картину, которая возможно большей частью лежала в области инвестиций и финансов, а не в области разработки продукта… Возможно, время покажет.
Да, первое знакомство и базовые вещи на уровне содержимого книжки «Learn You a Haskell for Great Good» оставляет исключительно положительные впечатления.
Но потом ты пишешь первую неучебную программу и ловишь segfault от сжирания всей памяти, пытаясь обработать какой-нибудь файлик в 500 Мб. Понимаешь всю цену «ленивости» языка, и что хоть Haskell по умолчанию ленивый, но программы рекомендуется писать по умолчанию строгими. Читаешь про BangPattern'ы, deepseq, разницу между Lazy и Strict (а потом value-strict и spine-strict) версиями структур данных, про unboxed типы — во многих книгах этого просто нет.
Затем смотришь на то, как применяют Haskell для реальных больших приложений, а не просто «типа скриптов» — например, в веб-фреймворках. Открываешь описание работы Servant'а и понимаешь, что все те описания монад, трансформеров и прочих typeclass'ов в книжках было лишь самой вершиной айсберга и тебе не рассказали про 101 pragm'у языка, каждая из которых добавляет новые возможности языка, поверх которых строится функционал каждого второго реального приложения на Haskell. И эти прагмы неожиданно сложные — даже не в плане того, как они реализованы, а в плане того, что они тебе дают. Например, попробовать сразу после LYHS разобраться в содержимом статьи wiki.haskell.org/GHC.Generics — гиблое дело.
И тут становится очевидной главная, имхо, проблема Haskell'а — очень большой gap между книжками и реальным production-использованием. И это на фоне действительно большей сложности языка по сравнению с другими мейнстримными. Если взять сферический rails, то после 1-2 книжек ты сможешь без особых сложностей освоить RoR на отличном уровне и быстро разбираться в новых возможностях, пролистывая доку/исходник. А с Haskell это не так. Радует только то, что эта сложность абсолютно логична и объяснима, чего иногда нет в других языках. В Haskell действительно очень многие вещи делаются абсолютно иначе, чем в привычных императивных языках и здесь совсем другая, более фундаментальная и вместе с тем очень утилитарная роль типов.
Иммутабельность не про это, а про то, что объект X всегда остаётся неизменным с момента создания. И если, например, X был передан в поток A, то он никак не изменится, что бы не происходило в потоке B.
С корзиной да, всё так же. Единственное, что, конечно, есть разумные оптимизации компилятора. Например, нет смысла повторно выделять память, чтобы хранить копию тех же самых данных — можно просто сослаться на данные старого объекта, если они те же. Иммутабельность позволяет делать это без опасений. Ну, и разумеется сборщик мусора.
Отвечая на второй вопрос. Если брать классические паттерны из «банды четырёх», то в мире ФП они все немного теряют в своей ценности и перестают быть каким-то артефактом правильной разработки, которые необходимо знать от и до. Какие-то реализуются элементарно просто за счёт полиморфизма/функций высшего порядка/частичного применения. Какие-то целиком укладываются в возможности монад. Какие-то просто теряют смысл в парадигме ФП. При этом более высокоуровневые паттерны («архитектурные», типа MVC и т.д.) остаются вполне актуальными.
От F-3 и F-4 до упрощенного термина «чистая функция» в контексте программирования — 1 шаг. Поэтому о какой-то притянутости чистоты/неизменности состояния говорить не стоит — это заложили не основоположники ФП по своей прихоти, а естественным образом вытекает из той области абстрактной математики, на основе которой ФП и основано.
Вот в этом тезисе, от которого строятся дальнейшие размышления (которые вообще верные), видится небольшая манипуляция. REST не для вызова процедур, но его мерят этой линейкой. Если отталкиваться от этого примера, то если в сервисе есть кейс, где нужно «создать пользователя, установить аватарку, подписать его на что-то», то нужно задуматься о возможности в момент создания пользователя сразу передать все требуемые данные. По сути это Resource Expansion работающий для создания ресурса. Как экстремальное развитие идеи Resource Expansion можно рассматривать GraphQL. Вы же не сравниваете RPC с GraphQL по линейке количества вызовов процедур?
титуладолжности. Внушает!