6 kyu
Bouncing Beams (Pt. 1)
57 of 179jkorinth
Loading description...
Puzzles
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Great Kata!
Fun :-) Is there a part 2?
How first answer of is equal to (0,1)? Isn't it (1,0)?
The same second example: it should end on (5, 7)! how it is (6,4)?
I am totally confused, with how answers have gotten? Can you explain me, please!
You have to be careful when reading the mazes, because in C++, backslashes are escaped what makes them tricky to read. Without escaped characters, mazes look like this:
I marked places where beam exits the maze with
+
, and they are located at(0,1)
for the first maze, and(6,4)
for the second maze.I am still confused, here is how i look to this:
Am I misunderstanding something here?
For this kata, coordinates in the maze are 0-based. First coordinate is horizontal (x), increasing left to right, and the second one is vertical (y) increasing from top to bottom. Such coordinate system is somewhat "customary" and I believe that's why it's not explained in details, but I've seen remarks in the comments that it's not sufficiently clarified in the description.
You are thinking as of [row][column] and the solution is [column][row]
Fixed C compiler warnings ;-)
Rust translation
I don't see any mentions of the order of the
position
property: which one is thex
direction and which one is they
direction?it's in there:
That's not explaining anything. How am I supposed to interpret
(0,1)
? Is it position or direction? Against what on the board? And which one is which dimension?You're not serious...? See, you're typically unreasonnable, here.
https://www.codewars.com/kumite/5eb240bce6a99d002d542431?sel=5eb240bce6a99d002d542431 ^ here's a python translation :)
It's a decent kata, but I agree with
@JohanWiltink
's comment. It's a familiar challenge, essentially a simpler version of my Ziggurat ride kata.I'd have ranked it higher but for the task not being new. Maybe it's new in C, in JS it's not. I don't know if it's really an issue, but this feels like more of the same old same old. Looking forward to new parts though, hope they do bring newness ( newity? ).
https://www.codewars.com/kumite/5cd3387ffb6f25456f8806b4
^ here's a javascript translation :)
Awesome! Would have merged it, but it says the latest changes from the record must be merged first?
Have you modified the description between now and then?
Yes, there was a merge conflict because of that. Forked and fixed the conflict here:
https://www.codewars.com/kumite/5cd3387ffb6f25456f8806b4?sel=5cd887ca5bf451002485da8e
Great, approved! :-)
Example tests were missing
assert
definition, therefore usingNode.assert
, therefore showing even a passed test with a red border. I fixed that.I also set the default
Node
version to10.x
, because I could. Why wouldn't you use the most recent supported version? You were already usingchai.assert
anyway?JS convention is to use camelCase, not snake_case. People are going to hate on that. It is very highly recommended to follow naming conventions on here.
Some explicit remark somewhere to return
[x,y]
and not the usual[y,x]
would be nice. ( I know, I know, maths use(x,y)
. But JavaScript uses[y][x]
and it's what we're used to. )It's never mentioned that when
*
doesnot exist,{{-1,-1},0}
is expectedTrue, because it is not required; all test cases have valid points of origin.
Nope,
circle_maze
andrandom_maze
all produce cases without*
ramdomlyI think it should still be said in the description; it's wiser imho.
Added a sentence in the summary.
Nope, how hard it is for you to understand that the random test generator always produce maps without
*
???????Yeah, no
*
is placed, as in the circular maze oneThis comment has been hidden.
It would have helped to mention that we're now discussing the C implementation, instead of the C++ implementation. :-(
CodeWars should mention that somewhere (it doesn't yet). All my apologies, it is indeed about the C implementation
@adri326: Comment was directed at @ZED.CWT, who appears to be losing patience with me, judging from the number of question marks. Thanks a lot for your suggestions, I've updated the kata.
Finally!...
I'm sorry, I really took extra time to clean it up, but obviously I have zero idea how to test katas. ☹ In my preview the initial solution compiles just fine - any pointers how I could test offline, or at least preview how the website merges the different code parts? Not even the line numbers make any sense here.
Well, a simple rule for katas on CW is, the initial solution should be runnable, and for katas including other definitions in the initial part, it should still be runnable after removing those definitions (unless they are specially mentioned in the desc) Paste the following in the solution panel and attemp (maybe you need to refresh the page or click
RESET
)Line numbers are.. not that important IMO, the printed code line shoule be enough for locating But if you really care about it.. then you can run with the first line containing syntax error and you would know the offset
Oh, so, do I understand you correctly: The initial solution was working until you removed code?
Noop, the initial solution itself is not runnable
Just checked it again, I can run the initial solution. Maybe you need to reset it to the current state?
How did you CHECKED????
I don't know what I'm doing wrong, I'm really not seeing these errors on my end. I've pressed re-publish several times now in the hope it'll change anything, but I have not means to check whether the code actually changed other than resetting my solution. If it does not work this time, I'll just stop wasting our time and withdraw it.
Nevertheless, thanks for testing, really! Please don't mistake my incompetence for reluctance to improve my kata, or even maliciousness.
Regarding the types: I'm sticking to the approach because this is a beginner's kata, and code wars is all about "production ready" code. I always encourage younger colleagues to use speaking names and concepts from the problem domain to name their types, classes, variables, etc. Many of the katas on code wars really disregard this aspect, using
std::vector<int>
to represent 2D coordinates,int
for things where negative values make no sense, and so on. Also, on the job you're seldom in a position to re-invent everything from scratch; chances are, you'll have to use predefined types likePos
andBoard
, whether you like it or not.Regarding the missing origins: I will investigate this right now; it should not have happened, my intention was that you may safely assume that there will always be a valid origin.
I could not reproduce the origin problem. I have increased the number of tests by 10x and inserted an
assert(false)
in the case no valid origin was found both in the test fixture and my solution, still my tests run through just fine. I've also changed the complete solution to return(1,1)
instead in case no*
was found, so that my complete solution and my validation solution contradict each other -- again without effect. Any help reproducing this bug would be appreciated.In the meantime I've extended the wording in the description to include the valid origin assumption. I will also add a comment to the custom types to explain that they should be used in the solution.
Okay, now it works. Maybe you havent successfully published last time o_O
This is not debuggable, please change to another type (maybe a simple
std::vector<uint64_t>
), or you will need to construct your own debug messageFixed.
Some still missing
Argh, dammit! Sorry, my first kata. Now it should finally work. 😅
Test cases should not relay on these definitions cause users can modify them easily
Wanted them to be visible for the user - should I preload them instead?
You could still leave it in the initial solution But you need to make another copy in the complete test, like
Done.
Thanks for testing, should be fixed now!