มีอัลกอริทึม O (1 / n) หรือไม่?

มีอัลกอริทึม O (1 / n) หรือไม่?

หรือสิ่งอื่นใดที่น้อยกว่า O (1)

คำถามนี้ไม่ได้โง่อย่างที่คิด อย่างน้อยในทางทฤษฎีบางสิ่งบางอย่างเช่นO (1 / n ) มีเหตุผลอย่างสมบูรณ์เมื่อเราใช้นิยามทางคณิตศาสตร์ของสัญลักษณ์Big O :

ตอนนี้คุณสามารถใช้แทนได้อย่างง่ายดายกรัม ( x ) สำหรับ 1 / x ... มันเห็นได้ชัดว่าคำนิยามดังกล่าวข้างต้นยังคงถือสำหรับบางฉ

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

def get_faster(list):
    how_long = (1 / len(list)) * 100000
    sleep(how_long)

เห็นได้ชัดว่าฟังก์ชั่นนี้ใช้เวลาน้อยลงเมื่อขนาดอินพุตเพิ่มขึ้น ... อย่างน้อยก็จนกว่าข้อ จำกัด บางอย่างจะถูกบังคับใช้โดยฮาร์ดแวร์ (ความแม่นยำของตัวเลข, เวลาน้อยที่สุดที่sleepสามารถรอ, เวลาในการประมวลผลข้อโต้แย้ง ฯลฯ ): ขีด จำกัด นี้จะเป็น ขอบเขตล่างคงที่ดังนั้นในความเป็นจริงฟังก์ชั่นด้านบนยังคงมี runtime O (1)

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

ใช่.

มีหนึ่งอัลกอริทึมที่แม่นยำพร้อมรันไทม์ O (1 / n) อัลกอริทึม "ว่าง"

สำหรับอัลกอริทึมที่จะเป็น O (1 / n) หมายความว่ามันดำเนินการแบบอะซิมโตติติกในขั้นตอนน้อยกว่าอัลกอริทึมที่ประกอบด้วยคำสั่งเดียว ถ้ามันดำเนินการในขั้นตอนน้อยกว่าหนึ่งขั้นตอนสำหรับ n> n0 ทั้งหมดจะต้องประกอบด้วยการเรียนการสอนที่ไม่มีเลยสำหรับ n เหล่านั้น เนื่องจากการตรวจสอบ 'ถ้า n> n0' มีค่าใช้จ่ายอย่างน้อย 1 คำสั่งจะต้องไม่มีคำสั่งสำหรับ n ทั้งหมด

สรุป: อัลกอริทึมเดียวซึ่งเป็น O (1 / n) เป็นอัลกอริทึมที่ว่างเปล่าซึ่งไม่มีคำสั่ง

คมชัดถูกต้อง O (1) เป็นประสิทธิภาพที่ดีที่สุด อย่างไรก็ตามมันไม่ได้หมายความถึงวิธีแก้ปัญหาที่รวดเร็วเพียงแค่โซลูชันเวลาที่แน่นอน

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

คนสองคนในชุดมีวันคล้ายวันเกิดหรือไม่ เมื่อ n เกิน 365 ให้ส่งคืนจริง แม้ว่าน้อยกว่า 365 นี่คือ O (n ln n) อาจไม่ใช่คำตอบที่ยอดเยี่ยมเนื่องจากปัญหาไม่ง่ายขึ้นอย่างช้าๆ แต่กลายเป็น O (1) สำหรับ n> 365

มันเป็นไปไม่ได้. คำจำกัดความของ Big-O ไม่ได้มากกว่าความไม่เสมอภาค:

A(n) = O(B(n))
<=>
exists constants C and n0, C > 0, n0 > 0 such that
for all n > n0, A(n) <= C * B(n)

ในความเป็นจริงแล้ว B (n) คือค่าสูงสุดดังนั้นหากมันลดลงเมื่อ n เพิ่มการประมาณจะไม่เปลี่ยนแปลง

