Re[18]: Про кластеризацию - Алгоритмы

Здравствуйте, avpavlov, Вы писали:

A>А вот это хороший вопрос

На который должна бы отвечать статья, но поскольку её писал не пойми кто для не пойми кого, мы это, наверное, уже никогда не узнаем

Мне кажется, ты несколько необъективен

Я бы сказал, некоторая инерция сформированной точки зрения, в данном случае излишняя.

Мне кажется, основная проблема статьи в том, что она помещена не в тот форум. Это не базы данных, это дата-майнинг, а он ближе к Алгоритмам скорее. Ты пытался читать её как статью по БД, в результате чего увидел много чудной незнакомой терминологии и какую-то совершенно дикую для БД постановку задачи. И сделал вывод, что автор изобретает что-то непонятное наукообразное неизвестно зачем, в БД ничего не понимает и написал статью для галочки. Но это не проблема статьи, это просто другая область, не БД. Там другие задачи и другая терминология, это не автор изобрёл, это такой мейнстрим, просто в другой области. Верблюд это не горбатая лошадь, это здоровый верблюд.

Речь не о том, что статья прекрасная, я плохо знаю дата-майнинг и совсем не работал с WEKA.
Речь о том, что аргументированной критики пока не было, так как не было понимания о чём вообще статья.

SH>Речь о том, что аргументированной критики пока не было,

Как её можно критиковать, если тупо непонятно что и зачем они делают

Я могу не знать WEKA (хотя я знаю для чего она нужна), я могу не знать терминологию, но я бы прекрасно понял, с какой целью они скармливают данные и что ожидают/получают на выходе. Если бы там это было. Но там, как я уже писал выше, просто какие-то вырванные из контекста куски, которые почему-то названы "статья".

SH> так как не было понимания о чём вообще статья.

Так как это никуда негодная статья?

Здравствуйте, avpavlov, Вы писали:

A>Как её можно критиковать, если тупо непонятно что и зачем они делают

Да чего там непонятного-то?
Есть куча данных, есть алгоритмы кластеризации. Типичный алгоритм кластеризации работает с точками и расстояниями, всё понятно.

А теперь мы хотим чтобы наши точки были не простыми, а сложно-составными. Хотим исследовать типичные маршруты пользователей по сайту (навигация). Или маршруты в сети (между сайтами). Или маршруты по стране (база билетов, регистраций в гостиницах и т.п.). Или в крайнем случае по врачам, как в статье.

И выясняется что WEKA как она есть не готова к этому вызову. Что-то надо подкрутить. Нужно написать класс для вычисления расстояния между двумя такими точками, нужно ещё что-то, не разбирался в деталях. Вот всё это и делается.

Что и зачем описано в первых абзацах статьи, во введении.

SH>Да чего там непонятного-то?

Что они кластеризуют в случае с врачами? Врачей? Услуги? Посещения (=Врач+Услуги в конкретный день)?.

Опять же, интересные вещи, вроде как они применяют алгоритм Левенштайна (который сформулирован для строк) к списку объектов, опущены. Вся эта статья похожа на отписку

Здравствуйте, avpavlov, Вы писали:

A>Что они кластеризуют в случае с врачами? Врачей? Услуги? Посещения (=Врач+Услуги в конкретный день)?.

Прости, но мне кажется что ты невнимательно читаешь то, что я пишу.

Они кластеризируют _маршруты_.

Человек пришёл к терапевту, тот направил его на рентген, с результатами к терапевту, оттуда к хирургу, потом через две недели ещё раз к хирургу на осмотр и ещё через две недели снимают гипс, после чего выписывают.

Это типовой маршрут #1, озаглавленный "трещина или закрытый перелом небольшой тяжести".

Система позволяет вычленить N штук типовых маршрутов, посмотреть на исключительные случаи и т.п.

A>Опять же, интересные вещи, вроде как они применяют алгоритм Левенштайна (который сформулирован для строк) к списку объектов, опущены. Вся эта статья похожа на отписку

Статья не о том, как они круто майнили медицинскую базу и как много нового нашли при таких-то параметрах или при других параметрах.
Статья о том, как технически при помощи WEKA решать подобные задачи кластеризации. Что нужно в WEKA дописать, чтобы это работало.

Вариантов применения расстояния Левенштейна тут несколько. Можно считать различными символами виды врачей, и получим одну картинку. Можно уточнять до конкретных фамилий врачей и получим другую. Можно учитывать промежутки времени между посещениями, можно нет, можно с какой-то точностью. Можно как-то учитывать действия, производимые врачом.

