Problem bei der Divison in einem Taschenrechner!

[Zwock]

Hi an Alle!
Ich habe die Suchfunktion benutzt und den Thread für Newbie's angeschaut, konnte dort aber keine Antwort auf meine Frage finden! Leider!
Nunja, zu meinem Problem:
Ich bin in einem Informatik-Leistungskurs 11 Klasse, und wir starten mit der Programmierung eines Taschenrechners:

Grundfunktion: 3 Edit Felder, Feld 1+2 werden addiert/subtrahiert/dividiert/multipliziert und in Feld 3 als "Int" ausgegeben. (Dafür brauchten wir dann auch die StrToInt und umgekehrten Befehle)
Soweit habe ich damit auch keine Probleme, aber welchen Typ muss ich bei der Division nutzen um Kommazahlen anzeigen zu lassen? Da bei dem bisherigen Typ "Int" zB bei der Aufgabe 10 : 3, genau 3 als Ergebnis angezeigt wird! Könnt ihr mir da helfen?

Vielen herzlichen Dank im Voraus,
Dominique

[ichbins]

nimm den typ extended. dann musst du floattostr und strtofloat nehmen und außerdem statt DIV das Zeichen

Delphi-Quellcode:

/

nehmen.
Übrigens: eine Exponentielle Rechnung machst du mit

Delphi-Quellcode:

Power(basis,exponent);

um das verwenden zu können, musst du aber die Zusatzunit math einbinden (oben steht uses und dann eine Liste von Namen. Da schreibst du math, dazu.

[BenjaminH]

Dafür verwendest du am besten Real
und zum formatieren nach String StrtoFloat, bzw FloattoStr

[ichbins]

extended is viel, viel genauer als real (2,5 mal so genau)

[Zwock]

Zitat:

Zitat von ichbins

nimm den typ extended. dann musst du floattostr und strtofloat nehmen und außerdem statt DIV das Zeichen

Delphi-Quellcode:

/

nehmen.

Das war einer meiner Gedanken, jedoch wurde mir dann ein Fehler angezeigt! Vielleicht liegt es daran, dass ich den falschen Typ benutze?

Und wie ist das mit dem StrToFloat gemeint? (Das sind meine ersten Schritte in Delphi!) Ausserdem, wie ist der Code für Real? StrToReal?

[ichbins]

wie heisst den der Fehler? floattostr wandelt eine Kommazahl in einen Text um und strtofloat einen Text in eine Kommazahl.

[Zwock]

Wenn ich "/" benutze, dann zeigt er mir einen Fehler an!

Zitat:

[Fehler] Taschrenrechner.pas(54): Es gibt keine überladene Version von 'IntToStr', die man mit diesen Argumenten aufrufen kann

Zitat:

[Fataler Fehler] Project2.dpr(5): Verwendete Unit 'Taschrenrechner.pas' kann nicht compiliert werden

Wird dann angezeigt wenn ich "/" bneutze!

[ichbins]

welchen denn? wie heisst der Text von dem Fehler genau?

[Die Muhkuh]

Hi Zwock,

du musst auch FloatToStr bzw. StrToFloat anstatt IntToStr bzw. StrToInt verwenden :)

[Zwock]

Und wo liegt der Unterschied zwischen dem Typ "Float" und "Int"? Das interessiert mich jetzt ^^ Man will ja aus seinen Fehlern was für die Zukunft lernen, und nicht einfach abtippen was einem vorgesagt wird :)

Es funktioniert übrigens jetzt!
Er zeigt mir die korrekten Ergebnise bei der Division an!

[ichbins]

float is eine Kommazahl. In float kannst du z.b. den wert 1.589727489 speichern oder pi oder sqrt(2) (wurzel 2). int ist eine natürliche Zahl. Int verwendest du z.B. um dir zu merken, in welchem Schuljahr du bist, wie viel Leben der Spieler noch hat oder wie oft der PC heute schon abgestürtzt ist (ich 6 :pale: ). Float verwendest du, um dir zu merken, wie viel mhz dein PC hat (z.B. 166.666) oder alle wie viel Sekunden der PC abstürtzt (z.B. 3539.294)

