雑記

2025年7月27日日曜日

新型コロナにかかっていました

7 月 12 日（土）に全身の痛みと怠さ，喉のはれと痛みに軽い頭痛の組み合わせでダウンしました．起き上がるのも辛いくらいの症状で，食欲は全然ないし，何か食べようとしても吐き気がひどくて，あっさりしたものを少ししか食べられませんでした．

7 月 13 日（日）になって全身の痛みと怠さはマシになったものの，体温は 38〜39℃ を推移していました．食欲は多少戻っていたものの，やはりあっさりしたもの以外は食べられませんでした．痰をともなう咳がたまに出るようになり，夜には鼻水も出るようになりました．

7 月 14 日（月）になると，喉のはれと痛み，痰をともなう咳や鼻水は残っていたものの，体の痛みはかなりマシになり，体温は微熱になっていました．このような状態で，内科に行って診察と検査を受けたところ，新型コロナに陽性が出ました．

「発症日を 0 日目として 5 日間は外出を控えること」，「10 日間が経過するまでは，ウイルス排出の可能性があることから，不織布マスクを着用したり，高齢者等ハイリスク者と接触は控える等，周りの方へうつさないよう配慮しましょう」とのことで， 7 月 22 日までは自宅作業推奨となりました．

7 月 15 日（火）の時点で体温はほぼ平熱に戻りました．体調については，倦怠感と息苦しさ，筋肉痛のような痛みがわずかに残る程度で，日常生活に支障はありませんでした．

以降の症状は，喉に若干の違和感があり，痰の排出にともなう咳がたまに出るくらいになりました．これらの症状については，今日（7 月 27 日）になってもまだわずかに残っている状態ですが，徐々に改善しているため，そう遠くない内に消えると思います．（希望的観測）

新型コロナに罹患した感想としては，初日の症状がモデルナのワクチンを受けたときの副反応とほぼ同じだったこと，外出ができないのが厳しかったこと，薬が高かったことが印象に残っています．費用については，診察と薬で 18,000 円もかかりました．「何か心配なことはありますか？」と聞かれて，「現金がなくて払えないんですが…」と返してしまうくらいの事件でした．ちなみに，薬局は電子マネーに対応していたので，モバイル Suica に 15,000 円をチャージして支払いました．

新型コロナの感染者数はまだ増加傾向らしいので，皆さんご注意ください．

2019年12月18日水曜日

Wizardry 1&2 のコンサートに行ってきました

コンサートがあったのは10日も前（2019年12月8日）なのですが，なんだか体調が悪かったりリングフィットアドベンチャーのやりすぎでダウンしたりで書くのが遅くなってしまいました．

Wizardry のコンサートが開催されることに気付いたのは，申し込み終了まで後少しというタイミングで，まったくの偶然でした．こちらのサイト（ゲーム音楽コンサートのポータルサイト - 2083WEB）でたまたま見つけて，今時Wizardry 1&2のオーケストラコンサートとか本気かよと思ったものです．一応，友人にも声をかけてみたものの，残念ながら誰も釣れませんでした．

コンサートは新日本BGMフィルハーモニー管弦楽団によるもので，会場は北とぴあのつつじホール（王子駅のすぐそば），チケットは送料込みで4,750円でした．Wizardryのコンサートとなるとそうそうあるものではないし，申し込みに間に合うタイミングで気付いたのも奇跡的ということで，ほとんど迷うことなくポチりました．

実際にある程度プレイした Wizardry はファミコン版の 2, 3 とスーパーファミコン版の 5 だけなのですが，アポロンゲームミュージックBOX ~メモリアル･サウンド･オブ･ウィザードリィ（今見たら中古価格がすごいことになっていてビックリ）を発売当時（2006年）に少し迷いつつ購入するくらいにはWizardryのBGMが好きで，Wizardry 1の曲も繰り返し聴いていたので丁度良かったと思います．ちなみに，上述のBOXはフタを開けると"OOPS! TELEPOTER"と書かれていて，デザインに悪魔的なセンスを感じます．