Можно вообще сравнивать как-то иначе, не Левенштейном, важно, что сравниваются маршруты как целое, а не посещения/услуги/врачи.

Здравствуйте, SergH, Вы писали:

SH>Они кластеризируют _маршруты_.
SH>Человек пришёл к терапевту, тот направил его на рентген, с результатами к терапевту, оттуда к хирургу, потом через две недели ещё раз к хирургу на осмотр и ещё через две недели снимают гипс, после чего выписывают.
SH>Это типовой маршрут #1, озаглавленный "трещина или закрытый перелом небольшой тяжести".
SH>Система позволяет вычленить N штук типовых маршрутов, посмотреть на исключительные случаи и т.п.

Вот это все они должны были написать в специальном разделе, посвященном целям исследования. Кроме того, во введении необходимо было обосновать мотивацию самой работы, зачем она вообще нужна, для каких практических целей.

SH>Вариантов применения расстояния Левенштейна тут несколько. Можно считать различными символами виды врачей, и получим одну картинку. Можно уточнять до конкретных фамилий врачей и получим другую. Можно учитывать промежутки времени между посещениями, можно нет, можно с какой-то точностью. Можно как-то учитывать действия, производимые врачом.
SH>Можно вообще сравнивать как-то иначе, не Левенштейном, важно, что сравниваются маршруты как целое, а не посещения/услуги/врачи.

Вот это все в статье необходимо было описать. Рассмотреть разные варианты и обосновать, почему был выбран используемый подход.

Вообще, в статье нет никаких результатов. Ну использовали некоторый подход, так что получили в результате?! Этого нет, т.е. нет никаких результатов, не сформулированы цели работы, из описания совершенно невозможно понять суть работы. Т.е. статья -- полный треш и должна быть полностью переработана.

Я текстовой классификацией и дата майнингом занимаюсь и статьи по этому поводу рецензирую. В общем, кое-какой опыт имею в этой области. Заявляю, что там нет вообще никаких научных результатов. Работа написана плохо и с точки зрения результатов и содержания.

Здравствуйте, mefrill, Вы писали:

M>Вообще, в статье нет никаких результатов. Ну использовали некоторый подход, так что получили в результате?! Этого нет, т.е. нет никаких результатов, не сформулированы цели работы, из описания совершенно невозможно понять суть работы. Т.е. статья -- полный треш и должна быть полностью переработана.

M>Я текстовой классификацией и дата майнингом занимаюсь и статьи по этому поводу рецензирую. В общем, кое-какой опыт имею в этой области. Заявляю, что там нет вообще никаких научных результатов. Работа написана плохо и с точки зрения результатов и содержания.

Правильно. Нет никаких научных результатов.

Потому что это не _научная_ статья по дата-майнингу.
Это _технологическая_ статья по дата-майнингу. Автор описывает как именно на данной платформе реализовать такую-то технологию.

Нигде нет ни слова о его собственных результатах, о целях, которые он ставил при майнинге, о конкретных параметрах -- нет этого. Из этого не следует, что автор дурак, следует, что статья про что-то другое. Она про технологию. Кто хочет -- сможет применить, если ему надо.

Посмотрите немного шире.

Здравствуйте, SergH, Вы писали:

SH>Потому что это не _научная_ статья по дата-майнингу.
SH>Это _технологическая_ статья по дата-майнингу. Автор описывает как именно на данной платформе реализовать такую-то технологию.

Если он описывает технологию, то надо ее описывать. Надо описать библиотеку, для чего она предназначена и т.п. Это будет т.н. обзорная статья, тоже полезная вещь. Здесь этого не наблюдается.

Здравствуйте, mefrill, Вы писали:

SH>>Потому что это не _научная_ статья по дата-майнингу.
SH>>Это _технологическая_ статья по дата-майнингу. Автор описывает как именно на данной платформе реализовать такую-то технологию.

M>Если он описывает технологию, то надо ее описывать. Надо описать библиотеку, для чего она предназначена и т.п. Это будет т.н. обзорная статья, тоже полезная вещь. Здесь этого не наблюдается.

Я не спорю, что статья не очень хороша хотя бы потому что она как минимум очень короткая. При том, что написана научным стилем со всеми введениями, выводами и сложно-составными предложениями -- в неё просто кажется не помещается что-то существенное.

