Das deutsche QBasic- und FreeBASIC-Forum

[Charly2]

Gibt es in Free-Basic keine doppeltgenauen Fließkommazahlen?
Wenn ich mit DIM X as Double ein Variable deklariere, habe ich nur
6 Stellen Genauigkeit.
Für betriebswirtschaftliche Anwendungen muß ich aber Beträge in
Millionenhöhe auf den Cent genau berechnen können.
Ist mit einer Verbesserung der Rechengenauigkeit für die kommenden Versionen vom Freebasic zu rechnen?

Mfg
Charly

[Quark48]

Hallo!

Beträge in Milltionenhöhe??!?
Dann hilft vielleicht, dass du ein paar Nuller wegtust

X# = 100.333123

100.333123 ...ist in Wirklichkeit 100333123 €

Vielleicht hilft das?
_________________
Grüßle, Stefan
***
Wenn ein Programm auf nem alten Rechner gut läuft, dann läuft´s auf nem neuen erst recht!
Ich habe/hatte keine feste Spange und auch keine Schwester. Der Rest stimmt. Es tut mir leid... :-/

[helium]

Und du bist sicher, dass du nicht Ausgabeformatierung mit interner Darstellung verwechselst?

Also intern wird zwar mit 15 Stellen gerechnet, ausgegeben werden aber weniger.
_________________
Bevor Sie aufhören sich körperlich zu betätigen sollten Sie ihren Doktor befragen. Körperliche Inaktivität ist abnormal und gefährlich für Ihre Gesundheit.

[Dusky_Joe]

in freeBASIC (wie auch in QB und VB) sind DOUBLE-Zahlen 64bit-Zahlen. Normalerweise haben die 15 Nachkommastellen und einen Zahlenbereich von -10^308 bis 10^308.
Single haben 32bit, bis zu 7 Nachkommastellen, und reichen etwa von -10^38 bis 10^38.

In welcher Situation sind denn die Zahlen so ungenau geworden?
Es wird das beste sein, du postest einfach mal ein bisschen Code.


Noch ein Tipp: Musst du von Zeit zu Zeit mit INTEGERs multiplizieren?
Dadurch kann der Typ geändert werden.

DIM a AS SINGLE
a = 1.5
PRINT 1% * a
PRINT 1! * a

Wird unterschiedliche Ergebnisse bringen; zuerst 1, und dann 1.5.
Hats geholfen?

Ciao
_________________
fully biological degradable

Once, the big wave arrives, you've got two ways, you can go:
Either, you ride it, or you don't do.
But, if you don't ride, you'll never know wether you'd have gone wet.

[Charly2]

Schön wärs ja, wenn es sich tatsächlich um 64bit Zahlen handelt.
Aber das bezweifle ich nach meinen Versuchen.
Nachfolgend ein kleines Testprogramm:

dim x as double,y as double, z as double
X = 723421.77
y = 488425.18
z = x + y
print z
print using "#######.##";z

Die Anzeige bei print z mit und ohne Using sieht wie folgt aus:
1.21185e+006

Herauskommen muß 1211846.95
Es wird also schon bei der 6. Stelle gerundet.
Bei Qbasic gibt es da keine Probleme.
Oder kommt hier jemand zu einem anderen Ergebnis?

[Dusky_Joe]

Bei mir läufts perfekt.
Das Es wird zweimal dieselbe Zahl angezeigt. Sonst würde ich ja auf nen Fehler von USING tippen, aber das wars auch ned.
Auch die Groß/Kleinschreibung (von X) macht keine Probleme. Naja FB is sowiso ned Großschreibungssensetiv...


Welche Version von FB hast du?
es ist zwar unwahrscheinlich, aber vllt ist es ein alter Fehler. Probier mal die V0.12b aus. (Windows-Download-Link
Linux-Download-Link)
_________________
fully biological degradable

Once, the big wave arrives, you've got two ways, you can go:
Either, you ride it, or you don't do.
But, if you don't ride, you'll never know wether you'd have gone wet.

[Charly2]

Bei mir läuft es jetzt auch!
Ich hatte die Version 0.10. Nach dem Download der neuesten
Version hat sich zunächst nichts geändert, wenn ich den Compiler
über die IDE gestartet habe.
Nach dem Direktstart des Compilers aus der Eingabeaufforderung
funktiionierte es dann plötzlich.
Es wird nun die Zahl mit der vollen Genauigkeit beim Print angezeigt.

