Herhangi bir hata yapmadan matematiksel kanıtları yazmayı, hata yapmayan bir bilgisayar programı yazmayı çok daha kolay bulduğumu fark ettim.

Görünüşe göre bu benim deneyimimden daha yaygın bir şey. Çoğu insan programlarında sürekli yazılım hataları yapar ve her zaman hatanın ne olduğunu söyleyen derleyicileri vardır. Büyük bir bilgisayar programı yazan ve bir keresinde hiçbir hata yapmayan, hiç bir şey yapamayacağına dair tam bir güven duymuş birini duymadım. (Aslında, neredeyse hiç bir program hatasızdır, hatta birçok hata ayıklanmıştır).

Yine de insanlar, tüm derleyicileri veya matematiksel ispat kitaplarını, derleyicileri olmadan, hata yaptıklarına dair geri bildirimde bulunmaksızın, bazen başkalarından geri bildirim almadan bile yazabilirler.

Açıklığa kavuşturayım. Bu, insanların matematiksel ispatlarda hata yapmadıklarını söylemek değildir, ancak hafif tecrübeli matematikçiler için bile, hatalar genellikle o kadar sorunlu değildir ve size işaret eden bir derleyici gibi bazı "dış kâhiler" yardımı olmadan çözülebilir. hata.

Aslında, durum böyle olmasaydı, o zaman matematik bana öyle geliyor ki mümkün olurdu.

Bu da bana şu soruyu sormamı sağladı: Kusursuz matematiksel kanıtlar yazmanın ve hatasız bilgisayar kodunun yazılmasının, öncekinden çok daha fazla izlenebilir olmasını sağlayacak kadar farklı olan şey nedir?

İnsanların, programcıları tembel kılan ve kodlarını titizlikle yazmak için gerekli olanı yapmalarını engelleyen, hatalarını gösteren bir derleyicinin "dış kahinesi" olduğu gerçeği söylenebilir. Bu görüş, eğer bir derleyicileri olmasaydı, matematikçiler kadar kusursuz olabilecekleri anlamına gelirdi.

Bunu ikna edici bulabilirsiniz, ancak deneyimlerime dayanarak matematiksel deliller yazıp matematiksel kanıtlar yazıyorsun, bana bunun gerçekten açıklama olmadığını sezgisel olarak gösteriyor. İki girişimde daha temel olarak farklı bir şey var gibi görünüyor.

İlk düşüncem, fark olabilir, bir matematikçi için doğru bir kanıt sadece her mantıksal adımın doğru olmasını gerektirir. Her adım doğruysa, kanıtın tamamı doğrudur. Öte yandan, bir programın hatasız olması için, sadece her kod satırının doğru olması gerekmez, aynı zamanda programdaki diğer tüm kod satırlarıyla olan ilişkisinin de çalışması gerekir.

Başka bir deyişle, eğer bir provadaki aşaması doğruysa, o zaman adımında hata yapmak hiç aşamasını karıştırmaz . Ama kod bir çizgi halinde doğru o zaman çizgisi içinde bir hata yapıyor, aşağı yazılır hattı çalışmasını etkileyecektir biz çizgi yazdıktan sonra, böylece Elimizdeki tüm diğer hatlara dikkate ilişkisini almaya. Kapsülleme ve tüm bunları, bunu sınırlamak için kullanabiliriz, ancak tamamen ortadan kaldırılamaz.Y X X Y X $X$$Y$$X$$X$$Y$$X$$X$

Bu, matematiksel bir ispattaki hataları kontrol etme prosedürünün ispat-adım sayısında esasen doğrusal olduğu, ancak bilgisayar kodundaki hataları kontrol etme prosedürünün esas olarak kod satırlarının sayısında üssel olduğu anlamına gelir.

Ne düşünüyorsun?

Not: Bu sorunun çok çeşitli gerçekleri ve bakış açılarını araştıran çok sayıda yanıtı vardır. Cevaplamadan önce, lütfen hepsini okuyun ve yalnızca eklemek için yeni bir şeyiniz varsa cevaplayın. Gereksiz cevaplar veya gerçekleri olan görüşleri yedeklemeyen cevaplar silinebilir.

Sorunuza cevap olarak bir neden ve bir yanlış anlama sunmama izin verin.

Temel nedeni o (görünüşte) doğru matematiksel kanıtları yazmak için daha kolay olduğunu onlar çok yüksek seviyede yazılı olmasıdır. Bunun gibi bir program yazabileceğinizi varsayalım:

function MaximumWindow(A, n, w):
    using a sliding window, calculate (in O(n)) the sums of all length-w windows
    return the maximum sum (be smart and use only O(1) memory)

O zamandan bu yana, bu şekilde programlarken ters gitmeye çok zor olurdu şartname programının çok daha özlü onun daha uygulanması . Aslında, sözde kodu koda, özellikle verimli koda dönüştürmeye çalışan her programcı , bir algoritma fikri ile uygulama detayları arasındaki bu büyük uçurumla karşılaşır . Matematiksel kanıtlar fikirlere daha fazla ve detaylara daha az odaklanır.

Matematiksel kanıtlar için kodun gerçek karşılığı bilgisayar destekli kanıtlardır . Bunlar, olağan metinsel kanıtlardan daha zordur ve genellikle okuyucuya "açık" olan (genellikle onları bile fark etmeyen), ancak bilgisayar için belirgin olmayan çeşitli gizli köşeleri keşfeder. Ayrıca, bilgisayar şu anda sadece nispeten küçük boşlukları doldurabildiğinden, kanıtlar, okuyan bir insanın ağaçlar için ormanı özleyeceği bir seviyeye hazırlanmalıdır.

Önemli bir yanılgı , matematiksel kanıtların genellikle doğru olduğu yönündedir. Aslında, bu muhtemelen oldukça iyimser. Hatalı karmaşık ispatlar yazmak çok zordur ve yazılar sıklıkla hatalar içerir. Belki de en ünlü son durumlar bazı 1000+ sayfalar dahil basit sonlu grupların sınıflandırılması halinde Wiles' ilk başta girişimi (bir özel durum) (Fermat'ın son teoremini ima) modülerlik teoremi ve çeşitli boşluklar vardır quasithin gruplar vardı Sınıflandırma bittikten 20 yıl sonra yazıldı.

Voevodsky'nin bir metnindeki bir hata, yazılı kanıtlardan o kadar çok şüphe uyandırdı ki , Homotopi tip teorisini , Homotopi teorisini resmi olarak geliştirmek için faydalı bir mantıksal çerçeve geliştirmeye başladı ve bundan sonra tüm çalışmalarını doğrulamak için bir bilgisayar kullandı. giriş). Bu aşırı (ve şu anda pratik olmayan) bir konum olsa da, sonuç kullanıldığında, bir kanıtı gözden geçirip doğru olup olmadığını kontrol etmesi gereken bir durumdur. Benim bölgemde, yanlış olduğu bilinen ancak asla geri çekilmemiş, uzmanlar arasında durumu ağızdan kulağa ileten birkaç makale var.

(Muhtemelen, burada doğru bir cevap yapmak için zamanım / ilgim olmadığı için, birkaç öneriyi riske atıyorum, ancak yazılanlar dikkate alındığında, aşağıda belirtilen metni (ve alıntı yapılan makalenin geri kalanını) oldukça anlayışlı buluyorum. tanınmış bir matematikçi tarafından. Belki de cevabı daha sonra geliştirebilirim.)