Но с точки зрения постановки задачи и структуры статья совершенно понятна.

— есть расширяемая платформа WEKA
— есть задачка кластеризации маршрутов — цепочек — сложно-составных данных
— "из коробки" WEKA эту задачу решить не позволяет, не умеет
— к счастью она расширяемая и мы можем дописать её так, так и вот так (тут находится собственно содержание статьи)
— после чего всё отлично работает

я не знаю, насколько актуально сейчас WEKA
я не знаю, насколько актуальна задачка кластеризации маршрутов
я не знаю, действительно ли WEKA не умеет это из коробки
я не знаю, насколько рассмотренный вопрос заслуживает статьи
и я не знаю, насколько хорошо предложенное решение

Поэтому я без проблем понял бы критику по этим направлениям. WEKA устарела уже сто лет, или задача эта никому не нужна никогда, или делают это совсем иначе, или есть стандартные средства, или код плохой, или о чём тут писать, там всё очевидно, вы ещё про 2+2 статью напишите -- ок.

Но пока критика идёт со стороны "почему у этого зверя нет хобота, у всех слонов должны быть хоботы". Это просто не слон, это собака, и это хорошо, что у неё нет хобота. И я не очень понимаю ситуацию, вроде какие-то очень простые вещи, которые должны быть понятны сразу, понимания не находят. Так сильна инерция? Не понятно.

Добрый день!

В первую очередь хотелось бы поблагодарить за потраченную на дискуссию время. Именно ради такого обсуждения и выбирался журнал RSDN. Можно было обратиться в более, скажем, академические журналы и не иметь при этом никакого feedback'a.

Во-вторых, большое спасибо SergH за ссылку на обсуждение. Я здесь гость редкий, а уж в ветку про шифрование точно никогда бы не заглянул.

Я постараюсь ответить на некоторые из возникших вопросов в одном посте (прошу прощения, если он получится длинным). Сразу замечу, что SergH отвечал на вопросы настолько точно, что мне остается лишь переписывать его посты

Действительно, некоторое недопонимание может быть вызвано тем, что статья по Data Mining, а не по базам данных. Никаких исследований в области БД (теории и/или практики) в данной статье, разумеется, нет.

1) По поводу путаницы с термином "цепочка". Если двое из трех отреагировавших на статью оказались в недоумении, значит, это моя вина и требуются пояснения. Действительно, когда речь идёт о "цепочке", мы говорим о некотором общем описании структуры данных: последовательность событий, фактов. Последовательность перехода по ссылке, последовательность визитов к врачу и т.д. Ни к какому понятию из теории БД этот термин в статье не применялся, т.к. находится на другом логическом уровне. Приведенная в статье структура БД (громко сказано: 2 таблички с FK) — лишь одна из возможных структур для хранения данных, отражающих эти "цепочки" (т.е. последовательность событий). Представьте себе, что вы ведете лог посещений сайта. Для каждой сессии есть SessionID и какие-то её характеристики (IP, время начала и пр), а также есть страницы посещенные в рамках этой сессии. ID сессий и их характеристики вы пишите в главную таблицу, а посещаемые страницы хранятся в подчиненной таблице. Хочется верить, что это пояснение никого не запутало окончательно.

2) "А зачем надо обрабатывать и кластеризовывать именно цепочки?". Здесь всё просто. Очень часто необходимая информация содержится в структуре. Простейший пример: предложение. Предложение (с запятыми, контекстом, порядком слов, кавычками и пр.) не есть просто набор слов и знаков пунктуации. Можно, конечно, рассматривать предложение как просто множество слов, но мы, вероятно, потеряем значимую информацию. Поэтому все чаще при обработке данных возникает необходимость учета их структуры. Аналогично и в данной работе: важно учесть последовательность услуг, их длительность, паузы между ними и т.д, а не только состав цепочки.

3) Сам алгоритм сравнения цепочек в статью не вошел, т.к. мне казалось, что специфика журнала больше ориентирована на вопросы реализации, чем на сами алгоритмы. Статья с описанием алгоритма написана довольно давно и пока нигде не опубликована. Если вдруг (несмотря на скептическое отношение к обсуждаемой статье) вы считаете, что методы сравнения таких цепочек будут интересны читателям журнала — я с большим удовольствием актуализирую статью.

