World: r3wp

... and then we still wait for much needed improvements to Extension 
interface. It needs to support Devices definitely. No easy way to 
do callbacks right now, etc.

As for my own guess - I think that at least whole January will be 
devoted to such development and testing ....

However - I would not be pessimistic. Quite opposite. Carl is right 
now working on very important aspects of R3. We have been waiting 
for it for 3-4 year and we are finally there ...

yes and i still belive in the christmass gift ;-)

... so just push your callendar a little bit :-)

PeterWood, I just checked the history on those pages and they haven't 
been modified since the initial import from the Core 2.3 manual. 
Thanks for flagging these for revision - I'll see about marking them 
as such.

Documentation writing and modification is the thing that we need 
the most help on, probably 50x the number of people we have working 
on the whole R3 project right now. For now, if there is some discrepancy 
between the manual and the behavior of R3, check CureCode. If it's 
not mentioned there then there is a good chance that the R3 behavior 
is intentional.

Claude, Rebol needs to move ahead in a clear path... finishing rebol 
core, in the way it is headed will allow rebol view itself.


it will also make rebol core a very appealing platform to integrate 
other tools into.  we're almost there but a few little things are 
still needed.

I would be happy to try and help with the documentation but the problem 
I, and possibly, many others face, is knowing what is the correct 
behaviour to document. I could only assume that the behaviour as 
demonstrated by the current Alpha is the one to be documented. I 
fearl that is too big an assumption to make.

Well, if you have any questions that aren't covered by CureCode, 
ask them here, in R3 chat, or post them in CureCode. Keep in mind 
that a ticket being dismissed in CureCode is nothing to be taken 
personally - we like those tickets because they serve as documentation 
of design decisions, especially in their comments.

Prime Numbers Peroformance Test: REBOL(r3-a96) vs. Java(jdk1.5)

For getting primes < 5000, Java is 6 times slower than Java
For getting primes < 100000, Java is 30 times slower than Java

correction: REBOL is 6 ...  REBOL is 30 ...

What is your code for getting primes?

REBOL []

get-primes: funct [ max-value [integer!] ] [
    case [
        max-value <= 0 [ 
            []
        ]
        max-value = 1 [
            [1]
        ] 
        true [
            primes: make block! 10000
            append primes 1
            for i 2 max-value 1 [
                is-prime: true
                foreach prime next primes [
                    if zero? i // prime [
                        is-prime: false
                        break
                    ]
                ]
                if is-prime [
                    append primes i
                ]
            ]
            primes
        ]
    ]
]


print dt [ print [ "there are" length? get-primes 100000 "primes" 
] ]

Thanks

i said some years ago when R3 was announced  that we wouldn't have 
it before 2010 ...  once again  I'm sad to be right...

and?

and? no R3  before 2015 fear my predictions  :P

and?

and pekr likes to say "and?"

R3.0 is gonna be released in 2010, so what is your point with 2015?

Jerry, the inner FOREACH loop bind/copies its code block with every 
iteration of FOR - this is a lot of overhead. Use FORALL instead.

A lot of code needs reoptimization when converted to R3 - particlarly 
since all loop functions are native now.

You might also consider
    primes: make block! max-value

instead of 10000 for speedup of prime calculation of max-value over 
10000. Trade memory for speed.

Using the algorithm: Sieve of Eratosthenes
it's just ligthning fast.
For 50000 max prime, i got those results:

; Eratosthenes 
== 0:00:00.089
; Jerry :-) 
== 0:00:10.099


get-primes: func [n /local primes mul p limit][
	primes: make bitset! n + 1
	p: 2
	limit: square-root n
	for p 2 (to-integer square-root n) 1[
		if p > n [break]
		unless primes/:p [
			mul: p + p
			until [
				primes/:mul: true
				n < mul: mul + p
			]
		]
	]
	primes
]

It returns a bitset. False Bits are prime numbers.

(probably, the real gain comes from using a bitset to store numbers)

remove the limit line in the source (n

not used

geez, some other lines are useless

get-primes: func [n /local primes mul p limit][
	primes: make bitset! n + 1
	p: 2
	for p 2 (to-integer square-root n) 1[
		unless primes/:p [
			mul: p + p
			until [
				primes/:mul: true
				n < mul: mul + p
			]
		]
	]
	primes
]

arghhh, one useless line again, abandon :-)

Looks good to me (minus the p: 2 line) :)

You can use FUNCT too instaed of specified locals. The p will be 
local to the FOR.

yep

The TO-BLOCK bitset! proposal would help here. Then the return could 
be
    to-block complement primes
which would return a block of integer primes.

yep, i asked this in curecode IIRC

both of us actually

I'll verify that later, and add it if it's missing :)

the point is not to use a good algorithm to get primes. the point 
is using the same algorithm to compare Java and REBOL

it"s not fair because we know java VMs use JIT compilation.

WOW, forall is really fast. Much faster than FOREACH

I rewrite it using FORALL, now REBOL is even faster than Java

Thanks, BrianH.

shortened version of yours:

get-primes: funct [max-value [integer!]][
	primes: insert make block! n / 2 1
	for i 2 max-value 1 [
		unless forall primes [
			if zero? i // primes/1 [break/return true]
		][
			append primes i
		]
	]
	head primes
]

even if you don't want it faster, you can have it more rebolish

bitset version. If max-value > 65536, it won't work.

>> a: make bitset! 100000
>> a/65535: true
== true

>> a/65536: true
** Script error: cannot set 65536 in path a/65536:

FORALL vs. FOREACH: interesting

about bitsets, the bug is already in curecode

Steeve, JIT compilation can't always beat precompiled and optimized 
native code. If you stick to native!, action! and op! functions REBOL 
can be faster than Java for some kinds of code.

i know