Getallen

In het moderne JavaScript zijn er twee soorten getallen:

1. Reguliere getallen in JavaScript worden opgeslagen in het 64-bits formaat IEEE-754, ook wel bekend als “double precision floating point numbers”. Dit zijn de getallen die we het meest gebruiken, en we zullen het er in dit hoofdstuk over hebben.

2. BigInt getallen, om gehele getallen van willekeurige lengte weer te geven. Ze zijn soms nodig, omdat een gewoon getal niet groter kan zijn dan 253 of kleiner dan -253. Omdat bigints op enkele speciale gebieden worden gebruikt, wijden we ze aan een speciaal hoofdstuk BigInt.

Dus hier gaan we het hebben over reguliere getallen. Laten we onze kennis ervan uitbreiden.

Meer manieren om een getal te schrijven

Stel je voor dat we 1 miljard moeten schrijven. De voor de hand liggende manier is:

let billion = 1000000000;

We kunnen ook underscore _ als scheidingsteken gebruiken:

let billion = 1_000_000_000;

Hier speelt de underscore_de rol van de “syntactische suiker”, het maakt het getal leesbaarder. De JavaScript engine negeert gewoon_tussen de cijfers, dus het is precies hetzelfde miljard als hierboven.

In het echte leven proberen we echter te vermijden lange reeksen nullen te schrijven. Daar zijn we te lui voor. We zullen proberen iets te schrijven als "1bn" voor een miljard of "7.3bn" voor 7 miljard 300 miljoen. Hetzelfde geldt voor de meeste grote getallen.

In JavaScript kunnen we een getal inkorten door er de letter "e" aan toe te voegen en het aantal nullen op te geven:

let billion = 1e9; // 1 billion, literally: 1 and 9 zeroesalert( 7.3e9 ); // 7.3 billions (same as 7300000000 or 7_300_000_000)

In andere woorden,evermenigvuldigt het getal met1met het gegeven aantal nullen.

1e3 = 1 * 1000 // e3 means *10001.23e6 = 1.23 * 1000000 // e6 means *1000000

let ms = 0.000001;

Net als eerder kan het gebruik van "e" helpen. Als we de nullen niet expliciet willen schrijven, kunnen we hetzelfde zeggen als:

let ms = 1e-6; // six zeroes to the left from 1

Als we de nullen tellen in 0.000001, dan zijn dat er 6. Dus is het natuurlijk 1e-6.

Met andere woorden, een negatief getal na "e" betekent een deling door 1 met het gegeven aantal nullen:

// -3 divides by 1 with 3 zeroes1e-3 = 1 / 1000 (=0.001)// -6 divides by 1 with 6 zeroes1.23e-6 = 1.23 / 1000000 (=0.00000123)

alert( 0xff ); // 255alert( 0xFF ); // 255 (the same, case doesn't matter)

let a; // binary form of 255let b = 0o377; // octal form of 255alert( a == b ); // true, the same number 255 at both sides

let num = 255;alert( num.toString(16) ); // ffalert( num.toString(2) ); // 11111111

let num = 12.36;alert( num.toFixed(1) ); // "12.4"

let num = 12.34;alert( num.toFixed(5) ); // "12.34000", added zeroes to make exactly 5 digits

We kunnen het omzetten in een getal met behulp van de unary plus of een Number() oproep: +num.toFixed(5).

Onnauwkeurige berekeningen

Intern wordt een getal weergegeven in het 64-bits formaat IEEE-754, dus er zijn precies 64 bits om een getal op te slaan: 52 daarvan worden gebruikt om de cijfers op te slaan, 11 daarvan slaan de positie van de decimale punt op (ze zijn nul voor gehele getallen), en 1 bit is voor het teken.

Als een getal te groot is, zou het de 64-bits opslagruimte overlopen, wat mogelijk een oneindigheid oplevert:

alert( 1e500 ); // Infinity

Wat misschien iets minder voor de hand ligt, maar wel vaak voorkomt, is het verlies van precisie.

Bedenk deze (vals!) test:

alert( 0.1 + 0.2 == 0.3 ); // false

Dat is juist, als we controleren of de som van 0.1 en 0.20.3 is, krijgen we false.

Schrikbarend! Wat is het dan als het niet 0.3 is?

alert( 0.1 + 0.2 ); // 0.30000000000000004

Ouch! Er zijn hier meer gevolgen dan een onjuiste vergelijking. Stel je voor dat je een e-shopping site maakt en de bezoeker legt $0.10 en $0.20 goederen in zijn winkelwagen. Het totaal van de bestelling zal $0.30000000000000004 zijn. Dat zou niemand verbazen.