Дискуссия бурно развивалась без меня и сейчас уже не очень ясно, какие вопросы отпали, а какие остались. Буду рад помочь разобраться, а также признать ошибки и неточности. Отмечу лишь, что сложно найти более точную формулировку для общего описания статьи:
SH>Статья о том, как технически при помощи WEKA решать подобные задачи кластеризации. Что нужно в WEKA дописать, чтобы это работало.

С уважением,
автор статьи "Технические особенности разработки программы кластеризации сложноструктурированных данных на базе платформы WEKA"

Здравствуйте, A.A.R., Вы писали:

Замечательно, что вы появились, мне кажется уже сам этот факт снимает половину вопросов.
Авторы остальных обсуждаемых статей не пришли, хотя начали получать обратную связь несколько раньше, видимо это снимает вопросы и про них.

Фидбэк получился, честно говоря, не очень... Не столько по теме статьи, сколько по пониманию читателями текстов. Может быть это тоже не лишнее, но обычно довольно обидно.

Очень рад, что понял вашу статью правильно.

AAR>3) Сам алгоритм сравнения цепочек в статью не вошел, т.к. мне казалось, что специфика журнала больше ориентирована на вопросы реализации, чем на сами алгоритмы. Статья с описанием алгоритма написана довольно давно и пока нигде не опубликована. Если вдруг (несмотря на скептическое отношение к обсуждаемой статье) вы считаете, что методы сравнения таких цепочек будут интересны читателям журнала — я с большим удовольствием актуализирую статью.

Если там нет слишком сложной математики и обсуждение этой статьи не огорчило вас слишком сильно -- присылайте. Публикуем всё подряд, как выясняется даже то, что не стоило бы, но с этим будем бороться. Кстати, я уже знаю, кого попрошу посмотреть

Надеюсь, mefrill найдёт время

Потому что своих экспертов по теме нету.

У нас основное это всё-таки сайт, журнал это его придаток и порождение. Это на многое влияет, например, можно заметить, что обсуждение пошло не после выпуска журнала, а после публикации текста на сайте. Потом, у нас нет форума по Data Mining-у, мне кажется ближе всего будут "Алгоритмы" и скорее всего статья окажется здесь. Так что посмотрите на форум, оцените уровень участников, читать и обсуждать будут именно они. Можно посмотреть близкие по темам статьи или ветки форумов, если такие есть. Если вас устраивает такая площадка -- присылайте. А журнал... Ну, наверное, кто-то и журнал читает

Здравствуйте, A.A.R., Вы писали:

AAR>1) По поводу путаницы с термином "цепочка". Если двое из трех отреагировавших на статью оказались в недоумении, значит, это моя вина и требуются пояснения. Действительно, когда речь идёт о "цепочке", мы говорим о некотором общем описании структуры данных: последовательность событий, фактов.

Вот так и надо было написать с самого начала. В разделе "Постановка задачи" необходимо было задачу поставить. Сначала сформулировать главную цель исследования, после чего разбить эту цель на несколько более частных и начать обсуждать возможные методы. Прежде всего, необходимо было построить математическую модель процесса. Если у Вас процесс -- это посещения врача пациентами, т.е. в качестве события выступает факт посещения, так об этом и напишите. После этого можно писать и о "цепочке событий", как о методе исследования взаимосвязи посещения пациентов поликлиники.

AAR>2) "А зачем надо обрабатывать и кластеризовывать именно цепочки?". Здесь всё просто. Очень часто необходимая информация содержится в структуре. Простейший пример: предложение. Предложение (с запятыми, контекстом, порядком слов, кавычками и пр.) не есть просто набор слов и знаков пунктуации. Можно, конечно, рассматривать предложение как просто множество слов, но мы, вероятно, потеряем значимую информацию. Поэтому все чаще при обработке данных возникает необходимость учета их структуры. Аналогично и в данной работе: важно учесть последовательность услуг, их длительность, паузы между ними и т.д, а не только состав цепочки.

Это самая важная часть работы, в которой содержаться основные положения. Этой части, таким образом, необходимо было посвятить львиную долю изложения. Самое важное здесь -- корректная математическая модель процесса. Я бы рассматривал атрибуты события как элементы векторного пространства событий, а последовательности (цепочки) событий -- как траектории в этом пространстве. Тогда многие вещи становятся яснее. Выбор дистанции Левенштейна здесь ничем не мотивирован, это плохо. Мне кажется, можно придумать другие хорошие методы. Кроме того, у Вас здесь почти десяток атрибутов, можно было бы придумать различные расстояния, отражающие разные цели исследования. Можно было бы брать различные проекции на какие-то координаты атрибутов, кластеризовать по ним и смотреть, что получится. Мне бы, например, было бы интересно посмотреть траектории с совпадающими началами и еще траектории с совпадающими концами. Тогда можно было бы попытаться понять, на чем обычно расходятся посещения и, наоборот, где они сходятся (может всех в конце-концов на УЗИ отправляют

).

