วิธีการแก้ปัญหาแบบฮิวริสติก "ลองใช้กรณีทดสอบ": อัลกอริทึมที่ปรากฏถูกต้อง แต่จริง ๆ แล้วไม่ถูกต้อง

ในการพยายามทดสอบว่าอัลกอริทึมสำหรับปัญหาบางอย่างถูกต้องหรือไม่จุดเริ่มต้นตามปกติคือลองใช้อัลกอริทึมด้วยมือในกรณีทดสอบง่ายๆ - ลองกับตัวอย่างกรณีปัญหารวมถึงกรณีมุมง่าย ๆ สองสามตัวอย่าง " นี่เป็นวิธีแก้ปัญหาที่ยอดเยี่ยม: มันเป็นวิธีที่ดีในการกำจัดความพยายามที่ไม่ถูกต้องอย่างรวดเร็วของอัลกอริทึมและเพื่อทำความเข้าใจเกี่ยวกับสาเหตุที่อัลกอริทึมไม่ทำงาน

อย่างไรก็ตามเมื่อการเรียนรู้อัลกอริทึมนักเรียนบางคนถูกล่อลวงให้หยุดที่นั่น: หากอัลกอริทึมของพวกเขาทำงานอย่างถูกต้องกับตัวอย่างจำนวนหนึ่งรวมถึงกรณีมุมทั้งหมดที่พวกเขาสามารถคิดได้ลองพวกเขาสรุปว่าอัลกอริทึมต้องถูกต้อง มีนักเรียนคนหนึ่งที่ถามอยู่เสมอ: "ทำไมฉันต้องพิสูจน์อัลกอริทึมของฉันให้ถูกต้องถ้าฉันลองได้ในบางกรณีทดสอบ?"

ดังนั้นคุณจะหลอก "ฮิวริสติกแบบทดสอบกรณี" ได้อย่างไร ฉันกำลังมองหาตัวอย่างที่ดีเพื่อแสดงว่าฮิวริสติกนี้ไม่เพียงพอ กล่าวอีกนัยหนึ่งฉันกำลังมองหาหนึ่งหรือมากกว่าหนึ่งตัวอย่างของอัลกอริทึมที่เผินๆดูเหมือนว่ามันอาจจะถูกต้องและผลลัพธ์ที่ได้คำตอบที่ถูกต้องในอินพุตขนาดเล็กทั้งหมดที่ทุกคนมีแนวโน้มที่จะเกิดขึ้น ไม่ทำงาน อัลกอริทึมอาจทำงานได้อย่างถูกต้องกับอินพุตขนาดเล็กทั้งหมดและล้มเหลวสำหรับอินพุตขนาดใหญ่เท่านั้นหรือล้มเหลวเฉพาะสำหรับอินพุตที่มีรูปแบบที่ผิดปกติ

โดยเฉพาะฉันกำลังมองหา:

1. อัลกอริทึม ข้อบกพร่องจะต้องอยู่ในระดับอัลกอริทึม ฉันไม่ได้กำลังมองหาข้อผิดพลาดในการใช้งาน (ตัวอย่างเช่นอย่างน้อยที่สุดตัวอย่างควรเป็นผู้ไม่เชื่อเรื่องภาษาและข้อบกพร่องควรเกี่ยวข้องกับความกังวลด้านอัลกอริทึมมากกว่าปัญหาด้านวิศวกรรมซอฟต์แวร์หรือปัญหาการใช้งาน)

2. อัลกอริทึมที่บางคนอาจมีความน่าเชื่อถือ รหัสเทียมควรมีลักษณะที่ถูกต้องอย่างน้อยน่าจะเป็นไปได้ (เช่นรหัสที่ obfuscated หรือน่าสงสัยว่าไม่ได้เป็นตัวอย่างที่ดี) คะแนนโบนัสหากเป็นอัลกอริทึมที่นักเรียนบางคนคิดขึ้นมาเมื่อพยายามแก้ไขปัญหาการบ้านหรือการสอบ

3. อัลกอริทึมที่จะผ่านกลยุทธ์การทดสอบด้วยตนเองอย่างสมเหตุสมผลด้วยความน่าจะเป็นสูง คนที่ลองใช้กรณีทดสอบเล็ก ๆ น้อย ๆ ด้วยมือไม่น่าจะค้นพบข้อบกพร่อง ตัวอย่างเช่น "จำลอง QuickCheck ด้วยมือในกรณีทดสอบขนาดเล็กโหล" ไม่น่าจะเปิดเผยว่าอัลกอริทึมไม่ถูกต้อง

