Overleg:Zwevendekommagetal

Associatief, distributief en afrondingsfouten.

Het engelse artikel stelt:

While floating-point addition and multiplication are both commutative (a + b = b + a and a×b = b×a), they are not necessarily associative. That is, (a + b) + c is not necessarily equal to a + (b + c).

en:floating point schrijft dit (terecht) toe aan afrondfouten. Zoals het echter in de nederlandse versie staat, lijkt de eigenschap geheel over boord te zijn gegaan. Tevens kom ik in de belangrijke waarde $\epsilon$ niet tegen, die er voor bedoeld is dit soort effecten tegen te gaan. Want als rekening wordt gehouden met de rounding error zijn fp optellingen en vermenigvuldigingen (binnen de grenzen van de natuurlijke precisie van de fp-definitie) wel degelijk distributief, assiociatief en communicatief, Kleuske 1 nov 2008 11:52 (CET)

Bron? --BDijkstra 1 nov 2008 14:49 (CET)

Structured Computer Organisation, Andrew S. Tanenbaum, Prentice/hall, 1984, Appendix 2, Floating Point Numbers. En natuurlijk het college getalsystemen, een inleiding, maar da's lang geleden. Ik heb overigens in bovenstaande tekst mijzelf iets duidelijker uitgedrukt. Als je een momentje hebt, pak ik Knuth even. Effuh kijkuh... The Art of Computer Programming, volume 2, Seminumerical Algorthms, Third Edition, Donald A. Knuth, Addison Wesley, 1998:pp. 232, 242, 698 en 718. Kleuske 1 nov 2008 17:06 (CET)

Dat zou toch ook al te dwaas zijn. Het zijn niet zomaar eigenschappen waar je over praat. Als fp-getallen helemaal niet communicatief waren, zouden normale berekening bijna niet meer lukken. Wat bedoeld wordt is dat bij iederebewerking (optellen, aftrekken, delen, vermenigvuldigen) er automatisch een fout in het resultaat sluipt. Hoe groot die fout maximaal is, kun je berekenen en vervolgens kies je een waarde voor epsilon ('$\epsilon$'), zodanig dat die gegarandeerd boven de maximale fout zit en je hebt een maat voor de precisie van je berekening (hoeveel decimalen mag ik gebruiken, een standaard natuurkunde annex meet- en regeltechniekvraag). In dit hele verhaal maakt het inderdaad wel uit hoe de volgorde van berekenen is, en kun je wel twijfelachtig naar die eigenschappen kijken, maar boven die grens gedragen ze zich gewoon volgens het wiskundige boekje. Hoe denk je dat een spreadsheet dat doet?

Die epsilon ( of $\epsilon ^{2}$ in 2-D) is overigens het belangrijkst als je twee floats met elkaar vergelijkt. Als je daar _GEEN_ rekening houdt met die fout, krijg je rare dingen. arcsin(sin(M_PI/3))*3 geeft zelden of nooit M_PI als uitkomst. dus if(arcsin(sin(M_PI/3))*3 == M_PI) doet zelden of nooit wat het wiskundig eigenlijk zou moeten doen. Kleuske 1 nov 2008 17:32 (CET)

Correctie: if(arcsin(sin(M_PI/3))*3 == M_PI) doet precies wat het wiskundig eigenlijk zou moeten doen, anders zit er een bug in de hardware. Het doet echter niet wat de leek zou verwachten, als deze geen rekening houdt met het verschil tussen wiskundige operatoren en programmeer-operatoren.(1) En natuurlijk is fp vaak genoeg assiociatief of zo dicht bij assiociatief dat het verschil niet van belang is, maar als je strikt wiskundig kijkt naar de kans op assiociativiteit voor een willekeurige berekening, denk ik dat je vrij laag uit zal komen(2). Het artikel zou hier inderdaad best wel wat praktischer mee mogen om gaan wat mij betreft. --BDijkstra 1 nov 2008 20:20 (CET)

(1)Zucht... Nee. Als het precies doet wat je er wiskundig van verwacht, zou deze constructie niet VERBODEN zijn. Het probleem is juist dat je NIET WEET wat het ding doet. Het is heel goed mogelijk dat de ENE compiler/library/CPU/FPU combinatie TRUE terug geeft en de ANDERE combinatie FALSE. Dat was het punt van het hele betoog: uitleggen dat er een verschil is tussen programmeer operatoren (noch sin() noch arcsin() zijn overigens operatoren, maar functies, en JA er is een verschil) en de zuiver wiskundige definitie. En overigens is dit stukje geschreven in C, C++, Java en/of D, dus de "hardware" heeft er geen hout mee te maken. Da's weer een verdieping lager. Niet iedere platform heeft tenslotte hardware floats. Not all the world's an Intel Pentium, zoals dat onder programmeurs heet.

Ik neem overigens aan dat je m'n bronnen inmiddels hebt nagetrokken? Niet? Waarom VRAAG je er dan naar? Ik bedoel, een KENNER zoals jij heeft toch vast wel een Knuth en een (misschien wat recentere) Tanenbaum op de plank staan. Het zijn tenslotte geen obscure werkjes die ik noem.Kleuske 2 nov 2008 09:41 (CET)

Zucht... Ja. Het doet precies wat het wiskundig eigenlijk zou moeten doen; met een debugger kan je precies zien wat er gebeurt als die constructie uitgevoerd wordt (en met de juiste specificaties kan je alles wiskundig afleiden). Afhankelijk van hoeveel je weet over comp/lib/CPU/FPU doet het al dan niet precies wat je er wiskundig van verwacht. Ik snapte je punt dat er een verschil is tussen wiskunde en praktijk, maar om te claimen dat er geen verschil zou moeten zijn, vond ik iets te ver gaan, vandaar. --BDijkstra 2 nov 2008 23:39 (CET)

Oh Heer, sta ons bij. "Met een debugger kan je precies zien..." Even kort en goed. Als je een debugger nodig hebt om te zien wat het ding doet, doet het wiskundig NIET wat je ervan verwacht. Als dat namelijk WEL het geval was, had je geen debugger nodig. Als je wel een debugger nodig hebt om te zien wat je programma doet, zit je dik in de problemen en heb je (softwarematig) heel wat uit te leggen. Als je deze stelling in een professionele omgeving verkondigt, wordt je de tent uitgelachen. En volstrekt terecht, mag ik daar aan toevoegen. Een stuk code dat zich op platform A anders gedraagt dan op platform B is onvoorspelbaar, aangezien je NOOIT precies weet op welk platform je code zal draaien. Dit specifieke geval kan nog per INTEL-FPU anders zijn, om maar eens een merk te noemen. Wat niemand haalt het in zijn hoofd daar garanties op te geven, zelfs "Our latest model is backward-compatible to a 8086"-Intel is niet zo dwaas.

(persoonlijke aanval verwijderd)Kleuske 4 nov 2008 09:30 (CET)

