With and without space has the same LB
", "rawMarkdown": "With and without space has the same LB", "votes": null }, { "id": "3383527", "postDate": "12/30/2025 10:42:18", "content": "If the test set is similar to the train.csv set, then it will matter for ca. 38% of the transliterations / ca. 33% of translations:\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F2259646%2F3559fe6ef88ba7f4bc76fb61a6a56bcc%2FFraction%20density%20in%20transliterations-translations.png?generation=1767090967162089&alt=media\"){kind=spacer}
For those that it will, it won't give a large impact, since in most cases fractions account for less than 5% of words:\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F2259646%2Ffcd4ecbbc6bdfc739cc339e34cd481ff%2FFraction%20to%20word%20ratio%20in%20transliterations-translations.png?generation=1767091109587433&alt=media\"){kind=spacer}
The code for the above fractions:
\nnumber_of_fractions = train.loc[:,'transliteration'].apply(lambda row: len(re.findall(r'\\b([0-9]+\\.33[3]*|[0-9]+\\.5|\\.25|[0-9]+\\.75)\\b', row)))\nnumber_of_words = train.loc[:,'transliteration'].apply(lambda row: len(re.findall(r'\\b([\\w\\-\\.]+)\\b', row)))\nfraction_to_words_ratio = number_of_fractions/number_of_words\n\nnumber_of_fractions_t = train.loc[:,'translation'].apply(lambda row: len(re.findall(r'\\b([0-9]+\\.33[3]*|[0-9]+\\.5|\\.25|[0-9]+\\.75)\\b', row)))\nnumber_of_words_t = train.loc[:,'translation'].apply(lambda row: len(re.findall(r'\\b([\\w\\-\\.]+)\\b', row)))\nfraction_to_words_ratio_t = number_of_fractions_t/number_of_words_t\nI haven't consulted the metrics so I can't give the estimates of how they would change but this would be my guess as to why the observed changes are not very impactful.
", "rawMarkdown": "If the test set is similar to the `train.csv` set, then it will matter for ca. 38% of the transliterations / ca. 33% of translations:\n\n\nFor those that it will, it won't give a large impact, since in most cases fractions account for less than 5% of words:\n\n\nThe code for the above fractions:\n```python\nnumber_of_fractions = train.loc[:,'transliteration'].apply(lambda row: len(re.findall(r'\\b([0-9]+\\.33[3]*|[0-9]+\\.5|\\.25|[0-9]+\\.75)\\b', row)))\nnumber_of_words = train.loc[:,'transliteration'].apply(lambda row: len(re.findall(r'\\b([\\w\\-\\.]+)\\b', row)))\nfraction_to_words_ratio = number_of_fractions/number_of_words\n\nnumber_of_fractions_t = train.loc[:,'translation'].apply(lambda row: len(re.findall(r'\\b([0-9]+\\.33[3]*|[0-9]+\\.5|\\.25|[0-9]+\\.75)\\b', row)))\nnumber_of_words_t = train.loc[:,'translation'].apply(lambda row: len(re.findall(r'\\b([\\w\\-\\.]+)\\b', row)))\nfraction_to_words_ratio_t = number_of_fractions_t/number_of_words_t\n```\n\nI haven't consulted the metrics so I can't give the estimates of how they would change but this would be my guess as to why the observed changes are not very impactful.", "votes": null }, { "id": "3383555", "postDate": "12/30/2025 11:18:45", "content": "It's similar for me the LB remains the same with or without floats to fractions conversion. However, if I sort public LB by score then I can see it's a bit better for the submission with fractions conversion. @hrithik22122 Is it the same for you? If 2 submissions are strictly equal then the first one (oldest) should be the first. Otherwise it's sorted by best score (even if it displays only a single digit as far as I know)
\nSecond, impact for floats to fractions conversion on geometric_mean is quite low on a single fold OOF for me:
\n- \n
- Floats + limited fractions in ground truth: 45.53 (we've some fractions already in ground truth) \n
- Fractions only in ground truth: 44.22 \n
Let's wait for the official voice of organizer. \nThere are for sure other reasons for such a big gap between CV / LB we need to discover.
", "rawMarkdown": "It's similar for me the LB remains the same with or without floats to fractions conversion. However, if I sort public LB by score then I can see it's a bit better for the submission with fractions conversion. @hrithik22122 Is it the same for you? If 2 submissions are strictly equal then the first one (oldest) should be the first. Otherwise it's sorted by best score (even if it displays only a single digit as far as I know)\n\nSecond, impact for floats to fractions conversion on geometric_mean is quite low on a single fold OOF for me:\n- Floats + limited fractions in ground truth: 45.53 (we've some fractions already in ground truth)\n- Fractions only in ground truth: 44.22\n\nLet's wait for the official voice of organizer. \nThere are for sure other reasons for such a big gap between CV / LB we need to discover.", "votes": null }, { "id": "3383557", "postDate": "12/30/2025 11:24:50", "content": "lol,yes, decimal places aren’t shown, but the submission clearly reflects the actual values of the three same scores.
", "rawMarkdown": "lol,yes, decimal places aren’t shown, but the submission clearly reflects the actual values of the three same scores.", "votes": null }, { "id": "3383570", "postDate": "12/30/2025 11:42:53", "content": "Nah , when I sort it , my first submission(one without fraction post processing) comes up first
\nI was expecting an LB increase of around 0.2–0.6 because the penalty for raw decimals should be massive:
\n- \n
BLEU: A mismatch like 13.3333 vs 13 ⅓ means zero overlap for that token. By fixing it, we should recover the unigram match, plus the associated bi-grams and tri-grams (\"paid 13.333 silver\" vs \"paid 13 ⅓ silver\").
\nchRF++: The character edit distance between 13.3333 (7 chars) and 13 ⅓ (3-4 chars) is very large. Normalizing this should have significantly reduced the edit distance penalty.
\n
The ground truth uses a space between the integer and the fraction (e.g., 2 ½).\nLet me put it this way, there are no instances of '/' in either the translation or transliteration, this goes for both the public and private evaluation data.
", "rawMarkdown": "The ground truth uses a space between the integer and the fraction (e.g., 2 ½).\nLet me put it this way, there are no instances of '/' in either the translation or transliteration, this goes for both the public and private evaluation data.", "votes": null }, { "id": "3383682", "postDate": "12/30/2025 16:37:59", "content": "Oh, this is really a highly potential point, I can try it again tomorrow.Thanks
", "rawMarkdown": "Oh, this is really a highly potential point, I can try it again tomorrow.Thanks", "votes": null }, { "id": "3383685", "postDate": "12/30/2025 16:43:19", "content": "Thanks , this is Huge
", "rawMarkdown": "Thanks , this is Huge", "votes": null } ], "comments": [ { "id": 3383499, "author_name": "hrithik22122", "author_url": "", "post_date": "12/30/2025 09:41:12", "content": "With and without space has the same LB
", "votes": null, "replies": [] }, { "id": 3383527, "author_name": "angantyr", "author_url": "", "post_date": "12/30/2025 10:42:18", "content": "If the test set is similar to the train.csv set, then it will matter for ca. 38% of the transliterations / ca. 33% of translations:\n
For those that it will, it won't give a large impact, since in most cases fractions account for less than 5% of words:\n
The code for the above fractions:
\nnumber_of_fractions = train.loc[:,'transliteration'].apply(lambda row: len(re.findall(r'\\b([0-9]+\\.33[3]*|[0-9]+\\.5|\\.25|[0-9]+\\.75)\\b', row)))\nnumber_of_words = train.loc[:,'transliteration'].apply(lambda row: len(re.findall(r'\\b([\\w\\-\\.]+)\\b', row)))\nfraction_to_words_ratio = number_of_fractions/number_of_words\n\nnumber_of_fractions_t = train.loc[:,'translation'].apply(lambda row: len(re.findall(r'\\b([0-9]+\\.33[3]*|[0-9]+\\.5|\\.25|[0-9]+\\.75)\\b', row)))\nnumber_of_words_t = train.loc[:,'translation'].apply(lambda row: len(re.findall(r'\\b([\\w\\-\\.]+)\\b', row)))\nfraction_to_words_ratio_t = number_of_fractions_t/number_of_words_t\nI haven't consulted the metrics so I can't give the estimates of how they would change but this would be my guess as to why the observed changes are not very impactful.
", "votes": null, "replies": [] }, { "id": 3383555, "author_name": "mpware", "author_url": "", "post_date": "12/30/2025 11:18:45", "content": "It's similar for me the LB remains the same with or without floats to fractions conversion. However, if I sort public LB by score then I can see it's a bit better for the submission with fractions conversion. @hrithik22122 Is it the same for you? If 2 submissions are strictly equal then the first one (oldest) should be the first. Otherwise it's sorted by best score (even if it displays only a single digit as far as I know)
\nSecond, impact for floats to fractions conversion on geometric_mean is quite low on a single fold OOF for me:
\n- \n
- Floats + limited fractions in ground truth: 45.53 (we've some fractions already in ground truth) \n
- Fractions only in ground truth: 44.22 \n
Let's wait for the official voice of organizer. \nThere are for sure other reasons for such a big gap between CV / LB we need to discover.
", "votes": null, "replies": [ { "id": 3383557, "author_name": "qifeihhh666", "author_url": "", "post_date": "12/30/2025 11:24:50", "content": "lol,yes, decimal places aren’t shown, but the submission clearly reflects the actual values of the three same scores.
", "votes": null, "replies": [] }, { "id": 3383570, "author_name": "hrithik22122", "author_url": "", "post_date": "12/30/2025 11:42:53", "content": "Nah , when I sort it , my first submission(one without fraction post processing) comes up first
\nI was expecting an LB increase of around 0.2–0.6 because the penalty for raw decimals should be massive:
\n- \n
BLEU: A mismatch like 13.3333 vs 13 ⅓ means zero overlap for that token. By fixing it, we should recover the unigram match, plus the associated bi-grams and tri-grams (\"paid 13.333 silver\" vs \"paid 13 ⅓ silver\").
\nchRF++: The character edit distance between 13.3333 (7 chars) and 13 ⅓ (3-4 chars) is very large. Normalizing this should have significantly reduced the edit distance penalty.
\n
The ground truth uses a space between the integer and the fraction (e.g., 2 ½).\nLet me put it this way, there are no instances of '/' in either the translation or transliteration, this goes for both the public and private evaluation data.
", "votes": null, "replies": [ { "id": 3383682, "author_name": "qifeihhh666", "author_url": "", "post_date": "12/30/2025 16:37:59", "content": "Oh, this is really a highly potential point, I can try it again tomorrow.Thanks
", "votes": null, "replies": [] }, { "id": 3383685, "author_name": "hrithik22122", "author_url": "", "post_date": "12/30/2025 16:43:19", "content": "Thanks , this is Huge
", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "3383435": "Hi everyone,\n\nFollowing the host's comment regarding the hidden test dataset using Unicode fractions (e.g., `½`, `⅓`, `2 ½`) instead of decimals/floats, I implemented a post-processing step to align my model's output with the expected format.\n\n### The Context\nIn the discussion [How To Handle These Examples](https://www.kaggle.com/competitions/deep-past-initiative-machine-translation/discussion/664795), the host mentioned:\n```\n\"The fractions are retained in the hidden test dataset... you will find 2 ½ minas... and NOT 2.5 ma-na.\"\n```\n### My Approach\nI wrote a script to dynamically convert decimal patterns in my predictions to their closest Unicode fraction equivalents (using `limit_denominator` to catch `0.333...` as `⅓`).\n\nVisually, the script seems to work perfectly on the sample items:\n\n* **Example 1:** `42.33333 ma-na` -> `42 ⅓ ma-na`\n* **Example 2:** `1.25 GÍN` -> `1 ¼ GÍN`\n\n### The Issue\nDespite this correction clearly matching the host's description of the ground truth format, **my LB score remained exactly the same** (to the 4th decimal) compared to the submission with raw floats.\n\n### My Code\nHere is the function I used. Is there an edge case I am missing, or is the spacing logic (`Integer[space]Fraction` vs `IntegerFraction`) different from what I assumed?\n\n```python\nimport re\nfrom fractions import Fraction\n\ndef process_fractions_dynamic(row, target_col=\"prediction\"):\n text_to_process = row.get(target_col, \"\")\n if not isinstance(text_to_process, str):\n return str(text_to_process)\n\n # Standard unicode map\n fraction_lookup = {\n (1, 2): \"½\", (1, 3): \"⅓\", (2, 3): \"⅔\",\n (1, 4): \"¼\", (3, 4): \"¾\",\n (1, 5): \"⅕\", (2, 5): \"⅖\", (3, 5): \"⅗\", (4, 5): \"⅘\",\n (1, 6): \"⅙\", (5, 6): \"⅚\",\n (1, 8): \"⅛\", (3, 8): \"⅜\", (5, 8): \"⅝\", (7, 8): \"⅞\"\n }\n\n def replacer(match):\n full_str = match.group(0)\n try:\n val = float(full_str)\n integer_part = int(val)\n decimal_part = val - integer_part\n\n # Return integer if decimal is negligible\n if decimal_part < 0.0001: \n return str(integer_part)\n\n # Limit denominator handles 0.3333 -> 1/3\n frac = Fraction(decimal_part).limit_denominator(12) \n \n unicode_frac = fraction_lookup.get((frac.numerator, frac.denominator))\n\n if unicode_frac:\n if integer_part == 0:\n return unicode_frac\n else:\n # Current logic: Space between Integer and Fraction\n return f\"{integer_part} {unicode_frac}\"\n \n return full_str \n\n except ValueError:\n return full_str\n\n processed_text = re.sub(r'\\b\\d+\\.\\d+\\b', replacer, text_to_process)\n return processed_text\n```\n## Ouput \n```\n[4] \n 2 ne2-pi2-szu 15 ma-na.TA u2 isz-ti2-in ne2-pi2-szu-um 10 ma-na ni-is-ha-su2 DIRI sza-du-a-su2 sza-bu-u2 SZU.NÍGIN 42.33333 ma-na KÙ.BABBAR s,a-ru-pa2-am ku-nu-ki-a a-na a-lu-wa u3 e-ni-sza-ri-im a2p-qi2-id-ma a-na a-lim{ki} a ma-la2 ti2-ir-ti2-szu a-s,e2-er sza-lim-a-szu3r u2-sze2-bi-il5-szu-nu a-ha-ma 13.33333 ma-na URUDU SIG5 a-na ga-am-ri-szu-nu u3 5 GÍN KÙ.BABBAR a-na u2-ku-ul-ti2-szu-nu a-di2-in IGI ili5-ba-ni DUMU ba-szi2-lam IGI a-hu-qar DUMU zu-ur-zu-ur IGI tu3-ra-am-i3-li2 DUMU e-di2-na-a-szu3r a-ha-ma 10.33333 ma-na 3.5 GÍN KÙ.BABBAR s,a-ru-pa2-am