Tahmin ettiğim fikir, mevcut cevaptan özellikle farklı değil, bir "kanıt" veya argümanın, amacı, onları (sıkıcı) ayrıntıların ilke olarak doldurulabileceğine ikna etmek olduğu bir matematik topluluğuna ilettiğidir. tam olarak tanımlanmış bir resmi kanıt elde etmek - sık sık hiç yapmadan. Bunun kritik bir örneği, mevcut teoremleri basitçe belirterek kullanabilmenizdir, ancak kodun yeniden kullanımı genel olarak çok daha zordur. Ayrıca, tamamen bir kod parçasını tamamen işe yaramaz hale getirebilecek (örneğin, SEGFAULT'lar) olan ancak "matematiksel bir argümanı bozulmadan bırakabilirse (yani, argüman çökmeden ortaya çıkarsa)" küçük hatalar düşünün.

Bir bilgisayar programının çalışabilmesi için gerekli olan doğruluk ve bütünlük standardı, matematik topluluğunun geçerli ispat standartlarından daha büyük bir kaç derece emridir. Bununla birlikte, büyük bilgisayar programları, çok dikkatli bir şekilde yazılmış ve çok dikkatli bir şekilde test edilmiş olsalar bile, her zaman hata yapmış gibi görünmektedir. [...] Matematiği uyguladıkça, diğer bilimlerden çok daha resmi olarak eksiksiz ve kesindir, ancak içeriği için bilgisayar programlarından daha az resmi olarak eksiksiz ve kesindir. Aradaki fark, sadece çaba ile değil, aynı çaba ile niteliksel olarak farklı. Büyük bilgisayar programlarında, sayısız uyumluluk meselesine muazzam bir çaba harcanması gerekir: tüm tanımların tutarlı olmasını sağlayarak "iyi" geliştirme Faydalı ancak hantal olmayan bir genelliğe sahip, fonksiyonlar için "doğru" genelliğe karar veren vb. veri yapıları, büyük bir programın çalışma bölümünde harcanan enerjinin, defter tutma bölümünden ayırt edildiği gibi şaşırtıcı bir şekilde küçüktür. Genel olarak ve işlevsellik eklenirken “doğru” tanımların değiştiğinden, kaçınılmaz bir şekilde elden çıkmaya başlayan uyumluluk sorunları nedeniyle, bilgisayar programlarının genellikle sık sık sıfırdan yazılması gerekir.

MATEMATİKTE KANIT VE İYİLEŞME HAKKINDA (sf. 9-10), WILLIAM P. THURSTON tarafından https://arxiv.org/pdf/math/9404236.pdf

EW Dijkstra'dan alıntı yaparak başlamama izin verin:

“Programlama, uygulamalı matematiğin en zor dallarından biridir; daha fakir matematikçiler daha iyi matematikçiler olmaya devam etmişlerdir.” (EWD498’den)

Her ne kadar Dijkstra’nın “programlama” ile ne anlama geldiği mevcut kullanımdan biraz farklı olsa da, bu alıntıda hala bir miktar hak var. Diğer cevaplar, matematikteki soyutlama seviyesinin programlamadan çok daha yüksek olmasına izin verdiğinden bahsetti, bu da eğer istersen bazı zor kısımları görmezden gelebiliriz.

Ancak, bu sadece bir kanıtı ve onların olan bir bilgisayar programı, arasında daha temel bir farkın bir sonucu olduğuna inanıyoruz amaç .

Matematiksel bir ispatın asıl amacı, diğerlerinin yanı sıra, kendini matematiksel bir iddianın doğru ve belki de daha önemli, anlayışı başardığına ikna etmektir . Bu nedenle, sadece matematik dünyasında çalışmayı seçebilirsiniz; her şey tasarımın kavrayabileceği şekilde yaratılır (bazı öğrenciler farklı olsa da dilenir). (neredeyse) yalnızca matematiksel gerçeklerle ve özelliklerini anlamada kendilerini ilgilendirir.

Bu nedenle, doğru ispatlar üretmenin, hataya dayanıklı olduğuna şaşırmamalısınız: bu, tüm "alıştırmanın" noktasıdır. (Yine de bu, hataların var olmadığı ya da zorlukla var olduğu anlamına gelmez, der ki, sadece insandır, derler)

Şimdi, programlamayı düşünürsek, amacımız ne? Gerçekten anlamayı istemiyoruz, işe yarayan bir şey istiyoruz . Ama ne zaman bir şey "işe yarıyor"? Bazı garip makinelerin yapmasını istediğimiz görevi tamamlamasını ve tercihen de oldukça hızlı bir şekilde yapmasını sağlayan bir şey başarıyla yarattığımızda bir şeyler işe yarıyor.

Bu, temel farkın, amacımızın programımızın "kanıtladığı" bir teorem olarak ifade edilemeyeceği anlamına geldiğine inanıyorum, gerçek dünyada bir şeyi arzu ediyoruz (bir şey değil), bazı matematiksel bir eser değil. Bu, makineye hitap etmemiz gerektiği için (Dijkstra'nın bunu dengesizce denemenize rağmen) amacımıza tamamen teorik olarak ulaşamayacağımız anlamına gelir, aslında hangi görevi yapmak istediğimizi bildiğimizi ve aynı zamanda dikkate alınmayan şeylerin farkında olduğumuzu umuyoruz. bir şekilde.

Dolayısıyla, sonuçta, sadece denemenin ve muhtemelen başarısız olmanın, düzeltmenin, başarısız olmanın ve sonuçtan biraz memnun kalana kadar tekrar denemenin başka yolu yoktur.

Hatasız kanıt yazma hipotezinizin, hatasız programların ( @Ariel'in işaret ettiği gibi farklı ifadelerdir) daha basit olduğunu, kanıtların sıklıkla deneme ve yanılma yoluyla bir seviyede yapıldığı gerçeğine dikkat edin. Yine de, bunun ima edilen soruya biraz ışık tuttuğunu umuyorum: “Bazı teoremleri ispatlamak ile bir program yazmak arasındaki fark nedir?” ( Curry-Howard yazışmalarında dikkatsiz bir gözlemci şöyle diyebilir: “Hiç bir şey yok!”)

Yorumlarda @wvxvw'nin belirttiği gibi, 'Yapısal Programlama Üzerine Notlar'dan (EWD249, sayfa 21) aşağıdaki paragraflar çok önemlidir:

(...) Bir program hiçbir zaman kendi içinde bir amaç değildir; Bir programın amacı hesaplamaları uyarmak ve hesapların amacı istenilen etkiyi oluşturmaktır. Program, programcı tarafından yapılan son ürün olmasına rağmen, onun tarafından uyandıran muhtemel hesaplamalar - "yapımı" makineye bırakıldı! - ticaretinin asıl konusu. Örneğin, bir programcı programının doğru olduğunu söylediğinde, gerçekten uyandırabileceği hesaplamalar hakkında bir iddiada bulunur.

(...) Bir anlamda bir programın yapılması matematiksel bir teori yapmaktan daha zordur: hem program hem de teori yapılandırılmış, zamansız nesnelerdir. Ancak matematik teorisi olduğu gibi mantıklı olsa da, program sadece yürütülmesi ile anlamlıdır.

Lamport, Kanıtın nasıl yazıldığına dair kanıtlardaki hataların yaygınlığına dair bir anlaşmazlık sağlar (sayfa 8-9) :

Yaklaşık yirmi yıl önce, giriş matematik dersi için Schroeder-Bernstein teoreminin bir kanıtını yazmaya karar verdim. Bulabileceğim en basit kanıt Kelley'in klasik genel topoloji metninde. Kelley daha sofistike bir izleyici kitlesi için yazdığından, yarım sayfalık kanıtına çok fazla açıklama eklemeliydim. Kelley'nin ispatının yanlış olduğunu anladığımda beş sayfa yazmıştım. Son zamanlarda, ispat stilimle ilgili ikna edici bir yanlış ispatla ilgili bir konferans göstermek istedim, bu yüzden Kelley'ye döndüm. Kanıtında yanlış bir şey bulamadım; Açıkçası doğru görünüyordu! Kanıtın okunması ve yeniden okunması beni ya hafızamın başarısız olduğuna ya da yirmi yıl önce çok aptal olduğuma ikna etti. Yine de, Kelley'in kanıtı kısaydı ve güzel bir örnek olurdu, bu yüzden yapılandırılmış bir kanıt olarak yeniden yazmaya başladım.

... Stil ilk önce Martin Abadi ile yazdığım bir makalede sıradan teoremlerin ispatlarına uygulandı. Çoktan geleneksel ispatlar yazmıştı - bizi ve muhtemelen hakemleri ikna etmeye yetecek kadar iyi kanıtlar. İspatları yapılandırılmış bir tarzda yeniden yazarken, teoremlerin doğru olmasına rağmen neredeyse her birinin ciddi hatalar olduğunu keşfettik. Yanlış ispatların yanlış teoremlere yol açmayacağına dair herhangi bir umut, bir sonraki işbirliğimizde yıkıldı. Zaman zaman tekrar düşünürsek, tahtaya bir ispat taslak hazırlardık - kolayca ikna edici bir geleneksel ispat haline getirilmiş bir taslak - sadece yapılandırılmış bir kanıt yazmayı deneyerek, yanlışlığın yanlış olduğunu keşfediyoruz. O zamandan beri, dikkatli ve yapılandırılmış bir kanıt olmadan sonuçlara hiç inanmadım.

Büyük bir fark, programların girdiler üzerinde çalışmak üzere yazılmasıdır, oysa matematiksel kanıtlar genellikle bir aksiyom dizisinden ve önceden bilinen teoremlerden başlar. Bazen yeterince genel bir kanıt elde etmek için birden fazla köşe vakasını ele almanız gerekir, ancak davalar ve kararları açıkça sıralanır ve sonucun kapsamı kapsanan davalarla örtülü olarak sınırlandırılır.

Bunu, bir dizi olası giriş için 'doğru' çıktı sağlamak zorunda olan bir bilgisayar programı ile karşılaştırın. Tüm girdileri numaralandırmak ve hepsini denemek nadiren mümkündür. Daha kötüsü, programın bir insanla etkileşime girdiğini ve girdilerinin işleyişini değiştirmesine izin verdiğini varsayalım. İnsanoğlunun bildiği gibi öngörülemez ve insan etkileşimi ile oldukça büyük bir program için olası girdiler olağanüstü bir oranda büyür. Bir programın kullanılabileceği tüm farklı yolları öngörmeyi denemeli ve tüm bu kullanım durumlarını çalışabilir ya da en azından makul bir şekilde, başarısızlık tek seçenek olduğunda başarısız kılmaya çalışmalısınız. Ve bu bile nasıl olduğunu farz ediyor sözde tüm bu karanlık köşe durumlarda çalışmak.

Son olarak, büyük bir program gerçekten tek bir kanıtla, hatta karmaşık bir programla karşılaştırılamaz. Büyük bir program, muhtemelen üzerinde çalışmanız gereken bazı hataları olan küçük bir edebiyat kütüphanesini toplamaya ve incelemeye daha yakındır. Küçük bir algoritma uygulaması olabilecek tek bir ispat ölçeğindeki programlar için diyelim ki, deneyimli yazılım mühendisleri, özellikle yaygın önemsiz hataları önleyen / çözen modern araçlar kullanırken (yazım hatalarını andıran) ) prova okumasında çözeceğiniz erken konulara eşdeğerdir.

Bilgisayarlardaki problemin, tam olarak söylediklerini yapmaları olduğunu söylüyorlar.

Bunun birçok nedenden biri olabileceğini düşünüyorum.

Bir bilgisayar programında, yazıcının (siz) akıllı, ancak okuyucunun (CPU) aptal olduğuna dikkat edin.
Ancak matematiksel bir kanıtla, yazar (siz) akıllısınız ve okuyucu (eleştirmen) de akıllıdır.

Bu, bir bilgisayarla asla " demek istediğimi biliyorsun " durumuna giremeyeceğin anlamına gelir . Bu, niyetini bilmeden tam olarak ne söylediğini yapar.

Örneğin, bunun bir kanıt olarak atılmış bir adım olduğunu varsayalım:

$x^2+4x+3$$x+3$$x = -3$

Yuval'ın cevabında değinmediğimi düşündüğüm bir konu, farklı hayvanları karşılaştırıyormuşsunuz gibi görünüyor.

$n$$n!$

Programların anlamsal özelliklerinin doğrulanması kararsızdır (Rice teoremi) ve benzer şekilde, birinci sıradaki bir mantık ifadesinin mantığının doğru olup olmadığını kontrol etmek de aynı şekilde mümkün değildir. Mesele şu ki, sorunlara bakış açınızdan sertlikte hiçbir fark yoktur. Öte yandan, programların (derleyiciler) sözdizimsel özellikleri hakkında düşünebiliriz ve bu da kanıtları doğrulayabileceğimiz gerçeğine benzer. Hatalar (kod istediğimi yapmıyor) anlamlıdır, bu yüzden onları doğru karşıtlarıyla karşılaştırmalısınız.

Yuval'ı güçlendireceğim ve tüm alanların bazı resmi sistemlerde yazılabilecek ve doğrulanabilecek matematiksel kanıtlar yazma motivasyonuyla büyüdüğünü söyleyeceğim, bu yüzden doğrulama süreci hiç de önemsiz değildir.

Kusursuz matematiksel ispatlar yazmanın ve hatasız bilgisayar kodunu yazmanın, eskisinden çok daha izlenebilir olmasını sağlayacak kadar farklı olan şey nedir?

Öncelikli nedenlerin önemsizlik (aynı girdiler için aynı sonuçları verir) ve değişmezlik ( değişmez ) olduğuna inanıyorum .

Peki ya bir matematik kanıtı Salı günü ya da 1999'dan 2000 yılına kadar olan bir yıl okunduğunda farklı sonuçlar verebilirse? Peki ya matematiksel bir ispatın parçası birkaç sayfaya geri gitmek, birkaç satırı yeniden yazmak ve sonra bu noktadan tekrar başlamaksa?

Bu tür bir kanıtın neredeyse bilgisayar kodunun normal bir parçası gibi hatalara eğilimli olacağına eminim.

Diğer ikincil faktörleri de görüyorum:

1. Matematikçiler genellikle önemli / açıklanabilir bir kanıt yazmaya başlamadan önce çok daha eğitimlidirler. Kendi adını taşıyan profesyonel geliştiricilerin 1 / 4'ü 6 yıldan daha az bir süre önce kodlamaya başladı (bkz. SO anketi 2017 ), ancak çoğu matematikçinin on yıldan fazla resmi matematik eğitimine sahip olduğunu varsayıyorum.
2. Matematiksel kanıtlar nadiren bilgisayar kodu ile aynı seviyededir. Tek bir yazım hatası bir programı bozabilir / kırabilir, ancak bir kanıtın değerini (sadece okunabilirliğini) yok etmek için düzinelerce yazım hatası yeterli olmayabilir.
3. Şeytanın detayları ve bilgisayar kodları detayları geçemez. Kanıtlar basit / rutin sayılan adımları atlamakta serbesttir. Modern dillerde bazı hoş sözdizimsel şekerler var, ancak bunlar çok kodlanmış ve kıyaslandığında oldukça sınırlı.
4. Matematik eski ve daha sağlam bir temele / çekirdeğe sahiptir. Kesinlikle matematikte yeni ve parlak alt alanların bir bolluğu vardır, ancak temel ilkelerin çoğu on yıllardır kullanılmaktadır. Bu stabiliteye yol açar. Diğer taraftan, programcılar hala temel kodlama metodolojisine katılmamaktadırlar (sadece Çevik gelişim ve benimseme oranı hakkında bilgi isteyin).

Yuval'ın yazdıklarına katılıyorum. Ama aynı zamanda çok daha basit bir cevabı da var: Uygulama yazılımları mühendisleri tipik olarak programlarının doğruluğunu kontrol etmeye bile çalışmazlar, basitçe yapmazlar, genellikle programın ne zaman doğru olduğunu tanımlayan koşulları bile yazmazlar.

Bunun çeşitli nedenleri var. Birincisi, çoğu yazılım mühendisinin problemleri matematiksel olarak açık bir şekilde formüle etme becerisine sahip olmadığı veya doğruluk kanıtları yazmayı bilmedikleridir.

Bir diğeri ise, karmaşık bir yazılım sistemi (özellikle dağınık olan) için doğruluk koşullarını tanımlamanın çok zor ve zaman alıcı bir iştir. Haftalar içerisinde işe yarayacak bir şeye sahip olmaları bekleniyor.

Başka bir neden, bir programın doğruluğunun, başkaları tarafından yazılan ve bu nedenle tekrar net bir anlam ifade etmeyen birçok sisteme bağlı olmasıdır. Bir kütüphanenin / hizmetinizin gözlenebilir bir davranışı varsa (sözleşmesinin bir parçası değil) birisinin nihayet buna bağlı olacağını söyleyen bir Hyrum yasası vardır. Bu, temel olarak, matematikte lemmalar gibi açık sözleşmelerle, modüler formda yazılım geliştirme fikri, pratikte çalışmadığı anlamına gelir. Yansımanın kullanıldığı dillerde daha da kötüleşiyor. Bugün bir program doğru olsa bile, birileri bağımlılıklarından birinde önemsiz yeniden yapılanmalar yaptığında yarın bozulabilir.

Uygulamada tipik olan şey, testlere sahip olmalarıdır. Testler programdan bekleneni yapar. Her yeni bir hata bulunduğunda, onu yakalamak için testler eklerler. Bir dereceye kadar çalışır, ancak bir doğruluk kanıtı değildir.

İnsanların doğruluğu belirleme, doğru programlar yazma becerileri veya ne yapmaları beklendiği ve bunu yapması beklenmeyen beceriler olmadığı zaman, yazılımların doğru olmaması şaşırtıcı değildir.

Ama aynı zamanda daha iyi yerlerde yazılım mühendisliğinin kod incelemesiyle yapıldığını unutmayın. Programın yazarı, programın doğru çalıştığını en az bir kişiyi ikna etmek zorundadır. Bazı gayri resmi üst düzey tartışmaların yapıldığı nokta budur. Fakat yine de tipik olarak net bir doğruluk tanımına yakın bir şey yoktur veya doğruluk kanıtı ortaya çıkar.

Matematikte insanlar doğruluk üzerine odaklanmıştır. Yazılım geliştirmede, bir programcının ilgilenmesi gereken pek çok şey vardır ve bunlar arasında takaslar vardır. Sorunsuz bir yazılıma veya hatta zaman içinde değişen gereksinimlere göre iyi bir doğruluk tanımına sahip olmak bir idealdir, ancak diğer faktörlere karşı işlem görmesi gerekir ve bunlar arasında en önemlilerinden biri mevcut tarafından geliştirilmesinde harcanan zamandır. geliştiricileri. Bu yüzden pratikte daha iyi yerlerde amaç ve süreçler, yazılımı hatasız yapmaktan ziyade böcek riskini mümkün olduğu kadar azaltmaktadır.

Halihazırda pek çok iyi cevap var ama matematik ve programlamanın aynı olmama nedenleri daha var.

1 Matematiksel kanıtlar, bilgisayar programlarından çok daha basit olma eğilimindedir. Varsayımsal bir kanıtın ilk adımlarını göz önünde bulundurun:

Bir tamsayı olsun

B bir tamsayı olsun

C = a + b olsun

Şimdiye kadar kanıt iyidir. Bunu benzer bir programın ilk adımlarına çevirelim:

A = input ();

B = giriş ();

C = a + b;

Zaten sayısız sorunumuz var. Kullanıcının gerçekten bir tamsayı girdiğini varsayarsak, sınırları kontrol etmemiz gerekir. Mı bir daha büyük -32768 (sisteminizde ya da her türlü dk int)? Mı bir 32767 daha az? Şimdi aynı şeyi b için de kontrol etmeliyiz . Ve a ve b eklediğimiz için program a + b olmadığı sürece doğru değildir.-32768'den büyük ve 32767'den küçük. Programcının bir matematikçinin görmezden gelebileceği konusunda endişelenmesi gereken 5 ayrı şart. Programcının sadece onlar için endişelenmesi gerekmiyor, bu şartlardan biri karşılanmadığında ne yapacağını bulmak zorunda ve karar vermiş olsa bile yapmak için kod yazması gerekiyor. Matematik basit. Programlama zor.

2 Sorgulayıcı, derleme zamanı hatalarına mı yoksa çalışma zamanı hatalarına mı atıfta bulunduğunu söylemiyor, ancak programcılar genellikle derleme zamanı hatalarını umursamıyor. Derleyici onları bulur ve düzeltmeleri kolaydır. Tipo gibiler. İnsanlar ilk defa hatasız olarak birkaç paragrafı ne sıklıkla yazarlar?

3 Eğitim.Çok küçük yaşlardan itibaren matematik yapmamız öğretilir ve küçük hataların tekrar tekrar sonuçlarına katlanırız. Eğitimli bir matematikçi, genellikle ortaokulda çok adımlı cebir problemlerini çözmeye başlamalı ve bir yıl boyunca her hafta düzinelerce (veya daha fazla) böyle problemler yapmalıydı. Tek bir bırakılan negatif işaret tüm sorunun yanlış olmasına neden oldu. Cebirden sonra problemler daha da uzuyordu. Diğer taraftan, programcılar genellikle daha az resmi eğitime sahiptir. Birçoğu kendi kendini eğitiyor (en azından başlangıçta) ve üniversiteye kadar resmi bir eğitim alamadı. Üniversite düzeyinde bile, programcılar bir kaç matematik dersi alırken, matematikçiler muhtemelen bir veya iki programlama dersi aldı.

Yuval'ın cevabını beğendim, ama bir süreliğine bunu mahvetmek istedim. Matematik kanıtları yazmayı daha kolay bulabilmenizin bir nedeni, Platonik Matematik ontolojisinin ne kadar olduğuna bağlı olabilir. Ne demek istediğimi görmek için aşağıdakileri göz önünde bulundurun:

• Matematik'teki işlevler saftır (bir işlev çağrmanın sonucu, tamamen deterministik olan ve giriş değerinden tamamen hesaplanan dönüş değerinde tamamen kapsüllenmiştir).
• Matematik mutasyon veya yeniden atama yoktur (bu tür şeyleri modellemeniz gerektiğinde, işlevler ve diziler kullanılır).
• Matematik, referans olarak saydamdır (örn. İşaretçiler yok, isim-by-call-by-call-no-by-nos- yonu yok) kavramı ve Matematiksel nesneler, uzamsal eşitlik semantiğine sahiptir (eğer "iki" şey her gözlemlenebilir şekilde aynı ise, o zaman aslında aynı şey).

Yukarıdaki kısıtlamaların bir program yazmayı kolaylaştırıp kolaylaştırmayacağı tartışılabilir olsa da, yukarıdaki kısıtlamaların bir program hakkında mantıklı olmayı kolaylaştıracağı konusunda geniş bir anlaşma olduğunu düşünüyorum . Bir Matematik kanıtı yazarken yaptığınız en önemli şey şu anda yazmakta olduğunuz kanıtla ilgili bir sebeptir (çünkü programlamadakilerin aksine, matematikte soyutlamalar ücretsiz olduğu için çabayı hiçbir zaman çoğaltmanıza gerek kalmaz), bu yüzden genellikle bunun için ısrar etmeye değer yukarıdaki kısıtlamaların üstünde.

Temel matematiksel kanıtlar, canlı insanların ihtiyaçlarını karşılamak için tasarlanmış gerçek bir dünya uygulaması anlamına gelmez.

İnsanlar, bilgisayar programları alanında günlük olarak neyin temeli olduğu konusundaki isteklerini, ihtiyaçlarını ve gereksinimlerini değiştireceklerdir.

Kusursuz matematiksel ispatlar yazmanın ve hatasız bilgisayar kodunu yazmanın, eskisinden çok daha izlenebilir olmasını sağlayacak kadar farklı olan şey nedir?

Matematiksel bir problem kadar açık bir gereksinim olduğu gibi kusursuz bir program yazılabilir. Dijkstra'nın algoritmasının bir grafikteki iki nokta arasındaki en kısa yolu bulabildiğini kanıtlamak, rastgele girdileri kabul eden ve içindeki iki nokta arasındaki en kısa noktaları bulan programla aynı değildir.

Yönetilmesi gereken bellek, performans ve donanım endişeleri var. Algoritmalar yazarken, bunları yönetmek için saf ve işlevsel yapılar kullanabileceğimizi düşünmemeyi, bilgisayar programları “gerçek” donanım dünyasında yaşarken, matematiksel kanıtların “teoride” yer almasını isterdim.

Veya daha özlü olmak için :

Başka bir açıdan bakıldığında, akademik olmayan bir ortamda çoğu zaman paraya düşer.

Diğer yayınlar da açıkça belirtildiği gibi, Math tek bir soyut şartnamedir, bu yüzden bir kanıtın sadece kanıtlanmış olan şartnamede tutarlı bir şekilde çalışması gerekir. Bir bilgisayar programı, matematiğin soyut spesifikasyonunun birçok uygulaması üzerinde çalışabilir - yani bir dilin veya donanım üreticisinin kayan nokta matematiğini uygulanma şekli, sonuçlarda hafif dalgalanmalara neden olabilecek şekilde biraz farklı olabilir.

Bu nedenle, yazmadan önce bir bilgisayar programını 'ispatlamak', daha sonra programın donanımın olası her bir kombinasyonu için donanım düzeyinde, işletim sistemi düzeyinde, sürücü düzeyinde, programlama dili, derleyici, belki tercüman vb. akla gelebilecek şekilde çalıştırılabilir ve akla gelebilecek akla gelebilecek tüm veriler. Muhtemelen başarısızlığın milyarlarca dolarlık dolar ve potansiyel olarak pek çok kaybedilen hayat anlamına geldiği uzay görevlerinde, silah sistemlerinde veya nükleer güç kontrol sistemlerinde bu hazırlık ve anlayış seviyesini bulacaksınız.

'Her gün' programcınız ve / veya işiniz için, çoğunlukla doğru kodda belirli bir doğruluk seviyesini kabul etmek ve kullanılabilir bir ürün satmak, çok daha düşük maliyetlidir ve geliştiriciler, hatalar sırasında ortaya çıktıkları zaman geriye dönük olarak düzeltebilirler. kullanımı.

Mantığınızın geçerli olduğunu düşünüyorum, ancak girişiniz geçerli değil. Her ikisi de insanlar tarafından yazılmışsa, matematiksel kanıtlar programlardan daha fazla hataya dayanıklı değildir. Dijkstra zaten burada alıntı yapıldı, ancak ek bir teklif sunacağım.

Ancak, hesaplamaları, sınırlı yetkilerimizin, hesaplamanın istenen etkiyi oluşturacağını garanti etmek için yeterli olacak şekilde düzenlemeliyiz. Bu düzenleme programın kompozisyonunu içerir ve orada bir sonraki büyüklük problemi ile karşı karşıya kaldık, viz. program metninin uzunluğu ve bu sorunu açıkça belirtmemiz gerekir. Bir metni okuyabilmemiz veya yazabilmemizin boyutuna büyük ölçüde bağlı olduğunun farkında olmalıyız. [...]

Aynı ruh hali içinde, okuyucunun dikkatini “açıklık” ın nicel yönleri olduğunu, pek çok matematiğin merakla yeterince habersiz göründüğü gerçeğine vurgulamak istemem gerektiği şeklindedir. Koşulların tam olduğu 10 sayfa yerine getirildiğinde sonucun geçerliliğini belirten bir teorem, teoriye itiraz edildiğinde her koşulun doğrulanması gerektiği için pek uygun bir araçtır. Öklid geometrisinde, Pythagoras Teoremi, A, B ve C olmak üzere üç nokta için geçerlidir; öyle ki, A ve C aracılığıyla düz bir çizgi B ve C boyunca düz bir çizgiye dik olarak çizilebilir. veya A, B ve C noktalarının tümü çakışıyor mu? Yine de bu, Pisagor Teoreminin kullanılabileceği kolaylıktan büyük ölçüde sorumlu görünüyor.

Özetleme: yavaş çalışan bir insan olarak çok küçük bir kafam var ve onunla yaşamayı ve sınırlamalarıma saygı duymayı ve onları görmezden gelmeyi denemekten ziyade tam kredi vermeyi daha iyi öğrendim; başarısızlıkla cezalandırılır.

Bu, Dijkstra'nın Yapısal Programcılığının birinci bölümünden son üç paragrafta biraz düzenlenmiştir.

Bunu tekrar ifade etmek için, sorunuza daha iyi uygulamak için: doğruluk büyük ölçüde ispatınızın bir fonksiyonudur. Uzun matematiksel kanıtların doğruluğunu tespit etmek çok zordur (çok sayıda yayınlanmış “kanıt”, belirsizlik sınırında yaşar, çünkü kimse bunları doğrulamaz). Ancak, önemsiz programların doğruluğunu önemsiz kanıtlarla karşılaştırırsanız, muhtemelen gözle görülür bir fark yoktur. Bununla birlikte, otomatik prova asistanları (daha geniş anlamda, Java derleyiciniz de prova asistanıdır), programların çok sayıda temel çalışmayı otomatikleştirerek kazanmasını sağlar.

Diğer cevapların cevaplarında değinildiği gibi (ayrıntılandırmak istiyorum), ancak sorunun büyük bir kısmı kütüphane kullanımıdır. Mükemmel belgelerle (hatasız kod kadar yaygın) bile, bir kütüphane hakkındaki tüm bilgileri kitaplığı kullanan her programcıya aktarmak mümkün değildir. Programcı kütüphanesini tam olarak anlamıyorsa, onu kullanırken hata yapabilir. Bazen bunlar, kod çalışmadığında keşfedilen kritik hatalara neden olabilir. Ancak küçük hatalar için bunlar farkedilmeyebilir.

Benzer bir durum, eğer bir matematikçinin var olan delilleri ve lemmaları tam olarak anlamadan kullanması; kendi kanıtları büyük olasılıkla hatalı olacaktır. Bu bir çözüm önerisi olsa da, kullandığı her kütüphaneyi mükemmel bir şekilde öğrenmek; bu pratikte çok zaman alıcıdır ve programcının sahip olmadığı alan bilgisini gerektirebilir. (DNA dizilimi / protein sentezi hakkında çok az şey biliyorum; ancak kütüphaneler kullanarak bu kavramlarla çalışabilirim).

Daha kısaca ifade etmek gerekirse, yazılım mühendisliği (genel olarak mühendislik) insanların uzmanlık alanlarındaki problemlerin daha küçük alanlarına odaklanmalarına izin vermek için farklı soyutlama seviyelerini kapsamaya dayanmaktadır. Her katman arasında. Bu iletişim mükemmel olmadığında sorunlara yol açar.

Tüm bu harika cevaplardan sonra orjinal olmaya çalışacağım.

Programlar olan deliller

Curry-Howard İzomorfizma programınızda türleri teoremleri ve gerçek kod onların kanıtıdır, söyler.

Kuşkusuz, bu çok soyut ve üst düzey bir görüş. Muhtemelen, demek istediğim, tipik bir kod yazmanın zor olması çünkü çok düşük seviyeli oluyor. Çoğu durumda "makineye ne yapacağını söylemeniz gerekir". Veya buna başka bir yoldan bakmak için: matematikçiler soyutlamada gerçekten iyidirler.

Bir yan not olarak: "Akışların müziği" , ikisi arasındaki en güzel köprülerden biridir. Temelde "İstediğim söylemek mümkün kümeleri şeyler bu yer o şekilde" ve makine sihirli yapar bu istendiği gibi aynen.

Diğer birçok cevapların hiçbiri aşağıdakilere dikkat çekmiyor. Matematiksel kanıtlar, sonsuz belleğe ve sonsuz bilgi işlem gücüne sahip hayali bilgi işlem sistemlerinde çalışır. Bu nedenle, sınırsız hassasiyet için keyfi olarak büyük sayıları tutabilirler ve herhangi bir hesaplamada hassasiyetini kaybedebilirler.

$\pi$

Değil. Matematiksel kanıtlar tam olarak doğası gereği taşınır, sadece okuyucuları bir derleyiciden daha müsaade eder. Benzer şekilde, bir bilgisayar programının okuyucuları, en azından çalıştırmayı deneyene kadar, doğru olduğuna inanmaya kolayca kandırılır.

Örneğin, matematiksel bir kanıtı ZFC gibi resmi bir dile çevirmeye çalışırsak, aynı zamanda hataları da içerecektir. Çünkü bu ispatlar çok uzun sürebilir, bu yüzden ispatı oluşturmak için bir program yazmak zorunda kalıyoruz. Temel kanıtları resmileştirme konusunda aktif bir araştırma olmasına rağmen, çok az insan tehlikeye düşüyor.

Ve gerçekten, matematik BSOD alabilir! İlk defa olmazdı!

Yeterince doğrulanmış tüm matematiksel kanıtların temelde doğru olduğu veya doğru yapılabildiği bu ortodoks düşünce, işinizde yazılım projenizi motive eden aynıdır: özellikleri tamamlandı - kesin bir nihai ürüne götüren yinelemeli bir süreç.

İşte kapak tarafı. Bakın, biz zaten finanse ettik, işletme kavramını doğruladık, tüm belgeler okumanız için burada. Sadece yürütmeni istiyoruz ve bu kesin bir şey!

Hilbert için de üzülmeyelim , neye bulaştığını biliyordu. Bu sadece iş.

Gerçekten emin olmak istiyorsan, her şeyi duruma göre al ve kendi sonuçlarını çıkar!

Programların matematik kanıtlarından daha fazla hataya eğilimli olmasının iki önemli sebebi görüyorum:

1: Programlar, zaman içinde değişen değişkenler veya dinamik nesneler içerirken, provalardaki matematiksel nesneler normalde statiktir. Bu nedenle, matematikteki gösterim, programlarda işe yaramadığı yerlerde doğrudan muhakeme desteği olarak kullanılabilir (ve eğer a = b ise durum böyle kalır). Ayrıca, programların paralel olduğu veya birden fazla iş parçacığı olduğu durumlarda bu sorun daha da kötüleşir.

2: Matematik genellikle nispeten düzgün tanımlanmış nesneler (grafikler, manifoldlar, halkalar, gruplar, vb.) Varsaymaktadır; programlama ise çok dağınık ve oldukça düzensiz nesnelerle ilgilidir: sonlu hassas aritmetik, sonlu yığınlar, karakter-tamsayı dönüşümleri, işaretçiler, toplanması gereken çöpler , vb ... Doğrulukla ilgili koşulların toplanmasının akılda tutulması çok zordur.

İki farklı "kategoriyi" ayırt etmelisiniz:

• sözde provalar (veya sözde kod) - kitaplarda gördüğünüz budur. Doğal dilde yazılmıştır (örneğin İngilizce). Matematik (veya Algoritmalar) öğrenmek için kullanmanız gereken şey budur.
• resmi kanıtlar (veya resmi kod) - mekanik olarak doğrulanabilir (veya çalıştırılabilir) olması için kanıtınıza (veya koduna) ihtiyacınız olduğunda yazabilirsiniz. Bu temsil herhangi bir "insan zekası" gerektirmez. Önceden tanımlanmış bazı adımları izleyerek (genellikle bugün bilgisayarlar tarafından yapılır) mekanik olarak doğrulanabilir (veya çalıştırılabilir).

Binlerce yıldır sahte kod kullanıyoruz (örneğin, Euclids algoritması). Resmi kodların yazılması (C veya Java gibi resmi dillerde), bilgisayarların icadından sonra oldukça popüler ve faydalı oldu. Ancak, ne yazık ki, resmi ispatlar (Principia Mathematica veya Metamath gibi resmi dillerde) çok popüler değildir. Ve bugün herkes sözde ispatlar yazdığından, insanlar genellikle yeni ispatlar hakkında tartışırlar. Onları yanlışlar gerçek "kanıt" sonra yıllar, on yıl ya da hatta yüzyıllar bulunabilir.

Referansı bulamıyorum, ancak Tony Hoare'nin bir zamanlar aşağıdaki satırlar boyunca bir şeyler söylediğini düşünüyorum: Bir programı kontrol etmek ve bir kanıtı kontrol etmek arasındaki fark, bir kanıtın aynı anda iki satır kontrol edilebileceğidir.

Bir kelimeyle: yerellik.

Provalar kolayca kontrol edilebilmeleri için yazılmıştır. Programlar yürütülebilmeleri için yazılmıştır. Bu nedenle, programcılar genellikle programı kontrol eden biri için faydalı olacak bilgileri bırakır.

X'in salt okunur olduğu bu programı göz önünde bulundurun

    assume x >= 0
    p := 0 ;
    var pp := 0 ;
    while( x >= pp + 2*p + 1 ) 
    {
        var q := 1 ;
        var qq := q ;
        var pq := p ;
        while(  pp + 4*pq + 4*qq <= x )
        {
            q, pq, qq := 2*q, 2*pq, 4*qq ;
        }
        p, pp := p + q, pp + 2*pq + qq ;
    }
    assert  p*p <= x < (p+1)*(p+1)

Uygulaması kolaydır, ancak kontrol edilmesi zordur.

Ancak, eksik iddiaları tekrar eklersem, programı yerel olarak sadece her bir görev sırasının kendi ön ve son koşullarına göre doğru olup olmadığını kontrol ederek yerel olarak kontrol edebilirsiniz; değişmez ve döngü korumasının ihmali.

    assume x >= 0
    p := 0 ;
    var pp := 0 ; 
    while( x >= pp + 2*p + 1 ) 
        invariant p*p <= x 
        invariant pp == p*p
        decreases x-p*p 
    {
        var q := 1 ;
        var qq := q ; 
        var pq := p ; 
        while(  pp + 4*pq + 4*qq <= x )
            invariant (p+q)*(p+q) <= x
            invariant q > 0 
            invariant qq == q*q 
            invariant pq == p*q 
            decreases x-(p+q)*(p+q)
        {
            q, pq, qq := 2*q, 2*pq, 4*qq ;
        }
        assert (p+q)*(p+q) <= x and pp==p*p and pq==p*q and qq==q*q and q>0
        p, pp := p + q, pp + 2*pq + qq ;
    }
    assert  p*p <= x < (p+1)*(p+1)

Asıl soruya dönersek: Neden matematiksel kanıtları yazmak bilgisayar kodunu yazmaktan daha hatasızdır? Kanıtlar okurları tarafından kolayca kontrol edilmek üzere tasarlandığından, yazarlar tarafından kolayca kontrol edilir ve bu nedenle uyarıcı yazarlar, kanıtlarında mantıksal hatalar yapma (veya en azından tutma) eğilimindedir. Programladığımız zaman, kodumuzun doğru olmasının nedenini sık sık yazamıyoruz; Sonuç, hem okuyucuların hem de programın yazarının kodu kontrol etmesinin zor olması; Sonuç, yazarların hata yaptıkları (ve sonra sakladıkları).

Ama umut var. Bir program yazdığımızda, programın doğru olduğunu düşündüğümüz nedenini de yazarsak, kodu yazarken kontrol edebilir ve daha az hata kodu yazabiliriz. Bu aynı zamanda başkalarının kodumuzu okuyabilmesi ve kendileri için kontrol edebilmesi avantajına sahiptir.

Biz de daha zor olup olmadığını sorabilirsiniz pratikte , ya da ilke , kanıtları yazmak veya kod yazmak.

Uygulamada, kanıtlama kodlamadan daha zordur. İki yıl üniversite düzeyinde matematik almış olan çok az kişi ispat yazabilir, hatta önemsiz olanlar bile. İki yıl üniversite düzeyinde CS alan kişiler arasında, muhtemelen en az% 30'u FizzBuzz'ı çözebilir .

Fakat prensipte , bunun tersi olmasının temel nedenleri var. Kanıtlar, en azından prensipte, herhangi bir yargılama veya herhangi bir anlama gerektirmeyen bir süreç aracılığıyla doğruluk açısından kontrol edilebilir. Programlar yapamaz - önceden belirlenmiş bir işlemle bir programın durup durmayacağını bile söyleyemeyiz.

Doğru olan matematiksel ifadelerin sadece küçük bir kısmı pratik olarak kanıtlanabilir. Daha da önemlisi, tüm gerçek ifadelerin kanıtlanmasına izin verecek önemsiz (*) bir matematiksel aksiyom dizisi oluşturmak imkansız olurdu. Bilgisayarlarla yapılabilecek şeylerin çok küçük bir kısmını yapmak için programlar yazması gerekirse, kesin olarak doğru bir yazılım yazmak mümkün olabilir, ancak bilgisayarlar genellikle doğru olarak doğru olanın ötesinde şeyler yapmak için çağrılır. yazılımı başarabilir.

(*) Tüm gerçek ifadelerin numaralandırılmasına ve böylece ispatlanmasına izin verecek bir aksiyom tanımlamak mümkündür, ancak bunlar genellikle çok ilginç değildir. Aksiyom gruplarını, göreceli olarak konuşmayan, önemsiz olanlara biçimsel olarak kategorize etmek mümkün olsa da, kilit nokta, doğru olan ancak kanıtlanamayan ifadelerin kanıtlanabilir varlığının bir küme içindeki kusur olmadığıdır. Aksiyomların Var olan gerçek ancak kanıtlanamayan tüm ifadeleri kanıtlanabilir kılmak için aksiyom eklemek, diğer ifadelerin gerçek olmasına neden olur, ancak kanıtlanamaz.

1. Bilgisayar programları gerçek dünyada test edilir. Sadece sınırlı sayıda insanın anlayabildiği, uzun bir matematiksel kanıtla ilgili zor bir teknik hata, tespit edilmeden kalma şansına sahiptir. Bir yazılım ürününde aynı türde bir hata olması, sıradan kullanıcıların farkettiği garip davranışlar yaratır. Öyleyse öncül doğru olmayabilir.

2. Bilgisayar programları faydalı gerçek dünya fonksiyonlarını yerine getirir. Bunu yapmak için% 100 doğru olmaları gerekmez ve yüksek doğruluk standartları oldukça pahalıdır. Kanıtlar yalnızca bir şeyi ispatlarsa faydalıdır, bu nedenle '% 100 doğru' kısmını atlamak matematikçiler için bir seçenek değildir.

3. Matematiksel kanıtlar açıkça tanımlanmıştır. Bir kanıtın hatalı olması durumunda, yazar bir hata yapmıştır. Gereksinimler doğru bir şekilde iletilmediğinden veya programcının hiç duymadığı bir şeyle uyumluluk sorunu olduğu için bilgisayar programlarındaki birçok hata ortaya çıkar.

4. Birçok bilgisayar programının doğru olduğu kanıtlanamaz. Yüzleri tanımak gibi gayri resmi olarak tanımlanan sorunları çözebilirler. Ya da borsa tahmin yazılımı gibi olabilirler ve resmi olarak tanımlanmış bir hedefleri olabilir ama çok fazla gerçek dünya değişkenini içerirler.

Bir insan etkinliği olarak matematiğin büyük bir kısmı, kanıtların doğrulanmasının bir insan için yapması kolay olan alana özgü dillerin geliştirilmesi olmuştur.

Bir ispatın kalitesi, uzunluğu ve karmaşıklığı ile ters orantılıdır. Uzunluk ve karmaşıklık, ele aldığımız durumu açıklamak için iyi bir gösterim geliştirerek ve söz konusu kanıtla etkileşim içinde olan yardımcı kavramlarla birlikte, genellikle azalır.

Bu kolay bir süreç değildir ve araştırmanın ön planından çıkarılmış kişilerin şahit olduğu kanıtların çoğu, binlerce yıl olmasa da, o alanın gösteriminin yapıldığı matematiksel alanlarda (cebir ve analiz gibi) gerçekleşir. kanıtları bir yere yazma eyleminin bir esinti gibi hissettirdiği noktaya getirildi.

Yine de araştırmanın ön saflarında, özellikle iyi kurulmuş veya iyi tanımlanmış notalara sahip alanlarda olmayan problemler üzerinde çalışıyorsanız, doğru bir kanıt yazmanın bile doğru bir program yazma zorluğuna yaklaştığını iddia ediyorum. Bunun nedeni aynı zamanda bir programlama dili tasarımının analoğunu yazmanız, sinir ağınızı doğru bir şekilde derlemesi için eğitmeniz, bunun ispatını yazmayı denemeniz, hafızanızın tükenmesi, dili iyileştirmeye çalışmanızdır. beyninizi dili öğrenerek yineleyin, ispatı tekrar yazın, vb.

Yinelemek gerekirse, doğru kanıtlar yazmanın, matematiğin belirli alanlarına doğru programlar yazmanın zorluğuna yaklaşabileceğini düşünüyorum, ancak matematiğin ilerleyişi kavramı, kanıtlamanın kolaylığına yakından bağlı olduğu için mutlaka genç ve az gelişmişlerdir. doğrulama.

Yapmak istediğim noktayı ifade etmenin bir başka yolu da, hem programlama dillerinin hem de matematiğin tasarlanan günün sonunda olması ve böylece bilgisayar programlarının ve ispatlarının derlenmesi mümkün olması. Sadece bir bilgisayar programını derlemek bir bilgisayarda yapılır ve genellikle programın doğruluğu ile ilgisi çok az olan sözdizimsel doğruluğu sağlarken, "derlemek" bir kanıtı bir insan tarafından yapılır ve aynı şey olan sözdizimsel doğruluğu sağlar. ispatın doğruluğu.

Dürüst olmak gerekirse, burada elma ve portakalları karşılaştırıyorsunuz. Hataya dayanıklı ve hatasız aynı şey değil.

Bir program numaralarını karşılaştırır ederse 2ve 3ve diyor 2 is greater than 3, o zaman çünkü bir arabası uygulamasının olabilir:

# Buggy implementation
function is_a_greater_than_b(a,b):
  return b > a

Program yine de hatasız. İki sayıyı karşılaştırarak ave b, her zaman b, büyük olandan büyük olup olmadığını size söyleyebilecek a. Bu, sizden (programlayıcı) bilgisayardan yapmasını istemeniz gereken şey değil.

a) Çünkü bilgisayar programları matematik kanıtlarından daha büyüktür.

a.1) Karmaşık bilgisayar programı yazarken matematik kanıt yazmadan daha fazla insanın kullanıldığına inanıyorum. Bu, hata payının daha yüksek olduğu anlamına gelir.

