big-O นั้นเกี่ยวข้องกับการทำงานในอุตสาหกรรมหรือไม่?


65

ในการสัมภาษณ์ทุกครั้งที่ฉันเข้าร่วมฉันได้รับการวิเคราะห์ทางคณิตศาสตร์เกี่ยวกับความซับซ้อนรวมถึงสัญกรณ์ใหญ่

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


5
@ MM01 ฉันได้เรียนในโรงเรียนมัธยมและมหาวิทยาลัย แม้ว่าฉันจะรู้ว่ามันเป็นส่วนเสริมของความรู้โปรแกรมเมอร์ แต่ฉันไม่เคยใช้มันในงานใด ๆ ของฉัน
systempuntoout

27
อะไรที่แน่นอนอุตสาหกรรมที่คุณใคร่ครวญเมื่อถามนี้หรือไม่? คุณกำลังเขียนโค้ดควบคุมสำหรับ rover lunar หรือแพลตฟอร์มบล็อกหรือไม่?
ทิมโพสต์

14
@systempuntoout คุณไม่เคยเลือกอัลกอริธึมที่เร็วกว่าอีกเพราะมันเร็วกว่าไหม

3
@ MM01 - หากคุณกำลังดิ้นรนกับมันหนึ่งในคำอธิบายที่ง่ายที่สุด (แม้ว่าจะง่ายกว่า) สามารถดูได้ที่นี่: rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation
Tim โพสต์

6
@Systempuntoout การทำความเข้าใจและการใช้ O-notation ไม่ได้หมายความถึงการพิสูจน์ทางคณิตศาสตร์ที่เข้มงวด แต่สามารถถ่ายทอดในการแสดงออกที่เรียบง่ายว่าอัลกอริทึมของคุณทำงานอย่างไร หากคุณต้องการเรียงลำดับใน 1D คุณต้องการอัลกอริทึม O (n log n) หากคุณต้องการการติดตั้งหมายเลข Fibbonaccacci ให้เลือกอันที่ทำงานใน O (n) แม้ว่าคุณจะไม่ได้พูดออกมาอย่างชัดเจน แต่ก็ยังคงเป็นเวอร์ชั่นย่อของจำนวนลูปและการเรียกซ้ำซึ่งเป็นประโยชน์อย่างมาก บันทึกจำนวนมากของคำ (และสำหรับ nitpicky - ใช่, kมีความสำคัญเช่นกันถ้ามันมีขนาดใหญ่หรือเล็ก)

คำตอบ:


76

คำถามของฉันคือการทดสอบนี้มีความเกี่ยวข้องกับการพัฒนาในอุตสาหกรรมอย่างไร

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

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

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

(ฉันไม่รู้ว่ามันเป็นไปได้หรือไม่ที่จะใช้ระบบที่ปรับขนาดได้อย่างต่อเนื่องโดยไม่ต้องมีความเข้าใจทฤษฎีความซับซ้อนที่แน่นแฟ้นฉันจะโน้มเอียงที่จะคิดว่ามันไม่ได้เป็นอย่างนั้น)


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

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

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

@Tim Post - ฉันพูดว่า "... ใช้ระบบที่ปรับขนาดได้อย่างต่อเนื่อง ... " แน่นอนว่าคุณสามารถรับโชค แต่คุณไม่สามารถรับโชคดีอย่างสม่ำเสมอ แต่ฉันก็พร้อมที่จะยอมรับว่าคนที่ฉลาด / มีประสบการณ์สามารถพัฒนาความเข้าใจที่เข้าใจง่ายเกี่ยวกับความซับซ้อนโดยไม่ต้องไปใกล้ ๆ กับตำราเรียนหรือหลักสูตรวิทยาศาสตร์คอมพิวเตอร์
Stephen C

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

36

เหตุผลนี้เป็นเพราะมันแสดงให้เห็นความยืดหยุ่น

กระบวนการที่เป็น O (n ^ 2) จะแย่กว่ากระบวนการที่เป็น O (n log n) แต่จะดีกว่าหนึ่งใน O (n ^ 3) หรือแม้แต่ O (n!)

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


แก้ไข: การเปรียบเทียบ 48n กับ n ^ 3 จากhttp://www.codinghorror.com/blog/2007/09/everything-is-fast-for-small-n.html (ซึ่งจะมาจากการเขียนโปรแกรม Pearls)

ป้อนคำอธิบายรูปภาพที่นี่