コンサート会場の座席数は402で，8割くらいは埋まっていたと思います．実際のところ，Wizardryのコンサートが開催されるとかまったく考えていなくて，「知っていれば行ったのに」という人もそれなりにいそうな気がします．

開演前の説明では，映画上映前のような注意事項を話していました．その中でひかるくさりかたびらをコンサート会場で装備するのはやめるように言っていました．Wizardryのコンサートならではのジョークですね．ひかるかたびらは性能が中途半端で，使う機会はほとんどなかった気がしますけど，名前が印象的なので覚えています．

演奏前と間のトークでは，Wizardryあるあるなお話が展開されていました．

カティノが重要なのでハリトを使ってはいけない．
1回でも多くディオスを使いたいのでバディオスを使ってはいけない．
ボルタック商店が「ぼったくる」に見える．
宿屋で回復しようとすると料金が高すぎてお金がなくなる．
カント寺院のお布施が高い．
ワードナにバディが効いてしまった．
キャラクターを作ってお金を回収して消すことでお金を増やせる．
レベルドレイン，くびをはねられたなど…．

ネタをいろいろ並べてみると，WizardryプレイヤーはドMで変態という言葉（トークでも登場）を否定できません．自身，Wizardryに関する記憶の中で印象的なものは何かと考えてみると，ろくでもないことばかり思い出します．

宝箱の罠に引っかかってパーティが半壊した．
一方通行の扉を通過して戻れずにパーティが半壊した．
マロールで座標を間違えてメインパーティが「いしのなかにいる」してしまい，セカンドパーティで命がけの回収作業をおこなった．
レベル1のパーティでダンジョンに入ったら，最初の戦闘でクローリングケルプ（経験値が低い，呪文を妨害する，同時出現数が多い）の群れが出て全滅した．

悲惨としか言いようがありませんけど，パーティが半壊した状態で城への帰還を目指しているときのドキドキ感がたまらないのも間違いありません．

肝心の演奏については，オーケストラのコンサート自体初めてでどのように評価すれば良いのかわかりませんが，思い入れのあるゲームのBGMということで，存分に楽しめました．プレイ経験の差もあってか，Wizardry 2の方が特に良かったと思います．

トークの中で音源化したいという話も出ていたので，続報に期待しております．私の勝手な期待としてはWizardry 3&5というのもあります．

2019年12月1日日曜日

時計を見るまで11月31日だと思っていました

もう12月に入ったということで，年賀状の宛名書きをしていました．元旦に届く時期に年賀状を投函したことは未だかつてないと記憶しているのですが，今年は昨年に年賀状をもらった人の分だけでも早めに出しておくつもりです．

何年前のことだったか忘れましたが，年末年始にしんどくて年賀状をまったく出さなかった年があり，そもそも少なかった年賀状がさらに減ったおかげで負荷が下がりました．書き損じさえしなければ10枚に届かないくらいです．

実のところ，ほかに片付けるべき案件があるもの，どうにもやりたくない気持ちが強くて手を付けられず，現実逃避として年賀状を書いていただけですが…．

2019年11月28日木曜日

古い書類を整理しました

天気予報によると長引く雨も今日までで，明日からは晴れるみたいです．やっと布団などの大物が干せそうです．ただ，気温は今よりも下がるらしくて，風邪を引かないように気を付けないといけません．

重要そうな書類は保管するようにしているのですが，古い書類がたまりすぎて邪魔になってきたので整理に着手しました．昔の領収書，期限切れの保証書やら火災保険の書類など，もはや保管しておく意味のない書類がたくさんあって，大量に廃棄することになりそうです．

さすがに燃やせるゴミに出すのはなんとなく気持ち悪いため，頑張ってシュレッダーにかけることにします．持っているシュレッダーの処理能力が貧弱なので，これがなかなか面倒な作業になるのですが…．

ついでに保管しておいた空箱・空袋や古布も片付けを進めています．

2019年11月27日水曜日

louds-trie を MSVC でも使えるように改修しました

