昨日の日記の読者から、ならば文字情報基盤MJ008683とMJ030252を漢字コード上で見分けるにはどうすべきか、という御質問をいただいた。これらの文字はいずれもU+5668「器」に統合されているので、どうしても見分けたい場合には、MJ008683を<U+5668 U+E0102>で、MJ030252を<U+5668 U+E0103>で書くべくIVS環境を整えるのが、IPAやCITPCがすすめてきた手法だ。ただ、話がヤヤコシイのは、Adobeの手法は<U+5668 U+E0100>と<U+5668 U+E0101>だったし、それ以前の台湾と日本ならU+20F96「𠾖」とU+FA38「器」で見分ける技も準備されていて、しかもU+FA38は<U+5668 U+FE00>へ変化したという黒歴史だ。まあ、歴史は歴史で覆しようがないので、私(安岡孝一)個人としては全部サポートするしかないと思うの

『日本・中国・台湾・香港・韓国の常用漢字と漢字コード』の読者から、文字情報基盤のMJ018123とMJ056839を漢字コード上で見分けるにはどうすべきか、という御質問をいただいた。まあ、環境にもよるのだが、今ならIVSを使うのが妥当だろう。これらの文字は、いずれもU+76F4「直」に統合されているので、どうしても見分けたい場合には、MJ018123を<U+76F4 U+E0102>で、MJ056839を<U+76F4 U+E0104>で書くべく環境を整えるのが、IPAやCITPCがすすめてきた手法だ。それが出来ない場合は、フォント切り替えという手法も有り得るとは思うが、私(安岡孝一)個人としては、フォント切り替えよりIVSを頑張る方が「まだまし」だと思う。

Transformers 4.22がSwin Transformer V2をサポートしたので、戸籍統一文字の総画数を元に、画像中の漢字に対して画数を求める画像分類モデルを、試作してみることにした。Google Colaboratory (GPU)だと、以下のような感じ。 !pip install 'transformers>=4.22' import os,glob url="https://github.com/KoichiYasuoka/kosekimoji-strokes" d=os.path.basename(url) !test -d $d || git clone --depth=1 $url img=glob.glob(d+"/*/*.png") lid={str(i):i for i in range(65)} class ImageDataset(object): def

台風       NOUN <╗           compound(複合) 14号       NUM  ═╝═╗<╗       nmod(体言による連体修飾語) の         ADP  <══╝ ║       case(格表示) 72時間以内 NOUN ═╗<══║═══╗   obl(斜格補語) に         ADP  <╝   ║   ║   case(格表示) 暴風域     NOUN ═╗═══╝<╗ ║   obl(斜格補語) に         ADP  <╝     ║ ║   case(格表示) 入る       VERB ═══════╝═╝<╗ acl(連体修飾節) 確率       NOUN ═══════════╝ root(親)

昨日および2017年12月26日の日記の読者から、戸籍統一文字559970「⿺辶鳥」はUCSに追加されるのか、という趣旨の質問をいただいた。私(安岡孝一)の知る限り、デジタル庁からも法務省からも、そういう話は出ていない。デジタル庁が考える文字情報基盤の「整備」にも書いたが、もう一度、地方公共団体情報システムデータ要件・連携要件標準仕様書【第1.0版】を見てみよう。 (2) 文字符号化方式 各標準準拠システムの間の連携のための符号化方式については、UTF-8とする。 なお、標準準拠システム内の符号化方式はUTF-8またはUTF-16とする。 (3) 外字の取扱い 標準準拠システムを導入する前に地方公共団体がそれぞれ独自に作成した文字、いわゆる「外字」については、戸籍システムにおいて当該「外字」を文字情報基盤として整備された文字と同定した文字を利用することにより、他の標準準拠システムは、当該「

