Data 🎲 Structures 📝 and Algorithms 🤹🏻 | Code Katha 🥋 Series 🎞️ | Part 02 | Index 🗺️ Heaps 🧱

𝖭𝗈𝗐 𝗍𝗁𝖺𝗍 𝗐𝖾 𝗁𝖺𝗏𝖾 𝖼𝗈𝗏𝖾𝗋𝖾𝖽 𝖺 𝗇𝗈𝗋𝗆𝖺𝗅 𝗁𝖾𝖺𝗉 𝗂𝗇 𝗍𝗁𝖾 𝗅𝖺𝗌𝗍 𝖺𝗋𝗍𝗂𝖼𝗅𝖾. 𝖠 𝗇𝖺𝗍𝗎𝗋𝖺𝗅 𝗉𝗋𝗈𝗀𝗋𝖾𝗌𝗌𝗂𝗈𝗇 𝗂𝗌 𝗍𝗈 𝗎𝗇𝖽𝖾𝗋𝗌𝗍𝖺𝗇𝖽 𝗂𝗍'𝗌 𝗅𝗂𝗆𝗂𝗍𝖺𝗍𝗂𝗈𝗇𝗌 𝖺𝗇𝖽 𝗍𝗈 𝗍𝗋𝗒 𝖺𝗇𝖽 𝗈𝗏𝖾𝗋 𝖼𝗈𝗆𝖾 𝗍𝗁𝖾𝗆. 𝖳𝗁𝖾 𝗀𝗋𝖾𝖺𝗍𝖾𝗌𝗍 𝗅𝗂𝗆𝗂𝗍𝖺𝗍𝗂𝗈𝗇 𝗈𝖿 𝗍𝗁𝖾 𝗁𝖾𝖺𝗉 𝗐𝖾 𝗐𝗋𝗈𝗍𝖾 𝗂𝗌 𝗍𝗁𝖺𝗍 𝗂𝗍 𝖽𝗈𝖾𝗌 𝗆𝖺𝗇𝗒 𝗍𝗁𝗂𝗇𝗀𝗌 𝗉𝖾𝗋𝖿𝗈𝗋𝗆𝖺𝗇𝗍𝗅𝗒 𝖻𝗎𝗍 𝖽𝗈𝖾𝗌𝗇'𝗍 𝖽𝗈 𝖽𝖾𝗅𝖾𝗍𝗂𝗈𝗇 𝖺𝗇𝖽 𝗎𝗉𝖽𝖺𝗍𝗂𝗇𝗀 𝗈𝖿 𝗄𝖾𝗒𝗌 𝗉𝖾𝗋𝖿𝗈𝗋𝗆𝖺𝗇𝗍𝗅𝗒.

𝖠𝗅𝗌𝗈 𝗂𝗍 𝗈𝗇𝗅𝗒 𝗁𝗈𝗅𝖽𝗌 𝖺 𝗏𝖺𝗅𝗎𝖾 𝗂𝗇 𝗍𝗁𝖾 𝗇𝗈𝖽𝖾𝗌 / 𝖼𝖾𝗅𝗅𝗌 𝖻𝗎𝗍 𝗂𝗇 𝗆𝖺𝗇𝗒 𝖺𝗉𝗉𝗅𝗂𝖼𝖺𝗍𝗂𝗈𝗇𝗌 𝗅𝗂𝗄𝖾 𝗍𝗁𝖺𝗍 𝗈𝖿 𝖣𝗂𝗃𝗄𝗌𝗍𝗋𝖺 𝗐𝗁𝖾𝗋𝖾 𝗁𝖾𝖺𝗉𝗌 𝗋𝖾𝖺𝗅𝗅𝗒 𝗂𝗇𝗍𝖾𝗀𝗋𝖺𝗅 𝗍𝗈 𝗍𝗁𝖾 𝗉𝖾𝗋𝖿𝗈𝗋𝗆𝖺𝗇𝖼𝖾 𝗀𝗎𝖺𝗋𝖺𝗇𝗍𝖾𝖾𝗌 𝗐𝖾 𝗇𝖾𝖾𝖽 𝗍𝗈 𝗌𝗍𝗈𝗋𝖾 𝗄𝖾𝗒 𝗏𝖺𝗅𝗎𝖾 𝗉𝖺𝗂𝗋𝗌 𝖺𝗇𝖽 𝗇𝗈𝗍 𝗃𝗎𝗌𝗍 𝗄𝖾𝗒𝗌. 𝖳𝗁𝖾 𝖪𝖾𝗒 𝗁𝖾𝖺𝗉𝗌 𝗍𝗁𝖺𝗍 𝖽𝗈𝗇'𝗍 𝖺𝗅𝗅𝗈𝗐 𝖿𝗈𝗋 𝖽𝖾𝗅𝖾𝗍𝗂𝗈𝗇 𝖺𝗇𝖽 𝗎𝗉𝖽𝖺𝗍𝗂𝗈𝗇 𝗈𝖿 𝗏𝖺𝗅𝗎𝖾𝗌 𝖿𝗈𝗋 𝗄𝖾𝗒𝗌 𝗌𝗍𝖺𝗋𝗍 𝖻𝖾𝖼𝗈𝗆𝗂𝗇𝗀 𝗋𝖾𝖺𝗅𝗅𝗒 𝗅𝗂𝗆𝗂𝗍𝗂𝗇𝗀 𝗋𝖾𝖺𝗅𝗅𝗒 𝗌𝗈𝗈𝗇.

