[Elke programmeertaal (?)] Waarom geeft delen door 0 error?

[Verwijderd]

Een paar dagen terug creëerde ik onbewust een "gevaarlijke" situatie in een applicatie dat ik aan het bouwen ben op een online aPaaS platform.

Wat was de "gevaarlijke" situatie? Ik maakte een berekening variable_1 / variable_2
Waarom is dit "gevaarlijk"? variable_2 kan soms de waarde 0 bevatten en daarom een error veroorzaken.

Het vervelende in dit geval was, dat de error logging van dit platform, bij dit type fout, tekort schoot. De applicatie is ondertussen aardig complex en het enige bericht dat ik kreeg was "Failed" bij het uitvoeren van een bepaalde taak, waarbij tientallen berekeningen worden gedaan. Samen met hulp van 2 ontwikkelaars van het platform zelf, zijn er 2 dagen overheen gegaan om de oorzaak te achterhalen.

Dit laatste stukje is niet heel relevant, maar gaf mij wel aanleiding tot mijn vragen:

1. Waarom geven programmeertalen een error of een andere type resultaat wanneer er gedeeld wordt door 0?
2. Wat is de rede dat programmeertalen niet standaard bij deling door 0, 0 als resultaat teruggeven?
3. Scheelt dit niet een hoop bug-fixing en extra controle code ("if var == 0 then ...")?

Dit vroeg ik mij zo af en ben benieuwd wat jullie hier van denken.

[SLeddert]

Omdat je niet door 0 kan delen...Het antwoord is dus niet 0, maar gewoon onjuist.

[samo]

Wat is de rede dat programmeertalen niet standaard bij deling door 0, 0 als resultaat teruggeven?

Omdat in de wiskunde iets gedeeld door 0 geen nul is. 100 gedeeld door 10 is 10. 10 keer 10 is 100. Als 100 gedeeld door 0 op 0 uit komt, is dan 0 keer 0 ook weer 100?

[jbdeiman]

1. Delen door 0 geeft een "oneindig groot getal" en geeft daarom een fout, als je vraagt hoevaak "0,0001" in 1 past is dat 10000 keer, het getal nul past er oneindig keer in, daar kunnen systemen simpelweg niet mee werken.
2. Omdat dat niet waar is, de computer probeert bij een "deling" te bepalen hoevaak x in y past. Omdat 0 op zichzelf een goede waarde is, maar oneindig past in welke waarde dan ook, wordt er geen 0 terug gegeven
3. Als je gaat delen, moet er altijd een waarde zijn waardoor je kunt delen, anders valt er niets te delen namelijk. Het is technisch wel mogelijk dat een programmeertaal dit voor je afvangt door 0 terug te geven, maar dan weet je niet of het een "ongeldige deling" was (delen door 0 kan immers niet), of dat je 1/10000 terug krijgt als integer (dus 0), dus dat de waarde "zo klein is dat deze (afgerond) gelijk wordt gesteld aan 0. Het laatste wat je wilt is dat een programmeertaal "aannames doet", omdat dat ongewenst/ onvoorspelbaar gedrag op kan leveren.

Meer info: Wikipedia: Division by zero

[ Voor 4% gewijzigd door jbdeiman op 17-03-2017 10:18 ]

[Xessive]

samo schreef op vrijdag 17 maart 2017 @ 10:16:
[...]

Omdat in de wiskunde iets gedeeld door 0 geen nul is. 100 gedeeld door 10 is 10. 10 keer 10 is 100. Als 100 gedeeld door 0 op 0 uit komt, is dan 0 keer 0 ook weer 100?

Division by zero is an operation for which you cannot find an answer, so it is disallowed. You can understand why if you think about how division and multiplication are related.
12 divided by 6 is 2 because
6 times 2 is 12

12 divided by 0 is x would mean that
0 times x = 12
But no value would work for x because 0 times any number is 0. So division by zero doesn't work.

Stukje ff 'snel' van internet geplukt maar je was me net voor.

Bij delingen is de enige check die je hoeft te doen het controleren van de deler. If var <> 0 then etc

[ Voor 6% gewijzigd door Xessive op 17-03-2017 10:22 . Reden: aanvulling ]

[Gamebuster]

Los van alle antwoorden hierboven vind ik het discutabel dat systemen knalhard falen bij delen-door-0. Ik vind Javascript's gedrag hierbij dan het beste:

JavaScript:

> 10/0
Infinity

Andere talen kiezen voor duidelijke error:

Ruby:

2.2.1 :001 > 10/0
ZeroDivisionError: divided by 0

Elixir:

iex(1)> 10/0
** (ArithmeticError) bad argument in arithmetic expression
    :erlang./(10, 0)

Python:

>>> 10/0
ZeroDivisionError: integer division or modulo by zero

Maar dat is een kwestie van smaak denk ik dan. Misschien vind ik een harde error wel fijn, gezien zo'n "Infinity" zoals in Javascript dan wel de hele tijd door de rest van je berekeningen gaan. Probeer 'm dan maar eens te traceren. Als je dan het getal wil tonen krijg je van die dingen als €NaN. Wat dat betreft is een harde error misschien wel beter.

Hoe dan ook, x/0 = 0 is wat mij betreft geen passende oplossing. Als je dat gedrag wil, moet je inderdaad maar zelf een check doen zovan y == 0 ? 0 : x/y

[ Voor 86% gewijzigd door Gamebuster op 17-03-2017 10:27 ]

[LordSinclair]

Als je 10 appels moet verdelen over 0 personen zijn niet opeens poef alle appels weg. Het kan gewoon niet.

[Alex3]

Er zijn getalrepresentaties met speciale waarden voor oneindig en ongedefinieerd (b.v. 0/0). Dan moet je wel na elke bewerking testen anders zit je voor niets te rekenen...

[Verwijderd]

Hartelijk dank allen. Het is mij nu geheel duidelijk.

[jbdeiman]

Alex3 schreef op vrijdag 17 maart 2017 @ 10:26:
Er zijn getalrepresentaties met speciale waarden voor oneindig en ongedefinieerd (b.v. 0/0). Dan moet je wel na elke bewerking testen anders zit je voor niets te rekenen...

Klopt, maar controleren moet je het sowieso, vooraf of achteraf.

[windwarrior]

Gamebuster schreef op vrijdag 17 maart 2017 @ 10:21:
Los van alle antwoorden hierboven vind ik het discutabel dat systemen knalhard falen bij delen-door-0. Ik vind Javascript's gedrag hierbij dan het beste:

JavaScript:

> 10/0
Infinity

Andere talen kiezen voor duidelijke error:

Ruby:

2.2.1 :001 > 10/0
ZeroDivisionError: divided by 0

Elixir:

iex(1)> 10/0
** (ArithmeticError) bad argument in arithmetic expression
    :erlang./(10, 0)

Python:

>>> 10/0
ZeroDivisionError: integer division or modulo by zero

Maar dat is een kwestie van smaak denk ik dan. Misschien vind ik een harde error wel fijn, gezien zo'n "Infinity" zoals in Javascript dan wel de hele tijd door de rest van je berekeningen gaan. Probeer 'm dan maar eens te traceren. Als je dan het getal wil tonen krijg je van die dingen als €NaN. Wat dat betreft is een harde error misschien wel beter.

Hoe dan ook, x/0 = 0 is wat mij betreft geen passende oplossing. Als je dat gedrag wil, moet je inderdaad maar zelf een check doen zovan y == 0 ? 0 : x/y

Daarnaast kan niet elke getalsrepresentatie Infinity representeren, wat zou bijvoorbeeld Java dan moeten doen als je (int) 10 / (int) 0 doet... er is geen Infinity voor Java's int.

In de wijze woorden van mijn wiskunde docent 5e klas: "Delen door nul is flauwekul". Daarom ben ik blij dat daar een harde error op gegooid wordt!

[Gamebuster]

windwarrior schreef op vrijdag 17 maart 2017 @ 10:47:
[...]


Daarnaast kan niet elke getalsrepresentatie Infinity representeren, wat zou bijvoorbeeld Java dan moeten doen als je (int) 10 / (int) 0 doet... er is geen Infinity voor Java's int.

In de wijze woorden van mijn wiskunde docent 5e klas: "Delen door nul is flauwekul". Daarom ben ik blij dat daar een harde error op gegooid wordt!

Ja dat is zeker waar. Doe dan maar consistent een harde error

[ Voor 3% gewijzigd door Gamebuster op 17-03-2017 11:05 ]

[Krysa]

Ik vond dit wel een goede uitleg waarom je niet door nul kunt delen: YouTube: Problems with Zero - Numberphile

[RobIII]

Verwijderd schreef op vrijdag 17 maart 2017 @ 10:06:
[list]
• Wat is de rede dat programmeertalen niet standaard bij deling door 0, 0 als resultaat teruggeven?