AAR>3) Сам алгоритм сравнения цепочек в статью не вошел, т.к. мне казалось, что специфика журнала больше ориентирована на вопросы реализации, чем на сами алгоритмы. Статья с описанием алгоритма написана довольно давно и пока нигде не опубликована. Если вдруг (несмотря на скептическое отношение к обсуждаемой статье) вы считаете, что методы сравнения таких цепочек будут интересны читателям журнала — я с большим удовольствием актуализирую статью.

Для нормальной работы необходимо статью переписать. Прежде всего, составить план. Два самых важных раздела: формулировка целей работы и актуализация задач, и второй раздел -- обсуждение различных методов реализации и обоснование выбора конкретного метода. Это наиболее трудная часть работы, надо суметь придумать адекватную математическую модель исследуемого процесса. Первый раздел, введение, должен обосновывать необходимость самой задачи, ее актуальность. Когда в диссертации будете писать про актуальность, можно будет просто взять краткий реферат этого раздела. Четвертым разделом сделать описание выбранного инструмента реализации, зачем нужен, как обычно использовать. В пятом разделе описать проделанную работу и полученные результаты. В заключении написать резюме проделанной работы, в общем сказать о достигнутых результатах и о направлениях будущей работы. Вот, если бы была такая статья, всем сразу было бы все понятно и все бы только хвалили, а не ругали.

Спасибо на добром слове

Фидбэк самый что ни на есть нормальный. Выводов сразу несколько. Например, основные понятия надо описывать так, чтобы вопросов не было вообще ни у кого. И что перед отправкой статью в журнал, надо почитать этот журнал и оценить уровень и основную тематику журнала. А то я ведь действительно статью написал и отправил так, будто бы это не журнал RSDN довольно широкого профиля, а узконаправленный "Data mining: кластеризация цепочек разными способами". Не удивительно, что к ней возникли вопросы: для стороннего читателя (не занимавшегося всю жизнь кластеризацией цепочек в особо крупных размерах) статья и начинается с середины, и не дописана до конца. По меньшей мере цель статьи я должен был написать предельно ясно.

Понятно, что самое интересное — именно тему обсуждать. Но, видимо, для этого сначала придется научиться писать статьи

Обязательно пришлю, но время потребуется: вспомнить, что писал, и подправить.

Здравствуйте, SergH, Вы писали:

SH>Здравствуйте, A.A.R., Вы писали:

SH>Замечательно, что вы появились, мне кажется уже сам этот факт снимает половину вопросов.
SH>Авторы остальных обсуждаемых статей не пришли, хотя начали получать обратную связь несколько раньше, видимо это снимает вопросы и про них.

SH>Фидбэк получился, честно говоря, не очень... Не столько по теме статьи, сколько по пониманию читателями текстов. Может быть это тоже не лишнее, но обычно довольно обидно.

SH>Очень рад, что понял вашу статью правильно.

AAR>>3) Сам алгоритм сравнения цепочек в статью не вошел, т.к. мне казалось, что специфика журнала больше ориентирована на вопросы реализации, чем на сами алгоритмы. Статья с описанием алгоритма написана довольно давно и пока нигде не опубликована. Если вдруг (несмотря на скептическое отношение к обсуждаемой статье) вы считаете, что методы сравнения таких цепочек будут интересны читателям журнала — я с большим удовольствием актуализирую статью.

SH>Если там нет слишком сложной математики и обсуждение этой статьи не огорчило вас слишком сильно -- присылайте. Публикуем всё подряд, как выясняется даже то, что не стоило бы, но с этим будем бороться. Кстати, я уже знаю, кого попрошу посмотреть

Надеюсь, mefrill найдёт время

Потому что своих экспертов по теме нету.

