Re: Generation of permutations

[Darren New <dnew@san.rr.com>]

Marin David Condic wrote:
> I *think* I follow - but that seems to disallow any sort of looping. (Or do
> I misunderstand?)

You misunderstand.

> Isn't it possible for a program to be in a state it has
> been in before (iterating through the data on disk again...) and not be
> caught in an infininte loop?

No. Perhaps the program counter will have a value it had before, but if
every variable in the program, all the values in the registers, the data
on the disk, etc, are the same, it's going to do the same thing it did
last time (assuming it's deterministic, of course).

> Or because you're including a check of the
> state of the data as well, then it can't be in the same state plus the
> identical state of the data without being caught in a loop? (So if you had
> 1k of program+data+processor_state, you'd save every bit, execute one clock
> cycle, compare the 1k against every previous 1k and if it matches, its stuck
> and throw it out? Sounds deliciously slow! :-)

Exactly.

> But that's just looking for the occurrence of a specific algorithm, isn't
> it? 

Right. Rather than a "general sort algorithm".

Actually, it's interesting, because a "sorting algorithm" doesn't sort
items. It orders them.

When I sort my socks, I don't put them in a row, darkest to lightest. I
group them by the sort of socks they are. :-) 

I think the unusual meaning of the word came about because a card sorter
(which really did just sort the cards without ordering them) was used to
order the cards, basically via repeated sorting a la radix sort.

Just an interesting aside...

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.