Son derece doğru programlar hakkında ne biliyoruz?

Bilgisayar programlarının gittikçe artan karmaşıklığı ve gittikçe önem taşıyan konum bilgisayarları toplumumuzda var ve neden kodun doğru çalıştığına dair resmi bir kanıt vermek zorunda olduğunuz programlama dillerini neden toplu olarak kullanmadığımızı merak ediyor.

Terimin 'onaylayıcı bir derleyici' olduğuna inanıyorum ( burada buldum ): bir kodun yalnızca kodu yazması gereken değil, aynı zamanda kodun özelliklerini belirttiği ve kodun uyduğunu kanıtladığı bir programlama dili derleyen bir derleyici şartname (veya bunu yapmak için otomatik bir prover kullanın).

İnterneti ararken, sadece çok basit bir programlama dili kullanan projeler buldum veya modern programlama dillerini uyarlamaya çalışan projelerden başarısız oldum. Bu beni soruma yönlendirir:

Tam gelişmiş bir programlama dili uygulayan herhangi bir onaylayıcı derleyici var mı, yoksa bu çok zor / teorik olarak imkansız mı?

Ek olarak, olarak adlandıracağım 'bu Turing makinesinin durduğuna dair bir kanıtın bulunduğu bir Turing makinesi tarafından onaylanabilen tüm dillerin sınıfı' gibi, provable programları içeren herhangi bir karmaşıklık sınıfını henüz görmedim . , özyinelemeli dilleri kümesi.$ProvableR$$R$

Böyle bir karmaşıklık sınıfını incelemenin avantajlarını görebiliyorum: örneğin, için Halting sorunu ( bariz bir şekilde tanımlanmış olan bile, karar verilebildiği en büyük dil sınıfı olurdu). Ek olarak, pratik olarak yararlı herhangi bir programı ekarte edeceğimizden de şüpheliyim: sonlandırdığını ispatlayamazsanız kim bir program kullanır?$ProvableR$$ProvableRE$

Yani ikinci sorum şu:

İçerdikleri dillerin kesin olarak belli özelliklere sahip olmasını gerektiren karmaşıklık sınıfları hakkında ne biliyoruz?

"Sertifika Derleyici" genellikle biraz farklı bir şey ifade eder: Bu, yayınladığı makine kodunun yüksek seviye anlambilimini doğru şekilde uyguladığını ispatlayabilecek bir derleyiciniz olduğu anlamına gelir. Yani, bu derleyici hataları olmadığının bir kanıtı. İnsanların derleyiciye verdiği programlar hala yanlış olabilir, ancak derleyici yanlış programın doğru bir makine kodu sürümünü üretecektir. Bu satırlar boyunca en büyük başarı hikayesi , büyük bir C alt kümesinin derleyicisi olan CompCert onaylı derleyicidir .