𝖫𝖾𝗍'𝗌 𝗋𝖾𝗌𝗈𝗅𝗏𝖾 𝗍𝗁𝗂𝗌 𝖻𝗒 𝗐𝗋𝗂𝗍𝗂𝗇𝗀 𝗐𝗁𝖺𝗍 𝖺𝗋𝖾 𝖼𝖺𝗅𝗅𝖾𝖽 𝖨𝗇𝖽𝖾𝗑 𝖧𝖾𝖺𝗉𝗌. 𝖠𝗀𝖺𝗂𝗇 𝗍𝗁𝗂𝗌 𝗂𝗌 𝖺 𝖼𝗈𝖽𝖾 𝗄𝖺𝗍𝗁𝖺 𝗌𝖾𝗋𝗂𝖾𝗌 𝗌𝗈 𝖨'𝗆 𝗀𝗈𝗂𝗇𝗀 𝗍𝗈 𝖺𝗌𝗌𝗎𝗆𝖾 𝖺 𝖻𝖺𝗌𝗂𝖼 𝖿𝖺𝗆𝗂𝗅𝗂𝖺𝗋𝗂𝗍𝗒 𝗐𝗂𝗍𝗁 𝗍𝗁𝖾 𝗂𝖽𝖾𝖺 𝖺𝗇𝖽 𝖿𝗈𝖼𝗎𝗌 𝗈𝗇𝗅𝗒 𝗈𝗇 𝗁𝗈𝗐 𝗍𝗈 𝗐𝗋𝗂𝗍𝖾 𝗈𝗇𝖾 𝗊𝗎𝗂𝖼𝗄𝗅𝗒 𝖺𝗇𝖽 𝖾𝖿𝖿𝗂𝖼𝗂𝖾𝗇𝗍𝗅𝗒 𝗂𝗇 𝖺 𝗐𝖺𝗒 𝗍𝗁𝖺𝗍 𝗂𝗍 𝖻𝖾𝖼𝗈𝗆𝖾𝗌 𝗆𝗎𝗌𝖼𝗅𝖾 𝗆𝖾𝗆𝗈𝗋𝗒 𝖾𝖺𝗌𝗂𝗅𝗒.

