Prev: Need help understanding javascript syntax
Next: My (Your) Library: canCall
From: nick on 15 Apr 2010 05:00
On Apr 15, 3:00 am, Johannes Baagoe <baa...(a)baagoe.com> wrote:
>
> It doesn't break anything, obviously, but just out of curiosity: why do
> you need that ?

No special reason really, it just helps me identify matching hashes
during debugging and looks more like a hash in a data structure
someone else might look at, so it could be less confusing (is it a
random number? A meaningful quantity? Nope, just a hash). I guess it's
just a personal preference thing really.

-- Nick

From: Johannes Baagoe on 15 Apr 2010 05:13
nick :
> Johannes Baagoe :

>> It doesn't break anything, obviously, but just out of curiosity: why do
>> you need that ?

> No special reason really, it just helps me identify matching hashes
> during debugging and looks more like a hash in a data structure someone
> else might look at, so it could be less confusing (is it a random
> number? A meaningful quantity? Nope, just a hash). I guess it's just a
> personal preference thing really.

OK, as long as you do not use it for authentication or encryption or
anything related to cryptology or security... I do not claim at all that
my hash function is secure and never leads to collisions, it couldn't
possibly be with only 53 bits.

Anyway, please test it thoroughly before using it in any kind of critical
application - it is only one day old! :) You may even want to wait for
review by real experts in the field, my own level of competence is only
that of an enthusiastic amateur. Which may be the worst case of all...

--
Johannes
From: nick on 15 Apr 2010 05:30
On Apr 15, 5:13 am, Johannes Baagoe <baa...(a)baagoe.com> wrote:
>
> OK, as long as you do not use it for authentication or encryption or
> anything related to cryptology or security... I do not claim at all that
> my hash function is secure and never leads to collisions, it couldn't
> possibly be with only 53 bits.

I wouldn't even do anything with it that required the same result
between browsers... I don't trust javascript with decimal math.

What I'm thinking about using it for in particular is hashing the
innerHTML of certain page elements to see if they've changed before
doing things with them.

> Anyway, please test it thoroughly before using it in any kind of critical
> application - it is only one day old! :) You may even want to wait for
> review by real experts in the field, my own level of competence is only
> that of an enthusiastic amateur. Which may be the worst case of all...

Thanks for the warning. To my untrained eye it seems to work well, but
I'm curious what the experts will say as well... anyway it seems quite
useful for what it is; thanks again for sharing it.

-- Nick
From: Johannes Baagoe on 15 Apr 2010 06:09
nick :

> I don't trust javascript with decimal math.

You may, though. ECMAScript Numbers are quite well defined, any
differences between implementations would AFAICS be severe bugs.
The only problem is that they do not quite behave like one expects
when one is used to dealing with integers in other languages.

> What I'm thinking about using it for in particular is hashing the
> innerHTML of certain page elements to see if they've changed before
> doing things with them.

That should be all right even across browsers, provided of course that the
innerHTML is the same. Please tell me if you find anything strange.

--
Johannes
From: Dr J R Stockton on 15 Apr 2010 14:41
In comp.lang.javascript message <2cOdnaJevP2utVvWnZ2dnUVZ8vJi4p2d(a)gigane
ws.com>, Wed, 14 Apr 2010 15:40:19, Johannes Baagoe <baagoe(a)baagoe.com>
posted:
>
>I first thought I could use well-established methods, like the
>Fowler–Noll–Vo family of hashes, which seemed to meet the needs.
>
>But that does not work: 32-bit FNV supposes that multiplications of
>two 32-bit integers will retain the 32 lowest bits of the result.
>
>This is not the case with ECMAScript Numbers, which are always
>"double-precision 64-bit binary format IEEE 754 values". That implies
>1. that in the case of overflow, the *lower* bits get discarded,
>
>and 2. that one never retains more than 53 significant bits - 54 if you
>count the sign.
>
>(For the same reason, one cannot implement the classic LCG PRNG in
>a naive way. Marsiglia's "easy to remember" multiplier 69069 is all
>right, since the result of its multiplication by a 32-bit integer
>will always fit in 53 bits. But 1103515245, which is widely used,
>leads to overflow, which ruins the modulo 2^32 assumption.)


When multiplying TWO ECMAScript Numbers, each of which actually holds an
integer in [0, 2^32[, trailing bits are, as you describe, often lost.

But that is not fatal.

There is in my JavaScript Random Web page, under "A Long-Period Random
Number Generator", in "General", code for a Lehmer PRNG with very long
numbers, followed in "64-bit State" by code for the 64-bit case.

It is only necessary to break the large numbers up into arrays of Base-
65536 digits (16-bit) each element stored in a Number, and to do with
them Long Arithmetic such as the elderly were taught at school.

Of course, the code runs slower.

FYI, my Pascal/Delphi program, "longcalc", /via/ sig line 3, does
integer arithmetic using any base from 2 to 16 and numbers of up to
about 65000 or 99999999 digits in essentially that manner.

Your latest E-mail, read in the distance, will
arrive as this departs.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; WinXP.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Need help understanding javascript syntax
Next: My (Your) Library: canCall