Stammtisch & Kaffeekranzerl

    Zitat von Wemir

    Also spielt die Größe der verrechneten Zahlen eine Rolle.

    bei gegebenem Typ, aber nicht für die Auswahl/Zuweisung des Typs. Das sind zwei unterschiedliche Dinge und hier reden wir wohl von unterschiedlichen Dingen. Ich sprach die ganze Zeit von der Typzuweisung. Daher auch mein Einwand.



    Zitat von Wemir

    Aber ich sprach ja nicht von einem Fehler sondern von einer Fehlermeldung und die ist meines Erachtens nicht so klar festgezogen. Eine Warnung könnte man zum Beispiel durchaus auch als Fehlermeldung verstehen, ich kann also meine Einschränkung, es sei nur eine Warnung, zurücknehmen.

    ich würde hier dann doch deutlicher unterscheiden und eine Fehlermeldung meldet eben einen Fehler und für eine Warnung bekommst du eine Warnmeldung.

    Wenn du das alles unter Fehlermeldung subsumieren willst, ok...macht die Sache halt unnötig unklar, aber schön das wir das geklärt hätten.



    Zitat von Wemir

    Mein übergeordneter Punkt ist allerdings in diesem lockeren Sinne ist sogar "NA" eine Fehlermeldung, jedenfalls wenn es bis zum Ende mitgeschleppt wird. Denn wenn ein numerisches Ergebnis erwartet wird, ist damit klar, dass die Berechnung irgendwo nicht richtig ausgeführt wurde. Gegenüber dem Fall, wo der integer overflow mit der Vergabe eine Werts im Wertebereich gelöst wird, der nicht das mathematische Ergebnis sein kann, und man insgesamt ein Ergebnis bekommt, dem man aber ohne Kenntnis des tatsächlichen Ergebnis über "ist numerisch" hinaus, nicht ansieht, dass es falsch ist.

    abgesehen von dem Terminus "Fehlermeldung" stimme ich dir hier voll zu, guter Punkt.


    edit: mir ist jetzt aber doch nochmal eingefallen. Ganz so toll ist es am Ende doch nicht, denn genau sowas will man eigentlich grundsätzlich vermeiden. Was sinnvoll passieren sollte, wäre dass nen Error geschmissen wird. Wenn schon nicht bei Compiletime, dann zumindest nen aussagekräfiger Error bei Runtime, wobei der Compiler aber bereits ein eingebautes Errorhandling verlangt.

    Zitat von Wemir

    Auf die 8 kommt man, weil der Abstand zwischen dem Maximum und dem Minimum des Unsicherheitsbereichs für c^2 6 beträgt.

    ah jetzt kann ich dir folgen.

    Wenn du dir anschaust was R da wirklich jeweils abspeichert und auch wie die Bitdarstellung der einzelnen Zahlen ist, dann sieht man, dass hier andere Werte zugrunde liegen, wir rechnen ja nicht mit c^2.

    Wüsste jetzt auch nicht, wie der "Unsicherheitsbereich" wie von dir dargestellt zustandekommen sollte?




    Wenn du mal die einzelnen Schritte durchgeht, dann ergibt sich:


    der korrekte Wert für c*(c+1) = 58184473363361820

    in R ist c*(c+1) = 58184473363361824


    der korrekte Wert für (c-1)*(c+2) = 58184473363361818

    in R ist (c-1)*(c+2) = 58184473363361816




    ich versuche noch herauszubekommen wo hier genau der Fehler entsteht. Also wie exakt die Mantisse da behandelt wird, dass es zu dem gegebenen Fehler kommt.



    Folgende Überlegungen hierzu:


    IEEE 754 Double Floating Point Format:


    IEEE_754_Double_Floating_Point_Format.svg



    c*(c+1) =

    (58184473363361820)10 = (11001110101101100111100001100010010001000011000000011100)2



    müsste dann wenn ich keinen Fehler gemacht habe im IEEE 754 Double Floating Point Format ergeben:

    sign| exponent | Mantisse

    0 | 10000110110 | 1001110101101100111100001100010010001000011000000011



    in R ist c*(c+1) = 5818447336336182410 = 110011101011011001111000011000100100010000110000001000002


    Wenn man jetzt aber die beiden Bitdarstellungen der beiden Zahlen gegenüberstellt:

    11001110101101100111100001100010010001000011000000011100

    11001110101101100111100001100010010001000011000000100000

    fällt auf, dass nicht nur abgeschnitten sondern auch gerundet wurde und da hänge ich aktuell noch. Da muss bei meiner Ermittlung der Mantisse oder alternativ bei der Rückrechnung noch nen Fehler sein bzw ich nen Schritt übersehen/vernachlässigen.




    Nur der Vollständigkeit halber hier noch für den zweiten Teil der Rechnung:


    (c-1)*(c+2) =

    (58184473363361818)10 = (11001110101101100111100001100010010001000011000000011010)2


    in R ist (c-1)*(c+2) = 5818447336336181610 = 110011101011011001111000011000100100010000110000000110002


    11001110101101100111100001100010010001000011000000011010

    11001110101101100111100001100010010001000011000000011000

    Stammtisch just went full Stammtisch-

    Zitat von nachdenklich

    Wenn du dir anschaust was R da wirklich jeweils abspeichert und auch wie die Bitdarstellung der einzelnen Zahlen ist, dann sieht man, dass hier andere Werte zugrunde liegen, wir rechnen ja nicht mit c^2.

    Wüsste jetzt auch nicht, wie der "Unsicherheitsbereich" wie von dir dargestellt zustandekommen sollte?


    Na das stand doch in dem FAQ.


    https://cran.r-project.org/doc…se-numbers-are-equal_003f


    Zitat

    The only numbers that can be represented exactly in R’s numeric type are

    integers and fractions whose denominator is a power of 2. All other
    numbers are internally rounded to (typically) 53 binary digits accuracy


    Und du hast da 56 Stellen in der Binärzahl. Wenn ich das richtig sehe, bekommst du die Zahl in R, wenn du entspechend der 54. Stelle rundest.


    Ergänzung: Hm, die Differenz ergibt sich wohl, weil einmal auf- und einmal abgerundet wird. Beim Aufrunden bekommst du im ersten Teil 100 dazu, beim Abrunden verlierst du 10 im zweiten Teil, zusammen 6.

    ja das da irgendwie gerundet oder einfach abgeschnitten wird ist irgendwie fast offensichtlich...

    Das es daran liegen sollte, kann ich mir auch denken, ich hätte aber gerne ne exakte Antwort.

    Insbesondere so, dass man damit dann auch den zweiten Teil korrekt herleiten kann, denn da wird irgendwie dann auf einmal doch nicht so offensichtlich einfach gerundet?!?


    (58184473363361820)10 = (11001110101101100111100001100010010001000011000000011100)2
    ergibt dann:

    1,1001110... * 255 = (-1)0 * (1 + 0,100111...) * 21078-1023 (für alle die es interessiert, das die wirklich korrekte Darstellung)


    Daraus ergibt sich für den Significand (hatte fälschlicherweise Mantisse vorhin geschrieben, das wäre aber mit der führenden 1):

    1001110101101100111100001100010010001000011000000011100

    was 55 Bits (nicht 56) sind.

    wir haben aber nur 52 Bits für den Significand:

    Wenn man also von Vorne einfach auffüllt:

    1001110101101100111100001100010010001000011000000011


    so und hier müsste nun wohl gerundet werden, aber wie und warum? So wie ich das sehe wird schlicht aufgerundet, aber warum wird aufgerundet?



    Ich würde mir auch gerne noch die exakte Bitdarstellung in R ausgeben lassen, aber da muss ich hier erst noch bissl was ändern, da hab ich jetzt schlicht nicht die Zeit zu, vllt komm ich heute Abend dazu.

    Das ist jetzt auch nicht schlimmer als sich mit Clive fetzen.



    Mir scheint du bist schon da, jedenfalls prinzipiell.


    Code
    58184473363361820

    11001110101101100111100001100010010001000011000000011100

    --------------------------------------------------------

    12345678901234567890123456789012345678901234567890123456

             1         2         3         4         5


    Da die Zahl nur mit 53 Stellen Genauigkeit codiert werden kann, wird gerundet entsprechend der 54. Stelle (1) also hier Aufrunden auf:


    Code
    11001110101101100111100001100010010001000011000000100000


    Das ist das Äquivalent von 100 (4) addieren. Und entspricht dem Wert in R.


    Code
    58184473363361818

    11001110101101100111100001100010010001000011000000011010

    --------------------------------------------------------

    12345678901234567890123456789012345678901234567890123456

             1         2         3         4         5


    Gerundet entsprechend der 54. Stelle (0) heißt Abrunden auf:


    Code
    11001110101101100111100001100010010001000011000000011000


    Das ist das Äquivalent von 10 (2) subtrahieren. Auch das entspricht dem Wert in R, den du angegeben hast.


    Also entsteht durch die Rundung eine zusätzliche Differenz zwischen den beiden Termen von 6.


    ---


    Nun wird R nicht diese beiden Terme auswerten, codieren und dann nochmal verrechnen. Sondern der ganze Ausdruck c * (c + 1) - (c - 1)*(c + 2) wird nach irgendeiner Ordnung in Schritten ausgeführt und ich nehme mal an, jede Operation mit c^2 oder den Folgezwischenergebnissen wird neu als double codiert. Wenn man das also genau nachvollziehen will, müsste man wissen in welcher Reihenfolge ausgewertet wird und die Rundung bei jedem einzelnen abgelegten Wert nachvollziehen.


    Beispielsweise bekomme ich schon bei Umstellung des Ausdrucks andere Ergebnisse, inklusive dem richtigen:


    Uuuh, neues Spiel! Wer bin ich?

    “

    Zitat von Qwayne

    Bin nur Epidemiologe am Billinda Gates und Merkel Institut für virale Propaganda

    Dein Sarkasmus ist, so wie ich es verstehe, eng verwandt mit deinem persönlichen Versagertum und ein trauriges Zeugnis dafür, dass du die Lage einfach nicht verstehst. Sad but true. (Ich bin nur fair)

    Zitat von Utan

    eins, zwei, drei,..


    fünf?


    ach scheisse. Das ist einfach zu anstrengend.

    Mir gefiel das Forum noch besser, als du noch zählen konntest. Sad performance for an old peformer. Sanders?

    “

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!

Benutzerkonto erstellen Anmelden