Bazı adamlar şöyle dedi:

Deterministik yöntemlerle rasgele sayılar üretmeye çalışan herkes, elbette bir günah durumunda yaşamaktadır.

Bu her zaman yalnızca bir bilgisayarla gerçek rasgele sayılar üretemeyeceğiniz anlamına gelir. Bilgisayarların tek bir Intel 8080 mikroişlemcinin (~ 6000 vana) eşdeğer büyüklüğünde olduğunu söyledi. Bilgisayarlar daha karmaşık hale geldi ve von Von Neumann'ın ifadesinin artık doğru olamayacağına inanıyorum. Uygulanan bir yazılımın yalnızca algoritmanın imkansız olduğunu düşünün. Fiziksel donanım üzerinde çalışıyorlar. Gerçek rasgele sayı üreteçleri ve entropi kaynakları da donanımdan yapılmıştır.

Bu Java parçası bir döngü içine koydu:

      file.writeByte((byte) (System.nanoTime() & 0xff));

resim olarak temsil ettiğim bir veri dosyası oluşturabilir:

Yapıyı görebilirsiniz, ama aynı zamanda çok fazla rastgelelikle. İlgi çekici olan, bu PNG dosyasının 232KB boyutunda olmasına rağmen, 250.000 gri tonlamalı piksel içermesidir. PNG sıkıştırma seviyesi maksimum idi. Bu sadece% 7'lik bir sıkıştırma oranı, yani. oldukça sıkıştırılamaz. Ayrıca ilginç olan, dosyanın benzersiz olmasıdır. Bu dosyanın her nesil biraz farklı bir kalıptır ve benzer ~% 7 oranında sıkıştırılabilirliğe sahiptir. Bunu, tartışmam için kritik öneme sahip olduğunu vurgularım. Bu ~ 7bits / byte entropi. Bu daha güçlü bir sıkıştırma algoritması kullanılmasıyla elbette azalacaktır. Ancak 0 bit / bayt civarında bir şeye düşürmeyin. Yukarıdaki görüntüyü çekerek ve renk haritasını rastgele biriyle değiştirerek daha iyi bir izlenim elde edilebilir: -

Yapının çoğu (üst yarıda), yalnızca benzer fakat marjinal olarak farklı değerlerin dizileri olduğu için kaybolur. Bu, sadece bir Java işletim sistemini çoklu alıp kullanan bir işletim sisteminde çalıştırarak yaratılan gerçek bir entropi kaynağı mıdır? Düzgün dağılmış rasgele sayı üreteci değil, bir entropi kaynağı mı? Sadece bir PC olan fiziksel donanım üzerinde çalışan bir yazılımdan oluşan entropi kaynağı.

tamamlayıcı

Her görüntünün, hepsinde ortak olan sabit bir düzen olmadan taze entropi oluşturduğunu doğrulamak için, ardışık 10 görüntü üretildi. Bunlar daha sonra birleştirildi ve derleyebileceğim en güçlü arşivleyici ile sıkıştırıldı (paq8px). Bu işlem, sadece değişiklikleri / entropiyi bırakan otomatik korelasyon dahil olmak üzere tüm ortak verileri ortadan kaldıracaktır.

Birleştirilmiş dosya ~% 66'ya sıkıştırılmıştır, bu da ~ 5.3 bit / bayt veya 10.5Mbits / görüntü entropi oranına yol açmaktadır. Şaşırtıcı miktarda entropi$\smile$

Ek 2

Sıkıştırma testi metodolojisine göre entropimin hatalı olduğu ve sadece üst üst sınır tahminde bulunacağı yönünde olumsuz yorumlar var. Bu yüzden şimdi NIST'in resmi kriptografik entropi değerlendirme testi olan SP800-90B_EntropyAssessment olsa da birleştirilmiş dosyayı çalıştırdım . Bu, IID olmayan entropi ölçümü için aldığı kadar iyidir. Bu rapor (üzgünüm bu soru uzun sürüyor, ancak sorun karmaşık): -

Running non-IID tests...

Entropic statistic estimates:
Most Common Value Estimate = 7.88411
Collision Test Estimate = 6.44961
Markov Test Estimate = 5.61735
Compression Test Estimate = 6.65691
t-Tuple Test Estimate = 7.40114
Longest Reapeated Substring Test Estimate = 8.00305

Predictor estimates:
Multi Most Common in Window (MultiMCW) Test: 100% complete
    Correct: 3816
    P_avg (global): 0.00397508
    P_run (local): 0.00216675
Multi Most Common in Window (Multi MCW) Test = 7.9748
Lag 

Test: 100% complete
    Correct: 3974
    P_avg (global): 0.00413607
    P_run (local): 0.00216675
Lag Prediction Test = 7.91752
MultiMMC Test: 100% complete
    Correct: 3913
    P_avg (global): 0.00407383
    P_run (local): 0.00216675
Multi Markov Model with Counting (MultiMMC) Prediction Test = 7.9394
LZ78Y Test: 99% complete
    Correct: 3866
    P_avg (global): 0.00402593
    P_run (local): 0.00216675
