Problem mit Variablen vom Typ Double

[Vampirmonster]

Ich teste gerade PureBasic, um zu sehen, ob diese Programmiersprache was für mich ist oder nicht.

Ich habe mir die Linux-Demoversion herunter geladen.

Folgendes Programm habe ich programmiert um ein bisschen mit Zahlen und Ausgaben zu experimentieren, ist also kein super ernst zu nehmendes Programm, sondern damit will ich nur austesten wie die Dinge unter PureBasic funktionieren :

Code: Alles auswählen

OpenConsole()

PrintN("Ausgabe von Fließkommazahlen :")

PrintN("")

a.d = 12 / 8.78

PrintN(StrD(a.d))

PrintN("")

b.d = 10.123456789012345678

Print(StrD(b.d))

c.d = 10.1234567890123456789

Print(StrD(c.d))

Endlos:

Goto Endlos

Nun zu den Problemem :

1.) Problem

In Zeile 17 wird c.d = 10.1234567890123456789 als Fehler angezeigt mit der Meldung "Numerical overflow: too many digits."

Zeile 17 muss ich also schon mal weglassen oder mit ; (REM) in einen Kommentar umwandeln.

Offensichtlich stören PureBasic so viele Stellen nach dem Komma. Kann man was dagegen tun ? QBasic und QuickBasic haben viele Stellen nach dem Komma nicht gestört, die wurden einfach abgeschnitten, die die zu viel waren, und fertig.

2.) Problem

a.d = 12 / 8.78

PureBasic zeigt auf dem Terminal folgendes an :

1.3667425968

Das ist alles. Selbst mein programmierbarer Taschenrechner zeigt da mehr Nachkommastellen an, und auch das alte QBasic hat mehr Nachkommastellen gekonnt, nämlich 15 Stellen nach dem Komma, mit der 1 vorne weg also 16 signifikante Stellen.

Was läuft hier schief ? 10 Stellen nach dem Komma ist ganz bestimmt kein Double, und .f stattdessen zu benutzen bringt auch nichts.

Was mache ich da falsch ?

3.) Problem

b.d = 10.123456789012345678 wird auf dem Bildschirm als 10.1234567890 ausgegeben, also dasselbe Problem wie unter 2.)

4.) Problem

Muss man in PureBasic wirklich hinter jeder Variablen den Typbezeichner anhängen ? also .f oder .d und so weiter ?

Gibt es sowas wie DEFDBL A-Z was es unter QBasic und QuickBasic gibt ?, simpel und einfach.

Wie handhabt man das unter PureBasic am besten ?

LG

[Kiffi]

Hallo,

Informationen über Variablen findest Du hier: http://www.purebasic.com/german/documen ... ables.html

4.) Problem

Muss man in PureBasic wirklich hinter jeder Variablen den Typbezeichner anhängen ? also .f oder .d und so weiter ?

Nein, nur einmal. Beispiel:

Code: Alles auswählen

Define b.d
b = ...

Und ein EnableExplicit am Anfang Deines Codes ist nicht verkehrt. Damit wirst Du gezwungen, alle Variablen, die Du in Deinem Code verwendest, zu deklarieren. Das bedeutet zwar mehr Tipparbeit, schützt aber zugleich vor Tippfehlern und langem Suchen nach Fehlern in Deinem Code.

Grüße ... Peter

P.S.: Gewöhn Dir das mit dem Goto am besten sofort ab.

[NicTheQuick]

Zu 1.: Im Grunde ist die Fehlermeldung praktisch, da so der Programmierer darauf hingewiesen wird, dass eine Double nicht mehr Stellen speichern kann und er sich nicht darauf verlassen kann, dass die letzte angegebene Stelle mit in die nächsten Rechenoperationen genommen wird.

Zu 2.: Die Lösung ist einfach bei StrD() den zweiten Parameter zu nutzen und die Anzahl der Nachkommastellen selbst festzulegen. Siehe auch die Hilfe dazu

Wird diese[r Parameter] nicht angegeben, wird die Zahl auf 10 Nachkommastellen gesetzt und die abschließenden Nullen entfernt.

Zu 3.: Siehe 2.

Zu 4.: Du kannst mit Define.d am Anfang alle Variablen automatisch Double sein lassen.

Code: Alles auswählen

Define.d
a = 12 / 8.78
Debug StrD(a, 15)