𝖳𝗁𝖾 𝗆𝖺𝗂𝗇 𝗂𝖽𝖾𝖺 𝗁𝖾𝗋𝖾 𝗂𝗌 𝖺𝖼𝗍𝗎𝖺𝗅𝗅𝗒 𝗁𝖺𝗌𝗁𝗂𝗇𝗀 𝖺𝗇𝖽 𝗌𝗈 𝗐𝖾 𝗐𝗂𝗅𝗅 𝖾𝗇𝖽 𝗎𝗉 𝗎𝗌𝗂𝗇𝗀 𝖺 𝗁𝖺𝗌𝗁 𝗍𝖺𝖻𝗅𝖾 / 𝖽𝗂𝖼𝗍𝗂𝗈𝗇𝖺𝗋𝗒 𝗍𝗈 𝗈𝗏𝖾𝗋𝖼𝗈𝗆𝖾 𝗍𝗁𝖾 𝗅𝗂𝗆𝗂𝗍𝖺𝗍𝗂𝗈𝗇. 𝖠𝗋𝗋𝖺𝗒𝗌 𝖺𝗋𝖾 𝗀𝗋𝖾𝖺𝗍 𝖻𝗎𝗍 𝗐𝖾 𝖽𝗈𝗇'𝗍 𝗄𝗇𝗈𝗐 𝗐𝗁𝖾𝗋𝖾 𝖺 𝗀𝗂𝗏𝖾𝗇 𝗏𝖺𝗅𝗎𝖾 𝗂𝗌 𝗌𝗂𝗍𝗍𝗂𝗇𝗀 𝗎𝗇𝗅𝖾𝗌𝗌 𝗐𝖾 𝗌𝖼𝖺𝗇 𝗍𝗁𝗋𝗈𝗎𝗀𝗁 𝗍𝗁𝖾 𝗐𝗁𝗈𝗅𝖾 𝖺𝗋𝗋𝖺𝗒 𝗐𝗁𝗂𝖼𝗁 𝗂𝗌 𝗊𝗎𝗂𝗍𝖾 𝗂𝗇𝖾𝖿𝖿𝗂𝖼𝗂𝖾𝗇𝗍.

𝖧𝖺𝗌𝗁𝗂𝗇𝗀 𝖼𝗈𝗆𝖾𝗌 𝗍𝗈 𝗋𝖾𝗌𝖼𝗎𝖾 𝗁𝖾𝗋𝖾 𝖻𝗒 𝗉𝗋𝗈𝗏𝗂𝖽𝗂𝗇𝗀 𝗎𝗌 𝖺 𝗄𝗂𝗇𝖽 𝗈𝖿 𝗀𝗋𝗂𝗉 𝗐𝗁𝖾𝗋𝖾 𝗐𝖾 𝖼𝖺𝗇 𝗍𝖺𝗄𝖾 𝖺 𝗏𝖺𝗅𝗎𝖾 𝖺𝗇𝖽 𝗂𝗇 𝗈𝗇𝖾 𝗌𝗁𝗈𝗍 𝗀𝖾𝗍 𝖺 𝗁𝗈𝗅𝖽 𝗈𝖿 𝗐𝗁𝖾𝗋𝖾 𝗂𝗍 𝗋𝖾𝗌𝗂𝖽𝖾𝗌 𝗂𝗇 𝗆𝖾𝗆𝗈𝗋𝗒. 𝖠𝗇𝖽 𝗐𝖾'𝗅𝗅 𝗉𝗎𝗍 𝗍𝗁𝗂𝗌 𝗂𝖽𝖾𝖺 𝗍𝗈 𝗀𝗈𝗈𝖽 𝗎𝗌𝖾 𝗁𝖾𝗋𝖾 𝗍𝗈𝗈. 𝖲𝗈 𝖿𝗈𝗋 𝖽𝖾𝗅𝖾𝗍𝗂𝗇𝗀 𝖺𝗇𝖽 𝗎𝗉𝖽𝖺𝗍𝗂𝗇𝗀 𝖺 𝗄𝖾𝗒 𝗐𝖾 𝗇𝖾𝖾𝖽 𝖺 𝗢(𝟣) 𝗍𝗂𝗆𝖾 𝗌𝖾𝖺𝗋𝖼𝗁 𝗉𝖾𝗋𝖿𝗈𝗋𝗆𝖺𝗇𝖼𝖾.

