幾天前，我有點不假思索地嘗試對 Twitter 記錄中的四個變數進行 MCA。 這些都是用戶名、用戶螢幕名稱、回覆名稱等。 全部都是隨機長度的字母順序。程式運行得很完美。
現在我開始重新分析，先思考。 我明顯的錯誤。在 4257 案例文件上，我無法讓 MCA 完成執行（我等待的時間不夠長）。Windows 任務管理器告訴我程式沒有回應，但是，當然，核心大小和 CPU 使用率不斷變化。
我推測了這些變數可能產生的類別數量。 因此，我選擇了使用者 ID 和引發該推文的回應實體的 ID。這是在具有 64GB 記憶體的 Dell 8 核心機器上運行的。它已經運行了兩個小時，使用了 8% 的 CPU（各百分比），記憶體不足 5,000 MB。評論行列出“未回复..”我可以讓這項工作整夜運行，無需額外費用。但背後的邏輯讓我困擾，因為我不太了解它。
A。如果變數使用數字，但被指定為名義建模——類別的最大數量就是案例的數量（例如文件中推文作者的數量）。
b.如果變數使用任意字元、單字或名稱，則相同的數字成立——案例方向上的最大維度是觀察值的數量。所以沒有差別。
C。如果將變數建模為數字，即使是序數，位置數也可能是集合中最低數字和最高數字之間的位數。
d.一位 JMP 社群成員進行了 60 萬個案例研究並製作了簡潔的圖表。他一定使用了魔杖——或者目標變數中的值很少。
e.如果我必須考慮創建一個「誰對誰」矩陣，我必須準備好（在我的例子中）一個 4257 x 4256 或左右的矩陣，然後對其進行簡化。但初步猜測，這個矩陣的字數不會超過 1,900 萬個。對計算機來說這並不算多。
我不明白什麼？我是否僅限於 4257 個案例乘以只有一打或兩個值的變數？
所以，既然你們過去這麼友善，我想我可以把它丟掉。如果有人願意，我可以上麵包含所有案例和一些變數的表格，但不想淹沒其他人的儲存。
：
謝謝，菲爾。
問題在於類別的數量。並不是說程式不能計算一千個左右的類別，而是需要很長時間。我要問的問題是誰回應誰。我將進一步研究一下，看看是否可以篩選其中一個變數來減少類別數量。如果有什麼結果，我會發布結果。
拉里
我認為如果您可以分享一些說明性數據可能會有所幫助。
我不太明白您的分析目標是什麼以及您嘗試分析的資料是什麼樣的。 我不確定MCA是否合適。
如果我理解的話，你有一個包含 4257 行的表。 對於 JMP Pro 中的 MCA 來說這不是問題。
一個更重要的因素是每個變數的等級數。
