Tại sao giá trị ngẫu nhiên này có phân phối 25/75 thay vì 50/50?

Chỉnh sửa: Vì vậy, về cơ bản những gì tôi đang cố gắng viết là hàm băm 1 bit double.

Tôi muốn ánh xạ doubletới truehoặc falsecó cơ hội 50/50. Vì tôi đã viết mã chọn một số số ngẫu nhiên (như một ví dụ, tôi muốn sử dụng mã này trên dữ liệu một cách đều đặn và vẫn nhận được kết quả 50/50) , kiểm tra bit cuối cùng của chúng và tăng ynếu là 1 hoặc nnếu là 0.

Tuy nhiên, mã này liên tục cho kết quả 25% yvà 75% n. Tại sao nó không phải là 50/50? Và tại sao một phân phối kỳ lạ, nhưng thẳng (1/3) như vậy?

public class DoubleToBoolean {
    @Test
    public void test() {

        int y = 0;
        int n = 0;
        Random r = new Random();
        for (int i = 0; i < 1000000; i++) {
            double randomValue = r.nextDouble();
            long lastBit = Double.doubleToLongBits(randomValue) & 1;
            if (lastBit == 1) {
                y++;
            } else {
                n++;
            }
        }
        System.out.println(y + " " + n);
    }
}

Ví dụ đầu ra:

250167 749833

Bởi vì nextDouble hoạt động như thế này: ( nguồn )

public double nextDouble()
{
    return (((long) next(26) << 27) + next(27)) / (double) (1L << 53);
}

next(x)làm cho xcác bit ngẫu nhiên.

Bây giờ tại sao điều này lại quan trọng? Bởi vì khoảng một nửa số được tạo bởi phần đầu tiên (trước khi phân chia) nhỏ hơn 1L << 52, và do đó, ý nghĩa của chúng không hoàn toàn lấp đầy 53 bit mà nó có thể điền vào, có nghĩa là bit có ý nghĩa nhỏ nhất luôn luôn bằng không đối với những số đó.

Do mức độ chú ý mà điều này nhận được, đây là một số giải thích thêm về những gì doubletrong Java (và nhiều ngôn ngữ khác) thực sự trông như thế nào và tại sao nó lại quan trọng trong câu hỏi này.

Về cơ bản, một doublecái nhìn như thế này: ( nguồn )

Một chi tiết rất quan trọng không thể nhìn thấy trong hình này là các số được "chuẩn hóa" ¹ sao cho phân số 53 bit bắt đầu bằng 1 (bằng cách chọn số mũ sao cho như vậy), sau đó 1 bị bỏ qua. Đó là lý do tại sao hình ảnh hiển thị 52 bit cho phân số (có ý nghĩa) nhưng có hiệu quả 53 bit trong đó.

Chuẩn hóa có nghĩa là nếu trong mã cho nextDoublebit thứ 53 được đặt, bit đó là đầu 1 ẩn và nó biến mất, và 52 bit còn lại được sao chép theo nghĩa đen của kết quả double. Tuy nhiên, nếu bit đó không được đặt, các bit còn lại phải được dịch chuyển sang trái cho đến khi nó được đặt.

Trung bình, một nửa số được tạo rơi vào trường hợp số ý nghĩa không bị dịch chuyển trái (và khoảng một nửa số có 0 là bit có ý nghĩa nhỏ nhất của chúng) và nửa còn lại được dịch chuyển ít nhất 1 (hoặc hoàn toàn thay đổi không) vì vậy bit có ý nghĩa nhỏ nhất của chúng luôn là 0.

1: không phải luôn luôn, rõ ràng không thể thực hiện bằng 0, không có giá trị cao nhất 1. Những số này được gọi là số không bình thường hoặc số không bình thường, xem wikipedia: số không bình thường .

Từ các tài liệu :

Phương thức nextDouble được lớp Thực hiện ngẫu nhiên như thể bởi:

public double nextDouble() {
  return (((long)next(26) << 27) + next(27))
      / (double)(1L << 53);
}

Nhưng nó cũng nêu sau đây (nhấn mạnh của tôi):

