ทำไมไม่ลองแสดงตัวเลขในอัลกอริธึมเชิงตัวเลข?

อัลกอริธึมเวลาแบบหลอกเทียมคืออัลกอริธึมที่มีเวลาทำงานพหุนามกับค่าอินพุต (ขนาด) แต่เวลาทำงานแบบเอ็กซ์โพเนนเชียลตามขนาดอินพุต (จำนวนบิต)

ตัวอย่างเช่นการทดสอบว่าตัวเลข$n$เป็นจำนวนเฉพาะหรือไม่ต้องการวนซ้ำผ่านตัวเลขตั้งแต่ 2 ถึง$n-1$และตรวจสอบว่า$n$ mod $i$เป็นศูนย์หรือไม่ หากตัวดัดแปลงใช้เวลา O (1) ความซับซ้อนของเวลาโดยรวมจะเป็น O (n)

แต่ถ้าเราปล่อยให้$x$เป็นจำนวนบิตที่ต้องการในการเขียนอินพุตดังนั้น$x = \log n$ (ไบนารี) ดังนั้น$n = 2^x$และเวลาการทำงานของปัญหาจะเป็น O ( $2^x$ ) ซึ่งเป็นเลขชี้กำลัง

คำถามของฉันคือถ้าเราพิจารณาการเป็นตัวแทนของอินพุต$n$ , ดังนั้นเสมอแล้วเวลา$x=n$หลอก - พหุนามจะเท่ากับความซับซ้อนของเวลาพหุนาม เหตุใดเราจึงไม่ทำเช่นนี้

ยิ่งไปกว่านั้นเนื่องจากมีอัลกอริธึมเวลาหลอกเทียมสำหรับเป้โดยใช้$x=n$ , เป้จะเป็นพหุนามเป็นผลลัพธ์ P = NP

สิ่งนี้หมายความว่าเป้นนารีที่เป็นเอกภาพในพีมันไม่ได้หมายความว่าเป้ (ด้วยตัวเลขที่เข้ารหัสด้วยเลขฐานสอง) อยู่ในพี

เป้เป็นที่รู้จักกันว่าเป็น NP- สมบูรณ์ หากคุณแสดงว่าเป้อยู่ใน P นั่นจะแสดงว่า P = NP

แต่คุณยังไม่ได้แสดงให้เห็นว่าเป้เป้น P คุณได้แสดงให้เห็นว่าเป้นนารีที่อยู่ในเป้น P อย่างไรก็ตามไม่ทราบว่าเป้นนารีที่ไม่สมบูรณ์นั้นเป็น NP-Complete (แท้จริงแล้วความสงสัยมาตรฐานก็คือ ) ดังนั้นการใส่เป้หลัง unary ใน P ไม่ได้หมายความว่า P = NP

ดังนั้นปัญหาใดบ้างที่เราควรใส่ใจเพิ่มเติมเกี่ยวกับเป้สะพายหลังหรือเป้หลังเอกนารี? หากแรงจูงใจของคุณขึ้นอยู่กับข้อกังวลในทางปฏิบัติคำตอบนั้นจะขึ้นอยู่กับขนาดของตัวเลขที่คุณต้องการแก้ปัญหาเครื่องหลัง: หากพวกเขามีขนาดใหญ่คุณต้องใส่ใจมากขึ้นเกี่ยวกับเครื่องหลังเครื่องหลัง หากแรงจูงใจของคุณขึ้นอยู่กับข้อกังวลทางทฤษฎีแล้วเป้น่าสนใจมากขึ้นเพราะมันช่วยให้เราได้รับความเข้าใจที่ลึกซึ้งยิ่งขึ้น - มันช่วยให้เราสามารถแยกความแตกต่างระหว่างขนาดเทียบกับขนาด - ในขณะที่เป้ unary ทำให้เราแตกต่าง

เพื่อตอบคำถามติดตามผลเกี่ยวกับอัลกอริธึมการเขียนโปรแกรมแบบไดนามิกสำหรับปัญหาเป้:

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

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

ฉันจะเพิ่มสิ่งเล็ก ๆ ลงในคำตอบของ DW:

ฉันเคยเห็นคนที่คิดว่าเพราะ unary Knapsack อยู่ใน P ดังนั้นเราจึงสามารถใช้มันแทน Knapsack ซึ่งอัลกอริทึมที่ดีที่สุดในปัจจุบันมีเวลาชี้แจง

$W=\{w_1, \ldots, w_n\}$$k$$O(nk)$

$O(nk)$

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

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

$k$$100$$100$$k$$2^{100}-1$$k$$k$$2^{100}-1$

$n$$n$$p(n)$$k$$p(n)$$k$$2^{p(n)}-1$$k$$k$

$n$$k$

ในระยะสั้นและเรียบง่ายฉันจะแสดงให้คุณเห็นว่าทำไม

$Tally$

x = input integer

factors = [];

for i in range(1, x + 1):
    if x % i == 0:
     factors.append(i)

 print(factors)

$x$$x$$O(2^n)$

$Tally/Unary$$O(n)$$x$

x = input tallies

factors = [];

for i in range(1, x + 1):
    if x % i == 0:
     factors.append(i)

 print(factors)

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