𝖠𝗇𝖽 𝗍𝗁𝖾 𝗆𝗈𝗌𝗍 𝗇𝖺𝗍𝗎𝗋𝖺𝗅 𝗐𝖺𝗒 𝗍𝗈 𝖽𝗈 𝗍𝗁𝗂𝗌 𝗂𝗌 𝗍𝗈 𝗌𝗍𝗈𝗋𝖾 𝗍𝗁𝖾𝗆 𝗂𝗇 𝖺 𝖽𝗂𝖼𝗂𝗍𝗈𝗇𝖺𝗋𝗒. 𝖠𝗀𝖺𝗂𝗇 𝖨 𝖽𝗈𝗇'𝗍 𝗐𝖺𝗇𝗍 𝗍𝗈 𝗀𝗈 𝗂𝗇𝗍𝗈 𝗍𝗈𝗈 𝗆𝗎𝖼𝗁 𝗈𝖿 𝗍𝗁𝖾 𝖾𝗑𝗉𝗅𝖺𝗇𝖺𝗍𝗂𝗈𝗇 𝗂𝗇 𝗍𝗁𝖾 𝗄𝖺𝗍𝗁𝖺 𝗌𝖾𝗋𝗂𝖾𝗌. 𝖡𝗎𝗍 𝗍𝗁𝖾 𝗄𝖾𝗒 𝗂𝖽𝖾𝖺 𝗂𝗌 𝗍𝗁𝖺𝗍 𝗐𝖾 𝗁𝖺𝗏𝖾 𝖺𝗇 𝖺𝗋𝗋𝖺𝗒 𝗉𝗊 𝗍𝗁𝖺𝗍 𝗁𝗈𝗅𝖽𝗌 𝗍𝗁𝖾 𝗏𝖺𝗅𝗎𝖾𝗌 𝖻𝗎𝗍 𝗐𝖾 𝖺𝗅𝗌𝗈 𝗐𝖺𝗇𝗍 𝖺 𝗄𝗂𝗇𝖽 𝗈𝖿 𝗂𝗇𝗏𝖾𝗋𝗌𝖾 𝗆𝖺𝗉 𝗅𝗂𝗄𝖾 𝗍𝗁𝖾 𝗈𝗇𝖾 𝖻𝖾𝗅𝗈𝗐:

𝖶𝗁𝖾𝗇 𝖨 𝗍𝖺𝗄𝖾 𝖺 𝗄𝖾𝗒 𝗌𝖺𝗒 𝖺𝗍 𝗽𝗾[ 𝗂 ] 𝖨 𝗐𝖺𝗇𝗍 𝖺 𝖽𝗂𝖼𝗍𝗂𝗈𝗇𝖺𝗋𝗒 𝗈𝗋 𝖺 𝗆𝖺𝗉 𝗍𝗁𝖺𝗍 𝗍𝖾𝗅𝗅𝗌 𝗆𝖾 𝗐𝗁𝖾𝗋𝖾 𝗂𝗍 𝗋𝖾𝗌𝗂𝖽𝖾𝗌 𝗅𝖾𝗍'𝗌 𝖼𝖺𝗅𝗅 𝗍𝗁𝗂𝗌 𝗆𝖺𝗉 𝗊𝗉. 𝖳𝗁𝖾 𝗋𝖾𝗅𝖺𝗍𝗂𝗈𝗇𝗌𝗁𝗂𝗉 𝗐𝖾 𝗇𝖾𝖾𝖽 𝗂𝗌

𝗾𝗽 [𝗄𝖾𝗒] = 𝗂 : 𝗐𝗁𝗂𝖼𝗁 𝗂𝗆𝗉𝗅𝗂𝖾𝗌 => 𝗾𝗽[𝗽𝗾[ 𝗂 ]] = 𝗂

