Điều thứ hai có vẻ như nó là một phép tính gần đúng với phép tính được sử dụng cho x+y < 20
trường hợp, nhưng dựa trên phép tính gần đúng Stirling .
Thông thường khi nó được sử dụng cho loại xấp xỉ này, mọi người sẽ sử dụng ít nhất thuật ngữ bổ sung tiếp theo (hệ số của trong phép tính gần đúng cho ), Điều này sẽ cải thiện đáng kể xấp xỉ tương đối cho nhỏ . n! n2πn−−−√n!n
Ví dụ: nếu và đều là 10, phép tính đầu tiên cho khoảng 0,088 trong khi xấp xỉ khi hệ số của được bao gồm trong tất cả các điều khoản là khoảng 0,089, đủ gần cho hầu hết các mục đích ... nhưng bỏ qua thuật ngữ đó trong phép tính gần đúng sẽ cho 0,5 - thực sự không đủ gần! Tác giả của chức năng đó rõ ràng đã không bận tâm để kiểm tra tính chính xác của phép tính gần đúng của anh ta trong trường hợp biên.y √xy2πn−−−√
Với mục đích này, tác giả có lẽ chỉ đơn giản là đã gọi hàm dựng sẵn lgamma
- cụ thể, bằng cách sử dụng hàm này thay vì những gì anh ta có cho log_p1
:
log_p1 <- lgamma(x+y+1)-lgamma(x+1)-lgamma(y+1)-(x+y+1)*log(2)
dẫn đến câu trả lời mà anh ta đang cố gắng ước tính (vì lgamma(x+1)
thực tế trả về , điều mà anh ta đang cố gắng gần đúng - kém - thông qua xấp xỉ Stirling).log(x!)
Tương tự, tôi không chắc tại sao tác giả không sử dụng hàm dựng sẵn trong choose
phần đầu tiên, một hàm có trong phân phối chuẩn của R. Đối với vấn đề đó, chức năng phân phối có liên quan cũng có thể được tích hợp sẵn.
Bạn không thực sự cần hai trường hợp riêng biệt; những lgamma
ai làm việc tốt phải xuống đến giá trị nhỏ nhất. Mặt khác, choose
hàm hoạt động với các giá trị khá lớn (ví dụ: choose(1000,500)
hoạt động tốt). Các an toàn tùy chọn có lẽ là lgamma
, mặc dù bạn sẽ cần phải có khá lớn và trước khi nó là một vấn đề.yxy
Với nhiều thông tin hơn có thể xác định nguồn gốc của bài kiểm tra. Tôi đoán là nhà văn đã lấy nó từ một nơi nào đó, vì vậy nó có thể theo dõi nó xuống. Bạn có một số bối cảnh cho điều này?
Khi bạn nói 'tối ưu hóa', bạn có nghĩa là làm cho nó nhanh hơn, ngắn hơn, dễ bảo trì hơn hay cái gì khác?
Chỉnh sửa sau khi đọc nhanh trên giấy:
Các tác giả dường như sai về một số điểm. Thử nghiệm chính xác của Fisher không cho rằng các lề được cố định, nó chỉ đơn giản là các điều kiện đối với chúng, hoàn toàn không giống nhau, như đã thảo luận, ví dụ, ở đây , với các tài liệu tham khảo. Thật vậy, họ dường như hoàn toàn không biết gì về cuộc tranh luận về điều kiện bên lề và lý do tại sao nó được thực hiện. Các liên kết có giá trị đọc.
[Họ tiến hành từ 'Thử nghiệm của Fisher luôn bảo thủ hơn so với thử nghiệm của chúng tôi' để khẳng định rằng thử nghiệm của Fisher quá bảo thủ ... điều đó không nhất thiết phải tuân theo trừ khi điều đó sai . Họ phải chứng minh điều đó, nhưng cho rằng đó là điều mà các nhà thống kê đã tranh cãi trong khoảng 80 năm, và các tác giả này dường như không biết tại sao điều hòa được thực hiện, tôi không nghĩ rằng những kẻ này đã hiểu rõ vấn đề .]
Các tác giả của bài báo ít nhất dường như hiểu rằng xác suất mà họ đưa ra phải được tích lũy để đưa ra giá trị p; ví dụ gần giữa cột đầu tiên của trang 5 (phần nhấn mạnh của tôi):
Ý nghĩa thống kê theo thử nghiệm chính xác của Fisher cho kết quả như vậy là 4,6% (giá trị P hai đuôi, nghĩa là xác suất để một bảng như vậy xảy ra trong giả thuyết rằng tần số Actin EST độc lập với các thư viện cDNA). Để so sánh, giá trị P được tính từ dạng tích lũy
(Công thức 9, xem Phương thức) của phương trình 2 (nghĩa là, tần số tương đối của EST Actin là giống nhau trong cả hai thư viện, với điều kiện có ít nhất 11 EST nhận thức được quan sát trong thư viện gan sau hai đã được quan sát trong thư viện não) là 1,6%.
(mặc dù tôi không chắc là tôi đồng ý với cách tính giá trị của họ ở đó; tôi phải kiểm tra cẩn thận để xem họ thực sự đang làm gì với cái đuôi kia.)
Tôi không nghĩ chương trình làm điều đó.
Tuy nhiên, coi chừng phân tích của họ không phải là phép thử nhị thức tiêu chuẩn; họ sử dụng một đối số Bayes để lấy giá trị p trong một bài kiểm tra thường xuyên khác. Theo tôi, chúng dường như - hơi kỳ quặc - dựa trên , thay vì . Điều này có nghĩa là họ phải kết thúc bằng thứ gì đó như nhị thức âm chứ không phải nhị thức, nhưng tôi thấy bài báo được tổ chức rất tệ và giải thích rất tệ (và tôi đã từng tìm hiểu những gì đang diễn ra trong các bài báo thống kê), vì vậy tôi sẽ không chắc chắn trừ khi tôi đi qua một cách cẩn thận.x + yxx+y
Tôi thậm chí không tin rằng tổng xác suất của họ là 1 vào thời điểm này.
Có rất nhiều điều để nói ở đây, nhưng câu hỏi không phải là về bài báo, đó là về việc thực hiện trong chương trình.
-
Dù sao, kết quả cuối cùng là, ít nhất là bài báo xác định chính xác rằng giá trị p bao gồm tổng xác suất giống như trong phương trình 2, nhưng chương trình thì không . (Xem eqn 9a và 9b trong phần Phương pháp của bài viết.)
Mã đơn giản là sai về điều đó.
[Bạn có thể sử dụng pbinom
, như nhận xét của @ whuber sẽ ngụ ý, để tìm ra xác suất riêng lẻ (nhưng không phải là đuôi, vì đó không phải là phép thử nhị thức khi họ cấu trúc nó) nhưng sau đó có thêm hệ số 1/2 trong phương trình 2 của họ nếu bạn muốn sao chép kết quả trong bài báo, bạn cần thay đổi chúng.]
Bạn có thể có được nó, với một số khó khăn, từ pnbinom
-
Các dạng thông thường của nhị thức âm là số lần thử nghiệm thành công hoặc số lần thất bại đối với thành công . Hai cái tương đương nhau; Wikipedia đưa ra hình thức thứ hai ở đây . Hàm xác suất là: k t hkthkth
(k+r−1k)⋅(1−p)rpk,
Phương trình 2 trên p4 (và cả eqn 1 trên p3) là một nhị thức âm, nhưng được dịch bởi 1. Đặt , và .p=N1/(N1+N2)k=xr=y+1
Điều này khiến tôi lo ngại rằng vì các giới hạn trên không bị thay đổi tương tự, nên xác suất của chúng thậm chí có thể không thêm vào 1.y
Điều đó sẽ rất tệ.
p2
tất cả; nhỏ hơnp1
vàp2
tương ứng với nhỏ hơnx
vày
, tương ứng - đó là một sự không hiệu quả. Một lỗi có thể là nhánh thứ hai của điều kiện không thể tính toán đượcp2
và chỉ sử dụngp1
. Tôi cũng nghi ngờ rằng mã có thể hoàn toàn sai, bởi vì nó không xuất hiện để tính giá trị p: nó chỉ là một nửa xác suất nhị thức và có lẽ phải là xác suất đuôi . Tại sao không chỉ sử dụngpbinom
/dbinom
và được thực hiện với nó?