Checksumme über BigDecimal Werte

[ARadauer]

Ich habe eine Datenstruktur in der befinden sich ca 200 BigDecimal Werte.
Diese Struktur wird auch in einer Datebank abgelegt. Ich würde jetzt bei einer Neuermittlung der Werte performant herausfinden ob etwas unterschiedlich zu dennen in der Datenbank ist....

Am liebsten wäre es mir wenn ich eine Checksumme über die Werte generieren könnte. Da fehlt mir aber irgendwie der Ansatz. Wie mache ich das am Besten?

 

[ARadauer]

anzumerken ist noch dass 2.0 und 2.00 die selbe checksumme haben sollten
im moment fehlt mir der ansatz, wie ich ein big dezimal in ein byte array umwandle..

 

[SlaterB]

naheliegend ist eine Aufsummierung der Werte, vielleicht mit dem Spass von ArrayList/ String usw., den vorherigen Wert jeweils mit 31 zu multiplizierten,
wobei du dann noch leichter in Bereiche gelangst, bei denen am Ende hohe und kleine Ziffern weit auseinander liegen

kannst du die Wertebereiche etwas einschränken? geht es gleichzeitig um -0.0099, 5, 17.000 und 10^354?

schon nach 4 Zeilen weg von meiner Idee zuvor: bringe jeden Wert auf String-Darstellung a.bbbbbbb^xxx,
davon hashCode(), das dann addieren, mit 31 verschoben, am Ende ein int-Wert, nicht zu genau,
aber eine Checksumme ist ja auch keine exakte Summe, mehr ein Hashcode

Änderungen in der 17. relevanten Stelle einer Zahl werden dabei freilich nicht erkannt..,
wenn dann komplette String-Darstellung wählen, nur eben auf Probleme wie unnötige Nullen achten,
also das richtige DecimalFormat verwenden (für aufwendige Kürzung auf genau a.bbbbbbb^xxx fällt mir schon wieder gar kein Grund ein)


steht wohl nur noch dein kleines Wörtchen 'performant' im Weg?

 

[ARadauer]

Ja ich kann den Werte Bereich einschränken... geht von 1.000.000 bis 0.001
Aufsummierung ist halt auch so eine Sache..
1000
200
300
ist was anderes als
1200
100
200

Im Moment verfogle ich den Ansatz, dass ich die BigDecimal in BigInteger wandle, diese in ein byte[] array umwandle und dann daraus einen MD5 Hash erzeuge...

Ist ok für mich da es mir egal ist ob
10.1 oder 10.10001

public class CheckSumHelper {

    private static String algorithm = "MD5";
    private static BigDecimal multiplyToInteger = new BigDecimal("1000");

    public static BigInteger calcCheckSum(List<BigDecimal> values) throws IOException, NoSuchAlgorithmException {

        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        for (BigDecimal value : values) {
            baos.write(toByte(value));
        }
        
        baos.close();
        MessageDigest m = MessageDigest.getInstance(algorithm);
        m.update(baos.toByteArray());
        return new BigInteger(1, m.digest());
    }

    public static byte[] toByte(BigDecimal v) {
        return v.multiply(multiplyToInteger).toBigInteger().toByteArray();
    }
}

 

[SlaterB]

Ja ich kann den Werte Bereich einschränken... geht von 1.000.000 bis 0.001
Aufsummierung ist halt auch so eine Sache..
1000
200
300
ist was anderes als
1200
100
200

dagegen soll sicher das *31 etwas helfen,
kommt allgemein vielleicht auch darauf an, wie wahrscheinlich das ist, ob das eine die Differenz von 2 anderen Werten ist usw.,
ob mehrere Werte im Bereich von 1000-1500 schwanken usw.

theoretisch kann man auch genau beim besten Hashcode das Problem haben,
dass der eine sich
von 49054389088 auf 49054399088 ändert und der andere
von 544847598 auf 544837598

in der Summe dann.., wobei eben wieder *31

(edit: ok, schlechtes Beispiel bei der so viele Stellen des Hashcodes gleich bleiben, aber theoretisch auch gleiche Summen denkbar)

-------

gegen MD5-Aufwand kann doch toString(), mit DecimalFormat ohne 2.00, und hashCode() darauf nicht viel schlechter sein?
oder zu wenig Stellen mit int-Wertebereich?

 

[nillehammer]

