World: r4wp

Same as yours only with prot-setnet.r added.

#include %gfx-colors.r
#include %gfx-funcs.r

#include %view-funcs.r
#include %view-vid.r
#include %view-edit.r
#include %view-feel.r
#include %view-images.r
#include %view-styles.r
#include %view-request.r

#include %prot-setnet.r


;-- Must be done prior to loading anything that requires fonts on 
Linux.

layout [text "imanXwin kludge"] ;-throw this one away soon-- okay?

open-events

you don't have any protocols

you need to include prot.r

and then remove prot-setnet.r or just add the protocols you need

Got it! Now I see how it all works and I have 'enface' working on 
linux. Many Thanks for your help!

What's the proper (fast) way to do this?

    REBOL [title: "Anagram List"]
    a: copy []
    mix: func [str prev] [   
        repeat i length? str [
            picked: pick str i
            rest: head remove at copy str i
            append a rejoin [prev picked rest]
            mix rest join prev picked
        ]
    ]
    mix input: ask "Text:  " ""
    editor unique a

Don't know if it is faster or more proper, but it's another way:
   http://www.rebol.org/view-script.r?script=lexpem.r

res: copy [ ] 
    mix: func [str /local i][
    	if 1 = i: length? str [append res copy head str exit]
    	loop i [
    		append str str/1
    		mix next remove str
    	]
    ]

Just use math:
a: copy []

mix: func [ myword /local n t] [
	n:  length? myword
	t: 1
	loop n [ 
		t: n * t 
		n: n - 1
		]	
	while [(length? a) < t] [
		append a random myword	
		unique a
	
		]
	a	
	]
mix "test"

editor a

I think that it's quicker, since you don't mess with series altering, 
insted you just create mixed words enough to reach the maximum available 
permutations.

For short words...

:-P

Thank you guys.  Steve, that's much quicker.  There's no way that 
succeeds without the exponential increase in evaluation, with each 
added character?  I was hoping there might be some magic to learn...

Steve, that code doesn't appear to create all the possible anagrams.

for instance ?

/me pouring a glass of whisky

REBOL [title: "Anagram List"]


a:[]m: func[s p][repeat i length? s[append a rejoin[p k: s/:i r: 
head remove at copy s i]m r join p k]]m ask""""editor unique a probe 
length? a


a:[]m: func[s /local i][if 1 = i: length? s[append a copy head s 
exit]loop i[append s s/1 m next remove s]]m ask""editor a probe length? 
a

halt

Mine is the first one, yours is the second.

can you give a test case where mine is faling ?

Try each line above.  Mine gives 325 anagrams for "asdfg".  Yours 
is much faster, but only results in 120 anagrams for the same input 
string.

For a 5 letters word, the number of combinations should be 5! (factorial 
5) which gives 120.

never mind - stupid me.  didn't count the unique results in mine.

<-- bows low, and walks away :)

I still have the same question though - is there any way to evaluate 
this without the exponential increase in loop counts?

Nick, it would be actually nice if it was just "exponential growth". 
But the number of permutaions of N elements is N! (N factorial), 
which grows faster than the exponential function.

typo: "permutations"

So there's no way of reducing this problem beyond N! ?

How can you produce N! distinct results without producing N! distinct 
results?

(there is no way)

I was hoping to discover some ignorance on my part about the problem.

Thank you for the definitive answer Ladislav, and thanks for the 
code Steeve

(I was hoping that there was perhaps some sort of parallel processing 
solution or some sort of advanced math magic that I knew nothing 
about)

Aha, but Steeve's algorithm looks like being slower than O(N!), if 
I understand it well.

Nick -- sounds like you want an algorithm that, say, returns the 
next 50 -- that way you can work with a window rather than have to 
generate all perms in one gulp. Some of the offered solutions should 
be easily adaptable in that way.

Ladislav, can you make one which performs faster than Steeve's?


Sunanda, paging through windows of is a great way to be practical. 
 I'm more concerned with finding the fastest algorithm - no reason 
- just frustrated with myself for sitting last night for longer than 
I wanted with a CS101 type problem ;)

Just out of curiosity, has anyone written a difinitive article about 
the performance of various looping structures in REBOL?  I remember 
some discussion about it several years ago, related to how badly 
REBOL did in the language "shootout" benchmarks (lots of  "for'" 
loops, if I remember correctly).  That would be a nice article to 
have available.

Nick, the issue is many of the looping constructs were mezzanine...

For R2: native loops are faster than mezzanine (function) loops, 
so much faster that their individual differences amongst themselves 
are almost irrelevant. For R3 all loops are native (except FIND-ALL, 
temporarily), so the big difference is one-time-per-call bind/copy 
overhead for binding loops, versus not having that for non-binding 
loops.

LOOP is the fastest limited scope loop.

I always noticed that Carl used more "while" structures than I w

For R2 I would use LOOP, REPEAT, FOREACH or WHILE whenever possible. 
In R3, REPEAT and FOREACH have bind/copy overhead, while FORALL and 
FORSKIP don't, so the latter can be faster in many cases. WHILE and 
LOOP are the same in R3 as they were in R2, at least relative to 
the other native loops.

FOR has bind/copy overhead in R3 and is a complex mezzanine in R2, 
so I only use it when it is really appropriate.

UNTIL is native in both too, basically a slightly simplified WHILE.

R3 is currently missing anything like the feature that made it possible 
to write really well-integrated mezzanine control structures, instead 
turning all such control structures into natives. Which was a problem 
before R3 was open sourced, not as much of one now.

Nick -- Have you looked at using a variable base algorithm? It may 
be fast, and it should be amenable to windowing:
   http://rosettacode.org/wiki/Permutations/Rank_of_a_permutation
Even if neither, it should be fun to write the script.

FOR ... is a complex mezzanine in R2
, with a lot of bugs, I have to add

Agreed :(

Do you have a non-buggy version? I'd love to add it to rebol-patches, 
with your permission.

Hmm, I do (I once submitted it to Carl, but he never used it). Nevertheless, 
in my code I prefer a general loop called CFOR (the name is unfortunate, 
I must admit). That is what I propose instead since it is both faster 
and more flexible at the same time. Do you think it makes sense to 
propose it in the CC?

Any good idea of a Rebol-compatible name for it?