先週から気温がぐっと下がり，しかも雨続きでどんよりした気分です．実のところ，週末には晴れ間もありましたが，丁度そのタイミングは頭痛でダウンしていたため，私の中ではずっと雨なのです．

https://github.com/s-yata/louds-trie を MSVC でも使えるように少し修正しました（差分 1, 差分 2）． gcc と MSVC における組み込み関数の違いに対応させただけなので，動作には影響しないはずです．コンパイラが MSVC かどうかの判定には _MSC_VER が定義されているかどうかを使っています．

CPU 命令と組み込み関数の対応は以下の通りです．

CPU 命令	gcc	MSVC
popcnt	__builtin_popcountll	__popcnt64
ctz	__builtin_ctzll	_tzcnt_u64
pdep	_pdep_u64	_pdep_u64

後は，対応するヘッダが異なります． gcc では x86intrin.h をインクルードしますが， MSVC では intrin.h と immintrin.h をインクルードします．

参考

2019年11月26日火曜日

ThinkPad T495s が届きました

先週注文した ThinkPad T495s が届きました．

古い PC に Windows 7 が入っているほかは， VM で Windows を使うことがある程度だったので，久しぶりに最新かつネイティブな Windows 環境を手に入れたことになります．

折角の新しい PC ではありますが，今すぐに使う用事はないので， Visual Studio Community 2019 をインストールして Hello World! できることを確認しただけで今日は終わりにしました．今後， Visual C++ でのビルド確認やら Ryzen での性能確認などに使っていく予定です．

2019年11月22日金曜日

古くなったケーブルを廃棄しました

モバイルバッテリーや USB 充電器にスマホなど，何かを買う度に USB ケーブルがついてくるせいか，いずれ使うかと保管しておいた USB ケーブルが結構な量になっていたため，古くなったものを廃棄しました．

USB は端子の種類が多い上，ケーブルを見ても性能がわからなくて困ります．端子を Type-C に統一できれば良いのですが，手元にある機器だけでも Type-A, B, C に Mini-B, Micro-B, Micro-B SuperSpeed といろいろな端子があり，念のために予備も残しておこうと考えると，なかなか数を減らせません．さらには通信用やら充電用やらあり，しかも通信速度や充電速度に違いがあって，見た目では判別できないため，本当に困ります．

ディスプレイケーブルもたくさんあって，整理したいとは思っているものの，それらを使う機器も一緒に整理しないといけなくて，どうにも面倒で着手できていません．

2019年11月21日木曜日

情報処理のバックナンバーを消化しました

年単位で積読状態になっていた情報処理（情報処理学会の学会誌）のバックナンバーを消化し終わり，少しだけ部屋が広くなりました．まだ書籍の山が二つ残っているので先は長いです．とりあえず，今年度中には片付きそうにありません．

2019年11月19日火曜日

体調が安定してきました

ここ数年は体調が不安定で，特にアトピーが悪化して困っていたのですが，今年に入って徐々に安定してきました．夏場の暑い時期や季節の変わり目は少し強めに症状が出たものの，大きくは悪化していません．

理由としては，時間の余裕が増えたこと，ストレスの原因を減らしたこと，生活習慣を見直したことなどが考えられます．一度体調を崩して，そこから食事などに手間をかける余裕がなくなり，さらに体調が悪化するというような悪循環が続いていたので，えいやっと環境を変えたのは正解だったと思います．

2019年11月18日月曜日

ThinkPad T495s を注文しました

永らく Windows はほとんど使っていなかったのですが，手持ちのノート PC に入っている Windows 7 がサポート終了間近ということで，新しいノート PC を注文しました．

当初は Windows でのビルドとテストができる環境が欲しくて検討し始め，どうせなら AMD の Ryzen を試してみたいとか，あまり持ち歩くことはないかなとか考えた結果， ThinkPad T495s になりました．主な構成は以下の通りです．

ThinkPad T495s

CPU: AMD Ryzen 5 PRO 3500U (2.1GHz, 4MB)
RAM: 16GB (PC4-21300 DDR4)
SSD: 512GB (NVMe)

