In article <[EMAIL PROTECTED]>,
Phil Carmody <[EMAIL PROTECTED]> writes:
> --- Ronald J Kimball <[EMAIL PROTECTED]> wrote:
>> On Fri, Aug 29, 2003 at 10:27:10PM -0000, Mtv Europe wrote:
>> > Hello Daniel!
>> >
>> > [EMAIL PROTECTED] (Daniel Tiefnig) wrote:
>> >
>> > > Well, you could still say "a" -> "a"..
>> >
>> > Nope, it's not permitted. Generic rule #2, "The program is expected to
>> > finish in a reasonable time", so input that leads to endless loop is
>> > not allowed.
>>
>> What a curious inference. Can I similarly conclude that any other input
>> which causes my program to take a long time to execute is prohibited?
>>
>> Generic rule #2 is a restriction on the code, not on the input. Either the
>> code must detect an infinite loop and terminate "in a reasonable time",
>> according to generic rule #2, or this particular golf challenge needs a
>> specific rule regarding input which causes an infinite loop.
>
> The rules say to me that you're not permitted to /partially/ carry out a set
> of replacements you must do them all. That means that any replacements that
> look like they are infinite loops should not terminate. That means no
> interruption of a potentially infinite loop.
>
> For example, "the program must return within a reasonable time two proper
> factors of the input" would be a restriction on the code, however, it implies
> that all input must be composite.
>
It's not that simple. In fact the only possible infinite loop is a
self-replacement, which has no effect. Since a challenge only describes
the required effect, not how to do it, I could defend that the program
can in a finite time compare the left and right side of a transformation
and and decide to skip it if they are equal.
So you can solve the infinite replacement case with a finite time program.
We need to know if we should handle this case, therefore it needs a
clarification of the challenge.
