Üretim yazılımında genel durum üstel zaman algoritmaları ne kadar yaygındır?

Üstel zaman algoritmalarından genel olarak kaçınılması gerektiğini, ancak bazen gerekli olduğunu biliyorum. Gezgin Satıcı olgusu. Bu tür algoritmalar üretim yazılımında ne kadar yaygındır? Bu durumlar genellikle gerekli mi yoksa acele işlerin bir sonucu mu? Birçoğunun iyi bir buluşsal yöntemle çözülebileceğini anlıyorum. Genellikle yapamayanlarla neler yapılır?

Değil bir şey de yapmış üretim yazılımı ancak üzerinde üretim yazılım olan biçimsel doğrulama . Muhtemelen çoğu müşteri yazılımı için kabul edilmez, ancak gömülü sistemler ve sürücüler için, yani doğruluğu önemli (ve izlenebilir) olan yazılım ve yazılımlar için iz kazanır.

Aslında hesaplanabilir olan bu doğrulama problemleri (bariyer # 1) genellikle EXPTIME -hard, daha şanslı durumlarda PSPACE-tamamlanmış problemler (bariyer # 2) alırsınız . Her iki sınıf da NP-tamamlanmış problemlerden daha zordur (şüphelenilir) ve bu da karşılaştırması kolaydır. Şüpheli üstel problemler de kolayca elde edilebilir.

Bu durumlarda, sezgisel tarama (sonuç sonucu anlamında) kesin sonuçlara ihtiyaç duyduğunuz için kesmez; bu nedenle büyük makinelere ve zamana ihtiyacınız var. Genellikle daha kısa çalışma süresine (yani, hata durumları arandığında akıllı arama alanı keşfi) yol açan sezgisel tarama (alternatif seçim anlamında) vardır, ancak en kötü durumda, tüm yapabileceğiniz beklemek. Ya da bir kalem ve kağıt kanıtı yapabilir ve hesap makineleri daha basit olan makineler tarafından kontrol edilmesini sağlayabilirsiniz .

Üstel en kötü durum karmaşıklığına sahip yaygın olarak kullanılan algoritma , doğrusal programlamada kullanılan simpleks yöntemidir . Ancak, bu yöntemin genel durum karmaşıklığı açık bir konudur. Bazı özel varsayımlarla polinomdur.

Programlama dili tercümanları üstel süreden daha kötüdür (girdilerinin uzunluğunda, yani yorumladıkları programın uzunluğunda) ve oldukça yaygındır. Başka bir örnek, otomatik teoremi kanıtlama / kısıtlama çözme / sat çözme / tamsayı doğrusal programlamadır. Ve yine bir başka örnek, örneğin Maple / Mathematica'da uygulandığı gibi sembolik farklılaşmadır (her ne kadar alt ifadeleri düğümler arasında paylaşmanıza izin verilirse doğrusal zamanda sembolik farklılaşma yapmak mümkündür).

Gezici satıcı sorunu örneğini ele alalım. Birkaç kez üzerinde çalıştım.

Seyahat eden satıcı sorununa çözüm yazmış bir takımda bulunduğumda, ancak birkaç parametre daha var. Örneğin, her biri benzersiz bir beceri setine sahip bir teknisyen ve mühendis filosuna sahip bir mağaza olabilir. Destinasyonlar her gün servis talepleri şeklinde gelir. Tüm programlar orijinal olarak yazıldığından beri değişiklikler ve bakım geçirmiş olsalar da üretimde.

Bu şekilde çalıştılar. Her mühendis, el tipi bir cihazda her gün servis edilecek şeylerin bir listesini alacaktı. Her hizmet görevini bitirdiklerinde, vakayı kapatmaları gerekir. Dışarıda bırakılan vakalar, ertesi gün için planlanacak vakalara, o zamana kadar müşterinin bazı memnuniyetsizliklerini ifade edeceği için biraz daha yüksek önceliğe katılır. Bir mühendisin davaya katılmamasının çok çeşitli nedenleri vardı. Trafik sorunları en yaygın olanıydı.

Ne kadar yaygındır? En azından müşterilerden gelen satış sonrası hizmet taleplerinin sayısı kadar yaygındır. Örneğin satış sonrası servis olmadan, müşterileri elde tutmak zor olacak ve yenilerini kazanmak daha zor olacaktır.

Amazon ve diğer kitap mağazaları gibi birçok web tabanlı mağazanın ve bu tür mağazaların işini iyi yapmasıyla, seyahat satıcısının eskisinden daha yaygın olduğunu düşünürdüm. Ayrıca, seyahat satıcısı sorununun ders kitaplarında öğretilen birçok varyasyonu olabilir.