私(安岡孝一)が昨日の日記に書いた「JIS X 0213に縮退するなんて無理です」に対し、現実の社会では既に縮退がおこなわれているのだから大丈夫なのではないか、という趣旨の御意見をいただいた。地方公共団体情報システムデータ要件・連携要件標準仕様書【第1.0版】の 氏名等について、文字情報基盤として整備された文字からJIS X 0213:2012の文字への縮退は、デジタル庁がMJ縮退マップを改良して作成した自治体用縮退マップを用いて行う。ただし、縮退した文字について、本人が希望する場合には、自治体用縮退マップにより縮退した文字とは異なるJIS X 0213:2012の文字とすることができる。 を横目に、登記統一文字01009670を含む神社(金「⿱刀比」羅神社)について、少し見てみよう。私の見る限り、これらの神社では「金刀比羅神社」への縮退や「こんぴら神社」への縮退が、現実におこわれている。

昨日の日記に対して、デジタル庁は文字情報基盤を拡張する心算なのではないか、との御指摘をいただいた。地方公共団体情報システムデータ要件・連携要件標準仕様書【第1.0版】を、もう少し読んでみよう。 標準準拠システムを導入する前に地方公共団体がそれぞれ独自に作成した文字、いわゆる「外字」については、戸籍システムにおいて当該「外字」を文字情報基盤として整備された文字と同定した文字を利用することにより、他の標準準拠システムは、当該「外字」を利用しない。仮に、「外字」を文字情報基盤の文字と同定する取組みを行った上でも、なお「外字」を利用せざるを得ない場合においては、戸籍システムにおいて文字情報基盤の文字とは別の文字コード（デジタル庁が指定したものに限る。以下同じ）に対応させたものを利用することにより、他の標準準拠システムは、当該「外字」を利用しない*。 文字情報基盤の文字セット及び文字情報基盤の文字と

戸籍・住記等システム間において氏名等を情報連携する場合には、文字情報基盤として整備された文字とする。 住民記録システムと戸籍・住記等システム以外の標準準拠システムとの間において氏名等を情報連携する場合や、戸籍・住記等システム以外の標準準拠システム間において氏名等を情報連携する場合は、JIS X 0213:2012の文字とする。 いや、それはマズイ。いくらなんでもJIS X 0213:2012や文字情報基盤では、個人の氏名のみならず法人名が書ききれない。JIS X 0213は、そもそも法人名を対象としていなかったし、文字情報基盤も登記ガラミの文字を対象としていないのは、以前、私(安岡孝一)の日記にも書いたとおりだ。これ、法人住民税とか固定資産税のシステムだと、どう考えても無理なんだけど、と思いつつ、前後を読んでみると、さらに恐ろしいことが書いてあった。 戸籍・住記等システム（戸籍システム、戸

『青空文庫DeBERTaモデルによる国語研長単位係り受け解析』にも書いたのだが、私(安岡孝一)が研究代表者を務める学際大規模情報基盤共同利用・共同研究拠点公募型共同研究『単語間に区切りのない書写言語における係り受け解析エンジンの開発』では、mdxを用いてBERT/RoBERTa/DeBERTaモデルの研究開発をおこなっている。ところが先週くらいから、このmdxに全くアクセスできなくなっているのだ。 8月23日（火）より、sshを用いた仮想マシンへの接続が不安定となる事象が発生しております。 現在原因を調査・対応中です。 復旧いたしましたらこちらのサイト及びユーザポータルにてお知らせいたします。 利用者の皆様には大変ご不便、ご迷惑をおかけして申し訳ございません。 まあ、ssh以外のアクセス手段を準備しておかなかった私も悪いのだが、ヨソのマシンに妙な「穴」を開けておくのはマズイかな、と思ったの

昨日の日記の読者から、「私は腹が立つた」は「象は鼻が長い」と同じ構造なのか、という趣旨の質問をもらった。昨日と同様に、nsubj:outerで書いてみよう。 象   NOUN ═╗<══╗ nsubj:outer(主語[外側]) は   ADP  <╝   ║ case(格表示) 鼻   NOUN ═╗<╗ ║ nsubj(主語) が   ADP  <╝ ║ ║ case(格表示) 長い ADJ  ═══╝═╝ root(親) 確かに、「象は鼻が長い」なら「鼻が長い」をPredicate Clauseとみなすのも、アリだと思う。ただ、もし本当にPredicate Cluaseであるならば、Universal Dependenciesの新しいルールによって倒置文「鼻が象は長い」は、以下のように表すことになる。

