الگورتھمک پیچیدگی

ہائے! آج کا سبق باقیوں سے قدرے مختلف ہوگا۔ اس میں فرق ہوگا کہ یہ صرف بالواسطہ طور پر جاوا سے متعلق ہے۔ اس نے کہا، یہ موضوع ہر پروگرامر کے لیے بہت اہم ہے۔ ہم الگورتھم کے بارے میں بات کرنے جا رہے ہیں ۔ الگورتھم کیا ہے؟ سادہ الفاظ میں، یہ اعمال کا کچھ سلسلہ ہے جو مطلوبہ نتیجہ حاصل کرنے کے لیے مکمل ہونا ضروری ہے ۔ ہم روزمرہ کی زندگی میں اکثر الگورتھم استعمال کرتے ہیں۔ مثال کے طور پر، ہر صبح آپ کا ایک مخصوص کام ہوتا ہے: اسکول یا کام پر، اور ساتھ ہی یہ بھی ہو:

• کپڑا
• صاف
• کھلایا

کون سا الگورتھم آپ کو یہ نتیجہ حاصل کرنے دیتا ہے؟

1. الارم گھڑی کا استعمال کرتے ہوئے اٹھیں۔
2. شاور لیں اور اپنے آپ کو دھو لیں۔
3. ناشتہ اور کافی یا چائے بنائیں۔
4. کھاؤ۔
5. اگر آپ نے پچھلی شام اپنے کپڑے استری نہیں کیے تو انہیں استری کریں۔
6. تیار ہو جاؤ.
7. مکان چھوڑ دو.

اعمال کا یہ سلسلہ یقینی طور پر آپ کو مطلوبہ نتیجہ حاصل کرنے دے گا۔ پروگرامنگ میں، ہم کاموں کو مکمل کرنے کے لیے مسلسل کام کر رہے ہیں۔ ان کاموں کا ایک اہم حصہ الگورتھم کا استعمال کرتے ہوئے انجام دیا جا سکتا ہے جو پہلے سے معلوم ہیں۔ مثال کے طور پر، فرض کریں کہ آپ کا کام یہ ہے: ایک صف میں 100 ناموں کی فہرست ترتیب دیں ۔ یہ کام کافی آسان ہے، لیکن اسے مختلف طریقوں سے حل کیا جا سکتا ہے۔ یہاں ایک ممکنہ حل ہے: ناموں کو حروف تہجی کے مطابق ترتیب دینے کے لیے الگورتھم:

1. ویبسٹر کی تیسری نئی بین الاقوامی لغت کا 1961 ایڈیشن خریدیں یا ڈاؤن لوڈ کریں۔
2. اس لغت میں ہماری فہرست سے ہر نام تلاش کریں۔
3. کاغذ کے ٹکڑے پر لغت کا صفحہ لکھیں جس پر نام موجود ہے۔
4. ناموں کو ترتیب دینے کے لیے کاغذ کے ٹکڑوں کا استعمال کریں۔

