Passive Infrared Sensor - Bugged ?

[RykoJLL]

Hello,
Im started playing SHENZEN IO just a week ago and i totally love that game. Im now at the Passive Infrared Sensor Level and i think it might be bugged.
I wrote my code, which i think is right , but when i simulate the circuit it works perfectly for 4 Cycles , then instantly jumps to Test Run 9 where my output doesn`t match the expected. According to the rules given on the Information Tab my code does the right thing , but yeah the expected output doesen`t match. On the Screenshot you can see my code and the point where it breaks.

Screenshot : https://imgur.com/a/HkTcG

Maybe you can confirm it, or prove me wrong and tell me my mistake :D .

[G4mm4g0bl1n]

The fail line must be this:
-mov 0 p1

If one TEQ comparison from above will negative, will the pointer jump to -mov 0 p1 .
You have to rearrange this. :)

[RykoJLL]

Hmm i debugged it and it will only jump to the -mov 0 p1 if the teq acc 1 negates. Also if you look at the values, the condition time == on_time is not fullfilled or am i wrong at this point ?
Also dont get me wrong i dont like calling out "It is a bug" in case something does not work, but i really cant explain right now.

[AlexMBrennan]

No test cycle can test all possible legal inputs, so you would expect a partial solution (which works for some legal inputs but not all of them) to pass some test cycles but not all of them.

In particular, the "slp 1" statement at the start seems particularly dodgy - you assume that the sensor starts off, but single stepping through the execution makes it obvious that this is not the case in all test cycles

If one TEQ comparison from above will negative, will the pointer jump to -mov 0 p1 .
You have to rearrange this. :)

That is the point. If the sensor is not on, it skips the 2nd test and jumps to outputting zero as per the specification. If the sensor is on, but the input is less than or equal to 20, then it still outputs 0 as per the specification. Only if the sensor is both ON and the input is greater than 20 is the output set to 100, as per the specification.

[G4mm4g0bl1n]

translate it in your language and you will see your logic problem:

IF teq dat x0 OR teq dat x1 OR teq acc 1 == NEG
Return(mov 0 p1)

[AlexMBrennan]

Originally posted by ¢ÒÓ£ $p0†:

translate it in your language and you will see your logic problem:

IF teq dat x0 OR teq dat x1 OR teq acc 1 == NEG
Return(mov 0 p1)

Multiple tests in sequence reset the hidden +/- variable each time, so you are simply wrong.

teq dat x0
teq dat x1

is equivalent to

teq dat x1

because the outcome of the first test gets overwritten without ever being used.

[G4mm4g0bl1n]

Yep, and exactly this is the problem
IF teq dat x0 == NEG
Return(mov 0 p1)

IF teq dat x1 == NEG
Return(mov 0 p1)

IF teq acc 1 == NEG
Return(mov 0 p1)

Thats, because it just exists only one negative Instruction for all Comparisions.

Its like a switch break comparison. In the case which we see is the Negative Instruction equal to "Default:".

Or my imagination goes wrong with me, but I guess this is the problem.

[AlexMBrennan]

IF teq dat x0 == NEG
Return(mov 0 p1)

Lines without a +/- prefix are always executed. Lines with a prefix are executed only if the last test command returned true/false respectively but execution order is still followed. There is no particular reason why you would need any lines tagged with a +/-.

#Double acc if x0 is 100
teq x0 100
+ mul 2

#In theory you could have an explicit -nop but that's not needed
teq x0 100
+mul 2
-nop

#Valid but equivalent to nop
teq 1 2
mov acc x0

In particular, the "teq acc 1" is always executed (since it doesn't have a prefix and there are no jumps to skip it), so the results of the earlier tests are overwritten.

[Ozone]

It's fun how some people pretend the game is bugged before considering maybe they did a mistake in their code.

[RykoJLL]

@OzoneGrif
As mentioned above, i dont like calling out it`s a bug, but im working on this puzzle for a several days and couldn`t explain the output given by the rules and the input values. (Also see my Edit in the 2nd post) . Also i asked if the level was bugged or if there was just a error in my code i didn`t see. But i definitly see that you didn`t really read the topic and instantly judge.

[Erdschüttler]

There are some places where the problem description is very accurate and the test outputs may be a bit unexpected, but this is definitly not the case here. It clearly says the device should be armed when the on time is reached, here the test simply starts at the on time. Your MCs are both still sleeping on the first step, so that is already a bug there.
BTW you can get rid of the second MC by using an DX300 to output the alarm.

[diversario 🏳️‍🌈]

Holy crap! I literally spent DAYS trying to solve this and couldn't because I tried to write it in such way that, if you would start within an ON time frame, it would detect it and be on.

Having re-read the description I wrote a really simple program that would only detect when time boundary is crossed and voila, tests passed.