World: r4wp

OK but in a sense what I typed is in full ASCII, isn't ?

Thanks Doc and I leave you now - going "à la soupe"... You will soon 
go to bed too I suppose.

Glad you came back already and safe

Yes, you input ASCII characters, but the runtime lexer needs to decode 
your Unicode codepoint in hex format, and the lexer has no support 
for that.

OK that's already fine as is for now.

Right, I'm not far from going to bed. ;-)

Keep up the good work - i'll support you by means of other donations, 
as soon as my next cheque is coming in.

Must go back to some real work now - I just played all the day with 
these other websites and books ...

Thanks Gerard! I'll have a look at your posts on RebelBB and will 
send you my comments, if any.

Results for the initialized state-table are now the same, finally. 
Thanks!

Red/System: Could it be that if you 
#define MAX-SIZE 100
my-array: as int-ptr! allocate MAX-SIZE * size? integer!
then using  
my-array/MAX-SIZE 
gives a compilation error??
*** Compilation Error: undefined pointer index variable

Probably food for an issue?

I remember that we allowed macro replacement in paths, but it might 
be only for macros with parameters. Have you found an existing ticket 
about that?

doesn't look like it.

That may indeed very well have been only about macro parameters

You could work around it:

i: MAX-SIZE

my-array/i

Right but then I have a #define macro AND a variable. So I had better 
started of with the variable in this case.

But is really is a constant.

Yes, it's imperfect

That is why I created an issue for it #504.

I'm finishing installing the tools I need and migrating all my data 
from old disks, I should be able to get back to full coding tonight....finally.

Such things always take a lot of time

I reached this:
C code:
hex value 2214165945 is=0x83f97db9

* 1664525 gives 32710463130033 plus j 0 and plus the init_key of 
value 291 
mt[i] 32710463130324 and(&) FFFFFFFFh results in mt[i] 4287171284
Red/Systemcode
-2080801351 which is also (to-hex -2080801351)
== #83F97DB9

multiplied by 1664525:: 1658067045 and then added also 291 and 1 
minus 1
state-array/i: 1658067336

(My) Conclusion the multiplication by 1664525 causes the results 
of the C source and Red/System source to diverge, possible reason 
calculation with long integers in C versus integer calculation in 
Red/System troubled by overflows.

Is that on a 64 bit machine?

It is my Macbook from 2008.

That is 64 bit but not the core or something, that is why it can't 
upgrade beyond Snow Leopard.

It must be 64 bit, because a long on Mac would probably be 84 bit 
there. Indeed, your multiplication result is 64 bit, so on Red/System, 
it is wrapping around

64

However, the algorithm should also work on 32 bit, shouldn't it?

Or is it using long longs?

Yes, there is a trick to AND with FFFFFFFFh to bring it back to 32 
bits, but harm to the resulting values has been done then.

Not if the algorithm is meant to work on 32 bit

I have no idea how to compile and run the C variant in 32 bit mode

There would be some compiler option, -32 or something

That was easy on XCode. Getting closer now. (still differences :( 
)

(changing target)

Shooting rabbits now?

pow pow pow!

all hits now :-)

There were some more hooks and traps, in the end the same generated 
numbers! Now removing a real truckload of dumps and prints from the 
source.

So does the C program produce different results in 32 and 64 bit 
versions?

That is what I concluded Tue 9:52. Still stands.

That's very strange for such an algorithm

Is the code supposed to support 64 bit?

After current test, I conclude otherwise :) Output is the same. Output 
in C source is unsigned, output in R/S is signed.
C: 10 outputs of genrand_int32()
1067595299  955945823  477289528 4107218783 4228976476 
3344332714 3355579695  227628506  810200273 2591290167 
R/S:--- Test 3 10 outputs of genrand-int32 ---
--------------------------------------------
1067595299 955945823 477289528 -187748513 -65990820 
-950634582 -939387601 227628506 810200273 -1703677129 
----------------------------------

(Where the negative values are bitwise equal to their unsigned counterpart 
in the C output.)

I was mislead by an incorrect intermediate result in the Red/System 
source that I expected to be correct already but had not fixed on 
this machine, together with a short blackout overseeing that adding 
nonzerobits to the left of a binary number changes the decimal representation 
in the lower digits too. Lots of output lines, many output terminal 
windows, small laptopscreen.
Same results make sense.

Syncing problems? Better use Fossil :-)