パスワードを忘れた? アカウント作成

yasuokaさんのトモダチの日記みんなの日記も見てね。 今週も投票をしましたか?

15816205 journal
地球

yasuokaの日記: DIN 476におけるB判の起源

日記 by yasuoka

Friedrich Wilhelm Ostwaldの『Sekundäre Weltformate』(Brücke, 1912年)には、A-Reihe、B-Reihe、C-Reiheとして、以下の表が掲載されている。

             A               B                C
   I    1   ×  1,41    1,06×  1,50     1,10×  1,56
  II    1,41×  2       1,50×  2,13     1,56×  2,20
 III    2   ×  2,83    2,13×  3        2,20×  3,12
  IV    2,83×  4       3   ×  4,25     3,12×  4,40
   V    4   ×  5,66    4,25×  6        4,40×  6,25
  VI    5,66×  8       6   ×  8,50     6,25×  8,80
 VII    8   × 11,30    8,50× 12        8,80× 12,50
VIII   11,30× 16      12   × 17       12,50× 17,70
  IX   16   × 22,60   17   × 24       17,70× 25
   X   22,60× 32      24   × 34       25   × 35,40
  XI   32   × 45,30   34   × 48       35,40× 50
 XII   45,30× 64      48   × 68       50   × 70,70
XIII   64   × 90,50   68   × 96       70,70×100
 XIV   90,50×128      96   ×136      100   ×141,40
  XV  128   ×181     136   ×192      141,40×200
 XVI  181   ×256     192   ×272      200   ×283
XVII  256   ×362     272   ×384      283   ×400

単位がセンチメートルなのでわかりにくいが、OstwaldのC-Reiheは、DIN 476「Papierformate」(1922年8月18日制定)のB判とほぼ一致する。ただし、この紙のサイズは、フランス・ベルギー・レナニア(ラインラント)・仏領ギアナ・仏領チュニジアなどでは既に使用されており、古くはフランス共和暦13 Brumaire an VII (1798年11月3日)公布の法律2136号「Loi sur le timbre」に遡る。フランスでは「Grand papier」(0.3536m×0.5000m)「Petit papier」(0.2500m×0.3536m)「Demi-feuille」(0.2500m×0.1768m)は、18世紀末から公式に使用されていたわけだ。

つまり、DIN 476にB判を持ち込んだのはOstwaldだが、その起源はフランスにあると考えられる。一方、DIN 476にC判を持ち込んだのもOstwaldだが、こちらは、まあ、OstwaldのA-Reihe(を多少改変した判型)だと言っていい。さて、DIN 476にA判を持ち込んだのは、誰なんだろう。

15815098 journal
バグ

yasuokaの日記: DIN 476におけるC判の起源

日記 by yasuoka

一昨日の日記に続いて、DIN 476「Papierformate」(1922年8月18日制定)の周辺を調べていたところ、『Normung in den Graphischen Gewerben』(Klimschs Jahrbuch, Bd.16 (1921/1922), S.126-132)という記事に、Walter PorstmannとFriedrich Wilhelm Ostwaldの熱き戦いが載っていた。

Den Anschuluß an das metrische System sieht Dr. Porstmann in der Flächeneinheit, dem qm als gegeben. Die sich daraus ergebende Vorzugsreihe ist die bisher als C-Reihe bezeichnete. Geheimrat Ostwald bezweifelt die Wissenschaftlichkeit bei der Ableitung der Vorzugreihe, da das Urmaß der cm sei, und das Format nicht durch Flächeneinheit, sondern durch das Verhältnis von Vielfachen der Längeneinheiten bestimmt werde. Auf Grund dieses Gedankenganges kommt Ostwald auf Reihe B (die Weltformatreihe), die er allein als Vorzugsreihe anerkennen könne. Dr. Porstmann verteidigte seine Auffassung mit so gutem Erfolg, daß die Entscheidung in seinem Sinne zu Gunsten der bisherigen C-Reihe siel unt mit 14 gegen 1 Stimme (Ostwald) beschlossen wurde, daß die Reihenfolge der Formatreihen künstig folgende ist: Reihe C (Vorzugsreihe), Reihe A, B und D. Die Reihen werden is dieser Folge zukünstig A - B - C - D bezeichnet.

私(安岡孝一)がざっと読んだ限りでは、規格策定の作業中、PorstmannはC判(フランスの「Grand registre」0.4204m×0.5946mや「Moyen papier」0.2973m×0.4204mをもとにした判型)を推していて、OstwaldはB判(1cm×1.41cmを基本とする「Weltformate」)を推していた。スッタモンダのあげく、投票の結果は14:1でPorstmannの圧勝、PorstmannのC判はA判へと格上げになり、OstwaldのB判はC判へと格下げになった、というオチのようである。この結果「Grand registre」はA2判に、「Moyen papier」はA3判になったというわけだ。ただ、DIN 476のC0判は917mm×1297mmなので、Ostwaldの「Weltformate」に出てくる90.5cm×128cmより、少しばかり大きい。C0判の面積を21/4m2に設定した結果だが、さて、そのあたりはどういう駆け引きがあったんだろ。