کیا اس طرح کے عمل سے ہمارا کام پورا ہو جائے گا؟ ہاں، یہ ضرور ہوگا۔ کیا یہ حل کارآمد ہے ؟ مشکل سے۔ یہاں ہم الگورتھم کے ایک اور بہت اہم پہلو کی طرف آتے ہیں: ان کی کارکردگی ۔ اس کام کو پورا کرنے کے کئی طریقے ہیں۔ لیکن پروگرامنگ اور عام زندگی دونوں میں، ہم سب سے زیادہ موثر طریقہ کا انتخاب کرنا چاہتے ہیں۔ اگر آپ کا کام ٹوسٹ کا مکھن والا ٹکڑا بنانا ہے، تو آپ گندم کی بوائی اور گائے کو دودھ دینے سے شروع کر سکتے ہیں۔ لیکن یہ ایک غیر موثر حل ہوگا - اس میں بہت وقت لگے گا اور بہت زیادہ رقم خرچ ہوگی۔ آپ صرف روٹی اور مکھن خرید کر اپنا آسان کام پورا کر سکتے ہیں۔ اگرچہ یہ آپ کو مسئلہ حل کرنے دیتا ہے، لیکن گندم اور گائے پر مشتمل الگورتھم عملی طور پر استعمال کرنے کے لیے بہت پیچیدہ ہے۔ پروگرامنگ میں، ہمارے پاس الگورتھم کی پیچیدگی کا اندازہ لگانے کے لیے خصوصی نوٹیشن ہے جسے بگ O نوٹیشن کہتے ہیں۔ Big O یہ اندازہ لگانا ممکن بناتا ہے کہ ان پٹ ڈیٹا کے سائز پر الگورتھم کے عمل درآمد کا وقت کتنا منحصر ہے ۔ آئیے سب سے آسان مثال دیکھیں: ڈیٹا ٹرانسفر۔ تصور کریں کہ آپ کو کچھ معلومات فائل کی شکل میں طویل فاصلے پر بھیجنے کی ضرورت ہے (مثال کے طور پر، 5000 میل)۔ کون سا الگورتھم سب سے زیادہ موثر ہوگا؟ یہ اس ڈیٹا پر منحصر ہے جس کے ساتھ آپ کام کر رہے ہیں۔ مثال کے طور پر، فرض کریں کہ ہمارے پاس ایک آڈیو فائل ہے جو 10 ایم بی ہے۔ اس معاملے میں، سب سے موثر الگورتھم فائل کو انٹرنیٹ پر بھیجنا ہے۔ اس میں چند منٹ سے زیادہ نہیں لگ سکتا تھا! آئیے اپنے الگورتھم کو دوبارہ بیان کریں: "اگر آپ 5000 میل کے فاصلے پر فائلوں کی شکل میں معلومات منتقل کرنا چاہتے ہیں، تو آپ کو انٹرنیٹ کے ذریعے ڈیٹا بھیجنا چاہیے"۔ بہترین اب اس کا تجزیہ کرتے ہیں۔ کیا یہ ہمارے کام کو پورا کرتا ہے؟ ٹھیک ہے، ہاں، ایسا ہوتا ہے۔ لیکن ہم اس کی پیچیدگی کے بارے میں کیا کہہ سکتے ہیں؟ ہمم، اب چیزیں مزید دلچسپ ہوتی جا رہی ہیں۔ حقیقت یہ ہے کہ ہمارا الگورتھم ان پٹ ڈیٹا، یعنی فائلوں کے سائز پر بہت زیادہ منحصر ہے۔ اگر ہمارے پاس 10 میگا بائٹس ہیں، تو سب کچھ ٹھیک ہے۔ لیکن اگر ہمیں 500 میگا بائٹس بھیجنے کی ضرورت ہو تو کیا ہوگا؟ 20 گیگا بائٹس؟ 500 ٹیرا بائٹس؟ 30 پیٹا بائٹس؟ کیا ہمارا الگورتھم کام کرنا چھوڑ دے گا؟ نہیں، ڈیٹا کی ان تمام مقداروں کو واقعی منتقل کیا جا سکتا ہے۔ کیا اس میں زیادہ وقت لگے گا؟ ہاں یہ ہو گا! اب ہم اپنے الگورتھم کی ایک اہم خصوصیت جانتے ہیں: بھیجنے کے لیے ڈیٹا کی مقدار جتنی زیادہ ہوگی، الگورتھم کو چلانے میں اتنا ہی زیادہ وقت لگے گا ۔ لیکن ہم اس تعلق کے بارے میں زیادہ درست سمجھنا چاہیں گے (ان پٹ ڈیٹا کے سائز اور اسے بھیجنے کے لیے درکار وقت کے درمیان)۔ ہمارے معاملے میں، الگورتھمک پیچیدگی لکیری ہے۔. "لینیئر" کا مطلب ہے کہ جیسے جیسے ان پٹ ڈیٹا کی مقدار بڑھے گی، اسے بھیجنے میں لگنے والے وقت میں تقریباً متناسب اضافہ ہوگا۔ اگر ڈیٹا کی مقدار دوگنی ہوجاتی ہے، تو اسے بھیجنے کے لیے درکار وقت دوگنا ہوگا۔ اگر ڈیٹا 10 گنا بڑھتا ہے، تو ٹرانسمیشن کا وقت 10 گنا بڑھ جائے گا۔ بڑے O اشارے کا استعمال کرتے ہوئے، ہمارے الگورتھم کی پیچیدگی کو O(n) کے طور پر ظاہر کیا جاتا ہے ۔ آپ کو یہ اشارے مستقبل کے لیے یاد رکھنا چاہیے — یہ ہمیشہ لکیری پیچیدگی والے الگورتھم کے لیے استعمال ہوتا ہے۔ نوٹ کریں کہ ہم یہاں مختلف چیزوں کے بارے میں بات نہیں کر رہے ہیں: انٹرنیٹ کی رفتار، ہمارے کمپیوٹر کی کمپیوٹیشنل پاور، وغیرہ۔ الگورتھم کی پیچیدگی کا اندازہ لگاتے وقت، ان عوامل پر غور کرنا کوئی معنی نہیں رکھتا — کسی بھی صورت میں، یہ ہمارے کنٹرول سے باہر ہیں۔ بگ O اشارے خود الگورتھم کی پیچیدگی کا اظہار کرتا ہے، نہ کہ "ماحول" جس میں یہ چلتا ہے۔ آئیے اپنی مثال کو جاری رکھیں۔ فرض کریں کہ ہم بالآخر سیکھ گئے کہ ہمیں کل 800 ٹیرا بائٹس فائلیں بھیجنے کی ضرورت ہے۔ ہم یقیناً انہیں انٹرنیٹ پر بھیج کر اپنا کام پورا کر سکتے ہیں۔ صرف ایک مسئلہ ہے: معیاری گھریلو ڈیٹا ٹرانسمیشن کی شرح (100 میگا بٹس فی سیکنڈ) پر، اس میں تقریباً 708 دن لگیں گے۔ تقریباً 2 سال! :O ہمارا الگورتھم واضح طور پر یہاں مناسب نہیں ہے۔ ہمیں کسی اور حل کی ضرورت ہے! غیر متوقع طور پر، آئی ٹی دیو ایمیزون ہمارے بچاؤ کے لیے آتا ہے! ایمیزون کی سنو موبائل سروس ہمیں موبائل اسٹوریج پر ڈیٹا کی ایک بڑی مقدار اپ لوڈ کرنے اور پھر اسے ٹرک کے ذریعے مطلوبہ پتے پر پہنچانے دیتی ہے! تو، ہمارے پاس ایک نیا الگورتھم ہے! "اگر آپ 5000 میل کے فاصلے پر فائلوں کی شکل میں معلومات کو منتقل کرنا چاہتے ہیں اور ایسا کرنے سے انٹرنیٹ کے ذریعے بھیجنے میں 14 دن سے زیادہ وقت لگے گا، تو آپ کو ایمیزون ٹرک پر ڈیٹا بھیجنا چاہیے۔" ہم نے یہاں من مانی طور پر 14 دن کا انتخاب کیا۔ ہم کہتے ہیں کہ یہ سب سے طویل مدت ہے جس کا ہم انتظار کر سکتے ہیں۔ آئیے اپنے الگورتھم کا تجزیہ کریں۔ اس کی رفتار کے بارے میں کیا خیال ہے؟ اگر ٹرک صرف 50 میل فی گھنٹہ کی رفتار سے سفر کرے تو بھی یہ 5000 میل کا فاصلہ صرف 100 گھنٹے میں طے کر لے گا۔ یہ چار دن سے تھوڑا زیادہ ہے! یہ انٹرنیٹ پر ڈیٹا بھیجنے کے آپشن سے کہیں بہتر ہے۔ اور اس الگورتھم کی پیچیدگی کے بارے میں کیا خیال ہے؟ کیا یہ لکیری بھی ہے، یعنی O(n)؟ کوئی یہ نہیں ہے. سب کے بعد، ٹرک کو اس بات کی کوئی پرواہ نہیں ہے کہ آپ اسے کتنے بھاری بھرکم لوڈ کرتے ہیں - یہ اب بھی تقریباً اسی رفتار سے چلائے گا اور وقت پر پہنچے گا۔ چاہے ہمارے پاس 800 ٹیرا بائٹس ہو، یا اس سے 10 گنا، ٹرک پھر بھی 5 دن کے اندر اپنی منزل تک پہنچ جائے گا۔ دوسرے الفاظ میں، ٹرک پر مبنی ڈیٹا ٹرانسفر الگورتھم میں مستقل پیچیدگی ہوتی ہے ۔ یہاں، "مستقل" کا مطلب ہے کہ یہ ان پٹ ڈیٹا کے سائز پر منحصر نہیں ہے۔ ٹرک میں 1GB فلیش ڈرائیو لگائیں، یہ 5 دنوں میں پہنچ جائے گی۔ 800 ٹیرا بائٹس ڈیٹا پر مشتمل ڈسک میں ڈالیں، یہ 5 دن میں پہنچ جائے گا۔ بڑی O اشارے استعمال کرتے وقت، مستقل پیچیدگی کو O(1) سے ظاہر کیا جاتا ہے ۔اور O(1) ، تو آئیے اب پروگرامنگ کی دنیا میں مزید مثالیں دیکھتے ہیں :) فرض کریں کہ آپ کو 100 نمبروں کی ایک صف دی گئی ہے، اور کام یہ ہے کہ ان میں سے ہر ایک کو کنسول پر ڈسپلے کریں۔ آپ ایک عام forلوپ لکھتے ہیں جو اس کام کو انجام دیتا ہے۔