PS. Apropos recentere Tanenbaum: "Gestructureerde Computerarchitectuur", Andrew S. Tanenbaum, 4e oplage, 1997, Academic Service, Schoonhoven, 1997, Appendix B: Floating Point getallen,p 677 e.v., en ik begin benieuwd te worden wat de ISOC89/C99 standaard over dit onderwerp te zeggen heeft, om nnog maar te zwijgen van IEEE-754. Kleuske 2 nov 2008 10:16 (CET)

Excuus, ik bedoel natuurlijk IEC 60559. Kleuske 2 nov 2008 10:20 (CET)

(2) Ik wacht met spanning op uw berekening. Graag voor 32, 64 en (long double onder GCC op een 64-bit AMD) 128 bit floats. Succes! (Hint bereken "$\epsilon$")Kleuske 2 nov 2008 09:49 (CET)

Volgens mijn berekeningen is de kans dat een 32-bits vermenigvuldiging van drie willekeurige 32-bits binaire normale (niet-gedenormaliseerde) IEEE-754-getallen volledig associatief is, ongeveer 1/8 of 12%. Maar de relevantie van exacte cijfers en wiskundige bewijzen hieromtrent ontgaat me, evenals het punt dat je waarschijnlijk wilt maken. --BDijkstra 3 nov 2008 23:01 (CET)

Laat je "berekening" dan maar eens zien. Want na het bovenstaande ben ik niet geneigd je op je woord te geloven. Sterker nog... Ik had eigenlijki een beetje een functie verwacht want de precisie van een float (elke float) is afhankelijk van dee waarde die je erin stopt. Alleen de RELATIEVE fout is (zo ongeveer) constant. In ieder geval verwacht ik een specificatie van float die wat hechter doortimmerd is dan "32-bit". Hoeveel bits in de matissa? Wel of geen guard-digits? Wat is je $\epsilon$? Kleuske 4 nov 2008 09:45 (CET)

(2 bis) Pak een zakjapanner of een spreadsheet en bereken 3.0*(4.0/3.0) en (3.0*4.0)/3.0 en vertel me de uitkomst (zoals het op het display verschijnt). Kleuske 2 nov 2008 09:56 (CET)

Uiteraard komt hier allebei precies 4.0 uit. Maar hier is het prima verklaarbaar waarom: 4/3 wordt naar boven afgerond en de afrondingsfout verdwijnt (schuift naar buiten) bij vermenigvuldiging, en 12 is gewoon deelbaar door 3. Leukere dingen krijg je als je bv. 4/3 uitrekent in lage precisie en vermenigvuldigt met 3 in hoge precisie. --BDijkstra 3 nov 2008 23:01 (CET)

En dat de gemiddelde zakjapanner een aantal (vaak drie) cijfers voor je verborgen houdt is nieuw voor je? Dat dit (flauwe) afronden nou juist een essentieel onderdeel is van het hele gebeuren is nog niet tot je doorgedrongen? Heb je inmiddels de bron die bij het artikel staat (what every computer scientist should know about floating point numbers) al GELEZEN? Kleuske 4 nov 2008 09:45 (CET)

Ah... ISO-8988 (ISO C99) Appendix F heeft het er uitgebreid over.

x − y ↔ x + (−y) The expressions x − y, x + (−y), and (−y) + x are equivalent (on IEC 60559 machines, among others).

— ISO/IEC 9899

En ja. Het waarschuwt uitgebreid voor rounding errors

x − y ↔ −(y − x) The expressions x − y and −(y − x) are not equivalent because 1 − 1 is +0 but −(1 − 1) is −0 (in the default rounding direction)

— ISO/IEC 9899

The implementation cannot generally apply the mathematical associative rules for addition or multiplication, nor the distributive rule, because of roundoff error, even in the absence of overflow and underflow.

— ISO/IEC 9899

En voor die rounding errors kun je een maximum uitrekenen voor een gegeven berekening. Met 80 of 128 bits is dat vrij klein. Dus $\epsilon$ is klein, dus mag je veel decimalen gebruiken,

Een propere vergelijking voor floats (in de ruimste zin des woords) luidt:

if (::abs(x - y) < MY_APP_EPSILON) { .... } else { .... }

Kleuske 2 nov 2008 10:45 (CET)

Ik snap het gewoon niet...

Er staat een pracht van een bron in de bibliografie. Leest iemand dat soort dingen wel eens?

In particular, the relative error corresponding to .5 ulp can vary by a factor of $\beta$. This factor is called the wobble. Setting $\epsilon =(\beta /2)*\beta ^{-p}$ to the largest of the bounds in (2) above, we can say that when a real number is rounded to the closest floating-point number, the relative error is always bounded by e, which is referred to as machine epsilon

— What Every Computer Scientist Should Know About Floating-Point Arithmetic, het vetgedrukte is van mij

. Kleuske 2 nov 2008 11:14 (CET)

Ik wil het niet eens snappen, geloof ik. Maar ik vermoed dat er verwezen wordt naar het feit dat zo iets simpels als een vijfde ofwel 0.2 niet nauwkeurig binair opgeslagen (zo men wil: weergegeven) kan worden.

Ѕіmоn dе Dаnѕеr 23 mrt 2010 03:03 (CET)

Gruwelijk anglicisme!

Wat is dit een ongelooflijk bekrompen artikel! Wat hier met het anglicisme(!) "drijvendekommagetal" wordt aangeduid, heet al sinds eeuwen(!) in gewoon Nederlands een "zwevendekommagetal"! Engels "to float" kan zowel "drijven" als (in bepaalde gevallen) "zweven" betekenen. Maar zodra computerlieden zich ermee bemoeien, vergeet men ineens dat we een eigen moedertaal hebben, die ook dergelijke termen bevat. Er wordt zomaar stilzwijgend van uitgegaan dat het een typische computerterm is, en men vergeet dat de kreet "zwevende komma" al weet-ik-hoelang bestaat, lang voordat de eerste computer verscheen.

Ik zal de komende dagen proberen het artikel wat op te kalefateren, maar het kan zijn dat ik er wat diepgaandere wijzigingen in moet aanbrengen. Dus even geduld met commetaar alstublieft!

--HHahn (overleg) 4 okt 2009 15:25 (CEST)

Ik heb het inmiddels aangepast (ook de verwijzingen naar deze pagina), maar ik vind het nog wel een beetje lapwerk.

Een algemene vraag die ik alle wikipedianen zou willen voorleggen, is: Voor wie schrijven we eigenlijk? Voor deskundigen (die het toch al weten en er dus geen encyclopedie voor nodig hebben), of voor leken? In dat laatste geval – wat m.i. het juiste is – moeten we dus ook voor leken begrijpelijk schrijven, want anders schieten we ons doel voorbij!

--HHahn (overleg) 4 okt 2009 17:12 (CEST)

Ik ken eigenlijk voornamelijk de term "drijvende komma". In een oudere encyclopedie komt deze term wel voor en de term "zwevende komma" niet. Met Anglicismen heeft het volgens mij niets te maken. Float betekent zowel drijven als zweven. Madyno 5 okt 2009 19:05 (CEST)