15812323 journal
バグ

yasuokaの日記: 日本標準規格第92号「紙ノ仕上寸法」と獨逸のオスワルド博士 4

日記 by yasuoka

A判の起源に関連して、日本標準規格第92号「紙ノ仕上寸法」(1929年12月4日決定)の周辺を調べていたところ、井上一男『規格が統一せられた紙の仕上寸法』(臺灣時報, 第176號(1934年7月), pp.73-79)に以下の記述を見つけた(p.76)。

卽ち次頁の表で我國の採用したものであつて、之は仕上り品に重心を置いたもので、此の仕上り寸法を規格で制定したものであるから、世上取扱はれるものゝ寸法が整然として來る。之は獨逸のオスワルド博士の考案で、古代美術に目覺めて居た希臘人が傳へた美學上最も優れた矩形、卽ち一對ルート二矩形を使用したのである。

Friedrich Wilhelm Ostwaldを「獨逸のオスワルド博士」と呼んでいるようだが、実のところ「次頁の表」には日本のA判とB判が書かれていて、Ostwaldとは直接関係がない。うーん、「物理学者オズワルド」にしろ「獨逸のオスワルド博士」にしろ、どういう経緯でA判と結びついたんだろう。

15809163 journal
日本

yasuokaの日記: MJ008683とMJ030252は両方とも「器」なのか

日記 by yasuoka

昨日の日記の読者から、ならば文字情報基盤MJ008683MJ030252を漢字コード上で見分けるにはどうすべきか、という御質問をいただいた。これらの文字はいずれも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>へ変化したという黒歴史だ。まあ、歴史は歴史で覆しようがないので、私(安岡孝一)個人としては全部サポートするしかないと思うのだけど、なかなか難しいんだろうなあ。

15808121 journal
日本

yasuokaの日記: MJ018123とMJ056839は両方とも「直」なのか

日記 by yasuoka

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

15800315 journal
人工知能

yasuokaの日記: Swinv2ForImageClassificationで漢字の総画数を求める画像分類モデル

日記 by yasuoka

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 __init__(self,files,label2id):
    self.files=files
    self.label2id=label2id
  __len__=lambda self:len(self.files)
  def __getitem__(self,i):
    from PIL import Image
    from torchvision.transforms.functional import to_tensor
    f=self.files[i]
    return {"pixel_values":to_tensor(Image.open(f).convert("L")),"labels":[self.label2id[f.split("/")[-2]]]}
from transformers import Swinv2ForImageClassification,Swinv2Config,DefaultDataCollator,TrainingArguments,Trainer
trainDS=ImageDataset(img,lid)
mdl=Swinv2ForImageClassification(Swinv2Config(image_size=200,num_channels=1,num_labels=len(lid),label2id=lid,id2label={i:l for l,i in lid.items()}))
arg=TrainingArguments(num_train_epochs=3,per_device_train_batch_size=32,output_dir="/tmp",overwrite_output_dir=True,save_total_limit=2)
trn=Trainer(args=arg,data_collator=DefaultDataCollator(),model=mdl,train_dataset=trainDS)
trn.train()
trn.save_model("my-kosekimoji")

GPUだと45分程度で、my-kosekimojiに画像分類モデルが出来上がる。うまく出来たら、法人番号5470001008156(金「⿱刀比」羅醬油株式会社)の商号画像(9文字)に対し、各漢字の画数を求めてみよう。

!curl -A Mozilla -L 'https://www.houjin-bangou.nta.go.jp/image?imageid=00005096' -o test.png
import torch
from PIL import Image
from torchvision.transforms.functional import to_tensor
from transformers import AutoModelForImageClassification
mdl=AutoModelForImageClassification.from_pretrained("my-kosekimoji")
e=Image.open("test.png")
w,h=e.size
with torch.no_grad():
  x=mdl(torch.stack([to_tensor(e.crop((x,0,x+h,h)).resize((200,200)).convert("L")) for x in range(0,w,h)],0)).logits
print(torch.argmax(x,axis=1).tolist())

私(安岡孝一)の手元では、以下の結果になった。

[8, 8, 19, 19, 8, 11, 6, 6, 7]

うーん、「⿱刀比」が8画、「株」が11画になってしまっていて、もう一息だ。さて、これ、教師画像を増やせば、もうちょっと精度あがるのかな。

15797025 journal
人工知能

yasuokaの日記: tiyaro.aiの考える日本語係り受け解析

日記 by yasuoka

