Okay, so first, for each vehicle type, compute the inverse weight as 1 / points. Normalize these weights to convert them into probabilities summing to 100%. This is done by dividing each weight by the total sum of all weights. Ensure the probabilities sum exactly to 100% by adjusting the last probability. For each vehicle type, compute the absolute difference between John's probability and the city's frequency and then sum all these differences. Subtract the total difference from 100% to calculate the match percentage: Match Percentage = 100 - Σ|P(Jhon) - P(City)|. If the match percentage is negative, set it to 0.

Here is an example: Points: [1, 3, 5, 6] City Frequencies: [58.82%, 19.61%, 11.76%, 9.81%] | Weight=[1, 1/3 ,1/5 ,1/6] | Sum of weights = 1.7 | Probabilities= [1/1.7, 0.33/1.7, 0.2/1.7, (1/6)/1.7]*100= | Probabilities = [58.82, 19.61, 11.76, 9.81] | In this case the sum is already 100%, so no adjustment is needed. | Differences= |58.82 - 58.82| + |19.61 - 19.61| + |11.76 - 11.76| + |9.81 - 9.81| = 0 | Match Percentage = 100 - 0 = 100.00%

The "match percentage" in this context measures how closely John’s point-based probability distribution aligns with the actual frequency distribution of vehicle types in the city. The purpose is to assess how well John's point system predicts the city's actual vehicle distribution. A high match percentage means the point system effectively captures real-world probabilities, while a low percentage suggests it deviates significantly, potentially making the game less representative of actual trends.

1 word book (only "Persepolis") was badly handled in my code,
it's fixed now :)

look like a bug.. i check that, thx

The code is fixed. Thanks for your response!

It's good that this errored because this means the tests were using the user's submission solution as the reference solution, which is dangerous

Thanks, I noticed that mistake in the example tests but forgot to fix it in the description.

Fixed

This is not OK anymore (on my part)
I'll check it

im sorry about this, my tests does not dump additional information yet, i'll fix this soon.

update: now you should be able to see exactly what went wrong.

Going to change it into a string once I have some spare time.

Rounding is one thing, but the place where potential problems are introcuded are calls to str(d). Stringification of doubles works in Python in a very specific way, and str does a lot of magic trying to come up with a very specific representation. This behavior is not inherent for IEEE-754 floats in general, and is not portable between languages (i.e. is not easily translatable). Without additional specification, users do not know that the reference solution uses str(d), and they do not know how to handle precision in a way considered correct by the tests.

The point is that there is no way of handling precision of floats, and representation of floats, which is considered "canonical". You made an assumption that the correct way is to use str(d) and rounding, but it is just one of possible assumptions, which is not universal. Without knowing this, users are missing some information necessary to come up with a correct solution.

Like natan said in the post above, float is not the best type to represent input for this problem. Something what represents "a sequence of digits" would be much better.

@PurrBunny

float does not represent decimal numbers. when you choose a type, make sure that it can encode the information you mean to convey.

if you consider it to be text, something you can write down, then the type for that is string.

some languages have a type to represent decimal numbers, that would kind of work, in that it's able to encode your values. however, what you're really conveying is the abbreviated number, not the number - so it probably shouldn't be a number type at all

if it is not text, but rather "many digits", then that's a list of integers

I have a workable solution by rounding everything. It is not theoretically 100% perfect, however practically there are no errors.

Its impossible to fix this issue and keep using floats. As long as floats are anywhere there, in solution or in tests, this challenge will be incorrect.