はじめに 11月にリリース予定のFirefox57でFirefoxの拡張はWebextensionsで作られたもの以外が動かなくなります。従来の技術で作られた拡張はすべて死にます。 しばらくはabout:configでextensions.legacy.enabledをtrueにすれば動き続けると思いますが、従来のAPIに関するコードは削除される予定なので動かせる期間はそう長くはないでしょうし、そもそも正常に動かないという報告もあります。 このWebExtensionsアポカリプス(もしくはFirefoxアポカリプス)に備えるために個人的に優先度が高いアドオンのWebExtensions対応についてまとめてみました。 対応済み/対応予定 μBlock Origin:対応済み μBlock OriginはすでにWebextensionsに対応しています。Chrome版もあったので比較的移行は

Latest topics > ツリー型タブのWebExtensionsへの移行のおはなし 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « WebExtensions Migration Story of Tree Style Tab Main マルチプルタブハンドラもWebExtensionsに移行しました » ツリー型タブのWebExtensionsへの移行のおはなし - Oct 03, 2017 Here is the English version of this article. このエントリはQiitaとのクロスポストです。 2017年の8月下旬に思い立って、ツリー型タブのWebExtensions版を作り始め、去る9月26日にバージ

有理か非有理か 三元か四元か 静電単位系、電磁単位系 MKSA単位系 cgsガウス単位系 目次 有理か非有理か 三元か四元か 静電単位系、電磁単位系 静電単位系 電磁単位系 付記: 磁束密度Bと磁場H MKSA単位系 cgsガウス単位系 相対論との関係 有理か非有理か 電磁気の単位系に影響を与えるものに「有理化をするかしないか」がある。これは一見すると単なる係数の取り方の違いにも見えるけど、単位系の間の単位換算を考える上では一番ややこしくなる原因かもしれない。 まずクーロン力とクーロンの法則についての式を、有理化していない形で書くと次のようになる。 一方、同じ法則を有理化した形で書くと次のようになる。 この形で比べると有理化していない式の方が簡潔だけど、微分形で書くと、 非有理化: 有理化: となって、有理化した方が式が簡潔になる。 磁場についても、ローレンツ力とアンベールの法則を書いた時

加賀孝英さんの「米情報機関によると」を信じる青髭さん 「宇宙人から聞いた話」を真に受けてどうするのだろうか？ 加賀孝英さんがいつものどうかしている記事を出している。週刊誌記者のところになぜか世界中の情報関係者が情報リークしてくれるといった不思議な記事だ 記事題名は「米政府が裏切り外交連発の韓国を敵視　当局『トランプ氏は訪韓中、ずっと怒っていた』 」である。要は米国はボク達の国、日本を愛して欲しい。憎い韓国を敵視していて欲しいといったネトウヨ願望擦り寄り記事だ。 そして例によって都合よく情報が集まっている。憎き文大統領の傲岸無礼に宗主国米国さまが怒っているといった情報が「旧知の米情報当局関係者は、こう吐き捨てた。」「複数の米軍、米情報当局関係者から入手した情報だ。」「外務省関係者があきれて次のようにいう」と情報関係者から入手できたと主張している。 もちろん基本的には宇宙人と会話したのたぐいで

日本工業標準調査会のサイトでJIS X 0212を閲覧していたところ、妙なことに気づいた。私(安岡孝一)の手元にあるJIS X 0212規格票と、版組が違う。日本規格協会でJIS X 0212をプレビューしてもらえばわかるが、p.1に入ってる文章の量からして、全く違っているのだ。しかも4.3の表題は、本物の規格票では

