hash et date

Le Wed, 09 Jul 2014 11:09:05 +0200
inconnu <inconnu@none.bid> a écrit :

Bonjour à tous,


J'ai généré un identifiant unique d'un objet en utilisant le hashCode
de la date de sa création.


J'ai maintenant besoin de retrouver la date à partir de ce hashCode.

Le code utilisé pour la génération du hashCode est d'après la
javadoc :

(int)(this.getTime()^(this.getTime() >>> 32))


Bref, comment retrouver le nb de millisecondes (this.getTime()) à
partir d'un hashCode connu ?


merci d'avance

Une des caractéristiques importantes des fonctions de hachage est
qu'on ne peut pas retrouver la valeur d'origine. C'est particulièrement
important quand il s'agit de problèmes de sécurité, mais c'est aussi
une caractéristique des fonctions de hachage plus simples.

Note qu'il n'est pas garanti que la valeur de hachage soit unique non
plus.

Si tu cherches un moyen d'associer la valeur réelle à la valeur hachée
il faudrait nous en dire un peu plus sur ce que tu veux faire, comment
les données sont stockées, ...

Bonjour,

le 09/07/2014 à 11:09, inconnu <inconnu@none.bid> a écrit dans le
message <lpj10c$j5v$1@shakotay.alphanet.ch> :

J'ai généré un identifiant unique d'un objet en utilisant le hashCode
de la date de sa création.


J'ai maintenant besoin de retrouver la date à partir de ce hashCode.

Le code utilisé pour la génération du hashCode est d'après la javadoc :

(int)(this.getTime()^(this.getTime() >>> 32))


Bref, comment retrouver le nb de millisecondes (this.getTime()) à
partir d'un hashCode connu ?

Pourquoi n'utilises-tu pas this.getTime() comme identifiant unique ?

--
Benoit Izac

Le 09/07/2014 19:03, Benoit Izac a écrit :

Pourquoi n'utilises-tu pas this.getTime() comme identifiant unique ?

Je pense qu'il veut un int et son getTime() retourne un long (des ms
sans doute).

Idée: stocker dans un long le getTime() initial (t0), ensuite utiliser
comme hash: (int)(this.getTime()-t0). Ca donnera en entier 32 bits
unique valable pendant 2^31 ms = 596 heures consécutives (au delà les
hash vont cycler).

sam.

Benoit Izac <use.reply.to@INVALID.ADDRESS> writes:

Bonjour,

le 09/07/2014 à 11:09, inconnu <inconnu@none.bid> a écrit dans le
message <lpj10c$j5v$1@shakotay.alphanet.ch> :

J'ai généré un identifiant unique d'un objet en utilisant le hashCode
de la date de sa création.


J'ai maintenant besoin de retrouver la date à partir de ce hashCode.

Le code utilisé pour la génération du hashCode est d'apr ès la javadoc :

(int)(this.getTime()^(this.getTime() >>> 32))


Bref, comment retrouver le nb de millisecondes (this.getTime()) à
partir d'un hashCode connu ?

Pourquoi n'utilises-tu pas this.getTime() comme identifiant unique ?

Tu as raison, bien sûr, mais... getTime() est en millisecondes,
c'est-à-dire suffisamment de temps pour créer un bon paquet d'obj ets,
qui auront tous la même "date".

-- Alain.

P/S: le calcul du hash tel qu'écrit ci-dessus est désastreux, par ce que
rien ne garantit que les deux appels à getTime() renvoient la même
valeur. Je sais bien que ça sort de la javadoc, mais quand même...

Bonjour,

le 10/07/2014 à 11:50, Alain Ketterlin a écrit dans le message
<87zjghzgnj.fsf@dpt-info.u-strasbg.fr> :

J'ai généré un identifiant unique d'un objet en utilisant le hashCode
de la date de sa création.

J'ai maintenant besoin de retrouver la date à partir de ce hashCode.

Le code utilisé pour la génération du hashCode est d'après la javadoc :

(int)(this.getTime()^(this.getTime() >>> 32))

Bref, comment retrouver le nb de millisecondes (this.getTime()) à
partir d'un hashCode connu ?

Pourquoi n'utilises-tu pas this.getTime() comme identifiant unique ?

