Kusuru kesin olarak gösteren, tekrarlanabilir bir test senaryosu oluşturmalısınız. Bu kadar eminseniz ve yazılım yaygın olarak kullanılıyorsa, teknik bir dergide yayınlanmasını garanti eder. Anahtar, şirketi dahil etmektir. Onlara test durumunuzu gösterin ve sonucu yayınlamakla ilgilendiğinizi belirtin. Yayın konusunda onlarla işbirliği yapmayı teklif edin. Bu şekilde, ya yanlış olduğunuzu göstermeye ya da haklı olduğunuzu kabul etmeye zorlanırlar. İkinci durumda, sorunu kabul ederek yüzlerini kurtarırlar. Seni görmezden gelirlerse, devam et.

Sorunun teknik yanıtı açık görünüyor: Sorunlarınız için "optimum" un ne anlama geldiğine dair net bir tanım varsa, her iki programı da çalıştırın ve hangisinin kazandığını görün, ardından sonuçları yayınlayın.

Siyaset hakkında nasıl ilerleyeceğinize dair herhangi bir tavsiye, vakanın gerçeklerini keşfetmek için teknik çalışmayı yapana kadar sadece spekülasyondur.

Bunlar olmak. Bir zamanlar kendi alanındaki endüstri standardı yazılım paketlerinden birinde bir "okul çocuğu hatası" keşfettik. Sonuçları sunduğumuz toplantıda, satıcının geliştirme ekibinin üç kıdemli üyesi (toplamda yaklaşık 300 kişi) başları ellerinde oturuyordu ve istersek onların belki de% 75'ini yok edebileceğimizi çok iyi biliyorduk. uluslararası kullanıcı tabanı. (Diğer% 25'in bir kısmı yaygaranın ne hakkında olduğunu anlamazdı ve ironik bir şekilde, en büyük bireysel müşterileri muhtemelen hatanın meydana gelmediği bilgisayar sistemlerini kullanıyorlardı - bu da hatayı başka kimsenin neden fark etmediğini açıklayabilir. önceki 10 yıl kadar).

Ancak bize sorunu çözmek için yazılım evini bombalamaktan çok daha fazla fayda sağladı, bu nedenle "en kısa sürede düzelt" seçeneğini ve "ASAP "beta test sürümünü edinmek yaklaşık 2 hafta sürdü.

Popüler olarak kullanılan bir yazılım paketinin ürettiği çözümün, yazılımın öyle olduğunu iddia etmesine rağmen optimal çözüm olmadığını gösteren bir örneğim var.

Bu bir muhtemelen hiçbir şey hakkında çok fazla telaş.

Varsa yazılım belgelerini okuyun . Hangi durumlarda "çözüm bulundu" dediği açıklamalıdır. Genellikle bu durum, optimallik için gerekli bir koşulla ilişkili birkaç parametrenin yeterince küçük olduğunu gösterir, bu da çözümün muhtemelen bulunduğunu gösterir. Burada garanti yok.

Dokümantasyonda bu davranış için bir neden bulamazsanız, beklenmedik davranışın meydana geldiği asgari bir çalışma örneği ile geliştiriciye yazın ve açıklama isteyin.

Popüler olarak kullanılan bir yazılım paketinin ürettiği çözümün, yazılımın öyle olduğunu iddia etmesine rağmen en uygun çözüm olmadığını gösteren bir örneğim var.

Yani yazılım iddia edebilir. çok fazla. Bu o kadar nadir bir durum değil.

Bu yüzden bu hatayı nasıl bildireceğimden emin değilim; tescilli, kapalı kaynaklı bir yazılımdır. İlk adım olarak, yazılım geliştiricisiyle hatayla ilgili olarak iletişime geçebilirim, ancak hataları bildirmek için basit bir yöntemi yok gibi görünüyor.

Üreticiyle herhangi bir şekilde iletişim kurmak, eğer Üreticiye (ve dolayısıyla dolaylı olarak kendinize ve başkalarına) yardım etmek istiyorsanız, özel bir yol belirtilmemiştir. Sadece hatanın gerçekten var olduğundan emin olun ve yeniden üretilebilmesi için onu iyice açıklayın.

Ancak daha büyük bir sorun, hatalı bir yazılıma dayalı sonuçlarla yayınlanan makalelerin tehlikeye atılabileceğidir.

Muhtemelen tüm yazılımlar biraz hatalı. Ayrıntıları bilmeden bu davanın ciddiyetini yargılamak zor. Bununla birlikte, bir yazılım paketine çok fazla güvenmemek, aynı zamanda eşzamanlı ürünleri de test etmek her zaman iyi bir fikirdir. Bu kağıtları kontrol edebilir ve hatadan etkilenip etkilenmediklerini ve etkileniyorlarsa ne kadar etkilendiklerini görebilirsiniz.

Nihai düzeltme yazılımın çalıştırılmasının çok daha uzun sürmesine neden olursa ne olur? büyük örneklerde çalıştırmak artık mümkün değil mi?

Bir sorunu doğru şekilde çözmesi daha uzun süren sabit bir yazılım her zaman hatalı ve hızlı bir yazılıma tercih edilir. Bu sadece büyük örnekler için doğru çözümlerin şimdiye kadar hiçbir zaman mümkün olmadığı anlamına gelir.

Danışmanıma konuyu anlattım, ancak muhtemelen olası sonuçlar nedeniyle pek ilgilenmiyor gibi görünüyor.

Belki de hatasız yazılım kullanmayı pek umursamıyor veya hatanın varlığından henüz emin değil ya da şirketi rahatsız edemeyecek kadar tembel ya da herhangi bir çatışma istemiyor.

