I've fixed this (I hope) by adding a test case to the Example Tests in which a pixel is changed before re-testing. If anyone else runs into the same issue in future, it should at least be clear why their approach isn't working.
Oh, sorry, I didn't mean to say it's incorrect in terms of Python :) If all you give the challenger is a class with single method and test case where you put single input and check it multiple times in various ways it strongly implies the full tests will do the same. How to generate and test images? What about creating one with constructor, because contructors construct stuff, run tests on it, clean up and repeat? And if you want to just slightly modify the data on the fly (which you don't do), I would add a dedicated method.
On the other hand, taking a look at this case from the perspective of C/C++ language, if you pass the pointer to the constructor and between contructor and the central_pixels function you silently modify the data, I would consider this a bad design which has to be fixed.
I'd be interested to hear the views of a Python expert (I don't consider myself one) on this. Is it "seriously incorrect" for Image objects to be mutable? If so, what would be the correct Pythonic way to procedurally generate an image, test it, then modify it and test it again?
I cannot get through tests other than Sample Tests. I checked the inputs - printing self.pixels in __init__ shows arrays full of zeroes and printing the very same thing in central_pixels shows non-zero values. Any hints for python rookie? The very same code works as expected on Sample Tests.
EDIT: I found the answer below for similar question from brrandon13 and my reaction to this is: this is seriously incorrect way to create such exercise and it should be AT LEAST described that you CANNOT access the input data in the initializer. Especially when literally Sample Tests suggests you to precalculate the answers as your code is asked for various colors within single input.
This is a really nice kata, but currently rather spoiled by test cases that involve numerical values too large to represent in double-precision floating point. One random test that I got was
f(x) = 45.5^(39.4*69.2^88.3+44)
which cannot be evaluated as a complex<double> value. (The derivative can be, of course, but the function itself cannot.) If the author really intended solutions to be able to handle such huge numbers, some explanation is required in the description, and the complex<double> type needs to be replaced by something more appropriate.
Even when all the numbers are small enough to represent, there are loss-of-precision issues from e.g. subtracting nearly-equal quantities. These are not well tested at present - I avoided them by attempting the test suite a few times until it served up some random tests that my code could pass.
I encountered a problem, one of the test results was 341 and my code output was 741. When I tried to print the data of 741, the submitted test passed, only 151 test cases were run, and my code had been submitted.
Alright, test case are fine, the problem was with return statement in function.
For some reason the output pixels didn't match the valid pattern for expected value "1".
I believe the further pixels are hidden to prevent the brute force solutions?
The Single_Digits test group just tests images of "0", "1", ... "9", in that order.
Are you saying that you get an image of "0" for the second test in this group?
Also, what language are you using? C++?
I wouldn't like to see this become the norm on Codewars. Kata descriptions should be detailed enough to enable programmers to understand the task, but not so detailed that the focus is on the tests rather than the task itself.
Where performance is a requirement, it is important to warn codewarriors away from algorithms that will be too slow. For this kata, I think that's covered by the statement that test images can be up to megapixel size.
I suggest to simply replace or modify this part: The test suite includes some larger images, up to a few megapixels. These are not difficult to solve -- at this scale, the images are so detailed that any halfway-decent algorithm can hardly go wrong -- but execution speed may be an issue.
I've fixed this (I hope) by adding a test case to the Example Tests in which a pixel is changed before re-testing. If anyone else runs into the same issue in future, it should at least be clear why their approach isn't working.
Also if you change the content of an array/list, what stops you from changing its dimensions?
Oh, sorry, I didn't mean to say it's incorrect in terms of Python :) If all you give the challenger is a class with single method and test case where you put single input and check it multiple times in various ways it strongly implies the full tests will do the same. How to generate and test images? What about creating one with constructor, because contructors construct stuff, run tests on it, clean up and repeat? And if you want to just slightly modify the data on the fly (which you don't do), I would add a dedicated method.
On the other hand, taking a look at this case from the perspective of C/C++ language, if you pass the pointer to the constructor and between contructor and the central_pixels function you silently modify the data, I would consider this a bad design which has to be fixed.
I'd be interested to hear the views of a Python expert (I don't consider myself one) on this. Is it "seriously incorrect" for Image objects to be mutable? If so, what would be the correct Pythonic way to procedurally generate an image, test it, then modify it and test it again?
I cannot get through tests other than Sample Tests. I checked the inputs - printing self.pixels in __init__ shows arrays full of zeroes and printing the very same thing in central_pixels shows non-zero values. Any hints for python rookie? The very same code works as expected on Sample Tests.
EDIT: I found the answer below for similar question from brrandon13 and my reaction to this is: this is seriously incorrect way to create such exercise and it should be AT LEAST described that you CANNOT access the input data in the initializer. Especially when literally Sample Tests suggests you to precalculate the answers as your code is asked for various colors within single input.
In the C version, the largest value of n tested is not 5000.
This is a really nice kata, but currently rather spoiled by test cases that involve numerical values too large to represent in double-precision floating point. One random test that I got was
f(x) = 45.5^(39.4*69.2^88.3+44)
which cannot be evaluated as a
complex<double>value. (The derivative can be, of course, but the function itself cannot.) If the author really intended solutions to be able to handle such huge numbers, some explanation is required in the description, and thecomplex<double>type needs to be replaced by something more appropriate.Even when all the numbers are small enough to represent, there are loss-of-precision issues from e.g. subtracting nearly-equal quantities. These are not well tested at present - I avoided them by attempting the test suite a few times until it served up some random tests that my code could pass.
It's so cool~
I encountered a problem, one of the test results was 341 and my code output was 741. When I tried to print the data of 741, the submitted test passed, only 151 test cases were run, and my code had been submitted.
The text rendering in the images is imperfect - the digits may not have exactly the right shapes. It's meant to simulate scanning a paper document.
Alright, test case are fine, the problem was with return statement in function.
For some reason the output pixels didn't match the valid pattern for expected value "1".
I believe the further pixels are hidden to prevent the brute force solutions?
The Single_Digits test group just tests images of "0", "1", ... "9", in that order.
Are you saying that you get an image of "0" for the second test in this group?
Also, what language are you using? C++?
I wouldn't like to see this become the norm on Codewars. Kata descriptions should be detailed enough to enable programmers to understand the task, but not so detailed that the focus is on the tests rather than the task itself.
Where performance is a requirement, it is important to warn codewarriors away from algorithms that will be too slow. For this kata, I think that's covered by the statement that test images can be up to megapixel size.
Encounter incorrect test case for
Single_Digitswhich expected to be equal "1", but from the test case output should be equal to "0".I suggest to simply replace or modify this part:
The test suite includes some larger images, up to a few megapixels. These are not difficult to solve -- at this scale, the images are so detailed that any halfway-decent algorithm can hardly go wrong -- but execution speed may be an issue.In this manner:
[n] Fixed tests[n] Easy_Tests[n] Single_Digits[n] Small_Text[n] Low_Contrast_Images[n] Large_Images[n] Random_Tests[n] Variable_TestsLoading more items...