Tu as raison, bien sûr, mais... getTime() est en millisecondes,
c'est-à-dire suffisamment de temps pour créer un bon paquet d'objets,
qui auront tous la même "date".

J'ai considéré que deux objets ne pouvaient pas être créés à la même
milliseconde sinon, quelque soit la fonction de hachage, ce ne serait
pas un identifiant unique...

P/S: le calcul du hash tel qu'écrit ci-dessus est désastreux, parce que
rien ne garantit que les deux appels à getTime() renvoient la même
valeur. Je sais bien que ça sort de la javadoc, mais quand même...

C'est vrai mais dans l'exemple ci-dessus (générer un identifiant
unique), je ne pense pas que ce soit problématique (toujours en gardant
le postulat que l'écart entre la création de deux objets est supérieur
à la milliseconde).

La question est peut-être pourquoi utiliser un int plutôt qu'un long
comme type pour l'identifiant ?

--
Benoit Izac

Le 10/07/2014 21:54, Benoit Izac a écrit :

La question est peut-être pourquoi utiliser un int plutôt qu'un long
comme type pour l'identifiant ?

En fait si on veut un vrai identifiant unique, il existe la classe UUID
rien que pour ca. Pourquoi ne pas l'utiliser? C'est standard.

http://docs.oracle.com/javase/1.5.0/docs/api/java/util/UUID.html

==> UUID.randomUUID() retourne un UUID différent à chaque appel.

Maintenant si c'est unique c'est pas forcément une bonne fonction de
hachage. Ca serait bien que l'OP nous dise pourquoi il veut à tout prix
que le hashCode de ses objets soient différents? Le contrat pour
utiliser le hashCode en java sont que si deux objects sont identiques
(au sens equals()) leur hashCode() l'est aussi, mais pas l'inverse!

C'est très simple et très souple. Cela autorise aussi d'utiliser
correctement les HashMap même dans le cas où deux objets ont le même
hashCode() (car on test l'equalité avec equals() en cas de doublon sur
les hashCode()).

Bref: utiliser une HashMap pour stocker les objets crées et implémenter
equals() et hashCode() en se basant sur le contenu des objets me semble
être plus propre que toutes les bidouilles avec les dates et cast en
int. Pour aider à batir des hashCode() sur le contenu des objets il y a
le HashCodeBuilder d'apache-commons:

https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/HashCodeBuilder.html

Similairement on trouve aussi le EqualsBuilder:

https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/EqualsBuilder.html

Avec ca on a plus d'excuse pour écrire des classes java implémentant
correctement le couple hashCode()/equals().

sam.

On 09. 07. 14 15:09, Yliur wrote:

Le Wed, 09 Jul 2014 11:09:05 +0200
inconnu <inconnu@none.bid> a écrit :

Bonjour à tous,


J'ai généré un identifiant unique d'un objet en utilisant le hashCode
de la date de sa création.


J'ai maintenant besoin de retrouver la date à partir de ce hashCode.

Le code utilisé pour la génération du hashCode est d'après la
javadoc :

(int)(this.getTime()^(this.getTime() >>> 32))


Bref, comment retrouver le nb de millisecondes (this.getTime()) à
partir d'un hashCode connu ?


merci d'avance

Une des caractéristiques importantes des fonctions de hachage est
qu'on ne peut pas retrouver la valeur d'origine. C'est particulièrement
important quand il s'agit de problèmes de sécurité, mais c'est aussi
une caractéristique des fonctions de hachage plus simples.

Note qu'il n'est pas garanti que la valeur de hachage soit unique non
plus.

Si tu cherches un moyen d'associer la valeur réelle à la valeur hachée
il faudrait nous en dire un peu plus sur ce que tu veux faire, comment
les données sont stockées, ...

Merci à tous pour vos réponses.


Les données du passé sont stocké avec le hash code de l'instant où elles
ont été créés. Malheureusement pas avec la date !
Je voudrais pouvoir récupérer le nb de millisecondes et finalement la
date approximative de la création


Ex : j'ai un hash code de 616448960
Quel est le nb de miliseconde nbms sachant que
nbms^(nbms >>> 32) = 616448960
La réponse doit correspondre à env. 11.07.2014 à 11h25


Est possible de résoudre cette équation en java ???


D'avance merci

On 09. 07. 14 19:03, Benoit Izac wrote:

Bonjour,

