ボルダリング・クライミング、人生の壁、心の壁、自宅の壁、建造物の壁など、テーマは不問です。
だれでも参加可能です。2025/12/01 00:00:00(JST) 時点で埋まっていなかったらカレンダーごと削除します。 2015年: https://adventar.org/calendars/1031
 2017年: https://adventar.org/calendars/2591
 20...

mstdn.maud.io Advent Calendar 2025 13 日目の記事です。昨日の記事は @Coro さんの 好きな動画チャンネル 2025 - blog.coro3.net でした。明日の記事は @zgock999 さんの「たまにはなんか書くか」です。 * * * どうも @mug です。伊豆大島の山奥から失礼します。 AI 生成画像ではありません。念のため。 うーん、素敵な場所ですね！**観光地には見えないくらい** 、ごく普通の山道です。 実際、ここに観光案内板があるわけでもありません。後ろを向いたからといって、絶景が広がっているわけでもありません。 ですが、ここには「ある用事」があって、この場所の写真を撮りにきました。ということで、最近の私の**趣味** を紹介します。 ### 趣味：リアルACW訪問 GeoGuessr というゲームがあります。世界中のストリートビュー画像がランダムに出てきて、その場所を地図上で当てるゲームです。 ちょっとマニアックな話になりますが、GeoGuessr には "World" という名前の公式世界マップがあります。しかし、この World は出題に謎の偏りがあったりして、なんとも「癖の強い」マップでした（※自分がよく遊んでいた 2022 年の話です。今はどうか知りません）。 > 第0回GeoGuessrガチ勢オフ会 > こちらで開催します。 > 希望者は現地集合でお願いします https://t.co/avPcRzr7dJ pic.twitter.com/iBSVyroPKc > > — Daig_O ʅ(･Θ･)ʃ (@Daig_O) 2024年4月30日 マジで、このミッドウェー島南西端ばっかり出ました そこで、World に代わる、出題バランスとゲーム性の担保されたマップを作る動きが有志から出てきます。その中で生まれたのが **ACW (A Community World)** マップです。ACW は人気も高く、一時期は公式の Duels 機能に逆輸入されていたほどです。他と比べても難易度が低めで、遊んでいて楽しいマップです。 ACW マップには世界中から **111,310 地点** が収録されていて（2025年12月現在）、有志が手作業で選んだそうです。すごい。出題地点には、住宅街や農村地帯もあれば、冒頭のような山道、まれに観光スポットも混ざっています。 私はそんな ACW マップが大好きです。なので、**ACW で見た場所を、ぜんぶ訪れようと思います**。というわけで、リアルでACWの出題地点を訪問する、**「リアルACW訪問」**が最近の私の趣味です。 ちなみに、「リアルACW訪問」は自分だけの趣味ではなく、何人か先駆者がいます。 X (旧 Twitter) で #リアルACW訪問 で検索すると、世界のあちこちの写真が出てくるので、あとで眺めてみてください。 さて、冒頭の伊豆大島をゲームのスクリーンショットと比べてみると、こんな感じです。 左：mug撮影、右：出題時のスクリーンショット どうでしょう？脇のガードレールの色や、木の生え方、道の曲がり方を比べてみると、たしかに間違いなく同じ地点です。 実際にゲームと同じ景色が目の前に現れると、なんだかパズルのピースがぴったり合ったような、不思議な**感動** があります。ストリートビューって現実の道を撮影しているんだから、この場所が存在するのは当たり前なんですけどね。どうでしょう、この感動、伝わりますか……？ というわけで、~~読者から共感を得られたかに不安を覚えつつ、~~ 今年「リアルACW訪問」した中で印象的だった場所をいくつか紹介していきます。 ### 青森 まずは青森市の住宅街から。Y字路の奥の赤いビルが目立つ、すてきな路地です。 ここを「リアルACW訪問」した時の写真がこちらです。ちゃんと、奥の赤いビルも、左右の建物もそのままあります。うれしいですね……！一方で、道脇や屋根の上に雪が積もっている点が、ストリートビューと違って印象的です。 ちなみに、青森市を訪れた日は、積雪深が113cmでした。訪れた時期にしては、平年の2倍くらい積もっていたようです。ここに来るまでにも、いくつか雪道を通ってきました。 駅前の放置自転車が完全に雪に埋もれており、雪中熟成のニンジンみたいになっていて味わい深かったです。 ついでに、ずっと行ってみたかった三内丸山遺跡にも寄ったのですが、 遺跡って冬に行くと、ただの雪原なんですね……。 Coffee break #1 ☕ ストリートビューの撮影時期 基本的に、ストリートビューは積雪のない時期に撮影されがちです。青森市内のストリートビューも例に漏れず、全て積雪のない時期（5月〜11月）に撮影されています。 ### 利尻島 北海道・利尻島にも ACW マップの出題地点があります。利尻町からオフロードの道を 2km ほど、標高差 60mくらい登ったところの丁字路です。 利尻島の ACW 出題地点 まわりは背の高い草木に囲まれていて、街灯もないような場所です。オフロードの道中も、人とは全くすれ違いませんでした。この丁字路目当てに観光に来る人は自分以外いないだろうと思うと、妙な優越感があります。 こういう謎地点を「リアルACW訪問」するとき、自転車やバイクは小回りが利いて便利です。ここを見に来るためだけに、利尻空港でマウンテンバイクを借りました。ルートの都合上、島一周 60km を走る羽目になったのですが、さすがにパソコンカタカタオタクには苦しかったです。 ちなみに、道中で昆布直売所の奥様から聞いた話ですが、利尻島は**島の風上が雨、風下が晴れ** というふうに天気が全然違うことがあるそうです。この日の風向は南で、島の南側は霧の強風でした。あまりにも向かい風がキツかったので後から調べたんですが、この日の最大風速は 18m/s だったそうです。そりゃあキツい。 島の南東、白い恋人のパッケージに描かれた丘。白すぎて何も見えず ACW の出題地点は島のちょうど真西で、晴れと曇りの境目くらいかなと思って行ったのですが、上の写真の通りこちらは曇りでした。残念に思いつつも、山の方角を見てみると、すーっと晴れ間が広がって、きれいに利尻富士が見えました。徳は積んでおくものですね。 ### 盛岡 盛岡市の ACW 出題地点は、イオンモール裏の住宅街にあります。家が並んで、電柱、歩道や車道もある、生活感あふれる道です。 この辺りには友人と一緒に来ていたのですが、「ちょっとここで待ってて」と言って、ゲームのスクリーンショットとなるべく同じ画角になるように、電柱の位置や奥のマンションの形を微調整しながら、数歩前に出てみたり、半歩下がってみたり、スマホを傾けてみたりして写真を撮っていました。 撮り終わって振り向いたら、「なにしてんだこいつ……」という顔をされていました。 夜は夜で雰囲気があっていいですね。ストリートビューは基本的に昼間に撮られるので、同じ場所の「夜の街並み」を見られるのは、現地訪問ならではの特権だなと思いました。 Coffee break #2 ☕ ストリートビューの画角 日本のストリートビューは、地上高 205cm から 360 度カメラで撮影されています。そのため、手持ちのスマホなどで画角を完全に合わせるのはかなり困難です。 写真を撮るコツですが、実際より少し後ろからズーム気味で撮ると、雰囲気が近くなっておすすめです。広角モードで撮ると、手前の建物にパースが強く効きすぎてしまいます。 ### 与那国 与那国島は日本最西端の島です。そんな与那国島には（おそらく）日本最西端の ACW マップ出題地点があります。与那国島らしい低い起伏と自然を一面に見渡せる、たいへん眺めの良いスポットです。 与那国島の ACW 出題地点 リアルACW訪問をしていると、出題者の意図を感じることがあります。GeoGuessrで出題されたのと同じ場所・アングルで写真を撮ると、ちゃんと「いい写真」に見えてくるんですよね。 ここは立体交差の高架をくぐったすぐ先が撮影地点でした。現地に行った時は、炎天下、汗を流しながら自転車で草木の間を走り抜けて、それはそれで旅の醍醐味なのですが、高架を抜けたこの場所で、一気に青空と与那国島の景色がバーッと広がって、本当に爽やかで美しい景色に見えました。 「たしかに、この島を一枚で切り取るならここかな」という気さえしてきて、この ACW というマップは、出題者が一つ一つ、見せたい景色を苦心して選んだマップなのかなと想像がふくらみます。いや、伊豆大島の山道を考えると、さすがにそれはないか……。 ところで、与那国島には、日本在来種のヨナグニウマという馬がいます。島の何か所かにヨナグニウマの牧場があり、そこで放牧されています。島の面積に対して牧場はかなり広く、牧場の中を道路が突っ切っていたりするので、道路から馬を観察することができます。 ACW 出題地点に向かうには、南牧場の中を通るルートが最短だったのですが、突然現れた馬の集団に道をふさがれて、経路変更を余儀なくされるなどのハプニングもありました。 ### ロンドン・ウェストミンスター ACW は "A Community **World** " の略なので、当然海外にも出題地点があります。なので、出題地点をぜんぶ訪れるには、海外に行く必要もありますね。 最後に、イギリス・ロンドンからの出題地点を紹介します。 ここはウェストミンスターにある、大使館が並ぶ通りの交差点です。ロンドンらしいレンガ造りの町並みに、窓が特徴的な奥の建物、手前右の "36 Buckingham Gate" の文字がチャーミングな場所です。 というわけで、飛行機に乗って…… 日本からはるばる、同じ交差点まで来ました。奥のビルも、"36 Buckingham Gate" の文字もそのままありますね！！ さすがに、奥の建物が見えてきた時にはちょっと感動しました。ここはバッキンガム宮殿に近いのもあって、かなり観光客の多い場所でした。 ここで「ゲームで出題された場所だ！」と喜んで写真を撮っていたら、通りがかった観光客の人たちも「ここがフォトスポットなのか？」という顔で同じ方向を撮りはじめて、ちょっと申し訳なくなりました。 Coffee break #3 ☕ 日本の ACW 出題地点数 ACW マップの出題地点は世界中にありますが、日本には全部で 2628 か所あるそうです。1 つの自治体あたり平均 1.5 か所ある計算になるので、あなたの街にも出題地点があるかもしれませんね。 ### おわりに こんな感じで、GeoGuessr の A Community World で出題された地点を訪れる「リアルACW訪問」をやっています。どれも観光ガイドに載るような場所ではありませんが、ゲームの中で一度見た風景に実際に立てたときの達成感は計り知れません。その土地土地の気候や人の気配を肌で感じて、同じ地点からまた新しい印象を受ける喜びもあります。 記事には書ききれなかった地点もいっぱいあり、これまで鹿児島、石垣島、アイラ島など、合計 24 地点を訪れてきましたが、 あと 111,286 地点を巡る必要があるようです。ではまた。 * * * ※本文中のゲーム画面の画像は、GeoGuessr のプレイ画面（Google ストリートビュー画像）を引用したものです。 Map data © Google

