Получение логарифмического правдоподобия из вероятностного суффиксного дерева

Вот мой код:

library(RCurl)
library(TraMineR)
library(PST)

x <- getURL("https://gist.githubusercontent.com/aronlindberg/08228977353bf6dc2edb3ec121f54a29/raw/c2539d06771317c5f4c8d3a2052a73fc485a09c6/challenge_level.csv")
data <- read.csv(text = x)

# Load and transform data
data <- read.table("thread_level.csv", sep = ",", header = F, stringsAsFactors = F)

data.seq <- seqdef(data[2:nrow(data),2:ncol(data)], missing = "NA", right = "*")

# Make a tree
S1 <- pstree(data.seq, ymin = 0.05, L = 6, lik = TRUE, with.missing = F)
logLik(S1)

По какой-то причине он отказывается возвращать значение логарифмического правдоподобия? Почему это так? Как я могу получить значение логарифмического правдоподобия?


pst traminer sequence-analysis markov-chains
person histelheim    schedule 25.01.2017    source источник

Ответы (2)


arrow_upward
2
arrow_downward

У вас неправильные значения для аргументов missing и right в вашей команде seqdef, что затем вызывает ошибку в pstree.

С

data.seq <- seqdef(data[2:nrow(data),2:ncol(data)], missing = NA, right= NA, nr = "*")
# Make a tree
S1 <- pstree(data.seq, ymin = 0.05, L = 6, lik = TRUE, with.missing = TRUE)
logLik(S1)

мы получили

'log Lik.' -31011.32 (df=47179)

Обратите внимание, что, поскольку у вас есть пропущенные значения, я установил with.missing = TRUE в команде pstree.

===============

Чтобы игнорировать правильные пропуски, установите right='DEL' в seqdef.

seq <- seqdef(data[2:nrow(data),2:ncol(data)], missing = NA, right= "DEL")
S2 <- pstree(seq, ymin = 0.05, L = 6, lik = TRUE, with.missing = F)
logLik(S2)

Я не знаю, что PST вычисляет как logLik(S2) и почему мы получаем здесь NA. Вероятность генерации данных с помощью дерева S2 можно получить с помощью функции predict, которая возвращает вероятность каждой последовательности в данных. Тогда логарифмическая вероятность данных должна быть

sum(log(predict(S2, seq)))

который дает

 [>] 984 sequence(s) - min/max length: 1/32
 [!] sequences have unequal lengths
 [>] max. context length: L=6
 [>] found 1020 distinct context(s)
 [>] total time: 0.588 secs
[1] -4925.79
person Gilbert    schedule 26.01.2017
comment
Однако все мои пропущенные значения находятся справа — внутри последовательностей нет ни одного пропущенного значения. Следовательно, примерно 90% всех моих событий — это *. Не исказит ли это вероятности? - person histelheim; 26.01.2017
comment
Например, когда я выполняю cmine(S1, pmin = 0, state = "good_idea", l = 1), я получаю вероятность e, то есть 47 % — это даже невозможно с этим набором данных, поскольку ни одна последовательность не начинается с *. - person histelheim; 26.01.2017
comment
Я отредактировал ответ, чтобы показать, как игнорировать отсутствующий конец последовательностей. И, вы правы, мы получаем NA logLik. Я предлагаю вам спросить автора пакета о том, каким должен быть этот logLik (он не возвращает то же значение, что и метод, который я предлагаю в ответе!). - person Gilbert; 27.01.2017

arrow_upward
2
arrow_downward

Действительно, возникла проблема при вычислении правдоподобия моделей, подходящих для последовательностей неравной длины. Это исправлено. Новая версия пакета PST (0.94) будет доступна в течение нескольких часов на R-Forge, для установки:

install.packages("PST", repos="http://R-Forge.R-project.org")

и позже CRAN.

Обратите внимание: поскольку ваши последовательности не содержат пропущенных значений, но имеют разную длину, вам не нужно устанавливать ни with.missing=TRUE при использовании функции pstree, ни какие-либо параметры при использовании seqdef.

Теперь при запуске следующего кода:

library(RCurl)
library(TraMineR)
library(PST)

x <- getURL("https://gist.githubusercontent.com/aronlindberg/08228977353bf6dc2edb3ec121f54a29/raw/c2539d06771317c5f4c8d3a2052a73fc485a09c6/challenge_level.csv")
data <- read.csv(text = x)

data.seq <- seqdef(data[2:nrow(data),2:ncol(data)])

# Make a tree
S1 <- pstree(data.seq, ymin = 0.05, L = 6)

Я получил:

> S1@logLik
[1] -4925.79
person Alexis Gabadinho    schedule 02.02.2017
comment
См. комментарий в вопросе: stackoverflow. com/questions/41968530/ — нераспознавание отсутствующих значений вызывает проблемы в tune() и cmine() — как это обойти? - person histelheim; 24.02.2017