2021年8月6日の日記に書いた「私は腹が立つた」だが、Universal Dependenciesに新たに導入されたnsubj:outerを使うべきだろうか、と思い悩み始めた。deplacy風に書くと、こんな感じ。 私   PRON ═╗<══╗ nsubj:outer(主語[外側]) は   ADP  <╝   ║ case(格表示) 腹   NOUN ═╗<╗ ║ nsubj(主語) が   ADP  <╝ ║ ║ case(格表示) 立つ VERB ═╗═╝═╝ root(親) た   AUX  <╝     aux(動詞補助成分)

知識plusにも書いたのだけど、QWERTY配列に対する誤解は、あまりに多い。とりあえず、橋本毅彦の『〈標準〉の哲学』(講談社, 2002年3月)から、以下の部分を取り上げてみることにする。 ショールズは、自分の作りたてのタイプライターでは、キーを素早く叩くと、キーの動きを印字に伝える金属棒(タイプバー)がからまってしまうことに気づいた。何とかタイプバーがからまないような工夫はないものか？　そこでショールズは、キーの配列を変え、続けて打たれるようなキーがキーボード上に離れてあるよう配列し直した。その結果、キーを叩くスピードは遅くなったが、タイプバーはからまないようになった。その配列こそが、現在の標準配列として生き残ることになったQWERTYの配列だったのである。 アルファベット2文字の組み合わせのうち、英語では「th」を続けて打つことが最も多いのだが、この2字はQWERTY配列では非常に近

『新しい常用漢字と人名用漢字』(三省堂、2011年3月)の読者から、本日付けのasagei MUSE『【ちむどんどん】記事への投書にも誤りが！新聞社が舞台とは思えない時代考証ミスとは？』を読んでみてほしい、との御連絡をいただいた。 「愛が目にした3通目の投書には『鎌田侑由子』という差出人の名前が書き添えてありました。他の投書にも名前の書かれているものが多く、制作側は多くの仮名を考えたのでしょう。しかしここに問題があったのです。というのも侑由子の『侑』は、1981年10月1日から人名用漢字として使えるようになった漢字。しかし物語は1978年（昭和53年）なのですから、侑由子さんから投書が来ることは有り得ないのです」 えっと、私(安岡孝一)自身は、昨日の『ちむどんどん』第67話を見ていないので、迂闊なことは書けないのだが、1978年のタイミングだと沖縄出身の人だったりしないのだろうか。あるいは

「戸籍法等の改正に関する中間試案」に関する意見募集が始まったので、ざっと資料を見直していたのだが、小書きのカナをどうするのかについては、やはり議論が煮詰まっておらず、どうも困った感じである。戸籍法等の改正に関する中間試案の補足説明の「【乙案】氏名を片仮名で表記したもの」に関する部分を見てみよう。 【乙案】は、戸籍の記載事項としての表記を片仮名と定めるものである。部会では、片仮名表記は、平仮名表記と比較して表音が容易であり、外来語の表記に違和感を覚えにくいという特徴があるとの指摘や、金融機関においては、データ通信量等の観点から、半角カナが用いられているとの指摘があった。 金融機関において使われているのは、いわゆる「半角カナ」(JIS X 0201のカタカナ)ではなく、旧JIS C 0803(1987年にJIS X 6001へ規格番号変更後1994年に廃止)のカタカナだったりする。そのため、小

川幡太一の『CSSにおける文字とフォント』を聞きながら思ったのだが、結局のところ日本は、Unicodeにおける漢字統合に、いまだ納得していないということなのだろう、と、今更ながら思いあたった。すなわち「神」と「神」に、同じ文字コードが割り当てられているのが、我慢ならないのだ。その結果、「U+795E」と「U+FA19」とで分けてみたり、「U+795E U+E0101」と「U+795E U+E0100」とで分けてみたり、何らかの方法で分けたい、ということになってしまっているわけだ。 でも、単に「分けたい」と言ってもJTC1/SC2/WG2は聞いてくれなかったので、JIS X 0213を理由にしてみたり、人名用漢字を理由にしてみたり、旧字による出版印刷を理由にしてみたり、戸籍統一文字を理由にしてみたりしてしまった。その結果「分ける」理由によって、異なるアプローチが起こってしまった。互換漢字とか

