Генотип, ко-факторы, исход, как анализировать? |
Здравствуйте, гость ( Вход | Регистрация )
Генотип, ко-факторы, исход, как анализировать? |
15.06.2014 - 14:09
Сообщение
#1
|
|
Группа: Пользователи Сообщений: 24 Регистрация: 11.06.2014 Пользователь №: 26460 |
Здравствуйте, коллеги! Прошу помощи в анализе данных.
Задача исследования - оценить связь между генотипом (15 SNP), "промежуточным фенотипом" (параметры биохимии, иммунологии и др.), исходом (ЗНО есть/нет). Существующий сервис "SNPstats" (http://bioinfo.iconcologia.net/SNPstats_web) выдает отношения шансов, "adjustet by фактор1+фактор2+...", используется при этом "logistic regression models" (то есть, логит-регрессию?). Хотелось бы поточнее узнать, что значит "adjusted by". Кроме того, в данной програме остается "за кадром", какой из факторов является ведущим. Возможно, есть какие то альтернативные методы анализа, позволяющие оценить вклад конкретных факторов? Посоветуйте, пожалуйста. Заранее благодарен. И есть ещё один вопрос: По разным SNP имеется разное количество генотипированных, как и разное количество известных значений по каждому из "промежуточных фенотипов" и исходов. То есть, грубо говоря, выборки по каждому из SNP перекрываются только отчасти. Нужно ли в этом случае рассматривать проблему множественных сравнений? Спасибо! |
|
28.09.2014 - 19:44
Сообщение
#2
|
|
Группа: Пользователи Сообщений: 219 Регистрация: 4.06.2013 Из: Тверь Пользователь №: 24927 |
Коды, генерируемые программой, можно преобразовать в коды R или SAS и в другие форматы.
Сообщение отредактировал anserovtv - 28.09.2014 - 21:05 |
|
29.09.2014 - 14:00
Сообщение
#3
|
|
Группа: Пользователи Сообщений: 24 Регистрация: 11.06.2014 Пользователь №: 26460 |
anserovtv
Большое Вам спасибо за первую ссылочку (до второй пока не добрался, рабочая сеть не позволяет)! Наглядно и доступно представлен алгоритм "классического" random forests. Однако, автор верно заметил, что классический вариант RF "не переваривает" анализ смешанных количественных и категориальных данных, в этом случае необходим cforest. Коллеги, если кто-то натыкался на пример использования cforest, будьте добры, поделитесь! Сообщение отредактировал don - 29.09.2014 - 14:02 |
|
29.09.2014 - 15:07
Сообщение
#4
|
|
Группа: Пользователи Сообщений: 116 Регистрация: 20.02.2011 Пользователь №: 23251 |
anserovtv Большое Вам спасибо за первую ссылочку (до второй пока не добрался, рабочая сеть не позволяет)! Наглядно и доступно представлен алгоритм "классического" random forests. Однако, автор верно заметил, что классический вариант RF "не переваривает" анализ смешанных количественных и категориальных данных, в этом случае необходим cforest. Коллеги, если кто-то натыкался на пример использования cforest, будьте добры, поделитесь! C кодом cforest ответил Вам в личку. Не совсем понятно, зачем Вам рассматривать каждое дерево по отдельности и что-то интерпретировать, ведь каждое дерево имеет свою индивидуальную структуру и свой прогноз, а конечный результат сводится к голосованию за результат, который дает большинство деревьев. Можно вывести структуру каждого из 100 (как в Вашем случае) деревьев, но потом все это интерпретировать будет заданием очень непростым и вряд ли полезным. После того, как cforest выдает Вам наиболее значимые предикторы на уровне СНИПов, Вам интересно ведь посмотреть какой генотип ассоциируется с риском развития заболевания или имеет наоборот протективный эффект. Для этого очень удобно использовать комбинацию методов: случайный лес, MDR, логистическая регрессия. Случайный лес - в качестве фильтра наиболее важных СНИПов, MDR - оценка взаимодействия СНИПов и оценка каждого из генотипов, а также их комбинаций, нахождения типа связи между СНИПами. Лог. регрессия - финальный этап, создание модели, которая включает лишь факторы, которые определились как важные из первых двух методов, валидация результатов. P.S. В Вашей базе - что прогнозируется? nat или cr? Если cr - получается, что исследуете очень редкое заболевание? Сообщение отредактировал TheThing - 29.09.2014 - 15:12 |
|
29.09.2014 - 21:09
Сообщение
#5
|
|
Группа: Пользователи Сообщений: 24 Регистрация: 11.06.2014 Пользователь №: 26460 |
P.S. В Вашей базе - что прогнозируется? nat или cr? Если cr - получается, что исследуете очень редкое заболевание? Прогнозируется cr (некое заболевание). Это урезанная база, здесь cr 24 из 165, в оригинальной базе 55 из 439. Но в оригинальной базе 45 предикторов, включая 13 снипов, и громадное количество пропусков в некоторых из них (более 50%). Поэтому пришлось несколько сузить масштабы анализа, убрав часть предикторов. Возможно, это неверно. Поправьте меня, если я не прав. |
|
29.09.2014 - 21:41
Сообщение
#6
|
|
Группа: Пользователи Сообщений: 116 Регистрация: 20.02.2011 Пользователь №: 23251 |
Прогнозируется cr (некое заболевание). Это урезанная база, здесь cr 24 из 165, в оригинальной базе 55 из 439. Но в оригинальной базе 45 предикторов, включая 13 снипов, и громадное количество пропусков в некоторых из них (более 50%). Поэтому пришлось несколько сузить масштабы анализа, убрав часть предикторов. Возможно, это неверно. Поправьте меня, если я не прав. Мне сложно Вас поправить, поскольку я практически не знаю дизайна исследования, целей, задач и т.д. - если Вы решили урезать массив, значит на то были причины. Посмотрел немного Вашу базу, прикольная (в том смысле, что собрано столько материала!!). Однако, например, первые три СНИПа IL1b_rs1143634, IL2_rs2069762, IL4_rs2070874, а точнее распределение их генотипов в группах больных и здоровых (cr) не позволяет их нормально анализировать, поскольку наблюдается или perfect separation (то есть классы больных и здоровых идеально расходятся и большинство алгоритмов сходит с ума поэтому) или алгоритм просто не сходится (did not converge), поскольку присутствуют не все комбинации генотипов в базе данных (может быть потому что Вы ее сократили) - это беда всех параметрических методов, в том числе и логит-регрессии(curse of dimensionality). Что-то нужно думать с базой.. |
|
30.09.2014 - 06:55
Сообщение
#7
|
|
Группа: Пользователи Сообщений: 24 Регистрация: 11.06.2014 Пользователь №: 26460 |
...если Вы решили урезать массив, значит на то были причины. Представьте следующую картину. У нас есть большая база, порядка полутора тысяч чел., в которой собраны наблюдения по разным параметрам, но с разной степенью "перекрывания" данных между ними. Нам известны: 1) генотипы по нескольким снипам для 400 чел., 2) параметр Х1 для 200 чел, из которых со снипами "перекрывается" 150, 3) параметр Х2 для 300 чел, из которых со снипами перекрывается 250, а с Х1 - только 15 4) параметр Х3 для 100 чел, из которых все перекрываются со снипами, но с Х2 и Х1 только 10-20. 5) и таких параметров еще десяток, с разной степенью "перекрывания" с другими. 6) для каждого из пациентов известен статус по болезни. Чтобы лучше понять, о чем идет речь, приложу файл с большой первоначальной базой (don_base111.txt). Причина урезания базы заключается в попытке отобрать тех пациентов, для которых известно как можно больше параметров. Делается это из предположения, что для адекватного анализа RF пропущенные значения конечно могут быть, но должны быть сведены к какому то разумному пределу (не более 30 %). То есть, до урезания базу можно представить так (база1.png), после - как-то так (база2.png). Сообщение отредактировал don - 30.09.2014 - 07:19
Прикрепленные файлы
|
|
30.09.2014 - 08:54
Сообщение
#8
|
|
Группа: Пользователи Сообщений: 116 Регистрация: 20.02.2011 Пользователь №: 23251 |
Представьте следующую картину. У нас есть большая база, порядка полутора тысяч чел., в которой собраны наблюдения по разным параметрам, но с разной степенью "перекрывания" данных между ними. Нам известны: 1) генотипы по нескольким снипам для 400 чел., 2) параметр Х1 для 200 чел, из которых со снипами "перекрывается" 150, 3) параметр Х2 для 300 чел, из которых со снипами перекрывается 250, а с Х1 - только 15 4) параметр Х3 для 100 чел, из которых все перекрываются со снипами, но с Х2 и Х1 только 10-20. 5) и таких параметров еще десяток, с разной степенью "перекрывания" с другими. 6) для каждого из пациентов известен статус по болезни. Чтобы лучше понять, о чем идет речь, приложу файл с большой первоначальной базой (don_base111.txt). Причина урезания базы заключается в попытке отобрать тех пациентов, для которых известно как можно больше параметров. Делается это из предположения, что для адекватного анализа RF пропущенные значения конечно могут быть, но должны быть сведены к какому то разумному пределу (не более 30 %). То есть, до урезания базу можно представить так (база1.png), после - как-то так (база2.png). Наверное собирали базу одну люди, а анализировать приходится Вам Может быть для начала изучить полностью вопрос с генетикой по максимальной базе без добавления доп. клин. параметров? Если что-то найдем по снипам, будем хотя-бы знать, что некоторые ассоциированы с заболеванием. Если снипы обнаружить не получиться, это значительно облегчит проблему перекрытия в базе, поскольку тогда стоит копаться лишь в клин. параметрах. Пока гляну сегодня по урезанной базе, что с остальными снипами.. |
|