Jetzt reicht es ! Java rechnet nicht richtig.

Hackpod

Hackpod

Aktives Mitglied
Thread Starter
Dabei seit
08.02.2009
Beiträge
892
Reaktionspunkte
29
Hallo,

Ich hab ein ziemlich komisches Problem. Mein Java Programm rechnet nicht richtig. :confused:

Hier ein kurzer Auszug:
Code:
void gPreis(){
        
        rechnerPreis= Preis*Nachte;
        System.out.println("Der Preis für "+Name+" beträgt "+rechnerPreis+" €");
        
    }
    
    void pPreis(){
       
        
        prozentPreis= (50/100)*rechnerPreis;


Statt der Hälfte von den Preisen wird immer Null ausgegeben.
Bis jetzt konnte mir noch keiner helfen.
 
hab zwar mit Java nichts am Hut, aber Versuch mal 50.0/100.0 bzw. achte darauf dass du nicht mit Ganzzahlen rechnest.

edit: 0.5*rechnerPreis könnte natürlich auch klappen :)
 
  • Gefällt mir
Reaktionen: Hackpod
Funktioniert wirklich ! Komisch :/
 
Nicht komisch sondern logisch. Schreibst du

Code:
x=50/100

geht Java von einer Integer-Rechnung aus.

schreibst du

Code:
x=50.0/100.0

geht Java von einer Gleitkomma-Rechnung aus.

Eigentlich sind das Grundlagen zu Java
 
  • Gefällt mir
Reaktionen: redweasel und volatus
wenn man zwei Ganzzahlen (also eine Zahl ohne Nachkommastellen) dividiert, kommt auch wieder eine Ganzzahl raus, und aus 0.5 wird halt 0.
 
Und das kann dir auch bei anderen Sprachen als bei Java passieren. Also am besten bei Float-Konstanten immer einen Punkt mit angeben.
 
  • Gefällt mir
Reaktionen: gishmo, dark.rider, iCode und 3 andere
Nicht komisch sondern logisch.
Ist überhaupt nicht logisch. Um das logisch zu finden benötigt man eine Vorbildung-/schädigung durch Programmiersprachen.

Die Division ist bei ganzen Zahlen nunmal nicht uneingeschränkt möglich (Z ist kein Körper). Das logischste wäre deswegen entweder, dass da eine rationale Zahl bei rauskommt (50/100 = 1/2, bzw. in Ermangelung dessen die Annäherung durch ein Fließkommazahl) oder dass das Programm einfach abstürzt (bzw. eine Ausnahme ausgelöst wird).
 
Zuletzt bearbeitet:
Ist überhaupt nicht logisch. Um das logisch zu finden benötigt man eine Vorbildung-/schädigung durch Programmiersprachen.
Leider stimmt das - meistens herrscht die Meinung "das wird schon immer so gemacht, das ist logisch und richtig" obwohl es für den Rest der Welt der größte Quatsch überhaupt ist
Genau der gleiche Schwachsinn wie "bäbäbä ein Kilobyte sind aber 1024 Bytes und nicht 1000 wie es der Rest der Welt macht - das ist halt so und wer das nicht weiß ist blöd"...
 
Ganz unrecht hat Modcat aber nicht, denn diese Rechenweise wurde so nunmal von den Entwicklern festgelegt. Wenn Java diesen Vorgaben folgt, ist das Ergebnis gemäß der Rechenweise richtig.
Dass man sich bei obigem Beispiel vielleicht ein etwas anderes (intelligenteres) Verhalten von Java wünscht, ist ja nachvollziehbar, aber eine entsprechend intelligent rechnende Divisionsfunktion müsste dann vom Entwickler auch so programmiert werden, dass es alle Eventualitäten abdeckt. Das macht eine solche Funktion in der Regel erheblich langsamer, was auch nicht unbedingt gewünscht ist, wenn man eine solche "Intelligenz" gar nicht benötigt, dafür aber eine schnelle Funktion (weil man Beispielsweise viele Zahlen dividieren muss). Ich finde es daher durchaus sinnvoll nur die simple Variante zur Verfügung zu stellen und den Programmierer eines Programms dann im Einzelfall entscheiden zu lassen, welche Funktion er nun braucht (der Programmierer wird ja wohl am besten Wissen welche Zahlen(typen) er an der Stelle des Programms verwendet).
 
Ganz unrecht hat Modcat aber nicht, denn diese Rechenweise wurde so nunmal von den Entwicklern festgelegt. Wenn Java diesen Vorgaben folgt, ist das Ergebnis gemäß der Rechenweise richtig. [...]
Was das ganze aber noch lange nicht *logisch* macht. Einfach nur ein weiterer unnötiger Stolperstein.

Dass man sich bei obigem Beispiel vielleicht ein etwas anderes (intelligenteres) Verhalten von Java wünscht, ist ja nachvollziehbar, aber eine entsprechend intelligent rechnende Divisionsfunktion müsste dann vom Entwickler auch so programmiert werden, dass es alle Eventualitäten abdeckt.
Intelligent muss da gar nichts sein. Ein simple Lösung die kein Stück Geschwindigkeit kostet wäre: <integer>/<integer> -> <double> plus Einführung eines extra Operators für die Integer-Division, wenn man sie denn wirklich mal braucht.
 
@Darii: Logisch ist das Ergebnis deswegen, weil Java gemäß der Vorgaben gerechnet hat. Dass vielleicht eine andere Funktionalität besser oder "intuitiver" ist, mag ja durchaus stimmen, aber Java hat eben gehalten, was der Entwickler versprochen hat.
 
  • Gefällt mir