SH>У нас основное это всё-таки сайт, журнал это его придаток и порождение. Это на многое влияет, например, можно заметить, что обсуждение пошло не после выпуска журнала, а после публикации текста на сайте. Потом, у нас нет форума по Data Mining-у, мне кажется ближе всего будут "Алгоритмы" и скорее всего статья окажется здесь. Так что посмотрите на форум, оцените уровень участников, читать и обсуждать будут именно они. Можно посмотреть близкие по темам статьи или ветки форумов, если такие есть. Если вас устраивает такая площадка -- присылайте. А журнал... Ну, наверное, кто-то и журнал читает

Спасибо за развернутый ответ. Сохранил в закладки. Точно пригодится.

я уже понял, что статья получилась "с середины" и это вызывает много вопросов.

Однако позволю себе целиком не согласиться со вторым абзацем (применительно к рассматриваемой статье). Дело в том (и это очень точно уловил SergH), что статья о другом. Не об алгоритме и его характеристиках, а о технических особенностях его реализации в рамках платформы WEKA. Я выбирал тему совершенно осознано, ориентируясь на то, что журнал/форум больше рассчитан на development, чем на алгоритмы. Видимо, здесь я и перегнул палку. Есть смысл говорить о том, что тема слишком узкая, а статья слишком маленькая и оттого непонятная. С этим я согласен. Но я не могу согласится, что в ней не хватает, например, мотивировки выбора дистанции Левенштейна. В конце концов, структура классов и бОльшая часть проблем связанных с их изменениями останутся прежними, даже если это будет какая-то другая функция расстояния. Обратите внимание, что ни один вывод не связан с дистанцией Левенштейна. Ключевой момент — сама структура данных, а не то, как считается расстояние между объектами.

Если позволите, я буду трактовать вашу критику следующим образом: "Тема статьи оказалась не очень понятной. Интересная статья могла бы получится, если писать о самом алгоритме и следовать следующим советам... [тут должен быть ваш пост]". С такой критикой я всецело бы согласился. В любом случае спасибо за отзыв. Если всё-таки статья о самом алгоритме получится — несомненно воспользуюсь советами.

P.S. Спорить с человеком, которому (вероятно) отдадут статью на проверку, наверное, была плохая идея.

Здравствуйте, mefrill, Вы писали:

M>Здравствуйте, A.A.R., Вы писали:

AAR>>1) По поводу путаницы с термином "цепочка". Если двое из трех отреагировавших на статью оказались в недоумении, значит, это моя вина и требуются пояснения. Действительно, когда речь идёт о "цепочке", мы говорим о некотором общем описании структуры данных: последовательность событий, фактов.

M>Вот так и надо было написать с самого начала. В разделе "Постановка задачи" необходимо было задачу поставить. Сначала сформулировать главную цель исследования, после чего разбить эту цель на несколько более частных и начать обсуждать возможные методы. Прежде всего, необходимо было построить математическую модель процесса. Если у Вас процесс -- это посещения врача пациентами, т.е. в качестве события выступает факт посещения, так об этом и напишите. После этого можно писать и о "цепочке событий", как о методе исследования взаимосвязи посещения пациентов поликлиники.

AAR>>2) "А зачем надо обрабатывать и кластеризовывать именно цепочки?". Здесь всё просто. Очень часто необходимая информация содержится в структуре. Простейший пример: предложение. Предложение (с запятыми, контекстом, порядком слов, кавычками и пр.) не есть просто набор слов и знаков пунктуации. Можно, конечно, рассматривать предложение как просто множество слов, но мы, вероятно, потеряем значимую информацию. Поэтому все чаще при обработке данных возникает необходимость учета их структуры. Аналогично и в данной работе: важно учесть последовательность услуг, их длительность, паузы между ними и т.д, а не только состав цепочки.

M>Это самая важная часть работы, в которой содержаться основные положения. Этой части, таким образом, необходимо было посвятить львиную долю изложения. Самое важное здесь -- корректная математическая модель процесса. Я бы рассматривал атрибуты события как элементы векторного пространства событий, а последовательности (цепочки) событий -- как траектории в этом пространстве. Тогда многие вещи становятся яснее. Выбор дистанции Левенштейна здесь ничем не мотивирован, это плохо. Мне кажется, можно придумать другие хорошие методы. Кроме того, у Вас здесь почти десяток атрибутов, можно было бы придумать различные расстояния, отражающие разные цели исследования. Можно было бы брать различные проекции на какие-то координаты атрибутов, кластеризовать по ним и смотреть, что получится. Мне бы, например, было бы интересно посмотреть траектории с совпадающими началами и еще траектории с совпадающими концами. Тогда можно было бы попытаться понять, на чем обычно расходятся посещения и, наоборот, где они сходятся (может всех в конце-концов на УЗИ отправляют

).