Inderdaad kun je discussiëren over de vraag of het in letterlijke zin aan de definitie van een "anglicsme" voldoet. Maar daar gaat het helemaal niet om. Waar het om gaat is dat uit de twee mogelijke vertalingen een keus is gemaakt die geheel voorbij gaat aan het reeds bestaan van een Nederlandse term voor het bedoelde begrip.

Een "oude encyclopedie" zegt op zich niet zoveel. Hoe oud is "oud"? Waar het hier om gaat, is dat vóórdat de computer en de daarmee opkomende Engelse termen kwamen, er reeds lang een Nederlandse term voor bestond, nl. "zwevende komma". Maatgevend zou bovendien niet een encyclopedie moeten zijn, maar vakliteratuur, leerboeken etc. van bijvoorbeeld vóór de Tweede Wereldoorlog. Natuurwetenschappen, numerieke wiskunde, etc., bestonden toen al lang, en de bedoelde notatiewijze werd toen dus ook al gebruikt.

Strikt genomen is het trouwens helemaal niet nodig om een van de vertalingen van het Engelse woord (in dit geval dus van 'float') te gebruiken. Het zou net zo goed iets als "schuivende komma" of zo hebben kunnen heten. Het gaat erom dat er géén nodeloos letterlijke vertaling gekozen wordt als er al een Nederlandse term voor is. Het schijnt typisch Nederlands te zijn om de eigen taal te verwaarlozen en maar aan te rotzooien met al dan niet krom "overgezette" vreemde woorden. In de computerwereld gebeurt dat heel sterk, maar elders ook steeds meer.

--HHahn (overleg) 5 okt 2009 19:57 (CEST)

Waarom niet vlottende komma zoals ik het op school leerde? Ѕіmоn dе Dаnѕеr 23 mrt 2010 03:13 (CET)

Ik opper inderdaad ook voor de term vlottende komma, die term heb ik ook aangeleerd op school. Henridv (overleg) 31 mei 2012 23:13 (CEST)

Tot mijn verbazing noemt het WNT het woord vlotten ook in de betekenis "drijven". Ik ken het in die betekenis alleen uit de boekhouding: "vlottende activa". Voor de rest geldt wat ik hierboven al schreef: We hebben al vele jaren voordat de eerste computer kwam, het woord zwevende komma. Wat is daar mis mee dat het ineens vervangen zou moeten worden? Ziet het er "niet Engels genoeg" uit? Nee, natuurlijk net, want het is Nederlands! En het heeft al eeuwen de hier bedoelde betekenis! Gewoon nuchter blijven dus. » HHahn (overleg) 1 jun 2012 16:24 (CEST)

Ook nooit gehoord van de vlotter in het waterreservoir van je toilet? --BDijkstra (overleg) 1 jun 2012 19:31 (CEST)

O ja, inderdaad. Maar dat neemt nog steeds niet weg dat de term "zwevende komma" in het Nederlands aanzienlijk ouder is dan de eerste computer. » HHahn (overleg) 2 jun 2012 14:02 (CEST)

Ik studeer aan de KULeuven en heb ook alleen nog maar vlottendekommagetal gehoord. Misschien is dit niet de originele Nederlandstalige benaming maar ik denk dat ze gangbaar genoeg is om in het artikel vermeld te worden. Ook vind ik het iets of wat vreemd dat we voor de benaming naar bronnen van voor de Tweede Wereldoorlog zouden moeten kijken, voor zover ik weet bestonden er toen nog geen computers die met zulke getallen werkten en dit artikel gaat toch net over de getalvoorstelling op computers? 2A02:1810:4412:5B00:4437:5056:9BBC:B8D6 8 aug 2015 22:26 (CEST)(tacit)

"Getal" is niet hetzelfde als "cijfer"!

Herhaaldelijk kom ik kreten tegen als "getallen achter de komma" e.d. Een getal is een variabele of een constante. die een waarde heeft, die uitgedrukt kan worden in 1 of meer cijfers. Het decimale stelsel heeft tien cijfers (0, 1, ..., 9), het hexadecimale heeft er zestien (0, 1, ..., 9, A, B, ..., F), het octale acht (0, 1, ..., 7), etc. De begrippen "getal" en "cijfer" dienen duidelijk onderscheiden te worden!

In enkele gevallen heb ik dit gecorrigeerd, dus lang niet overal.

--HHahn (overleg) 4 okt 2009 19:45 (CEST)

Gruwelijk anglicisme! (2)

Misschien de titel gewoon veranderen naar "Floating Point getal", i.p.v. een belachelijke vertaling te bedenken voor elke computerterm! Als ik naar het Nederlandstalige artikel over Floating Points op zoek ben, komt het nog niet in de verste verte bij mij op om te zoeken naar Zwevendekommagetal! Stop met het vertalen van computertermen en leer Engels! Zelfs de Fransen hebben het vertalen van computertermen opgegeven omdat dit niet vol te houden was, en dat wil al wat zeggen! Bedenk maar eens een Nederlandse term voor "to update": Opdatummen?! Nee, iedereen is het ermee eens dat dit belachelijk is, we zeggen gewoon updaten. Zo zeggen we vanaf nu ook Floating Point getal.
– De voorgaande bijdrage werd geplaatst door 79.132.232.126 (overleg · bijdragen) 20 feb 2010 12:41 (CET)

Helemaal mee eens. Kleuske 20 feb 2010 15:19 (CET)

Deze redenering is juist als het om nieuwe termen gaat. En van nieuwe termen staat een jong vukgebied als informatica uiteraard helemaal bol!

Hier gaat het echter om een term die al vele jaren, zo niet een paar eeuwen, bestaat. En dat velen niet op het idee komen om een term als "zwevende komma" op te zoeken, is een gevolg van de gemakzucht waarmee de meeste mensen een Engelse term zomaar overnemen zonder zoch af te vragen of er niet allang(!) een Nederlands term voor bestaat.

Bovendien kun je in dit concrete geval zeggend at de betekenis ook een rol speelt. Inderdaad betekent float zowel drijven als zweven. Echter, als een voorwerp drijft, blijft het altijd op hetzelfde niveau, nl. dat van de vloeistof waarop het drijft. Als iets zweeft, kan het altijd nog van hoogte veranderen. Denk aan een zweefvliegtuig, een luchtballon, etc. Dat het Engels daarvoor hetzelfde woord gebruikt, wil nog niet zeggen dat het ook hetzelfde begrip is!

