Очень многие жалуются на сложный код Lift, и выбирают Play второй веб фремворк по удобству для Scala и не нативный для Scala. Так что вполне вероятно что сложность языка(его внутрених библиотек) умноженная на сложность библиотеки(аля lift) — очень сложное нечто. Сам я достаточно просто пишу средние проекты на Scala, но переиспользовать чужие библиотеки не решаюсь.
Одна возможность создавать почти нативный DSL говорит о том что язык выучить невозможно т.к. это бесконечное число языков…
Что тут можно сказать. Scala нужно знать, писать на ней, и внедрять )
Очень интересно, но я не очень понял по каким свойствам вы классифицировали. Неужели только по оканчанию и слову целиком(при этом получилась такая точность 92%)? Насколько я знаю надо так же использовать связь с предыдущими тегами посредством HMM/CRF или просто пред предсказание…
Очень смущает гипотеза о том что вероятность найти естественные и искусственные ошибки одинаковая. Методика их создания и процесс совершенно разные и потому вероятности тоже.
Спасибо, не знал что scala так стар. В википедии правда сказано что оба языка появились в 2003.
Думаю груви бы появился в любом случае, groovy это логичная надстройка над java, а scala совершенно новый язык в котором иногда даже сложно использовать код на java(разница в collection api)
Groovy — относительно неплохой язык скриптования для тех кто привык к Java. Это по сути немного syntax suggar которые так не хватает яве.
Но дается с очень большой ценой — производительность груви в среднем раз в 10 меньше чем явы и не важно байт код это или режим скрипта — все дело в мета программирование и количестве оберток которые нужно дернуть прежде чем добраться до реального метода.
Если говорить о Grails то его проблема в количестве зависимостей от сторонних библиотек, так что если понадобится добавить свою зависимость есть большая вероятность что она будет несовместима.
В общем лично я предпочитаю python и scala. Хотя возможно все началось c groovy.
Визуализация это хорошо, но только такая визуализация для реальных примеров совершенно бесполезна так как реальные примеры это вектора от размерности нескольких тысяч, а не двух и не трех. И там применяются совершенно другие техники визуализации.
Это неважно сложный алгоритм или простой. Это фундаментальная характеристика любой классификации — сколько похих примеров было удалено среди плохих из 100 случайных, сколько хороших было удалено среди хороших и т.п.
Думаю когда вам захочется с кем то сотрудничать вам придется предоставить эту информацию о точности вашего алгоритма.
у любой задачи классификации есть точноть, покрытие(http://en.wikipedia.org/wiki/Precision_and_recall). Вы наверное строили, настраивали свой алгоритм по этим метрикам.
Ну и наверно самый очевидный совет, который следует непосредственно из формулы:
в топе будут те новости которые ближе всего вашим самым близким друзьям — коэффициент affinity пропорционален частоте вашего общения а значит он растет, вес так же вероятно будет большой так как ваши близкие друзья вероятнее прокомментируют эту новость(что дает набольший weight) — т.е. это максимизация по обоим параметрам. Т.е. вывод надо просто быть собой )
ну думаю любой ос проект будет жить до тех пор пока не надоест последнему разработчику.
Я же дополняю ваше определение «opsensource == сделай для себя и поделись результатом с другими. » тем что поделился с другими ради строчки в резюме.
Одна возможность создавать почти нативный DSL говорит о том что язык выучить невозможно т.к. это бесконечное число языков…
Что тут можно сказать. Scala нужно знать, писать на ней, и внедрять )
Groovy это groovy, и если его и имеет смысл использовать то только в полном объеме.
Думаю груви бы появился в любом случае, groovy это логичная надстройка над java, а scala совершенно новый язык в котором иногда даже сложно использовать код на java(разница в collection api)
Но дается с очень большой ценой — производительность груви в среднем раз в 10 меньше чем явы и не важно байт код это или режим скрипта — все дело в мета программирование и количестве оберток которые нужно дернуть прежде чем добраться до реального метода.
Если говорить о Grails то его проблема в количестве зависимостей от сторонних библиотек, так что если понадобится добавить свою зависимость есть большая вероятность что она будет несовместима.
В общем лично я предпочитаю python и scala. Хотя возможно все началось c groovy.
Думаю когда вам захочется с кем то сотрудничать вам придется предоставить эту информацию о точности вашего алгоритма.
у любой задачи классификации есть точноть, покрытие(http://en.wikipedia.org/wiki/Precision_and_recall). Вы наверное строили, настраивали свой алгоритм по этим метрикам.
в топе будут те новости которые ближе всего вашим самым близким друзьям — коэффициент affinity пропорционален частоте вашего общения а значит он растет, вес так же вероятно будет большой так как ваши близкие друзья вероятнее прокомментируют эту новость(что дает набольший weight) — т.е. это максимизация по обоим параметрам. Т.е. вывод надо просто быть собой )
Я же дополняю ваше определение «opsensource == сделай для себя и поделись результатом с другими. » тем что поделился с другими ради строчки в резюме.