חידון: האם אפשר לספור על JavaScript?

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

באופן כללי, parseInt מפסיק לנתח כאשר הוא נתקל בתו שאינו מספרי. כאן, הוא עוצר בפסיק, ולכן רק 123 מוחזר.

בגלל שגיאות דיוק של נקודה צפה, 0.1 + 0.2 לא שווה בדיוק ל-0.3. בשל האופן שבו מספרי נקודה צפה מאוחסנים בזיכרון, התוצאה היא 0.30000000000000004. תקן IEEE 754 לטיפול בחשבון נקודה צפה הוא האשם – הוא לא יכול לייצג חלק מהמספרים בדיוק מוחלט. זו בעיה נפוצה בכל שפות התכנות. בסופו של דבר תתקלו בשבר עשרוני אינסופי, והמחשב פשוט חייב להפסיק לרדוף אחרי ספרות אינסופיות.

שפות כמו Python ו-Java כוללות Decimal או BigDecimal לטיפול בזה, אבל זה לא מובנה ב-JavaScript. אפשר להשתמש בספריות כמו big.js או decimal.js כדי לטפל במקרים כאלה.

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

מכיוון ש-Number.MAX_VALUE הוא המספר הרגיל הגדול ביותר שניתן לייצוג ב-JavaScript, חריגה מהגבול שלו תגרום לגלישה מהירה - בעצם אתה עלול לראות תוצאות חסרות משמעות. הכפלתו ב-2 מביאה ל-Infinity.

אתה יודע, JavaScript ככה לפעמים.

.toFixed(2) מחזירה ייצוג מחרוזת של 5 עם שתי ספרות עשרוניות, כך שהתוצאה היא "5.00".

הנקודה הכפולה (5..toFixed(2)) היא ‘טריק’ לגישה למודל האובייקט של ליטרלים מספריים.

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

BigInt הוא טיפוס שונה מ-number, לכן parseInt("42") (מספר רגיל) אינו שווה בקפדנות ל-BigInt("42"). כדי להשוות, עליך להמיר את שניהם לאותו טיפוס: BigInt(parseInt("42")) === BigInt("42").

כל מחרוזת קלט שמתחילה ב-0x מטופלת אוטומטית כהקסדצימלית (בסיס 16). לכן זה שקול להעברת בסיס 16. אז parseInt("0x2A") זהה ל-parseInt("2a", 16). (זה לא תלוי רישיות.)

parseInt עם בסיס הקסדצימלי (16) ממיר את "FF" ל-255 בעשרוני. אולי ראית את זה בקודי צבע RGB/Hex ב-CSS.

הארגומנט השני של parseInt (ה-radix) מתיישר עם ארגומנט ה-index של מתודות המערך. זה מוביל לתוצאות בלתי צפויות, מכיוון ש-parseInt("One", 1) מחזיר NaN עקב קלט לא תקין.

האלמנט הראשון, 24, מפורש כ-24 בבסיס 0 (זיהוי אוטומטי), כך שהוא נשאר 24. האלמנט השני, 'One', מפורש כ-NaN בבסיס 1. האלמנט השלישי, 42, מפורש בבסיס 2. בבסיס 2, '42' הוא NaN, ולכן התוצאה היא [24, NaN, NaN].

זוהי מלכודת נפוצה עם parseInt ו-map. אם ברצונך לפרש מערך של מחרוזות למספרים, השיטה הבטוחה היחידה “המובנית” היא .map(Number) או הוספת callback/closure .map(x => parseInt(x, 10)).

Number ממיר ערכים לסוג מספרי בצורה מחמירה יותר מ-parseInt. כאן, 'Twenty1' הופך ל-NaN, בעוד 0o42 מוכר כליטרל אוקטלי ומומר ל-34.

parseInt מאלץ את הקלט למחרוזת, כך ש-null הופך ל-"null". מכיוון של-"null" אין תווים חוקיים בבסיס 10 (מספרים רגילים), הוא יחזיר NaN.

Number(null) מחזיר 0, כי JS אוהבת להפתיע אותך. למה? ובכן, אולי ארחיב אם יהיה עניין.

מאחר ש-parseInt תמיד ממיר את הקלט למחרוזת, null הופך למחרוזת "null".

בבסיס 36 (הקסאטריג’יסמל, אם אתם עוקבים), המחרוזת "null" מייצגת 1112745.

הערכים הרציפים של nulk, null, ו-nulm הם בהתאמה 1112744, 1112745, ו-1112746 בבסיס 36.