LZ78Y Prediction Test = 7.95646
Min Entropy: 5.61735

Sonuç olarak, NIST entropinin 5.6 bit / baytını oluşturduğuma inanıyor. DIY sıkıştırma tahminim, bunu biraz daha muhafazakar, 5.3 bit / byte değerine getiriyor.

-> Kanıt, sadece yazılımı çalıştıran bir bilgisayarın gerçek entropi üretebileceği fikrini desteklemektedir. Ve bu von Neumann yanıldı (ama belki de zamanı için doğru).

Talebimi destekleyebilecek aşağıdaki referansları sunuyoruz: -

Program yürütme oranında belirleyici olmayan herhangi bir rasgele model var mı?

Olasılıklı Sabit Gerçek Zamanlı Sistemlerin WCET Analizi

Deterministik olmayan bir kaos paterni üretebilecek bir yazılım algoritması var mı? ve kaotik etkilerin alaka düzeyi.

Kuantum entropik belirsizlik ilkesiyle paralellikler

Aleksey Shipilёv'in nanoTime () 'ın kaotik davranışına ilişkin blog yazısı . Dağılım komploları benimkine benzemiyor.

Sadece bir kalıp göremediğiniz için, hiçbir kalıp olmadığı anlamına gelmez. Sadece bir sıkıştırma algoritmasının bir kalıp bulamaması, hiçbir kalıp olmadığı anlamına gelmez. Sıkıştırma algoritmaları, bir kaynağın gerçek entropisini sihirli bir şekilde ölçebilen gümüş mermiler değildir; tek verdikleri entropi miktarına bağlı bir üst . (Benzer şekilde, NIST testi ayrıca size sadece bir üst sınır verir.) Kaos rastgelelik değildir.

Bu şekilde elde edilen rastgelelik kalitesine güven duymaya başlamak daha ayrıntılı bir analiz ve incelemeye ihtiyaç duyar.

Saat sarsıntısından ve iki donanım saati arasındaki sapmadan yararlanarak muhtemelen bir miktar rastgelelik elde edebileceğimizi düşünmek için nedenler var , ama bu hassas ve zorlu, bu yüzden dikkatli olmalısınız. Kendi uygulamanızı denemeyi tavsiye etmem. Bunun yerine, yüksek kaliteli bir entropi kaynağı kullanmanızı öneririm (genellikle modern işletim sistemlerinde uygulanır). Daha fazla ayrıntı için ayrıca Vikipedi , İstenilen ve /crypto//q/48302/351 (sizin zaten farkında olduğunuz anlaşılıyor) bakın.

Son olarak, açacağınız hakkında bir yorum yapın:

“Deterministik yollarla rasgele sayılar üretmeye çalışan herkes, elbette bir günah durumunda yaşamaktadır”.

Bu her zaman yalnızca bir bilgisayarla gerçek rasgele sayılar üretemeyeceğiniz anlamına gelir.

Hayır, genelde böyle yapılmaz ve söylediği şey bu değildir. Deterministik yollarla gerçek rasgele sayılar üretemeyeceğinizi söylüyor . Bir bilgisayarda yapıp yapamayacağınız, bilgisayarın deterministik olup olmamasına bağlıdır. Bilgisayar deterministic ise veya programınız sadece deterministic işlemleri kullanıyorsa, kullanamazsınız. Bununla birlikte, çoğu bilgisayar deterministik olmayan öğeler içerir ve eğer programınız bunları kullanıyorsa, rasgele sayılar üretmek için kullanılıp kullanılamayacağına karar vermeden önce daha ayrıntılı analiz gerekir. Sizin durumunuzda nanoTime()deterministik değil.

Eğer bir donanım entropi / rastgelelik kaynağı kullanıyorsanız, " deterministik yollarla rastgelelik yaratmaya çalışmıyorsunuz " (vurgum). Herhangi bir donanım entropi / rastgelelik kaynağı kullanmıyorsanız, o zaman daha güçlü bir bilgisayar sadece saniyede daha fazla günah işleyebileceğiniz anlamına gelir.

Deterministik bir algoritmanın sabit miktarda bir entropiye sahip olduğu anlamına gelen alıntıyı her zaman anladım ve çıktı "rasgele" görünse de, girdilerin sağladığından daha fazla entropi içeremez. Bu açıdan bakıldığında, algoritmanızın entropi içinde kaçakçılık yaptığını görüyoruz System.nanoTime()- "deterministik" bir algoritmanın tanımlarının çoğu bu işlevi çağırmaktan vazgeçer.

Alıntı - özlü iken - aslında bir totolojidir. Bunu kanıtlayacak hiçbir şey yok ve artık onu doğrulayamayacak bir donanım evrimi mümkün değil. Donanımla ilgili değil, deterministik bir algoritmanın tanımı ile ilgili. Sadece determinizm ve rastlantısallığın uyumsuz olduğunu gözlemliyor. Herhangi bir deterministik algoritma için, davranışının tamamı başlangıç ​​koşullarına göre tahmin edilir. Bir istisna bulduğunuzu düşünüyorsanız, deterministik olmanın ne demek olduğunu yanlış anlıyorsunuz.

