On Fri, 3 Apr 2015, Stefan Marr wrote:
Hi Eliot:
On 03 Apr 2015, at 16:47, Eliot Miranda <[email protected]> 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…
It's still the fastest option within a 32-bit image (way faster than
LargeInteger operations).
Of course you could just use Nativeboost if it's for Pharo.
Levente
Best regards
Stefan
--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/