4. เป็นอัลกอริทึมที่กำหนดขึ้นโดยเฉพาะ ฉันเคยเห็นนักเรียนหลายคนคิดว่า "ลองใช้กรณีทดสอบด้วยมือ" เป็นวิธีที่สมเหตุสมผลในการตรวจสอบว่าอัลกอริธึมที่กำหนดขึ้นถูกต้องหรือไม่ แต่ฉันสงสัยว่านักเรียนส่วนใหญ่จะไม่คิดว่าการลองใช้กรณีทดสอบสองสามอันเป็นวิธีที่ดี อัลกอริทึม สำหรับอัลกอริธึมความน่าจะเป็นมักจะไม่มีวิธีที่จะบอกได้ว่าเอาต์พุตใด ๆ ที่ถูกต้องหรือไม่ และคุณไม่สามารถยกตัวอย่างได้มากพอที่จะทำการทดสอบทางสถิติที่มีประโยชน์กับการกระจายสัญญาณ ดังนั้นฉันอยากจะมุ่งเน้นไปที่อัลกอริธึมที่กำหนดขึ้นเนื่องจากพวกเขาเข้าใจหัวใจของความเข้าใจผิดของนักเรียนมากขึ้น

ฉันต้องการสอนความสำคัญของการพิสูจน์อัลกอริทึมของคุณให้ถูกต้องและฉันหวังว่าจะใช้ตัวอย่างสองสามอย่างเช่นนี้เพื่อช่วยกระตุ้นการพิสูจน์ความถูกต้อง ฉันต้องการตัวอย่างที่ค่อนข้างง่ายและเข้าถึงได้สำหรับนักศึกษาระดับปริญญาตรี ตัวอย่างที่ต้องใช้เครื่องจักรกลหนักหรือพื้นหลังทางคณิตศาสตร์ / อัลกอริธึมจำนวนมากมีประโยชน์น้อยกว่า นอกจากนี้ฉันไม่ต้องการอัลกอริทึมที่ "ผิดธรรมชาติ"; ในขณะที่มันอาจจะง่ายในการสร้างอัลกอริธึมประดิษฐ์แปลก ๆ เพื่อหลอกฮิวริสติกถ้ามันดูผิดธรรมชาติอย่างมากหรือมีแบ็คดอร์ที่เห็นได้ชัดที่สร้างขึ้นเพื่อหลอกฮิวริสติกนี้ ตัวอย่างที่ดีใด ๆ

ข้อผิดพลาดทั่วไปที่ฉันคิดคือการใช้อัลกอริทึมโลภซึ่งไม่ได้เป็นแนวทางที่ถูกต้องเสมอไป แต่อาจใช้ได้ในกรณีทดสอบส่วนใหญ่

ตัวอย่าง:เหรียญ ได้แก่และตัวเลข , แสดงเป็นผลรวมของ : s ด้วยเหรียญน้อยที่สุด n n d $d_1,\dots,d_k$$n$$n$$d_i$

วิธีการที่ไร้เดียงสาคือการใช้เหรียญที่ใหญ่ที่สุดเท่าที่จะเป็นไปได้ก่อน

ยกตัวอย่างเช่นเหรียญมีมูลค่า ,และ จะให้คำตอบที่ถูกต้องด้วยโลภสำหรับตัวเลขทั้งหมดระหว่างและ ยกเว้นหมายเลข 55 1 1 14 10 = 6 + 1 + 1 + 1 + 1 = 5 + $6$$5$$1$$1$$14$$10 = 6+1+1+1+1 = 5+5$

ฉันจำตัวอย่างจากอาร์ Backhouseได้ทันที(นี่อาจเป็นหนึ่งในหนังสือของเขา) เห็นได้ชัดว่าเขาได้รับมอบหมายการเขียนโปรแกรมที่นักเรียนต้องเขียนโปรแกรมปาสคาลเพื่อทดสอบความเท่าเทียมกันของสองสาย หนึ่งในโปรแกรมที่เปิดโดยนักเรียนมีดังต่อไปนี้:

issame := (string1.length = string2.length);

if issame then
  for i := 1 to string1.length do
    issame := string1.char[i] = string2.char[i];

write(issame);

ตอนนี้เราสามารถทดสอบโปรแกรมด้วยอินพุตต่อไปนี้:

"มหาวิทยาลัย" "มหาวิทยาลัย" จริง ตกลง$\Rightarrow$

"หลักสูตร" "หลักสูตร" จริง; ตกลง$\Rightarrow$

"" "" จริง ตกลง$\Rightarrow$