Paylaşılan bir bilgisayarda çalışan ve karmaşık bir önbellek dizisi içeren ve çeşitli ağ ve donanım girişleri alan bir işlemin basit, yalıtılmış, özel donanımda çalışandan çok daha fazla entropiye erişimi olduğu doğrudur. Fakat eğer bu süreç bu entropiye eriştiyse artık deterministik değildir ve bu nedenle teklif geçerli değildir.

Deterministik yöntemlerle rasgele sayılar üretmeye çalışan herkes, elbette bir günah durumunda yaşamaktadır.

"Günah haliyle yaşamak" ı "saçmalık yapmak" olarak yorumladığınızda, kesinlikle doğru.

Yaptığın şey, System.nanoTime()oldukça zayıf rastgelelik oluşturmak için oldukça yavaş bir yöntem kullanmak. Biraz ölçtün

... entropi oranı ~ 5.3 bit / bayt ...

ama bu sadece üst sınır. Tüm alabileceğiniz bir üst sınırdır. Gerçek entropi, daha küçük büyüklükteki emirler olabilir.

Bunun yerine, diziyi MD5 gibi bir kriptografik karma kullanarak doldurmayı deneyin. Gibi bir sıra hesaplayın md5(0), md5(1), ...(her değerden bir veya daha fazla bayt alınan, bu önemli değil). Hiç sıkıştırma alamayacaksınız (evet, MD5 bozuk, ancak yine de sıkıştırılamaz veri üretmek için yeterince iyi).

Hiç entropi olmadığını söyleyebiliriz, ancak 8 bit / bayt ölçtünüz.

Gerçekten rastgele bir şeye ihtiyacınız olduğunda, sadece bir HW kaynağı kullanmak zorunda değilsiniz, aynı zamanda ne kadar entropi ürettiğine dair kesin bir sınır olduğunu bilmek zorundasınız . Muhtemelen bazı rasgelelikler olsa da nanoTime(), üzerinde önemsiz olmayan alt sınırların farkında değilim.

Kriptografi için rastgele olmanız gerektiğinde, gerçekten işletim sisteminiz, diliniz veya iyi bir kütüphane tarafından sağlanan bir şeye başvurmak zorundasınız. Bu sağlayıcılar, birden fazla kaynaktan ve / veya tahsis edilmiş HW'den entropi toplar ve bu entropi tahminlerine oldukça fazla çalışma yapılır.

Genellikle neredeyse hiç entropiye ihtiyacınız olmadığını unutmayın. Birkaç rastgele byte ile başlatılan iyi (deterministik) bir PRNG, kriptografi için ve dolayısıyla başka her şey için kullanılabilir.

"Rastgele" anlamına geldiğimi düşündüm. Buradaki cevapların çoğu , deterministik işlemlerin çıktısına kıyasla rastgele işlemlerin çıktısı hakkında konuşuyor . Bu "rastgele" nin mükemmel bir anlamı, ama tek değil.

Rastgele işlemlerin çıktısı ile ilgili bir problem, deterministik işlemlerin çıktılarından ayırt etmek zor olmalarıdır: kaynaklarının ne kadar rasgele olduğuna dair bir "kayıt" içermemektedirler. Buna aşırı bir örnek, rastgele bir sayı üreticisinin her zaman geri döndüğü , bir kalıp rulosundan geldiğinden dolayı rastgele olduğunu iddia eden bir kod yorumuyla ünlü bir XKCD çizgi romanıdır4 .

Kolmogorov karmaşıklığı olarak adlandırılan "rastgelelik" tanımına alternatif bir yaklaşım , nasıl üretildiğine bakılmaksızın verinin kendisine dayanır. Bazı verilerin Kolmogorov karmaşıklığı (örneğin bir sayı dizisi), bu verileri veren en kısa bilgisayar programının uzunluğu: veriler daha yüksek bir Kolmogorov karmaşıklığına sahipse "daha rastgele".

PNG gibi sıkıştırma algoritmalarını kullanmanız ve sıkıştırma öncesi ve sonrası uzunluğu karşılaştırmanız Kolmogorov karmaşıklığı fikrine benzer. Bununla birlikte, Kolmogorov karmaşıklığı, PNG gibi sınırlı bir formattan ziyade, herhangi bir Turing-komple programlama dilinde bir program olarak kodlanmasına izin verir; Bu kodlamaların (programların) "dekompresyonlanması", çalıştırılarak yapılır; bu, keyfi bir zaman ve hafıza alabilir (örneğin cılız evrenimizde mevcut olandan daha fazlası).

Rice teoremi bize genel olarak sonsuza dek döngü kuran programlar ile verilerimizi çıkaran programlar arasında ayrım yapamayacağımızı söyler. Bu nedenle, bazı verilerin Kolmogorov karmaşıklığını bulmak çok zordur: bu verileri üreten bir program yazarsak, aslında daha kısa bir program olabilir (örneğin daha düşük bir karmaşıklık), ancak bunu fark edemedik çünkü Sonsuz bir döngüden ayırt. Bu yüzden Kolmogorov karmaşıklığı tartışmasızdır, ancak Busy-Beaver sayılarını bilseydik, her programı kontrol ettiğimiz süreyi sınırlamak için bunları kullanarak hesaplayabilirdik.