le 09/07/2014 à 11:09, inconnu <inconnu@none.bid> a écrit dans le
message <lpj10c$j5v$1@shakotay.alphanet.ch> :

J'ai généré un identifiant unique d'un objet en utilisant le hashCode
de la date de sa création.


J'ai maintenant besoin de retrouver la date à partir de ce hashCode.

Le code utilisé pour la génération du hashCode est d'après la javadoc :

(int)(this.getTime()^(this.getTime() >>> 32))


Bref, comment retrouver le nb de millisecondes (this.getTime()) à
partir d'un hashCode connu ?

Pourquoi n'utilises-tu pas this.getTime() comme identifiant unique ?

j'ai utilisé le hashCode de la date de création. J'aimerais maintenant
récupérer la date !
Voir réponse à Yliur pour le détail ...

inconnu <inconnu@none.bid> writes:

On 09. 07. 14 15:09, Yliur wrote:

Une des caractéristiques importantes des fonctions de hachage est
qu'on ne peut pas retrouver la valeur d'origine.

Les données du passé sont stocké avec le hash code de l'in stant où
elles ont été créés. Malheureusement pas avec la date !
Je voudrais pouvoir récupérer le nb de millisecondes et finalem ent la
date approximative de la création

Ex : j'ai un hash code de 616448960
Quel est le nb de miliseconde nbms sachant que
nbms^(nbms >>> 32) = 616448960

Tu oublies le cast, qui supprime les 32 bits de poids fort du résultat.

La réponse doit correspondre à env. 11.07.2014 à 11h25

Est possible de résoudre cette équation

Non.

en java ???

Pas plus en Java qu'avec un autre langage.

Si toutefois tu connais ces 32 bits de poids fort (up), alors c'est
facile (c'est (hash^up)|(up<<32), plus les conversions vers long). 32
bits de millisecondes, c'est à la louche 49 jours. Si tu ne connais pas
les dates avec cette précision, c'est perdu.

-- Alain.

Le Fri, 11 Jul 2014 11:41:44 +0200
inconnu <inconnu@none.bid> a écrit :

On 09. 07. 14 15:09, Yliur wrote:
> Le Wed, 09 Jul 2014 11:09:05 +0200
> inconnu <inconnu@none.bid> a écrit :
>
>> Bonjour à tous,
>>
>>
>> J'ai généré un identifiant unique d'un objet en utilisant le
>> hashCode de la date de sa création.
>>
>>
>> J'ai maintenant besoin de retrouver la date à partir de ce
>> hashCode.
>>
>> Le code utilisé pour la génération du hashCode est d'après la
>> javadoc :
>>
>> (int)(this.getTime()^(this.getTime() >>> 32))
>>
>>
>> Bref, comment retrouver le nb de millisecondes (this.getTime()) à
>> partir d'un hashCode connu ?
>>
>>
>> merci d'avance
>
> Une des caractéristiques importantes des fonctions de hachage est
> qu'on ne peut pas retrouver la valeur d'origine. C'est
> particulièrement important quand il s'agit de problèmes de
> sécurité, mais c'est aussi une caractéristique des fonctions de
> hachage plus simples.
>
> Note qu'il n'est pas garanti que la valeur de hachage soit unique
> non plus.
>
> Si tu cherches un moyen d'associer la valeur réelle à la valeur
> hachée il faudrait nous en dire un peu plus sur ce que tu veux
> faire, comment les données sont stockées, ...
>
Merci à tous pour vos réponses.


Les données du passé sont stocké avec le hash code de l'instant où
elles ont été créés. Malheureusement pas avec la date !
Je voudrais pouvoir récupérer le nb de millisecondes et finalement la
date approximative de la création


Ex : j'ai un hash code de 616448960
Quel est le nb de miliseconde nbms sachant que
nbms^(nbms >>> 32) = 616448960
La réponse doit correspondre à env. 11.07.2014 à 11h25


Est possible de résoudre cette équation en java ???


D'avance merci

Si les données sont comme ça et que tu ne peux rien y faire, il reste
l'option d'essayer toutes les dates d'une plage et de voir lesquelles
correspondent à cette valeur de hachage. Par contre ce n'est jouable
que si tu n'as qu'une plage limitée à explorer et que tu ne tombes pas
sur des doublons dans cette plage.