הערות ממפגש 24/8/2022 של משתפי הפעולה של TFF

  • תמיכת טנזור דלילה ב-TFF:
    • EW - יש לנו דגמי Keras שאנחנו רוצים להעביר ל-TFF, יש להם טנסור דל
      • מיפוי פשוט לטנסור צפוף מביא לעלות זיכרון בלתי מקובלת ולאיטיות במקרה השימוש שלנו, אז אנחנו מחפשים להימנע מכך
    • ZG על תמיכת טנזור דלילה קיימת ב-TFF
      • בעיות שהוזכרו ב-GitHub קשורות בעיקר ל-tf.data.Dataset
      • לרוב עובד אחרת, אבל זה דורש קצת עשה זאת בעצמך, במיוחד צבירות, שבהן אנחנו לא יכולים רק בתמימות לעשות סכום דליל על משולשת הטנסורים המרכיבים, שלא תהיה התוצאה הרצויה
    • (שאלה לגבי חשיבות יחסית)
    • EW - זה לא חוסם עבורנו, אלא אופטימיזציה טובה של ביצועים/טביעת רגל
    • ZG - ביחס לבעיות GitHub, עשוי לעקוף על ידי הסתרת מערך הנתונים בתוך חישוב ה-TFF, כך שזה לא חלק מגבול הקלט-פלט
    • KO - מבהיר כי הערת "זה בעיקר עובד" שלנו מתייחסת לפרקטיקה המקובלת של ייצוג/טיפול בטנזורים דלילים כטפולים של טנזורים צפופים. האם ניסית להתמודד גם עם טנזורים צפופים דל כמו טפולים לשימוש במערך נתונים?
      • EW - עוד לא ניסיתי
    • KO - דליל בשיחה זו עלה בשני מקומות - עבור פרמטרים של מודל, אבל גם עבור נתוני קלט דלים - שניהם חשובים באותה מידה?
      • EW - באופן אידיאלי יהיה את שניהם
    • KO - פריט פעולה אחד עבור Ewan לנסות לעבוד עם tuples של טנסורים צפופים המייצגים את החלקים המרכיבים.
    • KO - זה עדיין משאיר שאלה לגבי ממשקי API/עוזרים טובים יותר לטיפול בטנזור דליל, אבל יכול לבטל את החסימה של מקרה השימוש הספציפי הזה. מחשבות על ה-API?
    • EW - באופן אידיאלי זה יכול להיות פשוט שקוף (אין צורך לעשות שום דבר מיוחד עבור דלילה על ידי הלקוח באמצעות TFF וזה פשוט עובד)
      • KO, ZG - במקרים מסוימים, זה לא ברור, למשל, עבור צבירה - יש פוטנציאל יותר מדרך אחת לצבור את החלקים המרכיבים של טנזורים דלילים, בחירה אידיאלית שתעשה על ידי הלקוח
      • KR - כנראה שיש משפחה קטנה של סמלים ייעודיים של "סכום דל" הוא הכי מעשי
      • KO - אולי נוכל להתחיל ביצירת אב טיפוס של הגרסה של הסכום הדליל הדרושה ל-EW ולקדם אותה ל-TFF כמפעיל סכום דליל גנרי כדי לראות את זה, ולהתבסס על זה (כדי לעקוב אחרי זה במצב לא מקוון - אולי על דיסורד)
      • EW +1
  • ההצעה של ג'רמי, ממשיכה מלפני שבועיים:
    • הערה טכנית של TFF: חיבורים ביוזמת הלקוח
    • (מה שצריך לעשות לכולם כדי לעיין בו מאוחר יותר מכיוון שהוא שותף זמן קצר לפני הפגישה)
    • (ג'רמי מציג)
    • JL - מציע את ההפשטה של ​​"חנות המשימות" להחלפת בקשות בין "ענן" לבין המבצעים לכל לקוח (למשל בדפדפנים), כשהאחרונים מושכים משימות מ"חנות משימות" מרכזית. האם משהו כזה נשקל בהקשר אחר?
    • KR - כן, בתרחישי טיפול בכשלים
      • עם זאת, בעיות שעירות יותר - העברת מדינה בין מוציאים לפועל היא קשה, לא בטוח עד כמה עובר לתרחיש שהציג ג'רמי
    • ח"ו - האם המוציאים לפועל בעלים יכולים להיות חסרי אזרחות
      • JL - זה יהפוך אותו ליותר כמו נייר SysML במכשיר חוצה
    • (שאלה לגבי ביצועים בתרחיש זה, בהשוואה לסטרימינג דו-כיווני באופן שדומה יותר לפרוטוקול ה-TFF המקורי)
    • JL - ack שיש שיקולי חביון
    • זרימה דו-כיוונית לא נתמכת בכמה תחבורה, כך שלא תמיד אפשרות מעשית
    • (נגמר הזמן)
    • (המשך בעוד שבועיים - נקודה ראשונה לסדר היום לפגישה הבאה, ג'רמי יצטרף)