Rechnen mit Texbox

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    Rechnen mit Texbox

    Hi

    Ich erstelle gerade ein Projekt zur Gewichtskontrolle.

    Mit diesem Code rechne ich.

    VB.NET-Quellcode

    1. Dim textb1 As Double = CDbl(CDbl(TextBox_Anfangsgewicht.Text))
    2. Dim textb2 As Single = CDbl(CDbl(GewichtTextBox.Text))
    3. 'Dim textb2 As Single = CSng(CDbl(GewichtTextBox.Text))
    4. AbgenommenTextBox.Text = CStr(textb2 - textb1)


    Es wir auch gerechnet. Nur die Kommastellen sind falsch siehe beigefügtes Bild bei Abgenommen

    Das verstehe ich jetzt nicht.
    Bilder
    • abgenommen.jpg

      29,16 kB, 578×390, 123 mal angesehen
    Ach ja, das alte Thema. Ein Computer arbeitet mit 1 und 0 => binäres System => bestimmte Nachkommagenauigkeiten sind mathematisch nicht immer zu erreichen. Du kannst es mit dem Variablentyp Decimal probieren. Ist z.B. für die Verwendung bei Währungen geeignet. Da würde mit anderen Typen ein kleiner Nachkommafehler bei unserer Wirtschaft Millionen Euro Differenzen zwischen berechnet und Realität ausmachen.
    btw: was soll Cdbl(Cdbl(Ausdruck)) bringen? Wozu ein doppelter ToDouble-Cast? Und warum mit TextBox arbeiten, wenn man ein NumericUpDown verwenden kann? Sonst trägt RodFromGermany noch seine geliebten »Rouladen mit Klößen« in die Textboxen ein.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    Folgender Sachverhalt:

    Dein jetziger Code:

    VB.NET-Quellcode

    1. Dim anfangsgewicht as Single = CDbl("100.3")
    2. Dim aktuellesGewicht as Double = CDbl("115.7")
    3. Console.WriteLine(CStr(aktuellesGewicht-anfangsgewicht))
    4. 'OUTPUT: 15.3999969482422



    Kleinere Änderung:

    VB.NET-Quellcode

    1. Dim anfangsgewicht as Double = CDbl("100.3")
    2. Dim aktuellesGewicht as Double = CDbl("115.7")
    3. Console.WriteLine(CStr(aktuellesGewicht-anfangsgewicht))
    4. 'OUTPUT: 15.4


    EDIT1:
    Was fällt dir da auf, woher könnte da eine Ungenauigkeit kommen?
    Und ja, das mit dem NumericUpDown macht ebenfalls mehr Sinn. ("Rouladen mit Klößen" :D )
    Wenn das Leben wirklich nur aus Nullen und Einsen besteht, dann laufen sicherlich genügen Nullen frei herum. :D
    Signature-Move 8o
    kein Problem mit privaten Konversationen zu Thema XY :thumbup:

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Acr0most“ ()

    @manni4545: Mir fällt grad ein: Du kannst natürlich auch einfach mithilfe von Math.Round entsprechend runden. Und Dim X As Single = CDbl … kann man mit Option Infer On auch zu Dim X = CDbl … kürzen, da dann eigenständig ermittelt wird, von welchem Typ X zwangsläufig ist.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    Kurz Off-Topic: @VaporiZed: Bitte niemals Gleitkommazahldatentypen für Währungen nehmen. Niemals.
    Das sollte man eig. relativ früh in der Schule bzw. der Ausbildung lernen, dass man Geldbeträge intern nicht als Kommazahl sondern als Ganzzahl darstellt: 1,56€ = 156 Euro-Cent. Denn diese Rundungsfehler treten bei Ganzzahlen nicht auf (wie denn auch?). Und so lassen sich auch bspw. in der Bankfiliale genaue Kommazahlen darstellen, ganz ohne Rundungsfehler.

    ichduersie schrieb:

    Das sollte man eig. relativ früh in der Schule bzw. der Ausbildung lernen, dass man Geldbeträge intern nicht als Kommazahl sondern als Ganzzahl darstell: 1,56€ = 156 Euro-Cent.


    Dies ist mir weder in der Ausbildung, noch in der Schule mitgeteilt worden.
    Es geht hier zudem auch um Gewichtsangaben, die man ggf. auch in etwas genaueren Bereichen ausgerechnet haben möchte.

    Und ein Abweichendes Ergebnis beim Minus kann m.M.n. nicht an iwelchen Rundungsfehlern, sondern maximal an der Verwendung unterschiedlicher Datentypen oder deren Konvertierung liegen.

    LG Acr0most
    Wenn das Leben wirklich nur aus Nullen und Einsen besteht, dann laufen sicherlich genügen Nullen frei herum. :D
    Signature-Move 8o
    kein Problem mit privaten Konversationen zu Thema XY :thumbup:
    Bitte nicht murks mit murks ausbessern.
    Das:

    Acr0most schrieb:

    VB.NET-Quellcode

    1. Dim anfangsgewicht as Double = CDbl("100.3")
    2. Dim aktuellesGewicht as Double = CDbl("115.7")
    3. Console.WriteLine(CStr(aktuellesGewicht-anfangsgewicht))

    sollte so aussehen:

    VB.NET-Quellcode

    1. Dim anfangsgewicht as Double = Double.Parse("100.3")
    2. Dim aktuellesGewicht as Double = Double.Parse("115.7")
    3. Console.WriteLine(aktuellesGewicht-anfangsgewicht)

    Edit:
    Eigentlich sollte man mit Double.TryParse erst überprüfen ob da auch verwertbare Zahlen drinstehen.
    @ichduersie: Ehm … Dass man einfache Rechenaufgaben mit Centbeträgen gut hinbekommt, ist mir durchaus bewusst. Aber viel Spaß mit Zins, Zinseszins und Co. Dort mit Integern zu arbeiten kostet einem zum Glück nicht den Job in der Finanzbranche. Man bekommt ihn nämlich gar nicht erst.
    Für Währungen wurde laut MSDN der Decimaltyp entwickelt:

    Microsoft schrieb:

    It is particularly suitable for calculations, such as financial, that require a large number of digits but cannot tolerate rounding errors.

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    EaranMaleasi schrieb:

    murks mit murks ausbessern.


    Ja - ok. Ich wollte eigentlich nur veranschaulichen bzw. nachfragen, ob er sieht, dass da verschiedene Datentypen im Einsatz sind. - ohne den eigentlichen Code zu verbessern.

    Beim nächsten Mal werde ich es gleich nach besten Wissen und Gewissen überarbeiten. ~ Danke für die Info ;)

    LG Acr0most
    Wenn das Leben wirklich nur aus Nullen und Einsen besteht, dann laufen sicherlich genügen Nullen frei herum. :D
    Signature-Move 8o
    kein Problem mit privaten Konversationen zu Thema XY :thumbup:
    Die "Rouladen mit Klößen" waren lecker. Danke für die Bereitstellung. :thumbsup:
    @manni4545 Gerechnet wird nicht mit TextBoxen, sondern mit Zahlen :!:
    Gerechnet wird immer mit demselben Datentyp, bei Gewichtsangaben würde ich Double präferieren.
    Vermischungen führen, wie wir gesehen haben, zu ungereimtheiten.
    Auf n Stellen wird erst bei der Anzeige gerundet.
    Das passiert beim DataGridView im CellFormatting-Event:

    VB.NET-Quellcode

    1. Private Sub DataGridView1_CellFormatting(sender As Object, e As DataGridViewCellFormattingEventArgs) Handles DataGridView1.CellFormatting
    2. If e.Value Is Nothing Then
    3. Return
    4. End If
    5. If e.ColumnIndex == 2 Then ' Deine Spalte von oben
    6. Dim content = String.Format("0:0.0 g", e.Value) ' eine Nachkommastelle
    7. e.Value = content ' den Ausgabetext wieder e.Value zuweisen
    8. Dim style = e.CellStyle ' Farben und Font zur Übung, kannste natürlich weglassen
    9. style.ForeColor = Color.Red
    10. style.SelectionForeColor = Color.Yellow
    11. style.Font = New Font(Me.Font, Me.Font.Style Or FontStyle.Bold)
    12. e.CellStyle = style
    13. End If
    14. End Sub

    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    <offtopic>
    Generell bzgl. der Verwendung von Index und Name:
    Nimmt man bei sowas wirklich den ColumnIndex @RodFromGermany?
    Wenn man hier eine Spalte aus welchen Gründen auch immer hinzufügt, muss man an x Stellen im Code die Abfragen anpassen.
    Sollte man da nicht auf den eigentlichen Column-Namen zugreifen?
    Oder liegt das wie so oft im Auge des Betrachters?
    </offtopic>
    Wenn das Leben wirklich nur aus Nullen und Einsen besteht, dann laufen sicherlich genügen Nullen frei herum. :D
    Signature-Move 8o
    kein Problem mit privaten Konversationen zu Thema XY :thumbup:

    Acr0most schrieb:

    Nimmt man bei sowas wirklich den ColumnIndex
    Name ist sicherer, Integer geht schneller.
    Bei mir kommt das Hinzufügen von Spalten selten vor, ich seh meine DataTable und zähle ab. Außerdem mach ich da noch ein Debug.Assert() rein.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    ichduersie schrieb:

    Bitte niemals Gleitkommazahldatentypen für Währungen nehmen.

    Hör ich zum Ersten mal. Da formatiert und umrechnet man sich ja nen Wolf wenn man die Beträge in nem Grid oder sonst wo anzeigen will... Zumal der Wert ja am Ende doch mit Komastellen angezeigt werden muss... Klingt für mich nach Redundanz.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    mrMo schrieb:

    Redundanz
    Nein.
    Informiere Dich mal, wie Banken rechnen. Da müssen die Zinsen stimmen, und die werden bankintern mit 4 Stellen nach dem Euro-Komma gerechnet.
    Da ist das Runden von Werten schon eine juristische Angelegenheit.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!