b) CEO'lar / Hissedarlar küçük hataları düzeltmekten çok paraya önem verdiğinden, bu arada (geliştirici olarak) bazı gereksinimleri / son teslim tarihlerini / demolarını yerine getirmek için görevlerinizi yapmanız gerekir.

c) Çünkü, bilgisayar bilimlerinde "derin" bilgiye sahip olmadan programcı olabilirsiniz, bu arada matematikte yapmak zor olurdu (inanıyorum)

Bunlara ek olarak:

NASA:

Bu yazılım hatasızdır. Mükemmeldir, insanların elde ettiği kadar mükemmel. Bu istatistikleri göz önünde bulundurun: Programın son üç versiyonu - her biri 420.000 satır uzunluğunda - her biri yalnızca bir hatayla karşılaştı. Bu yazılımın son 11 sürümü toplam 17 hata vardı.

Mekiğin, programın yalnızca% 1,5'ini veya 6,366 kod satırını içeren bir Global Konumlandırma Uydularında gezinmesine izin vermek için yazılımı yükseltin. Bu değişikliğin teknik özellikleri, bir telefon rehberinden daha kalın olan 2.500 sayfadır. Mevcut programın teknik özellikleri 30 cilt dolduruyor ve 40.000 sayfa yayınlıyor.

