אתה צודק, אבל בהגדרות התרגיל כתוב שמדובר במספר גדול מאוד של קוביות כך שאם הוצאת קוביה מצבע מסוים והקוביה לא חוזרת לשק (ואגב, לא כתוב שהיא לא חוזרת לשק אחרי שמשתמשים בה) זה עדיין כמעט ולא משנה את ההסתברות לשליפה של קוביה מצבע כלשהו (אלא אם הבנתי לא נכון). זה הבדל די מזערי.
שאלה לגבי הבודק האוטומטי. הגשתי את התרגיל ותיקנתי את כל ההערות (היו שם כמה רווחים סוררים). אחרי ההגשה ביצעתי כמה מקצי שיפורים. ביניהם החלפתי את הפונקציה שמחשבת את הנקודת בליסט קומפריהנשן. זה יצא שורה אחת קצרה ואלגנטית במקום פוקנציה של חמש שורות ושורת קריאה לפונקציה. כשהגשתי את זה לבודק קיבלתי את ההערה הבאה: “לא חייבים להשתמש כאן ב־list/dict comprehension, הפונקציה יודעת לקבל גנרטור.”
לא ממש הבנתי את תוכן ההודעה (מה הקשר לגנרטור פה). מעבר לכך, הייתי בטוח שליסט קומפריהנשן עדיף כי זה יותר קצר ואלגנטי וגם כי להבנתי זה עובד ברמת שפת C ולכן זה יותר מהיר מהלולאה שנדרשת בפונקציה. בינתיים הגשתי מחדש את התרגיל בצורה המקורית שלו (עם קריאה לפונקציה) כדי להיפטר מההערה הזו, אבל אשמח להבהרה למה ליסט קומפריהנשן לא עדיף במצב הזה (שזה מה שהבודק האוטומטי טוען).
האם על הlist comprehension מופעלת פונקציה?
אם כן אז עדיף להשתמש בגנרטור.
לדוגמא-
sum(I**2 for I in range(5)) (a
sum([I**2 for I in range(5)]) (b
בדוגמא פה הבודק מעדיף את דוגמא a
3 לייקים
הקומפריהנשן מופעל בתוך פונקציית “תור” שבניתי לצורך המשחק (כלומר הוא רץ בתוך פונקצייה) הוא גם משתמש במתודות שמעגלות את התוצאה בהתאם לדרישות נוסחת הניקוד. הוא מחליף את פונקציית חישוב הנקודות שמשתמשת בלולאה. אז הגשתי וזה עובד (תודה). אבל יש לי איזה חור בהשכלה פה. ההסרה של הסוגריים המרובעים הופכת את זה לקומפריהנשן מסוג אחר? זה בעצם generator comprehension או משהו כזה? לא הבנתי מה השינוי בסינטקס עושה פה ולמה הוא עדיף.
לייק 1