AAR>>3) Сам алгоритм сравнения цепочек в статью не вошел, т.к. мне казалось, что специфика журнала больше ориентирована на вопросы реализации, чем на сами алгоритмы. Статья с описанием алгоритма написана довольно давно и пока нигде не опубликована. Если вдруг (несмотря на скептическое отношение к обсуждаемой статье) вы считаете, что методы сравнения таких цепочек будут интересны читателям журнала — я с большим удовольствием актуализирую статью.

M>Для нормальной работы необходимо статью переписать. Прежде всего, составить план. Два самых важных раздела: формулировка целей работы и актуализация задач, и второй раздел -- обсуждение различных методов реализации и обоснование выбора конкретного метода. Это наиболее трудная часть работы, надо суметь придумать адекватную математическую модель исследуемого процесса. Первый раздел, введение, должен обосновывать необходимость самой задачи, ее актуальность. Когда в диссертации будете писать про актуальность, можно будет просто взять краткий реферат этого раздела. Четвертым разделом сделать описание выбранного инструмента реализации, зачем нужен, как обычно использовать. В пятом разделе описать проделанную работу и полученные результаты. В заключении написать резюме проделанной работы, в общем сказать о достигнутых результатах и о направлениях будущей работы. Вот, если бы была такая статья, всем сразу было бы все понятно и все бы только хвалили, а не ругали.

Здравствуйте, SergH, Вы писали:

SH>Здравствуйте, avpavlov, Вы писали:

A>>В разделе "Базы данных" тоже болтается парочка забавных статей из разряда "+1 к публикациям"

A>>http://rsdn.ru/forum/db/4714713.1.aspx

A>>http://rsdn.ru/forum/db/4713481.1.aspx

SH>Проблема в том, что такие статьи обычно написаны таким языком, что не специалисту трудно разобраться и найти концы. Автор употребляет какие-то слова по теме, уверенно составляет из них запутанные предложения и производит впечатление человека, который знает, что пишет.

SH>Специалист, читая статью, ищет существенную часть, пытается понять в чём же идея. И всю эту чепуху просматривает не читая, так как понимает, что идея не в этом. Не специалист плохо понимает, как должна бы выглядеть основная идея, поэтому вынужден продираться через все дебри.

SH>Вот например к обсуждаемой статье, про шифрование -- поскольку я примерно представляю себе, что будет являться алгоритмом шифрования, а что заведомо не будет, я все построения автора пропустил вплоть до "а теперь выполняем гаммирование". Прочитав это место я всё про автора и статью понял, ушло на это примерно пять минут. Редактору гораздо сложнее. И в области БД я, к сожалению, примерно в том же положении, что и редактор. Так что если вы в комментариях к статьям доступно объясните, в чем состоят ключевые проблемы -- может быть что-то изменится, если нет, то увы.

SH>Судя по тому, что написано в комментариях сейчас, там всё не так запущено, по крайней мере явной ереси нет. То есть статьи просто не интересны (похоже? поправь если я понял не правильно). Боюсь, что при нынешнем количестве статей отсеивать ещё и по этому параметру редакция не сможет. Да и технически не сможет -- для этого нужны профессиональные рецензенты, желающих на эту роль тоже оказывается не так много.
А в что не так? На то и форумы: почитают граждане статьи, сознательные (кто понял обо что речь, сделав усилие над собой, или сразу) поставят оценки и все довольны. Это же не конкурс красоты в конце концов — со временем ценность станет очевидной, даже удалять не надо.

	От:	SergH
	Дата:	03.05.12 10:35
	Оценка:

	От:	avpavlov
	Дата:	03.05.12 13:30
	Оценка:

	От:	SergH
	Дата:	03.05.12 13:51
	Оценка:

	От:	avpavlov
	Дата:	03.05.12 13:58
	Оценка:

	От:	SergH
	Дата:	03.05.12 14:08
	Оценка:

	От:	A.A.R.
	Дата:	04.05.12 11:19
	Оценка:

	От:	A.A.R.
	Дата:	05.05.12 10:23
	Оценка:

	От:	A.A.R.
	Дата:	05.05.12 12:11
	Оценка:

	От:	Аноним
	Дата:	06.05.12 00:29
	Оценка: