Coding Games and Programming Challenges to Code Better
Send your feedback or ask for help here!
Created by @David_Augusto_Villa,validated by @DeanTheMachine,@TBali and @Eulero314.
If you have any issues, feel free to ping them.
By default “value” in Java is read as float and stored in a float variable because of this, the solutions will fail tests because there is not enough precision, so please change the initial Java code to use double.
// Test 5
Found: 3 4 43.195312
Expected: 3 4 43.1953125
I don’t think CodinGame provides such an option to puzzle creators. You’ll have to adjust the initial code yourself.
Any reason why CG uses float instead double? Because as i read float you should use only if you KNOW why you want use float over double. And here is example of this statement.
1 Like
I have no idea why. All I can say is that a puzzle creator is required to write only one code, using CG’s syntax, and the website will convert it to the default code in the programming language chosen by a player. Whether a player modifies the default code, or how he/she modifies it is up to him/her. And not all programming languages distinguish between floats and doubles.
If you want to discuss this further, you should probably start a new topic on this forum or on Discord, instead of under this puzzle discussion thread.
1 Like
The puzzle statement does not specify the required accuracy of decimal places.
The puzzle’s expected outputs have varying decimal places.
It could be the result of a few programming languages’ default presentation style of float-point numbers and the puzzle was designed around that few languages. It is convenient for the puzzle setter.
However, in computers where float point numbers are using a limited number of bits to represent the integer and fractional parts, all float point numbers are just approximations and it should have been clearly defined how accurate the value should be represented in output, be it accurate to 3 or 4 decimal places, rather than let it be elastic.
1 Like
I tried to use nice numbers everywhere. Not having to worry about rounding or specifying the precision of the output was supposed to make it easier on the programmer, since this is intended to be an easy puzzle and that would just be one more thing to have to consider. I will change the tests so that they work with single precision floating point as well. (Update: Done!) However, I’m a bit surprised that some languages would default to this. That issue should be raised for the stub code generator, I think.