มีปัญหาใดที่จะง่ายขึ้นเมื่อพวกเขาเพิ่มขนาดหรือไม่

62

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

algorithms asymptotics

— dsaxton
แหล่งที่มา

7

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

— amon

1

@amon เวลาทำงานไม่ได้ระดับเช่น n มันต้องใช้เวลาเพียงเพื่ออ่าน hashes คุณได้รับเป็น input!

1 / n

$1/n$

n

$n$

n

$n$

— David Richerby

3

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

— Raphael

2

@DavidRicherby ในตัวอย่างนี้มันถูกต้องตามกฎหมายที่จะเพิกเฉยต่อค่าใช้จ่ายในการอ่านอินพุตตราบเท่าที่ฉันไม่ได้ทำรายการใด ๆ เกี่ยวกับค่าใช้จ่ายที่แน่นอน ความเร็วจะเพิ่มขึ้นเชิงเส้นตรงกับอินพุต ดังนั้น n • T (1)> T (n) แม้ว่าจะพิจารณาค่าใช้จ่ายในการอ่านอินพุต เช่นสำหรับปัญหานี้มันง่ายกว่าที่จะแก้ปัญหาอินพุทขนาดใหญ่ในคราวเดียวแทนที่จะแยกอินพุตแม้ว่าปัญหาจะแบ่งแยกได้ก็ตาม ฉันไม่ได้บอกว่า T (n)> T (n + 1) สำหรับทุกคน

— amon

4

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

n

$n$

n

$n$

— David Richerby

39

ไม่มันเป็นไปไม่ได้อย่างน้อยไม่ได้อยู่ในความรู้สึก asymptotic ที่คุณจำเป็นต้องมีปัญหาเพื่อให้ได้รับอย่างเคร่งครัดง่ายขึ้นตลอดไปเช่น\ $n \to \infty$

ให้เป็นเวลาทำงานที่ดีที่สุดที่เป็นไปได้สำหรับการแก้ปัญหาดังกล่าวโดยที่คือขนาดของอินพุต โปรดทราบว่าเวลาทำงานคือการนับจำนวนคำสั่งที่ดำเนินการโดยอัลกอริทึมดังนั้นจึงต้องเป็นจำนวนเต็มไม่เป็นลบ ในคำอื่น ๆสำหรับทุกnตอนนี้ถ้าเราพิจารณาฟังก์ชั่นเราจะเห็นว่าไม่มีฟังก์ชั่นดังกล่าวที่ลดความซ้ำซากจำเจอย่างเคร่งครัด (ไม่ว่าคืออะไรมันจะต้องมี จำกัด พูดแต่เมื่อลดลงอย่างซ้ำซากจำเจอย่างเคร่งครัดและ $T(n)$ $n$ $T(n) \in \mathbb{N}$ $n$ $T: \mathbb{N} \to \mathbb{N}$ $T(0)$ $T(0)=c$ $T$ $T(c) \le 0$ $T(c+1) \le -1$ ซึ่งเป็นไปไม่ได้) ด้วยเหตุผลที่คล้ายกันไม่มีฟังก์ชั่นที่ลดลงอย่างเข้มงวด asymptotically: เราสามารถพิสูจน์ได้ว่าไม่มีฟังก์ชันเวลาทำงานที่มีอยู่เช่นนั้นสำหรับ ,มีการลดลงอย่างเคร่งครัด monotonically (ฟังก์ชั่นดังกล่าวจะต้องกลายเป็นเชิงลบในที่สุด) $T(n)$ $n_0$ $n \ge n_0$ $T(n)$

ดังนั้นปัญหาดังกล่าวจึงไม่สามารถเกิดขึ้นได้ด้วยเหตุผลง่ายๆว่าเวลาทำงานต้องเป็นจำนวนเต็มไม่เป็นลบ

โปรดทราบว่าคำตอบนี้ครอบคลุมเฉพาะอัลกอริทึมที่กำหนดไว้แล้ว (เช่นเวลาทำงานที่เลวร้ายที่สุด) มันไม่ได้ตัดทอนความเป็นไปได้ของอัลกอริธึมแบบสุ่มซึ่งเวลาทำงานที่คาดว่าจะลดลงอย่างซ้ำซากจำเจตลอดไป ฉันไม่รู้ว่ามันเป็นไปได้สำหรับอัลกอริธึมที่มีอยู่หรือไม่ ฉันขอบคุณ Beni Cherniavsky-Paskin สำหรับการสังเกตนี้

— DW
แหล่งที่มา

9

นี่เป็นหลักฐานที่ดี แต่ฉันไม่เห็นด้วยกับหลักฐาน แทนที่จะขอรันไทม์ที่ลดความซ้ำซ้อนอย่างเคร่งครัดคำถามอาจจะต้องมีฟังก์ชั่นที่มี a, b กับ <b ดังนั้น T (a)> T (b) นั่นคือการลดลงแบบไม่จำเจอย่างเคร่งครัด แน่นอนว่ามันเป็นไปได้ที่จะหาฟังก์ชั่นจำนวนเต็มที่เหมาะสม แต่ทำไมต้องเป็นจำนวนเต็ม ฉันอยู่ภายใต้การแสดงผลว่าเวลาทำงานแสดงถึงเวลาไม่ใช่การนับการเรียนการสอน (ยกเว้นหลักสูตรสำหรับเครื่องทัวริง) และการแสดงออกของ T สามารถใช้การดำเนินการที่ไม่ใช่จำนวนเต็มเช่นการบันทึก () หรือเลขชี้กำลังไม่ใช่จำนวนเต็ม

— amon

2

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

— David Richerby

3

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

T (n) = n^{2} \cdot (1 + ϵ)^{- n} + n

$T(n) = n^2 \cdot (1+\epsilon)^{-n} + n$

T (n) \sim n

$T(n) \sim n$

T (n) \approx n^{2}

$T(n) \approx n^2$

n

$n$

— Raphael

2

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

T (n) \sim n

$T(n) \sim n$

T (n)

$T(n)$

n

$n$

n

$n$

n

$n$

T (n)

$T(n)$

n \leq c

$n \le c$

— DW

1

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

T

$T$

— เบนิเชอร์เคียฟสกี้ - ปาสกิ้

25

แม้ว่าจะไม่ใช่คำตอบสำหรับคำถามของคุณ แต่อัลกอริทึมการค้นหาสตริง Boyer-Moore เข้ามาใกล้ อย่างที่ Robert Moore พูดในหน้าเว็บของเขาเกี่ยวกับอัลกอริทึม

อัลกอริทึมของเรามีคุณสมบัติที่แปลกประหลาดซึ่งพูดโดยทั่วไปยิ่งลวดลายยาวเท่าไหร่ยิ่งอัลกอริธึมเร็วขึ้นเท่านั้น

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

— ริกฉูดฉาด
แหล่งที่มา

10

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

— Kevin

4

\sqrt{n}

$\sqrt{n}$

n

$n$

\log n

$\log n$

10

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

เส้นทาง : ยิ่งเส้นทางของคุณยาวขึ้นบางครั้งพวกเขาก็สามารถทำได้ง่ายขึ้น ตัวอย่างเช่นหากฉันต้องการให้ Google Maps บอกทิศทางให้ฉันไปทางตะวันตก 3,000 ไมล์ฉันสามารถขับรถไปที่ชายฝั่งตะวันตกได้และจะได้รับคำแนะนำในการขับรถข้ามประเทศ แต่ถ้าฉันต้องการไปทางตะวันตก 6,000 ไมล์ฉันจะจบลงด้วยคำแนะนำที่ง่ายกว่ามาก: ขึ้นเครื่องบินจากนิวยอร์คถึงฮอกไกโด การให้เส้นทางข้ามประเทศที่รวมการจราจรถนนสภาพอากาศและอื่น ๆ นั้นค่อนข้างเป็นอัลกอริธึม แต่การบอกให้ฉันขึ้นเครื่องบินและค้นหาเที่ยวบินในฐานข้อมูลนั้นค่อนข้างง่ายกว่า กราฟ ASCII ของความยากลำบากเทียบกับระยะทาง:

           |     /
           |    /
Difficulty |   /                  ____-------
           |  /           ____----
           | /    ____----
            ---------------------------------
                       Distance

การแสดงผล : บอกว่าฉันต้องการเรนเดอร์หนึ่งหน้าและเรนเดอร์ 1,000 หน้า; นี่เป็นโฆษณาบิลบอร์ดดังนั้นภาพสุดท้ายทั้งภาพต้องมีขนาด 10,000px คูณ 5,000 พิกเซล การแสดงผลหนึ่งใบหน้าในความเป็นจริงอาจทำได้ยาก - ด้วยความละเอียดหลายพันพิกเซลทั่วทั้งภาพคุณต้องใช้เครื่องจักรที่ทรงพลังจริงๆ - แต่สำหรับผู้คนกว่า 1,000 ใบหน้าแต่ละใบหน้านั้นต้องการเพียงสิบพิกเซลเท่านั้นและสามารถโคลนได้อย่างง่ายดาย! ฉันอาจแสดงผลได้ 1,000 ใบหน้าบนแล็ปท็อปของฉัน แต่การแสดงผลใบหน้าที่เหมือนจริงขนาด 10,000px จะใช้เวลานานและเครื่องที่ทรงพลัง กราฟ ASCII ของความยากลำบากเทียบกับวัตถุที่แสดงผลแสดงว่าความยากลำบากในการเรนเดอร์วัตถุ n ไปยังรูปภาพขนาดที่กำหนดลดลงอย่างรวดเร็ว แต่จากนั้นกลับช้า:

           | -    
           |- -                     _________
Difficulty |   --      ______-------            
           |     ------      
           |       
            ---------------------------------
                        Objects

การควบคุมฮาร์ดแวร์ : หลาย ๆ อย่างที่ฮาร์ดแวร์ทำได้ง่ายกว่ามาก "Move motor X 1 degree" นั้นยากและ / หรือเป็นไปไม่ได้และคุณต้องจัดการกับทุกสิ่งที่คุณไม่ต้องจัดการกับ "move motor X 322 degrees"

งานช่วงเวลาสั้น ๆ :สมมติว่าคุณต้องการให้รายการ X เปิด (เวลาน้อยมาก) ทุกวินาที ด้วยการเพิ่มระยะเวลาที่ X รันคุณจะต้องใช้ซอฟต์แวร์ที่ซับซ้อนน้อยลงรวมทั้งฮาร์ดแวร์

— Owen Versteeg
แหล่งที่มา

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

— David Richerby

ตัวอย่างการเรนเดอร์ไม่ใช่อินสแตนซ์ของปัญหาเดียวกัน: อันแรกคือการเรนเดอร์รูปภาพเดียว ภาพที่สองคือการแสดงภาพขนาดเล็กจำนวนมากแล้ววางสำเนาภาพเหล่านั้นไว้ในบางพื้นที่

— David Richerby

ฉันคิดว่า wrt เพื่อเดินทางพารามิเตอร์จะเป็นชื่อของ 2 เมืองและ n จะเป็นจำนวนอักขระที่เข้ารหัสพวกเขา

— emory

3

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

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

— Cort Ammon
แหล่งที่มา

2

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

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

ตัวอย่าง: ทางยาวที่สุดในรถยนต์ระหว่างลอนดอนและปารีสที่หลีกเลี่ยงการเยี่ยมเยียนเมืองฝรั่งเศสและเมืองอังกฤษสองครั้งและไม่ได้ไปประเทศอื่นคืออะไร คุณต้องไปเบอร์มิงแฮมก่อน Ashford, Orleans ก่อน Versailles, La Rochelle ก่อน Limoge ฯลฯ ...

เป็นที่ชัดเจนว่าปัญหานี้กับรายการที่ยาวจะง่ายขึ้นเมื่อเทียบกับรายการสั้น ๆ

ตัวอย่างการใช้งาน: ลองนึกภาพ playgame ที่จัดการโดยเครื่องและ IA ของคอมพิวเตอร์ต้องตรวจสอบว่าเขาต้องสำรวจเพิ่มเติมในการเล่นเพื่อค้นหาคำแนะนำเพิ่มเติมหรืออื่น ๆ ถ้าตอนนี้เป็นเวลาที่จะสรุปว่าการตัดสินใจที่ดีที่สุดคืออะไร .

— Juan Manuel Dato
แหล่งที่มา

2

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

— David Richerby

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

— Juan Manuel Dato

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

— Tom van der Zanden

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

— Juan Manuel Dato

n \log n

$n\log n$

1

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

ไม่มีการป้อนข้อมูล -> เดรัจฉานบังคับให้แตกสัญลักษณ์ทั้งหมดและคำใด ๆ ที่มีความยาว
ความยาวของรหัสผ่าน -> เดรัจฉานบังคับสัญลักษณ์ทั้งหมดในคำที่มีความยาวนั้น
สัญลักษณ์ที่มี -> ย่อรายการสัญลักษณ์ที่ต้องการตรวจสอบ
...
สัญลักษณ์ที่มีอยู่รวมถึงการเกิดขึ้นหลายครั้งและความยาว -> คำนวณการเปลี่ยนลำดับเท่านั้น
สัญลักษณ์ทั้งหมดในลำดับที่ถูกต้อง -> แก้ไขโดยทั่วไปแล้วเอง

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

ดังนั้นมันจึงขึ้นอยู่กับว่าคุณอนุญาตให้มีสิ่งที่เป็นนามธรรมมากน้อยเพียงใด

— RunOrVeith
แหล่งที่มา

2

b

$b$

0

ตามความเป็นจริงฉันมีปัญหาที่เล็กลงเมื่อข้อมูลเพิ่มขึ้น แอปพลิเคชั่นตัวหนึ่งของฉันบันทึกคุณสมบัติของผลิตภัณฑ์เฉพาะเจาะจง แอตทริบิวต์เป็นตัวอย่างเช่น CheeseType, Brand, Country, Area, MilkType เป็นต้นทุก ๆ เดือนฉันจะได้รับรายการชีสใหม่ที่เข้ามาในตลาดในช่วงเวลานั้นพร้อมกับคุณสมบัติ ตอนนี้คุณลักษณะเหล่านี้ถูกพิมพ์ด้วยมือโดยกลุ่มคน บางคนพิมพ์ผิดหรือไม่รู้จักคุณค่าของแอตทริบิวต์ทั้งหมด

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

อย่างที่คุณสามารถจินตนาการได้ด้วยระดับเสียงต่ำเสียงดังเป็นสิ่งสำคัญเกินกว่าจะแก้ไขได้อย่างถูกต้อง หากคุณมีอินสแตนซ์ของ Cheddar 5, 1 ของ Brie, 1 ของ Bri และ 1 ของ Chedar ฉันจะบอกได้อย่างไรว่าถูกต้องและพิมพ์ผิด? ด้วยปริมาณที่มากขึ้นความผิดพลาดมีแนวโน้มที่จะอยู่ในระดับต่ำมาก แต่ค่าที่หายากได้เพิ่มขึ้นเล็กน้อยที่สำคัญทำให้พวกเขาหลบหนีจากเสียง (ได้รับการสนับสนุนจากประสบการณ์) ในกรณีนี้ฉันจินตนาการได้ว่า 50,000 Cheddar, 3000 Brie, 5 Bri, 15 Chedar เป็นต้น

ดังนั้นใช่ปัญหาบางอย่างแก้ไขตัวเองในที่สุดเมื่อคุณมีข้อมูลเพียงพอ

— คริส
แหล่งที่มา

1

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

— David Richerby

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

— chris

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

— Dan Henderson

2

"ได้รับประสิทธิภาพมากขึ้น"! = "ทำให้ง่ายขึ้น"

— David Richerby

-1

พิจารณาปัญหา NP-complete 3-SAT หากคุณยังคงเพิ่มปัญหาโดยการให้อินพุตของแบบฟอร์ม x_i = จริง / เท็จคุณจะต้องแปลงการแยกความแตกต่างให้เป็นอนุประโยคสองตัวแปรซึ่งจะสร้างปัญหา 2-SAT ซึ่งเป็น P อย่างแน่นอนหรือคุณเพียงแค่ได้รับ คำตอบจริง / เท็จ