Iets heel anders: je kunt wel een 'sentinel' value als -1, -π, ∞, 🍆, ☃ of 0, FILE_NOT_FOUND of ERR_DIVISION_BY_ZERO willen (laten) teruggeven maar dat betekent dat je na elke scheet eerst moet controleren of de uitkomst die 'sentinel' value is. In bepaalde gevallen/talen heb je NaN / Infinity maar daar moet je dan wel specifiek rekening mee houden. Het is veel beter om een DivisionByZeroException (of soortgelijk) te gooien; fail fast. Bugs komen zo veel eerder aan 't licht (helemaal als je je logging op orde hebt ) dan wanneer je (potentieel) met de verkeerde waarde doorrekent.

jbdeiman schreef op vrijdag 17 maart 2017 @ 10:32:
[...]

Klopt, maar controleren moet je het sowieso, vooraf of achteraf.

Dat behoeft nogal wat nuance; er zijn plenty gevallen waarbij je zeker weet (lees: kunt garanderen) dat de deler nooit 0 zal zijn

[ Voor 20% gewijzigd door RobIII op 17-03-2017 11:35 ]

[jeroen3]

De hardware niet kan delen door 0. De instructie geeft dan een exception flag.
Of deze escaleert is aan de implementatie.

De fixed point mathlib die ik recent heb gebruikt geeft de kleinst mogelijke positieve waarde terug. Immers, op ARM is een divide by zero vaak een hardfault (stackdump). Daar kan je eigenlijk niet uit herstellen. Dus een reboot.

[Bloemkoolsaus]

Verwijderd schreef op vrijdag 17 maart 2017 @ 10:06:
Wat is de rede dat programmeertalen niet standaard bij deling door 0, 0 als resultaat teruggeven?

Omdat dat antwoord onjuist zou zijn. De uitkomst zou dan niet te vertrouwen zijn. Als je de uitkomst nodig hebt voor een volgende berekening dan ga je rekenen met een onjuiste waarde. Dat vind ik veel gevaarlijker!

[RobIII]

jeroen3 schreef op vrijdag 17 maart 2017 @ 11:24:
De hardware niet kan delen door 0.

"Niemand"/"niets" kan dat* Maar wat CPU's betreft: het is niet zo zeer dat ze het niet kunnen maar dat het gewoon gedefinieerd gedrag is; er wordt niet eens een poging ondernomen "If divisor == 0 set FLAG X..." (of result = infinity of Halt and Catch Fire of...)

* Althans, niet in het 'doorsnee rekenwerk'. Er zijn hele takken van de wiskunde waar vrolijk "met 0 gedeeld wordt" maar waarvan de uitkomst bepaald/vastgelegd is.

[ Voor 37% gewijzigd door RobIII op 17-03-2017 11:54 ]

[jbdeiman]

RobIII schreef op vrijdag 17 maart 2017 @ 11:19:
[...]


Iets heel anders: je kunt wel een 'sentinel' value als -1, -π, ∞, 🍆, ☃ of 0, FILE_NOT_FOUND of ERR_DIVISION_BY_ZERO willen (laten) teruggeven maar dat betekent dat je na elke scheet eerst moet controleren of de uitkomst die 'sentinel' value is. In bepaalde gevallen/talen heb je NaN / Infinity maar daar moet je dan wel specifiek rekening mee houden. Het is veel beter om een DivisionByZeroException (of soortgelijk) te gooien; fail fast. Bugs komen zo veel eerder aan 't licht (helemaal als je je logging op orde hebt ) dan wanneer je (potentieel) met de verkeerde waarde doorrekent.

[...]

Dat behoeft nogal wat nuance; er zijn plenty gevallen waarbij je zeker weet (lees: kunt garanderen) dat de deler nooit 0 zal zijn

Hoe weet je dat dan? Doordat jij de controle hebt (of hebt uitgevoerd over) de deler toch? Het is anders not done er geen controle op te maken bij ons in 't bedrijf.

[RobIII]

jbdeiman schreef op vrijdag 17 maart 2017 @ 11:53:
Hoe weet je dat dan?

Simpel:

code:

for (int i = 1; i < 100; i++) {
  print foo / i;
}

In zo'n geval (e.v.a.) is i gegarandeerd nooit 0. Als je overal braaf die "controle" loopt te doen "omdat regels" ben je je tijd aan 't verdoen.