Örnek verileriniz durumunda, Kolmogorov karmaşıklığını bulmak için (yani “gerçek rastgelelik”) aynı bayt sırasını çıkaran en kısa deterministik programı bulmamız ve uzunluğunu almamız gerekir.

Şimdi sorunuzu Kolmogorov karmaşıklığı bakış açısıyla yanıtlayabiliriz ve teklifin doğru olduğunu tespit ediyoruz: deterministik yollarla rastgele sayılar (yüksek Kolmogorov karmaşıklığı) oluşturamayız.

Neden olmasın? Küçük bir bilgisayar programı yazdığımızı ve rasgele sayılar dizisi oluşturmak için kullandığımızı düşünelim. Aşağıdaki durumlardan birinin geçerli olması gerekir:

• Büyük miktarda çıktı üretiyoruz. Ancak, bu çıktının küçük bir program tarafından üretildiğini bildiğimiz için, çıktı (tanım gereği) Kolmogorov karmaşıklığını düşüktür ve bu nedenle bu anlamda "rastgele" değildir.
• Bunları yazmayı bırakacak kadar az sayı üretiyoruz, kısa üretme programımızı yazmaktan çok, aynı, hatta daha az bit. Bu durumda, sayılar nispeten sıkıştırılamaz niteliktedir, bu Kolmogorov anlamında oldukça rastgele olduklarını gösterir. Çıkış listesi miktarı (program için kaynak kodu) koymak için karşılaştırılabilir olduğundan, ancak, 's adil programı rastgeleliğine "üretmek" olmadığını söylemek, biz o programı seçerek yaptı. Sonuçta, bu durumda, üretme programımız bu tam sayıların bir listesi olabilir (örn. print([...])).

Her iki durumda da, koyduğumuzdan daha fazla rastgelelik "üretmiyoruz" (üretim programımızın kaynak kodunun "rastgeleliği"). Çıkışın kısa bir üreteçe sahip olmasını önlemek için daha uzun bir üretken program kullanarak bu sorunu çözmeye çalışabiliriz, ancak bunu yapmanın sadece iki yolu vardır:

• Sistematik olarak, kodu bir şekilde "şişir". Bununla birlikte, Kolmogorov karmaşıklığı o programa bakım değildir biz verilerini oluşturmak için kullanılmıştır: sadece bakımları yaklaşık hangisi program üretme küçüğüdür. Sistematik kabarma Kolmogorov karmaşıklığını eklemez, çünkü koddaki bu tür kalıplar çok az miktarda kodla üretilebilir. Örneğin, almak run(shortGenerator)için bir miktar sistematik şişirme yükler ve eklersek run(bloatedGenerator), formdan hala kısa bir jeneratör vardır run(addBloat(shortGenerator)).
• Sistematik olmayan , yani herhangi bir şablon olmadan şişkinlik ekleyin , böylece bir addBloatfonksiyonun kodun kendisi kadar şişirilmiş olması gerekir. Ancak, kalıplardan yoksun olmak, rastgele bir şey yapan şeydir (yüksek Kolmogorov karmaşıklığı). Bu nedenle, bu şekilde üretim programı şişkinlik yok çıkış rastgelelik (Kolmogorov karmaşıklığı) artış, ancak , aynı zamanda , biz kaynak kodu şeklinde temin etmek üzere olduğu rasgelelik (Kolmogorov karmaşıklığı) miktarını artırır. Dolayısıyla, programı değil, "rastgeleliği" sağlayan bizleriz. Yukarıdaki yazı yazma örneğinde, print([...])sistematik olmayan şişkinlik eklenmesi, bu kodlanmış listede sadece "rastgele" sayıları yazmaya eşdeğerdir.

Sıkıştırma, rastgele bir kesinlik testi değildir ve bir görüntüye bakıp “rastgele görünen” demektedir.

Rasgelelik ampirik yöntemlerle test edilir . Aslında rastlantısallığı test etmek için özel olarak tasarlanmış yazılım / algoritma takımları vardır, örneğin TestU01 ve Diehard testleri .

Ayrıca, resminiz aslında bir boşluğa eşlenmiş 1B'lik bir sayı dizisidir ve bu nedenle ortaya çıkabilecek belirli kalıpları iyi bir şekilde göstermez.

Görüntü pikselinizi piksel cinsinden incelemek isteseniz, büyük olasılıkla ani bir düşüşten önce artan değerlerin kısa kalıplarını bulabilirsiniz. Eğer örnek değeri olan x değeri ve 'rastgele' işlevinden elde edilen değer olan y değeri olan bir grafik oluşturmak isteseydiniz, verilerinizin aslında testere dişi dalgası gibi göründüğünü göreceksiniz:

Bu, modüler aritmetik altında artan değerlerin yaptığı kalıptır (ki bu sizin hesaplamanızın bir örneğidir: yakın bir sabit hızda zamanın artması ve & 0xFFoyunculuk gibi mod 256).

Rastgele sayılar kavramını "rastgele görünen sayılar" dan karıştırıyorsunuz.

Von Neumann'ın teklifini anlamak için, "rastgele sayılar üretmenin" ne demek olduğunu anlamamız gerekir. Warbo'nun cevabı , bu amaç için mükemmel bir XKCD'ye :

Rasgele sayılar hakkında konuştuğumuzda, değerlerin kendileri hakkında konuşmuyoruz. Açıkçası, 4, 3'ten daha rasgele değildir. Üçüncü bir tarafın bu değeri rastgele şanstan daha iyi tahmin edebilme yeteneğinden bahsediyoruz. Rastgele bir sayı, öngörülemeyen bir sayıdır. Bazen buna koşullar ekleriz. Kriptografik olarak güvenli bir sözde rasgele sayı üreteci (CSPRNG), eğer bir saldırgan tohum / anahtarı bilmiyorsa, ancak rastgele sayılardan bahsediyorsak (sözde rastgele değil) genellikle, herhangi bir anahtar da dahil olmak üzere, sistemin tam bilgisiyle bile, tahmin edilemeyen bir sayı olarak tanımlanır.

Şimdi, örneğinizin, çoğu kişinin belirttiği gibi, deterministik değil. Program hangi değerin ortaya çıktığını belirtmiyor System.nanoTime(). Dolayısıyla, sözde rasgele sayılar üretmek için bir CSPRNG kullanmakla aynı sınıfta değildir. İlki, anahtarın değerinin deterministik olup olmadığını belirleyici iken belirleyici değildir. İlki deterministik değerlere sahip olmayan tanımlanmış işlemleri içerir.

Ancak, söylediğimi not edeceksiniz olabilir nondeterministic olun. Bunun System.nanoTime()için değer sağlamak için tasarlanmadığını unutmayın. Yeterli karakteristik olmayabilir veya olmayabilir. Bir uygulama sistem saatini, System.nanoTime()tümü için yapılan aramaların 256 nanosaniyenin katlarında (veya yakın) gerçekleşeceği şekilde ayarlayabilir . Ya da Spectre'nin son zamanlardaki istismarlarının büyük tarayıcıların zamanlayıcılarının çözümlerini kasıtlı olarak azaltmalarına yol açtığı Javascript'te çalışıyor olabilirsiniz . Bu durumlarda, "rastgele sayılarınız", planlamadığınız ortamlarda yüksek oranda tahmin edilebilir hale gelebilir.

• Bu yüzden deterministik süreçlerle rasgele sayılar üretmek ... günah.
• Özel rastgele donanım ile rastgele sayılar üretmek ... günah değil.
• Bilgisayarların özgün olmayan yönleriyle rasgele sayılar üretmek ... belki de günah.

Hepsi, neyi düşündüğünüze bağlı. Aşk mektuplarınızı Sünger Bob'a şifreliyorsanız, böylece kız kardeşiniz onları okuyamazsa, rastgele sayılarınıza verilen talepler oldukça düşüktür. System.nanoTime()Yaptığın gibi kullanılmış muhtemelen yeterince iyi. Nükleer sırları aktif olarak onları arayan gelişmiş bir yabancı devlete karşı koruyorsanız, zorlukla başa çıkmak için tasarlanmış donanımları kullanmayı düşünebilirsiniz.

Talebi anladığını sanmıyorum. Mesele şu ki, eğer 'rastgele' sayı dizileri (ya da herhangi bir şey) oluşturmak için belirleyici bir prosedür varsa, o zaman kalıbı bulmak sadece bu prosedürü bulmakla görevlidir!

Dolayısıyla, bir sonraki tamsayıyı tahmin etmek için her zaman deterministik bir yöntem vardır. Bu, tam olarak, eğer rastlantısallık varsayarsak, olmasını beklemiyoruz!

Yeterince karmaşık bir deterministiklik, stokastiklikten ayırt edilemez.

- Wrzlprmft kullanıcı sayfasından

Dolayısıyla, bir şey rastgele görünse bile , onu oluşturmak için belirleyici bir prosedürümüz varsa, neden yeryüzünde 'rastgele' olarak modelleyelim?

Bu bence en önemli sorun. Sadece bir tür ayırt edilemezlik gösterdiniz PRNG’nin ve “gerçek rastgeleliği” gösterdiniz.

Bununla birlikte, bu kavramların eşit olması dolayısıyla takip etmemektedir. Özellikle, rasgelelik matematiksel, teorik bir kavramdır. Yukarıda, PRNG'yi 'gerçek rastgelelik' olarak kabul etmenin bir çelişkiye yol açtığını daha önce göstermiştik. Dolayısıyla, eşit olamazlar.

Bence diğerleri zaten bunu vurguladı, ama vurgulayan değildi, bu yüzden tartışmaya da ekleyeyim.