Maar waarom gebeurt dit?

Een getal wordt in het geheugen opgeslagen in zijn binaire vorm, een opeenvolging van bits – enen en nullen. Maar breuken zoals 0.10.2 die er in het decimale getallensysteem eenvoudig uitzien, zijn in feite oneindige breuken in hun binaire vorm.

Met andere woorden, wat is 0.1? Het is één gedeeld door tien 1/10, een tiende. In het decimale getallenstelsel zijn dergelijke getallen gemakkelijk weer te geven. Vergelijk het met eenderde: 1/3. Het wordt een eindeloze breuk 0.33333(3).

Deling door machten 10 werkt dus gegarandeerd goed in het decimale stelsel, maar deling door 3 werkt dat niet. Om dezelfde reden werkt in het binaire getallenstelsel deling door machten van 2 gegarandeerd, maar 1/10 wordt een eindeloze binaire breuk.

Er is gewoon geen manier om precies 0.1 of precies 0.2 op te slaan met het binaire systeem, net zoals er geen manier is om een derde op te slaan als een decimale breuk.

Het numerieke formaat IEEE-754 lost dit op door af te ronden naar het dichtstbijzijnde mogelijke getal. Door deze afrondingsregels zien we dat “kleine precisieverlies” normaal gesproken niet, maar het bestaat wel.

We kunnen dit in actie zien:

alert( 0.1.toFixed(20) ); // 0.10000000000000000555

En als we twee getallen optellen, tellen hun “precisieverliezen” bij elkaar op.

Daarom is 0.1 + 0.2 niet precies 0.3.

Kunnen we het probleem omzeilen? Zeker, de meest betrouwbare methode is om het resultaat af te ronden met behulp van een methode toFixed(n):

let sum = 0.1 + 0.2;alert( sum.toFixed(2) ); // 0.30

Merk op dat toFixed altijd een string teruggeeft. Het zorgt ervoor dat het 2 cijfers achter de komma heeft. Dat is eigenlijk handig als we een e-shopping hebben en $0.30 moeten tonen. Voor andere gevallen kunnen we de unary plus gebruiken om er een getal van te maken:

let sum = 0.1 + 0.2;alert( +sum.toFixed(2) ); // 0.3

We kunnen de getallen ook tijdelijk met 100 (of een groter getal) vermenigvuldigen om er gehele getallen van te maken, de wiskunde doen, en dan terug delen. Omdat we dan met gehele getallen rekenen, neemt de fout iets af, maar we krijgen hem nog steeds bij het delen:

alert( (0.1 * 10 + 0.2 * 10) / 10 ); // 0.3alert( (0.28 * 100 + 0.14 * 100) / 100); // 0.4200000000000001

Dus, de vermenigvuldigen/vermenigvuldigen aanpak vermindert de fout, maar neemt hem niet helemaal weg.

Soms kunnen we proberen om breuken helemaal te vermijden. Als we bijvoorbeeld te maken hebben met een winkel, dan kunnen we de prijzen in centen opslaan in plaats van in dollars. Maar wat als we een korting van 30% toepassen? In de praktijk is het zelden mogelijk om breuken volledig te omzeilen. Rond ze gewoon af om “staartjes” af te snijden als dat nodig is.

// Hello! I'm a self-increasing number!alert( 9999999999999999 ); // shows 10000000000000000

Tests: isFinite en isNaN

Herken je deze twee speciale numerieke waarden nog?

• Infinity (en -Infinity) is een speciale numerieke waarde die groter (kleiner) is dan iets.
• NaN staat voor een fout.

Ze behoren tot het type number, maar zijn geen “normale” getallen, dus zijn er speciale functies om ze te controleren:

• isNaN(value) converteert zijn argument naar een getal en test dan of het NaN is:

  alert( isNaN(NaN) ); // truealert( isNaN("str") ); // true

  Maar hebben we deze functie nodig? Kunnen we niet gewoon de vergelijking === NaN gebruiken? Sorry, maar het antwoord is nee. De waarde NaN is uniek in die zin dat het aan niets gelijk is, ook niet aan zichzelf:

  alert( NaN === NaN ); // false

• isFinite(value) converteert het argument naar een getal en geeft true terug als het een gewoon getal is, niet NaN/Infinity/-Infinity:

  alert( isFinite("15") ); // truealert( isFinite("str") ); // false, because a special value: NaNalert( isFinite(Infinity) ); // false, because a special value: Infinity

Soms wordt isFinite gebruikt om te valideren of een string waarde een regulier getal is:

let num = +prompt("Enter a number", '');// will be true unless you enter Infinity, -Infinity or not a numberalert( isFinite(num) );