"มหาวิทยาลัย" "หลักสูตร" เท็จ; ตกลง$\Rightarrow$

"บรรยาย" "หลักสูตร" เท็จ; ตกลง$\Rightarrow$

"ความแม่นยำ" "ความแม่นยำ" เท็จ, ตกลง$\Rightarrow$

ทั้งหมดนี้ดูมีแนวโน้มมาก: โปรแกรมอาจใช้งานได้จริง แต่การทดสอบอย่างระมัดระวังยิ่งขึ้นด้วยการพูดว่า "บริสุทธิ์" และ "จริง" เผยให้เห็นผลลัพธ์ที่ผิดพลาด อันที่จริงแล้วโปรแกรมบอกว่า "จริง" ถ้าสตริงมีความยาวเท่ากันและมีอักขระตัวสุดท้ายเหมือนกัน!

อย่างไรก็ตามการทดสอบนั้นค่อนข้างละเอียด: เรามีสตริงที่มีความยาวต่างกันสตริงที่มีความยาวเท่ากัน แต่เนื้อหาที่แตกต่างกันและแม้แต่สตริงที่เท่ากัน นอกจากนี้นักเรียนยังได้ทดสอบและดำเนินการทุกสาขา คุณไม่สามารถโต้แย้งการทดสอบที่นี่ได้โดยไม่สนใจเลยเนื่องจากโปรแกรมนั้นง่ายมากมันอาจจะยากที่จะหาแรงจูงใจและพลังงานในการทดสอบอย่างละเอียดเพียงพอ

อีกตัวอย่างที่น่ารักคือการค้นหาแบบไบนารี่ ใน TAOCP, Knuth กล่าวว่า "แม้ว่าแนวคิดพื้นฐานของการค้นหาแบบไบนารี่จะค่อนข้างตรงไปตรงมา แต่รายละเอียดอาจยุ่งยากอย่างน่าประหลาด" เห็นได้ชัดว่าข้อผิดพลาดในการใช้งานการค้นหาแบบไบนารีของ Java ก็ไม่มีใครสังเกตเห็นมานานกว่าทศวรรษ มันเป็นข้อผิดพลาดล้นจำนวนเต็มและประจักษ์เท่านั้นด้วยการป้อนข้อมูลที่มีขนาดใหญ่พอ รายละเอียดยุ่งยากของการใช้งานค้นหา binary ยังถูกปกคลุมไปด้วยเบนท์ลีย์ในหนังสือเล่มไข่มุกเขียนโปรแกรม

บรรทัดล่าง: มันอาจเป็นเรื่องยากอย่างน่าประหลาดใจที่จะแน่ใจว่าอัลกอริธึมการค้นหาแบบไบนารี่นั้นถูกต้องเพียงแค่ทำการทดสอบ

ตัวอย่างที่ดีที่สุดที่ฉันเคยเจอคือการทดสอบเบื้องต้น:

อินพุต: จำนวนธรรมชาติ p, p! = 2
เอาท์พุท: เป็น pa นายกหรือไม่?
อัลกอริทึม: คำนวณ 2 ** (p-1) mod p ถ้า result = 1 ดังนั้น p คือไพร์มอย่างอื่น p ไม่ใช่

วิธีนี้ใช้ได้กับ (เกือบ) ทุกหมายเลขยกเว้นตัวอย่างตัวนับจำนวนน้อยมากและอีกอันหนึ่งต้องการเครื่องเพื่อค้นหาตัวอย่างตัวอย่างในช่วงเวลาที่เป็นจริง ตัวอย่างตัวอย่างแรกคือ 341 และความหนาแน่นของตัวอย่างจริงลดลงเมื่อเพิ่มค่า p แม้ว่าจะเป็นลอการิทึม

แทนที่จะใช้ 2 เป็นพื้นฐานของกำลังคนอาจปรับปรุงอัลกอริทึมโดยใช้เพิ่มเติมเพิ่ม primes ขนาดเล็กเป็นพื้นฐานในกรณีที่นายกคนก่อนกลับมา 1 และยังคงมีตัวอย่างกับโครงการนี้คือหมายเลขคาร์ไมเคิล ค่อนข้างหายาก แต่

นี่คืออันที่ฉันขว้างโดย google reps ในการประชุมที่ฉันไป มันถูกเข้ารหัสใน C แต่มันทำงานในภาษาอื่น ๆ ที่ใช้การอ้างอิง ขออภัยที่ต้องใช้รหัสใน [cs.se] แต่เป็นเพียงสิ่งเดียวที่จะอธิบายได้