アイダホ州を投げて良い感じに立たせてください 投げた位置が地図上の位置に近ければ近いほどアイダホ適性が高くなります

Easy for humans, hard for AI. Try ARC-AGI.

そうだ、おミクじ引こう！

<p>この記事は <a href="https://adventar.org/calendars/10134">2024 TSG Advent Calendar</a> 初日の記事です。</p> <p><span itemscope="" itemtype="http://schema.org/Photograph"><img class="hatena-fotolife" height="675" itemprop="image" loading="lazy" src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/sh-mug/20241119/20241119233235.png" title="" width="1200"/></span></p> <p><span style="font-size: 300%">…………🤔❓</span></p> <h3 id="Python-の数値文字列判定ロジックを探る"><a class="keyword" href="https://d.hatena.ne.jp/keyword/Python">Python</a> の数値文字列判定ロジックを探る</h3> <h4 id="strisnumeric-メソッドとは">str.isnumeric() メソッドとは？</h4> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/Python">Python</a> の <code>str.isnumeric()</code> メソッドは、文字列内のすべての文字が数値を表すものであれば True を、そうでなければ False を返します。<a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#f-3ca21f31" id="fn-3ca21f31" name="fn-3ca21f31" title='つまり、文字列全体が数の表現として正しいかとは無関係です。たとえば、"123.45".isnumeric() は False、"兆兆".isnumeric() は True を返します。'>*1</a> まず、このメソッドの基本的な動作を見てみましょう。</p> <pre class="code lang-python" data-lang="python" data-unlink=""><span class="synComment"># Python の isnumeric() の動作例</span> <span class="synIdentifier">print</span>(<span class="synConstant">"123"</span>.isnumeric()) <span class="synComment"># True; 1, 2, 3 は数字</span> <span class="synIdentifier">print</span>(<span class="synConstant">"123a"</span>.isnumeric()) <span class="synComment"># False; a は数字ではない</span> <span class="synIdentifier">print</span>(<span class="synConstant">"五千万"</span>.isnumeric()) <span class="synComment"># True; 五、千、万 は数値</span> </pre> <p>漢数字にも対応しており、一見よさそうに見えます。ところが……</p> <pre class="code lang-python" data-lang="python" data-unlink=""><span class="synIdentifier">print</span>(<span class="synConstant">"兆"</span>.isnumeric()) <span class="synComment"># True</span> <span class="synIdentifier">print</span>(<span class="synConstant">"垓"</span>.isnumeric()) <span class="synComment"># False</span> </pre> <p>「兆」と「垓」はどちらも漢数字に使われる文字なのに、なぜ <a class="keyword" href="https://d.hatena.ne.jp/keyword/Python">Python</a> の str.isnumeric() は異なる結果を返すのでしょうか？</p> <h4 id="Python-と-Unicode-文字データベース"><a class="keyword" href="https://d.hatena.ne.jp/keyword/Python">Python</a> と <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> 文字データベース</h4> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/Python">Python</a> の文字列メソッド <code>str.isnumeric()</code> は、内部的に <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> の情報を活用しています。<a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> とは、世界中の文字を一元管理するための国際的な規格で、それぞれの文字がどんな性質を持つのかを「<a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> 文字データベース (UCD)」<sup id="fnref:1"><a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fn:1" rel="footnote">1</a></sup> という形で記録しています。データベースには「絵文字かどうか (Emoji)」や「大文字かどうか (Uppercase)」といった属性が文字ごとに記録されています。</p> <p>その中で、この記事で鍵になる情報は <strong>Numeric_Type プロパティ</strong> です。このプロパティは、文字が「数値」として扱われるかを示したもので、<a class="keyword" href="https://d.hatena.ne.jp/keyword/Python">Python</a> の <code>str.isnumeric()</code> もこの情報を元に判断を行っています。</p> <p>Numeric_Type プロパティには以下の 4 種類があります。<code>str.isnumeric()</code> の正式な仕様<sup id="fnref:2"><a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fn:2" rel="footnote">2</a></sup> には、文字がこのうち <strong>Decimal, Digit, Numeric</strong> のいずれかである場合に True を返す、というふうに定めてあります。</p> <table> <thead> <tr> <th> Numeric_Type </th> <th> 説明 </th> <th> 例 </th> </tr> </thead> <tbody> <tr> <td> <strong>Decimal</strong> </td> <td> 十進法 (0～9) で使われる基本的な数字 </td> <td> U+0030～U+0039（アラビア数字 "0"～"9"）<br/>U+0660～U+0669（<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%E9%A5%D3%A5%A2%B8%EC">アラビア語</a>の数字） </td> </tr> <tr> <td> <strong>Digit</strong> </td> <td> 数字として機能するが、十進法の桁として直接使用されない特殊な数字 </td> <td>U+2070（上付きゼロ "⁰"）<br/>U+2460（丸付き数字 "①"）</td> </tr> <tr> <td> <strong>Numeric</strong> </td> <td> それ以外の数値を表す文字。整数や分数、負の数など幅広い数値が含まれる </td> <td> U+2155（1/5の分数 "⅕"）<br/>U+4E00（漢数字 "一"） </td> </tr> <tr> <td> None </td> <td> 上記に該当しない文字 </td> <td> U+0041（<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%E9%A5%C6%A5%F3%CA%B8%BB%FA">ラテン文字</a> "A"）<br/>U+3042（ひらがな "あ"） </td> </tr> </tbody> </table> <h4 id="実際に数詞の-Numeric_Type-を見てみる">実際に数詞の Numeric_Type を見てみる</h4> <p>では、これをふまえて、「兆」「垓」を含む日本語の数詞の Numeric_Type をまとめてデータベース<sup id="fnref:3"><a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fn:3" rel="footnote">3</a></sup> で確認してみましょう。</p> <table> <thead> <tr> <th> 文字 </th> <th> <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> </th> <th> Numeric_Type </th> <th> str.isnumeric() </th> </tr> </thead> <tbody> <tr> <td> 万 </td> <td> U+4E07 </td> <td> <strong>Numeric</strong> </td> <td> <strong>True</strong> </td> </tr> <tr> <td> 億 </td> <td> U+5104 </td> <td> <strong>Numeric</strong> </td> <td> <strong>True</strong> </td> </tr> <tr> <td> 兆 </td> <td> U+5146 </td> <td> <strong>Numeric</strong> </td> <td> <strong>True</strong> </td> </tr> <tr> <td> 京 </td> <td> U+4EAC </td> <td> <strong>Numeric</strong> </td> <td> <strong>True</strong> </td> </tr> <tr> <td> 垓 </td> <td> U+5793 </td> <td> None </td> <td> False </td> </tr> <tr> <td> 𥝱 </td> <td> U+25771 </td> <td> None </td> <td> False </td> </tr> <tr> <td> 穣 </td> <td> U+7A63 </td> <td> None </td> <td> False </td> </tr> <tr> <td> 溝 </td> <td> U+6E9D </td> <td> None </td> <td> False </td> </tr> <tr> <td> 澗 </td> <td> U+6F97 </td> <td> None </td> <td> False </td> </tr> <tr> <td> 正 </td> <td> U+6B63 </td> <td> None </td> <td> False </td> </tr> <tr> <td> 載 </td> <td> U+8F09 </td> <td> None </td> <td> False </td> </tr> <tr> <td> 極 </td> <td> U+6975 </td> <td> None </td> <td> False </td> </tr> </tbody> </table> <p>すると確かに、「兆」は Numeric_Type=Numeric に分類されている一方、「垓」は分類されていないことがわかります。これが、<a class="keyword" href="https://d.hatena.ne.jp/keyword/Python">Python</a> の str.isnumeric() メソッドが「兆」と「垓」で異なる結果を返すことへの直接的な理由です！</p> <p>……しかしながら、上の表を見ていると、新たに一つの疑問が沸き上がってきます。なぜ、<strong><a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> は「垓」以上の数詞に Numeric_Type を割り当てていない</strong>のでしょうか？この謎を解くため、<a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> の数詞の扱いについてもう少し掘り下げていきます。</p> <p></p><fieldset style="padding: 8px 15px; border: 2px solid #6699CC; border-radius: 10px; -moz-border-radius: 10px; -webkit-border-radius: 10px;"> <legend><span style="font-size: 15px; color: #6699CC; font-weight:bold;"> Coffee break ☕ <a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>の扱いが変わった？ </span> </legend> すこし面白いのは<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>の扱いです。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>(U+4EAC) は、<a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> 15.1 で Numeric_Type が None から Numeric に変更されました。この変更が <a class="keyword" href="https://d.hatena.ne.jp/keyword/Python">Python</a> 3.13 から取り入れれられたため<sup id="fnref:4"><a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fn:4" rel="footnote">4</a></sup>、これ以降のバージョンで <code>"京".isnumeric()</code> が True を返すようになりました。 <pre class="code lang-python" data-lang="python" data-unlink=""><span class="synComment"># Python 3.12 以前なら False</span> <span class="synComment"># Python 3.13 以降なら True</span> <span class="synIdentifier">print</span>(<span class="synConstant">"京"</span>.isnumeric()) </pre> <p></p></fieldset> <h3 id="京と垓を分けた-Unicode-の判断を探る"><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>と「垓」を分けた <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> の判断を探る</h3> <p>現行の <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> は<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>までの数詞に Numeric_Type を付与しているのにも関わらず、<strong>「垓」以上の数詞には付与していません</strong>。この線引きは、どのような基準で決まったのでしょうか？ それを知るためにも、まずは <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> における漢字と Numeric_Type の関係を知っておく必要があります。</p> <h4 id="漢字の-Numeric_Type-を決める仕組み">漢字の Numeric_Type を決める仕組み</h4> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> の漢字（CJK 統合漢字）に関する情報は、UCD とは別の <strong><a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> Han Database (Unihan)</strong><sup id="fnref:5"><a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fn:5" rel="footnote">5</a></sup> というデータベースに収録されています。このデータベースには、各漢字の読みや意味、部首だけでなく、数値に関する情報も格納されています。</p> <p>Unihan には kPrimaryNumeric という項目があり、ここにはその漢字が表す数値（たとえば「万」は10⁴）が定義されています。 ある漢字に kPrimaryNumeric が付与されると、それに対応して UCD で Numeric_Type=Numeric が設定される、つまりその漢字が <strong>「数を表す文字」として扱われる</strong>仕組みになっています。</p> <p></p><fieldset style="padding: 8px 15px; border: 2px solid #6699CC; border-radius: 10px; -moz-border-radius: 10px; -webkit-border-radius: 10px;"> <legend><span style="font-size: 15px; color: #6699CC; font-weight:bold;"> Coffee break ☕ Unihan と Numeric_Type </span> </legend> 漢字に Numeric_Type を付与する仕組みは、実際はもう少しいろいろあります。Unihan には kPrimaryNumeric の他にも <ul> <li>kAccountingNumeric: 領収書などで使われる<strong>「壱」「弐」「参」</strong>などの文字</li> <li>kOtherNumeric: 数字として扱うのが一般的でない<strong>「幺」「㠪」</strong>などの文字</li> </ul> <p>などの数値に関するフィールドがいくつかあり、これらのどれかが設定されている場合に Numeric_Type=Numeric が付与される、という仕組みになっています。 </p></fieldset> <h4 id="京と垓の境界線L222-223-提案と-Unicode-技術委員会の判断"><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>と「垓」の境界線：L2/22-223 提案と <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> 技術委員会の判断</h4> <p>つい最近の <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> 15.0（2022 年 9 月制定）まで、「万」「億」「兆」までが Numeric_Type を持つ数詞として扱われ、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>「垓」以降の数詞は Numeric_Type が付与されていませんでした。</p> <p>ここでターニングポイントとなるのが、2022 年 10 月に <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> 技術委員会 (<a class="keyword" href="https://d.hatena.ne.jp/keyword/UTC">UTC</a>) に提出された <strong>L2/22-223</strong><sup id="fnref:6"><a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fn:6" rel="footnote">6</a></sup> という提案です。L2/22-223 は、Unihan の数値フィールドに関する様々な修正を提案しています。</p> <p>特にその中で、<strong><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>以上の数詞（京、垓、𥝱、穣、溝、澗）など文字</strong> にも日本語で数値としての用例があることから、kPrimaryNumeric プロパティを追加する、すなわち<strong>新たに Numeric_Type を付与する</strong>ことを提案しているのです！ 下の表の太字は、実際に L2/22-223 で追加が提案された kPrimaryNumeric の値です。</p> <table> <thead> <tr> <th> 文字 </th> <th> <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> </th> <th> kPrimaryNumeric（提案は太字） </th> </tr> </thead> <tbody> <tr> <td> 兆 </td> <td> U+5146 </td> <td> 10¹², <strong>10⁶</strong> <a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#f-3d6c48f0" id="fn-3d6c48f0" name="fn-3d6c48f0" title="中国やベトナムで 106 を「兆」と書く慣習があり、現在でも中国本土で SI 接頭辞 106 を表す文字として「兆」を使うようです。">*2</a> </td> </tr> <tr> <td> 京 </td> <td> U+4EAC </td> <td> <strong>10¹⁶</strong> </td> </tr> <tr> <td> 垓 </td> <td> U+5793 </td> <td> <strong>10²⁰</strong> </td> </tr> <tr> <td> 𥝱 </td> <td> U+25771 </td> <td> <strong>10²⁴</strong> </td> </tr> <tr> <td> 穣 </td> <td> U+7A63 </td> <td> <strong>10²⁸</strong> </td> </tr> <tr> <td> 溝 </td> <td> U+6E9D </td> <td> <strong>10³²</strong> </td> </tr> <tr> <td> 澗 </td> <td> U+6F97 </td> <td> <strong>10³⁶</strong> </td> </tr> </tbody> </table> <p>そして、この L2/22-223 提案をとりまとめた <a class="keyword" href="https://d.hatena.ne.jp/keyword/UTC">UTC</a> の CJK &amp; Unihan 作業部会も、<a class="keyword" href="https://d.hatena.ne.jp/keyword/UTC">UTC</a> に対して上表のすべてを受け入れるよう勧告しました<sup id="fnref:7"><a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fn:7" rel="footnote">7</a></sup>。</p> <p>しかしながら、最終的な <a class="keyword" href="https://d.hatena.ne.jp/keyword/UTC">UTC</a> での議論の結果<sup id="fnref:8"><a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fn:8" rel="footnote">8</a></sup>、「兆」の 10⁶ と<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>の 10¹⁶ のみが <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> 15.1 に追加され、他の数詞への kPrimaryNumeric 付与は見送られることとなりました。この決定により、<strong><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>(U+4EAC) が数値として扱われる最後の文字として認められ</strong>、それ以上の数詞（垓、𥝱など）は対象外となってしまいました。</p> <blockquote><p>[173-A45] Action Item for John Jenkins, CJK: Apply the adjustments to the kAccountingNumeric, kOtherNumeric, and kPrimaryNumeric properties, based on document L2/22-223, as amended in Section 11 of document L2/22-247, and <strong>excluding any property values greater than that for U+4EAC</strong>, for <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> Version 15.1.</p></blockquote> <h4 id="結局なぜ京だけが追加されたのか">結局、なぜ<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>だけが追加されたのか？</h4> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>までが採用された顛末について、公開資料から読み取れるのはここまでです。しかし、これらの記録を読んでも、具体的に「なぜ『垓』以降が除外されたのか？」という理由は記されていません。</p> <p>そこで、この疑問を解消するために、<a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> の専門家であり、先ほどの勧告を行った CJK &amp; Unihan 作業部会の議長でもある <strong><a class="keyword" href="https://d.hatena.ne.jp/keyword/Ken%20Lunde">Ken Lunde</a></strong> 博士に直接問い合わせを行いました。氏の返信によれば、<strong><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>(10000000000000000) より上の数詞が除外された理由は、オーバーフローの懸念にある</strong>とのことです。以下は博士からの返信の引用です：</p> <p></p><blockquote class="twitter-tweet" data-conversation="none" data-lang="ja"><p dir="ltr" lang="en">See Consensus 173-C11 from <a href="https://twitter.com/hashtag/UTC173?src=hash&amp;ref_src=twsrc%5Etfw">#UTC173</a>, along with the associated action items, specifically 173-A45. Summary: Any <a class="keyword" href="https://d.hatena.ne.jp/keyword/value">value</a> over 10000000000000000 was explicitly excluded due to overflow concerns. <a href="https://t.co/4mlIljLhhl">https://t.co/4mlIljLhhl</a></p>— <a class="keyword" href="https://d.hatena.ne.jp/keyword/Ken%20Lunde">Ken Lunde</a> 小林剣 (@ken_lunde) <a href="https://twitter.com/ken_lunde/status/1857834598178370041?ref_src=twsrc%5Etfw">2024年11月16日</a></blockquote> <script async="" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script> <p>このような判断が行われた背景には、<a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> が幅広いシステムや環境で採用されていることが影響しています。オーバーフローのリスクを抱える値を Numeric_Type に含めると、数値処理を行う多くの実装に影響を及ぼす可能性がある、という判断がなされたと考えることができます。</p> <p>実際、64 bit 符号なし整数型が表現できる 0～2⁶⁴ -1（およそ 1.8×10¹⁹）の上界は<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>(10¹⁶) と「垓」(10²⁰) の間に位置します。さらに、一部のシステムでは数値を倍精度<a class="keyword" href="https://d.hatena.ne.jp/keyword/%C9%E2%C6%B0%BE%AE%BF%F4%C5%C0%BF%F4">浮動小数点数</a>型で表現しますが、この型で安全に整数を表現できる上限 <a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#f-7815dffe" id="fn-7815dffe" name="fn-7815dffe" title="JavaScript の Number.MAX_SAFE_INTEGER のことだと思ってください。">*3</a> は約 9×10¹⁵ です。この範囲を超える<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>(10¹⁶) が Numeric_Type を持つのは、この制約を直接反映したものではないかもしれませんが、それでも比較的小さな値として許容された可能性はあります。</p> <p>あくまで推測ですが、128 bit 整数や任意精度演算が一般的になるような環境が普及すれば、「垓」以降の数詞にも Numeric_Type が付与される可能性があるかもしれません。たとえば、128 bit 符号なし整数を使えば、およそ 3.4×10³⁸ までの値を安全に表現できます。この範囲なら「澗」(10³⁶) も含めることができます。<a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> における数詞の扱いも変わっていくには、すなわち <a class="keyword" href="https://d.hatena.ne.jp/keyword/Python">Python</a> の <code>str.isnumeric()</code> が「垓」以降の数詞を数値として扱うようになるには、さらなる計算機環境の進化を待つ必要があるかもしれません。</p> <h3 id="まとめ">まとめ</h3> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/Python">Python</a> の <code>str.isnumeric()</code> メソッドは、文字列内のすべての文字が「数を表す文字」であるかを判定しますが、<code>"兆"</code> には True、<code>"垓"</code> には False を返します。この理由は、<a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> の Numeric_Type プロパティが「垓」以上の数詞には付与されていないことにありました。</p> <p>さらにその理由を探ると、「垓」～「澗」に対する <a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> の数値フィールド修正の提案があったものの、オーバーフローのリスクを懸念して<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A1%D6%B5%FE%A1%D7">「京」</a>までの数詞のみが採用されたことがわかりました。</p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> のプロパティ設定には文字の意味以上に、技術的制約など多様な観点から仕様が検討されているのです。</p> <h3 id="謝辞">謝辞</h3> <p>本記事の執筆にあたり、<a href="https://x.com/ken_lunde">Ken Lunde</a> 博士から貴重な情報提供をいただきました。特に、<a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> の数値扱いに関する技術的な背景についての理解を深めることができましたことに感謝しています。また、<a class="keyword" href="https://d.hatena.ne.jp/keyword/Unicode">Unicode</a> 議事録の<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%B5%A1%BC%A5%D9%A5%A4">サーベイ</a>などに、幅広く助力していただいた <a href="https://x.com/hakatashi">hakatashi</a> 氏にもここに謝意を表します。</p> <h3 id="ゴママヨコーナー">ゴママヨコーナー</h3> <p>気軽に読める記事を目指していたのに、すごくまじめな内容になってしまったので、ゴママヨコーナーで中和したいと思います。</p> <ul> <li>「垓」以上 ←⁉</li> <li>Numeric_Type プロパティ ←⁉</li> </ul> <p>他に見つけたらぜひ教えてください。</p> <div class="footnotes"> <hr/> <ol> <li id="fn:1"> <a href="https://www.unicode.org/reports/tr44/">Unicode® Standard Annex #44 - Unicode Character Database</a>、参照日: 2024-11-17<a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fnref:1" rev="footnote">↩</a></li> <li id="fn:2"> <a href="https://docs.python.org/3.14/library/stdtypes.html#str.isnumeric">Python documentation - Built-in Types</a>、参照日: 2024-11-17<a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fnref:2" rev="footnote">↩</a></li> <li id="fn:3"> <a href="https://www.unicode.org/Public/16.0.0/ucd/extracted/DerivedNumericType.txt">Unicode Character Database - Numeric_Type</a>、参照日: 2024-11-17<a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fnref:3" rev="footnote">↩</a></li> <li id="fn:4"> <a href="https://docs.python.org/3/whatsnew/3.13.html#unicodedata">What's New in Python 3.13 - unicodedata</a>、参照日: 2024-11-17<a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fnref:4" rev="footnote">↩</a></li> <li id="fn:5"> <a href="https://www.unicode.org/reports/tr38/">Unicode® Standard Annex #38 - Unicode Han Database (Unihan)</a>、参照日: 2024-11-17<a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fnref:5" rev="footnote">↩</a></li> <li id="fn:6"> <a href="https://www.unicode.org/L2/L2022/22223-unihan-numeric.pdf">L2/22-223: Proposed Updates and Expansions of Unihan Numeric Fields</a>、参照日: 2024-11-17<a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fnref:6" rev="footnote">↩</a></li> <li id="fn:7"> <a href="https://www.unicode.org/L2/L2022/22247-cjk-unihan-group-utc173.pdf">L2/22-247: CJK &amp; Unihan Group Recommendations for UTC #173 Meeting</a>、参照日: 2024-11-17<a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fnref:7" rev="footnote">↩</a></li> <li id="fn:8"> <a href="https://www.unicode.org/L2/L2022/22241.htm#173-A45">UTC #173 Minutes</a>、参照日: 2024-11-17<a href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fnref:8" rev="footnote">↩</a></li> </ol> </div> <div class="footnote"> <p class="footnote"><a class="footnote-number" href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fn-3ca21f31" id="f-3ca21f31" name="f-3ca21f31">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">つまり、文字列全体が数の表現として正しいかとは無関係です。たとえば、"123.45".isnumeric() は False、"兆兆".isnumeric() は True を返します。</span></p> <p class="footnote"><a class="footnote-number" href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fn-3d6c48f0" id="f-3d6c48f0" name="f-3d6c48f0">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">中国や<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%D9%A5%C8%A5%CA%A5%E0">ベトナム</a>で 10⁶ を「兆」と書く慣習があり、現在でも中国本土で SI 接頭辞 10⁶ を表す文字として「兆」を使うようです。</span></p> <p class="footnote"><a class="footnote-number" href="https://shmug.hatenablog.com/entry/2024/12/01/000000#fn-7815dffe" id="f-7815dffe" name="f-7815dffe">*3</a><span class="footnote-delimiter">:</span><span class="footnote-text"><a class="keyword" href="https://d.hatena.ne.jp/keyword/JavaScript">JavaScript</a> の Number.MAX_SAFE_INTEGER のことだと思ってください。</span></p> </div>