[Community Puzzle] Particle Detection with Cloud Chamber

https://www.codingame.com/training/medium/particle-detection-with-cloud-chamber

Send your feedback or ask for help here!

Created by @LaurentValade,validated by @Marchete,@Fluxor and @LastRick.
If you have any issues, feel free to ping them.

Really unique puzzle, was fun to code and approve. But I’m having issues now with Validator 1 (all tests and other validators pass). Is Val 1 still the straight line shown on the contribute page?

1 Like

I encountered a few issues while solving this.

  • the statement requests rounding to the tenth, yet all test/validator outputs are integral
  • I find a very different radius for test 6 (55 vs 60). I work around it by recomputing the radius from the known particle properties, but it’s unclear this is what is asked. (seems to impact validators 4 and 6)
  • the relative g error formula threshold of 0.5 consistently confuses protons and alpha. Using 0.4 or picking best match works around it, but… why give a specific formula if it can’t work?

Great puzzle otherwise. Nice to see a good use of ASCII art for once.

2 Likes

Same for point 2, I used a statistical approach and ended up filtering the points aggressively (sigma <= 2) to get results in line with the expected output.
Also same for point 3, in that case I simply took the particule with the least error (closest to 0) and it worked, but that’s not something covered in the description.

I imagine the difference in radius for Test 6 is due to the issue in your first line. The confusion comes from the author using the word “tenth”. Here, it doesn’t mean “0.1” (to the right of the decimal); instead it means “to the nearest multiple of ten”. Something like "10*(int(radius/10)).

1 Like

If the radius is computed correctly (see my other note), you shouldn’t need that kind of check on least error. In my code (Dart), I found that using StringAsFixed(4) is enough accuracy to match the q/m values in the table.

For test 4 you do. If you use the correct radius of 60 you get a value of 0.49664609605580906 for the proton, and 2.0204107484267375e-16 for the alpha particle. Both are strictly under 0.5.

Not sure where those values are coming from. According to the table, g = Q/m, which for alpha is around 0.005 (2/3727), while proton Q/m is 0.001 (much smaller). Using R = 60 in the gammaV BRC equation (right side of the equation), g ~ 0.005. My code is literally a stack of if-statements like:
g.toStringAsFixed(4) == (2/3727).toStringAsFixed(4)
and this is enough to pass the tests.

Well, except Validator 1. Would love to know why I can’t get past that.

The formula for G is 1e6 * V / (B * R * c * ((1 - V ** 2) ** 0.5)), for a radius of 60 that gives you 0.000536624631070566.
The proton has a g_p value of abs(charge) / mass which is 0.0010660980810234541
If you compute the final formula abs(g_p - G) / g_p you get 0.49664609605580906.

I assume that your calls to toStringAsFixed are doing some rounding and that’s why you may not get the same result.

1 Like

Exactly!
I’m sorry for this mistake, I am quite weak in English :disappointed_relieved: !
I would like to correct it, but I don’t know if I can still edit a puzzle after its approval…

You can edit your puzzle from its contribution page, even after its approval.

1 Like

Hi Djoums,
I am not sure to understand where your problem came from, maybe it is because of my error in the statement with «nearest tenth» instead ef «the nearest multiple of 10».
Before writing this answer, I was sure that the abs(q)/m particle interval does not overlap as I choose the value .5 for the threshold of abs(g_p - G) / G such as, but my bad, abs(q)/m interval of proton and alpha overlap :expressionless: :rage: :pleading_face: :cry: :thinking: !

e-   : q = -1, m =    0.511  ==>  abs(q)/m =     1.96  :  G ∈ [   0.978,     2.94]
p+   : q =  1, m =  938.000  ==>  abs(q)/m =  0.00107  :  G ∈ [0.000533,   0.0016]
n0   : q =  0, m =  940.000  ==>  abs(q)/m =        0  :  G ∈ [       0,        0]
alpha: q =  2, m = 3727.000  ==>  abs(q)/m = 0.000537  :  G ∈ [0.000268, 0.000805]
pi+  : q =  1, m =  140.000  ==>  abs(q)/m =  0.00714  :  G ∈ [ 0.00357,   0.0107]

I took this criterion as a detail, but the devil is in the details!

So maybe I should change the statement

Likewise, the ratio g = |q|/m could not be computed exactly. Let’s note g_p the theoritical value of particle p (given in the table below) and G the computed value from picture with the formula above.
If
abs(g_p - G) / g_p < .5
one can conclude that the particle which just passed through the cloud chamber was p .
If none of the five known particle satifies
abs(g_p - G) / g_p < .5
one can conclude that the particle which just passed through the cloud chamber is unknown.

for

Likewise, the ratio g = |q|/m could not be computed exactly. Let’s note g_p the theoritical value of particle p (given in the table above) and G the computed value from ASCII-art picture with the formula above.
The particle p which just passed through the cloud chamber is the one with the minimal value of
abs(g_p - G) / g_p
if this value is stricly below .5, i.e. :
abs(g_p - G) / g_p < .5
If G is such that
abs(g_p - G) / g_p >= .5
for every known particles (those in the table above), one can conclude that the particle which just passed through the cloud chamber is unknown (as its value of abs(q)/m is too far from every known particle).

An other solution would be to change the threshold .5 for a smaller value, but

  • it would make the game a lot harder because a better precision on the computed radius would be needed,
  • it would not be backward compatible for the test/validator.

What do you think?

Thank you :slight_smile: !
Indeed, there were some mistake in the statement, sorry :worried: !
About your first point, as explained by @LastRick I wrote «closest tenth» instead of «nearest multiple of 10».
About your second and third point, the statement was indeed unclear and ambiguous, see my answer to @Djoums :
[Community Puzzle] Particle Detection with Cloud Chamber

2 Likes

I think it’s fine to take the particle with the lowest ratio, that’s what I did intuitively. Mentionning it in the description like you proposed would be enough :slightly_smiling_face:

1 Like

I’ll do that :slight_smile:

Done :slight_smile: !