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

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

• ملبوس
• صاف
• اچھی طرح کھلایا

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

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

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

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

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

int[] numbers = new int[100];
// ..заполняем массив числами

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) - مستقل پیچیدگی ۔ کیوں؟ براہ کرم نوٹ کریں: جب بھی ہم فہرست کے شروع میں نمبر داخل کرتے ہیں۔ اس کے علاوہ، جیسا کہ آپ کو یاد ہے، عناصر میں نمبر ڈالتے وقت ، وہ کہیں بھی منتقل نہیں ہوتے ہیں - لنکس کی نئی تعریف کی جاتی ہے (اگر آپ اچانک بھول گئے کہ LinkedList کیسے کام کرتا ہے، تو ہمارے پرانے لیکچرزLinkedList میں سے ایک پر ایک نظر ڈالیں )۔ اگر اب ہماری فہرست میں پہلا نمبر نمبر ہے ، اور ہم فہرست کے شروع میں نمبر 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 عناصر باقی ہیں۔ ہم اپنے قدم کو دہرائیں گے - دوبارہ بقیہ صف کو 2 سے تقسیم کریں اور دوبارہ درمیانی عنصر لیں (شکل میں لائن 3)۔ یہ تعداد 56 ہے، اور یہ اس سے بڑا ہے جس کی ہم تلاش کر رہے ہیں۔ اس کا کیا مطلب ہے؟ کہ ہم مزید 3 آپشنز کو مسترد کرتے ہیں - نمبر 56 خود، اور اس کے بعد دو نمبر (وہ یقینی طور پر 23 سے زیادہ ہیں، کیونکہ صف ترتیب دی گئی ہے)۔ ہمارے پاس چیک کرنے کے لیے صرف 2 نمبر باقی ہیں (اعداد و شمار کی آخری قطار) - صفوں کے اشاریے 5 اور 6 کے ساتھ نمبر۔ ہم ان میں سے پہلی کو چیک کرتے ہیں، اور یہ وہی ہے جس کی ہم تلاش کر رہے تھے - نمبر 23! اس کا اشاریہ = 5! آئیے اپنے الگورتھم کے نتائج کو دیکھتے ہیں، اور پھر ہم اس کی پیچیدگی کو سمجھیں گے۔ (ویسے، اب آپ سمجھ گئے ہیں کہ اسے بائنری کیوں کہا جاتا ہے: اس کا جوہر ڈیٹا کو مسلسل 2 سے تقسیم کرنا ہے)۔ نتیجہ متاثر کن ہے! اگر ہم لکیری تلاش کا استعمال کرتے ہوئے مطلوبہ نمبر تلاش کر رہے تھے، تو ہمیں 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(log n) ۔ اسے ایسا کیوں کہا جاتا ہے؟ ایک لوگارتھم ایکسپوینشن کا الٹا ہے۔ بائنری لوگارتھم کا استعمال 2 کی طاقت کا حساب لگانے کے لیے کیا جاتا ہے۔ مثال کے طور پر، ہمارے پاس 10,000 عناصر ہیں جن سے ہمیں بائنری سرچ استعمال کرنے کی ضرورت ہے۔ اب آپ کی آنکھوں کے سامنے ایک تصویر ہے، اور آپ جانتے ہیں کہ اس کے لیے زیادہ سے زیادہ 14 چیک کی ضرورت ہے۔ لیکن اگر آپ کی آنکھوں کے سامنے کوئی تصویر نہیں ہے، اور آپ کو ضروری چیک کی صحیح تعداد کو شمار کرنے کی ضرورت ہے؟ ایک سادہ سوال کا جواب دینے کے لیے یہ کافی ہے: نمبر 2 کو کس طاقت تک بڑھایا جائے تاکہ حاصل ہونے والا نتیجہ >= عناصر کی تعداد کی جانچ ہو؟ 10000 کے لیے یہ 14ویں طاقت ہوگی۔ 2 سے 13 ویں طاقت بہت چھوٹی ہے (8192) لیکن 2 سے 14 ویں طاقت = 16384 ، یہ نمبر ہماری حالت کو پورا کرتا ہے (یہ >= صف میں عناصر کی تعداد ہے)۔ ہمیں لوگارتھم ملا - 14۔ ہمیں کتنے چیک کی ضرورت ہے! :) الگورتھم اور ان کی پیچیدگی ایک ایسا موضوع ہے جس کو ایک لیکچر میں شامل نہیں کیا جاسکتا۔ لیکن یہ جاننا بہت ضروری ہے: بہت سے انٹرویوز میں آپ کو الگورتھمک مسائل ملیں گے۔ نظریہ کے لیے، میں آپ کو کئی کتابیں تجویز کر سکتا ہوں۔ شروع کرنے کے لیے ایک اچھی جگہ ہے " Grocking Algorithms ": اگرچہ کتاب میں مثالیں Python میں لکھی گئی ہیں، لیکن کتاب کی زبان اور مثالیں بہت آسان ہیں۔ ایک ابتدائی کے لیے بہترین آپشن، اور یہ حجم میں بھی چھوٹا ہے۔ مزید سنجیدہ پڑھنا: رابرٹ لافورٹ اور رابرٹ سیڈگوک کی کتابیں ۔ دونوں جاوا میں لکھے گئے ہیں، جس سے آپ کے لیے سیکھنا قدرے آسان ہو جائے گا۔ سب کے بعد، آپ اس زبان سے کافی واقف ہیں! :) اچھے ریاضیاتی پس منظر والے طلباء کے لیے، بہترین آپشن تھامس کورمین کی کتاب ہوگی ۔ لیکن آپ صرف نظریہ سے مطمئن نہیں ہوں گے! "جانیں" != "قابل ہو" آپ ہیکر رینک اور لیٹ کوڈ پر الگورتھم کے مسائل حل کرنے کی مشق کر سکتے ہیں ۔ وہاں کے مسائل اکثر گوگل اور فیس بک پر انٹرویوز کے دوران بھی استعمال ہوتے ہیں، اس لیے آپ یقیناً بور نہیں ہوں گے :) لیکچر کے مواد کو مزید تقویت دینے کے لیے، میں آپ کو یوٹیوب پر Big-O کے بارے میں ایک بہترین ویڈیو دیکھنے کا مشورہ دیتا ہوں ۔ اگلے لیکچرز میں ملتے ہیں! :)