הפעם הראשונה א 0.1 + 0.2 === 0.3 באג נשך אותי בייצור, עשיתי מה שרוב המפתחים עושים: חיפשתי, מצאתי " נקודה צפה היא מוזרה, " והמשכתי הלאה עברו שנים לפני שבאמת הסתכלתי על הביטים והבנתי למה ברגע שעשיתי זאת, קטגוריה שלמה של באגים מספריים הפסיקה להיות מסתורית המדריך הזה עובר על מה שמראה לך ממיר IEEE 754, באמצעות ה ממיר IEEE 754 על Toolz.dev, ומדוע לבהות בסימן, במעריך ובמנטיסה היא הדרך המהירה ביותר לבנות אינטואיציה אמיתית לגבי האופן שבו מחשבים מאחסנים עשרוניות.
TL;DR: מחשבים מאחסנים מספרי נקודה צפה כסימן, חזקה של שתיים ושבר מובהק, בהתאם לתקן IEEE 754. ממיר IEEE 754 מקודד עשרוני כמו 3.14159 לאותם ביטים מדויקים ומפענח ביטים בחזרה לערך. ה ממיר IEEE 754 האם שניהם, לדיוק יחיד וכפול, לגמרי בדפדפן שלך, כשהשלט, המעריך והמנטיסה פרוצים.
מהו IEEE 754?
IEEE 754 הוא התקן, שפורסם לראשונה בשנת 1985 ותוקן כ IEEE 754-2019, זה מגדיר כיצד מחשבים מייצגים מספרי נקודה צפה בבינארי. כמעט כל מעבד, GPU ושפת תכנות עוקבים אחריו, וזו הסיבה ש-a double מתנהג אותו הדבר ב-C, Java, Python ו-JavaScript. כשאנשים אומרים " נקודה צפה," הם מתכוונים כמעט תמיד לנקודה צפה בינארית IEEE 754.
רעיון הליבה הוא שמספר מאוחסן בשלושה חלקים יש סיבית סימן שאומרת חיובי או שלילי יש מעריך שמשנה את הערך בחזקת שתיים ויש מנטיסה, שנקראת גם השבר או המובהק, שמחזיקה את הספרות המדויקות ביחד, מספר נורמלי הוא סימן כפול 1.mantissa כפול 2 למעריך זה סימון מדעי, בבסיס שני, ארוז במספר קבוע של ביטים.
שני הפורמטים שאתה פוגש מדי יום הם דיוק יחיד, הנקרא binary32, ודיוק כפול, הנקרא binary64. יחיד משתמש בסיבית סימן 1, 8 סיביות מעריך ו-23 סיביות מנטיסה, עבור 32 סיביות בסך הכל. כפול משתמש בסיבית סימן 1, 11 סיביות מעריך ו-52 סיביות מנטיסה, עבור 64 סיביות בסך הכל. כפול הוא סוג ברירת המחדל של נקודה צפה ברוב השפות; יחיד נפוץ במעבדי GPU ובקוד רגיש לזיכרון.
מה בעצם עושה ממיר IEEE 754?
ממיר IEEE 754 לוקח מספר ומראה לך את תבנית הסיביות המדויקת שלו, מפוצלת לשלושת השדות האלה, יחד עם הצורה ההקסדצימלית והערך הנקרא בחזרה מהסיביות. זה עובד לשני הכיוונים: הזן עשרוני כדי לקודד אותו, או הדבק תבנית סיביות בינארית או משושה כדי לפענח אותו בחזרה למספר שהוא מייצג.
בToolz.dev זרימת העבודה קצרה בחר דיוק יחיד או כפול בחר אם הקלט שלך הוא מספר עשרוני, תבנית סיביות משושה או תבנית סיביות בינארית הזן את הערך הכלי מציג את סיבית הסימן, שדה המעריך, המנטיסה, הסיביות המלאות, המשושה, המעריך המוטה והבלתי מוטה כאחד, והערך המאוחסן המדויק לכל שדה יש כפתור העתקה.
הסיבה להסתכל על כל זה, במקום לסמוך על המספר שהשפה שלך מדפיסה, היא שהמספר המודפס נמצא בהשמטה. כאשר הקונסולה שלך מופיעה 0.1, זה מראה לך עיבוד מעוגל וידידותי. הביטים אומרים לך מה באמת מאוחסן, וההבדל בין שני אלה הוא המקום שבו חיים באגים בנקודה צפה.
מדוע 0.1 ועוד 0.2 לא שווה ל-0.3?
זו הדוגמה הקנונית, והממיר הופך אותו לקונקרטי הערך 0.1 לא יכול להיות מיוצג בדיוק בנקודה צפה בינארית, מאותה סיבה לא ניתן לכתוב 1/3 בדיוק בעשרוני בבסיס עשר, 1/3 הוא 0.3333... לנצח בבסיס שני, 0.1 הוא שבר חוזר שלעולם לא מסתיים, ולכן יש לעגל אותו כך שיתאים ל-52 סיביות מנטיסה.
פענח את הכפיל עבור 0.1 והערך שהסיביות מחזיקות בפועל הוא 0.1000000000000055511151231257827021181583404541015625 הכפיל עבור 0.2 הוא באופן דומה שערה גדולה מדי הוסף את שני הערכים המעוגלים והתוצאה היא ביט זעיר יותר מ-0.3, אבל הכפיל עבור 0.3 הוא ביט זעיר פחות, אז השניים לא שווים שום דבר לא שבור כל שלב עושה בדיוק מה ש-IEEE 754 דורש, והממיר מאפשר לך לראות את זה קורה במקום לקחת את זה באמונה.
לאחר שראיתם זאת, התיקון בא באופן טבעי: לעולם אל תשוו מצופים לשוויון מדויק השוו בתוך סובלנות קטנה, או השתמשו בסנטים שלמים לכסף, או בספרייה עשרונית כאשר אתם זקוקים לאריתמטיקה עשרונית מדויקת הבאג מעולם לא היה בתוספת זה היה בציפייה לפורמט בינארי לאחסן שברים עשרוניים בדיוק.
מהם הסימן, המעריך והמנטיסה?
לכל תחום יש עבודה ספציפית, והממיר מתייג את שלושתם.
סיבית הסימן היא הפשוטה ביותר: 0 פירושו חיובי, 1 פירושו שלילי. מכיוון שהסימן הוא סיביות נפרדות, ל-IEEE 754 יש גם אפס חיובי וגם אפס שלילי, שמתנהגים באותה מידה בהשוואות אך נושאים ביטים שונים.
שדה המעריך מאחסן חזקה של שתיים, אבל עם הטיה שנוספה כך שהוא יכול לייצג מעריכים שליליים ללא סימן נפרד ההטיה היא 127 עבור דיוק בודד ו-1023 עבור כפול. אז שדה מעריך מאוחסן של 127 בדיוק יחיד פירושו מעריך בפועל של אפס. ממיר Toolz.dev מציג את שני המספרים: הערך המוטה שחי בסיביות, והחזקה הבלתי מוטה של שניים הוא למעשה חל. ההבחנה הזו מעכבת הרבה אנשים, וזו הסיבה שהכלי מאיית את זה במקום לגרום לך להחסיר בראש שלך.
המנטיסה מחזיקה את החלק השברירי של המובהק עבור מספר נורמלי יש מוביל מרומז 1 שאינו מאוחסן, מכיוון שמשמעות בינארית מנורמלת מתחילה תמיד ב-1, כך שהפורמט מקבל סיביות חופשיות של דיוק על ידי השארתו בחוץ. לכן דיוק בודד נותן כ-7 ספרות עשרוניות וכפול נותן כ-15 עד 16, למרות ששדות המנטיסה הם 23 ו-52 סיביות.
הנה איך שני הפורמטים מסתדרים שדה אחר שדה:
| נכס | יחיד (בינארי32) | כפול (בינארי64) |
|---|---|---|
| סך כל הביטים | 32 | 64 |
| סימני פיסות | 1 | 1 |
| סיביות מעריך | 8 | 11 |
| חתיכות מנטיסה | 23 | 52 |
| הטיית מעריך | 127 | 1023 |
| בערך. ספרות עשרוניות | 7 | 15 עד 16 |
| שם נפוץ | לצוף | כפול |
כיצד אוכל להמיר ביטים בחזרה למספר עשרוני?
פענוח שימושי בדיוק כמו קידוד, וכך אתה קורא ערך מתוך dump זיכרון, פורמט קובץ בינארי או פרוטוקול רשת המאחסן מצופים גולמיים. הגדר את סוג הקלט ל-Hex או Binary והדבק את תבנית הסיביות המדויקת שהדיוק מצפה לה: 8 ספרות hex או 32 סיביות עבור יחיד, 16 ספרות hex או 64 סיביות עבור כפול.
לדוגמה, המשושה בעל דיוק יחיד 40490FDB מפענח ל-3.1415927, הציפה הקרובה ביותר ל-pi. הממיר מקבל גם אופציונלי 0x קידומת ומתעלם מרווחים ומקוים תחתונים, כך שתוכל להדביק בתים מקובצים כפי שאתה מוצא אותם. אם אתה נותן לו את המספר הלא נכון של ספרות, זה אומר לך בדיוק כמה הדיוק הזה צריך במקום לקצץ בשקט, וזה סוג הודעת השגיאה שהייתי רוצה שיותר כלים יטרחו לכתוב.
כיוון הפענוח הזה משתלב באופן טבעי עם גנרל ממיר בסיס מספרים כאשר אתה צריך להעביר ערך בין עשרוני, משושה, בינארי ואוקטלי ללא פרשנות הנקודה הצפה, ועם מתרגם בינארי כשאתה עובד עם טקסט ולא עם מספרים אני מושיט את ידי לשלושתם לעתים קרובות מספיק כדי שהם גרים באותה פינה של הסימניות שלי.
כיצד מיוצגים אינסוף, NaN ואפס?
הערכים המיוחדים הם המקום שבו IEEE 754 מתחכם, והממיר מזהה עבורך כל מקרה כך שלא תצטרך לשנן את הדפוסים.
שדה המעריך פועל כמתג כאשר כל סיבית מעריך היא 1, אתה נמצא בטווח המיוחד: מנטיסה של כל אפס פירושה אינסוף, וכל מנטיסה שאינה אפס פירושה NaN, לא מספר אינסוף חיובי ושלילי נבדלים רק בסיבית הסימן NaN הוא מה שאתה מקבל מפעולות כמו אפס חלקי אפס או שורש ריבועי של שלילי, ויש לו את התכונה המפורסמת שהוא לא שווה לעצמו.
כאשר כל סיבית מעריך היא 0, אתה נמצא בטווח המיוחד השני: מנטיסה של כל אפס היא אפס, חיובית או שלילית בהתאם לסיבית הסימן, ומנטיסה שאינה אפס היא מספר תת-נורמלי תת-נורמליים ממלאים את הפער בין אפס למספר הנורמלי הקטן ביותר, סוחרים בדיוק עבור היכולת לייצג גדלים זעירים מאוד הם משתמשים במעריך אפקטיבי של אחד פחות ההטיה, והם מפילים את ה-1 המוביל המרומז, שהממיר אחראי לו כאשר הוא מציג את המעריך הבלתי מוטה.
כל השאר, שבו שדה המעריך אינו כל האפסים ולא כל אלה, הוא מספר נורמלי היכולת להציץ בתבנית סיביות ולדעת באופן מיידי באיזה מחמשת המקרים הללו אתה מסתכל הוא כוח-על אמיתי של ניפוי באגים כאשר חישוב מייצר ערך שלא ציפית לו.
מתי אני באמת צריך את זה?
אתה צריך את זה לעתים קרובות יותר ממה שהיית מנחש ברגע שאתה יודע להסתכל. אני מושיט יד אליו כאשר תוצאה מספרית כבויה על ידי שגיאת עיגול ואני רוצה לאשר אם הערך ניתן לייצוג בדיוק. אני משתמש בו בעת כתיבה או ניפוי באגים של סדרתי בינארי, פורמט קובץ או פרוטוקול חוט המאחסן צפים, כדי שאוכל לאמת שהבתים תואמים למה שהתכוונתי. זה הכרחי כאשר משווים דיוק יחיד וכפול, למשל להחליט אם הצללת GPU יכולה להשתמש float מבלי לאבד יותר מדי דיוק. וזה אחד מעזרי ההוראה הברורים ביותר שאני מכיר לארכיטקטורת מחשבים, כי ראיית התחומים הופכת את הסטנדרט המופשט למוחשי.
אם בונים על פני הערימה כמו שאני בונה, נקודה צפה מופיעה במקומות מפתיעים: חישוב מחיר ב-API של Laravel, אנימציית קנבס ב-React, ייצוא CSV שמבלבל קואורדינטה הבנת פורמט האחסון היא השקעה קטנה שמשתלמת על פני כולם כתבתי על איך כלים כאלה משתלבים בערכה רחבה יותר ב ערכת כלים למפתחי אינטרנט, וה מדריך ממיר בסיס מספרים ו מדריך מתרגם בינארי כסה את ההמרות השכנות ברמה נמוכה יותר לעומק.
מהם הגבולות של דיוק נקודה צפה?
ברגע שאתה יכול לראות את הסיביות, גבולות הפורמט מפסיקים להיות מופשטים. לכפיל יש 52 סיביות מנטיסה מאוחסנות בתוספת ה-1 המוביל המרומז, שמסתדר בערך ל-15 עד 16 ספרות עשרוניות משמעותיות. Push past that והדיוק מתאדה בשקט המספר השלם הגדול ביותר שכפיל יכול לייצג כשכל ערך ביניהם עדיין מדויק הוא 2 בחזקת 53, שהיא 9007199254740992. הוסף לזה אחד והתוצאה מתעגלת חזרה למטה, כי הערך הבא שניתן לייצוג נמצא במרחק שניים, לא אחד. זו הסיבה ששפות שמשתמשות בכפילים עבור כל המספרים, JavaScript ביניהם, חושפות א Number.MAX_SAFE_INTEGER קבוע בדיוק בערך הזה, ומדוע מזהי מסד נתונים גדולים הנשלחים כמספרי JSON עלולים להשחית בשקט.
הפער בין ערך אחד שניתן לייצוג לאחר נקרא יחידה במקום האחרון, או ULP, והוא גדל ככל שהגודל גדל קרוב ל-1.0 הפער הוא זעיר; קרוב למיליארד זה כמה מאות; ליד הכפיל המקסימלי, בסביבות 1.8 כפול 10 עד ה-308, הפער בין השכנים גדול מבחינה אסטרונומית הממיר הופך את זה לגלוי: מקודד שני מספרים גדולים בקרבת מקום ולעתים קרובות תגלו שהם חולקים את אותם ביטים, כי פשוט אין ייצוג ביניהם הבנת ULP היא מה שעוצר אותך מלצפות ליותר רזולוציה ממה שהפורמט יכול לתת.
מלכודת קשורה היא ביטול קטסטרופלי כאשר מחסירים שני מספרי נקודה צפה כמעט שווים, הספרות המובילות מבטלות ונותרים עם הסיביות מסדר נמוך, שהיו החלק הכי פחות מדויק מלכתחילה התוצאה יכולה להיות נשלטת על ידי שגיאת עיגול למרות שכל קלט נראה מדויק זו הסיבה שקוד זהיר מבחינה מספרית מסדר מחדש פעולות כדי להימנע מהפחתת כמויות קרובות, ומדוע סיכום רשימה ארוכה של מצופים בלולאה נאיבית צובר שגיאה שאלגוריתמים טובים יותר כמו סיכום Kahan נמנעים ממנה.
הטייק אווי המעשי עקביים אל תאחסן כסף כמצוף; השתמש בסנטים שלמים או בסוג עשרוני, מכיוון שערך כמו 0.10 אינו בדיוק ניתן לייצוג ושגיאות מורכבות על פני אלפי עסקאות. אל תשווה מצופים עם שוויון מדויק; השווה בתוך סובלנות בגודל לבעיה שלך. וכאשר מספר שלם גדול מאוד חייב לשרוד נסיעה הלוך ושוב, שמור אותו כמחרוזת או השתמש בסוג מספר שלם בעל דיוק שרירותי במקום לסמוך על כפיל שיחזיק אותו. קל יותר לזכור כל אחד מהכללים הללו ברגע שהממיר הראה לך מדוע הפורמט מתנהג כפי שהוא מתנהג.
שאלות נפוצות
כיצד אוכל להמיר מספר עשרוני ל-IEEE 754?
בחר דיוק יחיד או כפול, שמור את סוג הקלט על עשרוני, הקלד את המספר שלך והמר הכלי מקודד את הערך לתבנית IEEE 754 סיביות שלו ומציג את סיביות הסימן, שדה המעריך, מנטיסה, בינארי מלא והקסדצימלי. הכל פועל בדפדפן שלך.
מה ההבדל בין דיוק יחיד לכפול?
דיוק יחיד (binary32) משתמש ב-32 סיביות: סימן 1, 8 מעריך ו-23 מנטיסה, מה שנותן כ-7 ספרות עשרוניות של דיוק. דיוק כפול (binary64) משתמש ב-64 סיביות: סימן 1, 11 מעריך ו-52 מנטיסה, נותן כ-15 עד 16 ספרות. כפול הוא סוג הציפה המוגדר כברירת מחדל ברוב השפות; יחיד נפוץ במעבדי GPU ובקוד מוגבל בזיכרון.
מדוע 0.1 לא ממיר לערך מדויק?
ל-0.1 אין ייצוג סופי בנקודה צפה בינארית, בדיוק כפי של-1/3 אין עשרוני סופי. הכפיל הניתן לייצוג הקרוב ביותר הוא 0.1000000000000055511151231257827021181583404541015625. הממיר מציג את הערך המאוחסן שנקרא בחזרה מהסיביות, כך שתוכל לראות את ההבדל הזעיר שגורם להפתעות עיגול כמו 0.1 + 0.2 לא שווה ל-0.3.
מהם הסימן, המעריך והמנטיסה?
סיבית הסימן היא 0 עבור חיובי ו-1 עבור שלילי. שדה המעריך מאחסן חזקה של שתיים עם הטיה נוספת (127 עבור יחיד, 1023 עבור כפול), וזו הסיבה שהכלי מציג גם את הערך המוטה בסיביות וגם את ההספק הבלתי מוטה שהוא מחיל. המנטיסה מחזיקה את החלק השברירי של המובהק, עם מוביל מרומז 1 עבור מספרים נורמליים.
האם אוכל להמיר IEEE 754 סיביות בחזרה למספר עשרוני?
כן.Set the input type to Hex or Binary and paste the exact bit pattern: 8 hex digits or 32 bits for single precision, 16 hex digities or 64 bits for double הכלי מפענח אותו ומציג את הערך העשרוני שהוא מייצג יחד עם פירוט השדות המלא.
כיצד מיוצגים אינסוף, NaN ואפס?
כאשר כל סיבית מעריך היא 1, מנטיסה של כל אפס פירושה אינסוף ומנטיסה שאינה אפס פירושה NaN. כאשר כל סיבית מעריך היא 0, מנטיסה של כל אפס היא אפס (חיובי או שלילי בהתאם לסיבית הסימן) ומנטיסה שאינה אפס היא מספר תת-נורמלי הממיר מתייג עבורך כל אחד מהמקרים הללו.
האם זה בטוח להשתמש בכלי זה עבור מספרים רגישים?
כן ההמרה פועלת כולה ב-JavaScript בדפדפן שלך שום בקשת רשת לא נושאת את הקלט שלך, שום דבר לא מאוחסן, והכלי עובד במצב לא מקוון לאחר טעינת הדף, כך שכל ערך שתזין נשאר במכשיר שלך.
לאיזה פורמט hex מצפה הממיר?
ספרות הקסדצימליות רגילות, עם קידומת 0x אופציונלית ורווחים או קווים תחתונים לקיבוץ, שמתעלמים מהם דיוק יחיד מצפה ל-8 ספרות משושה ודיוק כפול מצפה ל-16. לדוגמה, 40490FDB הוא pi בעל דיוק יחיד (3.1415927).
חקור את החלקים בעצמך עם החינם ממיר IEEE 754. הוא מקודד ומפענח צפים דיוק יחיד וכפול כולו בדפדפן שלך, בלי שום דבר שהועלה.
