World: r3wp

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

It's true that Java's JIT makes it an unfair comparison, but sometimes 
the unfairness goes in the other way :)

R3  needs to name itself Rebol 3.00 a 96  instead of rebol 2.100.96.3.1

I have one R3 TCP server, and two R3 TCP clients. When the second 
client starts to send data to the server, the server will stop handling 
data from the first client. This is very bad for my system.

What can I do? thanks

we shold probably push RT to fix the bug. IIRC Oldes (or someone 
else) found himself in the same situation, and it should be now reported 
in CureCode ...

There are 230 open issues in Curecode now.

So I guess this bug won't be fixed soon.

For work around this, I am trying to develop a middle-tier program 
using Java or Erlang.

yes - few months back we fixed ca 80 tickets a month. Now Carl is 
on Extensions and Host kit. However - some bugs could be bumped-up, 
and this one seems being pretty serious ...

Jerry - I sent private message to Carl, trying to point him to your 
and Oldes's ticket - those are imo related. Hopefully Carl reads 
my message ....

Perk, thanks. I hope this bug will be fixed soon, so my system developed 
in R3 can be online soon.

Has anyone developed some new styles for R3 GUI? Even the VID stuff 
is not yet ready IMO doing styles should be possible and the chances 
of lost-effort seems to be low.