מאגר פונקציות של וולפראם: פלטפורמת גישה פתוחה להרחבות שפות וולפראם

שלום, הבר! אני מציג לתשומת לבכם תרגום של הפוסט של סטיבן וולפרם "מאגר הפונקציות של וולפראם: השקת פלטפורמה פתוחה להרחבת שפת וולפרם".

תנאים מוקדמים לעקביות של שפת וולפרם

היום אנו עומדים על סף הישגים גדולים יחד עם שפת התכנות שפת וולפרם. רק לפני שלושה שבועות השקנו מנוע וולפרם בחינם למפתחיםלעזור למשתמשים שלנו לשלב את שפת Wolfram בפרויקטי התוכנה בקנה מידה גדול שלהם. היום אנחנו משיקים מאגר פונקציות Wolfram, על מנת לספק פלטפורמה מתואמת לפונקציות שנוצרו להרחבת שפת וולפרם, ואנחנו גם פותחים מאגר פונקציות לכל מי שיכול לתרום לפיתוח מוצר התוכנה שלנו.

מאגר הפונקציות של וולפרם הוא משהו שמתאפשר בזכות האופי הייחודי של שפת וולפראם לא רק כשפת תכנות, אלא גם כשפת תכנות. שפת מחשוב בקנה מידה מלא. בשפות תכנות מסורתיות, הוספת פונקציונליות משמעותית חדשה בדרך כלל כרוכה ביצירת ספריות נוספות שלמות שאולי יעבדו או לא יעבדו בשימוש יחד. עם זאת, בשפת וולפרם כל כך הרבה כבר מובנה בשפה עצמה, שאפשר להרחיב משמעותית את הפונקציונליות שלו על ידי הוספת פונקציות חדשות שמשתלבות מיד במבנה ההוליסטי של השפה כולה.

לדוגמה, מאגר הפונקציות של Wolfram כבר מכיל 532 תכונות חדשות מובנית ב-26 קטגוריות נושאיות:

כמו כן יותר מ 6000 פונקציות סטנדרטיות, מובנה בשפת Wolfram, לכל פונקציה מהמאגר יש דף תיעוד עם תיאור מפורט שלהם ודוגמאות לעבודה:

כדי להגיע לדף, העתק את האובייקט שלמעלה (פונקציה BLOB), הדבק אותו בשורת הקלט ולאחר מכן הפעל את הפונקציה - היא כבר מובנית בשפת Wolfram ונתמכת כברירת מחדל החל מ- גרסה 12.0:

יש לציין כאן כי בעת עיבוד LogoQRCode אתה לא צריך, למשל, להקים "ספריית עיבוד תמונה" - מכיוון שכבר יישמנו דרך אלגוריתמית עקבית וקפדנית בשפת וולפרם עיבוד תמונה, שניתן לעבד באופן מיידי על ידי פונקציות שונות של שפה גרפית:

אני מקווה שעם התמיכה קהילה נפלאה ומוכשרת, שגדל והתרחב (מבוסס על שפת וולפרם) במהלך העשורים האחרונים. מאגר הפונקציות של וולפראם יאפשר בעתיד הנראה לעין להרחיב באופן משמעותי את מגוון הפונקציות (שעשויות להיות משמעותיות, המתמחות בתחומים שונים של מדע וטכנולוגיה) הזמינים בשפה. כך, ניתן להשתמש הן בתוכן השפה (הפונקציות המובנות שלה) והן עקרונות פיתוח, אשר מיושמים על סמך השפה. (יש לציין כאן שלשפת וולפראם יש כבר יותר מ היסטוריה של 30 שנה של התפתחות וצמיחה יציבה).
פונקציות מהמאגר עשויות להכיל פיסות קוד קטנות או גדולות שנכתבו בשפת Wolfram. למשל, אלו יכולות להיות שיחות ממשקי API ושירותים חיצוניים או ספריות חיצוניות בשפות אחרות. התכונה הייחודית של גישה זו היא שכאשר אתה מתעמק בפונקציונליות ברמת המשתמש, לא יהיו חוסר עקביות פוטנציאליים מכיוון שהגישה בנויה על גבי המבנה העקבי של שפת וולפראם - וכל פונקציה תעבוד באופן אוטומטי בצורה נכונה - בדיוק כפי התכוונה. היא צריכה.
המעטפת ומבנה התכנות של מאגר התכונות של Wolfram תוכננו כך שכולם יוכלו לתרום למטרה המשותפת בצורה הפשוטה והנוחה ביותר עבורם - למעשה, רק על ידי מילוי קובץ הטקסט של פנקס הרשימות (עם סיומת nb) WL. פונקציות אוטומטיות מובנות מאפשרות לך לבדוק פונקציות חדשות שנוספו למאגר כדי להבטיח את שילובן בשפה. החברה שלנו מהמרת על המגוון הרחב של משתמשים שיכולים לשלב את הפונקציות שלהם בשפה, ולא על המורכבות הרבה של פונקציות חדשות - ולמרות שיש תהליך סקירה, אנחנו לא מתעקשים על שום דבר כמו ניתוח עיצוב קפדני או תקנים מחמירים לשלמות ומהימנות של תכונות משתמש חדשות, בניגוד לבדיקה קפדנית יותר של תכונות המובנות בשפת הליבה שבה אנו משתמשים.

ישנן פשרות ופרטים רבים בגישה זו, אך המטרה שלנו היא לייעל את מאגר התכונות של Wolfram הן עבור חווית המשתמש והן כדי להבטיח שתכונות משתמש חדשות תורמות באופן משמעותי לפיתוח השפה. ככל שאנו גדלים, אין לי ספק שנצטרך להמציא שיטות חדשות לעיבוד ואימות פונקציות המובנות במאגר, לא מעט לארגון מספר רב של פונקציות ומציאת אלו שהמשתמשים צריכים. עם זאת, מעודד שהדרך שבחרנו היא התחלה טובה. אני אישית הוסיפו מספר תכונות למסד הנתונים המקורי. רבים מהם מבוססים על קוד שפיתחתי באופן אישי במשך די הרבה זמן. ולקח לי רק כמה דקות לדחוף אותם למאגר. עכשיו כשהם במאגר, אני יכול סוף סוף - מיד ובכל זמן - להשתמש בפונקציות הללו לפי הצורך, מבלי לדאוג לחיפוש קבצים, הורדת חבילות וכו'.

