Jetzt reicht mir der 32 Bit schlüssel definitiv nicht! Ich brauche mindestens 128 Bit. Oder besser 256 BIt. Allerdings habe ich schwierigkeiten bei solchen Bitgrössen die funktion um zuschreiben....vielleicht hat jemand eine gute Idee?

Hier erstmal die alte variante mit 32 Bit:

Zur erklärung:
für jedes vektor element errechne ich einen 32 Bit key der addiert wird zum vorherigen ergebnis.
Ein 32 Bit wert für einen double wird so errechnet:
auf ganzzahl 64 Bit casten, dann die oberen 32 Bit mit den unteren verXORen
und dann die unteren 32 Bit rausschmeissen.

...
typedef unsigned int U_Int32;

...
U_Int32 
Hash::compute_key(const double* vec, size_t size) const
{                
    U_Int32 ret = 0;
    while(size--)
    {
        ret = (ret * 31) + hash_double(*vec);
        vec++;
    } 
    return ret;
}

inline U_Int32 
Hash::hash_double(double x)
{ 
    U_Int64* p = reinterpret_cast< U_Int64* > (&x); 
    return *p ^ (*p >> 32); 
}

ginge das irgendwie mittels unsigned long long ? sind dann aber wohl net 256 BIt oder?

danke euch

...bin mir unsicher ob ich das für meine double bzw. ganzzahligen werte verwenden kann?

Danke

aber bezieht sich das nicht auf char input? Kann es sein dass nur inputs bis maximal 64 erlaubt sind?

das gilt für den key, den man da reinmixen soll, damit der output noch 'zufälliger' wird. ist es ein 64-byte langer key, dann haste eine 'PRF-512'. die länge der daten, die gehashed werden sollen, ist aber variabel...

Mati schrieb:

...bin mir unsicher ob ich das für meine double bzw. ganzzahligen werte verwenden kann?

ist ja nicht so schlimm. musste halt dein double-array in char* casten.
(ich glaub' vor kurzem hatte hier einer exakt das gleiche thema )

Ich muss zusätzlich Zeitperformant bleiben

äääh, ach so, naja, an typecasts solls nicht scheitern aber wenn's um speed geht, würde ich eine PRF nicht nehmen. die verwendet zum verscramblen intern den SHA-1 algo und sowas hat zwar 'ne gewisse kryptografische qualität, ist aber leider alles andere als schnell

oder um es anders zu sagen : Die Casts an sich werden nichts verlangsamen. Alle Casts bis auf den dynamic_cast werden ausschließlich zur Compile Time ausgewertet, und haben zur Laufzeit keinen Einfluß mehr.

bis bald
akari

Alle Casts bis auf den dynamic_cast werden ausschließlich zur Compile Time ausgewertet, und haben zur Laufzeit keinen Einfluß mehr.

Falsch.

@ nöö : und kannst du deine "Kritik" auch begründen?

bis bald
akari

scheiße....prf ist also langsam und SHA auch? *grmpf....vielleicht sollte ich doch mit bitsets irgendwie arbeiten.....ach die welt wär doch so schön

Nein, es wird nichts gerechnet. Sondern der Compiler wird gezwungen, den Speicherbereich des Arguments wie vom Typ des Cast-Ziels zu behandeln. Das kann auch zu Speicherfehlzugriffen führen. Zum Beispiel so

unsigned short test = 10;
unsigned int test2 = std::numeric_limits<unsigned int>().max();
reinterpret_cast<unsigned int>(test) = test2;

Hier wird der Compiler gezwungen, die 2 Bytes des shorts mit den 4 Bytes des ints zu überschreiben, was demzufolge auch unzulässig ist.
Casts selber (bis auf den dynamic_cast) verändern gar nichts.

/Edit :
Ein guter Compiler läßt mein Beispiel gar nicht durch. Aber so kompilierts, und verursacht trotzdem Speicherfehler

unsigned short test = 10;
unsigned int test2 = std::numeric_limits<unsigned int>().max();
*(reinterpret_cast<unsigned int*>(&test)) = test2;

bis bald
akari

int main (int a, char **b)
{
   double d = (double)a;         // c++ casts auch mal probieren
   std::cout << d  << std::endl;
}

und schau dir das disassembly an.
ich könnte wetten, dass zum konvertieren eine versteckte funktion aufgerufen wird...

ja, die "versteckte Funktion" ist der Konstruktor von double.
Egal was aus dem Cast von a kommt, durch die Dekalration von double wird auf jedenfall ein gültiges double initialisiert.

bis bald
akari

Egal was aus dem Cast von a kommt,

eben nicht. der inhalt von 'd' ist davon abhängig.

okay, dann zieh ich meine erste Aussage zurück. Und grenze sie auf Pointer ein.

bis bald
akari