Hi Stefan,
the point is that the code uses only 32 bits. The java code ands by
16rffffffff on each update to seed, and even if that's not necessary because
seed is declared as int, it does show that we can discard bits above 3/ after
each update. Therefore any use of seed in a left shift does not need
alteration because high bits will be lost. The only case is in a right shift,
where the sign bit will be propagated.
So (assuming ^ & defined as bitXor: and bitAnd: ; I'm on my phone, and that >>>
is arithmetic shift right) I believe that this will work:
seed := ((seed + 16r7ed55d16) + (seed << 12)) & 16rffffffff.
seed := ((seed ^ 16rc761c23c) ^ (seed as32BitSignedValue >>> 19)) &
16rffffffff.
seed := ((seed + 16r165667b1) + (seed << 5)) & 16rffffffff.
seed := ((seed + 16rd3a2646c) ^ (seed << 9)) & 16rffffffff.
seed := ((seed + 16rfd7046c5) + (seed << 3)) & 16rffffffff.
seed := ((seed ^ 16rb55a4f09) ^ (seed as32BitSignedValue >>> 16)) &
16rffffffff.
^ seed as32BitSignedValue
Eliot (phone)
On Apr 3, 2015, at 8:04 AM, Stefan Marr <smallt...@stefan-marr.de> wrote:
> Hi Eliot:
>
>> On 03 Apr 2015, at 16:47, Eliot Miranda <eliot.mira...@gmail.com> wrote:
>>
>> if seed is Andes with 16rffffffff when it is initialized then the Java code
>> can be used to generate the next value and the sign conversion only applied
>> once to yield the next value. That would eliminate lots of conversions and
>> make the code readable, right?
>
> Sorry, I don’t understand you.
>
> In the Java code the `0xffffffff` is redundant/superfluous. It’s there
> because I ported the code from JavaScript. The important part is that Java
> has signed 32bit integers. So, it works as expected out of the box.
>
> The SOM version shows the explicit operations you need if you don’t have any
> knowledge about the underlying integer representation. In most SOM
> implementations, integers happen to be represented as 64bit values, that
> overflow into some form of big/large integer representations.
>
> The sign-related operations are necessary to get the correct shift and
> overflow semantics.
>
> I guess I could implement it easily on a 64-bit Spur image, but I haven’t
> looked into that yet.
>
> Marcus’ comment looks also useful, but it is going to be very slow…
>
> Best regards
> Stefan
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>
>
