Por que a implementação do t-SNE no R é padrão para a remoção de duplicatas?

Especificamente, a implementação R do t-SNE no pacote Rtsne possui um argumento "check_duplicates" e a documentação sugere que "é melhor garantir que não haja duplicatas presentes e defina essa opção como FALSE, especialmente para grandes conjuntos de dados".

Além disso, se você tentar executar o t-SNE em um conjunto de dados no R que possua duplicatas, você receberá a mensagem de erro: "Erro no [comando capturado pelo usuário]: remova as duplicatas antes de executar o TSNE".

Então, por que esse comportamento ocorre? Eu tenho um conjunto de dados em que várias amostras coincidentemente têm as mesmas medidas.

É simplesmente um "ponto de dados duplicado, após a redução, terá os mesmos pontos de dados de qualquer maneira, portanto, não desperdice poder de processamento"? A presença de duplicatas afeta os cálculos do processo?

O algoritmo foi projetado para lidar com conjuntos de dados sem informações duplicadas, portanto o pacote faz uma verificação antes de aplicar a técnica. Eles sugerem que você remova duplicatas e defina check_duplicates = FALSEuma melhoria de desempenho.

A implementação em R é esta:

if (check_duplicates & !is_distance){
if (any(duplicated(X))) { stop("Remove duplicates before running TSNE.")}

Com valores padrão check_duplicates = TRUEe is_distance = FALSE.

O artigo, para quem quer entender mais sobre o método, está aqui .

t-SNEO método não requer a remoção de duplicatas. O fato de ser um recurso padrão Rtsnenão implica em seu requisito. É útil para algum monitoramento de eventos de curto prazo. Para caracterizar tendências e / ou padrões de longo prazo com grandes conjuntos de dados, vejo pouca utilidade. A Rtsneconfiguração padrão pode ser mais inclinada para caracterizar eventos no domínio do tempo, sem estudos no domínio de Fourier.

Suponha que você tenha pontos no domínio do tempo. O algoritmo duplicado causa uma quantidade significativa de falsos positivos, porque a verificação duplicada é projetada principalmente no sinal no domínio do tempo. O espaço de Fourier pode mostrar que os eventos considerados pelo duplicado do algoritmo não são necessários.

Portanto, minha observação é que o algoritmo é ganancioso quanto a pontos duplicados no domínio do tempo, o que não é útil para mim quando consideramos sinais de longo prazo, tendências de longo prazo e padrões de longo prazo. O fato de o ponto estar duplicado no domínio do tempo não significa, na verdade, que está duplicado também no domínio de Fourier. Eu acho que será mais uma coincidência se for uma duplicata no domínio do tempo nas aplicações da vida real. Portanto, desativar o recurso deve estar ok. Estimar quanto dos pontos são realmente duplicados nos dois domínios é específico no estudo de caso. Eu obtenho descritores significativamente melhores de eventos e / ou fenômenos ao considerar conjuntos de dados de longo prazo sem a verificação duplicada em muitos aplicativos da vida real.

Eu acho que a Rtsnedocumentação não é clara sobre o caso ao dizer [desligar check_duplicatese] não desperdiçar energia de processamento . Existem realmente outras razões, como descrito acima, pelas quais a check_duplicatesdesativação pode ser realizada conforme também ocorre em algumas outras implementações do método. O check_duplicates=TRUEé uma seleção pessoal do Rtsnedesenvolvedor por padrão no momento. Gostaria de saber se existem razões de implementação para a decisão.