𝖠𝗇𝖽 𝗍𝗁𝗂𝗌 𝗂𝗌 𝖾𝗑𝖺𝖼𝗍𝗅𝗒 𝗍𝗁𝖾 𝗂𝗇𝗏𝖾𝗋𝗌𝖾 𝗈𝖿 𝗉𝗊. 𝖡𝖾𝖼𝖺𝗎𝗌𝖾 𝗊𝗉 𝖼𝗈𝗆𝗉𝗈𝗌𝖾𝖽 𝗐𝗂𝗍𝗁 𝗉𝗊 𝗀𝗂𝗏𝖾𝗌 𝗎𝗌 𝗍𝗁𝖾 𝗂𝖽𝖾𝗇𝗍𝗂𝗍𝗒 𝗆𝖺𝗉 𝗂𝗍 𝗍𝖺𝗄𝖾𝗌 𝗂 𝗍𝗈 𝗂. 𝖠𝗇𝖽 𝗐𝖾'𝗅𝗅 𝖾𝗑𝗉𝗅𝗈𝗂𝗍 𝗍𝗁𝗂𝗌 𝗌𝗂𝗆𝗉𝗅𝖾 𝖿𝖺𝖼𝗍 𝖺𝗀𝖺𝗂𝗇 𝖺𝗇𝖽 𝖺𝗀𝖺𝗂𝗇 𝗂𝗇 𝗂𝗆𝗉𝗅𝖾𝗆𝖾𝗇𝗍𝗂𝗇𝗀 𝖨𝗇𝖽𝖾𝗑 𝖧𝖾𝖺𝗉𝗌.

𝖠𝗅𝗌𝗈 𝗂𝗍'𝗌 𝗐𝗈𝗋𝗍𝗁𝗐𝗁𝗂𝗅𝖾 𝗇𝗈𝗍𝗂𝗇𝗀 𝗍𝗁𝖺𝗍 𝗐𝖾 𝖼𝖺𝗇 𝗋𝖾𝗎𝗌𝖾 𝗆𝗈𝗌𝗍 𝗈𝖿 𝗍𝗁𝖾 𝖼𝗈𝖽𝖾 𝖿𝗈𝗋 𝗋𝖾𝗀𝗎𝗅𝖺𝗋 𝖧𝖾𝖺𝗉𝗌. 𝖳𝗁𝖾𝗋𝖾 𝖺𝗋𝖾 𝗈𝗇𝗅𝗒 𝖺 𝖿𝖾𝗐 𝗉𝗅𝖺𝖼𝖾𝗌 𝗐𝗁𝖾𝗋𝖾 𝗂𝗇𝖽𝗂𝖼𝖾𝗌 𝗀𝖾𝗍 𝗎𝗉𝖽𝖺𝗍𝖾𝖽 𝖺𝗇𝖽 𝗇𝖾𝖾𝖽 𝗍𝗈 𝖻𝖾 𝗆𝖺𝗇𝖺𝗀𝖾𝖽 𝗉𝗋𝗈𝗉𝖾𝗋𝗅𝗒. 𝖬𝗈𝗌𝗍 𝗈𝗍𝗁𝖾𝗋 𝗆𝖾𝗍𝗁𝗈𝖽𝗌 𝗋𝖾𝗆𝖺𝗂𝗇 𝗎𝗇𝖼𝗁𝖺𝗇𝗀𝖾𝖽.

𝖠𝗌 𝗒𝗈𝗎 𝖼𝖺𝗇 𝗌𝖾𝖾 𝗌𝗐𝖺𝗉 𝖼𝗁𝖺𝗇𝗀𝖾𝗌 𝗍𝗈 𝗆𝖺𝗄𝖾 𝗌𝗎𝗋𝖾 𝗐𝖾 𝗆𝖺𝗂𝗇𝗍𝖺𝗂𝗇 𝗍𝗁𝖾 𝗂𝗇𝗏𝖺𝗋𝗂𝖺𝗇𝗍 𝗾𝗽[𝗽𝗾[ 𝗂 ]] = 𝗂 𝖺𝗇𝖽 𝗍𝗁𝖾 𝗋𝖾𝗌𝗍 𝗂𝗌 𝗎𝗇𝖼𝗁𝖺𝗇𝗀𝖾𝖽. 𝖲𝗂𝗆𝗂𝗅𝖺𝗋𝗅𝗒 𝗆𝗈𝗌𝗍 𝗈𝗍𝗁𝖾𝗋 𝗆𝖾𝗍𝗁𝗈𝖽𝗌 𝗋𝖾𝗆𝖺𝗂𝗇 𝗎𝗇𝖼𝗁𝖺𝗇𝗀𝖾𝖽.