Организация Apache Software Foundation объявила (https://blogs.apache.org/foundation/entry/the-apache-softwar...) о присвоении Apache SystemML (http://systemml.apache.org/) статуса первичного проекта Apache. Платформа машинного обучения SystemML изначально была создана компанией IBM и используется в системе IBM Watson Health. В ноябре 2015 года наработки по SystemML были переданы под покровительство фонда Apache, в котором проект находился в инкубаторе, где была проверена способность следования принципам разработки и управления, принятым в сообществе Apache и основанным на идеях меритократии. Теперь Apache SystemML признан готовым для самостоятельного существования, не требующего дополнительного надзора. Компоненты проекта написаны на языках С++ и Java и поставляются (https://github.com/apache/incubator-systemml) под лицензией Apache 2.0.
Платформа Apache SystemML предоставляет средства для построения масштабируемых распределённых систем машинного обучения. В состав входит транслятор для различных алгоритмов машинного обучения, способный на основе заданного декларативного описания алгоритма автоматически генерировать гибридные планы выполнения как для единичных систем c обработкой данных в оперативной памяти, так и для кластеров с крупными хранилищами, развёрнутыми при помощи систем Apache Hadoop и Apache Spark.Назначение SystemML для машинного обучения сравнивается с SQL для баз данных, SystemML позволяет абстрагироваться от черновой работы и сконцентрировать внимание на специфике решаемой проблемы при помощи высокоуровневого синтаксиса, похожего на язык R, а все оптимизации и преобразования будут выполнены специальным оптимизатором, учитывающим имеющиеся данные и ресурсы для формирования наилучшего плана выполнения алгоритма.
Системой предоставляется большая подборка статистических функций, примитивов линейной алгебры и конструкций, специфичных для систем машинного обучения. В отличие от имеющихся библиотек машинного обучения, предоставляющих фиксированный набор алгоритмов и типовых планов выполнения кода, SystemML пытается сочетать эффективность с масштабируемостью через применение автоматической оптимизации, учитывающей особенности текущих данных и имеющегося вычислительного кластера. Решения на базе SystemML способны масштабироваться от крупных кластеров и мэйнфреймов до ПК и смартфонов, позволяя создавать новые категории бизнес-приложений, использующих элементы машинного обучения.
URL: https://blogs.apache.org/foundation/entry/the-apache-softwar...
Новость: http://www.opennet.ru/opennews/art.shtml?num=46638
Нифига непонятно. Всё абстрагируется, самооптимизируется, самообучается.Понимаю, это не моего уровня продукты и задачи, но хотя бы из интереса посмотреть малюсенькую хаутушечку с маленьким каким-нибудь примером решения конкретного примера.
Хаутушечка разве сможет удовлетворить?
Не лучше ли, начать с азов Computer Science и постепенно "дойти" до сабжа?
Ты поаккуратнее с советами - могут случайно Skynet построить.
Скорее всего просто максимизатор скрепок.
Текст новости шикарен. Я вот не знаю что такое "машинное обучение" и замена "машинного обучения" на "сепуление" не сильно меняет смысл. Охотно верю, что не все такие серые как я и Вы. В нашей ситуации поможет wikipedia:
>> но хотя бы из интереса посмотреть малюсенькую хаутушечкуНет слов, Василий.
Интересная "вещь в себе". С какой стороны к ней подкатить?
"SystemML для машинного обучения сравнивается с SQL для баз данных"Какая-то неудачная аналогия, т.к. вообще говоря, SQL в итоге оказался полным провалом: убогость, косность фраз, не предназначенность для машинной обработки, в результате полный разброд у вендоров и быстрая смерть в начале 2010 годов в пользу NOSQL. RIP!
Надеюсь SystemML не имеет ничего общего с SQL
> Надеюсь SystemML не имеет ничего общего с SQLВообще ничего. SystemML настолько нужный и перспективный проект что IBM передала его в Apache Foundation. Похоже IBM получит сверхдоходы от проекта. Чтобы сильно не думалось я приведу пример двух проектов: никому не нужный LibreOffice который сам по себе, и всеми пользуемый и перспективный OpenOffice который в Apache.
Сверхдоходы IBM получает от того, что написано на основе SystemML, а не от неё самой.
Не нравится сравнивать с SQL - сравните с Прологом, например.Ну и просто интересно: можно конкретный пример убогости и косности SQLя? Пруфы про смерть я даже не буду спрашивать.
> можно конкретный пример убогости и косности SQLяпорядок операндов фиксированный, причём до маразма. limit и "order by" не вздумай поменять местами. а в например select сначала пишешь field, в потом table, в итоге автодополнение не работает. теряешь всего 3 сек, но 100500 раз - итого очень много.
аналитические функции с использованием rank, over и "partition by" делают вывих мозга
Плюсом из убогости (двумерность) самих РСУБД вытакает убогость всего SQL-я в виде разнообразных JOINов и 5этажных select into
при этом я особо сложные вещи на SQL не делал, предпочитая нормальные языки программирования.
про парсинг текста команды и костыли в виде prepared statements все знают.
про бардак с limit, top, rownum() или там except/minus итд итп тоже
Нормальные люди поработав с mongo api например выкидывают SQL на помойку. Можешь не видеть очевидного, мне не жалко. Но посмотри на рынок вакансий, нужно или nosql или ORM. А программисты SQL уже там же где и программисты HTML.
> порядок операндов фиксированныйи замечательно. S - значит structured. Иначе был бы не запрос, а нечитаемое мессиво.
> аналитические функции с использованием rank, over и "partition by" делают вывих мозга
Первые несколько дней - да. Это вы ещё на всякие мультисеты и группинг сеты не смотрели. К слову, чтобы вывернуть мозг на первый проект с использованием Redis, мне понадобилось больше месяца: очень бесила убогость и несуразность. Потом ничего, разобрался и понравилось. Начал бы с редиса - бесил бы переход на SQL.
> Плюсом из убогости (двумерность) самих РСУБД вытакает убогость всего SQL-я в виде разнообразных JOINов
Да нет в джоинах никакого зла.
> при этом я особо сложные вещи на SQL не делал, предпочитая нормальные языки программирования.
SQL - это _query_ language, причём тут нормальные/ненормальные языки программирования? К слову, orm - это всего лишь object-relational _mapping_.
> про парсинг текста команды и костыли в виде prepared statements все знают.
Поясните, плз, я не знаю.
> про бардак с limit, top, rownum() или там except/minus итд итп тоже
+1, раздражает. Однако, единого стандарта на nosql и orm я тоже не встречал.
> Нормальные люди поработав с mongo api например выкидывают SQL на помойку. Можешь не видеть очевидного, мне не жалко. Но посмотри на рынок вакансий, нужно или nosql или ORM. А программисты SQL уже там же где и программисты HTML.
Если кто-то покажет хорошую реализацию на noSQL, например, учётной системы сети гипермаркетов, я крепко задумаюсь. Однако, пока такого не видел.
PS: О чём вообще спор? Каждой задаче - свой инструмент.
> нечитаемое мессивоот свопа limit и order маша? нуну...
в монге вообще любой оператор можно менять местами. супер.
.find().limit(1).sort( { ts : -1 } ).pretty()>Начал бы с редиса
Ну, я начал с SQL ещё лет 15 назад. С радостью выкинул в пользу ORM и NoSQL.
Вообще по редису судить о всех NOSQL странно.
>К слову, orm - это всего лишь
в котором не надо писать километровые SQLзапросы. Для информации.
>единого стандарта на nosql
Потому что все NOSQL невероятно отличаются. Ещё скажи, что графовый Neo4j должен "говорить" на стандартном NOSQL-языке? Вся сила в разнообразии.
Мне кстати интересно, графовый модуль к Постгресу тоже в SQLные рамки затолкали? Вот уж неведома зверушка получилась явно.
>нет в джоинах никакого зла
Ты не шаришь в вопросе. Когда у тебя в resultset 90% дублированных данных из-за того что ради дополнительных полей все столбцы повторяют эти данные, выгребание этого заметно тормозит. Хотя, я забыл, у РСУБДшников же тормоза это норма... и нет никакого зла :)))
>>К слову, orm - это всего лишь
> в котором не надо писать километровые SQLзапросы. Для информации.Так ведь на сторону СУБД это прилетает именно в виде километровых запросов с настолько ужасными планами выполнения, что хочется убивать.
> в resultset 90% дублированных данных из-за того что ради дополнительных полей все столбцы повторяют эти данные
???
> Ты не шаришь в вопросе.
Не профи, конечно, но всякие красивые бумажки на тему DBA и Performance and tuning имеются. Тоже 15 лет в теме, кстати. Предлагаю за это выпить.
>> Ты не шаришь в вопросе.Все деффчонки знают что шарят только жабисты. Причём почти всегда - >|<опой по луже :)
>Не профи, конечно, но всякие красивые бумажки на тему DBA и Performance and tuning имеются. Тоже 15 лет в теме, кстати. Предлагаю за это выпить.Ай молодца! Тонко ты его! Давай выпьем!
Но без жабиста, увы - ему пока мамка не разрешает :)
> Но без жабиста, увы - ему пока мамка не разрешает :)Да не пью, ни пиво, ни остальное. И свитер не ношу. И подстрижен. И без коньюктивита. Фу, неправильный опеннетчик... ;) А самое приятное тут макнуть носом вас, кульДБА с 15летним опытом, в вашей же области. Про полноценное проганье с вами и поговорить не о чем.
Кому действительно непонятно в чём убогость РСУБДшного JOINа, покажите как храните в базе не сильно сложный объект с допустим 5 уровнями
Organisation с десятком полей-списков, в каждом ещё по 3-10 списков итд
Т.е. итого под 400-500 полей.И сколько стоит сервак, который будет его отдавать полностью из 200ГБ базы за скромные 1мс.
> Ты не шаришь в вопросе. Когда у тебя в resultset 90% дублированных
> данных из-за того что ты, как типичный похапист или ж[a|o]пист, в алгебрах реляционных и формах нормальных - ни ухом, ни рылом, но упорно лезешь в разработчики.фикс, не благодарите.
Руки прочь от sql! Беда, когда люди начинают (и заканчивают) изучение программирования с джавы. Они не понимают в большинстве своём ни как их собственный код работает на уровне процессора, памяти. Ни в азах реляционной алгебры, на которой построены реляционные БД. И главное - не хотят, поливают г-ном то в чем ни**я не разбираются. Оракл с постгресом ещё на похоронах nosql простудятся. Кстати, Оракл Sun с Java-ой купил с потрохами, а не наоборот.
Коллега, пишите скорее свой адрес, я вышлю вам пива с воблой.
88 Colin P Kelly Jr St.
San Francisco, CA 94107.
United States.
Не реагируйте на похоронную команду которая пришла за SQL, таких уже было не один раз. Жертвы менеджмента, что ещё скажешь у нас 5-6 лет наза менеджеры тоже носились с этим вот FB смог на этом выскочить и т.п. Написали тесты они показали, что в наших задачах лучше SQL ни чего пока нет. И всё вернулось на круги своя.
"R-like and Python-like" короче щит-лайк, а идея полезная. Нафаршировать бы алгоритмами и декларировать программы на птичьем языке без отладок и пыли.
а мы упоролись и хотим на пхп это летать ))))