swap(int& X, int& Y){
    X := X ^ Y
    Y := X ^ Y
    X := X ^ Y
}

อัลกอริทึมนี้จะทำงานสำหรับค่าใด ๆ ที่กำหนดให้กับ x และ y แม้ว่าพวกเขาจะมีค่าเดียวกัน มันจะไม่ทำงาน แต่ถ้ามันถูกเรียกว่า swap (x, x) ในสถานการณ์นั้น x สิ้นสุดเป็น 0 ทีนี้สิ่งนี้อาจไม่เป็นที่พอใจคุณเนื่องจากคุณสามารถพิสูจน์การดำเนินการนี้ว่าถูกต้องทางคณิตศาสตร์ แต่ก็ยังลืมเกี่ยวกับกรณีขอบนี้

มีทั้งชั้นของขั้นตอนวิธีการที่ยากที่โดยเนื้อแท้ในการทดสอบคือสุ่มหลอกกำเนิดจำนวน คุณไม่สามารถทดสอบเอาต์พุตเดี่ยว แต่ต้องตรวจสอบเอาต์พุต (หลายชุด) ด้วยวิธีทางสถิติ ขึ้นอยู่กับว่าคุณทดสอบอะไรและอย่างไรคุณอาจพลาดคุณลักษณะที่ไม่ใช่แบบสุ่ม

กรณีหนึ่งที่มีชื่อเสียงสิ่งที่ผิดพลาดไปอย่างน่ากลัวคือRandu มันผ่านการตรวจสอบที่มีอยู่ในเวลา - ซึ่งล้มเหลวในการพิจารณาพฤติกรรมของสิ่งอันดับของผลลัพธ์ที่ตามมา triples แสดงโครงสร้างจำนวนมากแล้ว:

โดยพื้นฐานแล้วการทดสอบไม่ครอบคลุมทุกกรณีการใช้งาน: ในขณะที่การใช้ RANDU แบบมิติเดียว (อาจเป็นส่วนใหญ่) ก็ดี แต่ก็ไม่สนับสนุนให้ใช้เพื่อทดสอบตัวอย่างจุดสามมิติ (ด้วยวิธีนี้)

การสุ่มตัวอย่างแบบหลอกเทียมที่เหมาะสมเป็นธุรกิจที่ยุ่งยาก โชคดีที่มีห้องทดสอบที่ทรงพลังอยู่หลายวันเช่นdieharderที่เชี่ยวชาญในการขว้างสถิติทั้งหมดที่เรารู้จักที่เครื่องกำเนิดไฟฟ้าที่เสนอ มันเพียงพอหรือไม่

^{เพื่อความเป็นธรรมฉันไม่ทราบว่าคุณสามารถพิสูจน์ได้สำหรับ PRNG อย่างไร}

สูงสุด 2 มิติในท้องถิ่น

$n \times n$$A$

$(i,j)$$A[i,j]$

$A[i, j+1], A[i, j-1], A[i-1, j], A[i+1, j]$$A$

จากนั้นแต่ละเซลล์ที่เป็นตัวหนาจะมีค่าสูงสุดในท้องถิ่น อาเรย์ที่ไม่ว่างจะมีค่าสูงสุดในท้องถิ่นอย่างน้อยหนึ่งค่า

$O(n^2)$

$A$$X$$X$$A$$(i, j)$$X$$(i, j)$$(i', j')$

$A \setminus X$$A$$X$$(i', j')$$A'$

$A'$$A$

$(i', j')$$A'$$A'$$(i', j')$$\diamond$

$\frac{n}{2}\times\frac{n}{2}$$A'$$(i, j)$

$T(n)$$n\times n$$T(n) = T(n/2) + O(n)$$T(n) = O(n)$

ดังนั้นเราได้พิสูจน์ทฤษฎีบทต่อไปนี้:

$O(n)$$n\times n$

หรือว่าพวกเรา

นี่เป็นตัวอย่างเบื้องต้นเพราะเป็นเรื่องธรรมดา

(1) อันดับแรกใน SymPy ฉบับที่ 1789 มีการทดสอบที่ไม่ถูกต้องวางอยู่บนเว็บไซต์ที่รู้จักกันดีซึ่งไม่ได้ล้มเหลวจนกระทั่งหลังจาก 10 ^ 14 ในขณะที่การแก้ไขถูกต้องมันเป็นเพียงการปะแก้หลุมมากกว่าคิดใหม่ปัญหา

(2) Primality ใน Perl 6 Perl6 ได้เพิ่ม is-prime ซึ่งใช้จำนวนการทดสอบ MR ที่มีฐานคงที่ มีตัวอย่างที่รู้จักกันดี แต่มีขนาดค่อนข้างใหญ่เนื่องจากจำนวนการทดสอบเริ่มต้นมีขนาดใหญ่มาก (โดยทั่วไปซ่อนปัญหาจริงโดยการลดประสิทธิภาพ) สิ่งนี้จะได้รับการแก้ไขในไม่ช้า

(3) ชนพื้นเมืองในฟลิ้นท์ n_isprime () คืนค่า true สำหรับคอมโพสิตเนื่องจากได้รับการแก้ไขแล้ว โดยทั่วไปปัญหาเดียวกันกับ SymPy การใช้ฐานข้อมูล Feitsma / Galway ของ pseudoprimes SPRP-2 ถึง 2 ^ 64 เราสามารถทดสอบสิ่งเหล่านี้ได้

(4) คณิตศาสตร์ของ Perl :: Primality เสีย is_aks_prime ลำดับนี้ดูเหมือนจะคล้ายกับการใช้งาน AKS มากมาย - รหัสจำนวนมากที่ทำงานโดยไม่ตั้งใจ (เช่นหลงทางในขั้นตอนที่ 1 และจบลงด้วยการทำสิ่งทั้งหมดโดยการแบ่งการทดลอง) หรือไม่ทำงานสำหรับตัวอย่างขนาดใหญ่ น่าเสียดายที่ AKS ช้ามากจนยากที่จะทดสอบ

(5) Pari pre-2.2 is_prime คณิตศาสตร์ :: ตั๋ว มันใช้ฐานสุ่ม 10 ฐานสำหรับการทดสอบ MR (ด้วยเมล็ดพืชคงที่เมื่อเริ่มต้นแทนที่จะเป็นเมล็ดตายตัวของ GMP ทุกครั้งที่เรียก) มันจะบอกคุณว่า 9 เป็นเรื่องสำคัญเกี่ยวกับ 1 จากการโทร 1M ทุกครั้ง หากคุณเลือกหมายเลขที่ถูกต้องคุณสามารถทำให้มันล้มเหลวบ่อยครั้ง แต่ตัวเลขนั้นกลายเป็นตัวแยกคำดังนั้นมันจึงไม่ปรากฏขึ้นมากนักในทางปฏิบัติ พวกเขาได้เปลี่ยนอัลกอริทึมและ API

นี่ไม่ผิดแต่เป็นคลาสสิกของการทดสอบความน่าจะเป็น: คุณบอกว่ามีกี่รอบที่ mpz_probab_prime_p ถ้าเราให้ 5 รอบมันดูเหมือนว่าจะทำงานได้ดี - ตัวเลขต้องผ่านการทดสอบเบส -210 แฟร์มาต์และจากนั้นเลือกเบสมิลเลอร์ราบิน 5 การทดสอบพื้นฐานที่เลือกไว้ล่วงหน้า คุณจะไม่พบตัวอย่างตัวอย่างจนกว่าจะถึง 3892757297131 (ด้วย GMP 5.0.1 หรือ 6.0.0a) ดังนั้นคุณต้องทำการทดสอบมากมายเพื่อค้นหา แต่มีตัวอย่างนับพันภายใต้ 2 ^ 64 ดังนั้นคุณจึงเพิ่มจำนวน ไกลแค่ไหน? มีปฏิปักษ์ไหม คำตอบที่ถูกต้องสำคัญแค่ไหน? คุณสับสนฐานสุ่มกับฐานคงที่หรือไม่? คุณรู้ขนาดของอินพุตที่คุณจะได้รับหรือไม่?

$10^{16}$

การทดสอบเหล่านี้ค่อนข้างยาก กลยุทธ์ของฉันรวมถึงการทดสอบหน่วยที่เห็นได้ชัดรวมถึงกรณีขอบและตัวอย่างของความล้มเหลวที่เห็นก่อนหน้าหรือในแพ็คเกจอื่น ๆ ทดสอบกับฐานข้อมูลที่เป็นไปได้ (เช่นถ้าคุณทำการทดสอบ MR-base-2 ครั้งเดียว ภารกิจในการทดสอบ 2 ^ 64 ตัวเลขไปยังการทดสอบประมาณ 32 ล้านหมายเลข) และสุดท้ายการทดสอบแบบสุ่มจำนวนมากโดยใช้แพคเกจอื่นเป็นมาตรฐาน จุดสุดท้ายใช้งานได้กับฟังก์ชั่นอย่าง primality ที่มีอินพุตค่อนข้างง่ายและเอาต์พุตที่รู้จัก แต่มีงานบางอย่างที่ค่อนข้างเช่นนี้ ฉันใช้สิ่งนี้เพื่อค้นหาข้อบกพร่องทั้งในรหัสการพัฒนาของตัวเองและปัญหาที่เกิดขึ้นเป็นครั้งคราวในแพ็คเกจเปรียบเทียบ แต่เมื่อกำหนดพื้นที่อินพุตไม่สิ้นสุดเราไม่สามารถทดสอบทุกสิ่งได้

สำหรับการพิสูจน์ความถูกต้องนี่เป็นอีกตัวอย่างหนึ่งของชนพื้นเมือง วิธีการ BLS75 และ ECPP มีแนวคิดของการรับรองแบบดั้งเดิม โดยทั่วไปหลังจากที่พวกเขาปั่นทำการค้นหาเพื่อค้นหาค่าที่ใช้ได้กับบทพิสูจน์พวกเขาสามารถส่งออกได้ในรูปแบบที่รู้จัก หนึ่งสามารถเขียนตัวตรวจสอบหรือให้คนอื่นเขียนได้ สิ่งเหล่านี้ทำงานได้เร็วมากเมื่อเทียบกับการสร้างและตอนนี้ (1) โค้ดทั้งสองชิ้นนั้นไม่ถูกต้อง (เพราะเหตุใดคุณจึงต้องการโปรแกรมเมอร์คนอื่นสำหรับ verifier) ​​หรือ (2) คณิตศาสตร์ที่อยู่เบื้องหลังแนวคิดการพิสูจน์นั้นผิด # 2 เป็นไปได้เสมอ แต่โดยทั่วไปแล้วสิ่งเหล่านี้ได้รับการตีพิมพ์และตรวจสอบโดยคนหลายคน (และในบางกรณีนั้นง่ายสำหรับคุณที่จะเดินผ่านตัวคุณเอง)

ในการเปรียบเทียบวิธีต่างๆเช่น AKS, APR-CL, แผนกการทดลองหรือการทดสอบ Rabin แบบกำหนดค่าได้ทั้งหมดไม่สร้างผลลัพธ์ใด ๆ นอกจาก "นายก" หรือ "คอมโพสิต" ในกรณีหลังเราอาจมีปัจจัยที่สามารถตรวจสอบได้ แต่ในกรณีก่อนหน้านี้เราไม่มีอะไรเหลือนอกจากเอาท์พุทหนึ่งบิตนี้ โปรแกรมทำงานถูกต้องหรือไม่? dunno

มันเป็นสิ่งสำคัญที่จะทดสอบซอฟต์แวร์มากกว่าตัวอย่างของเล่นเพียงไม่กี่ตัวอย่างและยังต้องผ่านตัวอย่างบางส่วนในแต่ละขั้นตอนของอัลกอริทึมและพูดว่า "ให้ข้อมูลนี้มันสมเหตุสมผลไหมที่ฉันมาอยู่ที่นี่กับสถานะนี้"

Fisher-Yates-Knuth ขั้นตอนวิธีการสับเป็น (ปฏิบัติ) ตัวอย่างและหนึ่งในซึ่งหนึ่งในนักเขียนของเว็บไซต์นี้มีความเห็นเกี่ยวกับ

อัลกอริทึมสร้างการเปลี่ยนลำดับแบบสุ่มของอาร์เรย์ที่กำหนดดังนี้:

 // To shuffle an array a of n elements (indices 0..n-1):
  for i from n − 1 downto 1 do
       j ← random integer with 0 ≤ j ≤ i
       exchange a[j] and a[i]

$i$$j$$0 \le j \le i$

อัลกอริทึม "ไร้เดียงสา" อาจเป็น:

 // To shuffle an array a of n elements (indices 0..n-1):
  for i from n − 1 downto 1 do
       j ← random integer with 0 ≤ j ≤ n-1
       exchange a[j] and a[i]

องค์ประกอบที่จะสลับถูกเลือกจากองค์ประกอบทั้งหมดที่มีอยู่ อย่างไรก็ตามเรื่องนี้ทำให้เกิดการสุ่มตัวอย่างลำเอียงของพีชคณิต (บางคนเป็นตัวแทน - ฯลฯ )

จริงหนึ่งสามารถมาขึ้นกับสับ Fisher-Yates-knuth ใช้ง่าย (หรือไร้เดียงสา) การวิเคราะห์การนับ

$n$$n! = n \times n-1 \times n-2 ..$$n$$n-1$

ปัญหาหลักในการตรวจสอบว่าอัลกอริธึมการสับเปลี่ยนนั้นถูกต้องหรือไม่ ( ลำเอียงหรือไม่ ) นั้นเป็นเพราะสถิติทำให้ต้องมีตัวอย่างจำนวนมาก บทความ codinghorrorฉันเชื่อมโยงดังกล่าวข้างต้นอธิบายว่าที่ (และกับการทดสอบจริง)

ตัวอย่างที่ดีที่สุด (อ่าน: สิ่งที่ฉันเจ็บปวดที่สุด) ที่ฉันเคยเห็นเกี่ยวกับการคาดคะเนโคลลาตซ์. ฉันอยู่ในการแข่งขันเขียนโปรแกรม (โดยมีรางวัล 500 ดอลล่าร์ในบรรทัดแรก) ซึ่งปัญหาอย่างหนึ่งคือการหาจำนวนขั้นต่ำของขั้นตอนที่ต้องใช้เพื่อให้ตัวเลขสองตัวถึงจำนวนเดียวกัน การแก้ปัญหาของหลักสูตรคือการสลับแต่ละขั้นตอนจนกว่าพวกเขาทั้งสองจะเข้าถึงสิ่งที่เคยเห็นมาก่อน เราได้รับช่วงของตัวเลข (ฉันคิดว่ามันอยู่ระหว่าง 1 ถึง 1000000) และบอกว่าการคาดคะเนโคลลาตซ์ได้รับการยืนยันถึง 2 ^ 64 ดังนั้นตัวเลขทั้งหมดที่เราได้รับจะมาบรรจบกันที่ 1 ในที่สุดฉันใช้ 32 บิต จำนวนเต็มที่ต้องทำตามขั้นตอนด้วย ปรากฎว่ามีหนึ่งหมายเลขชัดเจนระหว่าง 1 และ 1000000 (170,000 บางสิ่ง) ที่จะทำให้จำนวนเต็ม 32 บิตเพื่อล้นในเวลาที่กำหนด อันที่จริงตัวเลขเหล่านี้เป็นเสียงร้องที่หายากมาก 2 ^ 31 เราทดสอบระบบของเราสำหรับตัวเลขจำนวนมากที่มากกว่า 1000000 เพื่อ "มั่นใจ" ว่าการล้นไม่เกิดขึ้น ปรากฎว่ามีจำนวนน้อยกว่าที่เราไม่ได้ทดสอบทำให้เกิดการล้น เพราะฉันใช้ "int" แทน "long" ฉันได้รับรางวัลเพียง $ 300 แทนที่จะเป็น $ 500

เป้ 0/1ปัญหาเป็นสิ่งหนึ่งที่เกือบทุกนักเรียนคิดว่าแก้ปัญหาได้โดยธึม ที่เกิดขึ้นบ่อยครั้งมากขึ้นถ้าคุณก่อนหน้านี้แสดงให้เห็นการแก้ปัญหาโลภบางรุ่นที่เป็นปัญหาของเป้ที่โลภงานอัลกอริทึม

สำหรับปัญหาเหล่านั้นในชั้นเรียนฉันควรแสดงข้อพิสูจน์สำหรับเป้ 0/1 ( การเขียนโปรแกรมแบบไดนามิก ) เพื่อลบข้อสงสัยใด ๆ และสำหรับรุ่นปัญหาโลภด้วย จริงๆแล้วหลักฐานทั้งสองอย่างนั้นไม่สำคัญและนักเรียนอาจพบว่าพวกเขามีประโยชน์มาก นอกจากนี้ยังมีการแสดงความคิดเห็นเกี่ยวกับเรื่องนี้ในCLRS 3ed , บทที่ 16, หน้า 425-427

ปัญหา: ขโมยปล้นร้านค้าและสามารถบรรทุกน้ำหนัก W สูงสุดไว้ในกระเป๋าเป้สะพายหลังได้ มี n รายการและรายการที่มีน้ำหนัก wi และมีมูลค่า vi ดอลลาร์ สิ่งของที่โจรควรใช้ เพื่อเพิ่มผลประโยชน์ของเขา ?

ปัญหาเป้ 0/1 : การตั้งค่าเหมือนกัน แต่ไอเท็มอาจไม่แตกเป็นชิ้นเล็กดังนั้นโจรอาจตัดสินใจเลือกที่จะเอาไอเทมหรือปล่อยทิ้งไว้ (เลือกไบนารี) แต่อาจไม่ได้เศษเสี้ยวของไอเทม .