Sowieso is een controle in veel gevallen onzin, daar is de DivisionByZero exception voor en die kun je dan afhandelen hoe je wil. Je kunt overal wel een "if divisor == 0 then throw MyException('mag niet!!1')" of "if divisor == 0 then Message('mag niet!!1')" inbouwen maar het netto-effect blijft hetzelfde: je zult met die case moeten omgaan/afhandelen (en dus lekker gewoon de DivideByZeroException handlen, die is er niet voor niets). En dan heb ik het wel voornamelijk over 'wat dieper gelegen code' of 'libraries' etc; natuurlijk kijk je expliciet(er) naar divisors bij user-input etc. (dus code die wat meer "aan de oppervlakte" ligt).

jbdeiman schreef op vrijdag 17 maart 2017 @ 11:53:
Doordat jij de controle hebt [...] over de deler toch?

Dat is toch precies wat ik zeg?

RobIII schreef op vrijdag 17 maart 2017 @ 11:19:
er zijn plenty gevallen waarbij je zeker weet (lees: kunt garanderen) dat de deler nooit 0 zal zijn

[ Voor 63% gewijzigd door RobIII op 17-03-2017 12:34 ]

[jeroen3]

RobIII schreef op vrijdag 17 maart 2017 @ 11:26:
[...]

"Niemand"/"niets" kan dat* Maar wat CPU's betreft: het is niet zo zeer dat ze het niet kunnen maar dat het gewoon gedefinieerd gedrag is; er wordt niet eens een poging ondernomen "

Gelukkig niet zeg.
YouTube: What happens when divide by zero on mechanical calculator Facit ESA-01

[Rannasha]

jbdeiman schreef op vrijdag 17 maart 2017 @ 10:18:

1. Delen door 0 geeft een "oneindig groot getal" en geeft daarom een fout, als je vraagt hoevaak "0,0001" in 1 past is dat 10000 keer, het getal nul past er oneindig keer in, daar kunnen systemen simpelweg niet mee werken.

Nee, delen door 0 geeft geen "oneindig groot getal" binnen de reele getallen (of een subset daarvan). Het is simpelweg niet gedefinieerd. De functie "delen door" werkt niet als het tweede argument nul is.

Daarom...

Gamebuster schreef op vrijdag 17 maart 2017 @ 10:21:
Ik vind Javascript's gedrag hierbij dan het beste:

JavaScript:

> 10/0
Infinity

... is dit geen goed voorbeeld van hoe een functie zich hoort te gedragen bij deling door 0.

Deling door 0 is hetzelfde als een string doorgeven aan een functie die een getal verwacht (in een weakly typed taal): Een argument van de functie heeft een ongeldige waarde en daar hoort een fout-respons bij.

[Sissors]

Rannasha schreef op vrijdag 17 maart 2017 @ 12:05:
[...]

Nee, delen door 0 geeft geen "oneindig groot getal" binnen de reele getallen (of een subset daarvan). Het is simpelweg niet gedefinieerd. De functie "delen door" werkt niet als het tweede argument nul is.

Dat is het verschil tussen de interpretatie van wiskundige en bijvoorbeeld ingenieurs. Bij wiskundige kan het inderdaad niet. In mijn gebied (elektrotechniek) is delen door 0 algemeen geaccepteerd als correct iets wat oneindig als resultaat heeft.

[DroogKloot]

Rannasha schreef op vrijdag 17 maart 2017 @ 12:05:
[...]

Nee, delen door 0 geeft geen "oneindig groot getal" binnen de reele getallen (of een subset daarvan). Het is simpelweg niet gedefinieerd. De functie "delen door" werkt niet als het tweede argument nul is.

Daarom...

... is dit geen goed voorbeeld van hoe een functie zich hoort te gedragen bij deling door 0.

Wiskundig gezien niet, maar binnen de IEEE754 standaard geeft deling door 0 het infinity-bitpatroon (tenzij je er een sigfpe-trap voor zet), of NaN wanneer de teller ook 0 is. De meeste interpreted talen verhullen dit, want veiliger.

[jbdeiman]

RobIII schreef op vrijdag 17 maart 2017 @ 11:56:
[...]

Simpel:

code:

for (int i = 1; i < 100; i++) {
  print foo / i;
}

In zo'n geval (e.v.a.) is i gegarandeerd nooit 0. Als je overal braaf die "controle" loopt te doen "omdat regels" ben je je tijd aan 't verdoen.

