คำถามติดแท็ก abstract-data-types

อาร์เรย์หรือเวกเตอร์เป็นเพียงลำดับของค่า พวกเขาสามารถดำเนินการได้อย่างแน่นอนด้วยรายการที่เชื่อมโยง นี่เป็นเพียงโหนดจำนวนมากที่มีตัวชี้ไปยังโหนดถัดไป สแต็คและคิวเป็นข้อมูลนามธรรมสองประเภทที่สอนกันทั่วไปในหลักสูตร Intro CS ที่ไหนสักแห่งในชั้นเรียนนักเรียนมักจะต้องใช้สแต็คและคิวโดยใช้รายการที่เชื่อมโยงเป็นโครงสร้างข้อมูลพื้นฐานซึ่งหมายความว่าเรากลับไปที่แนวคิด "การรวบรวมโหนด" เดียวกัน คิวลำดับความสำคัญสามารถสร้างขึ้นได้โดยใช้ Heap ฮีปสามารถถูกคิดเป็นต้นไม้ที่มีค่า min ที่รูท ต้นไม้ทุกประเภทรวมถึง BSTs, AVL, ฮีปสามารถถือเป็นชุดของโหนดที่เชื่อมต่อกันด้วยขอบ โหนดเหล่านี้เชื่อมโยงกันโดยที่หนึ่งโหนดชี้ไปที่อื่น ดูเหมือนว่าทุกแนวคิดของข้อมูลสามารถต้มลงไปยังโหนดที่มีพอยน์เตอร์ไปยังโหนดอื่นที่เหมาะสมเท่านั้น นั่นถูกต้องใช่ไหม? ถ้ามันง่ายขนาดนี้ทำไมตำราเรียนไม่อธิบายว่าข้อมูลเป็นเพียงแค่จุดเชื่อมต่อที่มีตัวชี้? เราจะไปจากโหนดไปยังรหัสไบนารีได้อย่างไร

21 algorithms  data-structures  abstract-data-types 

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

17 data-structures  abstract-data-types 

สมมติว่าเรามีชุดDDDและสมาชิกแต่ละคนเป็นคู่ข้อมูลและคีย์ เราต้องการโครงสร้างข้อมูลที่จะสนับสนุนการดำเนินการต่อไปนี้:DDD แทรกเข้า ,(d,k)(d,k)(d,k)DDD ลบสมาชิก (ไม่จำเป็นต้องค้นหาเพื่อค้นหาเช่นชี้ไปที่สมาชิกใน )eeeeeeeeeDDD MostFrequent ซึ่งส่งคืนสมาชิกเช่นนั้นเป็นหนึ่งในคีย์ที่พบบ่อยที่สุดใน (โปรดทราบว่าคีย์ที่บ่อยที่สุดไม่จำเป็นต้องไม่ซ้ำกัน)e∈De∈De \in De.keye.keye.keyDDD การใช้โครงสร้างข้อมูลนี้อย่างมีประสิทธิภาพคืออะไร โซลูชันของฉันคือฮีปสำหรับคีย์และความถี่ที่จัดลำดับความสำคัญด้วยความถี่พร้อมกับตารางแฮชที่ฟังก์ชันแฮชจะแมปสมาชิกที่มีคีย์เดียวกันกับสล็อตเดียวกันในตารางแฮช สิ่งนี้สามารถให้สำหรับการดำเนินการสองครั้งแรกและสำหรับครั้งที่สาม (เวลาที่เลวร้ายที่สุดในการรันกรณี)Θ(lgn)Θ(lg⁡n)\Theta(\lg n)Θ(1)Θ(1)\Theta(1) ฉันสงสัยว่ามีวิธีแก้ปัญหาที่มีประสิทธิภาพมากกว่านี้ไหม (หรือโซลูชันที่เรียบง่ายกว่าที่มีประสิทธิภาพเท่ากันใช่หรือไม่)

14 algorithms  data-structures  abstract-data-types 

คำตอบ Programmers.SEลักษณะการเขียนเรียงความโดย Cook ( วัตถุที่ไม่ได้ ADTs ) เป็นคำพูด วัตถุทำตัวเหมือนฟังก์ชั่นที่มีลักษณะเหนือค่าของประเภทมากกว่าเป็นพีชคณิต วัตถุใช้นามธรรมกระบวนการแทนที่จะเป็นนามธรรมประเภท ADTs มักจะมีการใช้งานที่ไม่ซ้ำกันในโปรแกรม เมื่อภาษาของคุณมีโมดูลเป็นไปได้ที่จะมีการใช้งาน ADT หลายครั้ง แต่พวกเขาไม่สามารถทำงานร่วมกันได้ สำหรับฉันแล้วดูเหมือนว่าในบทความของ Cook มันเกิดขึ้นเป็นกรณีที่สำหรับตัวอย่างที่เฉพาะเจาะจงของชุดที่ใช้ในกระดาษของ Cook วัตถุสามารถดูได้ว่าเป็นฟังก์ชั่นพิเศษ ฉันไม่คิดว่าวัตถุโดยทั่วไปสามารถดูได้เป็นฟังก์ชั่นที่มีลักษณะเฉพาะ นอกจากนี้กระดาษของ Aldritch พลังแห่งการใช้งานร่วมกันได้: ทำไมวัตถุจึงหลีกเลี่ยงไม่ได้ ¹แนะนำ คำจำกัดความของแม่ครัวระบุว่าการจัดส่งแบบไดนามิกเป็นคุณสมบัติที่สำคัญที่สุดของวัตถุ เห็นด้วยกับเรื่องนี้และกับอลันเคย์เมื่อเขาพูด OOP สำหรับฉันหมายถึงเพียงการส่งข้อความการเก็บรักษาในท้องถิ่นและการป้องกันและการซ่อนกระบวนการของรัฐและการผูกมัดปลายสุดของทุกสิ่ง อย่างไรก็ตามสไลด์บรรยายร่วมเหล่านี้ไปยังกระดาษของ Aldritch แนะนำว่าคลาส Java เป็น ADTs ในขณะที่ส่วนต่อประสาน Java เป็นวัตถุ - และแน่นอนว่าการใช้อินเตอร์เฟซ "วัตถุ" สามารถทำงานร่วมกันได้ (หนึ่งในคุณสมบัติหลักของ OOP ตามที่กำหนด ) คำถามของฉันคือ ฉันถูกต้องหรือไม่ที่จะบอกว่าฟังก์ชั่นพิเศษไม่ใช่คุณสมบัติหลักของวัตถุและ …

11 programming-languages  object-oriented  abstract-data-types