הגברת היעילות תוך הפחתת עלויות

עוד לפני האינטרנט, היו דרכים לשתף קוד שפה של Wolfram (הפרויקט הריכוזי הראשון שלנו היה MathSource, נוצר עבור Mathematica בשנת 1991 על בסיס CD-ROM וכו'). כמובן, הגישה המוצעת ליישום המבוססת על מאגר הפונקציות של Wolfram היא כלי חזק ואמין יותר ליישום המשימות הנ"ל.

במשך למעלה מ-30 שנה, החברה שלנו עבדה במרץ כדי לשמור על שלמות מבנה שפת וולפרם, וזה קריטי כדי להבטיח ששפת וולפרם תהפוך לא רק לשפת תכנות, אלא גם לשפת תכנות. שפת מחשוב מלאה. ולפיכך, המהות של הגישה ליישום מאגר הפונקציות של וולפראם היא להשתמש בגישה מאוחדת לתכנות ופיתוח פונקציות חדשות שמתווספות ברצף ומתאימות למסגרת של השפה כך שהיא תוכל להתפתח ולהתפתח יחד.

תהליכים חישוביים שונים מתרחשים במבנה היישום של כל פונקציה. יש לציין כאן כי יש צורך שלפונקציה תהיה מראה ברור ואחיד וקריאות ויזואלית עבור המשתמש. בהקשר זה, הפונקציות המובנות של שפת וולפראם מוצגות עם יותר מ-6000 דוגמאות עוקבות כיצד לתכנת נכון פונקציות (אלה הן שלנו סרטוני תכנות חייםשכולל מאות שעות של תהליך של יצירת תוכניות סטנדרטיות). מה שגישה זו בסופו של דבר הופכת את מאגר התכונות של וולפרם למסוגל לבצע ביצועים טובים הוא האופי המבני של שפת וולפראם, עם מספר גדול של ספריות נוספות ומגוונות שכבר מובנות בשפה. לדוגמה, אם יש לך פונקציה שמעבדת תמונות, או מערכים דליליםאו מבנים מולקולרייםו - נתונים גיאוגרפיים או כמה אחרים - הייצוג הסמלי העקבי שלהם כבר קיים בשפה, ובזכות זה, הפונקציה שלך הופכת מיד לתואמת לפונקציות אחרות בשפה.

יצירת מאגר שלמעשה עובד טוב היא משימת מטה-תכנות מעניינת. לדוגמה, עודף של הגבלות בתוכנית לא יאפשר השגת האיחוד הנדרש והאוניברסליות של האלגוריתם. בדיוק כמו עם מספר לא מספיק של הגבלות פונקציונליות, לא תוכל ליישם רצף נכון מספיק של ביצוע אלגוריתם. מספר דוגמאות קודמות ליישום פשרה של גישות אלו, שיושמה על ידי החברה שלנו, פעלו בצורה די יציבה - אלו הן: פרויקט הדגמות טונגסטן, הושק ב-2007 וכעת פועל מקוון באינטרנט עם למעלה מ-12000 הדגמות אינטראקטיביות למשתמש. IN מסד נתונים של וולפרם ישנם יותר מ-600 מסדי נתונים מוכנים שניתן להשתמש בהם בשפת וולפראם, ו אחסון רשת עצבית של Wolfram מתמלא ברשתות עצביות חדשות כמעט כל שבוע (כבר יש 118 מהן עכשיו) והן מחוברות מיד דרך הפונקציה NetModel בשפת וולפרם.

לכל הדוגמאות לעיל יש תכונה בסיסית - לאובייקטים ולפונקציות שנאספו בפרויקט יש רמה גבוהה מאוד של מבנה והפצה של תהליכים. כמובן, הפירוט של המבנה של מה שהוא הדגמה או רשת עצבית או משהו אחר יכול להשתנות מאוד, אבל המבנה הבסיסי של כל מאגר נוכחי נשאר תמיד זהה. אז מה דעתך, משתמש יקר, על יצירת מאגר כזה שמוסיף הרחבות לשפת וולפרם? שפת Wolfram תוכננה להיות גמישה במיוחד, כך שניתן להרחיב אותה ולשנות אותה בכל דרך. נסיבות אלו חשובות ביותר ליכולת ליצור במהירות פרויקטי תוכנה בקנה מידה גדול בשפת וולפראם. יש לציין כאן שככל שהגמישות של השפה תגדל, עלות הפרויקטים המבוצעים בשפה כזו תגדל בהכרח. זאת בשל העובדה שככל שהמשתמש משתמש יותר בשפה כזו, כך הוא מקבל יותר פונקציונליות ייעודית, אך אל לנו לשכוח שלגישה זו עלולים להיות גם צדדים שליליים מבחינת חוסר היכולת להבטיח עקביות עקבית של מודולי התוכנית.

יש בעיה נפוצה עם ספריות בשפות תכנות מסורתיות - אם אתה משתמש בספרייה אחת, למשל, הקוד יעבוד כמו שצריך, אבל אם תנסה להשתמש במספר ספריות, אין ערובה שהן יפעלו בצורה נכונה זו עם זו . כמו כן, בשפות תכנות מסורתיות - שלא כמו שפת מחשוב מלאה - אין דרך להבטיח נוכחות של ייצוגים מובנים עקביים עבור כל פונקציה או סוג נתונים מלבד המבנים הבסיסיים שלהם. אבל, למעשה, הבעיה גדולה אפילו יותר ממה שהיא נראית במבט ראשון: אם בונים אנכית פונקציונליות בקנה מידה גדול, אז ללא העלויות העצומות של תכנות פרויקטים מרכזיים שהכנסנו לשפת וולפרם, אי אפשר להשיג עקביות. לכן חשוב שכל מודולי התוכנה תמיד יפעלו יחד בצורה נכונה.

אז הרעיון מאחורי מאגר התכונות של Wolfram הוא להימנע מהבעיה שתוארה לעיל על ידי הוספת הרחבות לשפה בפיסות קוד קטנות יחסית באמצעות תכונות בודדות שקל יותר לפתח כמודולים קוהרנטיים. עם זאת, ישנן תכונות תכנות שלא ניתן להפוך אותן לנוחות באמצעות פונקציות בודדות (והחברה שלנו מתכננת לשחרר אלגוריתם תכנות אופטימלי בעתיד הקרוב כדי לסייע ביישום חבילות תוכנה בקנה מידה גדול). עם זאת, בהתבסס על הפונקציות שכבר מובנות בשפת Wolfram, ישנן אפשרויות תכנות רבות המיושמות על סמך פונקציות בודדות. הרעיון כאן הוא שעם מאמץ תכנות קטן יחסית אפשר ליצור מספר פונקציות חדשות ושימושיות מאוד שיספקו קוהרנטיות מספקת לעיצוב, הן יתואמו היטב אחת עם השנייה, וגם, בנוסף לכך, הן יוכלו להשתמש בשפה בקלות ובאופן נרחב בעתיד.

גישה זו היא, כמובן, פשרה. אם חבילה גדולה יותר הייתה מיושמת, ניתן היה לדמיין עולם חדש של פונקציונליות שיהיה חזק ושימושי במיוחד. אם יש צורך בקבלת פונקציונליות חדשה שתשתלב בכל השאר, אך אינכם מוכנים להשקיע מאמצים רבים בפיתוח הפרויקט, הדבר, למרבה הצער, עלול להוביל לצמצום היקף הפרויקט שלכם. הרעיון מאחורי מאגר התכונות של וולפראם הוא לספק פונקציונליות לחלק מגדיר של פרויקט; גישה זו תוסיף פונקציונליות רבת עוצמה תוך כדי קל יותר לשמור על עקביות טובה בפרויקט תכנות.

עזרה בהוספת פונקציות מותאמות אישית למאגר הפונקציות

הצוות שלנו עבד קשה כדי להקל על המשתמשים לתרום לתכונות מאגר Wolfram. על שולחן העבודה (כבר נכנס גרסה 12.0), אתה יכול פשוט לעבור על לשוניות התפריט הראשי ברצף: קובץ > חדש > RepositoryItem > Function Repository Item ותקבל "מחברת הגדרה" (באופן תוכנתי בתוך שולחן העבודה. אתה יכול גם להשתמש בפונקציה האנלוגית - צור מחברת["משאב פונקציות"]):

ישנם שני שלבים עיקריים שתצטרכו לבצע: ראשית, רשום למעשה את הקוד עבור הפונקציה שלך, ושנית, רשום תיעוד הממחיש כיצד הפונקציה שלך אמורה לפעול.
לחץ על הלחצן "פתח מדגם" בחלק העליון כדי לראות דוגמה למה שאתה צריך לעשות:

בעיקרו של דבר, אתה מנסה ליצור משהו דומה לפונקציה מובנית בשפת Wolfram. אלא שהוא יכול לעשות משהו הרבה יותר ספציפי מפונקציה מובנית. יחד עם זאת, הציפיות לגבי שלמותו ואמינותו יהיו נמוכות בהרבה.
אתה צריך לתת לפונקציה שלך שם שעוקב אחר הנחיות מתן השמות של שפת וולפראם. בנוסף, תצטרך לפתח תיעוד עבור הפונקציה שלך, בדומה לפונקציות המובנות של השפה. אני אדבר על זה בפירוט רב יותר מאוחר יותר. לעת עתה, רק שימו לב שבשורת הכפתורים בחלק העליון של קובץ מחברת ההגדרה יש כפתור "הנחיות סגנון", המסביר מה לעשות, וכפתור כלים, המספק כלים לעיצוב התיעוד של הפונקציה שלך.
כאשר אתה בטוח שהכל ממולא כראוי ואתה מוכן, לחץ על כפתור "בדוק". זה לגמרי נורמלי שעדיין לא הבנת את כל הפרטים. אז הפונקציה "בדוק" תפעל אוטומטית ותבצע הרבה בדיקות סגנון ועקביות. לעתים קרובות, הוא ינחה אותך מיד לאשר ולקבל את התיקונים (לדוגמה: "שורה זו חייבת להסתיים בנקודתיים", והיא תנחה אותך להזין נקודתיים). לפעמים היא תבקש ממך להוסיף או לשנות משהו בעצמך. אנו נוסיף כל הזמן פיצ'רים חדשים לפונקציונליות האוטומטית של כפתור ה-Check, אבל בעצם המטרה שלו היא להבטיח שכל מה שאתה שולח למאגר התכונות כבר עוקב מקרוב אחר הנחיות סגנונות רבות ככל האפשר

אז, לאחר הפעלת "בדוק", אתה יכול להשתמש ב"תצוגה מקדימה". "תצוגה מקדימה" יוצר תצוגה מקדימה של דף התיעוד שהגדרת עבור הפונקציה שלך. אתה יכול גם ליצור תצוגה מקדימה לקובץ שנוצר במחשב שלך או לקובץ שנמצא באחסון בענן. אם, מסיבה כלשהי, אינך מרוצה ממה שאתה רואה בתצוגה המקדימה, פשוט חזור אחורה ובצע את התיקונים הדרושים, ולאחר מכן לחץ שוב על כפתור התצוגה המקדימה.
כעת אתה מוכן לדחוף את הפונקציה שלך למאגר. כפתור הפריסה נותן לך ארבע אפשרויות:

הדבר החשוב בשלב זה הוא שתוכל להגיש את הפונקציה שלך למאגר הפונקציות של Wolfram כך שהיא תהיה זמינה לכל אחד. במקביל, אתה יכול גם למקם את הפונקציה שלך עבור מספר מוגבל של משתמשים. לדוגמה, אתה יכול ליצור פונקציה שמתארחת באופן מקומי במחשב שלך כך שהיא תהיה זמינה כאשר אתה משתמש במחשב המסוים הזה. או שאתה יכול לפרסם את זה אצלך חשבון ענן, כך שהוא זמין עבורך כשאתה מחובר לענן. אתה יכול גם לארח (לפרוס) את התכונה באופן ציבורי דרך חשבון הענן שלך. זה לא יהיה במאגר התכונות המרכזי של Wolfram, אבל תוכל לתת למישהו כתובת URL שתאפשר לו לקבל את התכונה שלך מהחשבון שלך. (בעתיד, נתמוך גם במאגרים מרכזיים בכל החברה שלנו.)

אז נניח שאתה באמת רוצה לשלוח את הפונקציה שלך לבסיס הידע של פונקציות Wolfram. כדי לעשות זאת, לחץ על כפתור "שלח" למאגר. אז מה קורה כרגע? הבקשה שלך עומדת מיד בתור לבדיקה ואישור על ידי צוות האוצרים המסור שלנו.

ככל שהבקשה שלך מתקדמת בתהליך האישור (שאורך בדרך כלל מספר ימים), תקבל הודעות בנוגע למצב שלה ואולי הצעות לשימוש עתידי. אבל ברגע שהתכונה שלך תאושר, היא תפורסם מיד למאגר התכונות של Wolfram ותהיה זמינה לשימוש כל אחד. (וזה יופיע ב תקצירי חדשות של תכונות חדשות וכן הלאה)

מה צריך להיות באחסון?

יש לציין שלחברתנו סטנדרטים גבוהים מאוד לשלמות, אמינות ואיכות כללית, ומתוך 6000+ פונקציות שכבר בנו בשפת וולפרם במהלך 30+ השנים האחרונות, כולן עומדות בדרישות הנ"ל. המטרה של מאגר הפונקציות של Wolfram היא להשתמש בכל המבנה והפונקציונליות שכבר קיימים בשפת Wolfram על מנת להוסיף כמה שיותר פונקציות קלות יותר (כלומר, פונקציות ביצועים גבוהים יותר).

כמובן, פונקציות במאגר הפונקציות של Wolfram חייבות להתאים לעקרונות העיצוב של שפת Wolfram - כדי שיוכלו לקיים אינטראקציה מלאה עם פונקציות אחרות וציפיות המשתמשים לגבי האופן שבו הפונקציה צריכה לפעול כראוי. עם זאת, הפונקציות אינן חייבות להיות שלמות או מהימנות שווה.

בפונקציות המובנות של שפת וולפרם, אנו עובדים קשה כדי להפוך את פונקציות התכנות לכלליות ככל האפשר. עם זאת, כשאתה נמצא במאגר הפונקציות של וולפראם, אין שום דבר רע בכך שתהיה בו פונקציה שפשוט מטפלת באיזה מקרה מאוד ספציפי אך שימושי. למשל, הפונקציה SendMailFromNotebook יכול לקבל קבצים בפורמט אחד ספציפי וליצור דואר בצורה ספציפית אחת. דיאגרמה מצולעת יוצר תרשימים עם צבעים ותיוג מסוימים בלבד, וכו'.

נקודה נוספת הקשורה לפונקציות המובנות היא שהחברה שלנו עושה כל מאמץ לטפל בכל המקרים הלא טיפוסיים, לטפל נכון בקלט שגוי וכדומה. במאגר פונקציות, זה נורמלי לחלוטין שתהיה פונקציה מיוחדת שמטפלת במקרים העיקריים של פתרון בעיה ומתעלמת מכל השאר.

הנקודה הברורה היא שעדיף שיהיו פונקציות שעושות יותר ועושות את זה טוב יותר, אבל אופטימיזציה עבור מאגר פונקציות - בניגוד לפונקציות המובנות של שפת וולפרם - צריכה לכלול יותר פונקציות עם יותר פונקציות במקום להתעמק ב תהליכי היישום של כל פונקציה ספציפית.

כעת נסתכל על דוגמה לבדיקת פונקציות במאגר. ציפיות העקביות עבור פונקציות כאלה נמוכות באופן טבעי בהרבה מאשר עבור פונקציות שפה מובנות. זה נכון במיוחד במקרים בהם פונקציות תלויות במשאבים חיצוניים כגון APIs, חשוב לבצע כל הזמן בדיקות עקביות, מה שקורה אוטומטית בתוך אלגוריתמי האימות. בקובץ nb, אתה יכול לציין במפורש הגדרות (בקטע מידע נוסף) ולציין בדיקות רבות כפי שהוגדרו על ידי מחרוזות קלט ופלט או אובייקטים מלאים מסוג. VerificationTest, ככל שתמצא לנכון. בנוסף, המערכת מנסה כל הזמן להפוך את דוגמאות התיעוד שאתם מספקים לתהליך אימות (ולפעמים זה יכול להיות די עתיר משאבים, למשל, עבור פונקציה שתוצאתה תלויה במספרים אקראיים או בשעה ביום).

כתוצאה מכך, למאגר הפונקציות יהיו מספר מורכבויות יישום. חלקם יהיו רק שורת קוד בודדת, אחרים עשויים לכלול אלפי או עשרות אלפי שורות, ככל הנראה באמצעות פונקציות עוזר רבות. מתי כדאי להוסיף פונקציה שדורשת מעט מאוד קוד להגדרה? בעיקרון, אם לפונקציה יש שם זכרון טוב, שמשתמשים יבינו בקלות אם היו רואים אותו בקטע קוד, אז כבר ניתן להוסיף אותו. אחרת, כנראה שעדיף פשוט להוסיף מחדש את הקוד לתוכנית שלך בכל פעם שאתה צריך להשתמש בו.

המטרה העיקרית של מאגר פונקציות (כפי ששמו מרמז) היא להכניס תכונות חדשות לשפה. אם אתה רוצה להוסיף נתונים חדשים או ישויות חדשות, להשתמש מאגר נתונים של וולפרם. אבל מה אם אתה רוצה להציג סוגים חדשים של אובייקטים לחישובים שלך?

למעשה יש שתי דרכים. ייתכן שתרצה להציג סוג אובייקט חדש שישמש בפונקציות חדשות במאגר הפונקציות. ובמקרה זה, אתה תמיד יכול פשוט לרשום את הייצוג הסמלי שלו ולהשתמש בו בעת הזנה או פלט של פונקציות במאגר פונקציות.

אבל מה אם אתה רוצה לייצג אובייקט ואז מגדיר, באמצעות פונקציות קיימות בשפת וולפראם, שאתה רוצה לעבוד איתו? לשפת וולפראם תמיד היה מנגנון קל משקל לכך, הנקרא UpValues. עם כמה הגבלות (במיוחד עבור פונקציות ש לא יכול להעריך את הטיעונים שלהם), מאגר פונקציות מאפשר לך פשוט לייצג פונקציה ולהגדיר עבורה ערכים. (להעלות את הציפייה לעקביות בעת יצירת עיצוב מרכזי חדש המשולב במלואו בכל שפת וולפראם הוא בדרך כלל הליך חשוב מאוד שלא ניתן להשיג רק על ידי הגדלת עלות הפרויקט וזה משהו שהחברה שלנו עושה כחלק מפרויקטים לפיתוח ארוך טווח של השפה, משימה זו אינה מטרה המוגדרת כחלק מפיתוח המאגר).

אז מה עשוי להיות בקוד הפונקציה במאגר פונקציות? הכל מובנה בשפת וולפראם, כמובן (לפחות אם זה לא מייצג איומים עבור אבטחה והביצועים של התוכנית עצמה, כסביבת מחשוב) וכן כל פונקציה ממאגר הפונקציות. עם זאת, ישנן פונקציות אחרות: פונקציה במאגר פונקציות יכולה לקרוא ל-API, או ב ענן וולפרםאו ממקור אחר. כמובן, ישנם כמה סיכונים הקשורים לכך. בשל העובדה שאין ערבויות שה-API לא ישתנה, והפונקציה בחנות הפונקציות תפסיק לפעול. כדי לסייע בזיהוי בעיות כאלה, יש הערה בדף התיעוד (בסעיף הדרישות) עבור כל פונקציה המסתמכת על יותר מסתם פונקציונליות מובנית של שפת Wolfram. (כמובן, כשמדובר בנתונים אמיתיים, יכולות להיות בעיות אפילו עם הפונקציונליות הזו - כי הנתונים בעולם האמיתי משתנים כל הזמן, ולפעמים אפילו ההגדרות והמבנה שלהם משתנים).

האם כל הקוד עבור מאגר התכונות של Wolfram צריך להיכתב ב-Wolfram? אין ספק, הקוד בתוך ה-API החיצוני לא אמור להיכתב בשפת וולפרם, שאפילו לא מייצרת את קוד השפה. למעשה, אם אתה מוצא פונקציה כמעט בכל שפה או ספריה חיצונית, אתה יכול ליצור עטיפה המאפשרת לך להשתמש בה במאגר הפונקציות של Wolfram. (בדרך כלל אתה צריך להשתמש בפונקציות המובנות בשביל זה הערכה חיצונית או פונקציה חיצונית בקוד שפת וולפרם.)

אז מה הטעם לעשות את זה? בעיקרו של דבר, זה מאפשר לך להשתמש בכל מערכת השפה המשולבת של וולפראם ובכל מערך יכולות התוכנה המאוחדות שלה. אם אתה משיג את ההטמעה הבסיסית מספרייה או שפה חיצונית, תוכל להשתמש במבנה הסמלי העשיר של שפת Wolfram כדי ליצור פונקציה נוחה ברמה העליונה המאפשרת למשתמשים להשתמש בקלות בכל פונקציונליות שכבר מיושמת. לכל הפחות, זה צריך להיות אפשרי בעולם אידיאלי שבו קיימות כל אבני הבניין של טעינת ספריות וכו', ובמקרה זה הן יטופלו אוטומטית על ידי שפת וולפראם. (יש לציין שבפועל ייתכנו בעיות עם הגדרת שפות חיצוניות מערכת מחשב ספציפית, ואחסון בענן עלולים להוות בעיות אבטחה נוספות).

אגב, כשמסתכלים לראשונה על ספריות חיצוניות טיפוסיות, הן נראות לעתים קרובות מורכבות מדי מכדי לכסות אותן בכמה פונקציות, אבל במקרים רבים, חלק ניכר מהמורכבות נובעת מיצירת התשתית הדרושה לספרייה וכל הפונקציות תתמוך בזה . עם זאת, בעת שימוש בשפת וולפראם, התשתית בדרך כלל כבר מובנית בחבילות, ולכן אין צורך לחשוף את כל פונקציות התמיכה הללו בפירוט, אלא רק ליצור פונקציות עבור הפונקציות הספציפיות ליישום "העליון ביותר" בספריה .

"מערכת אקולוגית" של בסיס הידע

אם כתבת פונקציות שאתה משתמש בהן באופן קבוע, שלח אותן למאגר הפונקציות של Wolfram! אם לא ייצא מזה משהו נוסף (פיתוח שפה), אז גם אז יהיה לך הרבה יותר נוח להשתמש בפונקציות לשימוש אישי. עם זאת, הגיוני להניח שאם אתה משתמש בפונקציות באופן קבוע, אולי גם משתמשים אחרים ימצאו בהן שימושיות.

מטבע הדברים, אתה עלול למצוא את עצמך במצב שבו אינך מסוגל - או לא רוצה - לשתף את הפונקציות שלך או במקרה של גישה למשאבי מידע פרטיים. אפילו במקרים כאלה, אתה יכול פשוט לפרוס את הפונקציות בחשבון הענן שלך, מפרט זכויות גישה אליהם. (אם לארגון שלך יש ענן פרטי של Wolfram Enterprise, אז הוא יוכל בקרוב לארח מאגר תכונות פרטי משלו, אותו ניתן לנהל מתוך הארגון שלך ולהגדיר אם לאלץ צפיות להצגה על ידי משתמשי צד שלישי.)

הפונקציות שאתה שולח למאגר הפונקציות של Wolfram לא חייבות להיות מושלמות; הם רק צריכים להיות שימושיים. זה קצת כמו סעיף ה"שגיאות" בתיעוד הקלאסי של יוניקס - ב"מדור ההגדרות" ישנו סעיף "הערות המחבר" ​​בו תוכלו לתאר מגבלות, בעיות וכו' שאתם כבר יודעים על הפונקציה שלכם. בנוסף, כאשר אתה שולח את התכונה שלך למאגר, אתה יכול להוסיף הערות הגשה שייקראו על ידי צוות מסור של אוצרים.

ברגע שתכונה מתפרסמת, לדף שלה תמיד יש שני קישורים בתחתית: "שלח הודעה על תכונה זו"ו"לדון בקהילת וולפרם" אם אתה מצרף הערה (למשל, ספר לי על באגים), אתה יכול לסמן את התיבה שאומרת שאתה רוצה שההודעה שלך ופרטי הקשר שלך יהיו משותפים עם מחבר התכונה.

לפעמים אתה פשוט רוצה להשתמש בפונקציות ממאגר הפונקציות של Wolfram, כמו פונקציות מובנות, מבלי להסתכל על הקוד שלהן. עם זאת, אם אתה רוצה להציץ פנימה, תמיד יש כפתור פנקס רשימות בחלק העליון. לחץ עליו ותקבל עותק משלך של מחברת ההגדרה המקורית שהוגשה למאגר התכונות. לפעמים אתה יכול פשוט להשתמש בו כדוגמה לצרכים שלך. במקביל, אתה יכול גם לפתח שינוי משלך לפונקציה זו. ייתכן שתרצה לפרסם את הפונקציות הללו שמצאת מהמאגר במחשב שלך או בחשבון אחסון ענן כנימות, אולי תרצה לשלוח אותן למאגר הידע של הפונקציות, אולי כגרסה משופרת ומורחבת של הפונקציה המקורית.

בעתיד, אנו מתכננים לתמוך בחילוף בסגנון Git עבור מאגרי תכונות, אך לעת עתה אנו מנסים לשמור את זה פשוט, ותמיד יש לנו רק גרסה מקובלת אחת של כל תכונה מובנית בשפה. לעתים קרובות יותר מאשר לא (אלא אם כן מפתחים מוותרים על תחזוקת הפיצ'רים שפיתחו ויגיבו להגשות משתמשים), המחבר המקורי של הפיצ'ר לוקח שליטה על העדכונים שלו ומגיש גרסאות חדשות, שנבדקות לאחר מכן, ואם יעברו את תהליך הבדיקה , פורסם בשפה.

הבה נבחן את השאלה כיצד פועלת "גירסאות" של פונקציות מפותחות. כרגע, כאשר אתה משתמש בפונקציה ממאגר הפונקציות, ההגדרה שלה תישמר לצמיתות במחשב שלך (או בחשבון הענן שלך אם אתה משתמש בענן). אם גרסה חדשה של תכונה זמינה, בפעם הבאה שתשתמש בה תקבל הודעה המודיעה לך על כך. ואם תרצו לעדכן את הפונקציה לגרסה חדשה, תוכלו לעשות זאת באמצעות הפקודה עדכון משאבים. ("כתמת הפונקציות" למעשה מאחסנת יותר מידע על גרסאות, ואנו מתכננים להפוך את זה לנגיש יותר למשתמשים שלנו בעתיד.)

אחד הדברים היפים ב-Wolfram Function Repository הוא שכל תוכנת Wolfram Language, בכל מקום יכולה להשתמש בפונקציות ממנו. אם תוכנית מופיעה בפנקס רשימות, לרוב נוח לעצב את פונקציות המאגר כפונקציות "אובייקט בינארי פונקציה" קלות לקריאה (אולי עם ערכת גרסאות מתאימה).

אתה תמיד יכול לגשת לכל פונקציה במאגר הפונקציות באמצעות טקסט ResourceFunction[...]. וזה מאוד נוח אם אתה כותב קוד או סקריפטים ישירות עבור Wolfram Engine, למשל, עם באמצעות IDE או עורך קוד טקסט (יש לציין במיוחד שמאגר הפונקציות תואם באופן מלא עם מנוע וולפראם בחינם למפתחים).

איך זה עובד?

בתוך הפונקציות במאגר Wolfram זה אפשרי באמצעות אותו הדבר מערכות משאבים בסיסים, כמו ב כל המאגרים הקיימים האחרים שלנו (חנות מידע, מאגר נטו עצבי, אוסף פרויקטי הדגמה וכו'), כמו כל משאבי מערכת וולפרם האחרים, ResourceFunction בסופו של דבר מבוסס על תפקוד ResourceObject.

לשקול ResourceFunction:

בפנים אתה יכול לראות קצת מידע באמצעות הפונקציה מֵידָע:

כיצד פועלת הגדרת פונקציית משאב? המקרה הפשוט ביותר הוא מקרה מקומי בלבד. הנה דוגמה שלוקחת פונקציה (במקרה זה רק פונקציה טהורה) ומגדירה אותה כפונקציית משאב עבור הפעלה נתונה של תוכנית:

לאחר הגדרת ההגדרה, תוכל להשתמש בפונקציית המשאב:

שימו לב שיש אייקון שחור בבלוק הפונקציה הזה . המשמעות היא שהפונקציה BLOB מתייחסת לפונקציית המשאב בזיכרון שהוגדרה עבור ההפעלה הנוכחית. לתכונת משאב המאוחסנת לצמיתות במחשב או בחשבון הענן שלך יש סמל אפור . ויש אייקון כתום לתכונת משאבים רשמית במאגר התכונות של Wolfram .

אז מה קורה כשאתה משתמש בתפריט ההרחבה במחברת ההגדרה? ראשית, הוא לוקח את כל ההגדרות בפנקס הרשימות ומתוכם יוצר סימבולי ResourceObject). (ואם אתה משתמש ב-IDE או תוכנית מבוססי טקסט, אז אתה יכול גם ליצור במפורש ResourceObject)

פריסה מקומית של פונקציה ממאגר במחשב שלך מתבצעת באמצעות הפקודה LocalCache לאובייקט משאב לשמור אותו בתור LocalObject במערכת הקבצים שלך. הפריסה לחשבון ענן מתבצעת באמצעות הפקודה CloudDeploy עבור אובייקט משאב, ופריסה של ענן ציבורי הוא CloudPublish. בכל המקרים ResourceRegister משמש גם לרישום שם פונקציית המשאב, אז ResourceFunction["שֵׁם"] יעבוד.

אם תלחץ על כפתור שלח עבור מאגר פונקציות, מה יקרה מתחתיו ResourceSubmit נקרא על אובייקט משאב. (ואם אתה משתמש בממשק להזנת טקסט, אתה יכול גם להתקשר ResourceSubmit באופן ישיר.)

כברירת מחדל, ההגשות מתבצעות תחת השם המשויך ל-Wolfram ID שלך. אבל אם אתה מגיש בקשה מטעם צוות פיתוח או ארגון, אתה יכול הגדר מזהה בעל אתר נפרד ובמקום זאת השתמשו בו בתור השם לאינטראקציה עם הדעות שלכם.

לאחר ששלחת אחת מהפונקציות שלך למאגר הידע של הפונקציות, היא תעמוד בתור לבדיקה. אם תקבלו הערות בתגובה, הן בדרך כלל יהיו בצורת קובץ טקסט עם "תאי הערות" נוספים. אתה תמיד יכול לבדוק את סטטוס הבקשה שלך על ידי ביקור פורטל חברי מערכת משאבים. אבל ברגע שהפיצ'ר שלך יאושר, תקבל הודעה (באמצעות דוא"ל) והתכונה שלך תפורסם למאגר התכונות של Wolfram.

כמה דקויות בעבודה

במבט ראשון זה עשוי להיראות כאילו אתה יכול פשוט לקחת מחברת הגדרה ולהכניס אותה מילה במילה לתוך מאגר פונקציות, עם זאת, למעשה יש די הרבה דקויות מעורבות - והטיפול בהן דורש ביצוע מטא-תכנות די מורכב, טיפול בעיבוד סימבולי כקוד שמגדיר את הפונקציה , ו-Notepad עצמו מוגדר. רוב זה קורה באופן פנימי, מאחורי הקלעים, אבל יכולות להיות לזה כמה השלכות שכדאי להבין אם אתה מתכוון לתרום לבסיס הידע של התכונות.

עדינות מיידית ראשונה: כאשר אתה ממלא את מחברת ההגדרה, אתה יכול פשוט להתייחס לפונקציה שלך בכל מקום באמצעות שם כמו תפקוד שלי, שנראה כמו שם רגיל לפונקציה בשפת וולפראם, אך עבור תיעוד מאגר פונקציות זה מוחלף ResourceFunction["MyFunction"] הוא מה שהמשתמשים ישתמשו בפועל בעת עבודה עם הפונקציה.

העדינות השנייה: כאשר אתה יוצר פונקציית משאב מתוך Definition Notebook, יש ללכוד את כל התלות המעורבות בהגדרת הפונקציה ולכלול אותה במפורש. עם זאת, כדי להבטיח שההגדרות יישארו מודולריות, אתה צריך לשים את הכל בצורה ייחודית מרחב שמות. (כמובן, פונקציות שעושות הכל, נמצאים במאגר הפונקציות.)

בדרך כלל לעולם לא תראה שום זכר לקוד המשמש להגדרת מרחב השמות הזה. אבל אם מסיבה כלשהי אתה קורא לסמל שבוצע בחוסר ביצוע בתוך הפונקציה שלך, אז תראה שהסמל הזה נמצא בהקשר הפנימי של הפונקציה. עם זאת, בעת עיבוד ה-Definition Notepad, לפחות הסמל המתאים לפונקציה עצמה הוא מתכוונן לתצוגה הטובה ביותר כ-BLOB פונקציונלי ולא כדמות גולמית בהקשר הפנימי.

מאגר הפונקציות מיועד להגדרת פונקציות חדשות. ולפונקציות הללו עשויות להיות אפשרויות. לעתים קרובות פרמטרים אלה (לדוגמה, שִׁיטָה או גודל תמונה) יוכלו לשמש עבור פונקציות מובנות, כמו גם עבור אלו שעבורן כבר קיימים סמלים מובנים. אבל לפעמים תכונה חדשה עשויה לדרוש אפשרויות חדשות. על מנת לשמור על מודולריות, הפרמטרים הללו צריכים להיות סמלים המוגדרים בהקשר פנימי ייחודי (או משהו כמו פונקציות משאב שלמות, כלומר, עצמן). למען הפשטות, מאגר הפונקציות מאפשר לך להגדיר אפשרויות חדשות בהגדרות מחרוזת. ולנוחות המשתמש, הגדרות אלו (בהנחה שהשתמשו OptionValue и דפוס אפשרויות) מעובדים גם כך שבשימוש בפונקציות, ניתן לציין פרמטרים לא רק כמחרוזות, אלא גם כסמלים גלובליים עם אותם שמות.

רוב הפונקציות פשוט עושות את מה שהן אמורות לעשות בכל פעם שהן נקראות, אבל יש לאתחל חלק מהפונקציות לפני שהן יכולות לפעול בסשן מסוים - וכדי לפתור בעיה זו, יש סעיף "אתחול" בסעיף ההגדרה.

פונקציות ממאגר יכולות להשתמש בפונקציות אחרות שכבר נמצאות במאגר; על מנת להגדיר הגדרות עבור מאגר פונקציות הכוללות שתי (או יותר) פונקציות המתייחסות זו לזו, עליך לפרוס אותן בהפעלת התוכנית שלך כך שתוכל התייחסות כמו עליהם ResourceFunction["שֵׁם"], אז אתה יכול ליצור את השילובים של הפונקציות האלה שאתה צריך, דוגמאות (לא הבנתי) ולהוסיף פונקציה חדשה למאגר בהתבסס על אלה שכבר פורסמו קודם לכן. (או כבר או קודם לכן - שתי המילים מגושמות)

סיכויי פיתוח. מה צריך לקרות כאשר המאגר יהיה גדול באמת?

היום אנחנו רק משיקים את מאגר התכונות של Wolfram, אבל עם הזמן אנחנו מצפים שהגודל והפונקציונליות שלו עשויים לגדול באופן דרמטי, וככל שהוא יגדל בפיתוח יהיו בעיות שונות שאנחנו כבר צופים שיצוצו.

הבעיה הראשונה נוגעת לשמות הפונקציות והייחודיות שלהן. מאגר הפונקציות מתוכנן בצורה כזו שבדומה לפונקציות המובנות בשפת וולפראם, תוכלו להפנות לכל פונקציה נתונה פשוט על ידי ציון שמה. אבל זה אומר בהכרח ששמות פונקציות חייבים להיות ייחודיים גלובליים ברחבי המאגר, כך, למשל, יכול להיות רק אחד ResourceFunction["MyFavoriteFunction"].

זה אולי נראה כמו בעיה גדולה בהתחלה, אבל כדאי להבין שזו בעצם אותה בעיה כמו בדברים כמו דומיינים באינטרנט או ידיות של מדיה חברתית. והעובדה היא שלמערכת פשוט צריך להיות רשם - וזה אחד התפקידים שהחברה שלנו תבצע עבור מאגר הידע של פונקציות וולפרם. (לגרסאות פרטיות של מאגר, הרשמים שלהם עשויים להיות מנהלי מערכת.) כמובן שניתן לרשום דומיין אינטרנט מבלי שיהיה עליו שום דבר, אבל במאגר פונקציות ניתן לרשום שם פונקציה רק ​​אם יש הגדרה ממשית של הפונקציה.

חלק מתפקידנו בניהול בסיס הידע של פונקציות וולפראם הוא להבטיח שהשם שנבחר לפונקציה הוא הגיוני בהתחשב בהגדרת הפונקציה ושהוא עוקב אחר מוסכמות השמות של שפת וולפראם. יש לנו למעלה מ-30 שנות ניסיון במתן שמות לפונקציות מובנות בשפת Wolfram, וצוות האוצרים שלנו יביא את הניסיון הזה גם למאגר הפונקציות. כמובן, תמיד יש יוצאים מן הכלל. לדוגמה, אולי עדיף שיהיה שם קצר לפונקציה כלשהי, אבל עדיף "להגן" בשם ארוך יותר וספציפי יותר, כי יש סיכוי נמוך יותר להיתקל במישהו שירצה ליצור שם פונקציה דומה בעתיד .

(יש לציין כאן שפשוט הוספת תגית חבר כדי לבטל פונקציות לא תביא את האפקט המיועד. מכיוון שאם לא תתעקש להקצות תמיד תג, תצטרך להגדיר תג ברירת מחדל לכל פונקציה נתונה, וגם להקצות תגי מחבר , מה ששוב ידרוש תיאום גלובלי.)

ככל שבסיס הידע של פונקציות וולפרם גדל, אחת הבעיות שכנראה תתעוררנה היא יכולת הגילוי של פונקציות, שעבורן המערכת מספקת פונקציית חיפוש (וקובצי הגדרה עשויים לכלול מילות מפתח וכו'). עבור פונקציות מובנות בשפת Wolfram, יש כל מיני הפניות מוצלבות בתיעוד כדי לעזור "לפרסם" את הפונקציות. פונקציות במאגר פונקציות יכולות להתייחס לפונקציות מובנות. אבל מה עם ההיפך? לשם כך, אנו הולכים להתנסות בעיצובים שונים כדי לחשוף פונקציות מאגר בדפי תיעוד עבור פונקציות מובנות.

עבור פונקציות מובנות בשפת Wolfram יש מה שנקרא שכבת זיהוי מסופקת על ידי רשת של "דפי עזרה", המספקות רשימות מאורגנות של תכונות הקשורות לאזורים ספציפיים. תמיד קשה לאזן כראוי דפי אדם, וככל ששפת וולפרם גדלה, לעתים קרובות צריך לארגן מחדש לחלוטין את דפי האדם. זה די קל להכניס פונקציות ממאגר לקטגוריות רחבות, ואפילו לפרק את הקטגוריות הללו באופן עקבי, אבל זה הרבה יותר חשוב להחזיק דפי התייחסות לשפה מאורגנים כהלכה. עדיין לא ברור כיצד ליצור אותם עבור כל בסיס הידע של הפונקציות. לדוגמה, CreateResourceObjectGallery במאגר התכונות, כל אחד יכול לפרסם דף אינטרנט המכיל את ה"בחירות" שלו מהמאגר:

מאגר הפונקציות של Wolfram מוגדר כמאגר פונקציות מתמשך, כאשר כל פונקציה בו תמיד תעבוד. כמובן, גרסאות חדשות של תכונות עשויות להיות זמינות, ואנו מצפים שחלק מהפיצ'רים כמובן יתיישנו עם הזמן. הפונקציות יפעלו אם נעשה בהן שימוש בתוכניות, אך דפי התיעוד שלהן יקשרו לפונקציות חדשות ומתקדמות יותר.

מאגר התכונות של Wolfram נועד לעזור לך לגלות במהירות תכונות חדשות וללמוד דרכים חדשות להשתמש בשפת Wolfram. אנחנו מאוד אופטימיים שחלק ממה שנחקר במאגר התכונות יהיה הגיוני בסופו של דבר להפוך לחלקים מובנים בשפת הליבה של Wolfram. בעשור האחרון היה לנו סט דומה תכונות שהוצגו במקור ב-Wolfram | אלפא. ואחד הלקחים שנלמדו מהניסיון הזה הוא שהשגת הסטנדרטים של איכות ועקביות שאנו מתמקדים בהם בכל מה שמובנה בשפת וולפרם דורשת עבודה רבה, שלעתים קרובות היא קשה יותר מהמאמץ הראשוני ליישום הרעיון. למרות זאת, פונקציה בבסיס הידע של הפונקציות יכולה לשמש כהוכחה שימושית מאוד למושג לפונקציה עתידית שבסופו של דבר עשויה להיבנות בשפת וולפרם.

הדבר החשוב ביותר כאן הוא שפונקציה במאגר פונקציות היא משהו שזמין עבור כל משתמש לשימוש עכשיו. יתכן שתכונה בשפת אם יכולה להיות הרבה יותר טובה וביצועית יותר, אבל מאגר תכונות יאפשר למשתמשים לקבל גישה לכל התכונות החדשות מיד. והכי חשוב, הרעיון הזה מאפשר לכל אחד להוסיף כל פיצ'ר חדש שהוא רוצה.

מוקדם יותר בהיסטוריה של שפת וולפרם, הרעיון הזה לא היה עובד כמו שהוא עבד, אבל בשלב זה מושקע כל כך הרבה מאמץ בשפה, והבנה כה עמוקה של עקרונות עיצוב השפה, עד שכעת זה נראה מאוד אפשרי לקהילה גדולה של משתמשים להוסיף תכונות שישמרו על עקביות עיצובית כדי להפוך אותן לשימושיות למגוון רחב של משתמשים.

יש רוח מדהימה של כישרון(?) בקהילת המשתמשים ב-Wolfram Language. (כמובן, קהילה זו כוללת הרבה אנשי מחקר ופיתוח מובילים במגוון תחומים.) אני מקווה שמאגר התכונות של וולפראם יספק פלטפורמה יעילה לפתיחה והפצה של רוח כישרון זו. רק ביחד נוכל ליצור משהו שירחיב משמעותית את התחום עליו ניתן ליישם את פרדיגמת המחשוב של שפת וולפראם.

במשך יותר מ-30 שנה, עברנו דרך ארוכה עם שפת הוולפרם. עכשיו ביחד, בואו נלך אפילו רחוק יותר. אני מעודד בחום את כל המשתמשים המכובדים של שפת וולפרם ברחבי העולם להשתמש במאגר הפונקציונלי כפלטפורמה לכך, כמו גם בפרויקט התוכנה החדש כגון מנוע וולפרם החופשי למפתחים.

מקור: www.habr.com