[Zwock]

OkiDoki! Dann danke ich euch recht herzlich für eure Hilfe/Geduld mit mir! :D

[ManuMF]

Ergänzung:
DIV ist eine Ganzzahldivision, / eine normale.

Noch ein Hinweis: Bei Kommazahlen nimmt Delphi zwar als Trennzeichen das Komma an, wenn es im Code steht, muss aber ein Punkt verwendet werden:

Delphi-Quellcode:

Float := Eingabe * 15.23;

Gruß,
ManuMF

[Khabarakh]

[OT]

Zitat:

Zitat von ichbins

extended is viel, viel genauer als real (2,5 mal so genau)

So schlimm ist's nun auch wieder nicht :wink: . Extended hat etwa 1,3x so viele Nachkommastellen wie Real, ist also vernachlässigbar. Aber da AFAIK unter x86 immer in Extended-Genauigkeit gerechnet wird, sind die verschiedenen Typen sowieso gleich schnell, man kann also getrost Extended verwenden.
[/OT]

[dizzy]

Zitat:

Zitat von Khabarakh

[OT]

Zitat:

Zitat von ichbins

extended is viel, viel genauer als real (2,5 mal so genau)

So schlimm ist's nun auch wieder nicht :wink: . Extended hat etwa 1,3x so viele Nachkommastellen wie Real, ist also vernachlässigbar. Aber da AFAIK unter x86 immer in Extended-Genauigkeit gerechnet wird, sind die verschiedenen Typen sowieso gleich schnell, man kann also getrost Extended verwenden.
[/OT]

Dem ist nicht so :!:
Link

[ichbins]

was heisst denn dem is nich so?
ist es nicht egal, ob er jetzt 1,5 oder 15 Nanosekunden braucht um die Rechenoperation durchzuführen? und die 6 Byte zusätzlicher RAM machens auch nicht gerade aus, oder? wo ja der RAM eh von der Anwendung vorneherein verwendet wird, nämlich um nix zu speichern.

[Khabarakh]

Oh, jetzt fällt mir auch wieder ein, warum ich mich vor einem Jahr nach dem Lesen eines Posts für Double und gegen Extended entscheiden habe :mrgreen: . Danach muss ich mir aber irgendwo den Falschglauben angelesen haben :gruebel: .
Dass es in .Net nun gar keinen Extended-Typ mehr gibt, spricht auch eher dagegen.

[add] @ichbins: Bei 1,3-facher Nachkommastellenanzahl, aber dreifacher Rechenzeit würde ich es mir bei rechenlastigen Anwendungen (wozu eine Taschenrechner eher nicht zählt) doch genauer überlegen. [/add]

[ichbins]

kann ich eigentlich auch einen eigenen extended-typ (z.B. mit 100 Byte größe) schreiben? oder noch besser dynamisch? wenn ich z.B. schnell pi auf 100.000 Stellen genau berechnen will, gibt auch extended den Geist auf...

[Khabarakh]

Natürlich, hier gibt es ein paar Infos. Das wird dann aber wahrscheinlich noch viel langsamer als Real48 werden :wink: . Benutzerdefinierte Operatoren wie in .NET wären auch nicht schlecht, aber es geht auch so ganz gut.

[add] Für unendlich viele Nachkommastellen kannst du dir Hagens DEC-Math-Units anschauen, die müssen irgendwo in der DP als Anhang sein. [/add]

[dizzy]

Zitat:

Zitat von ichbins

was heisst denn dem is nich so?

Dass was da steht :)

Zitat:

Zitat von ichbins

ist es nicht egal, ob er jetzt 1,5 oder 15 Nanosekunden braucht um die Rechenoperation durchzuführen?

Es ist so lange egal wie man nur ein paar zig Operationen damit veranstanlten muss. Aber rate nun mal, warum auch die tollsten neusten Grafikkarten alle mit 32Bit Floats rechnen ;).

Zitat:

Zitat von ichbins

und die 6 Byte zusätzlicher RAM machens auch nicht gerade aus, oder? wo ja der RAM eh von der Anwendung vorneherein verwendet wird, nämlich um nix zu speichern.