Diğerlerinin de belirttiği gibi, entropiyi ölçme sorunu var. Sıkıştırma algoritmaları size bir şey söyleyebilir, ancak bunlar kaynak-agnostiktir. Beri Daha fazla bilgi veri nasıl oluşturulduğuna dair, muhtemelen çok daha iyi construt olabilir onu sıkıştırmak için algoritma ve gerçek entropi çok düşük olduğunu anlama geldiğini.

Ayrıca, "bilgisayarda" ve "deterministik" ifadelerinin anlamlarını biraz yanlış anlıyorsunuz. Kesinlikle bilgisayarda sayısal olmayan işlemleri gerçekleştirebilirsiniz .

Ayrıca, aslında, sadece yaptınız , ama ilk bakışta o kadar belirgin değil.

Tipik bir deterministikRasgele sayı üretimi için algoritma yani. PRNG benzeri doğrusal eşlenik jeneratör. Onlar devletlidir. İç durum, bir sonraki durum önceki tarafından belirlendiğinden daha az entropi anlamına gelir. Bunu dalmayacağım, muhtemelen senin için açık. Önemli olan nokta, tamamen deterministik algoritmanın ne olursa olsun, yalnızca önceki durumuna bağlı olmasıdır.

Şimdi algoritmanıza bakın. Neye dayanıyor? Ne kadar devletin var? Deterministik mi?

  file.writeByte((byte) (System.nanoTime() & 0xff));

Hadi görmezden file.writegelip arabellekleri boşaltabilir, G / Ç için beklemeye devam edebilir (sabit sürücü kablolarına bir süre boyunca ağır sesler eklemeye çalıştınız mı? Hayır? hadi kaynağa odaklanalım, bu daha önemli.

zaman bir devlet çeşit. Değişir, ancak çoğu aynıdır. Bu yüzden onu atlatmaya çalıştınız ve eyaletin çoğunu düşürmek için & 0xFF kullandınız . Ama hepsini düşürmediniz, önceki okumaların bir kısmı bir sonrakine sızdırabilir, bu yüzden kesinlikle tamamen özgün değildir *)

Ama bununla ilgilenmiyoruz. Teklifin yanlış olduğunu ispatlamak için:

Deterministik yöntemlerle rasgele sayılar üretmeye çalışan herkes, elbette bir günah durumunda yaşamaktadır.

Bunu deterministik bir yöntemle kanıtlamanız gerekir.
İlgilendiğimiz şey şudur: alginiz kesinlikle tamamen belirleyici midir?

.. ve olmadığı açıktır.

  System.nanoTime() & 0xff

Bu bir zaman ölçümü. Zaman ve ölçüm . Değer önbelleğe alınmışsa, ölçüm kısmı onu deterministik hale getirebilir. Öyle olmadığını varsayıyorum , aksi halde bu işlevin bir anlamı olmazdı. O zaman, kaynaktan anında okunursa, zamana dayalı değere sahibiz. Bunu bir kez daha adanmış bir donanıma koymamanızdan beri, ( sanırım ), zaman zaman bağlam değiştirme özelliğine sahip olabilirsiniz . Özel görevlere sahip bir donanıma sahip olsanız bile, zaman kaynağındaki sıcaklık / nem kayması, veriyolu zamanlaması vb. Nedeniyle zaman ölçümü yine de belirleyici olmayabilir.

Burada katılacağımı kesinlikle kabul ediyorum. Sürüklenme fazla etki yaratacak kadar büyük olmayacak (gerçekte nanotimeolabilirlerse de). Daha da önemlisi, nanotimehızlı olması gerekiyordu. Gerçek zamanlı kaynaktan okumuyor. İşlemcinin iç talimatına / devir sayısına dayanmaktadır. Bağlam anahtarları olmadığından emin olursanız, bu aslında deterministiktir.

Demek istediğim, eğer zamanında dayanırsanız gerçekten% 100 deterministik bir algoritma çalıştırmak gerçekten çok zor olabilir ve tamamen deterministik araçlara sahip olmadığınız sürece bu teklifi ispatlamaya hakkınız yoktur.

*) İlginç bir şekilde, sert bir şekilde giderseniz muhtemelen gerçek rasgeleliği artırabilirsiniz. Her biti okumadan önce & 0x01, bit bit uygulayın ve dikkatlice bekleyin. Bu şekilde veri üretmek gülünç derecede uzun olacaktır, ancak aslında bunun gerçekten rastgele olarak kabul edilebileceğini iddia ediyorum, RTF olmayan bir ortamda çalışıyorsanız IIF ve ayrıca her bir 'fark edilebilir zamanda' IFF'nin altında durmasını sağlayacak kadar yüksek İşletim sistemi ya uykuya gitti ya da bağlam başka bir göreve geçti.

İhtiyacınız olan cevabın, cevabın cevabını kendin verdiğin bu yorumla başladığını düşünüyorum:

Kalıp, Java, JVM, işletim sistemi, CPU + önbellekleri, sabit disk, akışını yaptığım Trance müziğinin CPU / RAM döngülerini ve aralarındaki herşeyin bir sonucudur. Desen, for / next döngüsünün içindeki tek bir Java kodu satırından kaynaklanır. Entropinin önemli bir kısmı, altta yatan donanım devrelerinden geliyor.

Bunu zaten anladınız, bence: kalıbı oluşturmak için deterministic araçlar kullanmadınız .

İhmal edilemez bir kısmı deterministik olan bir bilgisayar kullandınız, ancak entropi dış determinist olmayan (ya da en azından şu andaki tüm pratik niyet ve amaçlar için deterministik olmayan) kaynaklardan geldi: siz veya dış dünya etkileşimi bilgisayarla (ve daha az bir ölçüde, bilgisayar donanımındaki işlerin zamanlamasını etkileyebilecek herhangi bir fiziksel kusur).

Bu arada, modern işletim sistemlerinin programların kullanabileceği rasgele sayı üreteçlerini tohumlamalarının büyük bir kısmı: entropiyi, donanımıyla ve saldırgan için öngörülemeyeceğini umduğu kullanıcıyla etkileşimlerinde kullanarak.

Bu arada, dış dünya entropisi aslında iyi kodlanmış şifreleme ile bugüne kadar ele alınması gereken bir problem: öngörülebilir davranışa sahipaçılışta ve çalışma süreleri boyunca, salt okunur depolama alanı olan veya ağdan gelenler gibi ve öngörülebilir bir ağ ortamına sahip olanlar (bir ağa bağlı değil veya ağdaki iş yükü gibi) her şeyin içinde verilecek kadar düşüktür. kabaca tutarlı davranışı olan aynı sınırlı yazılım setini çalıştıran güvenilir bir süre), tahmin edilemez olduğu varsayılan bileşenlerden elde ettikleri entropiyi büyük ölçüde tahmin edebilir ve daha tahmin edilebilir sayılar üretebilir. Arka planda sizin için her türlü başka şeyi yapan (müzik akışı, dropbox ile senkronize, ne olursa olsun) tipik bir iş istasyonuna gittiğinizden.

Bence çoğu cevap bir döngüde alınan nanosaniye cinsinden son sekiz bit zaman ölçümünün kontrol edilmesinin o entropiyi hasat etmenin iyi bir yolu olup olmadığına odaklandığını düşünüyorum. Bu çok örneğinizdeki metodu pratikte rastgele bir sayı üretme şeması olarak kullanmadan önce doğru cevaplamanız için önemli bir sorudur , fakat sorduğum şeyden ayrı bir soru.

Önceki cevaplara eklemek için, işte bu soruyu düşünmenin kolay bir yolu.

Her şey rastgele ve deterministik arasındaki farkla ilgili . Daha sonra Von Neumann'a ve ne söylediğini göreceğiz.

Rastgele numaralar

Gerçek bir rasgele sayı üreteci, şimdiye kadar verilen diziyi verilen bir sonraki sayıyı tahmin etmek için kullanabileceğimiz arka planda bile gizlenmeyen bir düzen içermez. İdeal bir dünyada, fiziksel evrende ve sistem hakkında, nanosaniye ile nanosaniye ile ilgili bilmeniz gereken her şeyi biliyor olabilirsiniz ve yine de bir sonraki sayıyı denemek ve tahmin etmek yararsız olacaktır.

Bu ideal bir durumdur - pratik terimlerle oraya “kötü yaklaşımlar” olarak rastgele ya da gerçekten rastgele olan ya da matematiksel olarak hesaplanamayanlara çok yakın olduklarını kanıtlayabileceğiniz şeyleri matematiksel olarak birleştiren birçok kaynağı bir araya getirerek elde ederiz. belirli numaralara veya kalıplara karşı önyargısızlık.

• "İyi" kaynaklar, radyoaktif bozulma sürecini veya doğası gereği öngörülemeyen diğer kuantum işlemlerini beklemeye benzer şeylerdir. Isıya duyarlı yarı iletkenden çıkış. Bir diyot veya başka bir elektrikli malzemede rastgele ses. Güneşten gelen fotonları saymak.

• Buna karıştırarak, bunlara herhangi bir bağlantısı olmadığından yardım eden "fena değil" olarak düşündüğümüz bazılarını da ekleyebiliriz: Bir sonraki mouseclick veya ağ paketini beklemek. Bir sonraki dosyada son mikrotime yazma. "Bilinen ancak matematiksel olarak oldukça rastgele" bir yalancı sayı üreteci fonksiyonunun çıktısı. Rasgele sayıların önceki kullanımlarından önceki entropi.

Buradaki amaç, bildiğiniz evrende ne olursa olsun , hala tahmin edilemeyen bir sayı elde etmek ve matematiksel olarak algılanabilir bir düzen, önyargı veya öngörülebilirlik ve bir olayla korelasyon göstermeyen, bu kadar muhtemel olması muhtemeldir. tahmin için izlenebilir ve kullanılabilir. (Ya da bir olayla ilişkilendirildiyse, bağlantı "son fare tıklaması yalnızca zamanının nanosaniye basamağı" gibi inanılmaz derecede zahmetli olacak şekilde yapılır)