https://www.fastcompany.com/28121/they-write-right-stuff

Temel Seviyeler:

Matematik için biz var:
2 + 3 = 5

Bunu çok çok gençken öğrendim. En temel öğelere bakabilirim: iki nesne ve üç nesne. Harika.

Bilgisayar programlaması için çoğu insan yüksek seviyede bir dil kullanma eğilimindedir. Bazı yüksek seviyeli diller, C gibi daha düşük üst seviyeli dillerden birine "derlenebilir", daha sonra C, daha sonra Assembly diline çevrilebilir. Assembly dili daha sonra makine koduna dönüştürülür. Pek çok insan, karmaşıklığın orada biteceğini düşünüyor, ancak yapmıyor: Modern CPU'lar makine kodunu talimat olarak alıyor, ancak daha sonra bu talimatları uygulamak için "mikro kodu" çalıştırıyor.

Bunun anlamı, en temel seviyede (en basit yapılarla uğraşıyoruz), şimdi donanıma gömülü olan ve çoğu programcının doğrudan kullanmadığı ya da güncellemediği mikro-kod ile uğraşıyoruz. Aslında, çoğu programcı mikro koda (mikro koddan 0 seviyeden yüksek) dokunmaz, çoğu programcı makine koduna (mikro koddan 1 seviyeden yüksek) ve hatta Meclis'e (mikro koddan 2 seviyeden yüksek) dokunmaz. (belki de, kolej sırasında bir miktar örgün eğitim hariç). Çoğu programcı sadece 3 veya daha fazla seviye için zaman harcar.

