sciencetalk

zie ook Tail call optimization (Een goede wiki voor programmeurs btw)

Java gaat gewoon van het grootst mogelijke getal naar het kleinst mogelijke getal.

Eigenlijk is dat java niet die dit doet maar je processor. Java geeft de opdracht om y bij te tellen bij geheugenplaats x. Vermits de overflow bit gewoon niet meer wordt verwerkt door de processor gaat die idd circulair terug naar -MAX INT. Dit is voor elke taal zo (tenzij die taal natuurlijk expliciet voor zulke omstandigheden gaat testen, maar ik ben dit soort talen nog niet tegengekomen).

Eigenlijk is dat java niet die dit doet maar je processor.

Dit gedrag staat als dusdanig beschreven in The Java Language Specification, Third Edition. Zelfs al zou je processor nog niet aan een overflow toe zijn dan nog moet een JVM dit gedrag wel zo toepassen.

Zelfs al zou je processor nog niet aan een overflow toe zijn dan nog moet een JVM dit gedrag wel zo toepassen.

Elke processor kan die 'overflow' aan. Het is gewoon een logisch gevolg van het geheugensysteem.

Elke processor kan die 'overflow' aan. Het is gewoon een logisch gevolg van het geheugensysteem.

Ook dat niet. Dat Java specificeert dat een int 32 bits bevat (1 sign bit + 31 bits voor de waarde), zegt niks over hoe die 32 bits daadwerkelijk worden opgeslagen. Of je nu Java runt op een 8, 16, 22, 531 danwel geen-bits-systeem, of je nu intern voor elke bit 1 register van 64 bits gebruikt, het maakt allemaal niet uit. In alle gevallen zal de JVM hetzelfde moeten doen. De specificatie bepaalt het gedrag. Dat de specificatie gebaseerd is op zekere historische gronden doet hier niks aan af.

Ook dat niet. Dat Java specificeert dat een int 32 bits bevat (1 sign bit + 31 bits voor de waarde), zegt niks over hoe die 32 bits daadwerkelijk worden opgeslagen. Of je nu Java runt op een 8, 16, 22, 531 danwel geen-bits-systeem, of je nu intern voor elke bit 1 register van 64 bits gebruikt, het maakt allemaal niet uit. In alle gevallen zal de JVM hetzelfde moeten doen. De specificatie bepaalt het gedrag. Dat de specificatie gebaseerd is op zekere historische gronden doet hier niks aan af.

Maar JVM houdt echt niet bij welke int je als 32 bits hebt opgeslagen, of welke als 16bit. Dat is iets dat je OS bijhoudt.

JVM zorgt bv niet dat je geheugenplaats x bij y optelt. Dat is gewoon een instructie naar je processor. JVM kan dan niet meer zeggen 'ja maar je moet het wel behandelen als een 32bit getal'.

Maar JVM houdt echt niet bij welke int je als 32 bits hebt opgeslagen, of welke als 16bit.

Dat hoeft ook niet. Dat is het hele punt. Java specificeert dat een int 32 bit is en dat als je bij het grootst mogelijke getal 1 optelt je op het kleinst mogelijke getal uitkomt. Dat heeft helemaal niks met de hardware te maken. Elk argument dat verwijst naar hardware is dus niet van toepassing.

Vind niemand hier het raar dat een moderne programmeer taal dit soort implementatie details merkbaar laat zien? Laat een integer gewoon een geheel getal zijn ongeacht de grote. Waarom zou er een MAXINT zijn? Hetzelfde voor het gebruik van een onnauwkeurige float als een rational nauwkeuriger zou zijn.

Ik geef persoonlijk de voorkeur aan programmeertalen die Arbitrary-precision arithmetic ondersteunen.

Java specificeert dat een int 32 bit is en dat als je bij het grootst mogelijke getal 1 optelt je op het kleinst mogelijke getal uitkomt.

Java geeft door naar je OS dat het om een signed 32 bit gaat. Java zegt niet dat als je aan het grootste getal komt je teruggaat naar het kleinste. Dat is het logische gevolg van de beperkingen van de hardware. Ok je kan gaan zeggen dat het complement systeem daarvoor zorgt, maar indirect komt het gewoon door hardware beperkingen.

Vind niemand hier het raar dat een moderne programmeer taal dit soort implementatie details merkbaar laat zien?

Het is een keuze en die is op een bepaalde manier gemaakt. "Raar" vind ik dan ook niet het juiste woord in deze context.

Ik geef persoonlijk de voorkeur aan programmeertalen die Java geeft door naar je OS dat het om een signed 32 bit gaat.

Je mist het punt. Java specificeert het gedrag in zijn taalspecificatie (zie het voorbeeld hier). Het gedrag heeft niks met het OS of de hardware te maken.

Je mist het punt. Java specificeert het gedrag in zijn taalspecificatie (zie het voorbeeld hier). Het gedrag heeft niks met het OS of de hardware te maken.

Ok ik vermoed dat we naast mekaar aan het discussiëren zijn. Laten we het hier bij houden

Dit:[pre] for ( A ; B ; C ) { ... }[/pre]is exact hetzelfde als:

[pre] A ; while (B) { ... ; C }[/pre]

Dus ja, iedere for-constructie is ook als while te schrijven en andersom.

Vind niemand hier het raar dat een moderne programmeer taal dit soort implementatie details merkbaar laat zien? Laat een integer gewoon een geheel getal zijn ongeacht de grote. Waarom zou er een MAXINT zijn?

Performance. Je CPU werkt nu eenmaal met dat soort begrensde integers.

Wil je willekeurig grote of nauwkeurige getallen, geen probleem, dan moet je een daarvoor geschikte class gebruiken. Reken er wel op dat intensieve berekeningen met dat soort getallen veel langzamer gaan dan "native" getallen zoals ints, floats en doubles.

niet wanneer je verplicht dat er ook iets bij A, B en C staat.

akkoord dan kan je je for-lus in een while lus omzetten, maar het is nog niet gezegd dat je daarmeel iedere while lus in een for-lus kan omzetten.

Vladimir Lenin schreef:niet wanneer je verplicht dat er ook iets bij A, B en C staat.

akkoord dan kan je je for-lus in een while lus omzetten, maar het is nog niet gezegd dat je daarmeel iedere while lus in een for-lus kan omzetten.

Dat is in geen enkele fatsoenlijke taal verplicht toch? Maar dan nog, zonodig kun je er dummy statements neerzetten, bijvoorbeeld int NegeerMij=0 voor A, en NegeerMij+=0 voor C

Inderdaad, maar zoals ik al gezegd heb worden deze opdrachten ook uitgevoerd door de computer, en bijgevolg verspil je tijd en energie voor opdrachten die bijvoorbeeld iets met 0 optellen. Maar om tot een formeel besluit te komen over deze topic:

Een for-lus en een while-lus kunnen in principe door elkaar geschreven worden maar het heeft helemaal geen nut om dat te doen.

Kan iedereen zich daar in vinden? Als dat zo is, kan deze topic beëindigt worden. (Eindelijk )