จากการเรียนรู้ก่อนหน้านี้เกี่ยวกับสัญกรณ์ O ใหญ่ของฉันแม้ว่าคุณต้องการ 1 ขั้นตอน (เช่นการตรวจสอบตัวแปรทำการมอบหมาย) นั่นคือ O (1)

โปรดทราบว่า O (1) เหมือนกับ O (6) เนื่องจาก "ค่าคงที่" ไม่สำคัญ นั่นเป็นเหตุผลที่เราพูดว่า O (n) เหมือนกับ O (3n)

ดังนั้นหากคุณต้องการแม้แต่ 1 ขั้นตอนนั่นคือ O (1) ... และเนื่องจากโปรแกรมของคุณต้องการอย่างน้อย 1 ขั้นตอนอัลกอริธึมที่น้อยที่สุดก็คือ O (1) ถ้าหากเราไม่ทำมันก็คือ O (0) ฉันคิดว่างั้นเหรอ? ถ้าเราทำอะไรเลยมันก็จะเป็น O (1) และนั่นเป็นขั้นต่ำสุดที่จะทำได้

(ถ้าเราเลือกที่จะไม่ทำมันอาจกลายเป็นคำถามเซนหรือเทา ... ในขอบเขตของการเขียนโปรแกรม O (1) ยังคงเป็นขั้นต่ำ)

หรือวิธีการเกี่ยวกับเรื่องนี้:

โปรแกรมเมอร์ : เจ้านายฉันพบวิธีที่จะทำในเวลา O (1)!
เจ้านาย : ไม่จำเป็นต้องทำมันเราล้มละลายในเช้านี้
โปรแกรมเมอร์ : โอ้แล้วมันจะกลายเป็น O (0)

ไม่เป็นไปไม่ได้:

ในขณะที่ n มีแนวโน้มที่จะไม่มีที่สิ้นสุดใน 1 / n ในที่สุดเราก็บรรลุ 1 / (inf) ซึ่งเป็น 0 อย่างมีประสิทธิภาพ

ดังนั้นคลาสที่มีขนาดใหญ่ของปัญหาจะเป็น O (0) ที่มีค่า n มาก แต่ใกล้เวลาคงที่ด้วยค่าต่ำ n สิ่งนี้ไม่สมเหตุสมผลเนื่องจากมีเพียงสิ่งเดียวที่สามารถทำได้เร็วกว่าเวลาที่กำหนดคือ:

void nothing() {};

และแม้กระทั่งนี้ก็พิสูจน์ได้!

ทันทีที่คุณดำเนินการคำสั่งคุณจะอยู่ในอย่างน้อย O (1) ดังนั้นไม่เราไม่สามารถมีคลาส O (1 / n) อันยิ่งใหญ่!

ถ้าไม่ใช้งานฟังก์ชั่นเลย (NOOP) ล่ะ? หรือใช้ค่าคงที่ นั่นนับหรือไม่

ฉันมักจะใช้ O (1 / n) เพื่ออธิบายความน่าจะเป็นที่เล็กลงเมื่ออินพุตมีขนาดใหญ่ขึ้น - ตัวอย่างเช่นความน่าจะเป็นที่เหรียญยุติธรรมปรากฏขึ้นที่ส่วนท้ายของ log2 (n) การพลิกคือ O (1 / n)

O (1) หมายถึง "เวลาคงที่"

เมื่อคุณเพิ่มการออกก่อนหน้านี้ในลูป [1] คุณ (ในรูปของบิ๊กโอ) เปลี่ยนอัลกอริทึม O (1) เป็น O (n) แต่ทำให้เร็วขึ้น

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

1: สมมติความยาวรายการคงที่สำหรับตัวอย่างนี้

สำหรับใครก็ตามที่อ่านคำถามนี้และต้องการเข้าใจว่าบทสนทนานั้นเกี่ยวกับอะไรนี่อาจช่วยได้:

|    |constant |logarithmic |linear|  N-log-N |quadratic|  cubic  |  exponential  |
|  n |  O(1)   | O(log n)   | O(n) |O(n log n)|  O(n^2) |  O(n^3) |     O(2^n)    |
|  1 |       1 |          1 |     1|         1|        1|       1 |             2 |
|  2 |       1 |          1 |     2|         2|        4|       8 |             4 |
|  4 |       1 |          2 |     4|         8|       16|      64 |            16 |
|  8 |       1 |          3 |     8|        24|       64|     512 |           256 |
| 16 |       1 |          4 |    16|        64|      256|   4,096 |         65536 |
| 32 |       1 |          5 |    32|       160|    1,024|  32,768 | 4,294,967,296 |
| 64 |       1 |          6 |    64|       384|    4,069| 262,144 |   1.8 x 10^19 |

ฉันเชื่อว่าอัลกอริทึมควอนตัมสามารถทำการคำนวณหลายอย่าง "พร้อมกัน" ผ่านการทับซ้อน ...

ฉันสงสัยว่านี่เป็นคำตอบที่มีประโยชน์

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

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

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

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

เกี่ยวกับสิ่งนี้:

void FindRandomInList(list l)
{
    while(1)
    {
        int rand = Random.next();
        if (l.contains(rand))
            return;
    }
}

เมื่อขนาดของรายการโตขึ้นรันไทม์ที่คาดหวังของโปรแกรมจะลดลง

O (1 / n) ไม่น้อยกว่า O (1) ก็หมายความว่ายิ่งมีข้อมูลมากเท่าไหร่ สมมติว่าคุณได้รับอาเรย์และเติมองค์ประกอบมากถึง 10 ^{100 เสมอ}ถ้ามันมีค่าน้อยกว่านั้นและไม่ทำอะไรเลยถ้ามีมากขึ้น อันนี้ไม่ใช่ O (1 / n) แน่นอน แต่บางอย่างเช่น O (-n) :) สัญกรณ์ O-big ที่แย่เกินไปไม่อนุญาตให้มีค่าลบ

ดังที่มีการชี้ให้เห็นนอกเหนือจากข้อยกเว้นที่เป็นไปได้ของฟังก์ชัน null จะไม่มีO(1/n)ฟังก์ชั่นเนื่องจากเวลาที่ใช้จะต้องเข้าใกล้ 0

แน่นอนว่ามีอัลกอริทึมบางอย่างเช่นที่กำหนดโดย Konrad ซึ่งดูเหมือนว่าพวกเขาควรจะน้อยกว่าO(1)อย่างน้อยก็ในบางแง่มุม

def get_faster(list):
    how_long = 1/len(list)
    sleep(how_long)

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

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

อัลกอริทึมจำนวนมากสามารถเป็น O (h ^ p) หรือ O (n ^ {- p}) ขึ้นอยู่กับว่าคุณกำลังพูดถึงขั้นตอนขนาด (h) หรือจำนวนของแผนก (n) ตัวอย่างเช่นในวิธีของออยเลอร์คุณมองหาค่าประมาณ y (h) เนื่องจากคุณรู้ว่า y (0) และ dy / dx (อนุพันธ์ของ y) ค่าประมาณ y (h) ของคุณมีความแม่นยำมากขึ้นค่า h ที่ใกล้กว่าคือ 0 ดังนั้นเพื่อหาค่า y (x) สำหรับ x ตามอำเภอใจ x หนึ่งจะใช้ช่วงเวลา 0 ถึง x แยกออกเป็น n ส่วนและรันเมธอดของออยเลอร์ ในแต่ละจุดจะได้รับจาก y (0) ถึง y (x / n) ถึง y (2x / n) และอื่น ๆ

ดังนั้นวิธีของออยเลอร์จึงเป็นอัลกอริทึม O (h) หรือ O (1 / n) โดยที่ h ถูกตีความโดยทั่วไปว่าเป็นขนาดขั้นตอนและ n ถูกตีความเป็นจำนวนครั้งที่คุณแบ่งช่วงเวลา

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