Dahası, eğer Meclis'e bakarsanız (ki insanlar genelde normalde olduğu kadar düşük), her bir adım genellikle eğitilmiş ve bu adımı yorumlayacak kaynaklara sahip kişilerce anlaşılabilir. Bu anlamda, Meclis, üst düzey bir dilden çok daha basittir. Bununla birlikte, Meclis o kadar basittir ki, karmaşık görevlerin ve hatta vasat görevlerin yerine getirilmesi çok zahmetlidir. Üst seviye diller bizi ondan kurtarıyor.

"Tersine mühendislik" ile ilgili bir yasada, bir yargıç, teorik olarak her defasında bir bayt ele alınsa bile, modern programların milyonlarca bayt içerdiğini, bu nedenle bazı kayıtlar (kod kopyaları gibi) yapılması gerektiğini açıkladı. uygulanabilir olma çabası. (Bu nedenle, içsel gelişme, genelleştirilmiş "kopya çıkarmamak" telif hakkı yasası kuralına aykırı sayılmadı.) (Muhtemelen izinsiz Sega Genesis kartuşları yapmayı düşünüyorum, ancak Game Genie davasında söylenen bir şeyi düşünüyor olabilirim. )

modernizasyon:

286'lara yönelik kodlar kullanıyor musunuz? Yoksa 64 bit kod mu çalıştırıyorsunuz?