Davon rate ich aber ab, da das schnell zu Fehlern führt. Stattdessen einfach einmal definieren und das reicht auch schon.

Code: Alles auswählen

Define.d a, b, c
a = 12 / 8.78
b = 1 / 3
c = Pow(2, 0.5)
Debug a
Debug b
Debug c

Alle anderen Variablen bleiben weiterhin Integer. Selbst wenn du nicht Define benutzt, reicht es auch beim ersten mal den Suffix .d mitzugeben, danach musst du das nicht mehr tun.

Code: Alles auswählen

a.d = 12 / 8.78
Debug a

Und wenn du darauf hingewiesen werden möchtest, dass du Variablen nicht anständig definiert hast, dann lege ich dir EnableExplicit ans Herz.

Code: Alles auswählen

EnableExplicit

a.d = 1 / 3.0
Debug a

P.S.: Gewöhn Dir das mit dem Goto am besten sofort ab.

Da stimme ich zu. In den seltensten Fällen hilft Goto den Code zu vereinfachen. In deinem Fall wäre ein Input() besser gewesen um den Programmfluss zu stoppen. Damit wird auch nicht unnötig CPU-Zeit vergeudet.

[Vampirmonster]

Ja, Leute hassen das arme GOTO

Vielen Dank für eure Tipps !

LG

[NicTheQuick]

Ja, Leute hassen das arme GOTO

Ich hasse es nicht, denn es gibt immer noch Einsatzgebiete, in denen es den Programmfluss vereinfachen kann.

[Vampirmonster]

Ja, finde ich auch

[Josh]

Zu 4.: Du kannst mit Define.d am Anfang alle Variablen automatisch Double sein lassen.

Code: Alles auswählen

Define.d
a = 12 / 8.78
Debug StrD(a, 15)

Davon rate ich aber ab, da das schnell zu Fehlern führt.

Ist seit Pb 5.60 nicht mehr erlaubt

[Vampirmonster]

@Josh

Danke für den Hinweis.

[GPI]

Ja, Leute hassen das arme GOTO

Ich hasse es nicht, denn es gibt immer noch Einsatzgebiete, in denen es den Programmfluss vereinfachen kann.

Mag sein. Aber es ist wie ein Schleudersitz in Flugzeug: Nur weil er da ist, muss man nicht bei jeder Gelegenheit drauf hauen. zu 99% gibt es deutlich elegantere Methoden als ein Goto.

Gosub kann man dagegen ersatzlos streichen. Proceduren übernehmen die Funktionalität vollständig und sind deutlich flexibler.

[Kurzer]

OFFTOPIC

P.S.: Gewöhn Dir das mit dem Goto am besten sofort ab.

Also ich nehme das Goto noch immer sehr gerne, wenn ich am Anfang von Prozeduren diverse Bedingungen prüfe und bei Nichtbestehen dann die Prozedur mit Fehler abbreche.

Die folgende Version finde ich gerade bei etwas längeren Prozeduren viel übersichtlicher (weil linearer)...

Code: Alles auswählen

Procedure MeineProc()
	Protected.i iFehler	
	
	If Bedingung1 = #False : iFehler = 1 : Goto ErrorExit: EndIf
	If Bedingung2 = #False : iFehler = 2 : Goto ErrorExit: EndIf
	If Bedingung3 = #False : iFehler = 3 : Goto ErrorExit: EndIf
	
	;Mache das was gewünscht ist
	ProcedureReturn #OK
	
	ErrorExit:
	ProcedureReturn iFehler
EndProcedure

... als diese Version mit den verschachtelten If-Abfragen. Da kriege ich meist einen Knoten im Hirn, weil man zum Erfassen der Logik immer vom If zum Else springen muss. Schlecht wenn da zwei Bildschirmseiten Code zwischen liegen.

Code: Alles auswählen

Procedure MeineProc()
	If Bedingung1 <> #False
		If Bedingung2 <> #False
			If Bedingung3 <> #False
				;Mache das, was gewünscht ist.
				ProcedureReturn #OK
			Else
				ProcedureReturn #Fehler3
			EndIf
		Else
			ProcedureReturn #Fehler2
		EndIf
	Else
		ProcedureReturn #Fehler1
	EndIf
EndProcedure

/OFFTOPIC

Gruß Kurzer