tiyaro.aiという会社から、私(安岡孝一)の係り受け解析エンジンesuparに対して、かなりワケの分からないPull Requestが来たので、ここに晒しておくことにする。どうも、日本語係り受けモデルbert-base-japanese-uposを使ったAPIを公開したらしいのだが、係り受け解析モジュールを繋ぎ忘れているので、品詞付与までしかできない。しかも、例文が日本語ではなく英語なので、もうワケが分からない。とりあえず『Universal DependenciesとBERT/RoBERTa/DeBERTaモデルによる多言語情報処理』を示して、お取り下げ願ったのだが、どうも、あちこちでPull Request出しまくってるみたいだし、むしろリンクスパムだったのかなぁ。

15794922 journal
日本

yasuokaの日記: 「台風14号の72時間以内に暴風域に入る確率」における係り受け

日記 by yasuoka

ネットサーフィンしていたところ、「台風14号の72時間以内に暴風域に入る確率」が、妙に気になった。国語研長単位でdeplacy風に書くと、こんな感じ。

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

見事に係り受けが交差している。ただ、こういう係り受け解析が自動でおこなえる言語処理ツールは、まだ無いようだ。日本語の言語処理は難しいなぁ。

15792844 journal
人工知能

yasuokaの日記: Transformers 4.22.0とdeberta-base-japanese-aozora-ud-headによる国語研長単位係り受け解析

日記 by yasuoka

Transformers 4.22.0のリリースで、QuestionAnsweringPipelineにalign_to_words=Falseがサポートされた。これにより、6月15日の日記で示した手法が、もっと楽に動かせる。最新のTransformersをインストールしつつ、deberta-base-japanese-aozora-ud-headで係り受け解析を試してみよう。

$ pip3 install -U transformers --user
$ python3
>>> from transformers import pipeline
>>> head=pipeline(task="question-answering",model="KoichiYasuoka/deberta-base-japanese-aozora-ud-head",align_to_words=False)
>>> print(head("世界中","世界中が刮目している"))
{'score': 0.9999983310699463, 'start': 4, 'end': 7, 'answer': '刮目し'}
>>> print(head("が","世界中が刮目している"))
{'score': 0.9999953508377075, 'start': 0, 'end': 3, 'answer': '世界中'}
>>> print(head("刮目し","世界中が刮目している"))
{'score': 0.9998645782470703, 'start': 4, 'end': 7, 'answer': '刮目し'}
>>> print(head("ている","世界中が刮目している"))
{'score': 0.9999996423721313, 'start': 4, 'end': 7, 'answer': '刮目し'}

どうやらちゃんと動いているようだ。一方、Transformers 4.22.0ではhf_bucket_urlが無くなってしまったので、翌6月16日の日記の手法は使えなくなった。hf_bucket_urlをcached_fileに置き換えれば大丈夫そうなので、deberta-base-japanese-aozora-ud-headに示した使用例を、よく読んでおいてほしい。

15785200 journal
日本

yasuokaの日記: 戸籍統一文字559970「⿺辶鳥」はUCSに追加されるのか 2

日記 by yasuoka

昨日および2017年12月26日の日記の読者から、戸籍統一文字559970「⿺辶鳥」はUCSに追加されるのか、という趣旨の質問をいただいた。私(安岡孝一)の知る限り、デジタル庁からも法務省からも、そういう話は出ていない。デジタル庁が考える文字情報基盤の「整備」にも書いたが、もう一度、地方公共団体情報システムデータ要件・連携要件標準仕様書【第1.0版】を見てみよう。

(2) 文字符号化方式
 各標準準拠システムの間の連携のための符号化方式については、UTF-8とする。
 なお、標準準拠システム内の符号化方式はUTF-8またはUTF-16とする。

(3) 外字の取扱い
 標準準拠システムを導入する前に地方公共団体がそれぞれ独自に作成した文字、いわゆる「外字」については、戸籍システムにおいて当該「外字」を文字情報基盤として整備された文字と同定した文字を利用することにより、他の標準準拠システムは、当該「外字」を利用しない。仮に、「外字」を文字情報基盤の文字と同定する取組みを行った上でも、なお「外字」を利用せざるを得ない場合においては、戸籍システムにおいて文字情報基盤の文字とは別の文字コード(デジタル庁が指定したものに限る。以下同じ)に対応させたものを利用することにより、他の標準準拠システムは、当該「外字」を利用しない*。
 文字情報基盤の文字セット及び文字情報基盤の文字とは別の文字セットを合わせた文字セット(以下「文字情報基盤として整備された文字セット」という。)については、デジタル庁が法務省と協力して整備する。

ここで「文字情報基盤として整備された文字セット」を「デジタル庁が法務省と協力して整備する」と書いていて、しかも当該「文字セット」に対する「文字コード」は「デジタル庁が指定したものに限る」とまで言っているわけである。だったら、戸籍統一文字559970「⿺辶鳥」に対する「文字コード」は、デジタル庁と法務省がUCSに追加提案して、ちゃんと「UTF-8またはUTF-16」で使えるようにするというのが、「文字コード」としてのスジだと思うのだ。でも、私の知る限り、デジタル庁からも法務省からも、そういう話は出ていない。いったい、どうするつもりなんだろ。

typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...