Hi,
\nJust to make sure: If vel is the (1,70,70) velocity field, then we should submit vel[0, :, ::2]? I.e. retain the depth dimension completely and skip every second lateral value?
Hi,
\nJust to make sure: If vel is the (1,70,70) velocity field, then we should submit vel[0, :, ::2]? I.e. retain the depth dimension completely and skip every second lateral value?
Per the competition data section:
\n\n\nA sample submission file in the correct format. The submission format is a stack of the 2D predictions, with every row (y values) included, but only the odd-valued columns (x values).
\n
Suppose your tensor has shape (bs, 1, 70, 70), where the spatial dimension (70, 70) represents height and width respectively, or (y, x) in the Cartesian plan. Only odd x values will be evaluated, i.e., the following slices: (bs, 70, 1), (bs, 70, 3), (bs, 70, 5), etc, which should be obtained by vel[:, 0, :, 1::2].
For vel shaped (1,70,70) it should be vel[0, :, 1::2] because you skip the first column (the first column name is x_1 while the first row in the sample_submission file is 000039dca2_y_0, so we know the indexing starts at 0). This is in line with what @vitormeurerbesen wrote.
Thanks a lot for clarifying.
", "rawMarkdown": "Thanks a lot for clarifying.", "votes": null }, { "id": "3215031", "postDate": "06/01/2025 13:47:58", "content": "Thank you @vitormeurerbesen and @piotrekga for providing this critically important clarification.
\n\n\nOnly the odd position values of x_ (columns) should be submitted… All y_ positions (rows) must be predicted, with the predictions of each oid stacked onto each other.
\n
I want to humbly suggest Kaggle: Please do not (solely) use the words \"row\", \"column\", \"x\", \"y\", \"odd\", and \"even\" when making dimensional indexing descriptions such as this one. It's very, very ambiguous.
\n\"x\" and \"y\": Mathematicians use (x, y), Matlab 2D matrix indexing uses (y, x), Matlab meshgrid function uses (x, y), etc., etc. Different people have different conventions. Your x could be my y. Totally ambiguous.
\"Row\" and \"column\": If we take \"row\" to mean the first dimension (which is already an ambiguous term), then if you store things \"row\"-major, your row could be my column. If you talk about the dual solution while I'm referring to the primal solution, your column could be my row. Etc., etc. Totally ambiguous.
\n\"Odd\" and \"even\": If a tensor has shape (5, 70, 80), is size 70 at an odd or even index? It's even because it's at the second index, after 5. It's odd because with 0-based indexing, first is 0-th and second is 1-st, and 1 is odd. Totally ambiguous.
\nI suggest what @vitormeurerbesen and @piotrekga did: spit out exactly what is intended: vel[:, 0, :, 1::2] with some light human language describing your intention, if desired.
P.S. Just for reference, in Matlab or GNU Octave, vel[:, 0, :, 1::2] is vel(:, 1, :, 2:2:end)
P.S. Please don't overlook the issue of human language ambiguity. Some of the worst accidents in human history were solely caused by it.
", "rawMarkdown": "Thank you @vitormeurerbesen and @piotrekga for providing this critically important clarification.\n\n>Only the odd position values of x_ (columns) should be submitted... All y_ positions (rows) must be predicted, with the predictions of each oid stacked onto each other.\n\nI want to humbly suggest Kaggle: Please do not (solely) use the words \"row\", \"column\", \"x\", \"y\", \"odd\", and \"even\" when making dimensional indexing descriptions such as this one. It's very, very ambiguous.\n\n\"x\" and \"y\": Mathematicians use (x, y), Matlab 2D matrix indexing uses (y, x), Matlab `meshgrid` function uses (x, y), etc., etc. Different people have different conventions. Your x could be my y. Totally ambiguous.\n\n\"Row\" and \"column\": If we take \"row\" to mean the first dimension (which is already an ambiguous term), then if you store things \"row\"-major, your row could be my column. If you talk about the dual solution while I'm referring to the primal solution, your column could be my row. Etc., etc. Totally ambiguous.\n\n\"Odd\" and \"even\": If a tensor has shape (5, 70, 80), is size 70 at an odd or even index? It's even because it's at the *second* index, after 5. It's odd because with 0-based indexing, first is 0-th and second is *1*-st, and 1 is odd. Totally ambiguous.\n\nI suggest what @vitormeurerbesen and @piotrekga did: spit out exactly what is intended: `vel[:, 0, :, 1::2]` with some light human language describing your intention, if desired.\n\nP.S. Just for reference, in Matlab or GNU Octave, `vel[:, 0, :, 1::2]` is `vel(:, 1, :, 2:2:end)`\n\nP.S. Please don't overlook the issue of human language ambiguity. Some of the worst accidents in human history were *solely* caused by it.", "votes": null }, { "id": "3227969", "postDate": "06/19/2025 14:00:17", "content": "100% with you on this
", "rawMarkdown": "100% with you on this", "votes": null } ], "comments": [ { "id": 3191136, "author_name": "vitormeurerbesen", "author_url": "", "post_date": "05/01/2025 12:56:17", "content": "Per the competition data section:
\n\n\nA sample submission file in the correct format. The submission format is a stack of the 2D predictions, with every row (y values) included, but only the odd-valued columns (x values).
\n
Suppose your tensor has shape (bs, 1, 70, 70), where the spatial dimension (70, 70) represents height and width respectively, or (y, x) in the Cartesian plan. Only odd x values will be evaluated, i.e., the following slices: (bs, 70, 1), (bs, 70, 3), (bs, 70, 5), etc, which should be obtained by vel[:, 0, :, 1::2].
For vel shaped (1,70,70) it should be vel[0, :, 1::2] because you skip the first column (the first column name is x_1 while the first row in the sample_submission file is 000039dca2_y_0, so we know the indexing starts at 0). This is in line with what @vitormeurerbesen wrote.
Thanks a lot for clarifying.
", "votes": null, "replies": [] } ] }, { "id": 3215031, "author_name": "revealer", "author_url": "", "post_date": "06/01/2025 13:47:58", "content": "Thank you @vitormeurerbesen and @piotrekga for providing this critically important clarification.
\n\n\nOnly the odd position values of x_ (columns) should be submitted… All y_ positions (rows) must be predicted, with the predictions of each oid stacked onto each other.
\n
I want to humbly suggest Kaggle: Please do not (solely) use the words \"row\", \"column\", \"x\", \"y\", \"odd\", and \"even\" when making dimensional indexing descriptions such as this one. It's very, very ambiguous.
\n\"x\" and \"y\": Mathematicians use (x, y), Matlab 2D matrix indexing uses (y, x), Matlab meshgrid function uses (x, y), etc., etc. Different people have different conventions. Your x could be my y. Totally ambiguous.
\"Row\" and \"column\": If we take \"row\" to mean the first dimension (which is already an ambiguous term), then if you store things \"row\"-major, your row could be my column. If you talk about the dual solution while I'm referring to the primal solution, your column could be my row. Etc., etc. Totally ambiguous.
\n\"Odd\" and \"even\": If a tensor has shape (5, 70, 80), is size 70 at an odd or even index? It's even because it's at the second index, after 5. It's odd because with 0-based indexing, first is 0-th and second is 1-st, and 1 is odd. Totally ambiguous.
\nI suggest what @vitormeurerbesen and @piotrekga did: spit out exactly what is intended: vel[:, 0, :, 1::2] with some light human language describing your intention, if desired.
P.S. Just for reference, in Matlab or GNU Octave, vel[:, 0, :, 1::2] is vel(:, 1, :, 2:2:end)
P.S. Please don't overlook the issue of human language ambiguity. Some of the worst accidents in human history were solely caused by it.
", "votes": null, "replies": [ { "id": 3227969, "author_name": "justinwallace234", "author_url": "", "post_date": "06/19/2025 14:00:17", "content": "100% with you on this
", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "3190932": "Hi,\n\nJust to make sure: If `vel` is the `(1,70,70)` velocity field, then we should submit `vel[0, :, ::2]`? I.e. retain the depth dimension completely and skip every second lateral value?", "3191136": "Per the competition data section: \n> A sample submission file in the correct format. The submission format is a stack of the 2D predictions, with every row (y values) included, but only the odd-valued columns (x values).\n\nSuppose your tensor has shape `(bs, 1, 70, 70)`, where the spatial dimension (70, 70) represents height and width respectively, or (y, x) in the Cartesian plan. Only odd x values will be evaluated, i.e., the following slices: `(bs, 70, 1)`, `(bs, 70, 3)`, `(bs, 70, 5)`, etc, which should be obtained by `vel[:, 0, :, 1::2]`.", "3191290": "For `vel` shaped `(1,70,70)` it should be `vel[0, :, 1::2]` because you skip the first column (the first column name is `x_1` while the first row in the sample_submission file is `000039dca2_y_0`, so we know the indexing starts at `0`). This is in line with what @vitormeurerbesen wrote.", "3191489": "Thanks a lot for clarifying.", "3215031": "Thank you @vitormeurerbesen and @piotrekga for providing this critically important clarification.\n\n>Only the odd position values of x_ (columns) should be submitted... All y_ positions (rows) must be predicted, with the predictions of each oid stacked onto each other.\n\nI want to humbly suggest Kaggle: Please do not (solely) use the words \"row\", \"column\", \"x\", \"y\", \"odd\", and \"even\" when making dimensional indexing descriptions such as this one. It's very, very ambiguous.\n\n\"x\" and \"y\": Mathematicians use (x, y), Matlab 2D matrix indexing uses (y, x), Matlab `meshgrid` function uses (x, y), etc., etc. Different people have different conventions. Your x could be my y. Totally ambiguous.\n\n\"Row\" and \"column\": If we take \"row\" to mean the first dimension (which is already an ambiguous term), then if you store things \"row\"-major, your row could be my column. If you talk about the dual solution while I'm referring to the primal solution, your column could be my row. Etc., etc. Totally ambiguous.\n\n\"Odd\" and \"even\": If a tensor has shape (5, 70, 80), is size 70 at an odd or even index? It's even because it's at the *second* index, after 5. It's odd because with 0-based indexing, first is 0-th and second is *1*-st, and 1 is odd. Totally ambiguous.\n\nI suggest what @vitormeurerbesen and @piotrekga did: spit out exactly what is intended: `vel[:, 0, :, 1::2]` with some light human language describing your intention, if desired.\n\nP.S. Just for reference, in Matlab or GNU Octave, `vel[:, 0, :, 1::2]` is `vel(:, 1, :, 2:2:end)`\n\nP.S. Please don't overlook the issue of human language ambiguity. Some of the worst accidents in human history were *solely* caused by it.", "3227969": "100% with you on this" }, "source": "meta" }