User long=3.874054 lat=43.606779 distance 0.00910473979397 Caisse d'assurance retraite et de la Sante au travail
User long=3.874054 lat=43.606779 distance 0.020912517158 Caisse Primaire d'Assurance Maladie
UserLocation: long=3.874054 lat=43.606779
the second entry is expected to win ? (Test 03 Complete file)
The 6371 is needed if you want the real distance with the given formula. Anyway, in your previous formula for approximating with euclidean distance, you were multiplying only the square of latitude difference instead of the sum, so latitude difference was way more important than longitude difference, which gave you wrong results.
There appears to be a localization error. My locale is EN but the decimal point is still shown as a “,” in the input when it should be a “.”. Additionally the data to the puzzle uses the “;” as the list separator. For EN this character is the pipe “|”. Maybe this second point is splitting hairs but for truly international code the input data will typically be in one language and the code will have to determine if the users locale differs from the data locale and if so then convert accordingly. I don’t suspect that is the intent of this exercise and thus is breaks down.
The following code, in C++, should debug print the same but it doesn’t because my locale differs from the games locale.
I would have to write conversion code to make this work but then when I submit my solution it will undoubtedly be run in the servers locale which differs from mine and will probably result in my code not passing.
Games aren’t localized, inputs are the same for everyone so everyone has to convert commas to dots.
However, inputs are actually CSV files (french variant) so the international separator would be the comma, not the pipe.
The french users don’t have to change commas to dots. For them intrinsically the value is numeric if read numerically. My point was that in my locale, EN, a bunch of hoops have to be jumped through, which are not necessary if my locale were FR.
If you prefer me to say it this way: the server thus the default locale of programs is the same for everyone, french or not. So french users do have to change commas to dots too.
In the French locale floating point numbers are expressed with the comma as the decimal point. Pi is expressed as 3,14159; when formatting or writing code to read it, it is treated intrinsically. To change it to 3.14159 breaks it from being a number. They don’t have to change commas to dots. In the french locale reading a number with dots produces wrong results or an error. In the Windows environment one can review the code page of the system and the special characters that define the decimal point, numerical grouping, currency, date/time format, etc…
If you are using an English code page, and C++ is your game language, you can fix the library to correctly read French formatted numbers with the following code. The cerr output shows that the numbers were correctly read.
Additionally if you use a stringstream to convert from string to number you can use the same trick. I was able to get a 100% solution without doing any wonky string replaces.
I’ve been stuck on this one for hours, I don’t understand it seems to me that I’m doing everything right, but the result is not what is expected… Could someone be so kind to give my code a second pair of eyes ? Maybe a really dumb error is escaping me… (it’s C++ code)
double defib_lon_rad = defib_lon_deg / 180 * Pi;
double defib_lat_rad = defib_lat_deg / 180 * Pi;
double x = defib_lon_rad-pos_lon_rad * cos((defib_lat_rad+pos_lat_rad)/2);
double y = defib_lat_rad-pos_lat_rad;
double d = sqrt(x*x+y*y)*6371;
DEFIB 1;Maison de la Prevention Sante;6 rue Maguelone 340000 Montpellier;;3,87952263361082;43,6071285339217
defib_lon_deg 3.87952263361082 defib_lat_deg 43.6071285339217
defib_lon_rad 0.06771044337099159 defib_lat_rad 0.761087970356679
d 119.0306201940585 x 0.0186831836603522 y -1.829918516416118e-05
DEFIB 2;Hotel de Ville;1 place Georges Freche 34267 Montpellier;;3,89652239197876;43,5987299452849
defib_lon_deg 3.89652239197876 defib_lat_deg 43.5987299452849
defib_lon_rad 0.06800714512659435 defib_lat_rad 0.760941387332427
d 120.903608013006 x 0.01897646279614148 y -0.0001648822094161284
DEFIB 3;Zoo de Lunaret;50 avenue Agropolis 34090 Mtp;;3,87388031141133;43,6395872778854
defib_lon_deg 3.87388031141133 defib_lat_deg 43.6395872778854
defib_lon_rad 0.06761196627113926 defib_lat_rad 0.7616544823099812
d 118.5389204666394 x 0.01859793672765127 y 0.000548212768138101
Zoo de Lunaret
The expected result is Maison de la Prevention Sante, but my results point to the last one
As a javascript-user I experienced issues with this puzzle. Not spoiling too much:
My issue came from using parseFloat, that does not provide the correct precision. I got the correct precision from using “Number” and a certain “toPrecision”. After that, BOOM, 100%
My code was passing all the test cases, but after submitting the code I would only get a score of 75%. Using the simplified formula, I get a score of 100%. Thanks for the hint!