Phân phối Gauss
Phân phối Gauss
Nắn đường cong chuông rồi kéo một dải để đọc xác suất. Đỉnh cao lên bao nhiêu cũng được, còn diện tích thì không nhích một chút nào.
Đường cong chuông chỉ có hai con số điều khiển nó: trung bình μ và độ lệch chuẩn σ. Hai con số đó làm hai việc hoàn toàn khác nhau, và có đúng một đại lượng mà cả hai đều không đổi được.
Cái đáng học ở đây không phải hình dáng cái chuông, vì hình đó ai cũng nhận ra. Cái đáng học là ba câu hỏi mà nhìn hình không trả lời được: diện tích dưới đường là bao nhiêu, đỉnh cao bao nhiêu, và tại sao giá trị trên trục dọc được phép lớn hơn 1. Cả ba đều đo được ngay trong sim dưới đây.
Ở trạng thái mở bài, sim đang nói gì
Hai thanh kéo đang ở μ = 0.00 và σ = 1.00. Hai mép của dải đang ở -1.00 và 1.00, tức đúng bằng μ - σ và μ + σ. Ô xác suất trên thanh công cụ đọc P(-1.00 < X < 1.00) = 68.27%, và con số chính xác phía sau nó là 0.6826894723352726.
Hàng chữ dưới hình có sáu ô. Hai ô đầu nói về hình đang vẽ: đỉnh f(μ) = 0.399, giá trị chính xác là 0.3989422804014327, và dải: -1.00σ tới 1.00σ, tức dải đang rộng đúng một độ lệch chuẩn về mỗi phía.
Ba ô tiếp là ba dải ±1σ ôm 68.27%, ±2σ ôm 95.45%, ±3σ ôm 99.73%. Ba con số này không đổi khi bạn trượt hai thanh, và đó không phải chuyện tình cờ mà là nội dung của mục dưới. Ô cuối ghi trong khung vẽ: 100.00%, tức gần như toàn bộ diện tích đang nằm trong khung hình.
Chữ 100.00% đó đã được làm tròn. Diện tích thật trong khung là 0.9999999999974238, tức thiếu một chút, vì hai cái đuôi của chuông chạy ra ngoài x = -7 và x = 7. Ở trạng thái mở bài chỗ thiếu nhỏ tới mức không thấy được, nhưng nó không nhỏ ở mọi chỗ: kéo μ về -3.00 và σ lên 2.50 thì ô đó tụt xuống 94.52%, giá trị chính xác 0.945169022659347. Nghĩa là cái khung vẽ không phải cả đường cong, và mọi câu nói về diện tích trong bài này là câu nói về toàn bộ trục số chứ không phải về phần bạn nhìn thấy.
Hai tham số làm hai việc, và một thứ không đổi
Trượt μ và chỉ có một chuyện xảy ra: cả cái chuông dời ngang. Đỉnh vẫn cao đúng như trước, bề rộng vẫn thế, chỉ có vị trí đổi. Cổng kiểm đối chiếu điều này trên toàn bộ 1403 vị trí mà hai thanh kéo tạo ra, và không có vị trí nào chiều cao của đỉnh nhích một bit.
Trượt σ thì hai chuyện xảy ra cùng lúc, và chúng ngược chiều nhau: chuông bè rộng ra thì đồng thời thấp xuống, bóp gầy lại thì đồng thời cao lên. Hai chuyện đó buộc vào nhau, không tách được, và lý do là đại lượng thứ ba.
Đại lượng đó là diện tích dưới đường cong, và nó luôn bằng 1 dù hai tham số đổi thế nào. Đây là bất biến quan trọng nhất của bài. Nó cũng là lời giải thích trọn vẹn cho câu "bè ra thì phải thấp lại": nếu bè ra mà không thấp xuống thì diện tích sẽ lớn hơn 1, và một phân phối xác suất không được phép làm thế.
Cổng kiểm không tin lời khẳng định này, nó tích phân hàm mật độ của engine bằng công thức Simpson trên khoảng ±20σ tại từng vị trí trong 1403 cấu hình, và đòi chênh lệch so với 1 phải dưới 1e-14. Chỗ này có một bài học nhỏ về đo lường đáng kể lại, vì nó đi ngược trực giác.
Sai số của phép tích phân không giảm mãi khi lưới mịn dần. Với N = 50 bước, công thức Simpson lệch 2.9869321557107753e-4, tức tệ. Với N = 100 nó xuống 2.6645352591003757e-14, với N = 200 xuống 2.220446049250313e-16, và với N = 400 nó bằng đúng 0. Nhưng đẩy tiếp lên N = 51200 thì nó xấu trở lại, thành 9.2148511043888e-15, vì lúc này sai số làm tròn của việc cộng hàng vạn số hạng lớn hơn sai số của chính công thức. Mịn hơn không phải luôn đúng hơn.
Và có một chuyện quan trọng hơn cả độ mịn: bề rộng cửa sổ. Cùng N = 4000 bước, cắt cửa sổ ở ±4σ cho sai số 6.33424836644636e-5, ở ±6σ cho 1.973172847336002e-9, còn ở ±8σ cho 2.220446049250313e-16. Mười một bậc độ lớn, chỉ vì phần đuôi bị bỏ ngoài. Một phép kiểm chỉ biết làm mịn lưới sẽ kết luận sai rằng bộ tích phân bị hỏng.
Quy tắc 68 / 95 / 99,7 là hệ quả, không phải con số học thuộc
Bấm ba nút dải ±1σ, dải ±2σ, dải ±3σ để đưa dải về đúng μ ± kσ. Ba con số hiện ra là 68.27%, 95.45% và 99.73%.
Bây giờ trượt μ đi đâu cũng được, trượt σ lên xuống bao nhiêu cũng được, rồi bấm lại. Ba con số y nguyên. Đó là điều đáng chú ý, và nó có một dòng đại số phía sau: đổi biến u = (x - μ)/σ biến tích phân trên dải μ ± kσ thành một tích phân không còn μ và σ trong đó nữa. Nói cách khác quy tắc này không phải một mẹo nhớ, nó là cùng một tích phân viết ở đơn vị khác.
Bản thân đổi biến đó là một bất biến viết được thành một dòng: f(x; μ, σ) bằng (1/σ) nhân f((x-μ)/σ; 0, 1). Cổng kiểm quét đẳng thức này trên cả ba biến, 40687 mẫu, trong đó 25458 mẫu khớp tới từng bit và phần còn lại lệch tương đối dưới 1e-15. Nên phát biểu đúng là bất biến giữ được tới mức làm tròn, chứ không phải giữ được bit-y-nguyên ở mọi chỗ.
Con số chính xác thì đáng biết hơn con số làm tròn quen tai. Diện tích thật của ba dải là 0.6826894921370859, 0.9544997361036416 và 0.9973002039367398. Nghĩa là quy tắc "68 / 95 / 99,7" thật ra là 68.27%, 95.45% và 99.73%, và cách gọi quen chỉ là bản làm tròn của chúng.
Cổng kiểm tính ba con số này bằng hai đường không liên quan tới nhau. Đường thứ nhất là hàm lỗi erf viết riêng trong cổng bằng chuỗi Taylor trên số nguyên lớn với 90 chữ số thập phân, trong đó π lấy từ khai triển thập phân đã công bố và cả hai căn bậc hai tính bằng phép lặp Newton trên số nguyên, tức không có một phép tính dấu phẩy động nào. Đường thứ hai là tích phân số của chính hàm mật độ, một đường không biết erf là gì. Hai đường khớp nhau tới dưới 1e-12 trên toàn bộ 4209 mẫu của lưới.
Còn engine thì hơi khác, và chỗ khác đó đáng nói thẳng. Nó dùng một xấp xỉ cho erf, cụ thể là công thức hữu tỉ Abramowitz và Stegun 7.1.26, nên ba con số nó trả về là 0.6826894723352726, 0.9544998742254873 và 0.9973000654373705. Lệch so với giá trị đúng nhiều nhất 1.4e-7. Sai số đó không phải nhiễu làm tròn, nó lớn hơn một đơn vị cuối của số thực 64 bit tới cỡ 1e8 lần, và nó là sai số của chính cái xấp xỉ. Đo được: trên lưới x = k/1000 chạy khắp [-6, 6], tức 12001 điểm, sai số lớn nhất của erf trong engine là 1.3937450351469982e-7 tại x = -0.045.
May là 1.4e-7 vẫn nhỏ hơn chữ số cuối trên màn hình tới bốn bậc độ lớn, nên 68.27% in ra vẫn đúng. Nhưng nếu bạn cần bốn chữ số sau dấu phẩy thì cái xấp xỉ này đã hết đủ, và đó là loại chuyện chỉ biết được bằng cách đo.
Một chi tiết nhỏ của cùng cái xấp xỉ đó: erf(0) trong engine không bằng 0, nó bằng 9.999999717180685e-10, vì năm hệ số của công thức cộng lại được 0.9999999989999999 chứ không phải 1. Hệ quả là P(X ≤ μ) không đọc 0.5 mà đọc 0.5000000005. Sai lệch đó triệt tiêu ở mọi dải đối xứng, vì hai mép cùng mang đúng một lượng lệch và phép trừ xoá nó đi, nên ba con số 68.27 / 95.45 / 99.73 không bị ảnh hưởng. Nhưng ở một xác suất một phía thì nó không triệt tiêu, và nó hiện ra.
Đỉnh cao bao nhiêu
Giá trị lớn nhất của hàm mật độ nằm đúng tại x = μ và bằng 1/(σ√(2π)).
Cổng kiểm không đánh giá công thức này rồi so với chính nó, vì làm thế thì nó tự đồng ý với mình ở mọi cấu hình. Nó quét vét cạn: tại từng vị trí trong 1403 cấu hình, nó lấy 2001 điểm trải khắp ±6σ, tìm giá trị lớn nhất trong số đó, rồi mới đem so. Kết quả là giá trị quét được khớp công thức tới dưới 1e-15 tương đối, và điểm đạt cực đại lệch khỏi μ không quá 2e-15.
Vì σ nằm ở mẫu số nên đỉnh cao lên đúng theo tỉ lệ nghịch: giảm σ một nửa thì đỉnh cao gấp đôi. Cách gọn nhất để nói cùng một chuyện là tích σ nhân đỉnh luôn bằng cùng một hằng số, và hằng số đó là 0.3989422804014327.
Đây là mấy giá trị cụ thể trên thanh kéo:
σ | đỉnh chính xác | ô đỉnh đọc |
|---|---|---|
0.3 | 1.329807601338109 | 1.330 |
0.4 | 0.9973557010035817 | 0.997 |
1 | 0.3989422804014327 | 0.399 |
2.5 | 0.15957691216057307 | 0.160 |
Hai hàng đầu là chỗ đáng dừng lại, vì chúng nằm hai bên một cái mốc.
Đỉnh bằng đúng 1 khi σ bằng 1/√(2π), tức 0.3989422804014327. Ở đúng mốc đó, số thực 64 bit cho ra đúng 1 không sai một bit. Một số thực trên mốc thì đỉnh tụt xuống 0.9999999999999999, một số thực dưới mốc thì đỉnh lên 1.0000000000000002. Thanh kéo bước 0.1 nên nó không bao giờ đặt chân đúng vào mốc, nó nhảy qua: σ = 0.4 cho 0.997, còn σ = 0.3 cho 1.330.
Cũng vì thế mà ô đỉnh in ba chữ số sau dấu phẩy chứ không phải hai. Với hai chữ số, đỉnh ở σ = 0.4 sẽ in ra 1.00 trong khi giá trị thật là 0.9973557010035817, tức nhỏ hơn 1. Con số bị làm tròn thành đúng cái chữ số mà cả mục sau đây nói về nó, và người đọc sẽ kết luận ngược.
Mật độ không phải xác suất
Bóp σ về 0.3 và nhìn cái đỉnh vượt lên trên vạch ngang 1.0 trong hình. Ô đỉnh lúc này đọc 1.330 (lớn hơn 1).
Nếu con số trên trục dọc là xác suất thì đây là chuyện vô lý. Nhưng nó không phải xác suất, nó là mật độ, và mật độ không có trần. Đẩy σ nhỏ hơn nữa, ra ngoài dải thanh kéo cho phép, thì đỉnh cao bao nhiêu cũng được: ở σ = 1e-6 hàm mật độ tại μ bằng 398942.2804014327.
Xác suất là diện tích, không phải chiều cao. Đó là lý do câu trên không mâu thuẫn với bất cứ điều gì: cổng kiểm quét 169763 mẫu dải và không mẫu nào cho diện tích ra ngoài [0, 1], trong khi cùng lúc 61 trong 1403 cấu hình có đỉnh lớn hơn 1. Sáu mươi mốt cấu hình đó là đúng 61 vị trí của thanh μ tại σ = 0.3, mức duy nhất trên thanh kéo thấp hơn 1/√(2π).
Cách thấy rõ nhất là tự đo một dải hẹp. Ở σ = 0.3, chiều cao đỉnh là 1.330, nhưng dải x từ -0.05 tới 0.05, tức rộng 0.1, chỉ ôm 13.24% diện tích. Con số đó xấp xỉ chiều cao nhân bề rộng, và chính phép nhân với bề rộng là chỗ mật độ biến thành xác suất. Đơn vị của mật độ là xác suất trên một đơn vị của x, nên đổi đơn vị đo x là đổi luôn con số mật độ, còn diện tích thì không đổi.
σ = 0 là mốc suy biến, và cái xảy ra ở đó là quy ước
Công thức có σ ở mẫu số nên σ = 0 là chia cho 0. Nhưng chuyện xảy ra không phải "ra vô cùng" như nhiều người đoán, và đây là chỗ đo mới biết.
Cổng kiểm dựng lại bản công thức không có chốt chặn và đo: ở σ = 0 nó trả về NaN với mọi x, kể cả tại x = μ nơi thương số là 0/0. Không có Infinity nào cả, vì Infinity nhân 0 cũng là NaN.
Engine có một chốt chặn ở σ ≤ 0, và nó chọn ba thứ. Cả ba là quy ước, không phải chân lý, nên bài nói thẳng ra:
- hàm mật độ trả về
0ở mọix. Giới hạn trung thực là một cái gai cao vô hạn tạiμ, còn0là con số được chọn để giữ được đẳng thức "đỉnh bằng mật độ tạiμ" ở mọi trường hợp. - hàm phân phối trở thành bậc thang
x < μthì0, còn lại thì1. Toàn bộ khối xác suất dồn vào đúng một điểm. - vì bậc thang đó tính điểm
μvào phía dưới, một dải kết thúc đúng tạiμôm toàn bộ khối, còn một dải bắt đầu đúng tạiμôm không gì cả. Vớiμ = 0,P(-1 < X < 0)bằng1cònP(0 < X < 1)bằng0, cùng một bề rộng dải.
Sự lệch phải trái đó chính là chỗ quy ước lộ ra. Dọn dẹp một trong hai phía sẽ làm đổi câu trả lời, nên cổng kiểm khoá cả hai, đúng như hiện trạng.
Còn thanh kéo thì không tới được đó: σ bị kẹp sàn ở 0.3. Kẹp không im lặng, hệ hiện một dòng nói rõ bạn đặt bao nhiêu và nó dùng bao nhiêu. Ba nút dải ±kσ cũng vậy: ở μ = 3.00 và σ = 2.50, nút dải ±3σ muốn đặt mép phải ở 10.5, ra ngoài khung, nên hệ kẹp về 7.00 và nói ra.
Vì sao phân phối này xuất hiện khắp nơi
Có một lý do cấu trúc, gọn tới mức đáng nêu dù bài này không chứng minh nó: định lý giới hạn trung tâm nói rằng tổng của nhiều đại lượng độc lập nhỏ lẻ tiến về phân phối Gauss, gần như bất kể từng đại lượng có phân phối gì. Sim này không minh hoạ định lý đó, vì trong engine không có một phép sinh số ngẫu nhiên nào, nên đừng đọc bất cứ hình nào ở trên như bằng chứng cho nó.
Lý do thực dụng thì nằm ngay trong bài: cả cái chuông chỉ cần hai con số để mô tả trọn vẹn, và hai con số đó có nghĩa trực tiếp là đặt ở đâu và trải rộng bao nhiêu. Không có tham số thứ ba nào để chọn sai.
Những con số trong bài được kiểm bằng gì
Mọi con số bạn vừa đọc đều bị một cổng kiểm khoá lại, hiện là 332 khẳng định, và cổng không tin phép tính của chính engine.
Diện tích được dựng lại bằng tích phân số của chính hàm mật độ trong engine, không phải của một bản viết lại trong cổng. Chỗ này từng là một lỗ hổng thật: bản đầu của cổng chỉ tích phân bản viết lại, nên một đột biến bỏ mất số 1/2 trong số mũ, tức làm hỏng hẳn phân phối tới mức diện tích thành 1/√2, vẫn đi qua toàn bộ phần khẳng định về diện tích và chỉ vấp ở một chỗ đếm bit không liên quan. Sau khi vá, cùng đột biến đó báo đỏ ngay ở chính khẳng định về diện tích.
Hai nửa của engine cũng bị buộc vào nhau: cổng tích phân hàm mật độ giữa hai mép rồi so với diện tích mà hàm phân phối báo, trên 77165 dải, và chênh lệch lớn nhất là 1.4e-7, tức đúng sai số của erf. Nếu hai nửa rời nhau thì phép so này đỏ ngay.
Cổng còn tự phá engine mười cách rồi đòi chính mình phải báo đỏ, và cả mười lần nó đỏ. Cũng đáng ghi lại một lần cổng tự bắn vào chân: hàm bước một số thực của nó lúc đầu tăng mẫu bit như số nguyên không dấu, mà số thực 64 bit là dạng dấu-và-độ-lớn, nên với số âm nó chạy ngược chiều. Ba khẳng định mốc biên báo đỏ oan vì lý do không liên quan gì tới engine. Bây giờ hàm đó có đối chứng riêng cho cả hai dấu.
Cuối cùng, những gì bài này không chỉ ra. Không có dữ liệu thật ở đâu cả, nên không câu nào ở đây nói được rằng một tập số đo nào đó có phân phối Gauss. Không có phép ước lượng nào, nên bài không nói gì về việc đoán μ và σ từ mẫu. Và không có phép sinh ngẫu nhiên nào, nên định lý giới hạn trung tâm chỉ được nhắc tên ở mục trên chứ chưa được chỉ ra ở bất cứ đâu.
Hai tham số làm hai việc: μ dời đỉnh ngang mà không đổi chiều cao, σ đổi bề rộng và chiều cao cùng lúc theo hai chiều ngược nhau. Buộc chúng vào nhau là bất biến quan trọng nhất: diện tích dưới đường luôn bằng 1, đo bằng tích phân số trên 1403 cấu hình với sai số dưới 1e-14. Quy tắc 68 / 95 / 99,7 là hệ quả của cùng bất biến đó qua đổi biến u = (x-μ)/σ, và con số chính xác là 68.27%, 95.45%, 99.73%. Đỉnh cao đúng 1/(σ√(2π)) nên nó tỉ lệ nghịch với σ và vượt được 1: tại σ = 0.3 nó là 1.330. Đó không phải lỗi, vì mật độ không phải xác suất, xác suất là diện tích. Còn σ = 0 là mốc suy biến: công thức trần trả về NaN ở mọi x, và cái engine làm thay là một quy ước được nói rõ chứ không phải một sự thật.
- 1Bạn bóp độ lệch chuẩn xuống σ = 0.3 và thấy ô đỉnh đọc 1.330, tức lớn hơn 1. Đọc thế nào cho đúng?
- 2Bấm nút dải ±1σ, rồi trượt μ và σ đi bất cứ đâu và bấm lại. Con số 68.27% không nhích. Vì sao?
- 3Trong công thức mật độ, σ nằm ở mẫu số. Vậy gọi hàm với σ = 0 thì công thức trần, tức bản không có chốt chặn, trả về gì?