int[] numbers = new int[100];
// ...fill the array with numbers

for (int i: numbers) {
   System.out.println(i);
}

اس الگورتھم کی پیچیدگی کیا ہے؟ لکیری، یعنی O(n)۔ پروگرام کو انجام دینے والے اعمال کی تعداد کا انحصار اس بات پر ہے کہ اس کو کتنے نمبر بھیجے گئے ہیں۔ اگر صف میں 100 نمبر ہیں، تو 100 ایکشن ہوں گے (اسکرین پر سٹرنگز دکھانے کے لیے بیانات)۔ اگر صف میں 10,000 نمبر ہیں، تو پھر 10,000 اعمال انجام دینے چاہئیں۔ کیا ہمارے الگورتھم کو کسی بھی طرح بہتر بنایا جا سکتا ہے؟ نہیں، کوئی بات نہیں، ہمیں N کو سرنی سے گزرنا ہو گا اور کنسول پر سٹرنگز ڈسپلے کرنے کے لیے N سٹیٹمنٹس پر عمل درآمد کرنا ہو گا۔ ایک اور مثال پر غور کریں۔

public static void main(String[] args) {

   LinkedList<Integer> numbers = new LinkedList<>();
   numbers.add(0, 20202);
   numbers.add(0, 123);
   numbers.add(0, 8283);
}

