![\"arctan](\"https://storage.googleapis.com/kaggle-forum-message-attachments/369949/10056/atan1.png\")
Did I disclose I have been using DBSCAN? Well, now you know ;)
\n\nMy approach is quite straightforward and has been almost fully disclosed by @yuval. An helix that starts from z axis can be described by 4 parameters:
\n\nz0r0phi0zrThe last 3 can be expressed as functions of the momentum at origin, px, py, pz, and pt = sqrt(px² + py²):
r0 = C * ptphi0 = arctan(py/px)zr = pz/ptThe formula to compute C is given in the documents from CERN but I estimated it from the train data via a linear regression. That's the only use of supervised learning I made ;)
My code loops over z0, r0 pairs. Rather than estimating a distribution I just sample from the tracks in the first 100 train samples. For each pair I 'unroll the helix', i.e. compute phi0 and zr as:
phi0 = phi +- theta0\nzr = (z - z0) / (2 * r0 * theta0)\nwhere rt is the distance to origin in transverse plane, phi the angle in transverse plane, and theta0 is the unrolling angle:
rt = sqrt(x² + y²)\nphi = arctan(y/x)\ntheta0 = arcsin(rt / (2 * r0))\nIn one iteration I add theta0 to phi, and in the next iteration I subtract it.
In order to cope with the discontinuity at pi and -pi I use cos(phi0) and sin(phi0).
The distribution of zr is highly skewed. Many have use arctan to unskew it, but I found that using arcsinh was way more effective. I actually use:
arcsinh(zr / 0.7) / 3.5\nThe picture below gives the distribution of arctan(zr), and the one below the distribution of arcsinh. The latter is way more uniform.
\n\n
![\"arcsinh](\"https://storage.googleapis.com/kaggle-forum-message-attachments/369949/10055/asinh.png\")
The last twist is to model the uneven magnetic field at high values of z. The picture below shows the relative difference between the theoretical angle, and the median of measured angle as a function of z, the picture below gives the number of hits in log scale:
![\"ratio1\"](\"https://storage.googleapis.com/kaggle-forum-message-attachments/369949/10052/ratio1.png\")
The best way I found was to multiply theta0 with a correction that depends on z:
1.005 - (abs(z + 200) / 6000)**2.4\nThe picture below shows a smoothed average of the median measured angle deviation (in blue), and my correction function (in red):
\n\n![\"ratio\"](\"https://storage.googleapis.com/kaggle-forum-message-attachments/369949/10053/ratio.png\")
DBSCAN is run at each iteration. Its output is merged with existing tracks in a simple way: for each track, or candidate track, I compute the number of volumes with hits from the track. Hits are then assigned to the candidate track with the most volumes. Using number of volumes is way more effective than using the number of hits in the track.
\n\nAnother criteria is used for deciding which track wins. I assign a unique vl_id to each volume_id, layer_id pair. For each of the first 100 train events I represented each particle track by the sequence of its vl_id once data is sorted by z. I then compute the frequency of each sub sequence of 4 vl_id . The quality of each track candidate in test events is computed in a similar way: first create the sequence of its vl_id once data is sorted by z, then take the average of the log of the frequencies of its sub sequences of length 4, and multiply by the number of volumes of the candidate track. A hit is assigned to a new candidate track if the new candidate track has both more volumes and a better quality than the current track of the hit. This quality is very effective in removing tracks that do not make sense, for instance tracks that skip a layer entirely.
The above yields a LB score above 0.785 with about 33000 DBSCAN runs. It takes about 10 hours per event.
\n\nThe extra mileage I got comes for a simple idea: run another, similar model, on the inner volumes only (7, 8, and 9). This model can be more conservative (smaller eps for DBSCAN) because tracks are closer to perfect helix. I ran this model for about the same number of iterations, then merged its output with the previous model: tracks that overlap significantly are merged, and for the rest, the track with most volumes wins.
\n\nThe very last improvements (about 0.002) come from merging with a third model that is similar to the first one.
\n\nThat's it, no fancy math, just lots of tuning. I hope I have not made errors in the equations, I'll check again tomorrow, but appreciate if you find typos. They must be correct in the code given the results: the code finds about 95% of the centered tracks.
\n\nThings I thought about but did not had time to finish implementing:
\n\nI thought my approach would be a nice starting point for second phase, given its simplicity, but I no longer think it is, now that I saw @icecuber solution!
", "messages": [ { "id": 369949, "postDate": "2018-08-14T01:27:51.737Z", "content": "Did I disclose I have been using DBSCAN? Well, now you know ;)
\n\nMy approach is quite straightforward and has been almost fully disclosed by @yuval. An helix that starts from z axis can be described by 4 parameters:
\n\nz0r0phi0zrThe last 3 can be expressed as functions of the momentum at origin, px, py, pz, and pt = sqrt(px² + py²):
r0 = C * ptphi0 = arctan(py/px)zr = pz/ptThe formula to compute C is given in the documents from CERN but I estimated it from the train data via a linear regression. That's the only use of supervised learning I made ;)
My code loops over z0, r0 pairs. Rather than estimating a distribution I just sample from the tracks in the first 100 train samples. For each pair I 'unroll the helix', i.e. compute phi0 and zr as:
phi0 = phi +- theta0\nzr = (z - z0) / (2 * r0 * theta0)\nwhere rt is the distance to origin in transverse plane, phi the angle in transverse plane, and theta0 is the unrolling angle:
rt = sqrt(x² + y²)\nphi = arctan(y/x)\ntheta0 = arcsin(rt / (2 * r0))\nIn one iteration I add theta0 to phi, and in the next iteration I subtract it.
In order to cope with the discontinuity at pi and -pi I use cos(phi0) and sin(phi0).
The distribution of zr is highly skewed. Many have use arctan to unskew it, but I found that using arcsinh was way more effective. I actually use:
arcsinh(zr / 0.7) / 3.5\nThe picture below gives the distribution of arctan(zr), and the one below the distribution of arcsinh. The latter is way more uniform.
\n\n
The last twist is to model the uneven magnetic field at high values of z. The picture below shows the relative difference between the theoretical angle, and the median of measured angle as a function of z, the picture below gives the number of hits in log scale:
The best way I found was to multiply theta0 with a correction that depends on z:
1.005 - (abs(z + 200) / 6000)**2.4\nThe picture below shows a smoothed average of the median measured angle deviation (in blue), and my correction function (in red):
\n\n
DBSCAN is run at each iteration. Its output is merged with existing tracks in a simple way: for each track, or candidate track, I compute the number of volumes with hits from the track. Hits are then assigned to the candidate track with the most volumes. Using number of volumes is way more effective than using the number of hits in the track.
\n\nAnother criteria is used for deciding which track wins. I assign a unique vl_id to each volume_id, layer_id pair. For each of the first 100 train events I represented each particle track by the sequence of its vl_id once data is sorted by z. I then compute the frequency of each sub sequence of 4 vl_id . The quality of each track candidate in test events is computed in a similar way: first create the sequence of its vl_id once data is sorted by z, then take the average of the log of the frequencies of its sub sequences of length 4, and multiply by the number of volumes of the candidate track. A hit is assigned to a new candidate track if the new candidate track has both more volumes and a better quality than the current track of the hit. This quality is very effective in removing tracks that do not make sense, for instance tracks that skip a layer entirely.
The above yields a LB score above 0.785 with about 33000 DBSCAN runs. It takes about 10 hours per event.
\n\nThe extra mileage I got comes for a simple idea: run another, similar model, on the inner volumes only (7, 8, and 9). This model can be more conservative (smaller eps for DBSCAN) because tracks are closer to perfect helix. I ran this model for about the same number of iterations, then merged its output with the previous model: tracks that overlap significantly are merged, and for the rest, the track with most volumes wins.
\n\nThe very last improvements (about 0.002) come from merging with a third model that is similar to the first one.
\n\nThat's it, no fancy math, just lots of tuning. I hope I have not made errors in the equations, I'll check again tomorrow, but appreciate if you find typos. They must be correct in the code given the results: the code finds about 95% of the centered tracks.
\n\nThings I thought about but did not had time to finish implementing:
\n\nI thought my approach would be a nice starting point for second phase, given its simplicity, but I no longer think it is, now that I saw @icecuber solution!
", "rawMarkdown": "Did I disclose I have been using DBSCAN? Well, now you know ;) \n\nMy approach is quite straightforward and has been almost fully disclosed by @yuval. An helix that starts from z axis can be described by 4 parameters:\n\n - z at origin `z0`\n - radius `r0`\n - angle at origin in transverse plane (x,y plane) `phi0`\n - slope `zr`\n\nThe last 3 can be expressed as functions of the momentum at origin, `px`, `py`, `pz`, and `pt = sqrt(px² + py²)`:\n\n - `r0 = C * pt`\n - `phi0 = arctan(py/px)`\n - `zr = pz/pt`\n\nThe formula to compute `C` is given in the documents from CERN but I estimated it from the train data via a linear regression. That's the only use of supervised learning I made ;)\n\nMy code loops over `z0, r0` pairs. Rather than estimating a distribution I just sample from the tracks in the first 100 train samples. For each pair I 'unroll the helix', i.e. compute `phi0` and `zr` as:\n\n phi0 = phi +- theta0\n zr = (z - z0) / (2 * r0 * theta0)\n\nwhere `rt` is the distance to origin in transverse plane, `phi` the angle in transverse plane, and `theta0` is the unrolling angle:\n\n rt = sqrt(x² + y²)\n phi = arctan(y/x)\n theta0 = arcsin(rt / (2 * r0))\n\nIn one iteration I add `theta0` to `phi`, and in the next iteration I subtract it.\n\nIn order to cope with the discontinuity at `pi` and `-pi` I use `cos(phi0)` and `sin(phi0)`. \n\nThe distribution of `zr` is highly skewed. Many have use `arctan` to unskew it, but I found that using `arcsinh` was way more effective. I actually use:\n\n arcsinh(zr / 0.7) / 3.5\n\nThe picture below gives the distribution of arctan(zr), and the one below the distribution of arcsinh. The latter is way more uniform.\n\n![arctan distribution][1]\n\n![arcsinh distribution][2]\n\nThe last twist is to model the uneven magnetic field at high values of `z`. The picture below shows the relative difference between the theoretical angle, and the median of measured angle as a function of `z`, the picture below gives the number of hits in log scale:\n\n![ratio1][3]\n\nThe best way I found was to multiply `theta0` with a correction that depends on `z`:\n\n 1.005 - (abs(z + 200) / 6000)**2.4\n\nThe picture below shows a smoothed average of the median measured angle deviation (in blue), and my correction function (in red):\n\n![ratio][4]\n\nDBSCAN is run at each iteration. Its output is merged with existing tracks in a simple way: for each track, or candidate track, I compute the number of volumes with hits from the track. Hits are then assigned to the candidate track with the most volumes. Using number of volumes is way more effective than using the number of hits in the track. \n\nAnother criteria is used for deciding which track wins. I assign a unique `vl_id` to each `volume_id, layer_id` pair. For each of the first 100 train events I represented each particle track by the sequence of its `vl_id` once data is sorted by `z`. I then compute the frequency of each sub sequence of 4 `vl_id` . The quality of each track candidate in test events is computed in a similar way: first create the sequence of its `vl_id` once data is sorted by `z`, then take the average of the log of the frequencies of its sub sequences of length 4, and multiply by the number of volumes of the candidate track. A hit is assigned to a new candidate track if the new candidate track has both more volumes and a better quality than the current track of the hit. This quality is very effective in removing tracks that do not make sense, for instance tracks that skip a layer entirely. \n\nThe above yields a LB score above 0.785 with about 33000 DBSCAN runs. It takes about 10 hours per event.\n\nThe extra mileage I got comes for a simple idea: run another, similar model, on the inner volumes only (7, 8, and 9). This model can be more conservative (smaller eps for DBSCAN) because tracks are closer to perfect helix. I ran this model for about the same number of iterations, then merged its output with the previous model: tracks that overlap significantly are merged, and for the rest, the track with most volumes wins.\n\nThe very last improvements (about 0.002) come from merging with a third model that is similar to the first one.\n\nThat's it, no fancy math, just lots of tuning. I hope I have not made errors in the equations, I'll check again tomorrow, but appreciate if you find typos. They must be correct in the code given the results: the code finds about 95% of the centered tracks.\n\nThings I thought about but did not had time to finish implementing:\n\n - Use direction information from cells data\n - Extend to tracks that do not pass near z axis\n - Fit helix to each track candidate to remove outliers and possibly add missing hits.\n\nI thought my approach would be a nice starting point for second phase, given its simplicity, but I no longer think it is, now that I saw @icecuber solution!\n\n\n [1]: https://storage.googleapis.com/kaggle-forum-message-attachments/369949/10056/atan1.png\n [2]: https://storage.googleapis.com/kaggle-forum-message-attachments/369949/10055/asinh.png\n [3]: https://storage.googleapis.com/kaggle-forum-message-attachments/369949/10052/ratio1.png\n [4]: https://storage.googleapis.com/kaggle-forum-message-attachments/369949/10053/ratio.png", "votes": 41 }, { "id": 370324, "postDate": "2018-08-14T16:09:56.577Z", "content": "Thanks for you sharing,My solution is also based on DBScan and I also have no time to finish:\"Use direction information from cells data and Extend to tracks that do not pass near z axis\",but I fitted helix to extend the tracks.I also used the tips from Heng to find candicate hits and desinged a LGBM model to classify the candidates.
", "rawMarkdown": "Thanks for you sharing,My solution is also based on DBScan and I also have no time to finish:\"Use direction information from cells data and Extend to tracks that do not pass near z axis\",but I fitted helix to extend the tracks.I also used the tips from Heng to find candicate hits and desinged a LGBM model to classify the candidates.\n", "votes": 4, "replies": [ { "id": 370361, "postDate": "2018-08-14T17:33:31.113Z", "content": "Yes, track extension was definitely a miss for me. Congrats on your result, even if you passed me at the last minute ;)
", "rawMarkdown": "Yes, track extension was definitely a miss for me. Congrats on your result, even if you passed me at the last minute ;)" } ] }, { "id": 376482, "postDate": "2018-08-27T15:45:48.820Z", "content": "Final code and documentation is available on github: https://github.com/jfpuget/Kaggle_TrackML
\n\nI found why my local score was higher than the LB: I forgot to use the magnetic field correction in one model... Once fixed local score and LB score become much closer, with a difference smaller than 0.001. I document and share code for the fixed models.
", "rawMarkdown": "Final code and documentation is available on github: https://github.com/jfpuget/Kaggle_TrackML\n\nI found why my local score was higher than the LB: I forgot to use the magnetic field correction in one model... Once fixed local score and LB score become much closer, with a difference smaller than 0.001. I document and share code for the fixed models.", "votes": 1 }, { "id": 375535, "postDate": "2018-08-25T11:47:44.500Z", "content": "@CPMP
\n\nThanks for the solution. It is a nice piece of work!
", "rawMarkdown": "@CPMP\n \nThanks for the solution. It is a nice piece of work!\n", "votes": 1, "replies": [ { "id": 375611, "postDate": "2018-08-25T15:59:31.750Z", "content": "Thanks you Heng!
\n\nYour remark about supervised learning being mandatory for reaching 0.8 has been a driver for me!
\n\nIt is a pity you did not had time to submit a good solution at the end. I was surprised, as many of us, to not see you above 0.8 at the end.
", "rawMarkdown": "Thanks you Heng! \n\nYour remark about supervised learning being mandatory for reaching 0.8 has been a driver for me!\n\nIt is a pity you did not had time to submit a good solution at the end. I was surprised, as many of us, to not see you above 0.8 at the end." }, { "id": 375637, "postDate": "2018-08-25T17:17:48.230Z", "content": "i have some urgent project at work the last minute. I will be continuing this in the speed phase if time permits. Right now, i am at the TGS salt identification competition, do come and take a look!
", "rawMarkdown": "i have some urgent project at work the last minute. I will be continuing this in the speed phase if time permits. Right now, i am at the TGS salt identification competition, do come and take a look!", "votes": 1 }, { "id": 375656, "postDate": "2018-08-25T17:59:06.563Z", "content": "I am considering TGS or Airbus as my next ones ;)
", "rawMarkdown": "I am considering TGS or Airbus as my next ones ;)", "votes": 1 } ] }, { "id": 374054, "postDate": "2018-08-22T11:13:16.807Z", "content": "I have put some code on github
\n\nThis is work in progress, the repo should be final by Monday.
\n\nThe code computes something that should give a LB above 0.78. I'm running it as of now to see what score exactly this yields.
\n\nCleaning my code revealed few little glitches that explain why my LB score was below my local score. I hope the code on github fixes that.
", "rawMarkdown": "I have put some code on [github][1] \n\nThis is work in progress, the repo should be final by Monday. \n\nThe code computes something that should give a LB above 0.78. I'm running it as of now to see what score exactly this yields.\n\nCleaning my code revealed few little glitches that explain why my LB score was below my local score. I hope the code on github fixes that.\n\n\n [1]: https://github.com/jfpuget/Kaggle_TrackML", "votes": 1, "replies": [ { "id": 374326, "postDate": "2018-08-22T20:29:13.680Z", "content": "@CPMP thanks so much for sharing.
", "rawMarkdown": "@CPMP thanks so much for sharing. ", "votes": 1 } ] }, { "id": 372564, "postDate": "2018-08-19T18:01:32.607Z", "content": "Congratulations, CPMP! I always learn great things from your posts.
", "rawMarkdown": "Congratulations, CPMP! I always learn great things from your posts.", "votes": 1 }, { "id": 371557, "postDate": "2018-08-17T05:10:42.380Z", "content": "I'm trying to understand how I can get a better score. You have many improvements, probably every step give you a boost. \nAnyway, Yuval said that's easy yo get 0.7 with right features. I tried his approach with the normal distribution but didn't get a better score. And my features are standard: cos, sin, zr and arctan(zr) (I noticed that zr is helpful also together with arctan).
\n\n\n\n\nThe formula to compute C is given in the documents from CERN but I estimated it from the train data via a linear regression. That's the only use of supervised learning I made
\n
I don't understand why you need this. Features doesn't involved this constant and you don't have px, py, pz in the test data.
\n\n\n\n\nUsing number of volumes is way more effective than using the number of hits in the track.
\n
Probably this gave you a good boost, right? I used the number of hits.
\n\n\n\n\nThe extra mileage I got comes for a simple idea: run another, similar model, on the inner volumes only (7, 8, and 9).
\n
I used this also in my solution. I constructed tracks inside r < 200 (you can also use cells there). Then I used DBSCAN for all hits but verifying tracks by \"the first half\" of tracks found earlier.
", "rawMarkdown": "I'm trying to understand how I can get a better score. You have many improvements, probably every step give you a boost. \nAnyway, Yuval said that's easy yo get 0.7 with right features. I tried his approach with the normal distribution but didn't get a better score. And my features are standard: cos, sin, zr and arctan(zr) (I noticed that zr is helpful also together with arctan).\n\n> The formula to compute C is given in the documents from CERN but I estimated it from the train data via a linear regression. That's the only use of supervised learning I made\n\nI don't understand why you need this. Features doesn't involved this constant and you don't have px, py, pz in the test data.\n\n> Using number of volumes is way more effective than using the number of hits in the track. \n\nProbably this gave you a good boost, right? I used the number of hits.\n\n> The extra mileage I got comes for a simple idea: run another, similar model, on the inner volumes only (7, 8, and 9). \n\nI used this also in my solution. I constructed tracks inside r < 200 (you can also use cells there). Then I used DBSCAN for all hits but verifying tracks by \"the first half\" of tracks found earlier.", "votes": 1, "replies": [ { "id": 371568, "postDate": "2018-08-17T06:11:21.517Z", "content": "\n\n\nI don't understand why you need this.
\n
You can do without. I use it when sampling. I sample pt and pz from the tracks in train data, compute r0 from pt instead of having to compute it from the hits in each track. It is faster.
\n\n\n\n\nProbably this gave you a good boost, right?
\n
Everything I documented gave me a boost ;) This one gave me at least 0.02 and probably more. I did not measure its effect separately because I first replaced the number of hits by the number of layers, got a boost, then replaced the number of layers by the number of volumes, and again got a boost.
", "rawMarkdown": "> I don't understand why you need this. \n\nYou can do without. I use it when sampling. I sample pt and pz from the tracks in train data, compute r0 from pt instead of having to compute it from the hits in each track. It is faster.\n\n> Probably this gave you a good boost, right? \n\nEverything I documented gave me a boost ;) This one gave me at least 0.02 and probably more. I did not measure its effect separately because I first replaced the number of hits by the number of layers, got a boost, then replaced the number of layers by the number of volumes, and again got a boost.", "votes": 1 }, { "id": 371575, "postDate": "2018-08-17T06:29:27.707Z", "content": "\n\n\ncompute r0 from pt instead of having to compute it from the hits in each track.
\n
Ah, I see.
\n\n\n\n\nMy code loops over z0, r0 pairs.
\n
Do you have fixed (z0, r0) pairs unlike Yuval's randomness? \nAnd you don't use StandardScaler, right? \nSorry, if your code is shared, I woudn't ask. :)
", "rawMarkdown": "> compute r0 from pt instead of having to compute it from the hits in each track. \n\nAh, I see.\n\n> My code loops over z0, r0 pairs.\n\nDo you have fixed (z0, r0) pairs unlike Yuval's randomness? \nAnd you don't use StandardScaler, right? \nSorry, if your code is shared, I woudn't ask. :)" }, { "id": 371651, "postDate": "2018-08-17T10:11:32.967Z", "content": "As I wrote:
\n\n\n\n\nMy code loops over z0, r0 pairs. Rather than estimating a distribution I just sample from the tracks in the first 100 train samples.
\n
I collected all the (z0, pt) pairs from the train events I'm considering, then turned these into (z0, r0) pairs via the use of the C constant above. Then I draw one pair randomly at each iteration of the main loop.
\n\n\nThe formula to compute C is given in the documents from CERN
\n
I think the formula is something like pt/(q*B). For some reason a particle charge 'q' have only +-1 values, so we can ignore them. Otherwise it would be proportional to pt/q.
\n\n\n\n\nbut I estimated it from the train data via a linear regression.
\n
I think there's something you're not saying. ;) We have no the truth 'r0' value. Do use a certain formula or an approximation?
", "rawMarkdown": "> The formula to compute C is given in the documents from CERN\n\nI think the formula is something like pt/(q*B). For some reason a particle charge 'q' have only +-1 values, so we can ignore them. Otherwise it would be proportional to pt/q.\n\n> but I estimated it from the train data via a linear regression. \n\nI think there's something you're not saying. ;) We have no the truth 'r0' value. Do use a certain formula or an approximation?\n" }, { "id": 373443, "postDate": "2018-08-21T11:31:10.090Z", "content": "Right, i did not explain how I compute r0 for enought tracks to be able to compute the C constant.
Your questions (and all questions on this topic) will make my final document better. Thanks for that!
\n\nI use the conformal representation that was described in one of the documents shared on the forum, with coordinates x/rt, y/rt where rt = sqrt(x^2 + y^2)
In that representation, circles going through the origin are straight lines. With little math I found that the distance of this line to the origin is alpha0 = 1/r0. That's how I found the radius of the helix.
There are many ways to compute the radius of a circle once you have 3 points on it (the origin, and 2 points on the track). I could have used another one, for instance: https://math.stackexchange.com/questions/133638/how-does-this-equation-to-find-the-radius-from-3-points-actually-work
\n\nAnother question you had I did not answered: I am not using standard scaler.
\n\nI will share my code before the deadline set by organizers, your quest will be over soon ;) Reason it takes time is that I am on vacation...
", "rawMarkdown": "Right, i did not explain how I compute r0 for enought tracks to be able to compute the `C` constant.\n\nYour questions (and all questions on this topic) will make my final document better. Thanks for that!\n\nI use the conformal representation that was described in one of the documents shared on the forum, with coordinates `x/rt, y/rt` where `rt = sqrt(x^2 + y^2)`\n\nIn that representation, circles going through the origin are straight lines. With little math I found that the distance of this line to the origin is `alpha0 = 1/r0`. That's how I found the radius of the helix.\n\nThere are many ways to compute the radius of a circle once you have 3 points on it (the origin, and 2 points on the track). I could have used another one, for instance: https://math.stackexchange.com/questions/133638/how-does-this-equation-to-find-the-radius-from-3-points-actually-work\n\nAnother question you had I did not answered: I am not using standard scaler.\n\nI will share my code before the deadline set by organizers, your quest will be over soon ;) Reason it takes time is that I am on vacation...", "votes": 1 }, { "id": 373464, "postDate": "2018-08-21T12:04:27.030Z", "content": "@CPMP Thanks for the answer! Now it's clear.
\n\nBy the way do you know why q is -1 or +1? The CERN document says
\n\n\n\n\nthe charge as multiple of the absolute electron charge
\n
It's strange to me we have no particles with a charge more than 1.
", "rawMarkdown": "@CPMP Thanks for the answer! Now it's clear.\n\nBy the way do you know why q is -1 or +1? The CERN document says\n\n> the charge as multiple of the absolute electron charge\n\nIt's strange to me we have no particles with a charge more than 1.", "votes": 1 }, { "id": 373492, "postDate": "2018-08-21T12:47:16.113Z", "content": "I don't know the physics here, better ask the organisers than me!
", "rawMarkdown": "I don't know the physics here, better ask the organisers than me!" }, { "id": 373721, "postDate": "2018-08-21T19:50:43.110Z", "content": "q=+1 or -1 : charged particles created in proton collision are mostly charged pions, charged kaons, electron, muons, protons (and their anti particles), which all have charge +/- 1. In the real collisions we might have very rarely alpha particles (or helium nucleus) of charge +2. In other apparatus, like a mass spectrometer, one can have very large positive charge.
", "rawMarkdown": "q=+1 or -1 : charged particles created in proton collision are mostly charged pions, charged kaons, electron, muons, protons (and their anti particles), which all have charge +/- 1. In the real collisions we might have very rarely alpha particles (or helium nucleus) of charge +2. In other apparatus, like a mass spectrometer, one can have very large positive charge. " }, { "id": 373733, "postDate": "2018-08-21T20:16:48.653Z", "content": "\n\n\nwhich all have charge +/- 1.
\n
Great! Thanks for the answer!
\nI think there are also particles with a zero charge. For example, kaons. We don't have it too.
\n\n\nIn the real collisions we might have very rarely alpha particles (or helium nucleus) of charge +2
\n
In the real collisions, but not in our simulations, right? Though I didn't check all events. :)
\n\nIt's funny I think about it only after the competition. :) That's because I didn't use ground truth initial values...
", "rawMarkdown": "> which all have charge +/- 1.\n\nGreat! Thanks for the answer! \nI think there are also particles with a zero charge. For example, kaons. We don't have it too. \n\n> In the real collisions we might have very rarely alpha particles (or helium nucleus) of charge +2\n\nIn the real collisions, but not in our simulations, right? Though I didn't check all events. :)\n\nIt's funny I think about it only after the competition. :) That's because I didn't use ground truth initial values...\n" } ] }, { "id": 371059, "postDate": "2018-08-15T21:57:19.007Z", "content": "@CPMP, I'm wondering about your plot of the angle differences due to the magnetic field. You write it is as a function of z, but is your z-axis rescaled? The axis seems to go only from -300 to +300. Did you convert to cm?
\n\nI'm interested because of the large peaks in the curve. Do they coincide with the first large caps closest to the large cylinders? I ask because I think I saw some anomalies exactly at (and only at) these first (innermost) large caps.
\n\nYou curve also has a peaked feature at the positive z-end, which matches with the strange features of the B field visible in my plots in the last (outermost) cap towards +z, I think.
", "rawMarkdown": "@CPMP, I'm wondering about your plot of the angle differences due to the magnetic field. You write it is as a function of z, but is your z-axis rescaled? The axis seems to go only from -300 to +300. Did you convert to cm?\n\nI'm interested because of the large peaks in the curve. Do they coincide with the first large caps closest to the large cylinders? I ask because I think I saw some anomalies exactly at (and only at) these first (innermost) large caps.\n\nYou curve also has a peaked feature at the positive z-end, which matches with the strange features of the B field visible in my plots in the last (outermost) cap towards +z, I think.", "votes": 1, "replies": [ { "id": 371231, "postDate": "2018-08-16T09:53:37.370Z", "content": "Yes, it was rescaled, I should have said it, sorry. Top one is rescaled by 1/10, bottom one by 1/50.
\n\nThe most striking finding for me is that the variation is not symmetric when you change z sign.
\n\nI was also wondering about the peaks, which is why I also plot the number of hits. The peaks correspond to values of z with a high number of hits. It is the valleys that are misleading actually. The second plot is obtained by scaling z further, and removing values of z with a small number of hits. I did not investigate further than that, because a small number of hits can be safely ignored for my purpose.
\n\nI will release an EDA notebook to show how I produced these plots and other ones I found useful during the competition.
\n\nI also looked at magnetic field variation as a function of phi, and found some variation, like you. But I did not model it. I guess its effect is way smaller than the variation by z.
", "rawMarkdown": "Yes, it was rescaled, I should have said it, sorry. Top one is rescaled by 1/10, bottom one by 1/50.\n\nThe most striking finding for me is that the variation is not symmetric when you change z sign.\n\nI was also wondering about the peaks, which is why I also plot the number of hits. The peaks correspond to values of z with a high number of hits. It is the valleys that are misleading actually. The second plot is obtained by scaling z further, and removing values of z with a small number of hits. I did not investigate further than that, because a small number of hits can be safely ignored for my purpose.\n\nI will release an EDA notebook to show how I produced these plots and other ones I found useful during the competition.\n\nI also looked at magnetic field variation as a function of phi, and found some variation, like you. But I did not model it. I guess its effect is way smaller than the variation by z. " } ] }, { "id": 370955, "postDate": "2018-08-15T18:13:18.433Z", "content": "Congratulations and many thanks to share your solutions :-) Not easy competition not only to understand it but mostly for the computational effort !!!
", "rawMarkdown": "Congratulations and many thanks to share your solutions :-) Not easy competition not only to understand it but mostly for the computational effort !!! ", "votes": 1 }, { "id": 370609, "postDate": "2018-08-15T06:12:19.960Z", "content": "congratulations! and thanks for sharing your approach
", "rawMarkdown": "congratulations! and thanks for sharing your approach", "votes": 1 }, { "id": 370472, "postDate": "2018-08-14T21:40:06.623Z", "content": "For zr, the math says use arctan to convert to a physically meaningful angle. How did you ever come up with the idea of using a scaled inverse hyperbolic sine?
", "rawMarkdown": "For zr, the math says use arctan to convert to a physically meaningful angle. How did you ever come up with the idea of using a scaled inverse hyperbolic sine?", "votes": 1, "replies": [ { "id": 370583, "postDate": "2018-08-15T04:24:02.740Z", "content": "I looked for functions that were similar to tan(), i.e. that had infinite limits in a closed interval. sinh() was the first function I looked at, and its distribution looked very similar to that of zr.
", "rawMarkdown": "I looked for functions that were similar to tan(), i.e. that had infinite limits in a closed interval. sinh() was the first function I looked at, and its distribution looked very similar to that of zr. " }, { "id": 371072, "postDate": "2018-08-15T23:15:38.377Z", "content": "@CPMP Thanks for sharing your result and congratulations to gold!
\n\nIf one converts zr using arctan, one gets the angle between pt and pz, but this angle is probably not of uniform distribution for the events in a particle collider.
In fact, I found something quite interesting:
\n\nhttps://en.m.wikipedia.org/wiki/Pseudorapidity
\n\nThere is a number in particle physics, called pseudorapidity, given by
\n\neta = -ln(tan(delta/2))\nwhere
\n\ntan(delta) = pt/pz = 1/zr\nThis can also be written as
\n\neta = arsinh(1/tan(delta)) = arsinh(zr)\nThe interesting thing is that according to the Wikipedia article (and papers that can be found via Google) in hadron colliders \"particle production is constant as a function of rapidity\" (approximately).
\n\nIt seems like you found exactly the right formula that makes zr uniformly distributed! (except for the factor 1/0.7 which I do not understand right now and could be related to particle masses, the factor 1/3.5 is probably not so important).
Wow, thanks for sharing. I'm impressed I discovered something that is linked to a known physics law. In a way it is reassuring that this is not just a computation artifact.
\n\nThe 0.7 factor makes the distribution even more uniform, but results without it were already quite good. I'll share plots with and without 0.7 scaling ASAP.
\n\nThe 3.5 factor is just to scale the result to the same scale as the other two features I am using for clustering.
", "rawMarkdown": "Wow, thanks for sharing. I'm impressed I discovered something that is linked to a known physics law. In a way it is reassuring that this is not just a computation artifact.\n\nThe 0.7 factor makes the distribution even more uniform, but results without it were already quite good. I'll share plots with and without 0.7 scaling ASAP.\n\nThe 3.5 factor is just to scale the result to the same scale as the other two features I am using for clustering. " }, { "id": 371240, "postDate": "2018-08-16T10:26:00.447Z", "content": "@Mark JD Hamilton great find and thanks for sharing.
", "rawMarkdown": "@Mark JD Hamilton great find and thanks for sharing." } ] }, { "id": 370335, "postDate": "2018-08-14T16:43:40.443Z", "content": "@CPMP, congratulations on reaching your goal of 0.80! I was rooting for you to make it in the final hours before the deadline.
\n\nYour solutions looks very elegant. Definitely one of the best score per codelines ratios, I guess.
\n\nYes, all the ensemble clustering approaches would have no chance against the combinatoric/geometric ones in the throughput phase. However, the features you developed and your track quality metric could be interesting to incorporate for track evaluation even in combinatoric solutions.
", "rawMarkdown": "@CPMP, congratulations on reaching your goal of 0.80! I was rooting for you to make it in the final hours before the deadline.\n\nYour solutions looks very elegant. Definitely one of the best score per codelines ratios, I guess.\n\nYes, all the ensemble clustering approaches would have no chance against the combinatoric/geometric ones in the throughput phase. However, the features you developed and your track quality metric could be interesting to incorporate for track evaluation even in combinatoric solutions.", "votes": 1, "replies": [ { "id": 370365, "postDate": "2018-08-14T17:35:45.077Z", "content": "Glad you find it interesting. And even happier if some of my work is reused in stage 2.
", "rawMarkdown": "Glad you find it interesting. And even happier if some of my work is reused in stage 2. ", "votes": 1 }, { "id": 370385, "postDate": "2018-08-14T18:15:27.007Z", "content": "And thanks for rooting for me!
", "rawMarkdown": "And thanks for rooting for me!", "votes": 1 } ] }, { "id": 370129, "postDate": "2018-08-14T10:24:29.003Z", "content": "Thank you for sharing! And special thank you for the post on paralleling, it gave me a great boost once I managed to do it (better late than never :))
", "rawMarkdown": "Thank you for sharing! And special thank you for the post on paralleling, it gave me a great boost once I managed to do it (better late than never :))", "votes": 1, "replies": [ { "id": 370130, "postDate": "2018-08-14T10:25:20.847Z", "content": "Glad what i shared helped you. I'll try to share earlier next time ;)
", "rawMarkdown": "Glad what i shared helped you. I'll try to share earlier next time ;)" } ] }, { "id": 370021, "postDate": "2018-08-14T05:21:35.613Z", "content": "Congratulations @CPMP on gaining another gold metal and thanks for sharing your solution.
", "rawMarkdown": "Congratulations @CPMP on gaining another gold metal and thanks for sharing your solution.", "votes": 1 }, { "id": 370953, "postDate": "2018-08-15T18:04:22.343Z", "content": "@CPMP in the formula:
\n\nzr = (z - z0) / (2 * r0 * phi0)
didn't you mean
\n\n zr = (z - z0) / (2 * r0 * theta0)\nGood catch, thanks!
", "rawMarkdown": "Good catch, thanks!", "votes": 2 }, { "id": 370958, "postDate": "2018-08-15T18:18:25.143Z", "content": "Just trying to plug your magnetic field fix to my solution to see what I'll get, but can't make it work, yet.
", "rawMarkdown": "Just trying to plug your magnetic field fix to my solution to see what I'll get, but can't make it work, yet.", "votes": 1 }, { "id": 370964, "postDate": "2018-08-15T18:30:41.613Z", "content": "I'll share my code soon, in case my writeup missed something relevant.
", "rawMarkdown": "I'll share my code soon, in case my writeup missed something relevant.", "votes": 1 }, { "id": 370967, "postDate": "2018-08-15T18:34:46.710Z", "content": "I remember now, you must use the theta0 correction only for computing phi0, but not for computing zr.
", "rawMarkdown": "I remember now, you must use the theta0 correction only for computing phi0, but not for computing zr. ", "votes": 1 }, { "id": 370983, "postDate": "2018-08-15T18:57:01.477Z", "content": "WoW. plugged it in. used a short run (as is in my kernel) expanded, and got LB 0.785! I wonder what I'll get with the long run (100K points) .
", "rawMarkdown": "WoW. plugged it in. used a short run (as is in my kernel) expanded, and got LB 0.785! I wonder what I'll get with the long run (100K points) .", "votes": 1 }, { "id": 370995, "postDate": "2018-08-15T19:23:42.183Z", "content": "I tried 2 parts last night... I used observed r0,z0 values from EDA as my random values & replaced arctan2 with arcsinh for zr. r0,z0 seemed to have an improvement between 0.005 - 0.01 ( more than I expected). Could not get arcsinh to yield any improvement...so maybe I'm doing something wrong. Didn't try the theta0 adjustment, but now I will 😀
", "rawMarkdown": "I tried 2 parts last night... I used observed r0,z0 values from EDA as my random values & replaced arctan2 with arcsinh for zr. r0,z0 seemed to have an improvement between 0.005 - 0.01 ( more than I expected). Could not get arcsinh to yield any improvement...so maybe I'm doing something wrong. Didn't try the theta0 adjustment, but now I will 😀", "votes": 1 }, { "id": 371020, "postDate": "2018-08-15T20:34:24.343Z", "content": "> WoW. plugged it in. used a short run (as is in my kernel) expanded, and got LB 0.785!
\n\nGreat!
\n\nThe downside is that track extension becomes less effective. In my case, my track extension, based on Heng's code, became totally useless. You're using a more elaborate way with a supervised ML approach. Maybe you can get some upside.
\n\nAnyway, it is good to know that this correction improves your code. You may bet better results than mine in a fraction of time.
", "rawMarkdown": "> WoW. plugged it in. used a short run (as is in my kernel) expanded, and got LB 0.785! \n\nGreat!\n\nThe downside is that track extension becomes less effective. In my case, my track extension, based on Heng's code, became totally useless. You're using a more elaborate way with a supervised ML approach. Maybe you can get some upside.\n\nAnyway, it is good to know that this correction improves your code. You may bet better results than mine in a fraction of time.\n\n", "votes": 1 }, { "id": 371030, "postDate": "2018-08-15T21:06:21.003Z", "content": "* correction **\"\nI had a bug in my code it is \"only\" 0.76 with the short run and 0.785 with the long one.\nStill a 0.02 improvement
", "rawMarkdown": "*** correction **\"\nI had a bug in my code it is \"only\" 0.76 with the short run and 0.785 with the long one.\nStill a 0.02 improvement ", "votes": 2 }, { "id": 371053, "postDate": "2018-08-15T21:46:50.967Z", "content": "\n\n\nStill a 0.02 improvement
\n
I think that is roughly consistent with my own experience. As mentioned, I got about +0.01 from accounting for the systematic deviations due to the inhomogenous B field. It makes sense that it helps more in your case because your approach is more sensitive to variations in the helix parameters along a track, but it's still the same (small) order of magnitude.
", "rawMarkdown": "> Still a 0.02 improvement\n\nI think that is roughly consistent with my own experience. As mentioned, I got about +0.01 from accounting for the systematic deviations due to the inhomogenous B field. It makes sense that it helps more in your case because your approach is more sensitive to variations in the helix parameters along a track, but it's still the same (small) order of magnitude.", "votes": 1 }, { "id": 371226, "postDate": "2018-08-16T09:23:36.627Z", "content": "Mine was improved by 0.03
\n\nNot sure why it was more effective for me.
", "rawMarkdown": "Mine was improved by 0.03\n\nNot sure why it was more effective for me.", "votes": 1 }, { "id": 371248, "postDate": "2018-08-16T10:42:24.647Z", "content": "\n\n\nMine was improved by 0.03
\n
Interesting. Either it's the different sensitivity of the algorithms to perturbations of the helices, or I missed something in my implementation of the corrections.
", "rawMarkdown": "> Mine was improved by 0.03\n\nInteresting. Either it's the different sensitivity of the algorithms to perturbations of the helices, or I missed something in my implementation of the corrections." } ] }, { "id": 375722, "postDate": "2018-08-25T21:47:58.057Z", "content": "@CPMP really good job. Well done. enter link description here
", "rawMarkdown": "@CPMP really good job. Well done. [enter link description here][1]\n\n\n [1]: https://twitter.com/trackmllhc/status/1033277891226820608", "votes": 1 }, { "id": 370330, "postDate": "2018-08-14T16:29:00.220Z", "content": "Merci d'avoir partagé cela avec nous.
", "rawMarkdown": "Merci d'avoir partagé cela avec nous. ", "votes": 1 }, { "id": 374889, "postDate": "2018-08-24T04:49:07.260Z", "content": "Any participant (not necessarily with the highest score) who think they made valuable contributions with innovative algorithms (in particular if they have shared insights on the forum) are welcome to release publicly their code with an open source license and lightweight structured documentation. This will allow to compete for the « HEP meets ML » jury prizes: a NVidia V100 GPU, and two invitations to NIPS 2018 or the spring 2019 CERN workshop.See details in forum topic:
\n\nhttps://www.kaggle.com/c/trackml-particle-identification/discussion/63289
", "rawMarkdown": "Any participant (not necessarily with the highest score) who think they made valuable contributions with innovative algorithms (in particular if they have shared insights on the forum) are welcome to release publicly their code with an open source license and lightweight structured documentation. This will allow to compete for the « HEP meets ML » jury prizes: a NVidia V100 GPU, and two invitations to NIPS 2018 or the spring 2019 CERN workshop.See details in forum topic:\n\nhttps://www.kaggle.com/c/trackml-particle-identification/discussion/63289", "replies": [ { "id": 375008, "postDate": "2018-08-24T11:14:21.487Z", "content": "I'll submit, I have started publishing my code. But I try to enjoy the end of my vacation as well ;), hence I will submit Monday probably.
", "rawMarkdown": "I'll submit, I have started publishing my code. But I try to enjoy the end of my vacation as well ;), hence I will submit Monday probably." } ] }, { "id": 371307, "postDate": "2018-08-16T13:57:25.937Z", "content": "Following up on the excellent find by Mark JD Hamilton, here is a plot of arcsinh(zr). While quite uniform, it is not as uniform as the scaled version I used.
![\"arcsinh\"](\"https://storage.googleapis.com/kaggle-forum-message-attachments/371307/10098/asinh2.png\")
Thanks for the diagram!
\n\nI did a bit more research (which needs to be taken with a caveat, since I am not a particle physicist): There is another number, called rapidity, given by
\n\ny = artanh(beta*cos(delta))\nwhere
\n\nbeta = p/E\np = sqrt(pt^2+pz^2)\nE = sqrt(p^2+m^2)\ntan(delta) = pt/pz = 1/zr\nwith particle mass m. It is related to the pseudorapidity
eta = arsinh(1/tan(delta)) = arsinh(zr)\nby
\n\ny = arsinh(zr/k)\nwith
\n\nk = sqrt(1+m^2/pt^2)\nIf pt>>m, then y-->eta.
From the references I have seen like
\n\nhttps://www.physics.umd.edu/hep/drew/Baden_jets_kinematics_dec_2008.pdf (p. 12)
\n\n\n\nit seems the particle creation is really constant in the rapidity y, not the pseudorapidity eta.
This means that there is a rescaling involved, like in your case, but the following is a bit strange: in the formula for y above the number k is always >=1, but in your case it is 0.7<1. In addition, one expects the distribution for eta = arsinh(zr) to have a dip around eta = 0, like in the diagram on page 20 of the first reference, not a hill like in your case.
I don't understand this at the moment, perhaps there is a mistake in the conversions above. I will think about it.
", "rawMarkdown": "Thanks for the diagram!\n\nI did a bit more research (which needs to be taken with a caveat, since I am not a particle physicist): There is another number, called rapidity, given by\n\n y = artanh(beta*cos(delta))\n\nwhere \n\n beta = p/E\n p = sqrt(pt^2+pz^2)\n E = sqrt(p^2+m^2)\n tan(delta) = pt/pz = 1/zr\n\nwith particle mass `m`. It is related to the pseudorapidity\n\n eta = arsinh(1/tan(delta)) = arsinh(zr)\n\nby\n\n y = arsinh(zr/k)\n\nwith\n\n k = sqrt(1+m^2/pt^2)\n\nIf `pt>>m`, then `y-->eta`.\n\nFrom the references I have seen like \n\nhttps://www.physics.umd.edu/hep/drew/Baden_jets_kinematics_dec_2008.pdf (p. 12)\n\nhttps://warwick.ac.uk/fac/sci/physics/staff/academic/gershon/gradteaching/warwickweek/material/lhcphysics/chill_warwick_lhc_2010_1.pdf (p.27)\n\nit seems the particle creation is really constant in the rapidity `y`, not the pseudorapidity `eta`.\n\nThis means that there is a rescaling involved, like in your case, but the following is a bit strange: in the formula for `y` above the number `k` is always `>=1`, but in your case it is `0.7<1`. In addition, one expects the distribution for `eta = arsinh(zr)` to have a dip around `eta = 0`, like in the diagram on page 20 of the first reference, not a hill like in your case.\n\nI don't understand this at the moment, perhaps there is a mistake in the conversions above. I will think about it.\n\n\n", "votes": 1 }, { "id": 371406, "postDate": "2018-08-16T18:31:20.903Z", "content": "Mark,
\n\nbear in mind that we are dealing with simulated data. Maybe you just uncovered a discrepancy between the simulator and reality?
", "rawMarkdown": "Mark,\n\nbear in mind that we are dealing with simulated data. Maybe you just uncovered a discrepancy between the simulator and reality?" }, { "id": 371418, "postDate": "2018-08-16T19:07:50.777Z", "content": "Yes, I know, the data is simulated.
\n\nWhether we found a discrepancy with reality - let's see. I started reading about rapidities yesterday and the formulas with sinh etc. can be error prone... I need to check the formulas and the literature again.
But I think your formula with arsinh(zr) is not an coincidence, there should be something behind it.
By the way: If N is the number of particles, the distributions are related by
dN/deta = dN/dy * cosh(eta)/sqrt(m^2/pt^2 + cosh^2(eta))\nIf we assume that dN/dyis constant, then the function dN/deta is determined by the second factor, which is <1 for eta = 0 and goes to 1 for |eta| large. That is the dip one should see in the diagram for arsinh(zr).
Are you referring to the dip in the plot page 20 of the first reference ? Be careful that this is not a distribution. It only shows the curves of beta vs eta for different Pt for a pion, m=0.140gev.
\n\nIn most cases we are using the pseudo rapidity eta which is indeed flatish, but which can be sculpted by many effects. Honestly, we did not think it could be of any use for track finding, and it takes time to get used to this strange variable.
", "rawMarkdown": "Are you referring to the dip in the plot page 20 of the first reference ? Be careful that this is not a distribution. It only shows the curves of beta vs eta for different Pt for a pion, m=0.140gev. \n\nIn most cases we are using the pseudo rapidity eta which is indeed flatish, but which can be sculpted by many effects. Honestly, we did not think it could be of any use for track finding, and it takes time to get used to this strange variable. ", "votes": 1 }, { "id": 371476, "postDate": "2018-08-16T22:07:39.550Z", "content": "@ David Rousseau Thanks for your message!
\n\nYes, if I understand it correctly, the function beta(eta) = dy/detais called the Jacobian in some references, because it relates the rapidity distribution dN/dy and pseudorapidity distribution dN/deta.
I honestly just tried to make sense out of the curious fact (not primarily regarding track finding) that CPMP's formula
\n\narsinh(zr / 0.7) / 3.5\nled to a uniform distribution and some Google search showed it could be related to (pseudo-)rapidity.
\n\nBut I notice I am walking on shaky ground here!
", "rawMarkdown": "@ David Rousseau Thanks for your message!\n\nYes, if I understand it correctly, the function `beta(eta) = dy/deta`is called the Jacobian in some references, because it relates the rapidity distribution `dN/dy` and pseudorapidity distribution `dN/deta`.\n\nI honestly just tried to make sense out of the curious fact (not primarily regarding track finding) that CPMP's formula\n\n arsinh(zr / 0.7) / 3.5\n\nled to a uniform distribution and some Google search showed it could be related to (pseudo-)rapidity.\n\nBut I notice I am walking on shaky ground here!" }, { "id": 374220, "postDate": "2018-08-22T16:16:15.343Z", "content": "@Mark, I found that when I restrict the data to be the hits of tracks originating from the z axis, then non scaled arcsinh is best. It means my code can be improved by removing the scaling probably...
", "rawMarkdown": "@Mark, I found that when I restrict the data to be the hits of tracks originating from the z axis, then non scaled arcsinh is best. It means my code can be improved by removing the scaling probably..." }, { "id": 374243, "postDate": "2018-08-22T16:52:30.057Z", "content": "@CPMP, thanks, that's interesting.
", "rawMarkdown": "@CPMP, thanks, that's interesting." }, { "id": 374580, "postDate": "2018-08-23T10:22:43.883Z", "content": "What is funny is that with unscaled arcsinh my local score climbs faster, but plateaus earlier. Maybe I need to tune the value of eps for DBSCAN again, but I won't ;) Just to say that this is not a clear win.
", "rawMarkdown": "What is funny is that with unscaled arcsinh my local score climbs faster, but plateaus earlier. Maybe I need to tune the value of eps for DBSCAN again, but I won't ;) Just to say that this is not a clear win." } ] }, { "id": 370661, "postDate": "2018-08-15T08:28:14.233Z", "content": "By the way almost everyone used
\n\nphi = arctan(y/x)\nIt's not quite right, since (x, y) and (-x, -y) give the same angle, but they should differ by Pi. I used
\n\ndef calc_phi(hits_row):\nif hits_row['y'] >= 0:\n return math.acos(hits_row['x'] / hits_row['r2'])\nelse:\n return 2 * math.pi - math.acos(hits_row['x'] / hits_row['r2'])\nFor some reason it seems doesn't matter for a score.
", "rawMarkdown": "By the way almost everyone used \n\n phi = arctan(y/x)\n\nIt's not quite right, since (x, y) and (-x, -y) give the same angle, but they should differ by Pi. I used\n\n def calc_phi(hits_row):\n if hits_row['y'] >= 0:\n return math.acos(hits_row['x'] / hits_row['r2'])\n else:\n return 2 * math.pi - math.acos(hits_row['x'] / hits_row['r2'])\n\nFor some reason it seems doesn't matter for a score.", "replies": [ { "id": 370666, "postDate": "2018-08-15T08:54:23.220Z", "content": "arctan2(y,x) in most libraries including np does the job
", "rawMarkdown": "arctan2(y,x) in most libraries including np does the job", "votes": 2 }, { "id": 370670, "postDate": "2018-08-15T09:04:06.723Z", "content": "@David Rousseau\nThanks, I didn't know that arctan2 can do that. I had to check the documentation for this function.
", "rawMarkdown": "@David Rousseau\nThanks, I didn't know that arctan2 can do that. I had to check the documentation for this function." }, { "id": 370725, "postDate": "2018-08-15T10:57:48.767Z", "content": "@Sergey Zlobin, I was doing the same thing as you earlier until I saw np.arctan2(y,x) used in one of the kernels, I checked it out and discovered it works.
", "rawMarkdown": "@Sergey Zlobin, I was doing the same thing as you earlier until I saw np.arctan2(y,x) used in one of the kernels, I checked it out and discovered it works.", "votes": 1 } ] }, { "id": 371940, "postDate": "2018-08-17T21:32:53.583Z", "rawMarkdown": "", "isDeleted": true }, { "id": 370422, "postDate": "2018-08-14T19:52:40.967Z", "rawMarkdown": "", "votes": 1, "isDeleted": true } ], "comments": [ { "id": 370324, "author_name": "bestfitting", "author_url": "", "post_date": "2018-08-14T16:09:56.577000", "content": "Thanks for you sharing,My solution is also based on DBScan and I also have no time to finish:\"Use direction information from cells data and Extend to tracks that do not pass near z axis\",but I fitted helix to extend the tracks.I also used the tips from Heng to find candicate hits and desinged a LGBM model to classify the candidates.
", "votes": 4, "replies": [ { "id": 370361, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-14T17:33:31.113000", "content": "Yes, track extension was definitely a miss for me. Congrats on your result, even if you passed me at the last minute ;)
", "votes": 0, "replies": [] } ] }, { "id": 376482, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-27T15:45:48.820000", "content": "Final code and documentation is available on github: https://github.com/jfpuget/Kaggle_TrackML
\n\nI found why my local score was higher than the LB: I forgot to use the magnetic field correction in one model... Once fixed local score and LB score become much closer, with a difference smaller than 0.001. I document and share code for the fixed models.
", "votes": 1, "replies": [] }, { "id": 375535, "author_name": "hengck23", "author_url": "", "post_date": "2018-08-25T11:47:44.500000", "content": "@CPMP
\n\nThanks for the solution. It is a nice piece of work!
", "votes": 1, "replies": [ { "id": 375611, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-25T15:59:31.750000", "content": "Thanks you Heng!
\n\nYour remark about supervised learning being mandatory for reaching 0.8 has been a driver for me!
\n\nIt is a pity you did not had time to submit a good solution at the end. I was surprised, as many of us, to not see you above 0.8 at the end.
", "votes": 0, "replies": [] }, { "id": 375637, "author_name": "hengck23", "author_url": "", "post_date": "2018-08-25T17:17:48.230000", "content": "i have some urgent project at work the last minute. I will be continuing this in the speed phase if time permits. Right now, i am at the TGS salt identification competition, do come and take a look!
", "votes": 1, "replies": [] }, { "id": 375656, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-25T17:59:06.563000", "content": "I am considering TGS or Airbus as my next ones ;)
", "votes": 1, "replies": [] } ] }, { "id": 374054, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-22T11:13:16.807000", "content": "I have put some code on github
\n\nThis is work in progress, the repo should be final by Monday.
\n\nThe code computes something that should give a LB above 0.78. I'm running it as of now to see what score exactly this yields.
\n\nCleaning my code revealed few little glitches that explain why my LB score was below my local score. I hope the code on github fixes that.
", "votes": 1, "replies": [ { "id": 374326, "author_name": "YaGana Sheriff-Hussaini", "author_url": "", "post_date": "2018-08-22T20:29:13.680000", "content": "@CPMP thanks so much for sharing.
", "votes": 1, "replies": [] } ] }, { "id": 372564, "author_name": "Siddharth Yadav", "author_url": "", "post_date": "2018-08-19T18:01:32.607000", "content": "Congratulations, CPMP! I always learn great things from your posts.
", "votes": 1, "replies": [] }, { "id": 371557, "author_name": "Sergey Zlobin", "author_url": "", "post_date": "2018-08-17T05:10:42.380000", "content": "I'm trying to understand how I can get a better score. You have many improvements, probably every step give you a boost. \nAnyway, Yuval said that's easy yo get 0.7 with right features. I tried his approach with the normal distribution but didn't get a better score. And my features are standard: cos, sin, zr and arctan(zr) (I noticed that zr is helpful also together with arctan).
\n\n\n\n\nThe formula to compute C is given in the documents from CERN but I estimated it from the train data via a linear regression. That's the only use of supervised learning I made
\n
I don't understand why you need this. Features doesn't involved this constant and you don't have px, py, pz in the test data.
\n\n\n\n\nUsing number of volumes is way more effective than using the number of hits in the track.
\n
Probably this gave you a good boost, right? I used the number of hits.
\n\n\n\n\nThe extra mileage I got comes for a simple idea: run another, similar model, on the inner volumes only (7, 8, and 9).
\n
I used this also in my solution. I constructed tracks inside r < 200 (you can also use cells there). Then I used DBSCAN for all hits but verifying tracks by \"the first half\" of tracks found earlier.
", "votes": 1, "replies": [ { "id": 371568, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-17T06:11:21.517000", "content": "\n\n\nI don't understand why you need this.
\n
You can do without. I use it when sampling. I sample pt and pz from the tracks in train data, compute r0 from pt instead of having to compute it from the hits in each track. It is faster.
\n\n\n\n\nProbably this gave you a good boost, right?
\n
Everything I documented gave me a boost ;) This one gave me at least 0.02 and probably more. I did not measure its effect separately because I first replaced the number of hits by the number of layers, got a boost, then replaced the number of layers by the number of volumes, and again got a boost.
", "votes": 1, "replies": [] }, { "id": 371575, "author_name": "Sergey Zlobin", "author_url": "", "post_date": "2018-08-17T06:29:27.707000", "content": "\n\n\ncompute r0 from pt instead of having to compute it from the hits in each track.
\n
Ah, I see.
\n\n\n\n\nMy code loops over z0, r0 pairs.
\n
Do you have fixed (z0, r0) pairs unlike Yuval's randomness? \nAnd you don't use StandardScaler, right? \nSorry, if your code is shared, I woudn't ask. :)
", "votes": 0, "replies": [] }, { "id": 371651, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-17T10:11:32.967000", "content": "As I wrote:
\n\n\n\n\nMy code loops over z0, r0 pairs. Rather than estimating a distribution I just sample from the tracks in the first 100 train samples.
\n
I collected all the (z0, pt) pairs from the train events I'm considering, then turned these into (z0, r0) pairs via the use of the C constant above. Then I draw one pair randomly at each iteration of the main loop.
\n\n\nThe formula to compute C is given in the documents from CERN
\n
I think the formula is something like pt/(q*B). For some reason a particle charge 'q' have only +-1 values, so we can ignore them. Otherwise it would be proportional to pt/q.
\n\n\n\n\nbut I estimated it from the train data via a linear regression.
\n
I think there's something you're not saying. ;) We have no the truth 'r0' value. Do use a certain formula or an approximation?
", "votes": 0, "replies": [] }, { "id": 373443, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-21T11:31:10.090000", "content": "Right, i did not explain how I compute r0 for enought tracks to be able to compute the C constant.
Your questions (and all questions on this topic) will make my final document better. Thanks for that!
\n\nI use the conformal representation that was described in one of the documents shared on the forum, with coordinates x/rt, y/rt where rt = sqrt(x^2 + y^2)
In that representation, circles going through the origin are straight lines. With little math I found that the distance of this line to the origin is alpha0 = 1/r0. That's how I found the radius of the helix.
There are many ways to compute the radius of a circle once you have 3 points on it (the origin, and 2 points on the track). I could have used another one, for instance: https://math.stackexchange.com/questions/133638/how-does-this-equation-to-find-the-radius-from-3-points-actually-work
\n\nAnother question you had I did not answered: I am not using standard scaler.
\n\nI will share my code before the deadline set by organizers, your quest will be over soon ;) Reason it takes time is that I am on vacation...
", "votes": 1, "replies": [] }, { "id": 373464, "author_name": "Sergey Zlobin", "author_url": "", "post_date": "2018-08-21T12:04:27.030000", "content": "@CPMP Thanks for the answer! Now it's clear.
\n\nBy the way do you know why q is -1 or +1? The CERN document says
\n\n\n\n\nthe charge as multiple of the absolute electron charge
\n
It's strange to me we have no particles with a charge more than 1.
", "votes": 1, "replies": [] }, { "id": 373492, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-21T12:47:16.113000", "content": "I don't know the physics here, better ask the organisers than me!
", "votes": 0, "replies": [] }, { "id": 373721, "author_name": "David Rousseau", "author_url": "", "post_date": "2018-08-21T19:50:43.110000", "content": "q=+1 or -1 : charged particles created in proton collision are mostly charged pions, charged kaons, electron, muons, protons (and their anti particles), which all have charge +/- 1. In the real collisions we might have very rarely alpha particles (or helium nucleus) of charge +2. In other apparatus, like a mass spectrometer, one can have very large positive charge.
", "votes": 0, "replies": [] }, { "id": 373733, "author_name": "Sergey Zlobin", "author_url": "", "post_date": "2018-08-21T20:16:48.653000", "content": "\n\n\nwhich all have charge +/- 1.
\n
Great! Thanks for the answer!
\nI think there are also particles with a zero charge. For example, kaons. We don't have it too.
\n\n\nIn the real collisions we might have very rarely alpha particles (or helium nucleus) of charge +2
\n
In the real collisions, but not in our simulations, right? Though I didn't check all events. :)
\n\nIt's funny I think about it only after the competition. :) That's because I didn't use ground truth initial values...
", "votes": 0, "replies": [] } ] }, { "id": 371059, "author_name": "Edwin Steiner", "author_url": "", "post_date": "2018-08-15T21:57:19.007000", "content": "@CPMP, I'm wondering about your plot of the angle differences due to the magnetic field. You write it is as a function of z, but is your z-axis rescaled? The axis seems to go only from -300 to +300. Did you convert to cm?
\n\nI'm interested because of the large peaks in the curve. Do they coincide with the first large caps closest to the large cylinders? I ask because I think I saw some anomalies exactly at (and only at) these first (innermost) large caps.
\n\nYou curve also has a peaked feature at the positive z-end, which matches with the strange features of the B field visible in my plots in the last (outermost) cap towards +z, I think.
", "votes": 1, "replies": [ { "id": 371231, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-16T09:53:37.370000", "content": "Yes, it was rescaled, I should have said it, sorry. Top one is rescaled by 1/10, bottom one by 1/50.
\n\nThe most striking finding for me is that the variation is not symmetric when you change z sign.
\n\nI was also wondering about the peaks, which is why I also plot the number of hits. The peaks correspond to values of z with a high number of hits. It is the valleys that are misleading actually. The second plot is obtained by scaling z further, and removing values of z with a small number of hits. I did not investigate further than that, because a small number of hits can be safely ignored for my purpose.
\n\nI will release an EDA notebook to show how I produced these plots and other ones I found useful during the competition.
\n\nI also looked at magnetic field variation as a function of phi, and found some variation, like you. But I did not model it. I guess its effect is way smaller than the variation by z.
", "votes": 0, "replies": [] } ] }, { "id": 370955, "author_name": "Kenshiro75", "author_url": "", "post_date": "2018-08-15T18:13:18.433000", "content": "Congratulations and many thanks to share your solutions :-) Not easy competition not only to understand it but mostly for the computational effort !!!
", "votes": 1, "replies": [] }, { "id": 370609, "author_name": "Alexandra Yakunina", "author_url": "", "post_date": "2018-08-15T06:12:19.960000", "content": "congratulations! and thanks for sharing your approach
", "votes": 1, "replies": [] }, { "id": 370472, "author_name": "John Sweeney", "author_url": "", "post_date": "2018-08-14T21:40:06.623000", "content": "For zr, the math says use arctan to convert to a physically meaningful angle. How did you ever come up with the idea of using a scaled inverse hyperbolic sine?
", "votes": 1, "replies": [ { "id": 370583, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-15T04:24:02.740000", "content": "I looked for functions that were similar to tan(), i.e. that had infinite limits in a closed interval. sinh() was the first function I looked at, and its distribution looked very similar to that of zr.
", "votes": 0, "replies": [] }, { "id": 371072, "author_name": "Mark JD Hamilton", "author_url": "", "post_date": "2018-08-15T23:15:38.377000", "content": "@CPMP Thanks for sharing your result and congratulations to gold!
\n\nIf one converts zr using arctan, one gets the angle between pt and pz, but this angle is probably not of uniform distribution for the events in a particle collider.
In fact, I found something quite interesting:
\n\nhttps://en.m.wikipedia.org/wiki/Pseudorapidity
\n\nThere is a number in particle physics, called pseudorapidity, given by
\n\neta = -ln(tan(delta/2))\nwhere
\n\ntan(delta) = pt/pz = 1/zr\nThis can also be written as
\n\neta = arsinh(1/tan(delta)) = arsinh(zr)\nThe interesting thing is that according to the Wikipedia article (and papers that can be found via Google) in hadron colliders \"particle production is constant as a function of rapidity\" (approximately).
\n\nIt seems like you found exactly the right formula that makes zr uniformly distributed! (except for the factor 1/0.7 which I do not understand right now and could be related to particle masses, the factor 1/3.5 is probably not so important).
Wow, thanks for sharing. I'm impressed I discovered something that is linked to a known physics law. In a way it is reassuring that this is not just a computation artifact.
\n\nThe 0.7 factor makes the distribution even more uniform, but results without it were already quite good. I'll share plots with and without 0.7 scaling ASAP.
\n\nThe 3.5 factor is just to scale the result to the same scale as the other two features I am using for clustering.
", "votes": 0, "replies": [] }, { "id": 371240, "author_name": "YaGana Sheriff-Hussaini", "author_url": "", "post_date": "2018-08-16T10:26:00.447000", "content": "@Mark JD Hamilton great find and thanks for sharing.
", "votes": 0, "replies": [] } ] }, { "id": 370335, "author_name": "Edwin Steiner", "author_url": "", "post_date": "2018-08-14T16:43:40.443000", "content": "@CPMP, congratulations on reaching your goal of 0.80! I was rooting for you to make it in the final hours before the deadline.
\n\nYour solutions looks very elegant. Definitely one of the best score per codelines ratios, I guess.
\n\nYes, all the ensemble clustering approaches would have no chance against the combinatoric/geometric ones in the throughput phase. However, the features you developed and your track quality metric could be interesting to incorporate for track evaluation even in combinatoric solutions.
", "votes": 1, "replies": [ { "id": 370365, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-14T17:35:45.077000", "content": "Glad you find it interesting. And even happier if some of my work is reused in stage 2.
", "votes": 1, "replies": [] }, { "id": 370385, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-14T18:15:27.007000", "content": "And thanks for rooting for me!
", "votes": 1, "replies": [] } ] }, { "id": 370129, "author_name": "Blonde", "author_url": "", "post_date": "2018-08-14T10:24:29.003000", "content": "Thank you for sharing! And special thank you for the post on paralleling, it gave me a great boost once I managed to do it (better late than never :))
", "votes": 1, "replies": [ { "id": 370130, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-14T10:25:20.847000", "content": "Glad what i shared helped you. I'll try to share earlier next time ;)
", "votes": 0, "replies": [] } ] }, { "id": 370021, "author_name": "YaGana Sheriff-Hussaini", "author_url": "", "post_date": "2018-08-14T05:21:35.613000", "content": "Congratulations @CPMP on gaining another gold metal and thanks for sharing your solution.
", "votes": 1, "replies": [] }, { "id": 370953, "author_name": "yuval reina", "author_url": "", "post_date": "2018-08-15T18:04:22.343000", "content": "@CPMP in the formula:
\n\nzr = (z - z0) / (2 * r0 * phi0)
didn't you mean
\n\n zr = (z - z0) / (2 * r0 * theta0)\nGood catch, thanks!
", "votes": 2, "replies": [] }, { "id": 370958, "author_name": "yuval reina", "author_url": "", "post_date": "2018-08-15T18:18:25.143000", "content": "Just trying to plug your magnetic field fix to my solution to see what I'll get, but can't make it work, yet.
", "votes": 1, "replies": [] }, { "id": 370964, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-15T18:30:41.613000", "content": "I'll share my code soon, in case my writeup missed something relevant.
", "votes": 1, "replies": [] }, { "id": 370967, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-15T18:34:46.710000", "content": "I remember now, you must use the theta0 correction only for computing phi0, but not for computing zr.
", "votes": 1, "replies": [] }, { "id": 370983, "author_name": "yuval reina", "author_url": "", "post_date": "2018-08-15T18:57:01.477000", "content": "WoW. plugged it in. used a short run (as is in my kernel) expanded, and got LB 0.785! I wonder what I'll get with the long run (100K points) .
", "votes": 1, "replies": [] }, { "id": 370995, "author_name": "John Sweeney", "author_url": "", "post_date": "2018-08-15T19:23:42.183000", "content": "I tried 2 parts last night... I used observed r0,z0 values from EDA as my random values & replaced arctan2 with arcsinh for zr. r0,z0 seemed to have an improvement between 0.005 - 0.01 ( more than I expected). Could not get arcsinh to yield any improvement...so maybe I'm doing something wrong. Didn't try the theta0 adjustment, but now I will 😀
", "votes": 1, "replies": [] }, { "id": 371020, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-15T20:34:24.343000", "content": "> WoW. plugged it in. used a short run (as is in my kernel) expanded, and got LB 0.785!
\n\nGreat!
\n\nThe downside is that track extension becomes less effective. In my case, my track extension, based on Heng's code, became totally useless. You're using a more elaborate way with a supervised ML approach. Maybe you can get some upside.
\n\nAnyway, it is good to know that this correction improves your code. You may bet better results than mine in a fraction of time.
", "votes": 1, "replies": [] }, { "id": 371030, "author_name": "yuval reina", "author_url": "", "post_date": "2018-08-15T21:06:21.003000", "content": "* correction **\"\nI had a bug in my code it is \"only\" 0.76 with the short run and 0.785 with the long one.\nStill a 0.02 improvement
", "votes": 2, "replies": [] }, { "id": 371053, "author_name": "Edwin Steiner", "author_url": "", "post_date": "2018-08-15T21:46:50.967000", "content": "\n\n\nStill a 0.02 improvement
\n
I think that is roughly consistent with my own experience. As mentioned, I got about +0.01 from accounting for the systematic deviations due to the inhomogenous B field. It makes sense that it helps more in your case because your approach is more sensitive to variations in the helix parameters along a track, but it's still the same (small) order of magnitude.
", "votes": 1, "replies": [] }, { "id": 371226, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-16T09:23:36.627000", "content": "Mine was improved by 0.03
\n\nNot sure why it was more effective for me.
", "votes": 1, "replies": [] }, { "id": 371248, "author_name": "Edwin Steiner", "author_url": "", "post_date": "2018-08-16T10:42:24.647000", "content": "\n\n\nMine was improved by 0.03
\n
Interesting. Either it's the different sensitivity of the algorithms to perturbations of the helices, or I missed something in my implementation of the corrections.
", "votes": 0, "replies": [] } ] }, { "id": 375722, "author_name": "Mukharbek Organokov", "author_url": "", "post_date": "2018-08-25T21:47:58.057000", "content": "@CPMP really good job. Well done. enter link description here
", "votes": 1, "replies": [] }, { "id": 370330, "author_name": "Mukharbek Organokov", "author_url": "", "post_date": "2018-08-14T16:29:00.220000", "content": "Merci d'avoir partagé cela avec nous.
", "votes": 1, "replies": [] }, { "id": 374889, "author_name": "JR", "author_url": "", "post_date": "2018-08-24T04:49:07.260000", "content": "Any participant (not necessarily with the highest score) who think they made valuable contributions with innovative algorithms (in particular if they have shared insights on the forum) are welcome to release publicly their code with an open source license and lightweight structured documentation. This will allow to compete for the « HEP meets ML » jury prizes: a NVidia V100 GPU, and two invitations to NIPS 2018 or the spring 2019 CERN workshop.See details in forum topic:
\n\nhttps://www.kaggle.com/c/trackml-particle-identification/discussion/63289
", "votes": 0, "replies": [ { "id": 375008, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-24T11:14:21.487000", "content": "I'll submit, I have started publishing my code. But I try to enjoy the end of my vacation as well ;), hence I will submit Monday probably.
", "votes": 0, "replies": [] } ] }, { "id": 371307, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-16T13:57:25.937000", "content": "Following up on the excellent find by Mark JD Hamilton, here is a plot of arcsinh(zr). While quite uniform, it is not as uniform as the scaled version I used.
Thanks for the diagram!
\n\nI did a bit more research (which needs to be taken with a caveat, since I am not a particle physicist): There is another number, called rapidity, given by
\n\ny = artanh(beta*cos(delta))\nwhere
\n\nbeta = p/E\np = sqrt(pt^2+pz^2)\nE = sqrt(p^2+m^2)\ntan(delta) = pt/pz = 1/zr\nwith particle mass m. It is related to the pseudorapidity
eta = arsinh(1/tan(delta)) = arsinh(zr)\nby
\n\ny = arsinh(zr/k)\nwith
\n\nk = sqrt(1+m^2/pt^2)\nIf pt>>m, then y-->eta.
From the references I have seen like
\n\nhttps://www.physics.umd.edu/hep/drew/Baden_jets_kinematics_dec_2008.pdf (p. 12)
\n\n\n\nit seems the particle creation is really constant in the rapidity y, not the pseudorapidity eta.
This means that there is a rescaling involved, like in your case, but the following is a bit strange: in the formula for y above the number k is always >=1, but in your case it is 0.7<1. In addition, one expects the distribution for eta = arsinh(zr) to have a dip around eta = 0, like in the diagram on page 20 of the first reference, not a hill like in your case.
I don't understand this at the moment, perhaps there is a mistake in the conversions above. I will think about it.
", "votes": 1, "replies": [] }, { "id": 371406, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-16T18:31:20.903000", "content": "Mark,
\n\nbear in mind that we are dealing with simulated data. Maybe you just uncovered a discrepancy between the simulator and reality?
", "votes": 0, "replies": [] }, { "id": 371418, "author_name": "Mark JD Hamilton", "author_url": "", "post_date": "2018-08-16T19:07:50.777000", "content": "Yes, I know, the data is simulated.
\n\nWhether we found a discrepancy with reality - let's see. I started reading about rapidities yesterday and the formulas with sinh etc. can be error prone... I need to check the formulas and the literature again.
But I think your formula with arsinh(zr) is not an coincidence, there should be something behind it.
By the way: If N is the number of particles, the distributions are related by
dN/deta = dN/dy * cosh(eta)/sqrt(m^2/pt^2 + cosh^2(eta))\nIf we assume that dN/dyis constant, then the function dN/deta is determined by the second factor, which is <1 for eta = 0 and goes to 1 for |eta| large. That is the dip one should see in the diagram for arsinh(zr).
Are you referring to the dip in the plot page 20 of the first reference ? Be careful that this is not a distribution. It only shows the curves of beta vs eta for different Pt for a pion, m=0.140gev.
\n\nIn most cases we are using the pseudo rapidity eta which is indeed flatish, but which can be sculpted by many effects. Honestly, we did not think it could be of any use for track finding, and it takes time to get used to this strange variable.
", "votes": 1, "replies": [] }, { "id": 371476, "author_name": "Mark JD Hamilton", "author_url": "", "post_date": "2018-08-16T22:07:39.550000", "content": "@ David Rousseau Thanks for your message!
\n\nYes, if I understand it correctly, the function beta(eta) = dy/detais called the Jacobian in some references, because it relates the rapidity distribution dN/dy and pseudorapidity distribution dN/deta.
I honestly just tried to make sense out of the curious fact (not primarily regarding track finding) that CPMP's formula
\n\narsinh(zr / 0.7) / 3.5\nled to a uniform distribution and some Google search showed it could be related to (pseudo-)rapidity.
\n\nBut I notice I am walking on shaky ground here!
", "votes": 0, "replies": [] }, { "id": 374220, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-22T16:16:15.343000", "content": "@Mark, I found that when I restrict the data to be the hits of tracks originating from the z axis, then non scaled arcsinh is best. It means my code can be improved by removing the scaling probably...
", "votes": 0, "replies": [] }, { "id": 374243, "author_name": "Mark JD Hamilton", "author_url": "", "post_date": "2018-08-22T16:52:30.057000", "content": "@CPMP, thanks, that's interesting.
", "votes": 0, "replies": [] }, { "id": 374580, "author_name": "CPMP", "author_url": "", "post_date": "2018-08-23T10:22:43.883000", "content": "What is funny is that with unscaled arcsinh my local score climbs faster, but plateaus earlier. Maybe I need to tune the value of eps for DBSCAN again, but I won't ;) Just to say that this is not a clear win.
", "votes": 0, "replies": [] } ] }, { "id": 370661, "author_name": "Sergey Zlobin", "author_url": "", "post_date": "2018-08-15T08:28:14.233000", "content": "By the way almost everyone used
\n\nphi = arctan(y/x)\nIt's not quite right, since (x, y) and (-x, -y) give the same angle, but they should differ by Pi. I used
\n\ndef calc_phi(hits_row):\nif hits_row['y'] >= 0:\n return math.acos(hits_row['x'] / hits_row['r2'])\nelse:\n return 2 * math.pi - math.acos(hits_row['x'] / hits_row['r2'])\nFor some reason it seems doesn't matter for a score.
", "votes": 0, "replies": [ { "id": 370666, "author_name": "David Rousseau", "author_url": "", "post_date": "2018-08-15T08:54:23.220000", "content": "arctan2(y,x) in most libraries including np does the job
", "votes": 2, "replies": [] }, { "id": 370670, "author_name": "Sergey Zlobin", "author_url": "", "post_date": "2018-08-15T09:04:06.723000", "content": "@David Rousseau\nThanks, I didn't know that arctan2 can do that. I had to check the documentation for this function.
", "votes": 0, "replies": [] }, { "id": 370725, "author_name": "YaGana Sheriff-Hussaini", "author_url": "", "post_date": "2018-08-15T10:57:48.767000", "content": "@Sergey Zlobin, I was doing the same thing as you earlier until I saw np.arctan2(y,x) used in one of the kernels, I checked it out and discovered it works.
", "votes": 1, "replies": [] } ] }, { "id": 371940, "author_name": "", "author_url": "", "post_date": "2018-08-17T21:32:53.583000", "content": "", "votes": 0, "replies": [] }, { "id": 370422, "author_name": "", "author_url": "", "post_date": "2018-08-14T19:52:40.967000", "content": "", "votes": 1, "replies": [] } ], "raw_markdown_by_id": { "369949": "Did I disclose I have been using DBSCAN? Well, now you know ;) \n\nMy approach is quite straightforward and has been almost fully disclosed by @yuval. An helix that starts from z axis can be described by 4 parameters:\n\n - z at origin `z0`\n - radius `r0`\n - angle at origin in transverse plane (x,y plane) `phi0`\n - slope `zr`\n\nThe last 3 can be expressed as functions of the momentum at origin, `px`, `py`, `pz`, and `pt = sqrt(px² + py²)`:\n\n - `r0 = C * pt`\n - `phi0 = arctan(py/px)`\n - `zr = pz/pt`\n\nThe formula to compute `C` is given in the documents from CERN but I estimated it from the train data via a linear regression. That's the only use of supervised learning I made ;)\n\nMy code loops over `z0, r0` pairs. Rather than estimating a distribution I just sample from the tracks in the first 100 train samples. For each pair I 'unroll the helix', i.e. compute `phi0` and `zr` as:\n\n phi0 = phi +- theta0\n zr = (z - z0) / (2 * r0 * theta0)\n\nwhere `rt` is the distance to origin in transverse plane, `phi` the angle in transverse plane, and `theta0` is the unrolling angle:\n\n rt = sqrt(x² + y²)\n phi = arctan(y/x)\n theta0 = arcsin(rt / (2 * r0))\n\nIn one iteration I add `theta0` to `phi`, and in the next iteration I subtract it.\n\nIn order to cope with the discontinuity at `pi` and `-pi` I use `cos(phi0)` and `sin(phi0)`. \n\nThe distribution of `zr` is highly skewed. Many have use `arctan` to unskew it, but I found that using `arcsinh` was way more effective. I actually use:\n\n arcsinh(zr / 0.7) / 3.5\n\nThe picture below gives the distribution of arctan(zr), and the one below the distribution of arcsinh. The latter is way more uniform.\n\n![arctan distribution][1]\n\n![arcsinh distribution][2]\n\nThe last twist is to model the uneven magnetic field at high values of `z`. The picture below shows the relative difference between the theoretical angle, and the median of measured angle as a function of `z`, the picture below gives the number of hits in log scale:\n\n![ratio1][3]\n\nThe best way I found was to multiply `theta0` with a correction that depends on `z`:\n\n 1.005 - (abs(z + 200) / 6000)**2.4\n\nThe picture below shows a smoothed average of the median measured angle deviation (in blue), and my correction function (in red):\n\n![ratio][4]\n\nDBSCAN is run at each iteration. Its output is merged with existing tracks in a simple way: for each track, or candidate track, I compute the number of volumes with hits from the track. Hits are then assigned to the candidate track with the most volumes. Using number of volumes is way more effective than using the number of hits in the track. \n\nAnother criteria is used for deciding which track wins. I assign a unique `vl_id` to each `volume_id, layer_id` pair. For each of the first 100 train events I represented each particle track by the sequence of its `vl_id` once data is sorted by `z`. I then compute the frequency of each sub sequence of 4 `vl_id` . The quality of each track candidate in test events is computed in a similar way: first create the sequence of its `vl_id` once data is sorted by `z`, then take the average of the log of the frequencies of its sub sequences of length 4, and multiply by the number of volumes of the candidate track. A hit is assigned to a new candidate track if the new candidate track has both more volumes and a better quality than the current track of the hit. This quality is very effective in removing tracks that do not make sense, for instance tracks that skip a layer entirely. \n\nThe above yields a LB score above 0.785 with about 33000 DBSCAN runs. It takes about 10 hours per event.\n\nThe extra mileage I got comes for a simple idea: run another, similar model, on the inner volumes only (7, 8, and 9). This model can be more conservative (smaller eps for DBSCAN) because tracks are closer to perfect helix. I ran this model for about the same number of iterations, then merged its output with the previous model: tracks that overlap significantly are merged, and for the rest, the track with most volumes wins.\n\nThe very last improvements (about 0.002) come from merging with a third model that is similar to the first one.\n\nThat's it, no fancy math, just lots of tuning. I hope I have not made errors in the equations, I'll check again tomorrow, but appreciate if you find typos. They must be correct in the code given the results: the code finds about 95% of the centered tracks.\n\nThings I thought about but did not had time to finish implementing:\n\n - Use direction information from cells data\n - Extend to tracks that do not pass near z axis\n - Fit helix to each track candidate to remove outliers and possibly add missing hits.\n\nI thought my approach would be a nice starting point for second phase, given its simplicity, but I no longer think it is, now that I saw @icecuber solution!\n\n\n [1]: https://storage.googleapis.com/kaggle-forum-message-attachments/369949/10056/atan1.png\n [2]: https://storage.googleapis.com/kaggle-forum-message-attachments/369949/10055/asinh.png\n [3]: https://storage.googleapis.com/kaggle-forum-message-attachments/369949/10052/ratio1.png\n [4]: https://storage.googleapis.com/kaggle-forum-message-attachments/369949/10053/ratio.png", "370324": "Thanks for you sharing,My solution is also based on DBScan and I also have no time to finish:\"Use direction information from cells data and Extend to tracks that do not pass near z axis\",but I fitted helix to extend the tracks.I also used the tips from Heng to find candicate hits and desinged a LGBM model to classify the candidates.\n", "376482": "Final code and documentation is available on github: https://github.com/jfpuget/Kaggle_TrackML\n\nI found why my local score was higher than the LB: I forgot to use the magnetic field correction in one model... Once fixed local score and LB score become much closer, with a difference smaller than 0.001. I document and share code for the fixed models.", "375535": "@CPMP\n \nThanks for the solution. It is a nice piece of work!\n", "374054": "I have put some code on [github][1] \n\nThis is work in progress, the repo should be final by Monday. \n\nThe code computes something that should give a LB above 0.78. I'm running it as of now to see what score exactly this yields.\n\nCleaning my code revealed few little glitches that explain why my LB score was below my local score. I hope the code on github fixes that.\n\n\n [1]: https://github.com/jfpuget/Kaggle_TrackML", "372564": "Congratulations, CPMP! I always learn great things from your posts.", "371557": "I'm trying to understand how I can get a better score. You have many improvements, probably every step give you a boost. \nAnyway, Yuval said that's easy yo get 0.7 with right features. I tried his approach with the normal distribution but didn't get a better score. And my features are standard: cos, sin, zr and arctan(zr) (I noticed that zr is helpful also together with arctan).\n\n> The formula to compute C is given in the documents from CERN but I estimated it from the train data via a linear regression. That's the only use of supervised learning I made\n\nI don't understand why you need this. Features doesn't involved this constant and you don't have px, py, pz in the test data.\n\n> Using number of volumes is way more effective than using the number of hits in the track. \n\nProbably this gave you a good boost, right? I used the number of hits.\n\n> The extra mileage I got comes for a simple idea: run another, similar model, on the inner volumes only (7, 8, and 9). \n\nI used this also in my solution. I constructed tracks inside r < 200 (you can also use cells there). Then I used DBSCAN for all hits but verifying tracks by \"the first half\" of tracks found earlier.", "371059": "@CPMP, I'm wondering about your plot of the angle differences due to the magnetic field. You write it is as a function of z, but is your z-axis rescaled? The axis seems to go only from -300 to +300. Did you convert to cm?\n\nI'm interested because of the large peaks in the curve. Do they coincide with the first large caps closest to the large cylinders? I ask because I think I saw some anomalies exactly at (and only at) these first (innermost) large caps.\n\nYou curve also has a peaked feature at the positive z-end, which matches with the strange features of the B field visible in my plots in the last (outermost) cap towards +z, I think.", "370955": "Congratulations and many thanks to share your solutions :-) Not easy competition not only to understand it but mostly for the computational effort !!! ", "370609": "congratulations! and thanks for sharing your approach", "370472": "For zr, the math says use arctan to convert to a physically meaningful angle. How did you ever come up with the idea of using a scaled inverse hyperbolic sine?", "370335": "@CPMP, congratulations on reaching your goal of 0.80! I was rooting for you to make it in the final hours before the deadline.\n\nYour solutions looks very elegant. Definitely one of the best score per codelines ratios, I guess.\n\nYes, all the ensemble clustering approaches would have no chance against the combinatoric/geometric ones in the throughput phase. However, the features you developed and your track quality metric could be interesting to incorporate for track evaluation even in combinatoric solutions.", "370129": "Thank you for sharing! And special thank you for the post on paralleling, it gave me a great boost once I managed to do it (better late than never :))", "370021": "Congratulations @CPMP on gaining another gold metal and thanks for sharing your solution.", "370953": "@CPMP in the formula:\n\n `zr = (z - z0) / (2 * r0 * phi0)`\n\ndidn't you mean\n\n zr = (z - z0) / (2 * r0 * theta0)", "375722": "@CPMP really good job. Well done. [enter link description here][1]\n\n\n [1]: https://twitter.com/trackmllhc/status/1033277891226820608", "370330": "Merci d'avoir partagé cela avec nous. ", "374889": "Any participant (not necessarily with the highest score) who think they made valuable contributions with innovative algorithms (in particular if they have shared insights on the forum) are welcome to release publicly their code with an open source license and lightweight structured documentation. This will allow to compete for the « HEP meets ML » jury prizes: a NVidia V100 GPU, and two invitations to NIPS 2018 or the spring 2019 CERN workshop.See details in forum topic:\n\nhttps://www.kaggle.com/c/trackml-particle-identification/discussion/63289", "371307": "Following up on the [excellent find by Mark JD Hamilton][1], here is a plot of `arcsinh(zr)`. While quite uniform, it is not as uniform as the scaled version I used.\n\n![arcsinh][2]\n\n\n [1]: https://www.kaggle.com/c/trackml-particle-identification/discussion/63250#371072\n [2]: https://storage.googleapis.com/kaggle-forum-message-attachments/371307/10098/asinh2.png", "370661": "By the way almost everyone used \n\n phi = arctan(y/x)\n\nIt's not quite right, since (x, y) and (-x, -y) give the same angle, but they should differ by Pi. I used\n\n def calc_phi(hits_row):\n if hits_row['y'] >= 0:\n return math.acos(hits_row['x'] / hits_row['r2'])\n else:\n return 2 * math.pi - math.acos(hits_row['x'] / hits_row['r2'])\n\nFor some reason it seems doesn't matter for a score.", "371940": "", "370422": "" } }