8
+1: วิธีที่แย่ที่สุดที่จะทราบว่ากระบวนการของคุณไม่ได้ปรับขนาดคือการมีลูกค้าจำนวนมากตะโกนเรียกขึ้นมาพร้อมกัน
Larry Coleman

22
@ Larry อย่างน้อยเสียงกรีดร้องในแนวตรงกับจำนวนลูกค้า!

10
ฉันเดาว่าแค่แสดงให้เห็นว่า big-O สำคัญแค่ไหนนั่นคือเสียงจริงๆO(log Customers)dB
MSalters

4
@MSalters, ตกลงฉันยืนแก้ไข: "ที่จำนวนของเสียงกรีดร้องขนาดเส้นตรงกับจำนวนของลูกค้า" ระดับเสียงนั้นแตกต่างกัน

1
@ Thorbjørn Ravn Andersen: ฉันได้อ่านการศึกษาบางอย่างที่บ่งบอกว่ามันมีขนาดมากกว่าลอการิทึมซึ่งเป็นสาเหตุที่ชั้นเรียนร้องเรียนของลูกค้ามีความสำคัญมาก! พวกเขาระบุว่าฐานลูกค้าที่ใหญ่ขึ้นมีคนจำนวนมากที่มีปัญหานั้นและไม่ได้พูดอะไรหรือกำลังจะไปแข่งขัน
Steven Evers

32

ขึ้นอยู่กับสิ่งที่คุณทำ

สำหรับนักพัฒนาเว็บ (เช่นฉัน) สิ่งนี้มักจะสำคัญมาก คุณต้องการให้เว็บแอปพลิเคชันขยายขนาด หากแอปของคุณมีปัญหาคอขวดที่ปรับขนาดด้วย O (n ^ 2) และคุณคิดว่านี่เป็นเรื่องปกติเพราะเซิร์ฟเวอร์ของคุณสามารถรองรับผู้ใช้ 1,000 คนพร้อมกันดูเหมือนว่าคุณไม่จำเป็นต้องสนใจ สิ่งนี้คือจัดการสองเท่าให้มากที่สุด (ซึ่งมีความเป็นไปได้ที่จะเกิดขึ้นเพียงข้ามคืน) คุณจะต้องใช้พลังการคำนวณถึง 4 เท่า เป็นการดีที่คุณต้องการให้เว็บแอปขยายขนาดที่ O (n) เนื่องจากฮาร์ดแวร์ราคาถูกในอัตราส่วนผู้ใช้ / เซิร์ฟเวอร์คงที่

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

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


การสร้างแอพมือถือไม่ได้เป็นเพียงแค่การรวม GUI เข้าด้วยกัน แต่ฉันจะยกโทษให้คุณในการทำคำสั่งนั้นในปี 2010 :) มีความซับซ้อนในด้านสถาปัตยกรรมการทำเกลียวการจัดเก็บข้อมูลคิวเครือข่ายในมือถือ แต่ Big O ดิบนั้นไม่เกี่ยวข้อง (อย่างน้อยใน iOS) เพราะคุณควรใช้โครงสร้างข้อมูลและอัลกอริธึมดั้งเดิม
PostCodeism

21

ฉันไม่เคยใช้กฎอย่างเป็นทางการในชีวิตการทำงานของฉัน

อย่างไรก็ตามคุณต้องคุ้นเคยกับแนวคิดนั้นและนำไปใช้ในวิธีที่ง่ายทุกครั้งที่คุณออกแบบอัลกอริทึม

กฎคือ:

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


10

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

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

หากโปรแกรมเมอร์ต้นฉบับของโปรแกรมนี้เข้าใจ O-สัญกรณ์พวกเขาจะไม่ทำอย่างนั้น การแทนที่ความโง่เขลาด้วย hashtable ทำให้มันเร็วขึ้นมาก


8

ประสิทธิภาพของ Big-O มีความสำคัญ แต่ได้รับการปรับภายในเป็นส่วนใหญ่

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

ผลที่ได้คือปัญหาที่เป็นทางการไม่ค่อยเกิดขึ้นในทางปฏิบัติ แต่การฝึกฝนนั้นสร้างขึ้นบนหลักการเดียวกัน


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

6

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

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


5

บันทึกถึงตัวเอง!:

ฉันและคนอื่น ๆ ถามตัวเองด้วยคำถามนี้เป็นประจำ

ฉันคิดว่าเหตุผลที่แท้จริงที่เราถามคือเพราะเราขี้เกียจ

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

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


5

