Bug im Basic? Super Simpel aber hää?

Es gibt 8 Antworten in diesem Thema, welches 1.775 mal aufgerufen wurde. Der letzte Beitrag (30. März 2014 um 17:42) ist von spider-j.

  • Moin,

    habe gerade meiner Freundin bisschen Basic gezeigt und ganz simpel angefangen und schon ist etwas passiert, was ich nicht verstehe.

    Wieso kommen hierbei so komische Zahlen raus? (Reale Hardware als auch im Vice)

    10 for a 0 = to 10 step 0.1
    20 print a
    30 next a

    Die Zahl 3,7 gibt es z.B. gar nicht. Das ist doch ein Rechenbug, wieso entsteht das so?

    VG

    Trockenmodus ein... Jacke trocknet... deine Jacke ist jetzt trocken!

  • Die Zahl 3,699999 ist halt ein Rundungfehler und der setzt sich dann fort. (8bit-) Fließkommazahlen sind Rundungsfehler anfällig, genau deswegen gab es BCD-Code.
    Bitte melde dich an, um diesen Link zu sehen.


    mit
    10 for a = 0 to 100 step 1
    20 print a*0.1
    30 next a

    umgehst du am einfachsten so ein Problem.

    Das Problem gibt es aber auch bei jüngeren Sprachen: Bitte melde dich an, um diesen Link zu sehen.

    sl FXXS

    Bitte melde dich an, um diesen Link zu sehen.  Bitte melde dich an, um diesen Link zu sehen.

  • Die Zahl 3,7 gibt es z.B. gar nicht. Das ist doch ein Rechenbug, wieso entsteht das so?

    Warum das so ist, wurde Bitte melde dich an, um diesen Link zu sehen. mal ganz gut erklärt.

  • Danke euch beiden, sehr interessant!

    Ich lese es morgen noch mal durch und gehe jetzt schlafen. Da raucht mir ja der Kopf!

    Aber noch mal: Danke!

    Trockenmodus ein... Jacke trocknet... deine Jacke ist jetzt trocken!

  • Der Vollständigkeit halber: Das Problem hat mit der verwendeten Programmiersprache nichts zu tun, und es lässt sich auch nicht durch das Verwenden größerer Datentypen lösen.
    Zum Vergleich:
    Im gewohnten Dezimalsystem lässt sich die Zahl 1/3 nicht mit endlich vielen Dezimalziffern exakt darstellen. Das Gleiche gilt für 1/6, 1/7, 1/9, 1/11, ...
    Da das Binärsystem nun auf der Zahl 2 basiert und diese im Gegensatz zu der 10 des Dezimalsystems nicht den Primteiler 5 hat, lassen sich im Binärsystem nun z.B. auch die Zahlen 1/5 und 1/10 nicht mit endlich vielen Ziffern exakt darstellen.
    Es mag ungewohnt sein, aber: Ob eine Zahlendarstellung periodisch ist oder abbricht, liegt nicht am Wert der Zahl selbst, sondern an der Basis des verwendeten Zahlensystems. Im 3er-System wäre selbst der Wert 1/3 nicht mehr periodisch, sondern würde als "0.1" dargestellt. Dafür wäre dort dann 1/2 periodisch.
    BCD-Darstellung löst das Problem nicht; man erreicht damit lediglich, dass die Darstellungsprobleme auf die des Dezimalsystems reduziert werden. Bei 1/3 hilft es also nicht.

    Programmierer müssen sich dieses Problems bewusst sein und bei Bedarf eine entsprechende Lösung benutzen (z.B. statt mit gebrochenen Euro-Beträgen lieber mit ganzzahligen Cent-Beträgen rechnen), es gibt dafür keine Universallösung. Zwar gibt es für einige Programmiersprachen wie z.B. Python auch entsprechende Support-Libraries (die die Werte intern dann z.B. als Brüche behandeln), aber dann muss der Programmierer trotzdem noch wissen, in welchen Fällen er sie benutzen sollte.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Danke Mac Bacon, dass hab ich sogar nun verstanden!
    Du solltest Dozent werden! ;)

    Ich frage mich nur, wenn das Basic als Ebene schon zwischen Benutzer und Prozessor ist und ich sage, er soll in 0.1 Schritten hochzählen, dann könnte doch das Basic so schlau sein und es so interpretieren, das korrekte Werte rauskommen. Immerhin kann man es wie oben im Beispiel ja auch anders berechnen.

    Also könnte ein Betriebssystem schon dafür sorgen, das der Benutzer sich keine Gedanken machen müsste.

    Aber das ist ja auch nur Theorie und so ist die Praxis ja nicht und von daher auch egal ;)

    Trockenmodus ein... Jacke trocknet... deine Jacke ist jetzt trocken!

  • Also könnte ein Betriebssystem schon dafür sorgen, das der Benutzer sich keine Gedanken machen müsste.

    Ich dachte für sowas wäre Windows zuständig :bgdev


  • Ich frage mich nur, wenn das Basic als Ebene schon zwischen Benutzer und Prozessor ist und ich sage, er soll in 0.1 Schritten hochzählen, dann könnte doch das Basic so schlau sein und es so interpretieren, das korrekte Werte rauskommen. Immerhin kann man es wie oben im Beispiel ja auch anders berechnen.


    Es gilt aber immer noch die alte Regel: Ein Computer tut das, was Du schreibst, nicht das was Du willst.

    Mit den Fußangeln, die bei den Berechnungen mit den Fließkommazahlen auftreten können, beschäftigt sich die numerische Mathematik. Und in der Anwendung bei Computern lernt man da so ziemlich am Anfang, daß man FOR-Schleifen niemals (nie, nicht) mit gebrochenen Schrittweiten verwenden sollte, eben weil sich da die Rundungsfehler beliebig aufakkumulieren können - und zwar völlig unabhängig von gewähltem Computer, Betriebssystem und Sprache. Braucht man aber so eine Abfolge von Zahlen, so setzt man die FOR-Schleife stets nur als Zählschleife ein, und rechnet die Werte der Folge an Hand der ganzzahligen Laufvariable mit einem Rechenausdruck aus, genauso wie FXXS das gemacht hat.

  • Ist letztlich bei der mathematischen "Vorlage", also Folgen, Reihen usw. übrigens ebenfalls so, dass die Indizees immer aus der Menge der Natürlichlichen Zahlen sind (je nachdem nimmt man höchstens noch die 0 dazu).