Professional Documents
Culture Documents
Op Tim Ization
Op Tim Ization
אפיון השיטה:
Tabu serachהיא שיטה מטא־יוריסטית ,המשלבת שימוש בזיכרון בשיטות חיפוש לוקאלי על מנת לפתור בעיות אופטימיזציה.
החסרון העיקרי של שיטות חיפוש לוקאלי הוא הנטייה להתפס על פתרון שהתקבל במינימום לוקאלי אך אינו הפתרון הטוב
ביותר.
Tabu searchמתגבר על הבעיה הזו באמצעות קבלת פתרונות שאינם משפרים את הפתרון הקיים ,כדי לא להיתקע על מינימום
לוקאלי .מבנה הזכרון בו הוא משתמש נקרא .Tabu list
:Tabu list
Tabu listהיא רשימה השומרת מספר קבוע של מהלכים שבוצעו לאחרונה .אם פתרון פוטנציאלי מופיע ב־ ,Tabu listאי אפשר
לבקר בו שוב כל עוד הוא נמצא ברשימה .ה־ Tabu listמאלץ את האלגוריתם לבקר במרחבים בהם עדיין לא ביקר ,וכך מונע
ממנו להתקע באותו מינימום לוקאלי.
1
שורות 1 − 4עוסקות באתחול .המשתנה s0הינו פתרון התחלתי ,פתרון זה מתקבל לפני הרצת ה־ Tabu searchעל ידי פונקציה
שיצרנו ומסופק לו כפרמטר.
את משתנה זה נקבע בתור הפתרון הטוב ביותר שראינו עד כה הן במשתנה sBestהמייצג את הפתרון הטוב ביותר שנתקלנו
בו ,וב־ bestCandidateשמייצג את הפתרון הטוב ביותר עבור איטרציה ספציפית של הלולאה .בנוסף ,נאתחל את ה־Tabu list
ונוסיף לו את הפתרון ההתחלתי.
את מבנה הזיכרון ב־ Tabu searchאפשר לחלק לשני סוגים עיקריים Short term memory :ו־.Long term memory
זיכרון לטווח קצר הוא ה־ ,Tabu listומטרתו לא לחזור לפתרונות שכבר ראינו .הוא מחזיק פתרונות שראינו עד שגודלו מגיע
למספר מסויים )בפסודו־קוד נקרא ,(maxTabuSizeולאחר מכן מוציא פתרונות ישנים לטובת חדשים.
זיכרון לטווח ארוך דומה לזכרון לטווח קצר ,אך מוסיף פונקציונליות שאמורה לעודד את האלגוריתם לחפש באיזורי פתרונות
מגוונים ולא להתקע בפתרון תת־אופטימלי .למשל ,דרך אחת לממש אותו היא לקחת פתרון התחלתי חדש רנדומלי אם עברו
מספר איטרציות קבוע ולא נתקלנו עדיין בפתרון טוב יותר.
המימוש בפועל:
משתנים אלה הם היפר־פרמטרים להם עשינו tuningעל מנת למצוא את הגודל האופטימלי להם ,נפרט על כך בהמשך.
הבעיה עליה בחרנו להציג את Tabu searchהיא בעיית הסוכן הנוסע .בבעיה זו ,הקלט הוא רשימת ערים והמרחקים בין כל
שתי ערים .פלט הבעיה הוא מסלול קצר ביותר המבקר בכל עיר בדיוק פעם אחת וחוזר לנקודת ההתחלה.
קל להמיר את הבעיה ליצוג בגרפים :הקלט הינו גרף מתויג וממושקל ,והפלט הינו מעגל המילטוני קצר ביותר בגרף.
מעשית ,ייצגנו את הקלט לבעיה בתור קובץ טקסט שכל שורה בו מייצגת קשת במבנה של :קודקוד התחלה ,קודקוד סיום ,משקל
הקשת .את הפלט אנחנו מייצגים בתור מערך של קודקודים.
הפתרון ההתחלתי שסיפקנו לאלגוריתם הוא מערך רנדומלי של קודקודים.
2
פונקציית ה־ tnessבה השתמשנו היא פונקציית משקל של מסלול .כלומר ,ערך ה־ tnessלמסלול מסויים הינו סכום משקלי
הקשתות במסלול זה .כאמור ,המסלול הטוב ביותר הינו זה עם ה־ tnessהנמוך ביותר.
בנוסף ,מימשנו .Long term memoryלאחר מספר מסויים של איטרציות ללא שינוי בפתרון האופטימלי ,אנחנו מאתחלים את
החיפוש באמצעות פתרון התחלתי חדש ואיפוס ה־.Tabu list
בקוד שלנו ,כל 500איטרציות שבהן לא היה שינוי בפתרון האופטימלי ,רוקנו את ה־ Tabu listויצרנו פתרון התחלתי חדש.
בנוסף ,הגדלנו את stopping_turnל־ 1000כדי שיהיו לו מספיק הזדמנויות למצוא פתרון אופטימלי ביחס לפתרון ההתחלתי
שקיבל.
נציין ששימוש בזיכרון לטווח ארוך היה טוב יותר משימוש בזיכרון לטווח קצר גם כאשר stopping_turnהיה בגודל .500
על מנת לכייל את הפרמטרים עבור ה־ ,Tabu searchהגדרנו שלוש קבוצות של גרפים :קטנים ,בינוניים וגדולים .כל קבוצה
מכילה כמה מספרים המייצגים מספר קודקודים בגרף .יצרנו פונקציה שיודעת ליצור קלטים לבעיה בגודל מסויים שנגדיר לה.
היא יוצרת גרפים מלאים עם משקלים רנדומליים בטווח .1 − 100
בכל קבוצה ,יצרנו גרפים לדוגמא עם מספר קשתות שונה ,ועליהם הרצנו את אלגוריתם ה־ .Tabu searchאת שלושת ההיפר
פרמטרים עליהם פירטנו קודם לקחנו מתוך מערך שהכיל שלושה גדלים לבדיקה עבור כל פרמטר .בלולאה ,הרצנו את תהליך
החיפוש עבור על פרמוטציה אפשרית של הגדלים לכל פרמטר וראינו את ערך התשובה ) (tnessואת זמן הריצה.
תהליך זה נתן אינדיקציה לאילו פרמטרים טובים לאיזה סוג גרפים ,ואת התוצאות והמסקנות נציג בסוף הדוח.
מעבר להשוואה של Tabu searchעם עצמו ,ביצענו גם השוואה שלו עם שיטות חיפוש לוקאלי אחרות ,כאלו שלא משתמשות
במבנה בסגנון .Tabu listהאלגוריתמים אותם מימשנו הם hill climbing :ו־.simulated annealing
על מנת לעשות השוואה כמה שיותר הוגנת ,רצינו לתת לכל אלגוריתם קבועים שמביאים אותו לביצועים הטובים ביותר .לכן
ביצענו כיול גם עבור פרמטרים אלו בשיטה דומה לזו שהשתמשנו בה עבור .Tabu search
תוצאות הניסויים:
בנוסף ,הבדיקות בוצעו על שלושה קבוצות של גדלים לגרפים .הגדלים של הגרפים הקטנים היו ,10, 25של הבינוניים היה 40
3
ושל הגדול היה .60הגרף הכי גדול שבדקנו היה בגודל 60מפאת הזמן שלוקח להריץ גרפים גדולים ממנו על כל הקומבינציות
השונות של הפרמטרים.
עבור כל גודל גרף ועבור כל פרמטר הרצנו את האלגוריתם שלוש פעמים ולקחנו את ממוצע הזמן וה־ ,costוכל ריצה עבור גודל
גרף ספציפי השתמשה באותו פתרון התחלתי כדי לשמור על אמינות התוצאות.
חשוב לציין שבניסויים שמנו לב שלפרמטר tabu sizeאין הרבה השפעה על גדלי הקלט שבדקנו ,ולכן על מנת לצמצם את
כמות הגרפים החלטנו לקבע את ערכו ל־) 500הערך הטוב ביותר( בכל ההרצות.
עבור קלטים בגודל 10התקבלו הגרפים הבאים:
4
עבור קלטים בגודל 40התקבלו הגרפים הבאים:
5
ולבסוף ,עבור קלטים בגודל 60התקבלו הגרפים:
6
מהגרפים האלו ניתן ללמוד על ההתנהגות של Tabu searchביחס לגדלי הפרמטרים וגודל הקלט.
בגרף הקטן )בגודל ,(10ניתן לראות שהתוצאות יוצאות זהות בכל גדלי הפרמטרים .עבור גדלים מקסימליים ) (500, 500הפתרון
לוקח 6שניות ,לעומת 0.2כאשר הגדלים הם ) − (100, 100פי 30איטי יותר .מגמה זו ממשיכה גם בגרפים הבאים ,ככל שגדלי
הפרמטרים גדולים יותר ,הפתרון לוקח יותר זמן.
אם נסתכל על הגרפים של ה־ ,costנבחין במגמה בה ככל שהקלט בעל יותר קודקודים ,ההבדל בין הפתרון הטוב ביותר לזה
הגרוע ביותר גדל .עבור 10קודקודים למשל ,ההבדל הוא .0ב־ 25ההבדל הוא כבר ,8 13עבור 40נקבל 58 41ועבור גרף בגודל
60הוא יהיה .90יתרה מזאת ,בגרפים בגדלים גדולים יותר ) 40ו־ ,(60עלייה בכל אחד מגדלי הפרמטרים )בנפרד או ביחד(
מביאה לירידה ב־.cost
7
נסיק ש־ Tabu searchמכיל trade-oבין זמן וביצועים ,וככל שנעלה את גודל הקלט הוא רק יגדל .עבור גרפים קטנים ,התוצאות
היו זהות לכל גדלי הפרמטרים ,ולכן נעדיף לתת להם ערכים קטנים מאחר וההשפעה על התוצאה זניחה או לא קיימת .הסבר
אפשרי לתופעה הזו הוא שבקלטים קטנים ,בכל שילוב של ערכי הפרמטרים ה־ Tabu searchמצליח להגיע לפתרון האופטימלי.
עבור גרפים גדולים יותר לעומת זאת ,נדרש לחשוב אם נעדיף פתרון טוב או זמן ריצה קצר יותר .בהתאם לבעיה אותה מנסים
לפתור והמגבלות איתן מתמודדים ,אפשר לחפש גודל אופטימלי לכל אחד מהמשתנים בו מוותרים קצת על זמן הריצה וקצת על
אופטימליות התוצאה ,אך ברמה שלא מפריעה לנו.
כמסקנה מהגרפים ,ראינו שגדלים של 500עבור stopping sizeו־ 500עבור neighborhood sizeהביא לתוצאות הטובות
ביותר .עם זאת stopping size ,בגודל 200הביאו תוצאות דומות עם זמן ריצה משמעותית נמוך יותר.
לכן בחרנו בגדלים 200עבור stopping sizeו־ 500עבור ,neighborhood sizeואיתם ביצענו השוואה לאלגוריתמים נוספים.
על מנת לבדוק את ביצועי ה־ ,Tabu searchביצענו השוואה לאלגוריתמי חיפוש לוקאלי אחרים .ביצענו שלוש הרצות עבור כל
גודל קלט וכל אלגוריתם .ההרצות בוצעו כולן על אותו הקלט ,ולקחנו את ממוצע ה־ costוהזמן עבור כל אלגוריתם .בכל
אלגוריתם המכיל פרמטרים ,נבחרו הפרמטרים הטובים ביותר לפי הכיול שביצענו קודם לכן.
באותן ההשוואות ,ביצענו גם השוואה גם של Tabu searchעם ) Long term memoryשאת מימושו תיארנו קודם לכן( ביחס
ל־ Tabu searchעם Short term memoryושאר אלגוריתמי החיפוש.
להלן גרפים של תוצאות ההשוואה:
8
ננתח את תוצאות הגרפים:
עבור קלט בגודל ,10ניתן לראות שהתוצאות זהות לכל האלגוריתמים .כמו בבדיקת Tabu searchמול עצמו ,גם כאן נוכל
להסביר זאת בכך שבקלט קטן מרחב החיפוש יחסית קטן ולכן כל שיטה הצליחה למצוא את האופטימום הגלובלי .מבחינת זמן,
Tabu searchבלי זכרון לטווח ארוך היה איטי פי 25משאר האלגוריתמים שהם לא ,Tabu searchוהגרסה עם הזיכרון לטווח
רחוק הייתה איטית פי 145מהם.
עבור קלט בגודל 25יש הבדלים גדולים יותר .כעת ,ביצועי השיטות המבוססות Tabu searchטובים יותר באופן ניכר משאר
האלגוריתמים ,בממוצע ב־ .64.8נשים לב שהזכרון לטווח ארוך סיפק פתרון טוב רק ב־ 2מהפתרון של החיפוש שלא משתמש בו,
אך עם זאת היה פי 3.73יותר איטי ממנו.
בקלט בגודל 40מגמה זו ממשיכה לקרות .ביצועי השיטות שמבוססות על Tabu searchטובים בממוצע ב־ 142.3משאר
האלגוריתמים .כמו קודם ,ההבדל בין הפתרון כאשר משתמשים בזכרון לטווח ארוך לעומת כאשר לא משתמשים קטן מאוד ,רק
.2.3הבדלי הזמן ביניהם רק גדלו ,כאשר שימוש בזיכרון לטווח ארוך איטי פי .5.57
לבסוף ,עבור קלט בגודל 60נקבל עוד יותר הבדלים Tabu search .טוב בממוצע ב־ 230.5משאר האלגוריתמים ,וההבדל בזמן
הריצה הוא פי 2.94עבור שיפור של 11.6בתוצאה.
9
מסקנות מהגרפים ,יתרונות וחסרונות לשיטה וסיכום:
מהנתונים שהצגנו ,ניתן ללמוד שה־ Tabu searchאכן עובד טוב יותר בהשוואה לאלגוריתמי חיפוש לוקאלי אחרים כאשר מדובר
בגרפים בגדלים גדולים .כלומר ,הוספת ה־ Tabu listאכן עוזרת להמנע מאופטימום לוקאלי ואכן מצליחה לשפר את התוצאות.
מעבר לכך ,ניתן ללמוד גם שביצועים אלה באים על חשבון זמן ריצה גדול יותר .ככל שקלט הבעיה גדל ,כך נצפה ליותר זמן
ריצה עבור Tabu searchביחס לאלגוריתמים אחרים .ניתן להגיע לזמן ריצה נמוך יותר על ידי משחק עם פרמטרי ה־Tabu
searchולנסות להגיע לתוצאה קרובה מספיק לתוצאה עבור הערכים הטובים ביותר בתמורה לזמן ריצה נמוך בהרבה .עוד נוסיף,
שמימוש זכרון לטווח ארוך מבוסס מודולו באופן כללי לא כדאי מכיוון שהוא מעלה בצורה רבה את זמן הריצה בלי להביא פתרון
משמעותית טוב יותר מהפתרון בלעדיו.
כמסקנה ,נוכל לאמר שבאופן כללי לבעיות בעלות קלט קטן יחסית ,נעדיף להשתמש בחיפוש לוקאלי לא מבוסס .Tabu search
למשל אלגוריתמים כמו .hill climbingעבור קלטים בינוניים וגדולים ,התשובה תלויה במה שמנסים למצוא .אם רוצים פתרון
טוב ככל הניתן ,לא משנה כמה זמן יקח ,נעדיף את Tabu searchמאחר והוא בהחלט מספק תוצאות טובות יותר.
אם לעומת זאת זמן הריצה קריטי ,נדרש לכייל את פרמטרי ה־ Tabu searchלאלו שמביאים זמן רצוי בידיעה שנראה ירידה
מסויימת בביצועים ובנוסף יש לקחת בחשבון שדבר כזה לוקח זמן.
חסרונות:
.1שיטה זו לא מבטיחה פתרון אופטימלי.
.2שיטה זו מכילה כמה פרמטרים ,וכיול שלהם לוקח לא מעט זמן.
.3טיב הביצועים תלוי במימוש של האלגוריתם :איך בוחרים שכנים ,מימוש הזיכרון לטווח רחוק וכולי.
לסיכום ,ביצענו השוואה של Tabu searchעל בעיית TSPמול אלגוריתמי חיפוש לוקאלי שונים.
למדנו שלכל שיטה יש את היתרונות והחסרונות שלה ,והבחירה באיזה אלגוריתם להשתמש אינה חד משמעית ותלויה בנתונים
נוספים .למשל :כמות הזיכרון שמוכנים להקצות לתהליך החיפוש ,כמות הזמן שמוכנים להקדיש ,הגדרת הבעיה ו“הפתרון טוב
מספיק“ בעינינו ,ומגבלות פיזיות כמו כוח חישוב שיש ברשותנו.
בתנאים המתאימים Tabu search ,זו שיטה שיכולה להתאים ולמצוא פתרונות טובים ביחס לאלגוריתמים אחרים.
10