Vielen Dank für den Hinweis!

Mfg
Charly

[jsammle]

Gestattet, dass ich mich hier anhänge!

Wie bei anderen Programmierdialekten fällt mir auch bei FREEBASIC auf, dass bei der COS-Funktion bei Argumenten nahe 90° DEG mit doppelt genauen Fließkommazahlen nicht exakt gerechnet wird, sondern nur bis zur ca. 8ten Nachkommastelle.

Beispiel:
dim x as double
x=89.999999*3.141592653589793238/180
print cos (x)
Ergebnis ist 1.745 329 242 813 939e-008
sollte sein 1.745 329 251 994 329e-008

Mit der entsprechenden SIN-Funktion
dim x as double
x=0.000001*3.141592653589793238/180
print sin (x)
ist das Ergebnis mit 1.745 329 251 994 33e-008 korrekt.

Ist das der Prozessor, von dem Fehler übernommen wird - falsch bzw. schlecht implementiert? Oder woher werden die mathematischen Funktionen sonst genommen?

[nemored]

Ich dachte, wir hätten im Portal einen Eintrag bzgl. Genauigkeit von Nachkommastellen, aber ich finde jetzt dort auf die Schnelle nichts.

Tatsache ist, dass das Rechnen mit Gleitkommazahlen eben einfach nicht exakt ist, sondern immer eine Ungenauigkeit beinhaltet (solange nicht ausschließlich in Zweierpotenzen gerechnet wird). In deinem Beispiel ist bereits die Zahl PI (notgedrungen) ungenau - PI ist eben nicht exakt 3.141592653589793238, sondern nur ungefähr. Damit ist auch, im Bogenmaß gerechnet, der Kosinus von 3.141592653589793238 logischerweise nicht 0. Taschenrechner arbeiten da ein wenig anders als Computer, möglicherweise mit Feststellenarithmetik, genau weiß ich das nicht. Es ist auch möglich, das hier PI intern als exakter Wert verwendet wird. Interessant wäre daher, wie du den von dir genannten "exakten" Wert ermittelst.

Wenn ich in meinem betriebssystemeigenen Rechner cos(89.999999*3.141592653589793238/180) eintippe, erhalte ich übrigens bei 64bit Genauigkeit ungefähr den Wert 1,745 329 252 017 461 657 22e-008. Kurz und gut, je nachdem in welcher Reihenfolge und mit welchen Methoden gerechnet wird, kann in so engen Zahlenbereichen das Ergebnis gar nicht exakt sein - das gibt die Maschine gar nicht her.

Übrigens: Die von dir angegebenen Ergebnisse stimmen in 16 (!) Nachkommastellen überein. Die 1 zu Beginn ist bereits die 8. Nachkommastelle!



Edit: die mit meinem Betriebssystem-Taschenrechner ermittelte Näherung deckt sich übrigens mit der des sehr exakten Arithmetik-Interpreters ARIBAS bei 192bit Genauigkeit:

[jsammle]

Calc.exe von Windows 7 pro 64 (offensichtlich eine korrekte Softwarelösung; Umkehrfunktionen probieren; Rundungsfehler bei ca. e-36 - e-46);
UBASIC von Prof. Yuji Kida (Mathematiker), geht bis ca. 5000 Stellen.

[Jojo]

[dreael]

Selber mit einem kleinen Code gespielt:

[grindstone]

Hallo!

@Charly2: Rechne doch mit Integer - bzw LongInt - Zahlen und Centbeträgen (bzw. bei Bedarf mit 1/10 oder 1/100 Cents). Dann hast du (zumindest beim Addieren und Subtrahieren) überhaupt keine Rundungsfehler.

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!

[28398]

Öh es geht hier doch um Geld? Und mit Geld spielt man nicht, deswegen nimmt man keine Floats, sondern Festkommaarithmetik.

[dreael]

[Flo]

[dreael]

Für die Interessierten: Bei Java läuft die ganze Thematik über JSR 354.

Wer einen Blick dort hineinwirft, wird feststellen, dass das Ganze eine recht komplexe API mit zig Klassen geworden ist. Unter

http://javaremarkables.blogspot.ch/2013/04/usage-examples-for-jsr-354.html

hat ein Blogger auch Beispielcode gepostet, so dass im Prinzip eine kleine Untermenge (Reduktion auf das Wesentliche) dieser API auch in FB implementiert werden könnte.
_________________
Teste die PC-Sicherheit mit www.sec-check.net