และคุณสามารถหาแนวคิดหรืออัลกอริทึมจากนักเรียนที่ทำตามแนวคิดเดียวกันกับปัญหารุ่นโลภนั่นคือ:

• ใช้ความจุทั้งหมดของกระเป๋าแล้วใส่วัตถุที่มีค่ามากที่สุดเท่าที่จะเป็นไปได้และวนวิธีนี้จนกว่าคุณจะไม่สามารถใส่วัตถุเพิ่มเติมได้เนื่องจากถุงเต็มหรือไม่มีสิ่งของที่มีน้ำหนักน้อยกว่าสำหรับใส่ในกระเป๋า
• วิธีคิดที่ผิดวิธีอื่น ๆ คือนำสิ่งของที่มีน้ำหนักเบาและใส่ของเหล่านี้ไว้สูงที่สุดถึงราคาต่ำสุด
• ...

มีประโยชน์สำหรับคุณไหม? ที่จริงแล้วเรารู้ว่าปัญหาเหรียญเป็นรุ่นที่มีปัญหาเครื่องหลัง แต่มีตัวอย่างเพิ่มเติมในป่าของปัญหาเป้โดยตัวอย่างสิ่งที่เกี่ยวกับเป้ 2D (ที่เป็นประโยชน์จริงเมื่อคุณต้องการตัดไม้สำหรับทำเฟอร์นิเจอร์ผมเห็นในท้องถิ่นจากเมืองของฉัน) มันเป็นเรื่องธรรมดาคิดว่า โลภทำงานที่นี่เช่นกัน แต่ไม่ใช่

ข้อผิดพลาดทั่วไปคือการใช้อัลกอริทึมการสับผิด ดูการอภิปรายเกี่ยวกับวิกิพีเดีย

$n!$$n^n$$(n-1)^n$

Pythons PEP450ที่นำเสนอฟังก์ชันสถิติในไลบรารีมาตรฐานอาจเป็นที่สนใจ ในฐานะที่เป็นส่วนหนึ่งของเหตุผลในการมีฟังก์ชั่นที่คำนวณความแปรปรวนในห้องสมุดมาตรฐานของไพ ธ อนผู้เขียน Steven D'Aprano เขียน:

def variance(data):
        # Use the Computational Formula for Variance.
        n = len(data)
        ss = sum(x**2 for x in data) - (sum(data)**2)/n
        return ss/(n-1)

ด้านบนดูเหมือนจะถูกต้องกับการทดสอบแบบไม่เป็นทางการ:

>>> data = [1, 2, 4, 5, 8]
>>> variance(data)
  7.5

แต่การเพิ่มค่าคงที่ทุกจุดข้อมูลไม่ควรเปลี่ยนค่าความแปรปรวน:

>>> data = [x+1e12 for x in data]
>>> variance(data)
  0.0

และความแปรปรวนไม่ควรเป็นค่าลบ:

>>> variance(data*100)
  -1239429440.1282566

ปัญหาเกี่ยวกับตัวเลขและความแม่นยำในการสูญหาย หากคุณต้องการความแม่นยำสูงสุดคุณจะต้องสั่งการปฏิบัติการของคุณด้วยวิธีใดวิธีหนึ่ง การนำไปใช้ที่ไร้เดียงสานำไปสู่ผลลัพธ์ที่ไม่ถูกต้องเนื่องจากการไม่แม่นยำมีขนาดใหญ่เกินไป นั่นเป็นปัญหาอย่างหนึ่งที่ฉันเรียนเกี่ยวกับตัวเลขที่มหาวิทยาลัย

แม้ว่านี่จะไม่ใช่สิ่งที่คุณต้องการ แต่ก็เป็นเรื่องง่ายที่จะเข้าใจและทดสอบกรณีเล็ก ๆ โดยที่ไม่ต้องคิดอะไรเลยจะนำไปสู่อัลกอริทึมที่ไม่ถูกต้อง

$n$$n^2+n+41$$0<d$$d\text{ divides } n^2+n+41$$d < n^2+n+41$

โซลูชันที่เสนอ :

int f(int n) {
   return 1;
}

$n= 0, 1, 2, \dotsc, 39$$n=40$

"ลองบางกรณีเล็ก ๆ และสรุปอัลกอริธึมจากผลลัพธ์" เข้าหาพืชผลบ่อยขึ้น (แม้ว่าจะไม่มากเท่าที่นี่) ในการแข่งขันการเขียนโปรแกรมซึ่งความกดดันจะเกิดขึ้นกับอัลกอริทึมที่ (a) รวดเร็วในการนำไปใช้ ) มีเวลาทำงานที่รวดเร็ว