Send your feedback or ask for help here!
Circles feel a bit unclear here. It would be good if you described the rounding for spheres, like “a point is on the border of a sphere only if has a rounded distance from the center equal to the radius”, as well as to define how calculations like that (referring to distance from the center of a circle and comparisons to a radius) work here. Otherwise a good puzzle!
The Python rounding is the problem here. I initialized the values to 0.0001, not to 0.
A good workaround for rounding in Python is
int(number + .5).
(If you just use
round, the defaults rounding is the banker’s rounding that round to closest even
2.5 -> 2 and
3.5 -> 4.)
What you’re describing is a way to solve the problem, which I feel does not need to be defined in the statement, and is not needed there. Also, you don’t need to round any distances in this puzzle.
Added a statement lightly touching the rounding requirement. Looks like it is suffice.
And as 5DN1L said, to determine whether a point is on a circle border, it does not need rounding. Only color division involves rounding.
I really liked the color blending challenge of this.
But I couldn’t give the full 5-stars because of the rounding confusion that I would not have known how to address without the work-around shown in the discussion section here. (I solved in C#)
Python behaves oddly in its round() function is a relatively common knowledge among its seasoned users. As you can perceive, a puzzle cannot specifically tell python coders how to do rounding correctly.
It is a language feature. Blame the python designers for not creating a normal round() function for general uses and another round_banking() function for bankers’ special needs.
Some work-around are indeed very well-know and applicable to other languages. If you learned a new trick after doing an exercise, congratulation to you to have one step advanced in the learning curve.
I think the description should say that the “thin” border of a shape has no thickness.
“All shapes have a thin black border”
If a radius of a circle is 8 and the distance from a point to the circle center is 7.99999, you are not on the border. If the distance is 8.000001, you are not on the border.
So when you round, like it says in the description, you fail.
“In case you have decimal values to handle, they should be rounded to the nearest integers.”
For me the validators were solid.
Thank you @java_coffee_cup for puzzle.
There is an easy way to see if you’re on a border : instead of computing sqrt(dx²+dy²) and compare to radius, you have to compute dx²+dy² and compare to radius². There is no rounding to do.
If you have a point having distance of 7.9 or 8.1 to center, both should be rounded to integer 8 before using it to check is the point “on the border”.
Think it this way - a distance of 8.1 does not exist because we do not have a 8.1 pixel length on the screen. (Or better say, we do not have coordinates of (7.9, 8.1) on a screen.)
Think it in another way - 8.1 does not exist and is useless, why generate it in the first place?
Is it possible to avoid using float point numbers in distance calculation?
No sin, cos, tan
You are saying in the description that you should round to integer.
In your answer to me, again you say that decimals should be rounded to integer.
If you do that, you will not pass the tests.
Test 01 RGB.
Shape 2 is a circle at position x,y 4,6. The radius is 3.
The fourth point is at position x,y 5,3.
The distance from the point to the circle is about 3.2.
If you round 3.2 to the integer 3 you will be on the border and you will fail the test.
The answer of test 01 for point 5,3 is “(0, 255, 0)”. Not “(0, 0, 0)”.
I got your idea. Rather than saying distance should be rounded to integer, it is better to say if the calculated radius is not an integer the point is not on the border. Would try to alter the statement a bit accordingly.