Sowieso is een controle in veel gevallen onzin, daar is de DivisionByZero exception voor en die kun je dan afhandelen hoe je wil. Je kunt overal wel een "if divisor == 0 then throw MyException('mag niet!!1')" of "if divisor == 0 then Message('mag niet!!1')" inbouwen maar het netto-effect blijft hetzelfde: je zult met die case moeten omgaan/afhandelen (en dus lekker gewoon de DivideByZeroException handlen, die is er niet voor niets). En dan heb ik het wel voornamelijk over 'wat dieper gelegen code' of 'libraries' etc; natuurlijk kijk je expliciet(er) naar divisors bij user-input etc. (dus code die wat meer "aan de oppervlakte" ligt).

[...]

Dat is toch precies wat ik zeg?

[...]

Dat is dan wat ik ook bedoelde toen ik zei dat je vooraf controleert (dit kan ook doordat jij de controle hebt over de input voor de deler) dat de deler correct is (ongelijk aan 0). Ik had mogelijk je reactie verkeerd gelezen/ geïnterpreteerd, excuus daarvoor.

Sissors schreef op vrijdag 17 maart 2017 @ 12:51:
[...]

Dat is het verschil tussen de interpretatie van wiskundige en bijvoorbeeld ingenieurs. Bij wiskundige kan het inderdaad niet. In mijn gebied (elektrotechniek) is delen door 0 algemeen geaccepteerd als correct iets wat oneindig als resultaat heeft.

Dit dus, wiskundig "kan het niet" maar zoals ik ook uitlegde is het voor "mij" een bepaling van hoe vaak iets ergens in past

[PageFault]

Sissors schreef op vrijdag 17 maart 2017 @ 12:51:
[...]

Dat is het verschil tussen de interpretatie van wiskundige en bijvoorbeeld ingenieurs. Bij wiskundige kan het inderdaad niet. In mijn gebied (elektrotechniek) is delen door 0 algemeen geaccepteerd als correct iets wat oneindig als resultaat heeft.

Ik weet niet waar jij elektro gestudeerd hebt...

In de wiskunde kan het niet, maar door gebruik van limieten te maken, nadert het oneindig, maar oneindig * 0 is geen 1!

Mij leerde ze ooit: "delen door nul is gelul." Door met limieten te werken, kun je door rekenen, denk een beetje als in jouw geval de wortel van -1. In de wiskunde is i² = -1, da's wezelijk iets anders dan stellen dat i = sqrt(-1). Echte mannen gebruiken hier natuurlijk de letter j voor

Als je elektrotechneut bent, weet je ook als een van de weinige wat het oudste beroep is van de wereld...

[ Voor 3% gewijzigd door PageFault op 17-03-2017 13:48 ]

[Rannasha]

PageFault schreef op vrijdag 17 maart 2017 @ 13:47:
[...]
In de wiskunde kan het niet, maar door gebruik van limieten te maken, nadert het oneindig,

Ook niet eens, want

lim (x->0) 1 / x

is niet gedefinieerd, want de functie 1/x gaat richting de hele grote positieve getallen als je x=0 van bovenaf nadert, terwijl het naar de hele grote negatieve getallen gaat als je van onder richting x=0 gaat.

Maar dat buiten beschouwing gelaten, het "invullen" van een niet-gedefinieerde functiewaarde door de limiet-waarde is een vies trucje dat, om het maar even zo te zeggen, vooral door ingenieurs gebruikt wordt

Het is enkel toegestaan (wiskundig) als de functie continu is in het punt in kwestie. En dat is 1/x absoluut niet.

[Onbekend]

Nu ik hier over nadenk is het vreemd dat standaard programmeertalen bij delen door 0 een andere foutmelding geven dan als er een overflow ontstaat bij bijvoorbeeld 1 / 0.00000000000001.

Zelf programmeer ik voornamelijk in een zogenaamde high level language waarbij we per variabele aangeven wat de minimum en maximum waarde mag zijn. Hierdoor mag ik rustig delen door 0 en komt in die betreffende variabele de maximum waarde te staan.
(Zelf heb ik liever ook C# o.i.d. waarbij ik dit soort fouten sneller kan vinden en corrigeren. )

[Hydra]

Onbekend schreef op vrijdag 17 maart 2017 @ 19:33:
Nu ik hier over nadenk is het vreemd dat standaard programmeertalen bij delen door 0 een andere foutmelding geven dan als er een overflow ontstaat bij bijvoorbeeld 1 / 0.00000000000001.

Hoezo? Het zijn toch gewoon andere situaties? Delen door nul kan gewoon niet. 1 delen door 0.00000000000001 is hetzelfde als 1 delen door 0.1 met als enige 'probleem' dat het misschien niet past (wat raar is, want 10^14 past prima in een float).