Wenn es hier um eine Prüfsumme zur Erkennung von Datenfehlern und nicht um kryptograhische Anforderungen geht, warum dann nicht einfach bei den HashCodes von Java bleiben? BigDecimal hat selbst eine hashCode()-Methode (nicht sehr überraschend). Die ist so einigermaßen geeignet, dass bei unterschiedlichen Werten unterschiedliche einzelne HashCodes rauskommen. Für die "Aufsummierung" würde ich auch Standardmechanismen nutzen. Wenn Deine "Datenstruktur" ein Array ist, wäre Arrays.hashCode(...) passend. Wenn sie eine Implementierurng einer Collection ist, deren hashCode()-Methode. Zumindest bei den Klassen des JDK (ArrayList, HashSet etc.) werden die Elemente berücksichtigt. Mein Vorschlag läuft also letztlich auf etwas sehr einfaches hinaus:
Bei Arrays speicher das Ergebnis von Arrays.hashCode(...)
Bei Collections speicher das Ergebnis des hashCode-Aufrufs auf der Collection.

 

[SlaterB]

Returns the hash code for this BigDecimal. Note that two BigDecimal objects that are numerically equal but differ in scale (like 2.0 and 2.00) will generally not have the same hash code.

war im zweiten Posting noch als direkt schlecht angesprochen und der Anfang zu anderen Lösungen,
das müsste man etwas umschiffen wenn wirklich wichtig,
temporär String in guten Format oder neue BigDecimal mit einheitlichen Scale

 

[nillehammer]

war im zweiten Posting noch als direkt schlecht angesprochen und der Anfang zu anderen Lösungen,
das müsste man etwas umschiffen wenn wirklich wichtig

Tatsache! Und in dem Post sogar genau die Zahlen aus dem Javadoc-Code verwendet. Da hätte ich ja mal reinschauen könnnen! Sorry für den unnötigen Post.

[EDIT]Tja, dann würde ich mir für alle BigDecimals mit toString oder toPlainString die String-Repräsentationen holen, sie in einem String-Array speichern und dann Arrays.hashCode(...). Warnung: Ich habe auch bei den toString/toPlainString nicht nachgeschaut, ob da irgendwas anderes nicht passt. Bitte nicht hauen [/EDIT]

 

[Timothy Truckle]

Ich habe eine Datenstruktur in der befinden sich ca 200 BigDecimal Werte.
Diese Struktur wird auch in einer Datebank abgelegt. Ich würde jetzt bei einer Neuermittlung der Werte performant herausfinden ob etwas unterschiedlich zu dennen in der Datenbank ist....

Am liebsten wäre es mir wenn ich eine Checksumme über die Werte generieren könnte. Da fehlt mir aber irgendwie der Ansatz. Wie mache ich das am Besten?

Die Vorschläge der Kollegen sind ja alle ganz nett, aber "performant heist do wohl, dass der selbe Check in der DB läuft, damit die großen Zahlen nicht erst übertragen werden müssen. Wenn ist die sowieso erst aus der DB holen muss brauche ich doch den Check nicht mehr...

Also Ich würde die die Klasse [JAPI]CRC32[/JAPI] bemühen, die ist nämlich genau dafür da....

bye
TT

 

[nillehammer]

Also Ich würde die die Klasse CRC32 bemühen, die ist nämlich genau dafür da....

Sehr gute Idee, ein Standardisierter Algorithmus. Erhöht die Chance, dass die DB das auch unterstützt. Wir haben nur alle noch nicht rausgefunden, wie man aus einem BigDecimal ein byte-Array macht.

Außerdem muss die DB es doch garnicht berechnen. Bei jedem Abspeichern kann doch der von Java berechnete Wert mit gespeichert werden. Beim nächsten Select dann vorher ausgelesen werden.

 

[SlaterB]

soll der Link
CRC32 (Java Platform SE 7 )
allein dem Stichwort CRC32 dienen, falls in DB, oder tatsächlich Bytes in Java bearbeiten?

in jedem Fall ist zu bedenken, dass hoffentlich auf 2.0 vs. 2.00 geachtet wird (sofern das immer noch wichtig ist, man kann das nur einschränkend wiederholen),
irgendwo muss diese Info ja stecken, schon fraglich ob sie überhaupt in der DB als Unterschied gespeichert wird,
aber vielleicht in den neu erstellten Vergleichsdaten in Java,

wenn man nur bytes vergleicht, macht diese Information wohl einen Unterschied,
es braucht eine inhaltsbasierte Interpretation

edit: die Checksumme der Werte in der DB wird wohl beim Speichern eh berechnet, mitgespeichert oder im Programm vorgehalten, in der DB muss womöglich nichts berechnet werden

 

[Timothy Truckle]

soll der Link
CRC32 (Java Platform SE 7 )
allein dem Stichwort CRC32 dienen, falls in DB, oder tatsächlich Bytes in Java bearbeiten?

Ich kenne noch einen: 12.6.2. Mathematical Functions

in jedem Fall ist zu bedenken, dass hoffentlich auf 2.0 vs. 2.00 geachtet wird (sofern das immer noch wichtig ist, man kann das nur einschränkend wiederholen),
irgendwo muss diese Info ja stecken, schon fraglich ob sie überhaupt in der DB als Unterschied gespeichert wird,

Oracle würde das wohl von der Definition des Feldes abhängig machen...

bye
TT