『人名用漢字の新字旧字』第200回「新」と「𣂺」の読者から、Wikipediaの「新の本字」を読んでみてほしい、との御連絡をいただいた。読んでみたのだが、ノッケからわけのわからないことが書いてある。 𣂺（𣂺）は、漢字「新」の本字 [1] （本来の字体）である。旧字 [2] とも。ただし（新字体に対する）旧字体ではなく、それより千数百年は古い時代の字体である [3] 。 『人名用漢字の新字旧字』では「常用漢字(1981年版)字体が新字、それ以外は旧字」という「原則」を、私(安岡孝一)なりに立てていたりする。まあ「原則」なので、あちこち「例外」が出たりもするのだが、それでも「旧字」が複数ありうるというのは、連載のかなり早いタイミングで示したはずだ(第8回「闘」と「鬪」と「鬭」参照)。だとすると、ここでいう「旧字体ではなく」って、一体どういう意味なんだろ？ 常用漢字ではなく、人名用漢字に含

gojiteji/byt5-small-ain-jpn-mtという言語モデルがリリースされているのを見つけた。名前からすると、ByT5によるアイヌ語→日本語自動翻訳モデルのようだ。試しに使ってみよう。 $ pip3 install -U transformers --user $ python3 >>> from transformers import AutoTokenizer,AutoModelForSeq2SeqLM,TranslationPipeline >>> tkz=AutoTokenizer.from_pretrained("gojiteji/byt5-small-ain-jpn-mt") >>> mdl=AutoModelForSeq2SeqLM.from_pretrained("gojiteji/byt5-small-ain-jpn-mt") >>> pipeline=T

一方で、fugashi(というかBertJapaneseTokenizer)をトークナイザに使うと、オプションにreturn_offsets_mapping=Trueが効かないため、11月26日の日記で書いたような手法が適用できない。うーん、国語研短単位をサポートするようなPreTrainedTokenizerFastを、何とかデッチ上げるしかないかな。 元旦の宿題に、PreTrainedTokenizerFastとまではいかなかったものの、何とかBertJapaneseTokenizerFastっぽいクラスを、pytokenizationsでデッチ上げてみた。Google Colaboratoryで動かしてみよう。 !pip install transformers pytokenizations fugashi unidic_lite from transformers import

12月23日の日記の手法を拡張して、青空文庫(2.37億字)をもとにroberta-base-japanese-aozora-charを作ってみた。12層・隠れサイズ768・12ヘッド・トークン幅512とした上で、7772556文3億字(元データ2.37億字＋異体字増量分0.64億字)をNVIDIA A100-SXM4-40GBで728679ステップ(32バッチ)学習させたところ、19時間11分かかってしまった。とりあえず、Google Colaboratoryで使ってみよう。 !pip install transformers from transformers import AutoTokenizer,AutoModelForMaskedLM,FillMaskPipeline tokenizer=AutoTokenizer.from_pretrained("KoichiYasuoka/

自然言語処理Advent Calendar 2021を見に行ってみたところ、今年は閑古鳥が鳴いている。もはや、自然言語処理ブームが過ぎ去った、ということなのかもしれないが、それでも、今年発表された日本語係り受け解析器のうち、私(安岡孝一)の目に止まったものを「総ざらえ」してみよう。 ja-ginza-electra transformers-ud-japanese-electra-base-ginzaをベースにした日本語係り受け解析器で、GiNZAの最新モデルである。単語間係り受けのみならず、文節間係り受けもサポートしており、日本語係り受け解析器としてはダントツの性能(私見)。 SuPar-UniDic 形態素解析部に10種類のUniDicを、係り受け解析部に21種類のBERTモデルを、つなぎ換えて楽しむ日本語係り受け解析器。どれをどう繋げば性能が出るのかわかりにくいが、使い方は3月12日