ہمارے پاس ایک خالی ہے LinkedListجس میں ہم کئی نمبر ڈالتے ہیں۔ ہمیں اپنی مثال میں ایک نمبر کو داخل کرنے کی الگورتھمک پیچیدگی کا جائزہ لینے کی ضرورت ہے LinkedList، اور یہ فہرست میں عناصر کی تعداد پر کیسے منحصر ہے۔ جواب ہے O(1) یعنی مستقل پیچیدگی ۔ کیوں؟ نوٹ کریں کہ ہم فہرست کے شروع میں ہر نمبر داخل کرتے ہیں۔ اس کے علاوہ، آپ کو یاد ہوگا کہ جب آپ ایک نمبر کو a میں داخل کرتے ہیں LinkedList، تو عناصر کہیں بھی منتقل نہیں ہوتے ہیں۔ لنکس (یا حوالہ جات) کو اپ ڈیٹ کر دیا جاتا ہے (اگر آپ بھول گئے ہیں کہ LinkedList کیسے کام کرتی ہے، تو ہمارے پرانے اسباق میں سے ایک کو دیکھیں )۔ اگر ہماری فہرست میں پہلا نمبر ہے x، اور ہم فہرست کے آگے نمبر y ڈالتے ہیں، تو ہمیں بس اتنا کرنے کی ضرورت ہے:

x.previous  = y;
y.previous = null;
y.next = x;

جب ہم لنکس کو اپ ڈیٹ کرتے ہیں، تو ہمیں اس بات کی پرواہ نہیں ہوتی کہ پہلے سے ہی کتنے نمبر ہیںLinkedList ، چاہے ایک یا ایک ارب۔ الگورتھم کی پیچیدگی مستقل ہے، یعنی O(1)۔