ไม่ได้จริงๆ โดยทั่วไปครั้งเดียวที่ฉันเคยคิดเกี่ยวกับมันคือเมื่อเข้าถึงฐานข้อมูล ฉันมักจะดูรหัสและพูดว่า "นั่นคือการสอบถาม n + 1 คุณควรเปลี่ยนเป็นเพียง 1 หรือ 2"

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

หากมีปัญหาเราจะทำการโปรไฟล์และแก้ไขในภายหลัง


1
ฉันคิดว่าการสอบถาม "n + 1" แบบไม่เป็นทางการมันอันตรายมาก โดยเฉพาะอย่างยิ่งฉันได้เห็นรหัสที่ทำให้ข้อความค้นหา n ^ d (โดยที่ d> = 2) ถูกไล่ออกเป็น "n + 1" ซึ่งทำให้สถานการณ์ที่น่ากลัวอย่างแท้จริงนั้นดูไม่ดี
philosodad

3

คุณตั้งคำถามสามข้อและฉันคิดว่าคำตอบสั้น ๆ สามารถช่วยให้ข้อโต้แย้งที่ยาวนานยิ่งขึ้นได้รับ

การทดสอบนี้มีความเกี่ยวข้องกับการพัฒนาในอุตสาหกรรมอย่างไร

ขึ้นอยู่กับอุตสาหกรรม

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

คุณใช้ซ้ำบ่อยแค่ไหน

ขึ้นอยู่กับอุตสาหกรรม

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

จำเป็นต้องมีความคิดที่เฉียบคมสำหรับปัญหาอย่างไร

จำเป็นอย่างยิ่ง

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


3

ฉันว่ามันบ่อยมาก โดยทั่วไปเราไม่ได้พิสูจน์บางสิ่งบางอย่างที่มีขนาดใหญ่ -O แต่เรามีความคิดภายในและจดจำ / คุ้นเคยกับการรับรอง -O ใหญ่สำหรับโครงสร้างข้อมูลและอัลกอริทึมเฉพาะและเราเลือกสิ่งที่เร็วที่สุดสำหรับการใช้งานเฉพาะอย่าง ช่วยให้มีไลบรารีที่เต็มไปด้วยตัวเลือกทั้งหมดเช่นไลบรารีคอลเลกชัน Java หรือ C ++ STL คุณใช้บิ๊กโอโดยปริยายและเป็นธรรมชาติทุกวันเมื่อคุณเลือกใช้java.util.HashMap( O(1)ค้นหา) แทนที่จะเป็นjava.util.TreeMap( O(lg n)ค้นหา) และแน่นอนว่าเลือกที่จะไม่เรียกใช้การค้นหาเชิงเส้นข้ามjava.util.LinkedList( O(n)ค้นหา) สำหรับบางสิ่งที่คุณไม่จำเป็นต้องเข้าถึงแบบเรียงลำดับ

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


3

ใช่

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

ฉันทำงานกับระบบที่แตกต่างกันสองระบบซึ่งดูเหมือนจะดีในการพัฒนาช่วงแรก แต่นำฮาร์ดแวร์มาที่หัวเข่าในการทดสอบการผลิตเพราะบางคนใช้อัลกอริทึม O (n ^ 2) และในทั้งสองกรณีการแก้ไขเป็นการเปลี่ยนแปลงเล็กน้อยสำหรับอัลกอริทึม O (n)


1

มันอาจใช้ในสถานที่ที่พวกเขากำลังพัฒนา API เพื่อการบริโภค C ++ STL เป็นหนึ่งในไม่กี่ API ที่มีข้อ จำกัด ด้านความซับซ้อนในอัลกอริทึม แต่สำหรับโปรแกรมเมอร์ประจำวัน / โปรแกรมเมอร์อาวุโส / ดีไซเนอร์ / สถาปนิกที่ทำงานประจำวัน


API คอลเลกชันที่ดีจะทำให้การค้ำประกันเหล่านี้ตัวอย่างเช่น API การรวบรวมของ Java มีการรับประกันเหล่านี้ในเอกสารประกอบ
Ken Bloom

1

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

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

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

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

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

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

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

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


0

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

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


0

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


-3

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

ทุกคนที่เรียนรู้วิศวกรรมซอฟต์แวร์อย่างคุ้มค่าจะต้องเจอ“ Big O” เพื่อตอบคำถามที่ดีเกี่ยวกับ“ Big O” คุณต้องเข้าใจโครงสร้างข้อมูลและอัลกอริธึมมาตรฐานด้วยเช่นกัน

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

ดังนั้นคำถามเกี่ยวกับ "บิ๊กโอ" จึงมีความเกี่ยวข้องกับกระบวนการสัมภาษณ์

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.