(En wat "update" betreft: Heel veel vertaalde software gebruikt hiervoor in zijn menu's allang de term "bijwerken". Niemand die daarover klaagt.)

HHahn (overleg) 20 feb 2010 17:17 (CET)

Hoelang de term zwevendekommagetal bestaat, weet ik niet, maar het gegevenstype waarover dit artikel gaat bestaat pas sinds de late jaren zestig en wordt in mijn ervaring nooit als zwevendekommagetal aangeduid, maar als float of floating point getal. Het is toch waarachtig niets nieuws dat jargon vaak op talen anders dan de nederlandse gebaseerd is. Da's al ouder dan het woord zwevendekommagetal. Kleuske 9 mrt 2010 00:24 (CET)

Begripsafbakening...

Voor de verhandeling over de Wetenschappelijke notatie en Reëele getallen hebben we andere artikelen. Dit artikel gaat specifiek over het gegevenstype in de computer wereld en had eigenlijk gewoon floating point moeten heten. Kleuske 20 feb 2010 15:06 (CET)

Een artikel dat zo goed als onleesbaaris geworden, door de taalverherbouwingen van ellenlangewoordenbrijtaalpuristenbrigade. Waarvoor dank. Kleuske 20 feb 2010 15:17 (CET)

Ik stel voor dit artikel "Floating point getal" te noemen, en de term "zwevende ... " te reserveren voor de normale decimale weergave met exponent.Madyno 23 feb 2010 20:20 (CET)

Helaas: "floating point getal" is nòch Nederlands, nòch Engels. De juiste Nederlandse schrijfwijze moet hier zijn "floatingpointgetal" (zie http://woordenlijst.org/leidraad/12/1/, http://www.onzetaal.nl/advies/langeafstandsloper.php en Engelse ziekte (taal)).

Het onderscheid dat Madyno hier voorstelt, is wat kunstmatig. In het Engels heten beide "floating point number". En er is ook geen enkele reden waarom je per se twee verschillende termen zou moeten hebben. Wij onderscheiden "geheel getal" (getalsoort) en "integer" (gegevenstype in informatica), terwijl het Engels beide "integer" noemt.

Een onderscheid dat we wél moeten maken, is tussen de terminologie in strikte zin (dus de naam van de getalsoort) en het "keyword" dat een bepaalde programmeertaal er toevallig voor gebruikt. Er is geen enkele garantie dat alle huidige en toekomstige programmeertalen hetzelfde keyword "floating point" of "float" zullen gebruiken. Ik meen dat ik inderdaad wel eens "real" als keyword ben tegengekomen. We moeten hier dus de gangbare term gebruiken. En die is in het Engels "floating point number" (juistere schrijfwijze zou overigens "floating-point number" zijn), en in het "Nederlands" "floatingpointgetal" (zie bovengenoemde link), of in echt Nederlands, jawel, "zwevendekommagetal".

Bovendien: Een keyword voor een bepaald gegevenstype als lemma opnemen is alleen zinvol als je dat ook met alle gangbare soortgenoten doet. Dus ook int, integer, uint, unsigned integer, real, en ga zo maar door. Een hele klus (want: welke programmeertalen wel en welke niet meenemen?), en de vraag of het zinvol is. Welke niet-deskundige komt die afzonderlijke termen nou tegen? Ze worden vrijwel nooit buiten de alleen voor deskundigen gangbare context gebruikt.

HHahn (overleg) 24 feb 2010 11:09 (CET)

Ik had noch niet nagedacht over de schrijfwijze van de NL vorm van "floating(-)point mumber". Ik hou zeker niet van de "Engelse ziekte", dus "floatingpointgetal" lijkt me prima. Vasthouden aan de benaming "zwevende..." lijkt me niet erg zinnig.Madyno 26 feb 2010 12:58 (CET)

Vasthouden aan een term die al weet-ik-hoe-lang bestond voordat de eerste computer ook maar bedacht was, vindt u dus niet zinnig?? HHahn (overleg) 26 feb 2010 13:18 (CET)

In een artikel dat zeer specifiek over een gegevens-type (en dus NIET over wetenschappelijke notatie, Reeele getallen of anderzins) gaat niet, nee... Kleuske 9 mrt 2010 00:19 (CET)

Ik probeerde hierboven (onder ditzelfe kopje, op 24 febr. 2010) al aan te geven dat er voor de type specifier niet één standaardterm bestaat, maar dat iedere programmeertaal daar zijn eigen kreet voor gebruikt. Dat tegenwoordig float vaak voorkomt, komt door de invloed van "C" en daarvan afgeleide talen. Maar andere talen hebben er weer andere kreten voor. Het is, zoals ik al schreef, ondoenlijk (en zinloos, want erg specialistisch) om voor elke variant een eigen lemma te maken. Het zal dus zinvol zijn een "verzamelterm" hiervoor te gebruiken.

Welnu, al deze varianten van het betreffende gegevenstype komen allemaal neer op representaties van de "scientific notation", die in het Nederlands al sinds weet-ik-hoe-lang "zwevendekommanotatie" heet, of met een anglicisme(!) "wetenschappelijke notatie" ("science" = (meestal) natuurwetenschappen!). Juist om deze reden acht ik het zinvol, de neutrale wiskundige term "zwevendekommagetal" te gebruiken als verzamelbegrip. De getalwaarde is dan een zwevendekommagetal, terwijl het daarvoor te gebruiken gegevenstype, afhankelijk van de gehanteerde programmeertaal, bijvoorbeeld float, floating point, real of wat dan ook kan zijn.

HHahn (overleg) 9 mrt 2010 12:06 (CET)

Bewerkingen

Ik denk dat de termen "associatief" en "distributief" waaraan bewerkingen met zwevendekommagetallen niet volledig zouden voldoen, in deze context niet op hun plaats zijn. Het gaat er in beide gevallen alleen maar om dat de volgorde van bewerkingen het resultaat beinvloedt. Madyno (overleg) 16 dec 2011 10:09 (CET)

De termen geven nauwkeuriger aan wat je hierboven wat vager omschrijft. Waarom zouden die niet op hun plaats zijn?--Patrick (overleg) 16 dec 2011 12:00 (CET)

Wil je dat niet begrijpen?Madyno (overleg) 16 dec 2011 16:47 (CET)

Nou, zo evident is het anders niet. Als de volgorde van de bewerkingen het resultaat beïnvloedt, is er toch precies geen sprake van associatieve/distributieve bewerkingen? Paul B (overleg) 16 dec 2011 17:05 (CET)

Mogelijk heb je formeel gelijk. Ik denk echter bij niet-associatief en niet-distributief niet aan bewerkingen die a.h.w. intrinsiek een beperkte nauwkeurig hebben. In ieder geval vind ik dat dat aspect beter belicht zou moeten worden, en vind ik het volstrekt onbelangrijk dat de termen associatief en distributief genoemd worden. Madyno (overleg) 16 dec 2011 17:45 (CET)

Ik bedacht nog het volgende. Als ik een optelschakeling bedenk, waarbij de regeisters A en B betrokken zijn, en wel zo dat A+B->A, en ik om die reden A groter uitvoer dan B, dan is de optelling zelfs niet commutatief. Er is dus denk ik meer aan de hand dan alleen een eigenschap van FP-bewerkingen. Ik moet er nog eens goed over nadenken. Madyno (overleg) 16 dec 2011 17:52 (CET)

Ik zou de termen wel noemen: het is de basis van de gebruikelijke algebraïsche bewerkingen en de beperkte nauwkeurigheid zorgt ervoor dat je die bewerkingen in ieder geval niet gedachteloos in je code kunt doorvoeren omdat er weleens iets anders uit kan komen dan je had verwacht. Paul B (overleg) 16 dec 2011 18:09 (CET)

"Echt" niet associatief is bijvoorbeeld het bepalen van het vectorproduct. In ons geval levert de andere volgorde weliswaar niet hetzelfde resultaat op, maar het gaat eigenlijk wel om hetzelfde getal, alleen tengevolge van onnauwkeuriheid is er verschil.Madyno (overleg) 16 dec 2011 23:40 (CET)

Dat deze bewerkingen niet per definitie associatief of distributief zijn, is inherent aan alle afgeronde getallen. Ik merk het ieder jaar bij mijn belastingaangifte (als zzp'er, dus balans en verlies- en winstrekening). De totalen zijn nooit precies gelijk, doordat alle bedragen die je invult, op hele euro's afgerond moeten worden. Er zit dus altijd een verschil van één à twee euro in, wat je eerst "weg moet smokkelen", omdat de aangifte anders niet geaccepteerd wordt. Deze bedragen zijn gebroken getallen, afgerond op gehele gehele getallen. Het zijn in dit geval dus géén zwevendekommagetallen. » HHahn (overleg) 16 dec 2011 23:30 (CET)

Gelukkig mag je die verschillen expliciet in je eigen voordel wegsmokkelen :) Paul B (overleg) 16 dec 2011 23:37 (CET)

@Paul B: Uiteraard doe ik dat ook. Maar (1) toen ik nog papieren aangifte deed, deed ik alles op de cent nauwkeurig (makkelijker voor mijn eigen controle!) en rondde alleen het eindresultaat af; (2) ik vind het stom dat de software dat niet zelf doet (bijv. op basis van het aantal bij elkaar getelde subtotalen een bepaalde afwijking toestaan) en (3) dat "eigen voordeel" is verwaarloosbaar: het gaat om hoogiut enkele euro's, zodat het te betalen belastingbedrag nóg kleiner is. Intussen noemde ik dat belastingvoorbeeld alleen omdat het illustreert dat het beschreven probleem niet alleen bij zwevendekommagetallen optreedt, maar bij alle afgeronde getallen. » HHahn (overleg) 16 dec 2011 23:47 (CET)

Beperkte grootte van registers is geen argument

Floating point getallen zijn niet nodig omdat de registers van computers beperkt van grootte zijn! Al is het lastig programmeren, "eindeloos" lange getallen hoeven geen onoverkomelijk probleem te zijn. De werkelijke reden voor floating point getallen is dat de getallen in veel toepassingen (natuurkunde, techniek, meetkunde) van nature een beperkte precisie hebben, en het heeft geen zin om met meer cijfers te rekenen dan de gegevens kunnen dragen.

Floating point getallen heten in het spraakgebruik trouwens "drijvende komma getallen". De aanduiding die breed ingang heeft gevonden verdient de voorkeur ook al is die taalkundig niet de beste. Letterlijk gezien is er noch sprake van "zweven" (dat vereist lucht, of een ander gas), noch van drijven (dat vereist een vloeistof).

Rbakels (overleg) 29 aug 2013 14:30 (CEST)

Wat het eerste betreft heb ik het aangepast. - Patrick (overleg) 29 aug 2013 15:07 (CEST)

Wat het tweede betreft vraag ik me af in welke kringen er "drijvende" wordt gebruikt en of dat genoeg is om dat het spraakgebruik te noemen. Daarbij is er zeker wel letterlijk sprake van zweven in de betekenis van heen en weer laten gaan. --BDijkstra (overleg) 29 aug 2013 18:54 (CEST)

NaN

Hier een verifieerbare onderbouwing van de beweringen omtrent NaNs.

C:

$ cat src/nans.c
#include <stdio.h>
int main(void) {
       printf("1/0 = %f\n", 1.0 / 0.0);
       printf("0/0 = %f\n", 0.0 / 0.0);
       return 0;
}
$ bin/nans
1/0 = inf
0/0 = nan

Java:

$ cat src/nans.java
public class nans {
       public static void main(String[] args) {
               System.out.printf("1/0 = %f\n", 1.0 / 0.0);
               System.out.printf("0/0 = %f\n", 0.0 / 0.0);
       }
}
$ java -classpath bin nans
1/0 = Infinity
0/0 = NaN

--BDijkstra (overleg) 10 jan 2014 23:34 (CET)

Een voorbeeld is geen bron. Je vermeldt niet eens welke compiler/processor deze resultaten levert. Kleuske (overleg) 12 jan 2014 10:01 (CET)

In het geval van Java is het niet nodig om de compiler/processor te noemen: de taal specificeert dit gedrag. Ik had gehoopt dat bovenstaande voorbeelden (voorlopig) genoeg waren om de bewering het voordeel van de twijfel te geven. Ik had verwacht dat je hoogstens een {Bron?}-sjabloon zou toevoegen en daarmee medewerkers de ruimte zou geven om bronnen aan te dragen. Ik hoop dat je met je recente bewerkingen in dit artikel het beste voor hebt met Wikipedia. --BDijkstra (overleg) 13 jan 2014 11:57 (CET)

Oh, du Unschuld vom Lande... Punt een: er zijn diverse Java implementaties di4e nogal verschillen. Punt twee, deze bron heeft het niet over delen door nul. Punt drie: Dit artikel gaat over floating point getallen, niet over Java. Punt vier: Je bijdrage hier ondermijnt je bewering in het artikel. Kleuske (overleg) 13 jan 2014 12:03 (CET)

Punt 1: Ik ga ervan uit dat de meeste en de meest belangrijke implementaties 100% voldoen aan de taalspecificatie op deze paragraaf (4.2.3). Het benoemen van afwijkende implementaties lijkt me minder relevant voor dit artikel. Punt 2: jawel. Punt 3: de bewering gaat over IEEE 754, wat Java beweert te volgen. Je kunt niet eerst zeggen dat de door mij gebruikte implementatie ontbreekt ("welke compiler/processor") en vervolgens zeggen dat het niet gaat over de implementatie (bv. Java). Punt 4: volgens mij strookt het met elkaar, dus ik begrijp niet waarom je zegt dat het ondermijnt. --BDijkstra (overleg) 13 jan 2014 13:21 (CET)

Associatief, distributief?

Hier is al eerder discussie over geweest en ik zou graag zien dat meer mensen meedenken. Mijn standpunt is dat de verschillen die ontstaan in het resultaat van bewerkingen met zwevendekommagetallen als gevolg van de gehanteerde volgorde, niets te maken hebben met de begrippen associativiteit en distributiviteit. Het is slechts het gevolg van de eindige nauwkeurigheid. Daarom zou ik de afhankeljkheid van de volgorde alleen daarmee in verband willen brengen en niet de begrippen associatief en distributief vermelden. Madyno (overleg) 11 jan 2014 14:38 (CET)

Een binaire operatie met afronding is zelf ook gewoon een binaire operatie waar je eigenschappen van kan bespreken. - Patrick (overleg) 11 jan 2014 17:21 (CET)

De eindige precisie is er de oorzaak van dat bewerkingen niet helemaal associatief en distributief zijn, maar het resultaat is er niet anders om. Distributieve en associatieve eigenschappen werken alleen bij benadering. Kleuske (overleg) 12 jan 2014 10:08 (CET)

De afhankelijkheid van de volgorde is inderdaad een direct gevolg van de eindige nauwkeurigheid, maar ik vind het wel relevant om daarbij te vertellen dat hierdoor niet wordt voldaan aan de voorwaarden voor associativiteit en distributiviteit. - De voorgaande opmerking werd toegevoegd door Bdijkstra (overleg · bijdragen) 13 jan 2014 23:27‎ (CET)

Alleen al dat je kunt spreken over niet helemaal associatief, geeft al aan dat het hier niet gaat om de associatieve eigenschap. Duidelijk is dat er in principe bijna hetzelfde uitkomt als de volgorde veranderd wordt. Zelfs is het zo dat de nauwkeurigheid daarvan afhangt van de gebruikte implementering, en niet een inherente eigenschap is van de bewerking. Madyno (overleg) 14 jan 2014 10:52 (CET)

Beveiliging

Wegens een bwo die wat uit de hand begint te lopen heb ik het artikel voor 1 dag beveiligd in de verkeerde versie natuurlijk. Natuur12 (overleg) 13 jan 2014 12:13 (CET)

Kan "Natuur12" vertellen wat een "bwo" is? Ik vond de afkorting(?) noch in Wikipedia zelf noch in de "urban dictionary" met een betekenis die hier zou kunnen passen. Rbakels (overleg) 1 apr 2016 12:52 (CEST)

WP:BWO. --BDijkstra (overleg) 1 apr 2016 14:46 (CEST)

Rekenvoorbeelden

Mijn voorbeeld, nog concreter (berekeningen met Google):

1 + 3e-12 geeft 1. Dit resultaat plus 3e-12 geeft dus ook 1.

Echter: 3e-12 + 3e-12 geeft 6e-12. Vervolgens: 1 + 6e-12 geeft 1,0000000001.

Bij dit voorbeeld gaat het steeds om de afrondingen op de zichtbare resultaten. In één uitdrukking wordt vaak nauwkeuriger gerekend: (1 + 3e-12) + 3e-12 geeft 1,0000000001. In principe geldt echter hetzelfde. Mogelijk zal een compiler soms zelf een optimale volgorde bepalen, waardoor de met haakjes aangegeven volgorde niet uitmaakt. - Patrick (overleg) 13 jan 2014 14:22 (CET)

Wat precies is er niet duidelijk aan het woord "Bron"? Wat is er niet duidelijk aan de NOODZAAK voor BRONNEN in een ENCYCLOPEDIE? Waarom proberen mensen met flauwe voorbeeldjes een BRONVERMELDING te omzeilen? Perque? Is dit flauwe geneuzel EINDELIJK afgelopen? Kleuske (overleg) 13 jan 2014 14:27 (CET)

Hetzelfde niveau: x²=2x. Voorbeeld: 2²=4=2*2. Klopt, dus. Voorbeeld is er, dus dat geldt ALTIJD. Kleuske (overleg) 13 jan 2014 14:27 (CET)

Het kan toegevoegd worden als voorbeeld van "Soms is een bepaalde volgorde (of meer algemeen een bepaald algoritme) duidelijk beter dan een andere, ook al zijn ze wiskundig gelijkwaardig, in de zin dat bij exact rekenen de uitkomst hetzelfde zou zijn." - Patrick (overleg) 13 jan 2014 14:46 (CET)

Patrick, het is misschien beter om dit te laten rusten totdat je een bron hebt. --BDijkstra (overleg) 13 jan 2014 15:17 (CET)

Dat is wel overdreven voor een rekenvoorbeeld dat iedereen zo kan narekenen. Er staan wel meer rekenvoorbeelden op Wikipedia. Vanwege het auteursrecht zijn die niet gekopieerd uit een bron. - Patrick (overleg) 13 jan 2014 15:26 (CET)

Zie bijv. Vriespuntsdaling. - Patrick (overleg) 13 jan 2014 15:30 (CET)

De rekenvoorbeelden op Vriespuntsdaling zijn puur wiskundig en er wordt impliciet vanuit gegaan dat de lezer een geschikte rekenomgeving zal gebruiken. De rekenvoorbeelden hier gaan juist over de grenzen van de rekenomgeving en dat maakt het wenselijk om betrouwbaar en verifieerbaar aan te geven onder welke omstandigheden die grenzen wel en niet bereikt worden. Daarnaast is een rekenvoorbeeld nog slechts een voorbeeld ter illustratie van een bepaalde bewering en om verder conflict te vermijden is het beter om beweringen van een bron te voorzien. --BDijkstra (overleg) 13 jan 2014 16:44 (CET)

Zoals gezegd stel ik voor het toe te voegen aan "Soms ..". Een dergelijke bewering wordt niet alleen verduidelijkt maar zelfs bewezen door een voorbeeld. - Patrick (overleg) 13 jan 2014 17:49 (CET)

Het voorbeeld bewijst dat er ergens afronding gebeurt; het bewijst niet dat dit komt door het gebruik van zwevendekommagetallen en het bewijst niet eens dat er intern gebruik is gemaakt van zwevendekommagetallen. De herkomst van het voorbeeld (Google) maakt de relevantie van de bewering twijfelachtig: wie gebruikt Google nou serieus als rekenmachine? Dan is er nog de betrouwbaarheid en verifieerbaarheid: als je al aannemelijk kan maken dat Google zwevendekommagetallen gebruikt, dan is er nog geen enkele zekerheid dat ze dat morgen nog op dezelfde manier zullen doen. Als laatste: het stukje "Soms..." gaat over de volgorde, jouw voorbeeld geeft niet twee berekeningen in een verschillende volgorde die een verschillend resultaat geven (terwijl je volgens de rekenregels van de wiskundige operatoren eenzelfde resultaat zou verwachten). --BDijkstra (overleg) 13 jan 2014 18:35 (CET)

Google is waarschijnlijk de bekendste calculatorwebsite, maar een andere kan ook. Wat ook kan (en het een sluit het ander niet uit) zijn rekenvoorbeelden, met de hand doorgerekend, op basis van een bepaalde keuze van de parameters van een systeem van zwevendekommagetallen, met de aanname "het resultaat van een bewerking is de werkelijke uitkomst, afgerond op het dichtstbijzijnde representeerbare getal". Wat je laatste punt betreft: ik vergelijk (1 + 3e-12) + 3e-12 met 1 + (3e-12 + 3e-12), daar ging het toch over? - Patrick (overleg) 13 jan 2014 22:42 (CET)

Wat mijn laatste punt betreft: je hebt gelijk. Ik ben blijkbaar heel slecht in het lezen van berekeningen die niet in wiskundige notatie staan... Maar, een calculatorwebsite bewijst niets, omdat je niet de interne representatie en de tussenstappen weet. En als je zelf een met de hand doorgerekend voorbeeld gaat maken, dan gaat dat op origineel onderzoek lijken. Een bron is echt beter. --BDijkstra (overleg) 14 jan 2014 00:00 (CET)

Het is gewoon analoog aan rekenvoorbeelden op Vriespuntsdaling. - Patrick (overleg) 14 jan 2014 09:10 (CET)

Nee. Je valt in herhaling. Mijn argumenten staan hierboven. Als je daar niet op in kunt gaan, is deze discussie wat mij betreft afgelopen. --BDijkstra (overleg) 14 jan 2014 09:37 (CET)

Je zegt "De rekenvoorbeelden op Vriespuntsdaling zijn puur wiskundig en er wordt impliciet vanuit gegaan dat de lezer een geschikte rekenomgeving zal gebruiken. De rekenvoorbeelden hier gaan juist over de grenzen van de rekenomgeving en dat maakt het wenselijk om betrouwbaar en verifieerbaar aan te geven onder welke omstandigheden die grenzen wel en niet bereikt worden." Ik vind dat niet duidelijk, op basis van een bepaalde keuze van de parameters van een systeem van zwevendekommagetallen, met de aanname "het resultaat van een bewerking is de werkelijke uitkomst, afgerond op het dichtstbijzijnde representeerbare getal" is een rekenvoorbeeld ook puur wiskundig. - Patrick (overleg) 14 jan 2014 10:24 (CET)

Openingsparagraaf

Het lijkt me dat de openingsparagraaf meteen precies moet vertellen wat zo'n zwevendekommagetal is. Het staat wel in het artikel, maar druppelsgewijs in volgende paragrafen. Ik was begonnen de tekst te veranderen, maar dat heb ik vooralsnog opgegeven.

Volgens mij wordt uitsluitend van zulke getallen gesproken in relatie tot computers. Hoewel de term "floating point number" algemeen gebruikelijk is, gaat het eigenlijk om een bepaalde representie van getallen in computers. Het is dus niet juist om apart van de "interne representatie" te spreken: het is een interne representatie.

Om tot de zwevendekommarepresentatie te komen wordt een getal allereerst wiskundig wordt omgezet in een mantisse en een exponent, waarvan vervolgens (voor een gegeven type floating point getal, zoals short, long of double) slechts een vast aantal cijfers van de mantisse en de exponent worden opgeslagen.

Zoals gewoonlijk is een voorbeeld veel makkelijker dan een abstracte beschrijving: bij een "floating point number" gaat het (bijv.) om <zoveel (mantisse)> maal tien tot de macht <zoveel (exponent)>. Als de mantisse door tien wordt gedeeld en de exponent met één wordt vermeerderd blijft het gerepresenteerde getal hetzelfde: dat is het "drijven van de komma". Gegeven het feit dat de mantisse in een computer altijd slechts in een eindig aantal cijfers wordt vastgelegd wordt de exponent bij voorkeur zo gekozen dat de doorgaans onvermijdelijke afrondingsfout minimaal is.

Met een mantisse van drie cijfers kan het getal pi worden voorgesteld als 3 * 10⁰ of 31 * 10^-1 of 314 * 10^-2. De laatste representatie is duidelijk de nauwkeurigste.

Zwevendekommagetallen worden typisch gebruikt om grootheden weer te geven die worden gemeten, vastekommagetallen voor grootheden die worden geteld. Als je de hoogte van een tafel meet dan weet je die nooit precies: er is altijd een meetfout. Maar jet weet die doorgaans wel met een bepaalde nauwkeurigheid, zeg 1%, dan dan volstaat een getal van 2 cijfers, ongeacht de eenheid waarin je meet. Daar is een zwevendekommagetal (=representatie) het meest geschikt voor. Gaat het om geld, of individuen, dan moet een vastekommagetal (=representatie) worden gebruikt. Moderne computers kennen vastekommarepresentaties van tenminste 64 bits waar getallen t/m 18.446.744.073.709.551.615 mee kunnen worden gerepresenteerd. Rbakels (overleg) 1 apr 2016 13:19 (CEST)

Ik ben het met je eens dat de openingsparagraaf een beetje gedetailleerder kan (maar van mij hoeft het ook niet perse). Voel je vrij en ga je gang.

Op de rest van je post heb ik wel wat aan te merken.

Ten eerste, ja, een floating point getal is een getal van de vorm m * r^e waarbij m en e een vast eindig bereik hebben. (Het grondtal is niet perse gelijk aan 10, meestal 2.) Daarmee ligt de interne representatie echter nog niet vast. Een double is bijvoorbeeld 64 bits, maar welke bits zijn de mantisse en de exponent? Is er een aparte tekenbit? Is de exponent signed of wordt er een offset genomen? Etc, etc, etc. "short" en "long" zijn trouwens geen floating point types, maar (in ieder geval in de programmeertalen die ik ken) integer-types.

Ten tweede, een vastekommarepresentatie is niet hetzelfde als een integer. In een vastekommarepresentatie ligt het aantal cijfers achter de komma vast. Als we twee cijfers nemen, kun je bijvoorbeeld 1234567,89 en 1,23 representeren, maar diet 1,234. In een zwevendekommagetal ligt alleen het aantal cijfers vast, de komma staat op een willekeurige plek. Je kan dus grote getallen met weinig cijfers achter de komma of kleine getallen met veel cijfers achter de komma representeren. Als je (met grondtal 10) 4 cijfers nauwkeurigheid neemt, kun je bijvoorbeeld 1234 en 4,321 (en 12340) representeren, maar niet 1234,5 (en 12345).

Hoopje (overleg) 1 apr 2016 14:01 (CEST)

Afrondingsfouten

Het lijkt me dat een apart hoofdstukje over afrondingsfouten niet mag ontbreken.

Het is de bedoeling om met de zwevendkommarepresentatie een getal zo nauwkeurig mogelijk vast te leggen in een gegeven aantal cijfers. Dat is meestal enigszins onnauwkeurig, zeker in het geval van waarden van transcendente functies, wiskundige functies die getallen opleveren die precies niet in een eindig aantal decimale cijfers weer te geven zijn.

Hoewel de nauwkeurigheid van de gangbare zwevendkommarepresentaties heel groot lijkt, kan de uitkomst van aftrekkingen veel onnauwkeuriger zijn dan de onnauwkeurigheid van de beide termen, met name als twee ongeveer even grote getallen van elkaar worden afgetrokken. Stel je vast dat de onder- en de bovenkant van een tafelblad zich op ongeveer een meter boven de grond bevinden, dan is dat redelijk nauwkeurig, maar de dikte van het tafelblad - het verschil - is dan 100% onnauwkeurig. Om zgn. cijferverlies te voorkomen rekenen wiskundigen dan ook graag met zwevendkommagetallen van "double" of zelfs "long double" precisie. Niettemin blijft numeriek differentiëren een heikele zaak. Een differentiaalquotiënt is immers gedefinieerd als de limiet van het quotiënt van twee verschillen die beide naar nul gaan.

Als een groot aantal getallen bij elkaar wordt opgeteld cumuleert de onnauwkeurigheid. Programmeurs moeten er op bedacht zijn dat a + a + a niet dezelfde uitkomst hoeft te hebben als 3 * a.

Zwevendekommagetallen zijn wel onontbeerlijk voor wiskundige programma's, maar zij introduceren ook een nieuwe problematiek waar de programmeur alert op moet zijn. Rbakels (overleg) 1 apr 2016 13:42 (CEST)

Inleiding schiet tekort

Een eerste alinea van een lemma moet volgens mij de essentie van het onderwerp aangeven voor leken, met zo min mogelijk details. Dat is hier volstrekt niet het geval. Ik weet wat een drijvende-komma-getal is, maar herken dat niet in de tekst. Is het niet vooral zo dat drijvende-kommagetallen worden gebruikt voor berekeningen en gemeten grootheden, in tegenstelling tot gehele getallen, die worden gebruikt om te tellen? het is verhelderend om drijvende-kommagetallen tegenover de (meer gebruikte) vaste-komma getallen te zetten. Rbakels (overleg) 2 mei 2017 05:13 (CEST)

Als je goed leest zie je dat bovenaan staat dat dit lemma over een gegevenstype gaat bij computers. Voor de algemene betekenis moet je het lemma Wetenschappelijke notatie bekijken. Madyno (overleg) 2 mei 2017 10:41 (CEST)

Rationale getallen?

In de inleiding staat dat een zwevendekommagetal een rationeel getal is. Moet dit niet reëel getal zijn? Pingel (overleg) 2 mei 2017 12:29 (CEST)

Nee, het is een rationAAl getal. Madyno (overleg) 2 mei 2017 12:30 (CEST)

Oeps, ik heb dat altijd verkeerd gelezen. Afijn, koptitel op deze pagina aangepast. Waarmee mijn vraag overigens nog wel blijft. Pingel (overleg) 2 mei 2017 12:47 (CEST)

Hoezo, ik schreef toch al dat het een rationaal getal is!Madyno (overleg) 2 mei 2017 15:16 (CEST)

En mijn vraag is dus of het niet beter is te spreken van reële getallen. Naar mijn idee kan een zwevendekommagetal met een zekere precisie ook een irrationaal getal beschrijven, vandaar. Pingel (overleg) 2 mei 2017 15:57 (CEST)

Zwevendekommagetallen hebben een eindig aantal cijfers achter de komma en kunnen daardoor altijd als een breuk geschreven worden. Het zijn dus duidelijk rationale getallen. K_Ad^EIk_E ^[!?] 2 mei 2017 16:17 (CEST)

Een zwevendekommagetal kan net zo goed een imaginair getal beschrijven. Het is aan de programmeur om te bepalen of een waarde reëel is of imaginair, of iets anders (hoewel er programmeertalen zijn met REAL als type). --bdijkstra (overleg) 2 mei 2017 17:00 (CEST)

Zo weet ik er nog een paar. Het alfabet bestaat uit letters, is het niet? Maar je kunt net zo goed bepalen dat het getallen zijn. Madyno (overleg) 2 mei 2017 18:58 (CEST)

Ik vind het voorstel van Pingel helemaal niet gek. Natuurlijk is het zo dat elk zwevendekommagetal óók een rationaal getal is. Maar elk zwevendekommagetal is óók een reëel getal. En net zoals niet alle reële getallen zwevendekommagetallen zijn, zijn niet alle rationale getallen zwevendekommagetallen (met vast grondtal). Kortom: zwevendekommagetallen zijn niet gelijk aan reële getallen, maar ze zijn ook niet gelijk aan rationale getallen. Met zuiver rationale ( ;-) ) argumenten kom je hier dus niet uit.

Gevoelsmatig worden zwevendekommagetallen echter vooral gebruikt waar men theoretisch een reëel getal zou verwachten, zoals voor een lengte of een grootte. Praktisch zijn het dus meestal benaderingen van reële getallen, niet van rationale. Het is niet voor niks dat, zoals bdijkstra al opmerkte, sommige programmeertalen zwevendekommagetallen achter het type Real verstoppen, terwijl programmeertalen of bibliotheken die een Rational-datatype hebben, deze meestal als een expliciete breuk representeren.

En geheel terzijde: niet dat dat voor onze beslissing van invloed hoeft te zijn, maar de Engelse Wikipedia kiest ook voor reële getallen.

Hoopje (overleg) 2 mei 2017 21:41 (CEST)

Het klopt niet wat je zegt over de Engelse Wikipedia. In het betreffende lemma staat duidelijk: A floating-point number is a rational number. Wel kan opgemerkt worden dat FFP-getallen meestal gebruikt worden als benadering voor reële getallen.Madyno (overleg) 3 mei 2017 10:26 (CEST)

Pingel had het specifiek over het gebruike van rationale getallen in de inleiding, dus ik ging er van dat het duidelijk was dat ik ook naar de inleiding van de Engelse Wikipedia verwees, en daar staat, als eerste zin zelfs: "In computing, floating-point arithmetic is arithmetic using formulaic representation of real numbers as an approximation so as to support a trade-off between range and precision." (nadruk van mij). Dat verder in het artikel de dingen nog preciezer worden gemaakt is natuurlijk zonneklaar, ik had ook niet anders verwacht. Hoopje (overleg) 3 mei 2017 10:53 (CEST)

Tja, wat zal ik ervan zeggen? Madyno (overleg) 3 mei 2017 17:21 (CEST)

Wat vinden jullie van zoiets in de eerste alinea:

• Hoewel zwevendekommagetallen strikt genomen rationale getallen zijn, worden ze meestal gebruikt als benadering voor reële getallen. Pingel (overleg) 3 mei 2017 18:17 (CEST)

Prima, maar in het geheel dan zo:

Een zwevendekommagetal of drijvendekommagetal (Engels: floating-point number) is een gegevenstype dat een vaste geheugenruimte beslaat, en een grote variëteit getallen kan bevatten, van zeer kleine tot zeer grote. Hoewel zwevendekommagetallen strikt genomen rationale getallen zijn, worden ze meestal gebruikt als benadering voor reële getallen.'De relatieve nauwkeurigheid waarin getallen worden gerepresenteerd, is ongeveer gelijk over de hele linie. Het is de digitale versie van de wetenschappelijke notatie.

Madyno (overleg) 4 mei 2017 11:58 (CEST)

Mooi zo, ik heb het aangepast. Pingel (overleg) 5 mei 2017 22:42 (CEST)