It breaks only on series with zero as the largest number and with the largest number in mem[0]./Zett
Surely Smallest Mouse
Surely Smallest Mouse
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
It breaks only on series with zero as the largest number and with the largest number in mem[0]./Zett
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...
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.
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.
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.
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.
Hippo
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 ...
)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 ...
.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 ...