«После этого документ представляется в виде вектора, где i-тый элемент это мера вхождения i-того слова словаря в документ. Это может быть + 1 или -1 в зависимости от того, входит ли слово в документ или нет»
Я к сожалению не вникала в то как именно работает svmlight, но есть подозрение что структуры там частино одинаковые. это значит, что вы передаете туда компактный вектор:
7:6 11:6.56 19:45.56 25:0.5. то есть только те значения, которые не равны нулю.
Если же вы будете делать как у вас написано в статье +1/-1, то у вас получится вектор с кучей -1 вместо нулей. и вместо того чтобы передавать вектор из 500 значений, вы будете передавать вектор из 47тысяч. Это как бы совсем нелогично и для данного типа классификации не используется. И поэтому я подумала, что либо вы не совсем точно описали в статье что вы хотите сказать этим «i-тый элемент = +1/-1», либо я вас просто не поняла.
Кстати, только что заметила, что например у вас в примере очень разрозненные данные. 19 элемент — 45, 25 — меньше 1! В данном случае просто необходимо делать нормализацию, скалирование. Об этом кстати тоже написано в той статье по моей ссылке.
да, это так и делается в svm. используются ядра более высокого порядка.
но как уже выше было сказано при очень большом количестве атрибутов и относительно маленьком количестве документов линейное ядро показывает такие же результаты
лучше использовать libSVM так как она поддерживает мультиклассовость — то есть входной файл содержит не +1/-1, а номер класса для каждого документа, который вы хотите классифицировать. таким образом вам не нужно 80 классификаторов. а всего лишь 2 файла — для обучения и для тестов
далее, неразумно в качестве свойста использовать +1/-1 для классификации документов. так как у вас из обычного очень разреженного вектора из например 500 значений (500 features), получится вектор из полного списка (47тыс в вашем примере* количество оцениваемых свойств) значений, большая часть которых просто неинформативна — забита -1. или я вас в этом моменте неправильно поняла?
и по поводу того, какие свойста имеет смысл оценивать в документе — есть так называемые distributional features, которые как раз таки используются для классификации текстов. и если вы знаете о них, то стоило в статье их и описать и назвать своими названиями, можно даже с формулами :) а не обобщенно «доля слова в документе» и т.п.
но в целом приятно было встретить на хабре данную статью.
один раз кликнешь — узнаешь о хоткее. второй раз за ним уже лезть не будешь
а программа удобней тем, что она одна, а настройки у каждого софта в своем места
да, так и есть. shading хорошо работает на границах материалов, а внутри мы получаем в принципе одно направление, которое тем не менее достаточно случайное, так как зависит от шума еще
в текстуре плотность тканей. она не шифрована в RGB, просто эту плотность можно потом дальнейшем как угодно интерпретировать и получать необходимые значения на выходе.
возьмем например плотность мяса и плотность кости — на границе будет большая разница, то есть большой градиент (его длина), внутри одной сущности, например мяса, градиент тоже будет из-за шумов, но весьма маленький. И этот градиент и есть наша нормаль
так же по коду можно заметить, что берутся не просто соседние воксели, а нечто усредненное из всех 9 вокселей, окружающих искомую точку
режим рендеринга изоповерхностей лишь один из режимов визуализации, причем даже не основной
и вы не построите векторную графику в данной области, здесь физическая суть другая )
мне с ним приходилось иметь дело долгое время. и вот насчет несвязанных друг с другом изображений могу поспорить :) если взять отдельный обычный дайком файл, то raw данные которые там хранятся непосредственно описаны в предыдущих тегах. и они не могут быть никак не связанны. это не имеет смысла
так же это не имеет отношения к текущей статье :)
и как раз таки из-за того, что этот rayPosition зависит от скорости прохода, при большой скорости и большом шаге мы может пропустить точное положение изоповерхности и получаются такие вот круги, о которых я в конце упомянула. и которые надеюсь еще рассмотреть в следующей статье
почему дата возврата обязательна для поиска?
лучше бы оригинал запостили. тут думаю все английский понимают на таком уровне
Я к сожалению не вникала в то как именно работает svmlight, но есть подозрение что структуры там частино одинаковые. это значит, что вы передаете туда компактный вектор:
7:6 11:6.56 19:45.56 25:0.5. то есть только те значения, которые не равны нулю.
Если же вы будете делать как у вас написано в статье +1/-1, то у вас получится вектор с кучей -1 вместо нулей. и вместо того чтобы передавать вектор из 500 значений, вы будете передавать вектор из 47тысяч. Это как бы совсем нелогично и для данного типа классификации не используется. И поэтому я подумала, что либо вы не совсем точно описали в статье что вы хотите сказать этим «i-тый элемент = +1/-1», либо я вас просто не поняла.
Кстати, только что заметила, что например у вас в примере очень разрозненные данные. 19 элемент — 45, 25 — меньше 1! В данном случае просто необходимо делать нормализацию, скалирование. Об этом кстати тоже написано в той статье по моей ссылке.
но как уже выше было сказано при очень большом количестве атрибутов и относительно маленьком количестве документов линейное ядро показывает такие же результаты
далее, неразумно в качестве свойста использовать +1/-1 для классификации документов. так как у вас из обычного очень разреженного вектора из например 500 значений (500 features), получится вектор из полного списка (47тыс в вашем примере* количество оцениваемых свойств) значений, большая часть которых просто неинформативна — забита -1. или я вас в этом моменте неправильно поняла?
очень рекомендую к прочтению в этом контексте данную статью — A Practical Guide to Support Vector Classication
и по поводу того, какие свойста имеет смысл оценивать в документе — есть так называемые distributional features, которые как раз таки используются для классификации текстов. и если вы знаете о них, то стоило в статье их и описать и назвать своими названиями, можно даже с формулами :) а не обобщенно «доля слова в документе» и т.п.
но в целом приятно было встретить на хабре данную статью.
а программа удобней тем, что она одна, а настройки у каждого софта в своем места
не по теме, но на вашем профиле хабр что-то заглючило 0_о
возьмем например плотность мяса и плотность кости — на границе будет большая разница, то есть большой градиент (его длина), внутри одной сущности, например мяса, градиент тоже будет из-за шумов, но весьма маленький. И этот градиент и есть наша нормаль
так же по коду можно заметить, что берутся не просто соседние воксели, а нечто усредненное из всех 9 вокселей, окружающих искомую точку
при большом шаге мы можем проскочить точное положение изоповерхности. рисуется все одинаково.
и вы не построите векторную графику в данной области, здесь физическая суть другая )
возможно мы просто говорим с вами о разных вещах или об одном и том же, но с разных позиций
так же это не имеет отношения к текущей статье :)