While-Schleife Endet zu früh



  • richtig lösen würdest du dein problem wahrscheinlich wenn du einen int für die schleife nehmen würdest und den double wert dann jedes mal berechnest



  • KN4CK3R schrieb:

    richtig lösen würdest du dein problem wahrscheinlich wenn du einen int für die schleife nehmen würdest und den double wert dann jedes mal berechnest

    Und falsch lösen indem du den Code verwendest den du hier gepostet hast. 🤡
    An double liegt das nicht, so schlimm sind die Rundungsfehler nun auch wieder nicht.

    Gehen wirs mal anders an: Wie kommst du denn darauf dass die Schleife nicht oft genug ausgführt wird ?
    Kann das nchct auch ein Problem in der Zeichenlogik sein - oder hast du das wirklich nachgeprüft ?



  • Danke für die idee ich werde es gleich mal versuchen.
    Der Schleifenabbruch entstand wie schon erwähnt jedoch durch die Übergabe eines Termes an meine Mathlogic der ein E-Format beinhaltet, das Seltsame dran war nur das er mir keinen Fehler ausgegeben hat, was eigentlich passieren sollte. Zumindest tut es dies, wenn ich nur einen Wert mit einem E-Format berechnen lasse



  • So Funktion wurde umgeschrieben jedoch mit dem selben Problem.
    Bei einem Test hatte ich das selbe Problem das ich ab einem Bestimmten Punkt nahe 0 ein E-Format erhatlen habe.
    Die Ausgabe der Messagebox war:

    VarX = -1.989999999998506E-05 j = 549 increse = 0.0182149

    xMax = 10.0 (double)
    xMin = -10.0 (double)
    width = 1098 (double)

    double increse = Math.Round((xMax - xMin) / width, 7); 
    Points[,] myPoints = new Point[4, (int)((xMax - xMin) / increse)+1];
    int j = 0;
    string VarX;
    
    while(j < myPoints.Length/4)
       {
       // i = Math.Round(i, 7); ;
       // VarX = i.ToString("F20");
       VarX = (xMin + (j * increse)).ToString();
       if (VarX.Contains('E'))
          {
             MessageBox.Show("VarX = " + VarX + " j = " + j.ToString() + " increse = " +increse.ToString());
          }
          j++;
       }
    


  • E Format (aka scientific notation) vermeidet man z.B. mit Formatstrings:

    number.ToString("F9"); //9 decimals fixedpoint
    

    Wobei das gar nicht das Problem ist, das eigentliche Problem ist dein Design. Ein Taschenrechner sollte NIE einen string zum Rechnen brauchen!
    Ausgabe ist ok, aber nicht zur Berechnung deines Terms.
    Und bei der Ausgabe kannst du die wissenschaftliche Notation verwenden, oder eine Lösung von Stackoverflow: Double to string conversion without scientific notation nutzen.



  • Wenn ich keinen String als Term benutzten soll, stellt sich die Frage wie ich Beispielsweise "sin(3*(2+4*4))" berechnen kann.

    Mein aktueller Ansatz übergibt meiner Klasse Mathlogic den Term als String
    dieser sucht nach der innersten klammer "(2+43)".
    Anschließend wird darin nach dem Rechenzeichen mit der höheren Priorität gesucht in diesem Fall "
    ".
    Nun werden die Zahlen vor und nach dem Rechenzeichen gesucht "4" und "3",
    welche ich dann in double umwandele und berechnen lasse.
    Das Ergebnis setzte ich dann ein "(2+12)" usw... (14) klammer löschen ...sin(3*14) ... sin(42) ... 0.6691306063

    Meine Klass Mathlogic macht das wie ich finde auch völlig Zufriedenstellend
    nur kommt sie auf eine eingabe wie 1.999E-05*3 nicht klar.
    Höchstwahrscheinlich könnte ich das ganze auch noch abfangen
    aber ob ich dies nun in der Klasse tue oder schon vor dem Aufruf dafür sorge,
    dass sowas nicht vorhanden ist macht für mich keinen Unterschied.



  • Gobbles schrieb:

    Wenn ich keinen String als Term benutzten soll, stellt sich die Frage wie ich Beispielsweise "sin(3*(2+4*4))" berechnen kann.

    Ganz einfach: Du parst den Inputstring, baust einen Baum und arbeitest diesen ab.



  • Sollte das Sarkasmus sein gehen wir nun besser zurück zu Produktivem, falls nicht hab ich keine Ahnung von was du da redest



  • Das war kein Sarkasmus.
    Du kannst deinen Ausdruck mit einem Algorithmus wie z.B. dem Shunting-yard algorithm parsen.
    Ist zwar keine einfache, dafür aber eine sehr elegante Lösung. Dann musst du nicht mehr mit strings rumhantieren und dein Problem ist auch gelöst. 😉



  • Hab mir das nun mal angeschaut Ansich auch interessant nur finde ich das kaum Eleganter gelöst.
    Da auch hier genauso viel beim Auslesen beachtet werden muss in welcher Reihenfolge was abgearbeitet wird
    und auch hier müsste ich es bei dem Einlesen abfangen das bei einer Zahl wie 1.99E-05 beispielsweise das - nicht als Operator
    sondern zu der Zahl an sich gehört. Kurz gesagt ich lande beim Selben Problem,
    welches ich nun aber schon Zufriedenstellend gelöst hab durch das toString konvertieren mit dem Parameter "Fxx"



  • Gobbles schrieb:

    [...]nur finde ich das kaum Eleganter gelöst.

    Woher stammt nur diese Obsession von Anfängern mit Eleganz? Versteh erstmal die Grundlagen und dann, wenn das Grundwissen sitzt und Du anfängst tatsächlich zu verstehen worum es geht, dann darfst Du anfangen über Eleganz zu reden. If anything, dann ist Eleganz eine Folge von guten Lösungsansätzen...

    Gobbles schrieb:

    [...]welches ich nun aber schon Zufriedenstellend gelöst hab

    Ich sage nur: http://de.wikipedia.org/wiki/Dunning-Kruger-Effekt

    Lies den Artikel und versteh was es mit Dir zu tuen hat.

    Und nein, wenn Du INTERN einen Zahlenwert erst in einen String verwandeln mußt um ihn dann wieder in einen Zahlenwert zu parsen dann ist das mit an Sicherheit grenzender Wahrscheinlichkeit ein mieses Design. Ebenso wenn Du eine while-Schleife benutzt um eine for-Schleife zu simulieren, dann ist auch das ein schlechtes Zeichen. Dein Code stinkt im Sinne von: http://en.wikipedia.org/wiki/Code_smell



  • Gobbles: Nimm einfach meinen Parser für mathematische Formeln 😉

    Dort ist auch ein Graph-Programm (inkl. Source-Code) in einem der unteren Beiträge als Anhang.



  • loks sollte man wohl besser ignorieren, zum einen weil ich mir nicht anhören muss das ich mein können unterschätze ohne mich überhaupt zu kennen und zweitens warum sollte man zwingend eine For-schleife nehmen obwohl eine While-schleife ca 5-7% schneller ist? In sofern spar dir Sinnlose Kommentare.

    Th69 schrieb:

    Gobbles: Nimm einfach meinen Parser für mathematische Formeln 😉

    Danke für das Angebot, aber ich würde das gerne eigenständig machen.
    Durch Copy-Paste ist die Lernkurve nicht so groß 😉



  • Gobbles schrieb:

    loks sollte man wohl besser ignorieren, zum einen weil ich mir nicht anhören muss das ich mein können untüberschätze ohne mich überhaupt zu kennen [...]

    ftfy. Und loks hat schon Recht ...

    Gobbles schrieb:

    [...] und zweitens warum sollte man zwingend eine For-schleife nehmen obwohl eine While-schleife ca 5-7% schneller ist? [...]

    R O F L M A O !



  • Gobbles schrieb:

    eine While-schleife ca 5-7% schneller ist?

    Da bin ich aber auf eine Erklärung gespannt 😃



  • Gobbles schrieb:

    loks sollte man wohl besser ignorieren, zum einen weil ich mir nicht anhören muss das ich mein können unterschätze ohne mich überhaupt zu kennen

    Das hat loks auch gar nicht ausdrücken wollen, sondern eher das Gegenteil dessen.

    Gobbles schrieb:

    und zweitens warum sollte man zwingend eine For-schleife nehmen obwohl eine While-schleife ca 5-7% schneller ist? In sofern spar dir Sinnlose Kommentare.

    Schwupps, nur haste keine Fachleute mehr im Thread. Die helfen zwar gern, aber man kennt auch die Grenzen.

    Gobbles schrieb:

    Durch Copy-Paste ist die Lernkurve nicht so groß 😉

    Aber auch nicht, indem man das Infinite-Monkey-Theorem zur Grundlage des Wissenserwerbs macht.



  • Hatte das vor einiger Zeit mal gestestet

    private void Button_Click_1(object sender, RoutedEventArgs e)
            {
                DateTime dtstart = DateTime.Now;
                int iMax = 200000000;
                int check = 0;
                for (int i = 0; i < iMax; i++)
                {
                    check++;
                }
                DateTime dtende = DateTime.Now;
                TimeSpan tszeit = dtende - dtstart;
                LBAusgabe.Items.Add("For-Schleife : " + tszeit.Seconds.ToString() + "." + tszeit.Milliseconds.ToString() + "sec");
            }
    
            private void Button_Click(object sender, RoutedEventArgs e)
            {
                DateTime dtstart = DateTime.Now;
                int iMax = 200000000;
                int check = 0;
                int i = 0;
                while (i < iMax)
                {
                    check++;
                    i++;
                }
                DateTime dtende = DateTime.Now;
                TimeSpan tszeit = dtende - dtstart;
                LBAusgabe.Items.Add("While-Schleife : " + tszeit.Seconds.ToString() + "." + tszeit.Milliseconds.ToString() + "sec");
            }
    

    habs eben nochmal laufen lassen und folgende Ergebnise bekommen

    For Schleife in (sec)
    0.149
    0.143
    0.145
    0.145
    0.163
    0.154
    ~ 0.14983333

    While Schleife in (sec)
    0.145
    0.152
    0.150
    0.143
    0.145
    0.151
    ~ 0.14766666



  • volkard schrieb:

    Schwupps, nur haste keine Fachleute mehr im Thread. Die helfen zwar gern, aber man

    vielleicht auch besser Anfangs wurden ja noch interessante Aussagen getätigt die auch zur Problemlösung beitragen wollten.
    Aber mittlerweile wird man ja nur noch angegangen weils für einige hier wohl nicht der sauberste weg ist darauf kann ich gern verzichten...
    Ich bin zufrieden so wie es ist und nachdem das Problem der E-Formen nun auch gelöst ist finde ich momentan keinen weiteren Fehler in meinem Rechner,
    egal welchen Term ich Eingebe bekomme ich ein Ergebnis welches bis auf 15-Nachkommastellen genau ist.
    Selbst Funktionen wie sin(1/x) die nahe X=0 recht wild werden bekommt er mindestens genau so gut hin wenn nicht sogar noch besser als mein grafischer Casio Taschenrechner.

    In sofern bedanke ich mich bei all dennen die sich bemüht haben mir zu helfen

    cya


  • Administrator

    Gobbles schrieb:

    habs eben nochmal laufen lassen und folgende Ergebnise bekommen

    For Schleife in (sec)
    0.149
    0.143
    0.145
    0.145
    0.163
    0.154
    ~ 0.14983333

    While Schleife in (sec)
    0.145
    0.152
    0.150
    0.143
    0.145
    0.151
    ~ 0.14766666

    *hust*
    http://msdn.microsoft.com/en-us/library/system.datetime.now.aspx

    System                   | Approximate Resolution
    -------------------------+-------------------------------
    Windows NT 3.5 and later | 10 milliseconds
    Windows 98               | 55 milliseconds
    

    The Now property is frequently used to measure performance. However, because of its low resolution, it is not suitable for use as a benchmarking tool.

    Du misst Mist.

    Die Leute wollten dir hier anfangs noch helfen, aber du lieferst hier ein Paradebeispiel des Dunning-Kruger-Effekts.

    Es wäre aber ehrlich gesagt durchaus noch interessant zu sehen, wie denn deine MathLogic Klasse aussieht. Hier wollen dir sehr kompetente Leute helfen, damit du dich verbessern kannst. Die haben zum Teil langjährige Erfahrungen und haben schon deutlich komplexere Probleme gelöst. Du hast somit zwei Optionen. Komm von deinem hohen Ross herunter und lern dabei etwas. Oder ignoriere die Leute und mach dich dabei mit solchen seltsamen Aussagen noch lächerlich. Ich empfehle dir die erstere Option. Damit kommst du weiter.



  • warum ich wegen dem DataTime.Now misst Messe kann ich gerade nicht ganz nachvollziehen,
    da ich es für beide gleichermaßen Nutze sollte die Ungenauigkeit keine Rolle spielen. Falls ich mich darin irren sollte so klär mich auf 😉

    Ich finde das hat weniger was mit einem hohen Ross als eher damit zu tun "wie man in den wald hineinruft so schallt es heraus" aber gut *absitz*

    hier hast du meine Klasse

    https://www.dropbox.com/s/nmgpipp2rphylrp/Mathlogic.cs


Anmelden zum Antworten