Deterministik sayılar

Matematikçiler, formüller ve işlevler hakkında bir şeyler ispatlayabilirler. Böylece, bir fonksiyonun, tekrar tekrar çağrıldığında, "bunlar tekrar tekrar çağırılırsa o fonksiyonun çıkışları" dır, basit bir kalıp dışında herhangi bir forma hiçbir önyargı veya tercih vermediğini kanıtlamak mümkündür.

Örneğin, 1 ile 10 milyon arasında bir sayı seçerseniz, onu ikilik olarak yazın ve tekrar tekrar "hash" yapın, oldukça rasgele görünen bir rakam dizisi elde edersiniz. Neredeyse rastgele - ama aslında hiç rastgele değil. Algoritmayı ve herhangi bir durumu, bir sonraki sayının ne olacağını tahmin edebilirsiniz.

Biz ona "sahte" diyoruz, çünkü öyle gözüküyor ve görünüşte bile rastgele görünüyor.

İşte güzel bir örnek. Bu 3 basamaklı "rastgele sayılar" dizisini düşünün: 983, 367, 336, 244, 065, 664, 308, 602, 139, 494, 639, 522, 473, 719, 070, 217. Size söyleyeyim diyelim Aynı şekilde bir milyon sayı üretebilirim. Daha sonra, eşit olarak ya da her ne olursa olsun dağıldığını onaylayacak (söyleyecek) bir istatistikçiye geçebilirsiniz. Açıkça tahmin edilebilir bir patern yok. Oldukça rastgele görünüyorlar, değil mi? Ama şimdi sana gerçekte olduklarını söylüyorum

Pi'nin 500'üncü + basamağı 3'lü olarak gruplandırıldı.

Birdenbire, ancak rastgele

Pi rakamları

olabilir, hemen sonraki 2 sayının 986 ve 094 olacağını tahmin edebilirsiniz.

Açık olmak gerekirse, tam olarak ne kadar rastgele bilmiyorum

Pi rakamları

vardır. Çalışılacak ve iyi bilinen bir cevap olacaktır. Ancak mesele şudur: Prensipte, aynı sonuç, deterministik bir süreçten sonra üretilen herhangi bir kaynak için geçerlidir .

Arasında

İkisi arasında, "rastgele görünen ve genellikle bir dereceye kadar rastgele olan şeyler" dizisinin tamamı vardır. Ne kadar rastgele ve ne kadar rastlantısallık karıştırabilirse, çıktının algılanan herhangi bir patern ya da herhangi bir çıktının matematiksel olarak tahmin edilebilmesi mümkün olmaz.

Von Neumann ve sorunuza geri dönün

Görebildiğiniz gibi, deterministik çıktılar rastgele görünebilir, ancak istatistiksel olarak rasgele dağıtılabilir. Bilme gerçekçi bir umudumuz olmayan "gizli" veya hızlı değişen verileri bile kullanabilirler. Ancak, deterministik olduğu sürece, rakamlar hiçbir zaman gerçekten rastgele olamaz . Onlar sadece "farkı unutmaktan mutlu olduğumuz için rastgele yakın" olabilirler.

Verdiğin teklifin anlamı bu. Deterministik bir süreç rastgele sayılar veremez. Sadece rastgele sayılar gibi görünen ve oldukça benzeyen sayılar verebilir.

Şimdi sorunuzu şu şekilde yeniden ifade edebiliriz: "Benim (veya herhangi bir modern) bilgisayarımın çıktısı tamamen rastgele görünebilir ve davranabilir, bu von Neumann'ın teklifinin artık eski ve yanlış olduğu anlamına mı geliyor?"

Sorun hala şudur: Bilgisayarınızın çıktısı rasgele olarak görünse ve davransa bile, yine de gerçekten rastgele olmayabilir . Eğer sadece deterministik olarak hesaplanırsa, bu, bir sonraki sayıyı elde etmeyle ilgili olarak tahmin edilebilecek sebep-sonuç olmayan hiçbir şeyin olmadığı anlamına gelir (bu, “deterministik” in bu anlamda ne anlama geldiğidir). Var olan bazı verilerle (bilinen) başlıyoruz, bilinen bir işlemi (karmaşık veya dağınık ya da her neyse) uyguluyoruz ve yeni bir "rastgele sayı" çıkmış gibi görünüyor. Fakat bu rastgele değil, çünkü süreç deterministikti.

Metodunuzun (yarı iletkende radyoaktif bozulma veya gürültüden kaynaklanan rastgele bir sayı gibi) düzeltmek için gerçek bir donanım rastgele üreteci içereceğini söylerseniz, cevabınız şimdi rastgele olabilir - ama tanımınızla yönteminiz artık belirleyici değil , herhangi bir daha fazla giriş / ilk veri (nedenleri) verilen çıkışları (veya efektler) tahmin edilemez çünkü tam .

Von Neumann neredeyse her iki şekilde de kazanıyor!