[Trong các phiên bản đầu của Java, kết quả được tính không chính xác là:

 return (((long)next(27) << 27) + next(27))
     / (double)(1L << 54);

Điều này có vẻ tương đương, nếu không tốt hơn, nhưng trên thực tế, nó đã đưa ra một sự không đồng nhất lớn do sự sai lệch trong cách làm tròn các số có dấu phẩy động: có khả năng gấp ba lần số bit bậc thấp của số có nghĩa là 0 hơn thế nó sẽ là 1 ! Sự không đồng nhất này có lẽ không quan trọng lắm trong thực tế, nhưng chúng tôi cố gắng hoàn thiện.]

Lưu ý này đã có từ khi Java 5 ít nhất (tài liệu cho Java <= 1.4 nằm sau một tường đăng nhập, quá lười để kiểm tra). Điều này thật thú vị, vì vấn đề rõ ràng vẫn còn tồn tại ngay cả trong Java 8. Có lẽ phiên bản "đã sửa" chưa bao giờ được thử nghiệm?

Kết quả này không làm tôi ngạc nhiên khi biết các số dấu phẩy động được biểu diễn như thế nào. Giả sử chúng ta có một loại dấu phẩy động rất ngắn chỉ với 4 bit chính xác. Nếu chúng ta tạo một số ngẫu nhiên từ 0 đến 1, được phân phối đồng đều, sẽ có 16 giá trị có thể:

0.0000
0.0001
0.0010
0.0011
0.0100
...
0.1110
0.1111

Nếu đó là cách họ nhìn trong máy, bạn có thể kiểm tra bit thứ tự thấp để có phân phối 50/50. Tuy nhiên, phao IEEE được thể hiện như một sức mạnh gấp 2 lần so với lớp phủ; một trường trong float là lũy thừa của 2 (cộng với phần bù cố định). Sức mạnh của 2 được chọn sao cho phần "mantissa" luôn là một số> = 1.0 và <2.0. Điều này có nghĩa là, trên thực tế, các số khác hơn 0.0000sẽ được biểu diễn như thế này:

0.0001 = 2^(-4) x 1.000
0.0010 = 2^(-3) x 1.000
0.0011 = 2^(-3) x 1.100
0.0100 = 2^(-2) x 1.000
... 
0.0111 = 2^(-2) x 1.110
0.1000 = 2^(-1) x 1.000
0.1001 = 2^(-1) x 1.001
...
0.1110 = 2^(-1) x 1.110
0.1111 = 2^(-1) x 1.111

(Điểm 1trước nhị phân là một giá trị ngụ ý; đối với số float 32 và 64 bit, thực tế không có bit nào được phân bổ để giữ giá trị này 1.)

Nhưng nhìn vào phần trên sẽ chứng minh tại sao, nếu bạn chuyển đổi biểu diễn thành bit và nhìn vào bit thấp, bạn sẽ nhận được không 75% thời gian. Điều này là do tất cả các giá trị nhỏ hơn 0,5 (nhị phân 0.1000), bằng một nửa các giá trị có thể, có mantissas của chúng bị dịch chuyển, làm cho 0 xuất hiện trong bit thấp. Tình huống về cơ bản là giống nhau khi lớp phủ có 52 bit (không bao gồm hàm 1) như doublehiện tại.

(Trên thực tế, như @sneftel đã đề xuất trong một nhận xét, chúng tôi có thể bao gồm hơn 16 giá trị có thể có trong phân phối, bằng cách tạo:

0.0001000 with probability 1/128
0.0001001 with probability 1/128
...
0.0001111 with probability 1/128
0.001000  with probability 1/64
0.001001  with probability 1/64
...
0.01111   with probability 1/32 
0.1000    with probability 1/16
0.1001    with probability 1/16
...
0.1110    with probability 1/16
0.1111    with probability 1/16

Nhưng tôi không chắc đó là loại phân phối mà hầu hết các lập trình viên mong đợi, vì vậy nó có thể không đáng giá. Thêm vào đó, nó không mang lại cho bạn nhiều khi các giá trị được sử dụng để tạo số nguyên, như các giá trị dấu phẩy động ngẫu nhiên thường là.)