Da bist du mir eine Erklärung schuldig. Warum sollte Speicher für nix alloziert werden? Richtig ist, dass nicht immer alles sofort wieder an Windows freigegeben wird (mit Delphi Speichermanager), aber nichts anderes. Einzig mit dem Wort "Alignment" ließe ich mich hier noch breitschlagen :D. (Was aber bei einem packed array of [Typ] z.B. auch wieder rausfällt.)

Es kommt nunmal immer darauf an was man machen möchte, und welcher Aspekt einem wichtig ist. Ein generelles "das ist das einzig wahre" gibt es hier imho nicht. Speziell zum Thema Extended vs. Double: Der Tradeoff ist rein rechnerisch ziemlich mies. Du bekommst ca. 125% Genauigkeit für ca. 305% der Rechenzeit. In meinen Augen recht teuer.


Ich will hier nicht sagen, dass Extended nicht sogar geeignet wäre. Kommt auf die Zielsetzung an. Jedoch finde ich es wichtig so kleine Hintergründe zu wissen um bedächtiger mit den vorhandenen Ressourcen umgehen zu können, und damit man weiss wo im Zweifelsfall Optimierungspotential vorhanden ist. Ich finde nicht dass einem Anfänger mit barschen Totalaussagen "das beste", "das schnellste" geholfen ist, da diese je nach Umstand nicht mehr zutreffen. Gerade das ist imho die Kunst der Informatik: An der richtigen Stelle die genau passende Lösungsstrategie zu finden die zum Ziel führt. Und mit Schrotflinten nach Fliegen zu schießen ist in meinen Augen nicht passend :). Das mag bei einem so kleinen Problem wie einem Taschenrechner völlig unnötig klingen, aber gerade bei Einsteiegern ist die Gefahr, dass ein solches Vorgehen auch in spätere größere Projekte geschleppt wird, groß (verständlicherweise). Von daher finde ich es wichtig von vorne herein auch für solche Spitzfindigkeiten zu sensibilisieren - nicht um jemanden zu ärgern, sondern um den Pool an Randwissen und den "Blick" für solche Dinge groß und offen zu halten. Mit "nehme ich immer" ist keinem wirklich geholfen (meistens).
Und wenn sich ein Einsteiger von so etwas zunächst erschlagen fühlt: Das legt sich mit der Zeit - das ist sicher ;) Und damit sich das schnell legt, gibt es Foren wie uns :D


Ein kleiner OT-Beitrag vom
Fabian :mrgreen:

[Zwock]

Also liebe Leute!
Nachdem ihr mir das letzte Mal so nett, schnell und kompetent geholfen habt, habe ich hier schonwieder eine Frage:

Das Prinzip bleibt das selbe.
Ein Taschenrechner mit 3 Edit Feldern, Feld 1 u. 2 werden verrechnet, das Ergebnis wird in Feld drei angezeigt. Auslöser ist ein Onclik Ereigniss auf 4 Buttons, die je für eine Rechenart stehen. Also ein Button für +, einer für - u.s.w.
Wenn nun aber bei dem Klick auf z.B. + , ein Plus zwischen den beiden Feldern erscheinen soll, was muss ich da tun?

Bisher habe ich als Onclick ereigniss folgendes benutzt:

Ein Label zwischen die beiden Felder gesetzt (Label2) und folgenden Code verwendet:

Delphi-Quellcode:

Label2.Caption:= x;

Wo liegt der Fehler, und wenn es geht bitte auch eine kleine Erklärung, man will ja aus seinen Fehlern lernen!

Danke im Voraus
Sincerly Dominique E.

[Sharky]

Hai Zwocke,

was ist x denn für eine Variable?
Oder soll in dem Label ein x stehen?
Wenn ja:

Delphi-Quellcode:

Label2.Caption := 'x';

[Zwock]

Hi Sharky!
X ist keine Variable sondern ein Text, bzw. soll als Text ausgegeben werden im Label!

[ManuMF]

Zitat:

Zitat von Sharky

Delphi-Quellcode:

Label2.Caption := 'x';

Text wird in Delphi immer in zwei ' eingegeben.

Gruß,
ManuMF