لوگاریتھمک پیچیدگی

گھبرائیں نہیں! :) اگر لفظ "لوگارتھمک" آپ کو اس سبق کو بند کرنا اور پڑھنا بند کرنا چاہتا ہے، تو صرف چند منٹ کے لیے ٹھہریں۔ یہاں کوئی پاگل ریاضی نہیں ہوگی (اس طرح کی بہت ساری وضاحتیں کہیں اور ہیں)، اور ہم ہر ایک مثال کو الگ کریں گے۔ تصور کریں کہ آپ کا کام 100 نمبروں کی صف میں ایک مخصوص نمبر تلاش کرنا ہے۔ مزید واضح طور پر، آپ کو یہ چیک کرنے کی ضرورت ہے کہ آیا یہ وہاں ہے یا نہیں۔ جیسے ہی مطلوبہ نمبر مل جاتا ہے، تلاش ختم ہو جاتی ہے، اور آپ کنسول میں درج ذیل کو ظاہر کرتے ہیں: "مطلوبہ نمبر مل گیا! اس کا اشاریہ صف میں = ....." آپ اس کام کو کیسے پورا کریں گے؟ یہاں حل واضح ہے: آپ کو پہلے (یا آخری سے) سے شروع کرتے ہوئے ایک ایک کرکے صف کے عناصر پر اعادہ کرنے کی ضرورت ہے اور چیک کریں کہ آیا موجودہ نمبر اس سے ملتا ہے جس کی آپ تلاش کر رہے ہیں۔ اس کے مطابق، اعمال کی تعداد براہ راست صف میں عناصر کی تعداد پر منحصر ہے. اگر ہمارے پاس 100 نمبر ہیں، تو ہمیں ممکنہ طور پر اگلے عنصر پر 100 بار جانے اور 100 موازنہ کرنے کی ضرورت پڑ سکتی ہے۔ اگر 1000 نمبر ہیں تو پھر 1000 موازنہ ہو سکتے ہیں۔ یہ واضح طور پر لکیری پیچیدگی ہے، یعنی O(n) ۔ اور اب ہم اپنی مثال میں ایک اصلاح شامل کریں گے: جس صف میں آپ کو نمبر تلاش کرنے کی ضرورت ہے اسے صعودی ترتیب میں ترتیب دیا گیا ہے ۔ کیا اس سے ہمارے کام میں کوئی تبدیلی آتی ہے؟ ہم اب بھی مطلوبہ نمبر کے لیے ایک بریوٹ فورس سرچ کر سکتے ہیں۔ لیکن متبادل طور پر، ہم معروف بائنری سرچ الگورتھم استعمال کر سکتے ہیں ۔ تصویر میں اوپر کی قطار میں، ہم ایک ترتیب شدہ صف دیکھتے ہیں۔ ہمیں اس میں نمبر 23 تلاش کرنے کی ضرورت ہے۔ نمبروں پر تکرار کرنے کے بجائے، ہم صرف ارے کو 2 حصوں میں تقسیم کرتے ہیں اور صف میں درمیانی نمبر کو چیک کرتے ہیں۔ سیل 4 میں موجود نمبر تلاش کریں اور اسے چیک کریں (تصویر میں دوسری قطار)۔ یہ نمبر 16 ہے، اور ہم 23 کی تلاش کر رہے ہیں۔ موجودہ تعداد اس سے کم ہے جس کی ہم تلاش کر رہے ہیں۔ اس کا کیا مطلب ہے؟ اس کا مطلب ہے کہ تمام پچھلے نمبرز (جو نمبر 16 سے پہلے واقع ہیں) کو چیک کرنے کی ضرورت نہیں ہے : وہ اس سے کم ہونے کی ضمانت دی جاتی ہے جس کی ہم تلاش کر رہے ہیں، کیونکہ ہماری صف ترتیب دی گئی ہے! ہم باقی 5 عناصر کے درمیان تلاش جاری رکھتے ہیں۔ نوٹ:ہم نے صرف ایک موازنہ کیا ہے، لیکن ہم نے ممکنہ اختیارات میں سے نصف کو پہلے ہی ختم کر دیا ہے۔ ہمارے پاس صرف 5 عناصر باقی ہیں۔ ہم اپنے پچھلے مرحلے کو ایک بار پھر دہرائیں گے بقیہ ذیلی ارے کو نصف میں تقسیم کرکے اور دوبارہ درمیانی عنصر (تصویر میں تیسری قطار) کو لے کر۔ نمبر 56 ہے، اور یہ اس سے بڑا ہے جس کی ہم تلاش کر رہے ہیں۔ اس کا کیا مطلب ہے؟ اس کا مطلب ہے کہ ہم نے مزید 3 امکانات کو ختم کر دیا ہے: خود نمبر 56 اور اس کے بعد کے دو نمبر (چونکہ ان کے 23 سے زیادہ ہونے کی ضمانت ہے، کیونکہ صف ترتیب دی گئی ہے)۔ ہمارے پاس چیک کرنے کے لیے صرف 2 نمبر باقی ہیں (تصویر میں آخری قطار) — صف کے اشاریے 5 اور 6 والے نمبر۔ ہم ان میں سے پہلے کو چیک کرتے ہیں، اور وہ ڈھونڈتے ہیں جو ہم ڈھونڈ رہے تھے — نمبر 23! اس کا انڈیکس 5 ہے! آئیے اپنے الگورتھم کے نتائج کو دیکھتے ہیں، اور پھر ہم اس کی پیچیدگی کا تجزیہ کریں گے۔ ویسے، اب آپ سمجھ گئے ہیں کہ اسے بائنری سرچ کیوں کہا جاتا ہے: یہ ڈیٹا کو بار بار نصف میں تقسیم کرنے پر انحصار کرتا ہے۔ نتیجہ متاثر کن ہے! اگر ہم نمبر تلاش کرنے کے لیے ایک لکیری تلاش کا استعمال کرتے ہیں، تو ہمیں 10 تک موازنہ کی ضرورت ہوگی، لیکن بائنری تلاش کے ساتھ، ہم نے صرف 3 کے ساتھ کام پورا کیا! بدترین صورت میں، 4 موازنہ ہوں گے (اگر آخری مرحلے میں جو نمبر ہم چاہتے تھے وہ پہلے کے بجائے باقی امکانات میں سے دوسرا تھا۔ تو اس کی پیچیدگی کا کیا ہوگا؟ یہ ایک بہت ہی دلچسپ نکتہ ہے :) بائنری تلاش الگورتھم لکیری سرچ الگورتھم (یعنی سادہ تکرار) کے مقابلے صف میں موجود عناصر کی تعداد پر بہت کم انحصار کرتا ہے۔ صف میں 10 عناصر کے ساتھ ، ایک لکیری تلاش کو زیادہ سے زیادہ 10 موازنہوں کی ضرورت ہوگی، لیکن بائنری تلاش کے لیے زیادہ سے زیادہ 4 موازنہوں کی ضرورت ہوگی۔ یہ 2.5 کے فیکٹر سے فرق ہے۔ لیکن 1000 عناصر کی ایک صف کے لیے ، ایک لکیری تلاش کو 1000 تک موازنہ کی ضرورت ہوگی، لیکن بائنری تلاش کے لیے صرف 10 کی ضرورت ہوگی ! فرق اب 100 گنا ہے! نوٹ:صف میں عناصر کی تعداد میں 100 گنا اضافہ ہوا ہے (10 سے 1000 تک)، لیکن بائنری تلاش کے لیے درکار تقابل کی تعداد میں صرف 2.5 (4 سے 10 تک) کے عنصر کا اضافہ ہوا ہے۔ اگر ہم 10,000 عناصر تک پہنچ جائیں تو فرق اور بھی زیادہ متاثر کن ہوگا: لکیری تلاش کے لیے 10,000 موازنہ، اور بائنری تلاش کے لیے کل 14 موازنہ ۔ اور پھر، اگر عناصر کی تعداد میں 1000 گنا اضافہ ہوتا ہے (10 سے 10000 تک)، تو موازنہ کی تعداد صرف 3.5 (4 سے 14 تک) کے عنصر سے بڑھ جاتی ہے۔ بائنری سرچ الگورتھم کی پیچیدگی لوگاریتھمک ہے ، یا، اگر ہم بڑی O اشارے، O(log n) استعمال کرتے ہیں ۔ اسے ایسا کیوں کہا جاتا ہے؟ لوگارتھم ایکسپوینشن کے مخالف کی طرح ہے۔ بائنری لوگارتھم وہ طاقت ہے جس میں نمبر حاصل کرنے کے لیے نمبر 2 کو بڑھانا ضروری ہے۔ مثال کے طور پر، ہمارے پاس 10,000 عناصر ہیں جو ہمیں بائنری سرچ الگورتھم کا استعمال کرتے ہوئے تلاش کرنے کی ضرورت ہے۔ فی الحال، آپ یہ جاننے کے لیے اقدار کے جدول کو دیکھ سکتے ہیں کہ ایسا کرنے کے لیے زیادہ سے زیادہ 14 موازنہ کی ضرورت ہوگی۔ لیکن کیا ہوگا اگر کسی نے بھی ایسا ٹیبل فراہم نہ کیا ہو اور آپ کو زیادہ سے زیادہ موازنہ کی صحیح تعداد کا حساب لگانے کی ضرورت ہو؟ آپ کو صرف ایک سادہ سوال کا جواب دینا ہوگا: آپ کو نمبر 2 کو کس طاقت تک بڑھانے کی ضرورت ہے تاکہ نتیجہ جانچنے والے عناصر کی تعداد سے زیادہ یا اس کے برابر ہو؟ 10,000 کے لیے، یہ 14ویں طاقت ہے۔ 2 سے 13ویں طاقت بہت چھوٹی ہے (8192)، لیکن 2 سے 14ویں طاقت = 16384 ، اور یہ نمبر ہماری حالت کو پورا کرتا ہے (یہ صف میں موجود عناصر کی تعداد سے بڑا یا اس کے برابر ہے)۔ ہمیں لوگارتھم ملا: 14۔ ہمیں کتنے موازنہ کی ضرورت ہو سکتی ہے! :) الگورتھم اور الگورتھم کی پیچیدگی ایک سبق میں فٹ ہونے کے لیے بہت وسیع موضوع ہے۔ لیکن یہ جاننا بہت ضروری ہے: بہت سے ملازمت کے انٹرویوز میں الگورتھم سے متعلق سوالات شامل ہوں گے۔ تھیوری کے لیے، میں آپ کے لیے کچھ کتابیں تجویز کر سکتا ہوں۔ آپ " گروکنگ الگورتھم " کے ساتھ شروع کر سکتے ہیں۔ اس کتاب میں مثالیں ازگر میں لکھی گئی ہیں لیکن کتاب میں بہت سادہ زبان اور مثالیں استعمال کی گئی ہیں۔ یہ ایک ابتدائی کے لیے بہترین آپشن ہے اور مزید یہ کہ یہ بہت بڑا نہیں ہے۔ زیادہ سنجیدہ پڑھنے میں، ہمارے پاس رابرٹ لافور اور رابرٹ سیڈجوک کی کتابیں ہیں ۔ دونوں جاوا میں لکھے گئے ہیں، جس سے آپ کے لیے سیکھنا قدرے آسان ہو جائے گا۔ سب کے بعد، آپ اس زبان سے کافی واقف ہیں! :) ریاضی کی اچھی مہارت رکھنے والے طلباء کے لیے، بہترین آپشن تھامس کورمین کی کتاب ہے ۔ لیکن صرف نظریہ آپ کا پیٹ نہیں بھرے گا! علم != قابلیت ۔ آپ HackerRank اور LeetCode پر الگورتھم کے مسائل کو حل کرنے کی مشق کر سکتے ہیں۔ . ان ویب سائٹس کے ٹاسکس اکثر گوگل اور فیس بک پر انٹرویوز کے دوران بھی استعمال کیے جاتے ہیں، اس لیے آپ یقیناً بور نہیں ہوں گے :) اس سبق کے مواد کو تقویت دینے کے لیے، میں تجویز کرتا ہوں کہ آپ YouTube پر بڑے O نوٹیشن کے بارے میں یہ بہترین ویڈیو دیکھیں۔ اگلے اسباق میں ملتے ہیں! :)