JIS X 0212-1990の規格票を眺めていたところ、「黑へん」のところで妙なことに気づいた。JIS X 0212は76区の最後から77区の最初にかけて、黕・黟・黤・黬・黭・黮・黰・黲・黵・黸の「黑へん」10字を収録しているのだが、黤の「黑へん」だけ規格票でのデザインが違うのだ。規格票p.31を閲覧してもらえばわかるが、黤は「黑へん」の8画目が右上にハネあがっているのに対し、他は全て横棒だ。 どうしてこんなことになったのだろう、と、原案にあたる『印刷産業の情報処理高速化に関する調査研究報告書』のp.273をチェックしてみたところ、やはり、黤は「黑へん」の8画目が右上にハネあがっているのに対し、黕・黟・黬・黭・黮・黰・黲・黵・黸は横棒だった。もしやこれは、と思い、『大漢和辞典』をチェックしてみたところ、検字番号48117の「黑へん」は右上にハネあがっているのに対し、48057・48091

この前、関東地方のテレビニュースで、埼玉県にある「垳(がけ)」という地名が変更されそうなので反対の声があるという話を報じていました。全国でここだけにしかない地名だから保存すべき、という話です。 ウェブのニュースサイトにあるかなと思って探してみたら、例えば次のような記事がありました。 八潮市の全国唯一の地名「垳」、区画整理で消滅の危機　地元住民が保存の動き この「垳」という字は、JIS X 0208の第2水準、区点位置52-24にあります。ただ、この字は5万字を誇る「大漢和辞典」にも載っていない字です。かつて、どうしてこんな、辞書に載っていないような字がJISに入っているんだ、という疑問(というか批判)がありました。 しかし、JIS X 0208の1997年改正によって、この埼玉県の地名からきていることが明らかになりました。漢和辞典は主として漢文を読むための辞典であって、日本で作られた漢字(

JIS X 0208の幽霊漢字についてTwitterで興味深いツイートを見ました。 大正十二年の幽霊文字 - ことばマガジン：朝日新聞デジタルhttps://t.co/djVExrVN3o 朝日新聞の縮刷版検索に「彁」が見えた話 pic.twitter.com/1RhHtyWFyB — ひめ＠女体化したい (@sarasvati635) 2017年11月18日 朝日新聞デジタルの記事で、JIS X 0208の出所不明の幽霊漢字「彁」らしく見える文字が大正12年の印刷物に見えたという話です。 内容について詳しくは記事(2011/09/05付)そのものを読んでいただければ良いのですが、備忘として概要をかいつまんで紹介しておきたいと思います。 JIS X 0208の幽霊漢字とは JIS漢字コード規格JIS X 0208にはいくつか出所不明の漢字が含まれていて幽霊文字と俗に呼ばれています。拙著『プ

本大会で最強の評価関数はAperyのものだと私はくどいほど言い続けたが、それを確認しておく。 KPPT型のrezero19。これがelmo+R170ぐらい。(長い時間だともう少し強いかも) これと対局させてみた。今回から、1スレッド＝1物理スレッド(1論理スレッドではない)で計測する。論理スレッド分だけスレッドを作成した場合(80HT×2(先後) = 160論理スレッド作成した場合)、コンソールが詰まったりして、多少誤差が乗るので物理スレッドのほうが計測が安定するようである。あと開始局面として、やねうら王の互角局面集を用いている。 engine1 = YaneuraOuGoku_KPPT_learn.exe , eval = rezero_kppt_epoch19 engine2 = YaneuraOuGoku_KPPT_learn.exe , eval = Apery20171111 T

昨年ぐらいからStockfishの改良点を取り込んでもほとんど強くならないというのが続いている。いまや、Stockfishによって将棋ソフトにもたらされるレーティング向上は年間R30にも満たないように思う。 平岡さんがSDT5の1日目に徹夜して(?)、探索部を改良された。(おそらくオーダリングまわりをStockfishの最新のものにキャッチアップ)　しかし、あまり強くならなかったとのことである。 そして現在のAperyの探索性能は完全に時代遅れ感があるという事も分かりましたね(´･_･`) — 平岡 拓也‹‹(´･_･` )/›› (@HiraokaTakuya) November 13, 2017 やねうら王のほうは、次の方法で探索パラメーターをチューニングしている。 過去のStockfishにあった、過去に有効か互角ぐらいであった枝刈り一つ一つ導入して、その枝刈りを入れたほうが強くなる

やねうら王のlearnコマンドのfreeze_kk/kkp/kppは何のためにあるのか、説明を書いておく。 本来、FV38(EvalList 38枚固定化)にした場合、KKはKKPに含まれるのでKK自体、要らない。どういうことかと言うと、KKPの値 = ΣBK・WK・P(BK=先手玉、WK=後手玉、Pは玉以外の駒)で38回の足し算をするのだが、ここにKKの値を1/38ずつ乗せておけば、KKの項は不要である。実際、今回(SDT5)のAperyはKKの項が無い。 KKを無くすデメリットとして駒落ちでKの位置評価がおかしくなるというのがある。例えば、4枚落ちであれば、Pは34枚であるが、1/38ずつKの位置評価(KK)がKKPに乗って来ていると、4枚落ちのときに34/38しかKの位置評価を足し合わせていないことになる。やや少ない。ただ、駒落ちは駒落ち用の評価関数を別途作るべきという気もするので、

今回、やねうら王は公開しているバージョンからほとんど強くすることが出来なかった。(KPP_KKPT型 評価関数でelmo+R170、探索部で+R20程度。elmo+rezero8 = relmo8がelmo+R120程度なので+R70ぐらいしか強くなっていない。) 私の本業のほうが忙しかったこともあるが、それを差し引くとしても、課題に対する取り組み方とか、方針の立て方とか、色々反省すべき点は多い。他の開発者が同じ轍を踏まぬよう、その原因をざっと書いておきたいと思う。 1. 開発用のPCの問題 開発に使っているPCはXeon 2698のdual(40C80HT)が6台である。元は5台であったが、1台が故障して、修理している間にもう一台購入した。5月の段階では、メモリは32GBで頑張っていたが、結局1台は256GB、残り5台を96GBに増設した。ストレージは、サーバー機に1TBのSSD、3TB

リゼロ評価関数では、評価関数をゼロから学習させているが、駒割り(駒の点数)は、Aperyのソースコードで定義されている点数を初期値として用いてある。実際のところ、これがすべてゼロであってもきちんと学習できることは確かめた。 そもそもで言うと駒割りはKKPで表現できるので、それとは別に駒点を扱うことの意義はあまりない。強いて挙げるならSEE(Static Exchange Evaluation)で、駒点を使っていることぐらいであろうか。SEEで使っている駒点はそこまで厳密なものは要求されていないし、枝刈り用の探索パラメーターの一種であるとみなせるので、ここの調整は駒点とは別だと考えて、自己対局から調整したほうが良いように思う。 そうなってくるとそもそも駒点とは何なのかという話になってくる。USIプロトコルでは歩を100点として現在の局面の評価値を出力することになっているが、KKPに歩の価値が

今年の6月ごろ、色んな人から、やねうら王だと教師局面の生成が終わらないことがあるという報告を受けた。 教師局面の生成は複数スレッドで行なうが、長時間生成していると処理が終了しないスレッドが出てくるのだ。原因はいくつかあった。平手の開始局面からランダムムーブを5手ほど(設定で変更可)して、そこから対局をスタートさせるわけであるが、EvalHash(一度計算した評価値をcacheしておく仕組み)や、置換表の衝突など色んな問題により、この現象が生じることがわかった。 結局、置換表はスレッドごとに用意することにして、一度search()を呼び出すごとに、置換表世代を新しくすることにして、かつ、EvalHashは教師局面生成時は無効化するようにした。これで私のほうでは教師局面の生成が終わらないということはなくなったが、それでも何人かの開発者からの「教師局面の生成が終わらない」という叫び声にも似たツイ

metacircular-evaluator.org 2024 著作権. 不許複製 プライバシーポリシー