Это ваша задача доказать мне, что ваш метод работает. В научном методе и других областях знания (судебная система, напр) есть специальный термин для этого--burden of proof, бремя доказательства. А вы делаете типичную ошибку--перекладываете это бремя на меня (читателя).
Я постарался привести простой доступный пример, когда кустарный метод дает систематическую ошибку, хотя выглядит очень даже ничего. Вам я ничего не приписывал. И систематическая ошибка может присутствовать в вашем кустарном методе сравнения деревьяв. Пока вы не докажете обратное, графику верить нельзя.
Вот еще немного критики, раз старая не понравилась вам:
1.
Да, метод «собственный» сравнения деревьев, но он простой и ясно показывает, что нужно. Мне не нужно для элементарных вещей изучать что-то еще, что не дает такого же четкого результата.
Пример: мы хотим сравнить две строки--посчитать расстояние между ними (это могут быть как раз последовательности нуклеотидов). Строки «ABCA» и «ACBA». Вы придумаете кустарный способ, и будете считать число удалений и число вставок букв в певрую строку, чтоб получить вторую. Получите расстояние 2 (удалить B слева от C, вставить B справа от C). А есть нормальный алгоритм сравнения--расстояние Левенштайна. Он даст расстояние, равное 1 (поменять местами B и C) (в ДВА раза меньше, чем ваше кустарное). Алгоритм надо выбирать в зависимости от задачи, и для сравнения генов используется как раз расстояние Левенштайна. То есть ваш кустарный способ будет давать систематическую ошибку вплоть до 2 раз.
Так же и с деревьями--ваш кустарный способ может давать систематическую ошибку в несколько раз, и ваш график в конце статьи сейчас можно смело выбрасывать.
2. Важное замечание. Ваш график ошибок не показывает, что ваш метод работает правильно, а TASLT--неправильно. Он показывает, что два метода дают разные результаты. И, поскольку TASLT--код проверенный, свободный, результаты опубликованы во многих журналах, прошли peer review, я, как непредвзятый читатель, скорее подумаю, что это ВАШ метод неправильный и ошибочный. Может, у вас просто баги в коде. То есть вы делаете принципиально неправильный вывод из этого графика.
Удивительно то, что вы называете дисперсию «мутным индексом», а потом всегда говорите о соотношении сигнал-шум, притом что эта величина измеряется как раз через мутные индексы:
1. надо взять сигнал (случайный процесс-- только для них задается соотношение сигнал-шум. ваши деревья, кстати, тоже можно считать случайным процессом)
2. посчитать спектральную плотность мощности (напр, посчитать автокорреляционную функцию, посчитать от нее преобразование Фурье)
3. мощность полезных гармоник разделить (сигнал) поделить на мощность шума.
А в частном случае соотношение сигнал-шум как раз считается через дисперсию сигнала.
1. опыт, видимо, неудачный. Для этого статьи и рецензирование и нужны--чтобы отсеивать неподходящий материал. Вместо того, чтоб продолжать писать статьи на хабр в свободное время, лучше вам подумать, что именно не так в вашем подходе. И если уж совсем интересно, найти профессора в Европе/США (по вашей теме, computational biology, computational genetics), подать заявку на PhD и поработать full-time 4 года над этой темой.
2. Критика иногда не касается сути, но в основном касается. Рецензенты, конечно, тоже разные бывают. Ну и характер замечаний разный--major, minor, critical.
3. Ваш анализ результатов меня, даже как дилетанта, не устраивает:
серьезные замечания:
а. детерминистический подход в принципе не может работать--во всех генах присутствуют случайные мутации, это одна из основ эволюции. Поэтому стохастический подход явно лучше детерминистического.
б. Сравнение двух деревьев--это стандартная задача. Вы их сравниваете явно кустарным способом. Потрудитесь поискать хоть что-нибудь об этой теме.
мелочи:
в. «распределениями вероятности, оценками смещения, дисперсии и т.п. мутными индексами и ничего не говорящими коэффициентами» Если вам, как программисту, не читали основы теории вероятности--то это ваши проблемы. Почитайте курс лекций какой на досуге (курсера, напр), и научитесь разбираться в мутных индексах.
г. у вас нет ни одной (!) ссылки на научные статьи. Это не вызывает доверия--может, вы вообще в теме не разбирались.
4. если результат The All-Species Living Tree слабоват, то обычно появляются статьи с критикой--это же выгодно критикующим (к ним сразу пристальное внимание). Она вполне может быть очень жесткой (пример из физики, правда).
В общем, я считаю, что вы напрасно тратите свое время и время людей, которых привлекаете. И даже если ваши результаты будут чего-то достойны, о них никто не узнает и на них никто не обратит внимания. Кроме того, глупо думать, что если вы хороший программист, то легко войдете в генетику и расскажете тысячам пацанов, что они 30 лет были неправы, и вообще все разложите по полочкам (так называемый «синдром программиста»).
1. цели неизмеримы. Лучше если б это было «написать 2 статьи за 2 года/привлечь 100500 млн инвестиций за 2 года»
2. цели нереальны. «изучить геном прокариот, построить дерево происхождения видов»--это то, чем занимаются тысячи ученых по всему миру много лет. Вы можете быть даже умнее их, но у вас нет столько времени (даже если взять всю вашу жизнь, без сна и еды). И у вас нет экспертизы и опыта. И, скорее всего, вы не умнее их большей части. И если вам кажется, что они просто дурачки, и не замечают каких-то очевидных подходов, то, скорее всего, это не так.
Это как нисходящее проектирование: вы начинаете с более высокого уровня абстракции, потом переходите к низкому. Так легче воспринимать статью--сразу знаешь, куда автор ведет, чего ожидать; сразу видишь за лесом деревья; легче выделять структурные блоки, выделять важное в статье, можно сразу понять, что статья неинтересна, и т.п.
В научных статьях обычно 3 уровня абстракции: abstract, introduction, сама статья.
Я считаю, что вам надо проконсультироваться со специалистами в этой области, притом обязательно с теми, у которых есть публикации в рецензируемых международных журналах по этой теме. Вероятно, вы услышите немало критики. Еще лучше попробовать опубликовать статью в рецензируемом международном журнале--вы тоже, вероятно, услышите немало критики. Я считаю, это может очень помочь в расстановке приоритетов, оценке собственных ресурсов и качества результатов. Так вы сэкономите свое время и время людей, которых хотите привлечь к проекту.
Кроме того, мне кажется, вашей основной задачей должна быть публикация статей в международных профильных журналах--иначе никто из отрасли о ваших результатах не узнает, а те, кто узнает--не поверят (потому что результаты не прошли peer review).
Я считаю правильным, когда простые вещи делаются просто, а сложные — пропорционально сложно.
Это шикарное замечание.
В добавок отмечу, что показатель качества технологии--это кривая обучения (что вы можете сделать в зависимости от потраченного времени на обучение). Она должна быть в крайнем случае линейной, в лучшем случае идти резко вверх, а потом плавно повышаться (то есть большинство вещей делаются просто, остальные--пропорционально сложно).
У WPF же (и всех продуктах Microsoft, которые они не копируют из opensource )--steep learning curve. То есть пока вы не прочитаете 1000 страниц книжки, ничего вменяемого (правильно) сделать не сможете. Это значит, что в технологии множество hidden dependencies, высокая связность, она не модульная, не расширяемая (и ASP.NET MVC по всем этим пунктам лучше WPF, потому что скопирован с RoR).
Хочу обратить внимание, что эти два подхода слежения за изменениями--это по сути разновидности Pull и Push парадигм работы с данными (так же как и классический http/web-sockets).
Вы правы. Поэтому лучшее решение, на мой взгляд, это
а. пользоваться гугловским соглашением о полных путях
б. написать еще один макрос/плагин/консольное приложение :-), типа «UpdateDefineGuardsInProject», который сможет обновить все define guards в проекте в соответствие с текущими путями
в. в новых файлах вызывать ваше представленное расширение, генерировать начальный guard
г. при перемещении/переименовании файлов вызывать второй плагин
Притом в вашем расширении можно просто будет вызвать часть кода из UpdateDefineGuardsInProject, при определенной архитектуре.
Имхо, уникальный идентификатор со случайными цифрами выглядит ужасно. Google C++ Style guide рекомендует генерировать его по полному пути к файлу в проекте (заменяя слэши на подчеркивания)--и я с ним согласен, так define guards выглядят намного читабельнее и удобнее.
1. Шаблоны: книжка Gang of Four--1994 год, MVC--1979
2. базы данных: SQL--1970
3. принципы проектирования: шикарная книжка Structure and interpretation of Computer programs--1984
4. ООП: Simula--1967 (это такой язык, где уже есть все плюшки ООП. серьезно, даже сборка мусора и виртуальные методы)
5. основные принципы современных языков и операционных систем: С--1972, С++ 1983, POSIX--1988
1.а. сбои в электронике (не рассчитанной на такие ускорения)
1.б. сбои в ПО, не рассчитанном на такие ускорения (как минимум, ПО надо было тестировать с учетом таких экстремальных условий--то есть экстремальных численных значений датчиков, например) Например, если вы выбираете положение направляющих в зависимости от скорости ветра, то вам надо как-то сглаживать текущее значение скорости. Если вы это будете делать плохо, то в условиях урагана появятся численные ошибки сглаживания, расчета положения направляющих и ПО выведет из строя сервоприводы (я не знаю, так ли работает этот робот, но идея, думаю, понятна)
1.в. сбои в механизмах (приводы направляющих, разрыв кабелей)
programmers.stackexchange.com/questions/21987/how-is-intellij-better-than-eclipse
java.dzone.com/articles/why-idea-better-eclipse
habrahabr.ru/post/112749/
Лично я с ними согласен и c уверенностью рекомендую вам Idea :-)
Первый из обзоров
1.
Пример: мы хотим сравнить две строки--посчитать расстояние между ними (это могут быть как раз последовательности нуклеотидов). Строки «ABCA» и «ACBA». Вы придумаете кустарный способ, и будете считать число удалений и число вставок букв в певрую строку, чтоб получить вторую. Получите расстояние 2 (удалить B слева от C, вставить B справа от C). А есть нормальный алгоритм сравнения--расстояние Левенштайна. Он даст расстояние, равное 1 (поменять местами B и C) (в ДВА раза меньше, чем ваше кустарное). Алгоритм надо выбирать в зависимости от задачи, и для сравнения генов используется как раз расстояние Левенштайна. То есть ваш кустарный способ будет давать систематическую ошибку вплоть до 2 раз.
Так же и с деревьями--ваш кустарный способ может давать систематическую ошибку в несколько раз, и ваш график в конце статьи сейчас можно смело выбрасывать.
2. Важное замечание. Ваш график ошибок не показывает, что ваш метод работает правильно, а TASLT--неправильно. Он показывает, что два метода дают разные результаты. И, поскольку TASLT--код проверенный, свободный, результаты опубликованы во многих журналах, прошли peer review, я, как непредвзятый читатель, скорее подумаю, что это ВАШ метод неправильный и ошибочный. Может, у вас просто баги в коде. То есть вы делаете принципиально неправильный вывод из этого графика.
1. надо взять сигнал (случайный процесс-- только для них задается соотношение сигнал-шум. ваши деревья, кстати, тоже можно считать случайным процессом)
2. посчитать спектральную плотность мощности (напр, посчитать автокорреляционную функцию, посчитать от нее преобразование Фурье)
3. мощность полезных гармоник разделить (сигнал) поделить на мощность шума.
А в частном случае соотношение сигнал-шум как раз считается через дисперсию сигнала.
2. Критика иногда не касается сути, но в основном касается. Рецензенты, конечно, тоже разные бывают. Ну и характер замечаний разный--major, minor, critical.
3. Ваш анализ результатов меня, даже как дилетанта, не устраивает:
серьезные замечания:
а. детерминистический подход в принципе не может работать--во всех генах присутствуют случайные мутации, это одна из основ эволюции. Поэтому стохастический подход явно лучше детерминистического.
б. Сравнение двух деревьев--это стандартная задача. Вы их сравниваете явно кустарным способом. Потрудитесь поискать хоть что-нибудь об этой теме.
мелочи:
в. «распределениями вероятности, оценками смещения, дисперсии и т.п. мутными индексами и ничего не говорящими коэффициентами» Если вам, как программисту, не читали основы теории вероятности--то это ваши проблемы. Почитайте курс лекций какой на досуге (курсера, напр), и научитесь разбираться в мутных индексах.
г. у вас нет ни одной (!) ссылки на научные статьи. Это не вызывает доверия--может, вы вообще в теме не разбирались.
4. если результат The All-Species Living Tree слабоват, то обычно появляются статьи с критикой--это же выгодно критикующим (к ним сразу пристальное внимание). Она вполне может быть очень жесткой (пример из физики, правда).
В общем, я считаю, что вы напрасно тратите свое время и время людей, которых привлекаете. И даже если ваши результаты будут чего-то достойны, о них никто не узнает и на них никто не обратит внимания. Кроме того, глупо думать, что если вы хороший программист, то легко войдете в генетику и расскажете тысячам пацанов, что они 30 лет были неправы, и вообще все разложите по полочкам (так называемый «синдром программиста»).
1. цели неизмеримы. Лучше если б это было «написать 2 статьи за 2 года/привлечь 100500 млн инвестиций за 2 года»
2. цели нереальны. «изучить геном прокариот, построить дерево происхождения видов»--это то, чем занимаются тысячи ученых по всему миру много лет. Вы можете быть даже умнее их, но у вас нет столько времени (даже если взять всю вашу жизнь, без сна и еды). И у вас нет экспертизы и опыта. И, скорее всего, вы не умнее их большей части. И если вам кажется, что они просто дурачки, и не замечают каких-то очевидных подходов, то, скорее всего, это не так.
В научных статьях обычно 3 уровня абстракции: abstract, introduction, сама статья.
Кроме того, мне кажется, вашей основной задачей должна быть публикация статей в международных профильных журналах--иначе никто из отрасли о ваших результатах не узнает, а те, кто узнает--не поверят (потому что результаты не прошли peer review).
Это шикарное замечание.
В добавок отмечу, что показатель качества технологии--это кривая обучения (что вы можете сделать в зависимости от потраченного времени на обучение). Она должна быть в крайнем случае линейной, в лучшем случае идти резко вверх, а потом плавно повышаться (то есть большинство вещей делаются просто, остальные--пропорционально сложно).
У WPF же (и всех продуктах Microsoft, которые они не копируют из opensource )--steep learning curve. То есть пока вы не прочитаете 1000 страниц книжки, ничего вменяемого (правильно) сделать не сможете. Это значит, что в технологии множество hidden dependencies, высокая связность, она не модульная, не расширяемая (и ASP.NET MVC по всем этим пунктам лучше WPF, потому что скопирован с RoR).
а. пользоваться гугловским соглашением о полных путях
б. написать еще один макрос/плагин/консольное приложение :-), типа «UpdateDefineGuardsInProject», который сможет обновить все define guards в проекте в соответствие с текущими путями
в. в новых файлах вызывать ваше представленное расширение, генерировать начальный guard
г. при перемещении/переименовании файлов вызывать второй плагин
Притом в вашем расширении можно просто будет вызвать часть кода из UpdateDefineGuardsInProject, при определенной архитектуре.
2. базы данных: SQL--1970
3. принципы проектирования: шикарная книжка Structure and interpretation of Computer programs--1984
4. ООП: Simula--1967 (это такой язык, где уже есть все плюшки ООП. серьезно, даже сборка мусора и виртуальные методы)
5. основные принципы современных языков и операционных систем: С--1972, С++ 1983, POSIX--1988
И так далее
1.а. сбои в электронике (не рассчитанной на такие ускорения)
1.б. сбои в ПО, не рассчитанном на такие ускорения (как минимум, ПО надо было тестировать с учетом таких экстремальных условий--то есть экстремальных численных значений датчиков, например) Например, если вы выбираете положение направляющих в зависимости от скорости ветра, то вам надо как-то сглаживать текущее значение скорости. Если вы это будете делать плохо, то в условиях урагана появятся численные ошибки сглаживания, расчета положения направляющих и ПО выведет из строя сервоприводы (я не знаю, так ли работает этот робот, но идея, думаю, понятна)
1.в. сбои в механизмах (приводы направляющих, разрыв кабелей)
2. переворачивание поплавка (см. картинку)
3. запутывание троса
4. разрыв троса
5. и еще миллион штук.
В общем, то, что робот выжил--это офигенно.