hacker.org

Yessss, my mouse passed the test It breaks only on series with zero as the largest number and with the largest number in mem[0].

/Zett

How long is the smallest known mouse that needs not to benefit from deficiencies of the check routine? Is there one which beats mine with 24 instructions?
Considering the mice which stop on reading a zero, are there smallest ones which do not use a ::> instruction sequence?

My mouse stops at zero in mem, but contains no ::> instruction.

My mouse stops reading at zero and doesn't use the ::> sequence either... it uses > though. The 21 instruction version fails when mem[2] is the solution and mem[1] is smaller than mem[0], or of course if one of the inputs is zero. The 23 instruction version however is valid for all inputs not containing a zero! Maybe I can do it with even less... hmm...

There are only two limitations within my program:
1) No zero in the array.
2) The elements of the array have to be unique.

I only use "<" twice, no ">".

This problem drove me nuts. I solved up to 'Really Small Mouse' after much racking of the brain. I got down to 26 instructions assuming 0 could occur in the array.

It took me a while to realize that assuming that 0 wasn't in the array allowed me to simplify the termination test.

I ended up with a solution that just can't have 0 in the array, tho it can requires alot more cycles than the ::>/memory changing solution.

Hi there,

i finally made it!!!
From your description i have the same answer as snibril.
I think it a bit strange that my older solutions (for 25-instructions) are a lot more difficult to understand than my solution for 21...
How does your solution with ::> work?

basically ::> solution uses memory location 0 as the place to store the current smallest value it's found. Memory location 1 gets written if a number isn't currently the largest.

Instead of 2 values on the stack (one for the smallest, and one for your current position) you just need one value to store your current position.

Wow,
it would have taken years for me to find this solution.
But quite an interesting idea.
Thanks for your post.

I have also the limitation that there is no 0 in the array and the numbers are almost unique but made it in 20 instructions...

nice, janb! a new challenge is up for 20 instructions...

you are nuts, all of you ^^
i really thought that 21 instructions would be the shortest possible and now it's down to 20 and i think it's even down to 19 later.
i've got a ::> solution. i couldn't get my solution, without changing mem, shorter than 22.
so start again making it shorter*g*

I found two solutions with 21, but I can get none of these even smaller.
I have no clue how this can be possible

Solution finding max of 4 numbers didn't went through so I had to rearrange my code ... I am probably at ShardFire solution. (So no ::> trick found, but nice to learn )

BTW: it increases the probability of success to 1 from 0.975 (if 0 is equally probable as all integers ... not meaning the computer integers )

Yes these solutions must be very simillar now and maybe the brute force approach mentioned in another forum will work here ... I am not inclined to try it on 20 yet.

Actually when I was thinking about 21 solution I got this calc:
iniLoopVar 1(number),copy to read 1|0(^), copy to compare 1|0(^), copy to endloop 1|0(^), readvar 1|0(<), readmax 1|0(<), loopend 1|2(?), loopjmp 1|1(c), storemax 1|2(>), varchg 1|1(+|-), compare 1|1( : ), makewriteaddrvalid 1|1(+|-|: ), print 1(p), giving total of 13, but decreasing stack in loop by 8 so 8 numbers must be in the loop to make it work. That gives 21 in total. Starting to search for algorithm with these constraints by comp could be possible.

I don't thing negative jnz could be implemented more compressed than by ?c with 2 numbers.

Hmmm, finding small solution not changing memory would be another challenge ... that would not decrease stack that drastically ... it saves savemax, readmax pair, but has problems with rearranging items on stack ...

Hmmm, I have a feeling the snibril constraint solution does not exist .
I have decided to run bruteforce search for it ... looks like several years of machine time would suffice to prove the nonexistence of it ... . (I am not searching for 20 op code, but 21 without > ...)

Hmmm, the estimate time is something between 10^8 to 10^12 years ... the prunnig is probably not powerful enough . ... maybe using idle time of all world computers ... but the energy consumption ...

... hvm simulator using graphic cards paralelism ... if something like that would be possible, than maybe ...