สำหรับวิธีการของออยเลอร์ถ้าคุณใช้คะแนนลอยตัวให้ใช้ขั้นตอนและการยกเลิกเล็ก ๆ พอและคุณกำลังเพิ่มจำนวนเล็กน้อยให้เป็นจำนวนมากโดยไม่เปลี่ยนแปลงจำนวนมาก สำหรับอัลกอริทึมที่คำนวณอนุพันธ์โดยการลบจำนวนสองค่าจากฟังก์ชันที่ประเมินที่ตำแหน่งใกล้เคียงกันมากสองค่าโดยประมาณ y '(x) ด้วย (y (x + h) - y (x) / h) ในฟังก์ชัน y ที่ราบรื่น (x + h) เข้าใกล้ y (x) ส่งผลให้มีการยกเลิกขนาดใหญ่และประมาณการสำหรับอนุพันธ์ที่มีตัวเลขนัยสำคัญน้อยกว่า สิ่งนี้จะแพร่กระจายไปยังอัลกอริธึมที่คุณต้องการอนุพันธ์ (เช่นปัญหาค่าขอบเขต)

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

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

ฉันเห็นอัลกอริทึมที่เป็น O (1 / n) ยอมรับกับขอบเขตบน:

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

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

นี่เป็นกรณีที่เลวร้ายที่สุดของ infinity แต่ประสิทธิภาพของ case โดยเฉลี่ยลดลงเมื่อพื้นที่ข้อมูลเต็ม

ในการวิเคราะห์เชิงตัวเลขอัลกอริทึมการประมาณควรมีความซับซ้อนเชิงซีเอ็นโทติคย่อยในค่าเผื่อการประมาณ

class Function
{
    public double[] ApproximateSolution(double tolerance)
    {
        // if this isn't sub-constant on the parameter, it's rather useless
    }
}

