Hallo leute, auf meinem display-simulator in bascom ist 108,03/100= 1,0799992...wie kann das sein dim a as single dim c as single a= 108,3 c= a/100 eigentlich sollte ja 1,083 oder so rauskommen....mache ich was falsch oder liegts am simulator? Gruß Manuel
Hmm... Ich meine, das hängt irgendwie mit der Taktfrequenz zusammen. Ich meine mal gelesen zu haben, dass der die Taktfrequenz zum dividieren benutzt. Dementsprechend müsstest du, um ein sauberes Ergebnis zu bekommen, wahrscheinlich einen 10MHz Quarz nehmen. Ich kann mich aber auch komplett irren und das mit etwas anderem verwechseln... Aber stell doch mal im Simulator einen Takt von 10MHz ein. Gruß Sebezahn
Das könnte an der Rechenroutine liegen. Fließkommazahlen im Dezimalsystem sind schlecht im Binärsystem darstellbar, deshalb kommt es i.a. zu Rundungsfehlern. Daß diese allerdings so groß sind... man müßte mal genau nachvollziehen, wie diese Zahlen binär aussehen, vielleicht kann man dann mehr sagen.
Hi Manuel, so funzt es Dim A As Single Dim B As Single Dim C As Single A = 108.3 B = 100 C = A / B Gruss Gerhard
@Manuel [meckermodus] ...Und wenn man die zugegeben grottenschlechte Bascom-Hilfe gelesen hätte dann wüßte man das das ,naja, "Normal" ist. Es steht drinn das die Genauigkeit nicht super ist und das irgendwo bei der x-ten Stelle Fehlert auftreten [/meckermodus] Aber ich kann dich trösten. Hab anfangs selber ne halbe stunde in dem Chaotentext rumsuchen müssen ;-)
Stimmt, da war irgendwas mit der Baudrate und einem Fehler je nach Takt... Ich meine, das wars. Gruß Sebezahn
Nö,Falschrechnen hat nix mit Geschwindigkeit zu tun. Nur der Baudratengenerator arbeitet mit festen Teilerstufen weswegen es zu falschen Baudraten kommt. Aber auch das steht im Datenblatt groß und breit drinne. ;)
danke ratber, wie aufmunternt *g ich hab in der zeit mal bisse probiert und andere chips und mhz genommen (aber nur bei bascomeinstellung) und jedes mal das gleiche ergebnis. ich finds halt nur bissel hart,daß schon bei der 3ten stelle solche fehler auftreten...jetzt konnte ich noch den fehler erkennen und anderweitig umgehen...aber wie ist es erst bei anderen werten? mh, und mit assembler? gibts da auch solche probleme? notfalls alles mathematische in assembler machen? Gruß Manuel
Wie groß der Rechenfehler ist hängt von der Routine ab. Wird se entsprechend genauer ausgelegt dann wird se aber auch größer und kostet auch mehr Rechenzeit. Und genau mit dieser aussage kann man sich jetzt vortrefflich streiten auf wieviele Stellen genau es denn sein soll. Für den einen reichen 2 Stellen und der andere fordert 10 Stellen. Wem soll man es recht machen ? Der Kompromiss ist es so genau einzurichten das man die meisten Anwendungen abdecken kann ohne unnötig Resourcen zu verschwenden. Wers genauer will der schreibt sich eben was eigenes oder nutzt nen Controller mit Hardwaremultiplizierer.
na was muß mann denn beim avr 90s/mega machen, um 5 bis 6 stellen genauigkeit zu bekommen in bascom bzw assembler ich will einfach nur, daß 108,03/100 = 1,0803 sind und nicht 1,799992... sollte doch eigentlich nich allzuviel verlangt sein für einen solchen prozessor,oder? Gruß Manuel
du klammerst dich jetzt aber etwas an die im gedächtnis recht einfach zu lösende aufgabe 108,03/100 Setz mal was anderes ein und du siehst etwas klarer. zb. 108,03/83 Für den Proz ist die Aufgabe gleich schwer aber für den Menschen dann nicht mehr so simpel wie dein Beispiel oder ? ;) Wenn ich nen Rechner wie nen PC habe der mit etlichen Megabyte und nem recht großen Rechenwerk glänzen kann ist das absolut kein Akt. Selbst der alte Z80 macht das spielend aber nen Controller ist da noch recht weit von entfernt,also ne ganz andere Klasse. Es gibt ja genug Routinen in Assembler oder C die genauer sind aber du wirst sicher schnell feststellen das die ein gewisses Maß an Platz fordern und Controller haben eben nicht soviel. Wie man Multiplikationen und Divisonen zufuß nur mit Bitmanipulationen und Additionen erledigt weißt du vieleicht. Wenn ja dann schreib einfach mal selber mit der von dir geforderten Auflösung. Du wirst merken das es ohne Zweifel lösbar ist aber es kostet auch was. Wie gesagt: Reicht es bei Bascom nicht dann eben selber schreiben. Bieleicht wird ja noch vom Hersteller drann rumgefeilt
Hallo Manuel, bei mir kommt als Ergebnis 1,083000058 (mit Bascom). Ich geh Gruß Klaus
Es gab vor nicht allzu lange rZeit noch PC-Basic-Interpreter die auch nicht viel besser waren. Die Zahl Gleitkommazahl wird auch nur in 4 Byte dargestellt. Das ist ganz normal mit der Ungenauigkeit. Wem die Hilfe zu mager ist, der kann sich ja ein Buch kaufen. E sgibt inzwischen sogar 2 deutsche Bücher zu Bascom. Ich finde die garnicht schlecht
wenn eine variable einen Wert bekommt, der mit einem Faktor verrechnet wird dann müsste der compiller das eigentlich erst ausrechnen und dann verwenden. wenn die werte feststehen warum soll der mcu damit belastet werden? aber warscheinlich liegt soetwas am programmierer: constanten definieren und der compiler machts warscheinlich so wie ichs grade fordere. hmm ist mir garnicht bewust gewesen, wenn ich am PC programmiert habe, das ich mit sowas den rechner ausbremse...
Eine Fließkommadivision braucht eine gewisse Zahl an Rechenschritten wenn man es in software macht. Je mehr Nachkommastellen desto mehr Rechenaufwand. Das dürfte ja wohl einleuchtend sein oder ? Klar,im PC hab ich ja nen Coprozessor der sowas in einigen Takten erledigt.Da merkt man es nicht.Die meisten vergessen es immer weil er ja seit 486 integriert ist. Ich empfehle den Rechner mal mit abgeschalteten Copro zu betreiben.Ein besseres Aha-Erlebnis gibbet wohl kaum ;) Aber die meisten Controller haben eben keinen Copro also muß es eben Softwaremäßig erledigt werden. Die Megas zb. haben nen Hardwaremultiplizierer den man dafür ranziehen kann aber der muß auch vom Compiler genutzt werden. Ob Bascom das macht kann ich nicht bezeugen aber ich vermute es einfach mal da ich noch nicht nachgerechnet habe.
wenn die antwort zum meinem post gehörte: ich meinte eher, feste zahlen also konstanten sollten von hand ausgerechnet (PC) werden und dann in die mcu übernommen werden. der pc hats schließlich einfacher und der wert im mcu ist immer der selbe. brauch also nicht immer neu berechnet werden (zb bei jedem starten des mcu) deshalb: wenn möglich mit konstannten arbeiten und alle möglichen berrechnungen vorher von "hand machen"
Ja schön ,das setze ich mal generell vorraus das man Konstanten auch gleich als Konstanten eingibt aber wir reden von Berechnungen und die kann man ja nicht im vorraus erledigen. Oder wie meinst du das ? Ich kann dem Sinn deines Posts nicht so recht folgen.
Für den Privatgebrauch kann man natürlich Genauigkeit und Geschwindigkeit optimieren. Im professionellen Gebrauch müssen aber die Bibliotheken gewissen Standards genügen und darauf muß man sich auch verlassen können. Bei C-Compilern werden Kommazahlen oft im IEEE-754 Standard dargestellt. Das ist ein 32Bit Wert, wobei die Mantisse 23 Bit groß ist. Damit ist eine Genauigkeit von 5...6 Dezimalstellen erreichbar. Ich hab mal das obige Beispiel mit Borland-C auf dem PC bzw. Keil C51 auf dem 8051 getestet. Das Ergebnis war das gewünschte und auch bei beiden gleich. Exakt kann man im Binärsystem nicht durch 10 teilen, deshalb runden die Bibliotheken 9-er Perioden auf. Diese Rundung läßt sich über einen Compilerschalter abschalten. Z.B. kommt bei der Division nach IEEE-754 Standard 108,03 / 100 = 1,08029997 raus und wird dann automatisch auf 1,0803 gerundet. Wenn der Bascom nicht den IEEE-754 Standard einhält, muß dann ja irgendwo stehen, welcher maximaler Fehler z.B. bei der Division entstehen kann. Gibt es keinerlei zugesicherte Aussagen über die Genauighkeit, würde ich Bascom nicht nehmen. Peter
Wie ich schon sagte stehts in der Hilfe zu Bascom das es Fehler gibt.
Einmal:
"Floating-Point Complications
Every decimal integer can be exactly represented by a binary integer;
however, this is not true for fractional numbers. In fact, every number
that is irrational in base 10 will also be irrational in any system
with a base smaller than 10.
For binary, in particular, only fractional numbers that can be
represented in the form p/q, where q is an integer power of 2, can be
expressed exactly, with a finite number of bits.
Even common decimal fractions, such as decimal 0.0001, cannot be
represented exactly in binary. (0.0001 is a repeating binary fraction
with a period of 104 bits!)
This explains why a simple example, such as the following
SUM = 0
FOR I% = 1 TO 10000
SUM = SUM + 0.0001
NEXT I%
PRINT SUM ' Theoretically = 1.0.
will PRINT 1.000054 as output. The small error in representing 0.0001
in binary propagates to the sum."
--------------------
Und
--------------------
"General Floating-Point Concepts
It is very important to realize that any binary floating-point system
can represent only a finite number of floating-point values in exact
form. All other values must be approximated by the closest
representable value. The IEEE standard specifies the method for
rounding values to the "closest" representable value. BASCOM supports
the standard and rounds according to the IEEE rules.
"
Soweit ,sogut.
Der Rechenfehler der offensichtlich existiert sollte also nicht
auftreten.
Da er es dennoch tut gehe ich mal davon aus das er auf der
"Todo-Liste" steht und irgendwann gefixt wird.
Derzeit kann ich aber damit leben.
Als Workaround kann man die Werte zur Berechnung ja im Exponenten um
einige Stellen verschieben.
Hallo,
Bei Meinem Bascom im 2313 kommt bei :
Cls
A = 108.03
C = A / 100
Home
Lcd "A= " ; A
Lowerline
Lcd "C= " ; C
folgendes heraus :
A= 108.029998778
C= 1.080299971
Der größte Fehler besteht also schon in der Variablen,
schon vor der Rechnung ...
Warum rechnet jedes Bascom anders ?
3 Leute, drei andere Ergebnisse
Hmm Interessant. Ich probier deine Zeilen. Mal sehen was der M16 sagt.
Yo,das bekomm ich exact auch. Hab gerade mal nachgelesen. ab der 6. Nachkommastelle gibt es das Problem. Begrenz mal deine Berechnungen auf 5 stellen (Nüste ja reichen oder ?) dann stimmts wieder.
Mir reicht das...... ich hatte ja das Problem auch nicht ich wurde nur neugierig weil jeder was anders herausbekam, ich denke aber das sie nicht im Chip sondern nur im Simulator getestet haben .. Gruss HansH
Yo,ich Teste aus gewohnheit fast nur im Chip (Ok ,ich weiß.Kostet Zeit usw. usw.) da ich die 1000-10000 Schreibzyklen eh nie voll bekomme. Ich hab mal folgendes versucht: A = 10803 C = A / 10000 A wird dann richtig als 10803 angezeigt aber C dann wieder mit diesem Fehler. Offensichtlich taucht der Fehler nur auf wenn eine Nachkommastelle nicht null ist. Sehr seltsam aber vorerst muß man damit leben
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.