Matematik binlerce yıllara kadar uzanan temelleri kullanır. Bilgisayarlarla, insanlar genellikle yirmi yıllık bir işe yatırım yapmayı düşüncesizce boşa harcarlar. Bu, Matematik'in çok daha ayrıntılı bir şekilde test edilebileceği anlamına gelir.

Kullanılan Araçlar Standartları:

Bana (benden daha resmi bilgisayar programlama eğitimi almış bir arkadaş tarafından) C spesifikasyonlarını karşılayan hatasız bir C derleyicisi diye bir şeyin olmadığı öğretildi. Bunun nedeni, C dilinin temel olarak bir yığın amacı için sonsuz bellek kullanma olasılığını varsaymasıdır. Açıkçası, böyle imkansız bir gereklilik, insanlar doğada biraz daha sınırlı olan gerçek makinelerle çalışan kullanılabilir derleyicileri yapmaya çalıştıklarında sapmak zorunda kaldılar.

Uygulamada, Windows Komut Dosyası Sistemi'ndeki JScript ile nesneleri kullanarak çok iyi şeyler başarabildiğimi öğrendim. (Yeni kod denemek için gereken araç seti Microsoft Windows'un modern sürümlerine yerleştirildiği için çevreyi seviyorum.) Bu ortamı kullanırken, bazen nesnenin nasıl çalıştığıyla ilgili kolayca ulaşılabilecek bir belge bulunmadığını gördüm. Ancak, nesneyi kullanmak o kadar faydalı ki, yine de yapıyorum. Öyleyse benim yaptığım şey, eşek arısı yuvası gibi görünen bir kod yazıp, etkilerini görebileceğim ve nesnenin etkileşime girerken nesnenin davranışları hakkında bilgi edebileceğim güzel bir sanal alanda.