สำหรับกรณีที่มีความซ้ำซ้อนในอินพุต x_i = จริง / เท็จ (อินพุตเดียวกันมีจำนวนมากครั้งหรืออินพุตที่ขัดแย้ง) คุณสามารถเรียงลำดับอินพุตและละเว้นค่าซ้ำซ้อนหรือรายงานข้อผิดพลาดหากค่าขัดแย้งกัน

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

ตอนนี้สถานการณ์ที่เจ๋งจริง ๆ ก็คือถ้าเรายินดีที่จะยอมรับ T (0) (การใช้สัญลักษณ์ของ DW ในคำตอบข้างต้น) อาจไม่มีที่สิ้นสุด ตัวอย่างเช่น T (0) อาจเทียบเท่ากับการแก้ปัญหาการหยุดชะงักของทัวริง หากเราสามารถกำหนดปัญหาเช่นการเพิ่มอินพุตเพิ่มเติมแปลงเป็นปัญหาที่แก้ไขได้เราจะได้ทองคำ โปรดทราบว่ามันไม่เพียงพอที่จะแปลงเป็นปัญหาที่แก้ไขได้แบบไม่แสดงอาการ - เพราะนั่นเป็นสิ่งที่เลวร้ายพอ ๆ กับการบังคับให้ปัญหาเกิดขึ้น

— v vv cvvcv
แหล่งที่มา

1

อินพุตเฉพาะเหล่านี้ง่ายขึ้น อย่างไรก็ตามเมื่อคุณพิจารณาอินพุต 3SAT ที่เป็นไปได้ทั้งหมดโดยทั่วไปจะยากขึ้นอย่างมากเมื่อคุณเพิ่มส่วนเพิ่มเติม: อินพุตที่ยากคือสิ่งที่ไม่มีคำสั่ง "hint" หากคุณไม่อนุญาตให้ใช้อินพุตทั่วไปคุณจะต้องระบุว่าคุณอนุญาตให้ใช้อินพุตใด

— David Richerby

ก่อนอื่น: เราอยู่ในข้อตกลงที่เพิ่มอินพุตมากขึ้นสามารถเพิ่มเวลาทำงาน ฉันบอกว่าสิ่งเดียวกันข้างต้น ประการที่สองฉันพูดอย่างชัดเจนว่าเรากำลังรับ 3-SAT ที่มีอยู่และเพิ่มเฉพาะอินพุตของรูปแบบ x_i = จริง / เท็จ ฉันคิดว่านี่ชัดเจนเพียงพอและฉันไม่ต้องการชี้แจงเพิ่มเติม ฉันคิดว่าคุณกำลังประสบปัญหาในการตีความสิ่งที่ฉันเขียนผิดไปมากที่สุด โปรดอย่าเดือดร้อนตัวเอง

— v vv cvvcv

1

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

— David Richerby

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

— v vv cvvcv

ฉันเป็นนักวิทยาศาสตร์คอมพิวเตอร์ไม่ใช่ผู้อ่านใจ ทำให้การเรียกร้องของคุณแม่นยำเป็นงานของคุณไม่ใช่ของฉัน

— David Richerby

-1

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

$n$
$t$ $p$

$n$

3) เอาท์พุท:
เอาท์พุทเป็นเส้นทางระหว่างงานที่จะต้องดำเนินการโดยพนักงาน แต่ละพา ธ จะเชื่อมโยงกับจำนวนพนักงานที่รับไป ตัวอย่างเช่น:

$n1$
$n2$
$n3$
$n4$
$n5$

4) วิธีแก้ปัญหาที่เป็นไปได้: ทางออก
หนึ่งที่เป็นไปได้คือการคำนวณเส้นทางที่สั้นที่สุดไปยังโหนดที่ใกล้ที่สุดจาก A. นี่จะเป็นเส้นทางไปข้างหน้า จากนั้นคำนวณเส้นทางไปข้างหน้าซ้ำสำหรับแต่ละงานที่เยี่ยมชม ผลที่ได้คือต้นไม้ ตัวอย่างเช่น:

          
      ก่อนคริสต์ศักราช
    DE

$n$ $n1$ $n2$ $n2 \neq 0$

$n=\infty$ $n = 1$

$n$

— yemelitc
แหล่งที่มา

6

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

— DW

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

— yemelitc

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

— David Richerby

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

— yemelitc