@John422 Wo ist das Problem?
Und:
Seit wann arbeitet VB6 mit einem Framework?
Passe Deinen Thread-Header an.

@John422 Komisch.
Ich hab mal fix ne XML-Serialisierung gebaut, da steht <0> drin.

Was für ein Booleanwert kommt für Foo raus, wenn Du schreibst Dim Foo = LA.fReserviert = 0?

Du hast es doch selbst geschrieben.

John422 schrieb:

in einer externen Datenbank gibt es in einer Tabelle mit einer Spalte fBestand vom Typ Decimal (25,13)

Da sollten also 13 Nachkommastellen stehen.

Wenn du eintippst
Dann macht er das auch so und die Datenbank macht da nix anderes.

Der Decimal Datentyp ist kein Gleitkommawert, oder? Das wird der Hauptgrund sein.
Ein Vergleich sollte nicht scheitern, denn die Differenz ist ja 0 egal wie viele Stellen.

Mich würde interessieren, was er abgreift wenn die Spalte decimal(25,0) wäre und du in der DB 0.000000000001 einträgst. Kannst ja mal ausprobieren.

Das sind ja völlig ungeahnte Eigenschaften

John422 schrieb:

In meiner Vorstellung liegen für einen Decimal 16 Bytes im RAM rum.

Offensichtlich hängt da noch eine Format-Information dran.
Da müsste man z.B. eine speziell designte Klasse binär serialisieren, um das rauszukriegen.

Offensichtlich hängt da noch eine Format-Information dran.

Es sieht tatsächlich so aus, als hätte ein Decimal-Wert eine Format-Info an Bord, die von der Variable höherer Genauigkeit übernommen wird:

Bei einer Gleitkommazahl sind das ja, ich sag mal, tatsächlich Kommazahlen. Deswegen gibts da manchmal diese kleinen Wertverrutschungen, weil nicht jede Kommazahl in so und so vielen Bits existieren kann.
Ich denke der Decimal Datentyp als Festkommazahl ist in Wahrheit ein Integer, der zusätzlich eine Kommastelle wegspeichert. Quasi 500E-4, 0E-13
Wenn man mit BigInteger arbeitet, dann bastelt man sowas z.B. selbst, weil es keinen BigDecimal gibt.

RodFromGermany schrieb:

Das sind ja völlig ungeahnte Eigenschaften

Ich find das einen erstaunlichen Bug.
Zwei gleiche Dinge müssen, wenn sie auf gleiche Weise ausgegeben werden, auch gleich aussehen.
Double zB macht keine solche Sperenzchen:

ErfinderDesRades schrieb:

Ich find das einen erstaunlichen Bug.

Da pflichte ich Dir wohl bei. Ich habe gesucht und nix dazu gefunden.
In C# sieht es genau so aus.
Vielleicht kann @Löffel was dazu sagen.

ErfinderDesRades schrieb:

Zwei gleiche Dinge müssen, wenn sie auf gleiche Weise ausgegeben werden, auch gleich aussehen

Das stimmt doch nicht:
​5000E-2 = 500E-1 = 5E1 Das ist alles 1 Ding, nämlich die Zahl 50. Alle diese Darstellungen existieren dennoch.

klar kann man dieselbe Zahl verschieden "darstellen" - und du scheinst mit darstellen eher 'code formulieren' zu meinen.
Ich sprach aber von Ausgabe. Damit meine ich Ausgabe im allgemeinen, also ob über .ToString formatiert, oder innerhalb einer Serialisierung, oder innerhalb von Dataset.WriteXml oder whatever.
Wenn der Gleichheits-Operator ergibt, dass zwei Dinge gleich sind, dann soll auch das ausgegebene gleich sein - sofern beides auf dieselbe Weise ausgegeben wird.

zb bei ausgabe per .ToString: "0" ist nicht das gleiche wie "0.000" - und das darf nicht sein.

Das ist doch ein grundlegendes logisches Gesetz, dass bei a = b auch gilt: a.ToString = b.ToString

Oh hm, würde nicht mitgehen, dass das ein "logisches Gesetz" ist, vielleicht ist das ein Gesetz im VB.Net Code, weiß ich nicht.

Aber ich verstehe sehr wohl, was du meinst.

Habe auch mal mein Beispiel versucht einzutippern.
VS nimmt kein 50.00D , stutzt der so auf 50D.
Wenn man 50.00 haben möchte muss man 50 + 0.00D schreiben.
Also die 0 sticht da wirklich raus.

Gleichzeitig, wenn ich = implementieren müsste, dann guck ich bei String = String einen anderen Algorithmus an als bei Dec = Dec
Ich denke, was ich sagen möchte ist, ich finde das nicht schlimm, mir gefällts sogar.

Haudruferzappeltnoch schrieb:

Oh hm, würde nicht mitgehen, dass das ein "logisches Gesetz" ist

glaub mir, es ist ein mathematisches Gesetz: Sind zwei Dinge gleich, so sind auch ihre Abbildungen gleich.
Argumentieren kann ich das schlecht, weil mit logischen Argumenten die Grundlagen der Logik zu begründen - da müssen Leute wie Popper, oder Russel ran - mir wird da glaub zu schnell ein Kreis-Schluss unterlaufen.

---

Aber ich habe jetzt herausgefunden, dass sich in .Net 0 tatsächlich von 0.000 unterscheidet:
Der Code liest die 16 Bytes der Decimal-Struktur aus.


Hier das schockierende Ergebnis:

Gut, da haben wir nun drei Fachgebiete, die sich sicher alle nicht in alle Punkten einig sind, Mathematik, Informatik und Logik.
Also Informatisch gilt hier offensichtlich: a=b und a.ToString <> b.ToString.
Mathematisch gilt: a=b => f(a) = f(b)
Und logisch gilt damit folglich: ToString ist keine Abbildung.

Irgendwo muss eine Festkommazahl ja auch die Kommastelle speichern, die Bits können nicht gleich sein.

Haudruferzappeltnoch schrieb:

Und logisch gilt damit folglich: ToString ist keine Abbildung.

eine originelle Folgerung.
Also .Tostring ist für alle mir bekannten Datentypen eine Abbildung, ausser für den Decimal-Datentyp beim Wert 0.

Oder liege ich falsch? Gibt es noch weitere Datentypen, wo gelten kann a=b und a.ToString <> b.ToString ?

---

Aber in meim Vorpost hatte ich Unrecht: 0 kann durchaus intern verschieden dargestellt werden, weil ist ja egal, wie die Skalierung gesetzt ist - ergibt ja immer 0.
scheint mir zwar nicht so schlau, intern solche Differenzen zuzulassen, aber ich habs bei dene ja auch nicht zu sagen.