Diğer durumlarda, bazen yalnızca bir nesnenin nasıl davrandığını belirledikten sonra, nesnenin (işletim sistemi ile birlikte gelen) bir hata olduğunu ve Microsoft'un kasıtlı olarak düzeltilmemeye karar verdiğinin bilinen bir sorun olduğunu buldum. .

Bu gibi senaryolarda, programlı olarak yeni sürümler yaratan usta programcılar tarafından yaratılan OpenBSD'ye (yılda iki kez) düzenli olarak (yılda iki kez), 10+ yıldaki "sadece iki uzak delik" ünlü bir güvenlik kaydıyla güveniyor muyum? (Hatta daha az ciddi sorunlar için hatalı yamaları var.) Hayır, hiçbir şekilde. Bu kadar yüksek kalitede böyle bir ürüne güvenmiyorum, çünkü insanlara Microsoft Windows kullanan makineler tedarik eden işletmelere destek veren bir işletme için çalışıyorum, bu yüzden kodumun üzerinde çalışması gerekiyor.

Uygulanabilirlik / kullanılabilirlik, insanların yararlı bulduğu platformlar üzerinde çalışmamı gerektiriyor ve bu, güvenlik açısından son derece kötü bir platform (aynı şirketin ürünlerinin çok daha kötü olduğu bin yılın başlarında büyük gelişmeler olsa bile) .