Reaktionen: PeTerminator und sagovana
@StarSirius: Jetzt reite bitte nicht auf der Definition von logisch rum. Das ist albern, denn du weißt genau was ich gemeint habe.
 
Was, Java kann NOCH langsamer werden?? :sick::suspect:

Spar dir diese Mär.. Die stimmt nicht....

@Darii: Logisch ist das Ergebnis deswegen, weil Java gemäß der Vorgaben gerechnet hat. Dass vielleicht eine andere Funktionalität besser oder "intuitiver" ist, mag ja durchaus stimmen, aber Java hat eben gehalten, was der Entwickler versprochen hat.

Das Verhalten ist logisch. Es wurden zwei Integer durch einen Operator miteinander verknüpft. Dabei kommt wieder ein Integer heraus. So verhält sich IMHO jede C-ähnliche Programmiersprache. Mit Intuition hat das absolut nichts zutun weil Intuition sich von Individuum zu Individuum aufgrund unterschiedlicher Erfahrungen unterscheiden kann. Da will niemand, der eine Programmiersprache entwirft, sich drauf einlassen. Wer sagt denn dass da ein Double herauskommen soll? Wieso nicht ein Tupel aus Integer und Rest?
 
Intelligent muss da gar nichts sein. Ein simple Lösung die kein Stück Geschwindigkeit kostet wäre: <integer>/<integer> -> <double> plus Einführung eines extra Operators für die Integer-Division, wenn man sie denn wirklich mal braucht.
Oh, man braucht sie durchaus. Wenn du Double-Variablen benutzt, also <double>/<double> (nichts anderes ist .x btw.), kommt auch <double> raus. Rechnest du <integer>/<integer>, so kommt <integer> raus. Bildet für mich den besten Kompromiss aus Intuition, Schnelligkeit und Schreibeffizienz.
 
  • Gefällt mir
Reaktionen: _ebm_
@_ebm_: Dass Integer/Integer ein Integer ergibt, hat nichts mit Logik zu tun, das hat nur mit der Definition des Operators zu tun (eine Definition hat nichts mit Logik zu tun). Aber deine Worte fassen es eigentlich gut zusammen:

Wer sagt denn dass da ein Double herauskommen soll? Wieso nicht ein Tupel aus Integer und Rest?

Beides wäre möglich, kommt eben drauf an, was der Entwickler/Programmierer gerne haben möchte.

Mit einer "intuitiveren" Funktion (ich habe intuitiver ja extra in Anführungsstrichen gesetzt) meinte ich eher eine Funktion, die der üblichen Division in den rationalen/reellen/komplexen Zahlen entspricht, an die wohl die meisten Menschen denken, wenn sie an Division denken (dabei bildet die Division in die rationalen/reellen/komplexen Zahlen ab). Das wurde hier ja auch von vielen angeprangert (und darüber lässt sich auch durchaus diskutieren).
 
e der üblichen Division in den rationalen/reellen/komplexen Zahlen entspricht,

Und da haben wir ein Problem. Wir befinden uns im Definitionsbereich in der Menge er Ganzen Zahlen. Wir haben also eine Abbildung f: o(a,b) -> c; a, b el Z. Klar wissen wir, dass der Operator o (Division) über die Ganzen Zahlen nicht abgeschlossen ist. Aber wenn wir uns an die Grundschule erinnern, lernten wir dort dass als Ergebnis ebenfalls eine Ganze Zahl und ein gewisser Rest entsteht.

Logik hat in meiner Anschauung übrigens sehr wenig mit dem zutun was im menschlichen Kopf passiert (das wäre Intuition), sondern mit Mathematik. (Aussagenlogik, Prädikatenlogik,....)
 
Oh, man braucht sie durchaus.
Da bestreite ich nicht, aber wie oft? Ich habe sie bis jetzt vielleicht 1, 2 Mal gebraucht (und daran kann ich mich nichtmal erinnern).

Am besten gefällt mir da noch die Smalltalk-Lösung: 4/2 gibt 2 und 5/2 gibt 5/2 (also einen Bruch).

Für den Fall dass es auch schnell sein soll würde ich den Python3-Weg vorziehen. 4/2 gibt 2.0, 5/2 gibt 2.5 und 5//2 gibt 2.
 
Da bestreite ich nicht, aber wie oft? Ich habe sie bis jetzt vielleicht 1, 2 Mal gebraucht (und daran kann ich mich nichtmal erinnern).
Also das kommt wohl gänzlich auf das Programm an. ;)
Mein letztes Projekt für die Uni nutze die Integerdivision deutlich häufiger. Wobei... eigentlich nur diese. Sonderlich viel Divisionen gab es gar nicht. Sekunden (um)rechnen, Pixelpositionen bzw. unser Koordinatensystem, welches wir über die Pixel "gelegt" haben - da braucht man nirgendwo Kommazahlen.


Für den Fall dass es auch schnell sein soll würde ich den Python3-Weg vorziehen. 4/2 gibt 2.0, 5/2 gibt 2.5 und 5//2 gibt 2.
Und in Java bestimmst du die Ausgabe eben nicht über den Operator, sondern über die Eingabe. Meine Güte, so ist es eben. Für mich praktisch, da kann jeder denken was er will. Ändert es ja letztlich eh nicht.
 
Zurück
Oben Unten