Compcert derleyicisinin kendisi, bir program için kod oluşturması halinde (CompCert tasarımcılarının kullandığı montaj & C işletim anlamında) doğru olacağını garanti eden (Coq'da yapılan) bir doğruluk kanıtı olan bir programdır. Bunları makine kontrol etme çabası oldukça büyük; Genellikle doğruluk kanıtı, doğruladığınız programın boyutunun 1x ile 100x arasında herhangi bir yerde olacaktır. Makine kontrollü programlar ve provalar yazmak, öğrenmeniz gereken yeni bir beceridir - her zamanki gibi yapmasına bağlı olmasına rağmen, her zamanki gibi matematik veya programlama değildir. Sıfırdan başlıyormuş gibi hissediyorsunuz, yine acemi bir programcı olmak gibi.

Bununla birlikte, bunun için özel bir teorik engel yoktur. Bu satırlar boyunca tek şey, Blum Size teoremidir , tüm programların toplam olduğu herhangi bir dil için, bir programı genel özgeçmişli bir dilde bulabilirsin; bu, toplam dilde programlandığında en azından üssel olarak daha büyük olacaktır. Bu sonucu anlamanın yolu, toplam dilin sadece bir programı değil, aynı zamanda bir sonlandırma kanıtını da kodlamasıdır. Böylece, uzun süreli sonlandırma kanıtları olan kısa programlarınız olabilir. Ancak, bu uygulamada gerçekten önemli değil, çünkü yalnızca yönetilebilir sonlandırma kanıtları olan programlar yazacağız.

EDIT: Dai Le, son noktanın biraz detaylandırılmasını istedi.

Bu, çoğunlukla bir programın neden çalıştığını anlayabiliyorsanız, bunun sebebinin büyük miktarda değişmeyen milyonlarca sayfa uzunluğunda olması ihtimaline dayanan pratik bir iddiadır. (Kullandığım en uzun değişmezler birkaç sayfa uzunluğunda ve oğlanlar hakemleri huysuzlaştırıyorlar! Anlaşılır bir şekilde öyle, çünkü değişmez, programın insanların onu anlamalarına yardımcı olan tüm anlatıdan çıkarılmasının nedeni budur.)

Fakat aynı zamanda bazı teorik nedenler de var. Temel olarak, doğruluğu kanıtları çok uzun olan programları sistematik olarak icat etmenin çok fazla yolunu bilmiyoruz. Ana yöntem (1) doğruluğu kanıtladığınız mantığı benimsemek, (2) doğrudan bu mantıkla ifade edilemeyen bir özellik bulmak (tutarlılık kanıtları tipik kaynaktır) ve (3) bir program bulmaktır. doğruluk kanıtı, ifade edilemez özelliğin ifade edilebilir sonuçlarının bir ailesine dayanır. (2) ifade edilemez olduğu için, bu her ifade edilebilir sonucun kanıtının bağımsız olarak yapılması gerektiği anlamına gelir, bu da doğruluk kanıtının boyutunu arttırmanıza izin verir. Basit bir örnek olarak, ebeveyn ilişkisine sahip birinci dereceden bir mantıkta, ata ilişkisini ifade edemeyeceğinizi unutmayın.$k$$k$) Her sabit için açıktır . Bu nedenle, ataların bazı özelliklerini bir derinliğe kadar (örneğin, 100) kullanan bir program vererek, bu özelliklerin kanıtlarını yüzlerce kez içermesi için FOL'de bir doğruluk kanıtı zorlayabilirsiniz.$k$

Bu konudaki sofistike yaklaşım "ters matematik" olarak adlandırılır ve verilen teoremleri ispatlamak için hangi aksiyomların gerekli olduğunun araştırılmasıdır. Bu konuda pek bir şey bilmiyorum, ancak CS ile ilgili bir soru gönderirseniz, eminim en azından Timothy Chow ve muhtemelen birkaç kişi daha ilginç şeyler söyleyebilecek.

Bence ilk sorunun cevabı genel olarak mevcut araçlarla çok fazla çalışmak olduğu. Bu hissi elde etmek için, Coq'daki Bubble Sort'un doğruluğunu ispat etmeye çalışmanızı öneririm (veya biraz daha fazla zorluk tercih ederseniz, Quick Sort kullanın). Bu temel algoritmaların doğruluğunu kanıtlamak çok zor ve zaman alıcı olduğu sürece, programcıların doğrulanmış programlar yazmasını beklemenin makul olduğunu düşünmüyorum.

Bu soru, matematikçilerin neden kanıt denetçileri tarafından doğrulanabilir resmi kanıtlar yazmadığını sormaya benzer mi? Resmi doğruluk kanıtı olan bir program yazmak, yazılı kod hakkında matematiksel bir teorem kanıtlamak anlamına gelir ve bu sorunun cevabı da sorunuza uygulanır.

