Watch this video, it will help you
I can’t understand the last case,“Not There”.I used consle.error try to find why.But it print nothing…Please tell me Why…
your timeout must happen before your print to the error stream. Try adding some error messages before.
Where can I see answers in js?
Once you solved it in JS.
If you solved the puzzle in js you can see the shared solutions:
- From the IDE in the “Results” tab.
- From the puzzle’s page in the “Solutions” tab.
Ok thanks!
I am getting an erreur : you are nor providing entry in due date. Could you help please
if you look just above in the console, you have another error:
SyntaxError: invalid syntax
at Answer.py. not in a function on line 24
is this answer for me?
thank you. it worked. now I have to resolve
6th test (evasive) is just killing me I spent most of Saturday evening to understand, what is wrong with my solution.
With my algorithm (tried in Perl and in Javascript) I got same solution on 7th step as with Java example, but still it says:
Standard Output Stream:
[…my actual values here…]
Game information:
Failure: you are too late. Joker’s bombs exploded. The hostages are dead. You lose Batman moved from window […my actual values here…] to window […my actual values here…] The bombs are located above Batman
I choosed a bit different approach (compared with Java example), so seems like there is not important to find right window, but to find it in certain way.
Rule states:
Your mission is to program the device so that it indicates the location of the next window Batman should jump to in order to reach the bombs’ room as soon as possible .
It also says that:
For some tests, the bombs’ location may change from one execution to the other : the goal is to help you find the best algorithm in all cases.
With Java example the final target is every time the same window.
So I tried to cheat a bit: if I tweak my program just to iterate over array (containing steps I previously calculated with my agorithm), does it satisfy the test? Like
my @steps =(
[3,49],
[2,25],
[1,13],
...
);
And it did not, also. So I tried with values, calculated with Java version, and test was happy. After I changed my steps
-array last 3 steps with correspondings from Java steps, test was happy with my work.
So, conclusion: I am a bit disappointed, that this test does not actually follow the rules. If my algorithm finds solution by the stated rules, it should be right solution, even if it uses different approach.
I share my solution happily, if someone wants to dig in and make sure, my code really works as stated. Just tought it is not appropriate to post it here.
Without seeing your code, I am already sure of two things:
- All the tests and validators follows the rules.
- If your code doesn’t pass some tests or validators, it’s because it doesn’t work as stated.
But you can share it if you want some hints of the why…
I saved my code as a gist here, I did not found a way to share my code with personal message, so I had to post link here. Hope it is not too much,
The sentence you quoted means that the window differs from one test to another.
But the same test always has the bomb in the same window, it’s intended like this.
The validators are different from the tests to make it hard to hardcode your solution, but generally the nth validator is somehow similar to the nth test (similar size, similar edge case to check).
If your solution fails, it’s just that you take too many turns to find the good window.
The specific order you follow to check the windows doesn’t matter, as long as you find the bomb fast enough.
I believe there’s a tag “dichotomy” in the problem description, you might want to check what it is, it would help you create a faster algorithm.
Looking at the code there’s already a dichotomic approach.
@w_k There’s a couple things I’d say about your code but overall it looks good enough. So I tested it in the IDE and corrected the problem by replacing
let actualJump = [ (parseInt( width/2 ) || 1 ), (parseInt( height/2 ) || 1 ) ];
with
let actualJump = [ Math.ceil(width / 2), Math.ceil(height / 2) ];
Not sure why you were parsing int values in the first place.
I try to explain:
- I took seven window locations from my solution and made it as array
- I made new solution, which takes just those 7 hardcoded steps and iterates over them
- It does not work
- I made same with Java example
- Those hardcoded steps did work
- Both arrays have one common thing: last/seventh step
- I tried to swap out 6th step in my hardcoded array with corresponding I made from Java example
- It did not work
- Then I swapped also 5th step
- Now my hardcoded solution works.
What is your conclusion?
You can take my solution and Java example and try them out. They both end in the same window on 7th step.
How do you define faster algorithm, when both solutions take same amount of steps?
Thank you, parseInt
was certainly wrong way to round off to int
.
I am still confused: why my approach was counted as failed, when it took 7 steps and found right window…
PS I originally wrote my solution in Perl and ceil
and floor
functions are from Posix
module. Unfortunately this module is not accessible from IDE
This puzzle is peculiar cause the bomb position can vary from one execution to another, and it seems that the position of the bomb is decided in function of your first move.
So a hard-coded solution has a really few chances to work, unless you are sure of where the bomb gonna be after the first move you will make. That’s why hard-coded steps generated from a valid solution works.
You can see where the bomb really is by activating the debug mode in the viewer (By clicking on the gear icon).
You are right, location varies. But it does not depend from first move. Actually, I did combine my 4 steps with 3 steps from Java solution to hardcoded version, and it worked fine.
I think, that moving target (depending from your steps) is very interesting variation of this puzzle, but this is not stated in the rules. Rules says: target may change from execution to execution, not that it may be interacted with your steps.
I had maximized my console output pane, so I did not even saw, that there is even visualization and debug opportunities. Thank you for pointing!