Şu anda bu yazılımı kullanabileceğim bir proje üzerinde çalışıyorum; Şimdi ona güvenmiyorum ve çok daha az güçlü bir açık kaynak alternatifine geçtim.

Biraz güveni kaybetmek doğal ama belki hepsini değil. Projenizin özel koşullarında hala güvenilebiliyorsa, eski yazılımı dikkatlice değerlendirebilir (hataların ara sıra meydana geldiğini göz önünde bulundurarak), sonra onu kullanmak isteyip istemediğinize veya her iki yazılım projesini de kullanmak isteyip istemediğinize karar verebilirsiniz. yalnızca alternatif yazılımı kullanmak istiyorum (bu da hatalı olabilir, bu yüzden ona da tamamen güvenmeyin).

Sanırım sorum şu: Bu durumu nasıl ele almalıyım?

• Şirketle iletişime geçmeli ve onlara hatayı anlatan kısa bir mesaj yazmalısınız. Hızlı bir şekilde düzeltip güveni geri kazanabilirler.
• Ayrıca hatayı yayınlayabilirsiniz (blogunuzda, bir posta listesinde, hatta hata yeterince önemliyse ve bir dergi bununla ilgileniyorsa teknik bir rapor olarak bile) ) böylece diğerleri bunun farkındadır, özellikle de şirket bunu hızlı bir şekilde çözmezse.
• Sahip olduğunuz iki yazılım paketini kullanmalı ve bunları karşılaştırmalısınız. Her ikisinin de, onlar hakkında henüz hiçbir şey bilmediğiniz hataları olabileceğini varsayın.

Bence yanıtlamanız gereken ilk soru, sorunun gerçekte ne kadar olduğu. Bu sadece uç bir durum mu? "En uygun" çözüm yalnızca marjinal olarak daha mı iyi? Gerçek kullanım durumu ve çözümleri hakkında daha fazla ayrıntı olmadan çok şey söylemek zor. Doktora programım için üzerinde çalıştığım bazı optimizasyon / uydurma problemleriyle, sonsuza kadar "daha" en uygun çözümleri araştırabilirsiniz, ancak verilerin ne kadar gürültülü olduğuna bağlı olarak, bu aslında yeni çözümlerin "daha iyi" olduğu anlamına gelmiyordu . Problem setinizi ve temeldeki optimizasyon algoritmalarını iyi anladığınızda, kapalı kaynak yazılımda tam olarak neyin yanlış gittiğini ve gerçek bir problem olup olmadığını anlayabilmelisiniz.

For bu tartışmanın geri kalanında, bir tür ampirik veri kümesine optimum uyumu bulmaya çalıştığınızı varsayacağım. Eğer öyleyse, bir çeşit chi ^ 2-parametreli uzayda etkili bir şekilde arama yapıyorsanız, daha uygun bir uyumu bulmak çok farklı şeyler anlamına gelebilir, örneğin

1. chi ^ 2 alanınız gürültülü ve a " daha iyi "çözüm aslında hiçbir şey ifade etmiyor
2. Tescilli sistem yerel minimumda sıkışıp kalıyor ve bulduğunuz global minimum değeri bulamıyor
3. İkiniz de aynı şeyi araştırıyorsunuz küresel minimum ancak çözümünüz biraz daha yakın

Etkili bir şekilde, optimum çözümü bulma süreci çok zor olabilir ve kullanılabilecek, her biri kendi yararları ve dezavantajları olan bir dizi farklı algoritma vardır. Fitting parametreleriniz ile chi ^ 2 arasında sorunsuz değişen bir ilişkiniz varsa, hemen hemen her optimizasyon yöntemi minimumu bulabilir, ancak hayat her zaman o kadar basit değildir. Bütün bunlar, belirli bir problemde daha iyi bir optimum bulmuş olsanız bile, bu, yazılımın çöp olduğu ve atılması gerektiği anlamına gelmez. Özellikle, daha iyi olanı nasıl buldunuz? Genel olarak bu tür optimizasyon problemlerine aynı yöntemi uygulayabilir misiniz? Her zaman daha iyi uyum sağlayacak mı? Bu son iki sorudan herhangi birinin cevabı hayır ise, burada gerçekten çok önemli bir şey olmadığını söyleyebilirim. Büyük olasılıkla tek gerçek sorun, hiçbir yazılım sisteminin gerçekçi olarak sunamayacağı şeyleri vaat eden söz konusu yazılım şirketiyle aşırı hevesli bir pazarlamacıdır.

Özetle şunu söyleyebilirim ki, gerçekten bununla koşmadan önce, algoritmalarının neden en uygun çözümü bulamadığını ve bu bile pratikte önemli olup olmadığını ayrıntılı olarak anlamanız gerekir.

CPLEX gibi iyi bilinen ticari optimizasyon paketlerinin stres altında yanlış sonuç verdiğini gördüm, tabiri caizse --- söz konusu yazılımla kağıt üzerinde çözülebilen, ancak pratikte test edildiklerinden yeterince farklı olan sorunları çözüyor

Yanlış derken, olabildiğince yanlış demek istiyorum, yani doğrusal bir optimizasyon problemi uygulanabilir olmadığı bildirilirken, bir fizibilite sertifikası üretme isteği başarısız olur (ve daha yüksek bir hassasiyetle çözülürse) daha yavaş bir açık kaynak çözücü ise, sorun uygulanabilir hale gelir).

Er ya da geç hata, eğer bir hata varsa, bulunacak ve açığa çıkacaktır, bilim böyle çalışır. Bu arada, geçtiğimiz birkaç yıl içinde, diğer şeylerin yanı sıra, bir monografideki ve ders kitaplarındaki hataları düzelten (sic!) Makaleler yayınladım; ilgili hatalı makaleler 20 yıldan fazla bir süre önce yayınlandı. Pekala.