ฉันเดาน้อยกว่า O (1) เป็นไปไม่ได้ เวลาใดก็ตามที่ algo ถูกเรียกว่า O (1) แต่สำหรับ O (1 / n) วิธีการเกี่ยวกับฟังก์ชั่นด้านล่าง (ฉันรู้ว่ามีหลายสายพันธุ์ที่นำเสนอในการแก้ปัญหานี้แล้ว แต่ฉันคิดว่าพวกเขาทุกคนมีข้อบกพร่องบางอย่าง (ไม่สำคัญพวกเขาอธิบายแนวคิดได้เป็นอย่างดี) ดังนั้นนี่คือข้อโต้แย้งเพียงประการเดียว:

def 1_by_n(n, C = 10):   #n could be float. C could be any positive number
  if n <= 0.0:           #If input is actually 0, infinite loop.
    while True:
      sleep(1)           #or pass
    return               #This line is not needed and is unreachable
  delta = 0.0001
  itr = delta
  while delta < C/n:
    itr += delta

ดังนั้นเมื่อเพิ่ม n ฟังก์ชั่นจะใช้เวลาน้อยลง นอกจากนี้ยังมั่นใจได้ว่าหากอินพุตเป็น 0 จริงแล้วฟังก์ชันจะใช้เวลาตลอดไปในการส่งคืน

บางคนอาจโต้แย้งว่ามันจะถูก จำกัด ด้วยความแม่นยำของเครื่องจักร ดังนั้น sinc eit จึงมีขอบเขตบนคือ O (1) แต่เราสามารถหลีกเลี่ยงสิ่งนั้นได้เช่นกันโดยรับอินพุตของ n และ C เป็นสตริง และนอกจากนี้และการเปรียบเทียบจะทำในสตริง แนวคิดก็คือด้วยสิ่งนี้เราสามารถลดขนาดเล็กได้ตามต้องการ ดังนั้นขีด จำกัด สูงสุดของฟังก์ชั่นจะไม่ถูก จำกัด แม้ว่าเราจะไม่สนใจ n = 0

ฉันยังเชื่อว่าเราไม่สามารถพูดได้ว่าเวลาทำงานคือ O (1 / n) แต่เราควรพูดอะไรบางอย่างเช่น O (1 + 1 / n)

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

ฉันไม่รู้เกี่ยวกับอัลกอริทึม แต่ความซับซ้อนน้อยกว่า O (1) ปรากฏในอัลกอริทึมแบบสุ่ม ที่จริงแล้ว o (1) (น้อย o) น้อยกว่า O (1) ความซับซ้อนแบบนี้มักจะปรากฏในอัลกอริทึมแบบสุ่ม ตัวอย่างเช่นที่คุณพูดเมื่อความน่าจะเป็นของเหตุการณ์บางอย่างมีค่าเป็น 1 / n พวกเขาจะแสดงด้วย o (1) หรือเมื่อพวกเขาต้องการบอกว่ามีบางอย่างเกิดขึ้นกับความน่าจะเป็นสูง (เช่น 1 - 1 / n) พวกเขาแสดงว่ามี 1 - o (1)

หากคำตอบเหมือนกันโดยไม่คำนึงถึงข้อมูลอินพุตคุณมีอัลกอริทึม O (0)

หรือในคำอื่น ๆ - คำตอบเป็นที่รู้จักกันก่อนที่จะส่งข้อมูลเข้า - ฟังก์ชั่นสามารถเพิ่มประสิทธิภาพออก - ดังนั้น O (0)

Big-O สัญกรณ์แสดงสถานการณ์กรณีที่เลวร้ายที่สุดสำหรับอัลกอริทึมซึ่งไม่เหมือนกับเวลาใช้งานทั่วไป มันง่ายที่จะพิสูจน์ว่าอัลกอริทึม O (1 / n) เป็นอัลกอริทึม O (1) ตามคำนิยาม
O (1 / n) -> T (n) <= 1 / n, สำหรับ n> = C> 0
O (1 / n) -> T (n) <= 1 / C, ตั้งแต่ 1 / n <= 1 / C สำหรับทุก n> = C
O (1 / n) -> O (1) เนื่องจากสัญกรณ์ Big-O ละเว้นค่าคงที่ (เช่นค่าของ C ไม่สำคัญ)

ไม่มีอะไรที่เล็กไปกว่าเครื่องหมาย O (1) Big-O ซึ่งหมายถึงลำดับความซับซ้อนที่ใหญ่ที่สุดสำหรับอัลกอริทึม

หากอัลกอริทึมมีรันไทม์ของ n ^ 3 + n ^ 2 + n + 5 ก็จะเป็น O (n ^ 3) พลังที่ต่ำกว่าไม่สำคัญที่นี่เพราะในขณะที่ n -> Inf, n ^ 2 จะไม่เกี่ยวข้องกับ n ^ 3

เช่นเดียวกันกับ n -> Inf, O (1 / n) จะไม่เกี่ยวข้องกับ O (1) ดังนั้น 3 + O (1 / n) จะเหมือนกับ O (1) จึงทำให้ O (1) การคำนวณที่เล็กที่สุดที่เป็นไปได้ ความซับซ้อน

inline void O0Algorithm() {}

นี่เป็นอัลกอริทึม O (1 / n) ที่ง่าย และมันก็ทำสิ่งที่น่าสนใจ!

function foo(list input) {
  int m;
  double output;

  m = (1/ input.size) * max_value;  
  output = 0;
  for (int i = 0; i < m; i++)
    output+= random(0,1);

  return output;
}

เป็นไปได้ O (1 / n) ตามที่อธิบายถึงวิธีการที่เอาท์พุทของฟังก์ชั่นการเปลี่ยนแปลงให้เพิ่มขนาดของการป้อนข้อมูล หากเรากำลังใช้ฟังก์ชั่น 1 / n เพื่ออธิบายจำนวนคำสั่งที่ฟังก์ชั่นดำเนินการก็ไม่จำเป็นที่ฟังก์ชันจะใช้คำสั่งเป็นศูนย์สำหรับขนาดอินพุตใด ๆ แต่เป็นสำหรับทุกขนาดอินพุตซึ่งมากกว่า n บางขีด จำกัด จำนวนคำสั่งที่ต้องการนั้นถูกล้อมรอบด้วยค่าคงที่บวกที่คูณด้วย 1 / n เนื่องจากไม่มีจำนวนจริงที่ 1 / n เป็น 0 และค่าคงที่เป็นค่าบวกดังนั้นจึงไม่มีเหตุผลว่าทำไมฟังก์ชันจึงถูก จำกัด ให้ใช้คำสั่ง 0 หรือน้อยกว่า