World: r4wp

so if you really want to reverse it, it has to be

if  MM <= ss [

However, it's more logical to put constants last, and it can also 
generate more optimal code in Red/System

There are more off-by-one errors in there, so the algorithm is not 
the same

The pointer initialisation earlier needs to be

ran_arr_ptr: :ran_arr_dummy

It should actually crash on what you have now, but if it doesn't, 
it pokes a value over an unitialised pointer, so any value in your 
program could be corrupted

Thanks for the compliment Doc, not really sure what you mean exactly 
by making it more like Red/System and less C: use more descriptive 
names? I will take a closer look at some ed/System examples out there.

Thanks Kaj for finding those and for the tips, the size of MM makes 
it the same in effect in this case, but it has to be <= then. Program 
not crashing, I was lucky then! off-by-one errors? My index goes 
from 1 up, where in C it is from 0 up, I had to debug this to make 
sure elements were swapped in the same way as in the original program. 
That is also why I declare KKP and LLP to as to save from adding 
1 to KK and LL over and over again. 


Knuth's algorythm was the first one I found, and I knew already of 
its existence, so it made sense to use what you have. Sure my Red/System 
code is not optimised.


Going to work on it now and tomorrow, and later I take on the Twister. 
It is a good exercise!

Actually, your work on porting that algorithm has many values, like 
showing us the trade-offs of 1-base vs 0-base indexing at Red/System 
level.

About "making it more like Red/System" means applying Red/System 
coding style, which is not formaly defined, but it is very close 
to the official Rebol one. For example, the naming rules for variable 
and function names are the same as in Rebol.

About odd, this solution managed to get all odd number from the even 
ones. Your solution is way more elegant, better fitting the language.

Base-1 Base-0, my personal view on this, it is the programmers choice 
on the level of the source code. What happens beneath the surface 
is compiler/linker sh*t. As a programmer and a human being I start 
to count at 1. 0 is not the new number 1 nor is 1 the new number 
2 etc. It is only an addressing issue, compare to the post. Houses 
in the street are numbered from 1 up to N. The first address a computer 
has in an array is the all 0 address, which is the first "pidgeon-hole" 
to be used. The computer doesn't know 0 as we understand it. Well 
you know all about it.

And the computer must adapt to the human, or the human pulls the 
plug! ;)

CPU are optimized for 0-based accesses. Using 1-base indexing will 
make Red/System a bit slower than it needs to be.

OTOH, you can always use pointer arithmetics to get a 0-base indexing 
model.

Arnold: does the C code use register variables?

Yes it does

I was going to aslk whether register varaibles still improve performance 
with modern CPUs with on-chip caches?

The source (with some displays to help compare both versions) is 
in the Red Randompublic folder

If register variables do improve performance I was going to add register 
variables to the Red/System V2 wish list.

I would certainly expect that to be the case. My code is just Red/System 
compilable and executable.

Funny

: #define odd? (x) etc as Kaj suggested gives a compile error on 
line where it is used: 
*** Compilation Error: undefined symbol: odd? 

*** in file: %/Users/Arnold/data/develop/red/testscripts/random.reds 
*** in function: ran_start
*** at line: 117 
*** near: [odd? ss [

Shouldn't  it be odd?(ss) ?

macros require the (), unlike function calls.

That solved it! Thnx, now putting the questionmark back in.

(As fast as yesterday) The base-1 versus base-0 would be accountable 
for a minute delay (less than 1% of the addressed numbers in the 
array, the 0-th and the last). The use of variables in the register 
looks more likely imho. Good point for the wishlist.

I was going to add register variables to the Red/System V2 wish list.


This is not required as one of the first change I have in mind for 
Red/System 2.0 is adding a good registers allocation method to backend 
code emitters.

That change alone should make a significant difference in speed (I 
expected it close to twice faster) and code size compared to the 
current approach.

Put it on for the world to know :)

The mersenne twister has a lot of examples in other languages. finding 
out the closest 1 to red/system.

Arnold as I understand, If the compiler to fully uses the registers 
then they wouldn't be available for application programmers.

to fully -> fully

I'm making good progress on the new Android bridge and demo, I should 
be able to release it tonight with all the new changes in source 
code (so Pekr will not need to reverse-engineer the apk ;-)).

most probbly I will do so anyway ;-) Will the demo be hello world 
example, or more usefull one, e.g. getting a contact list item? :-)

I'm not sure you're much interested in learning how to do it using 
Java objects, do you? It can be done already, but in order to implement 
proper abstraction for Red, we need at least objects support. Also, 
getting the GUI layer done is higher priority.

Arnold, sorry about forgetting the parentheses. They will really 
be gone in Red/System v2 :-)

The register storage class in C is just an advice from the programmer 
to the compiler. The compiler always needs to make the best use of 
the available registers. Your variables may or may not be stored 
in them, and if you request them, you may or may not get them

@Kaj, no problem, and Peter came to the rescue. Amazing even with 
a community this small, these things get solved in such a small timeframe.

I cut out all register directives from the C source, replaced with 
ordinary declarations. Program is yet as fast as previously. Most 
likely to me is the XCode compiler fills in some optimisations regarding 
this.

Yes

When Knuth wrote it long ago, it probably still made some difference 
in some compilers then

It even has #defines for K&R declarations...

About the pointer, I got the example of pointer/value: value somewhere, 
not saying from the fossil repository but might very well be so. 
The pointer: :value suggested confuses me. I tend to stick to what 
I had figured out. I prefer to avoid pointers almost always at all 
costs because of the trouble they can be. A good description is needed 
of how they are best used in  Red(/System).

Arnold, if you have specific questions about pointers in Red/System, 
maybe you could ask them on SO and make the first SO entries for 
Red?

Red on Android teaser: http://static.red-lang.org/droid-eval.png

Notice that this runs on the x86 emulator, there's still a few bugs 
to fix for the ARM version.

Nice :-)

Also, it's possible to use a ICS skin...I just need to figure out 
how/where to define it.

The whole UI is built in Red, calling the Android API through JNI.

Though, there's no UI dialect yet, but it can be built pretty quickly 
as Kaj demonstrated in the GTK binding.

ah, looks nice anyway. So - was the bridge rewriten, wrt your mentioned 
jni object limit?

What I mean is - would like to post something to FB channel, but 
not necessarily if the screenshot is an interim teaser. I can wait 
for some "more official" release, but surely I don't know your intentions, 
e.g. yesterday you mentioned objects, but those might be few weeks 
away?