Bu, doğrulanmış programların başarılı olamadığı anlamına gelmez. Microsoft'un hiper yöneticisi gibi sistemlerin doğruluğunu kanıtlayan gruplar olduğunu biliyorum . İlgili bir durum, Microsoft’un Verified C Compiler’ıdır . Ancak, genel olarak mevcut araçlar, genel programcılar (ve matematikçiler) için faydalı hale gelmeden önce (SE ve HCI yönleri dahil) çok fazla gelişmeye ihtiyaç duyar.

Neel'in sadece toplam fonksiyonlara sahip diller için program büyüklüğü büyümesiyle ilgili cevabının son paragrafı ile ilgili olarak, aslında daha fazlasını kanıtlamak kolaydır (Doğru anladım) Herhangi bir programlama dilinin sözdiziminin ce olmasını ve toplam hesaplanabilir fonksiyonların kümesinin ce olmamasını beklemek mantıklıdır, bu nedenle, tüm programların toplam olduğu herhangi bir programlama dili için, herhangi bir program tarafından hesaplanamayan toplam bir hesaplanabilir fonksiyon vardır. herhangi bir boyutta) bu dilde.

İkinci soru için, bir süre önce Scott'ın blogunda benzer bir soruyu cevapladım. Temel olarak eğer karmaşıklık sınıfı iyi bir karakterizasyona sahipse ve hesaplanabilir şekilde gösterilebilirse (yani ce ise) o zaman karmaşıklık sınıfındaki problemlerin bazı temsillerinin karmaşıklık sınıfına karşılık gelen çok zayıf teorilerde toplam olduğunu kanıtlayabiliriz. Temel fikir, teorinin ispatlanabilir toplam fonksiyonlarının tüm fonksiyonlarını ve karmaşıklık sınıfı için bir problemi içermesidir , bu yüzden karmaşıklık sınıfındaki tüm problemleri içerir ve bu programların toplamını ispatlayabilir. . İspatlar ve karmaşıklık teorisi arasındaki ilişki ispat karmaşıklığında incelenmiştir, bkz. SA Cook ve P. Nguyen'in son kitabı "$AC^0$$AC^0$Prova Karmaşıklığının Mantıksal Temelleri "eğer ilgileniyorsanız. ( 2008'den bir taslak mevcuttur.) Bu yüzden temel cevap," Provably C = C "sınıfları için.

Bu, genel olarak doğru değildir çünkü sözdizimsel karakterizasyonu olmayan anlamsal karmaşıklık sınıfları vardır, örneğin toplam hesaplanabilir fonksiyonlar. Özyinelemeli olarak toplam özyinelemeli işlevler kastediyorsanız, o zaman ikisi eşit değildir ve bir teoride kanıtlanabilir toplamı olan hesaplanabilir fonksiyonlar kümesi, kanıt teorisi literatüründe iyi çalışılmıştır ve teorinin kanıtlanabilir toplam işlevleri olarak adlandırılır . Örneğin: bir kanıtlanmıştır toplam fonksiyonları olan -Recursive fonksiyonları (Godel'in sistemi eşdeğer işlevleri ) 'in kanıtlanmıştır toplam fonksiyonları Girard sisteminde fonksiyonu olan , ve kanıtlanmıştır toplam fonksiyonları$PA$$\epsilon_0$$T$$PA^2$$F$$I\Sigma_1$ ilkel özyinelemeli fonksiyonlar,.

Fakat bunun bana program doğrulama bağlamında çok şey ifade ettiği görülmüyor, çünkü aynı işlevi aynı anda hesaplayan programlar da var, ancak iki programın da aynı işlevi hesapladığını kanıtlayamıyoruz; kasıtlı. (Bu, Sabah Yıldızı ve Akşam Yıldızına benzer.) Ayrıca, teorinin bütünlüğünü ispatlayamayacağı bir programın elde edilmesi için belirli bir toplam programın değiştirilmesi kolaydır.

İki sorunun birbiriyle ilgili olduğunu düşünüyorum. Amaç doğrulanmış bir program elde etmektir. Doğrulanmış programlar, programın matematiksel bir ifade olan bir açıklamayı yerine getirdiği anlamına gelir. Bunun bir yolu, bir programlama dilinde bir program yazmak ve daha sonra genel uygulama olan açıklamayı yerine getirdiği gibi özelliklerini ispatlamaktır. Diğer bir seçenek ise, sorunu açıklayan matematiksel ifadeyi kısıtlı yollarla kanıtlamaya çalışmak ve ondan doğrulanmış bir program çıkarmaktır. Biz tekabül eden teorik olarak ortaya çıkması halinde, örneğin, , herhangi bir sayısı için , ürün eşittir asal bir sayı dizisi vardır , o zaman özü$P$$n$$n$$P$ispatından çarpanlara ayırma için algoritma. (İlk yaklaşımı mümkün olduğunca otomatize etmeye çalışan araştırmacılar da var, ancak programların ilginç önemsiz özelliklerini kontrol etmek hesaplama açısından zor ve yanlış pozitifler ve negatifler olmadan tam olarak doğrulanamıyor.)

İlk soruda sorduğunuz şey bazen "doğrulayıcı bir derleyici" olarak adlandırılır ve birkaç yıl önce Tony Hoare bunu bilgisayar araştırması için büyük bir zorluk olarak sundu . Bir dereceye kadar bu zaten mevcut olan ve problemi tip teorisi ve tip olarak önerme ilkesi (" Curry-Howard ") ile organize eden Coq teoremi prover'i gibi araçlarda aktif olarak kullanılmaktadır .

EDIT: Sadece "bir dereceye kadar" vurgusu eklemek istedim. Bu çözülmemiş bir sorun olmaktan uzak, ancak Coq'un başarısı bunun kesin bir rüya olmadığını umuyor.

Bir programın doğru olup olmadığını kontrol eden bir araca bazen program doğrulayıcı adı verilir. Bu bağlamda, "doğru" genellikle iki şey ifade eder: programın hiçbir zaman belirli çıktılar üretmediği (düşünme segmentasyon hatası, NullPointerException, vb.) Ve programın bir şartname ile aynı fikirde olduğu anlamına gelir.

Kod ve şartname kabul edilebilir ve yine de yanlış olarak algılanabilir. Bir anlamda, geliştiricilerden özellikler yazmasını istemek, iki geliştiriciden sorunu çözmesini istemek gibidir. İki uygulama da aynı fikirdeyse, tamam olduklarına daha fazla güvenirsiniz. Bununla birlikte, başka bir deyişle, özellikler ikinci bir uygulamadan daha iyidir. Spesifikasyonun verimli olması ve hatta çalıştırılabilir olması gerekmediğinden, çok daha özlü olabilir ve bu nedenle yanlış yapmak daha zor olabilir.

Bu uyarılar dikkate alındığında, Spec # program doğrulayıcıya bakmanızı tavsiye ederim .

Genel durumda, bir algoritmanın bir spesifikasyona eşdeğer olup olmadığını onaylayan bir algoritma oluşturmak mümkün değildir. Bu gayri resmi bir kanıt:

Neredeyse tüm programlama dilleri Turing-tamamlandı. Bu nedenle, bir TM tarafından karar verilen herhangi bir dile, bu dilde yazılmış bir program tarafından da karar verilebilir.

İki olarak bilinen aynı dili kabul edip etmediğini belirleme sorunu tespit edilemez. Turing'in eksiksiz olmasının bir sonucu olarak, aynısı, verilen dilin programları için de geçerlidir. Başka bir deyişle, programınızın kabul etmesini istediğiniz girişlerin ve gerçekte yaptığı girişlerin aynı olup olmadığını bilmek kararsızdır.$Equivalence/TM$

Dahası, tekrarlamalı sayılar bile değildir. Bunun nedeni, (bir TM'nin en az bir girişi kabul edip ) kabul edilebilir bir dil olmasıdır, çünkü tüm olası girişleri yineleyebilirsiniz. TM boş değilse, sonunda kabul edilen bir kelime bulacaksınız. Bu nedenle, kabul edilemezdir, aksi takdirde, karar verilebilir (ki olmadığını biliyoruz). Ancak, Emptiness / TM, TM'ye düşürülebilir , dolayısıyla de kabul edilemez. Bu nedenle, iki makinenin eşdeğer olup olmadığına dair bir algoritma kullanabilirsiniz, ancak bunların eşdeğer olup olmadığından emin olamazsınız veya algoritmanıza yeterince zaman vermediniz.$Equivalence/TM$$Non-emptiness/TM$$Emptiness/TM$$Emptiness/TM$$Equivalence/TM$$Equivalence/TM$

Ancak, bu sadece genel durum için. Sorunun daha rahat bir versiyonunu çözerek özelliklerin programla aynı olup olmadığına karar vermeniz mümkündür. Örneğin, yalnızca birkaç girdiyi inceleyebilir veya iki programın bazı belirsizliklerle eşdeğer olduğunu söyleyebilirsiniz. Bu, yazılım testlerinin neyle ilgili olduğu.

Diğer sorularınız için:

Not: Bu bölüm açıklama için düzenlenmiştir. Kaçınılmaya çalıştığım hatayı yaptığım ortaya çıktı, üzgünüm.

, karar verilebileceğini bildiğimiz dillerin bir koleksiyonu olsun . Tabii ki . Kişi daha sonra şunları kanıtlayabilir:$TrueR$$TrueR \subseteq R$

$ProvableR = TrueR$ . Bunun olduğunu görmek kolaydır . Ancak, aynı zamanda . Kanıt çok kolaydır: . Tanım olarak, her girişinde YES veya NO. Bu nedenle, her girişte durur. olduğunu .$ProvableR \subset TrueR$$TrueR \subset ProvableR$$A \epsilon TrueR$$A$$A$$A \epsilon ProvableR$

Gayriresmi olarak, bu şöyle özetlenebilir: Bir dilin böyle olduğunu kanıtlayana kadar karar verilebileceğini bilmiyorsunuz. Dolayısıyla, resmi bir sistemde bir dilin geçerliliği olduğu bilgisine sahipseniz, bu bilgi bunun için bir kanıt olabilir. Bu nedenle, bir dilin hem karar verilebileceğini hem de kanıtlanamayacağı bilgisine aynı anda sahip olamazsınız, bu yüzden bu iki ifade birbirini dışlar.

Son noktam, bilgimizin kısmi olduğu ve çalışmanın tek yolunun ile . Bu ayrım matematikte anlamlı olabilir ve bunu kabul edebiliriz, ancak çalışacak hiçbir aracımız yok. Yana , tamamen bilemezsin bağlanmıştır bütünüyle.$R$$ProvableR$$ProvableR \subset R$$R$

@Kaveh bunu en iyi şekilde özetler: Provable, her zaman bazı sistem / teorilerde kanıtlanabilir anlamına gelir ve genel olarak gerçeklerle örtüşmez.

Aynısı başka bir karmaşıklık sınıfı için de geçerlidir: Üyeliği belirlemek için önce bir kanıt gerekir. Bu nedenle, ikinci sorunuzun çok karmaşık olduğuna inanıyorum, çünkü dilin sahip olmasını istediğiniz özelliğe bağlı olarak sadece karmaşıklık teorisi değil, aynı zamanda hesaplama teorisi de var.

Aşağıdaki klasik monografi neredeyse ikinci sorunuzu tam olarak incelemektedir:

Hartmanis, J. Uygulanabilir hesaplamalar ve ispatlanabilir karmaşıklık özellikleri , Uygulamalı Matematik Alanında CBMS-NSF Bölgesel Konferans Serisi, 30. Endüstri ve Uygulamalı Matematik Derneği (SIAM), Philadelphia, Pa., 1978.

Örneğin, "F-TIME [T (n)]" (F bazı makul bir resmi ispat sistemidir) (burada , tam bir TM listesinde i-th Turing makinesidir ve , maksimum çalışma . uzunluk girişleri ). Sorunuzla ilgili birkaç sonucu vurgulamama izin verin - monografide ve referanslarda daha birçok şey bulunabilir:$\{L(M_i) | T_i(n) \leq T(n) \text{ is provable in F}\}$$M_i$$T_i(n)$$M_i$$n$

Kor. 6.4: hesaplanabilir bir fonksiyon olmasına izin verin ve in sınırsız bir hesaplanabilir fonksiyon olmasına izin verin . Ardından - .g ( n ), ≥ 1 K T ı M D [ t ( n ) ] ⊊ T ı M D [ t ( n ) g ( n ) $T(n) \geq n \log(n)$$g(n) \geq 1$$F$$TIME[T(n)] \subsetneq TIME[T(n) g(n)]$

Teorem 6.5: - olan hesaplanan monoton artan zaman sınırları vardır .$T(n)$$F$$TIME[T(n)] \neq TIME[T(n)]$

Teorem 6.14: Her türlü hesaplanabilir , .$T(n) \geq n \log(n)$$TIME[T(n)] = \{ L(M_i) | \text{F proves} (\exists j)[L(M_j) = L(M_i) \wedge T_j(n) \leq T(n)] \}$

Ancak alan için durum daha iyi kontrol edilir:

Teorem 6.9: (1) Eğer uzaydan yapılabiliyorsa, - .$s(n) \geq n$$SPACE[s(n)] = F$$SPACE[s(n)]$

(2) Eğer - ( ) ise gibi bir boşluk yapıcı .S P A C E [ S ( n ) ] S ( n ) ≥ n s ( n ) S P A C E [ S ( n ) ] = S P A C E [ s ( n ) $SPACE[S(n)]=F$$SPACE[S(n)]$$S(n) \geq n$$s(n)$$SPACE[S(n)]=SPACE[s(n)]$

Sorunun doğru olarak yönlendirilmesi gerekiyor. Örneğin, hiç kimse gerçek bir programın verilen sonsuz hafızayı ve programa erişimin belirli yollarını tamamlayıp tamamlamayacağını bilmek istemez (belki de ana adresi bir sayıya kadar taşıma işlemi). Turing'in teoremi somut anlamda programın doğruluğu ile ilgisizdir ve bunu program doğrulamasının önündeki bir engel olarak belirten insanlar birbirinden oldukça farklı iki şeyi karıştırırlar. Mühendisler / programcılar programın doğruluğundan bahsettiklerinde sonlu özellikler hakkında bilgi sahibi olmak isterler. Bu aynı zamanda bir şeyin kanıtlanabilir olup olmadığıyla ilgilenen matematikçiler için de geçerlidir. Godel'in mektubu http://vyodaiken.com/2009/08/28/godels-lost-letter/ bunu biraz ayrıntılı olarak açıklar.

Yani, Entscheidungsproblem'in kararsızlığına rağmen, Evet veya Hayır sorularına ilişkin bir matematikçinin zihinsel çalışmasının tamamen bir makine ile değiştirilebileceği anlamına gelir. Ne de olsa, doğal olarak n sayısını o kadar fazla seçmek zorunda kalacaksınız ki, makine bir sonuç vermezse, sorun hakkında daha fazla düşünmenin bir anlamı yoktur.

Gerçek bir bilgisayarda çalıştırılan bir programın devasa durum kümesini incelemek ve kötü durumları tespit etmek mümkün olmayabilir, bunun neden yapılmaması gerektiğine dair teorik bir neden yoktur. Aslında, bu alanda çok ilerleme kaydedilmiştir - örneğin, bkz. Http://www.cs.cornell.edu/gomes/papers/SATSolvers-KR-book-draft-07.pdf (bunun için Neil Immerman'a teşekkürler). bana bunu anlatmak)

Farklı ve daha zor bir problem, bir programın doğru olması için hangi özelliklere sahip olmasını istediğini belirtmektir.