以前は Visual C++ Express を使っていた記憶がありますが，現在は Visual Studio Community を使えば良さそうです．https://visualstudio.microsoft.com/ja/vs/community/ に「個人開発者の方はどなたでも、独自の無料/有料のアプリを作成するために Visual Studio Community を使用できます。」と書いてあります．

2019年10月14日月曜日

marisa-trie で BMI2 の PDEP 命令を使えるようにしました

簡潔ビットベクトルの select に BMI2 の PDEP 命令を使うと実装を単純化できる上に高速化できるという情報を見つけたので marisa-trie (https://github.com/s-yata/marisa-trie) に組み込んで試してみました．

PDEP を使うのは， 64-bit 整数まで絞り込んだ後になります．
marisa-trie での該当箇所は以下の通りです．（MSVC 向けの部分はカットしました．）
unit から i+1 番目の 1 になっているビットの位置を求めています．（bit_id はただのオフセットなので気にしなくて OK です．）

std::size_t select_bit(std::size_t i, std::size_t bit_id, UInt64 unit) {
  return bit_id + ::__builtin_ctzll(_pdep_u64(1ULL << i, unit));
}

select は lookup や reverse_lookup の中で特に重い処理なので，結構効果がありました．
以下， marisa-benchmark に日本語 Wikipedia のタイトル一覧（順序そのまま）を入力したときの出力を貼っておきます．
実行環境の CPU は Core i7 6800K 3.4GHz です．

まずは PDEP を使わないバイナリです．

$ make clean && autoreconf && ./configure --enable-bmi && make
...
$ tools/marisa-benchmark -p jawiki-20191001-all-titles-in-ns0
Number of tries: 1 - 5
TAIL mode: Text mode
Node order: Descending weight order
Cache level: Normal cache
Number of keys: 1887667
Total length: 40976550
------+----------+--------+--------+--------+--------+--------
#tries       size    build   lookup  reverse   prefix  predict
                                      lookup   search   search
          [bytes]    [K/s]    [K/s]    [K/s]    [K/s]    [K/s]
------+----------+--------+--------+--------+--------+--------
     1   16224608  1446.04  3608.77  3206.54  3152.50        -
     2   11877920  1169.76  2051.87  1898.60  1977.19        -
     3   11008584  1158.67  1699.86  1695.10  1708.77        -
     4   10692624  1151.92  1685.07  1632.11  1644.95        -
     5   10557664  1155.25  1661.06  1597.17  1618.07        -
------+----------+--------+--------+--------+--------+--------

次に PDEP を使うバイナリです．

$ make clean && ./configure --enable-native-code && make
...

$ tools/marisa-benchmark -p jawiki-20191001-all-titles-in-ns0
...
------+----------+--------+--------+--------+--------+--------
#tries       size    build   lookup  reverse   prefix  predict
                                      lookup   search   search
          [bytes]    [K/s]    [K/s]    [K/s]    [K/s]    [K/s]
------+----------+--------+--------+--------+--------+--------
     1   16224608  1418.83  4134.11  3956.39  3858.28        -
     2   11877920  1220.01  2357.28  2276.49  2279.57        -
     3   11008584  1164.50  2037.00  1978.51  1985.62        -
     4   10692624  1158.25  1915.64  1929.95  1909.70        -
     5   10557664  1159.29  1916.36  1902.57  1872.88        -
------+----------+--------+--------+--------+--------+--------

PDEP を使わない場合と比べて PDEP を使う場合は， lookup が 14-20% の高速化， reverse_lookup が 17-23% の高速化となりました．

2018年11月17日土曜日

古いプロジェクトのメンテナンス

古くなったプロジェクトのメンテナンスをおこないました．

変更したところは大体こんな感じです．

新しいコンパイラで出るようになった警告が出ないように修正しました．
ドキュメントのリンク先がなくなっているリンクを更新しました．
バージョンが上がったソフトウェアとの組み合わせを試しました．
Markdown のインデントを修正しました．

2018年11月16日金曜日

アーカイブの公開方法を変更

日本語ウェブコーパス 2010 (NWC 2010) の移動が完了したため， HTML アーカイブとテキストアーカイブの公開方法を変更しました．

https://www.s-yata.jp/corpus/nwc2010/htmls/
https://www.s-yata.jp/corpus/nwc2010/texts/

以前は AWS Account Number を教えてもらい，こちらで EBS スナップショットのアクセス権限を設定していました．
この方法だと，利用者は AWS アカウントが必要な上，手元にダウンロードするまでの手順がとても面倒という問題がありました．

今回， EBS スナップショットに入れていたデータを S3 に移動したので，アーカイブが欲しいという連絡をもらったとき，こちらで公開の設定をおこなえば，利用者は単純にダウンロードするだけになります．

2018年11月15日木曜日

日本語ウェブコーパス 2010 の移動

日本語ウェブコーパス 2010 (NWC 2010) は，当時もっとも安かった米国東部（バージニア北部，us-east-1）リージョンで作成した後，これまで同リージョンに置きっぱなしになっていました．
現状， us-east-1 にこだわる理由は特にないので，東京リージョンに移動することにします．

それから，サイズの大きいアーカイブは EBS スナップショットにしていたのですが，コスト面で s3 の方が優れていると判明したので，すべて s3 に移行しようと思います．
稀にリクエストがある程度のアーカイブであれば， Glacier にすることでコストを削減できるはずです．

GitHub Pages でサイトを作成してみた

GitHub Pages でサイトを作成してみました．
https://www.s-yata.jp/

旧サイトの中身を持ってきただけなので，新しいことは特にありません．
これで問題がなければ，旧サイトをホストしているサーバは解約できます．

追記：
http://s-yata.jp/ へのアクセスは http://www.s-yata.jp/ にリダイレクトされることを確認しました．
旧サイトのコンテンツに対するブックマークなども有効なはずです．
ただ，ウェブサービスについてはサーバをなくしたいので廃止してしまいました．

2018年11月13日火曜日

GitHub Pages をお試し中

ウェブサーバの管理をきちんとやるのは大変なので， GitHub Pages でウェブサイトを公開する方が良いのではないかと試しています．

GitHub Pages の使い方は GitHub の Help (https://help.github.com/categories/github-pages-basics/, https://help.github.com/categories/customizing-github-pages/) に詳しく書いてあります．
既に HTML ファイルが手元にあれば，リポジトリの設定で GitHub Pages を有効にして， push するだけで公開完了します．

ウェブサイトの生成には Jekyll が使われているため， Front Matter 付きの Markdown ファイルを push すれば， HTML に変換されたものが見えるようになります．
_config.yml を追加してテーマを変更したりプラグインを追加したりすることもできます．

2018年10月16日火曜日

Code prettifier の使い方

https://github.com/google/code-prettify の使い方をメモしておきます．

「テーマ - HTML の編集」で <script> タグを <b:skin> の前に追加した後，「テーマ - レイアウト - 上級者向け - CSS を追加」でスタイルを追加しました．
<script> を入れるべき場所はテーマで変わりそうな気がします．

上記の設定だけではモバイル版には反映されません．
「テーマ - モバイル - 設定」で「カスタム」を選択すれば反映されました．

2018年10月15日月曜日

ソースコードの埋め込みを試す

以下は https://github.com/google/code-prettify の例です．
色と行番号はスタイル指定で変更できます．
デフォルトだと微妙な気がするので，気が向いたときにでも調整しようと思います．

#include <stdio.h>

int main(void) {
  /* Hello, world! */
  printf("Hello, world!\n");

  return 0;
}

Blogger を試す

はてなダイアリーが終了してしまうので， Blogger を試してみることにしました．
ソースコードの貼り付けは gist や https://github.com/google/code-prettify で大丈夫そうです．
とりあえず，少し使ってみることにします．
一番の問題は書くべき内容がないことでしょうか．

登録: 投稿 (Atom)