özet

Bilgisayar programlamanın hataya daha yatkın olmasının ve bilgisayar kullanıcıları topluluğu tarafından kabul edilmesinin sayısız nedeni vardır. Aslında, çoğu kod, hatasız çabalara tolerans göstermeyecek ortamlarda yazılmıştır. (Güvenlik protokolleri geliştirmek gibi bazı istisnalar, bu konuda biraz daha fazla çaba gösterebilir.) Daha fazla para yatırmak istemeyen işletmelerin ve müşterileri mutlu etmek için suni son başvuru tarihlerini kaçırmanın sebeplerinin genel olarak düşünüldüğü gibi, bunun etkisi de vardır. Çok fazla zaman harcıyorsanız, eski bir platformda çalışacağınızı söyleyen teknoloji yürüyüşü, çünkü işler on yıl içinde önemli ölçüde değişiyor.

Sonuç olarak, strlen ve strcpy için bazı kaynak kodları gördüğümde, bazı çok kullanışlı ve popüler fonksiyonların ne kadar kısa olduğuna şaşırdığımı hatırlayabilirim. Örneğin, strlen "int strlen (char * x) {char y = x; while ( (y ++)); return (yx) -1;}" gibi bir şey olabilirdi

Ancak, tipik bilgisayar programları bundan daha uzundur. Ayrıca, pek çok modern programlama, daha az kapsamlı bir şekilde test edilebilecek, hatta buggy olarak bilinen başka bir kod kullanacaktır. Günümüzün sistemleri, kolayca düşünülebileceklerinden çok daha ayrıntılıdır, ancak daha düşük seviyelerde ele alınan ayrıntılar gibi çok sayıda minutinin el sallanması dışında.

Bu zorunlu karmaşıklık ve karmaşık ve hatta yanlış sistemlerle çalışmanın kesinliği, bilgisayar programlamasını, işlerin çok daha basit seviyelere düşme eğiliminde olduğu birçok matematikten daha doğrulamak için çok fazla donanım yapar.

Matematiğin içindeki şeyleri parçaladığınızda, çocukların anlayabileceği bireysel parçalara ulaşırsınız. Çoğu insan matematiğe güvenir; en azından temel aritmetik (veya en azından sayma).

Başlık altında neler olup bittiğini görmek için bilgisayar programlamayı gerçekten parçaladığınızda, sonuçta elektronik olarak yürütülen standartların ve kodların kırılmış uygulamalarına son verirsiniz ve bu fiziksel uygulama, üniversite eğitimi almış çoğu bilgisayar bilimcisinin sahip olduğu mikro kodun sadece bir adım altındadır. dokunmaya cesaret edemiyorsanız (eğer farkındalarsa bile).

Üniversitedeki bazı programcılar veya son zamanlarda mezun olan öğrencilerle, hatasız kodun yazılabileceği fikrine itiraz ediyorum. Olasılığı yazdılar ve bazı etkileyici örneklerin (gösterebildiğim) bazı ikna edici argümanlar olduğunu kabul etseler de, bu tür örneklerin temsili nadir rastgele şanslar olduğunu düşünüyorlar ve yine de sayma ihtimalini reddettiler böyle yüksek standartlara sahip üzerinde. (Matematikte gördüğümüz çok daha güvenilir bir temelden çok, çok farklı bir tutum.)

Matematiksel kanıtlar “ne” bilgisini ve programlarını “nasıl“ bilgiyi ”tarif eder.

Program yazmak, programcının ortaya çıkabilecek farklı durumları ve programın davranışının sonuç olarak nasıl değiştiğini düşünmesi gerektiğinden daha karmaşıktır. Kanıtlar, diğer tanımlamalar hakkında bir şeyler kanıtlamak için formül veya kategorik akıl yürütmeyi kullanır.

Hataların çoğu, programcının öngörmediği durumlara giren süreçlerden kaynaklanır. Bir programda genellikle binlerce veya büyük bir sistemde, statik veri olmayan, ancak aslında programın çalışma şeklini değiştiren milyonlarca olası değişken vardır. Bütün bunlar birlikte etkileşim, özellikle altınızda değişen soyutlama katmanlarının olduğu modern bir bilgisayarda önceden görülmesi imkansız olan davranışlar yaratır.

Bir kanıt olarak, değişen bir durum yoktur. Tartışmanın tanımları ve nesneleri sabittir. Kanıtlamak genel olarak problemi düşünmeyi ve birçok vakayı dikkate almayı gerektirir, ancak bu davalar tanımlarla belirlenir.