晴れ。 少し涼しくなった (真夏日 & きのうから今日にかけては熱帯夜)。
xyzzy はさすがに有志の開発も止まっていそうだけど、Ng, mg, jove, zile は未だに Debian パッケージもある。 わかりやすいのは Debian -- trixie の mg パッケージに関する詳細かな。 なぜか類似のテキストエディターが紹介されている。 っていうか mg は未だに細々と開発が続けられているようで、長く OpenBSD プロジェクトで開発されてきたもの。 jove も開発が続いていそうだ。 すごい。 mg と zile と jove のパッケージを入れても 1,704 kB しかディスクスペースを食わない。 すごい。
3 つをとりあえず試してみたところ、zile が一番今風かな。 ちゃんと範囲指定に色が付く。 3 つとも横スクロールが最初からオンなのはなんでだろうな。 しかしすごいな、2025 年にもなってこの軽量 GNU Emacs 風エディターが未だに保守されているとは... Ng もね、他とは違って一応 UTF-8 対応にはなっているというのがすごいんだけど、さすがにちゃんと保守されているか心配になるレベルだ。
まぁ、自分は GNU Emacs を普通に使い続けているけど、それも root 権限では使わないもんな。 軽量なやつはそういう用途にはいいのかも知れない。 けどまぁそれなら別に vim-tiny でもいいし nano でもいいし...
中学生の頃になくしてしまった英和辞典はどこのやつだったのか。 そんなに分厚くなくて便利なやつ。 発音記号を最初に学ぼうとしたのがそれだった。
で。 ふと思いついて図書館にいって探してみた。 現行のを見てみると少し思い出してきた。 Cat の a を、アの口の形でエと言う、という風な表現になっていたんだ。 これを、逆にエの口の形でアと言う、としている辞典もある。
いろいろ見た結果、学習研究社のやつだったんじゃないか、という感じだけど、思ったより分厚いし説明が真ん中付近のページにあるのも記憶と違うし、もはやわかんないな。 もし、昔のバージョンのアンカー英和辞典に小さいのがあったなら正解かも知れない。
最近の版は小学生から英語を学ぶことを前提としたものが出ているようだ。 それはそうだな。 ベネッセまで出しているのが意外だ。 あの福武書店がねぇ。 チラッと見てみたら、出てくる絵にベネッセの香りがして元進研ゼミ受講者としてはにやけてしまう。 研究社 ジュニアアプローチ英和辞典 (1989) のはじめにのところに書かれていたのが、以下のような文章だった:
ちょうど，昭和 63 年 4 月に新改訂の教科書が出たことから，新しい教科書に対応できる中学生向けの辞書がぜひ必要であると考え，まず，日本の新しい教科書の英文すべてをコンピューターに入力し，それらを分析整理しました。
つまり学校教育を念頭に置いて英和辞典を作っている。 それはそんなものなのかも知れないけど、おもしろい。 それを考えるともうちょっと後の 1991 年度中学入学の人からカリキュラムが違うんだよね、確か。 そういうことも頭に入れて、古い英和辞典の登場時期と見比べると、違いが見られるかも知れない。
ちなみに、どの英和辞典も同じ方式の発音記号が使われていた。 カタカナ表記も基本的に併記されるのが普通だったようだ。 カタカナはいいとして、発音記号は例の微妙なやつだ。 Fifty などの最後の y の部分が、field の ie の音とは違う表記になっているやつ。 いわゆる、唇を左右に引くか、イとエの中間のやつかの違いがあって、微妙なやつでは後者のように見えてしまうが、実際には前者でなければならないはずだ。 もっとごちゃごちゃした発音の preliminary みたいな単語を調べるとわかりやすいが、図書館ではいい単語を思いつかなかったw 最初の pre の e と、末尾の ry の y の音は違うんだ。 ロングマンや Cambridge はちゃんとそこが区別された発音記号を使っている。 英辞郎は区別されていない発音記号を使っていて、図書館で見た感じでも日本の英和辞典ではそれが主流のようだ。
学習研究社 ジュニアアンカー英和辞典の古いやつをコピーさせてもらったんだけど、フォニックスという、つづりと発音との結びつきのルールものっていて、それが意外というか... 1995 年の基礎英語 1 でやっていたので何となくは覚えているものもあるけど、それが英和辞典に載っていたかと言われるとそんな記憶はない...
ジュニアじゃないアンカーの 1985 年版も見たが、意外とジェスチャーなどの文化の説明にページがさかれているのがおもしろいと思った。 古いやつは白黒の絵だったが、最近の小学生向けも想定されていると思われる英和辞典には、カラーページもついて、目の色の違いが写真になっているなど、かなり親切で楽しめる内容になっている... っていう見方は実に大人目線だろうね。 今時の子供がどう思うのかはよくわからないね。 YouTube なんかで外国の動画に触れる機会も多いだろうし。 英和辞典ががんばっていろいろ載せたところで、教科書じゃないんだから、世界史の資料集みたいに授業中の暇つぶしに使われればいいほうで、完全スルーされる可能性もありそう。
晴れ。 暑い日。
テレビでやってた映画『もののけ姫』。 1997 年の邦画。
最新の C 言語規格の C23 は、もう GCC や Clang で使えるようになっているらしい。
それぞれ Debian 13 の公式パッケージで OK。
-std=c23 でいける。
bool 型が標準装備なのも使える。
ちなみにその Debian 13 の GCC 14 では、ついにプロトタイプ宣言の返り値の型省略がデフォルトでエラーになるようになった。
いきなり main(){ で書き始める超手抜きプログラムはもうデフォルトでは許されない。
他にもポインターの暗黙の型変換が void ポインターとの間以外ではエラーになるように変わっている。
なお、C89 より前のスタイルの関数宣言、すなわち引数の型をまとめて指定する方式は引き続き許されるようだし、プロトタイプ宣言の引数を () として任意の引数を受け付けるというやつも、デフォルトでは許されている。
-std=c23 を指定すれば () で宣言した関数に引数を指定するとエラーになるし、C89 より前のスタイルの関数宣言は GCC は old-style function definition として警告、Clang は -std=c23 ではそれも完全に受け付けないようだ。
-std=c11 なら両方とも通るので (Clang は警告を出す)、1990 年代に C を勉強した人なら見覚えがあるであろう懐かしのスタイルの終わりの足音が近づいてきたな。
晴れ。 暑い日。 気象庁アメダスによれば... 東京・府中の最低気温 26.4 度 (05:22)、最高気温 39.0 度 (14:38)、とまぁ、暑い。 バーディー 90 で買い物行っただけでヘルメットの中が汗で...
JavaScript の再帰を使って書いてみたバージョン 20250830-nqueens.js。 コードは短いが実行時間はだいぶ長い。
Emacs Lisp バージョン 20250830-nqueens.el。
さすがに遅い。
ネイティブコンパイルがきいてもよさそうなんだが、eln ファイルは見当たらぬ。
試しに byte-compile-file をやって elc を作らせてみたところ、el を指定するより elc のほうが圧倒的に速い。
5 倍以上も差がつく。
へぇー、そんなもんなんだ。
その場でバイトコンパイルして動くわけじゃないんだね。
native-compile に直接 el ファイルを指定したらネイティブコンパイルができて、elc の 0.55 倍ぐらいの実行時間になった。
へぇー。
再帰バージョンを QuickJS に入れると、Emacs Lisp の elc の 0.74 倍ぐらいの実行時間。 まあまあ速いけど再帰じゃないこの前のバージョンと比べれば倍以上の時間になる。
実は最初 2 番目の引数を t としていて、Emacs Lisp が動かなくて首をかしげていた。
t は古くからの Lisp 由来のシンボルだ。
オランダ GP 予選。 角田は 12 番手。 トップからピアストリ、ノリス、フェルスタッペンの順、続く 4 番手にハジャー! Q2 まではノリスのほうが微妙に速そうだったけど、Q3 になってピアストリがきわどい戦いを制した。 プレッシャーかな。 プレッシャーに強いのはノリスよりピアストリっぽいもんな。
きのうの、JavaScript の再帰を使って書いてみたバージョンを高速化したバージョン 20250831-nqueens.js。 改良点はふたつあって、ひとつは再帰を一部やめてただのループにした。 もうひとつは左右反転した同一パターンが存在するのでそれを活かして探索量を減らした。 2014 年に書いた C 版はそれをやっていたのを急に思い出した。 ここまでやると 2014 年に書いたバージョンをベースにした 27 日版よりも速くなった。 2014 年版はそもそも再帰呼び出しを使っていないんだけど、この結果を見るに再帰呼び出しが遅いってわけじゃないらしい。 しかし... やっぱりインタープリター言語としては異様な速さだな、JavaScript は。
Free Pascal バージョン 20250831-nqueens.pas。
ビットシフトに Borland Pascal の拡張の演算子を使っているため標準 Pascal ではない。
Pascal は教育用言語と言われるけど、読みやすいかと言われると、うーん (笑)。
Free Pascal は現状ではまだ LLVM をデフォルトで使うようにはなっていなくて、この手の計算プログラムに対する最適化は弱い。
それでもさすがに Node.js よりは速いバイナリが生成される。
最適化オプションを特に指定しなかった場合で Node.js と同じくらいの実行時間だった。
まぁ、Node と比べての速さの肝は立ち上がりかもね。
出だしはいくら just-in-time compiler があってもインタープリターが不利だろう。
と思って N=16 まで追加してみたけど、さすがに Free Pascal に最適化オプション -O1 をつけただけで Node.js よりは速くなるし、-O3 を付ければ 1 割ちょっとの差がついた。
Visual Basic (.NET Framework) バージョン:
昔の Visual Basic とはすっかり変わっていてソースコードがこれで足りるかわからないけど、フォームと実装は含まれるのでまぁわかる人にはわかるだろう。
ビットシフトは << >> なのねぇ。
昔はビットシフトなかったよな。
かけ算割り算で書いていた思い出。
Pentium でも軽快に動いていた昔の Visual Basic とは違い、現在の開発環境はむちゃくちゃな重さでウチの Athlon 5350 Windows パソコンでははっきり言って実用にならないが、できあがるバイナリは軽い。
一発目が Free Pascal の -O3 と変わらないくらいで、二発目以降はそれより速かった。
晴れ。 暑い日。 暑かった。 8 月最終日も猛暑日っていうね。
上の実験のために Visual Studio Community 2013 を立ち上げたらライセンス切れになっていて、仕方なく Visual Studio Community 2022 のインストールを始めたらとても時間がかかったし、インストーラーは画面からはみ出すし、プロジェクト作成の画面には豆粒みたいな 9 ポイントよりも小さな文字が出てきて読めないし、いろいろと時代を感じる。 Visual Basic のフォームデザイナーが出てくるまで数分、簡単なコードを書いて F5 キーを押したら、昔とは違ってビルドが始まって、待っていたら 5 分のスクリーン セーバーが始まって笑った。 5 分してもビルドが終わらない Visual Basic ってw インタープリターじゃなくなったらそうなるよな。 Visual Basic 自体、コントロールの一覧をどこから呼び出すのか探すほど、昔よりも取っつきにくくなっている感じがある。 Let ステートメントも今はなくなっていて、使おうとしてもエラーになる。
んで Lazarus も Windows 版をインストールしてみたところ、インストール自体はそこそこの時間はかかったが、起動は軽快だ。 いきなりフォーム編集できるし、名前つけずにいきなり実行できるし、昔の Visual Basic に近い。 インタープリターではないけど、ビルド自体が速い。 たぶん Delphi もこんな感じだったんだろうね。
オランダ GP。 スタートで 3 番手スタートのフェルスタッペンと 2 番手ノリスが入れ替わった! ポールスタートのピアストリは絶妙なラインを通ってフェルスタッペンが滑ってしまって 1 番手キープ。 何周かして順位戻ったけどノリスは追い上げなのでおもしろレースだ。 雨が降るかどうか、降りそうで降らない感じで、降っても少なくて、... そしてクラッシュはハミルトン! バンクのところのペイントが濡れていて滑ったらしい。 それで出たセーフティカーで損をした組に角田も含まれる。 再開でローソンとサインツが接触、もったいない...
ハジャーが 4 番手を死守していてすばらしかったが、後ろでしびれを切らしたルクレールが先にピットインして、アウトラップでアントネッリと絡んでクラッシュしてまたしてもセーフティカー、フェラーリ 2 台とも終了。 そして再開、トップ争いが 1 周だけ DRS の争いになったが順位変わらず、その後は 1.6 秒ぐらいの間隔をキープしていたが... 72 周のレースの 65 周目にノリスのマシンから煙が...! ああ! 3 度目のセーフティカー、なんとハジャーが 3 番手に! マクラーレンはミディアムタイヤスタートでハードタイヤを 2 スティント使っても余裕で最速なんだよな。 本当に今年のマクラーレンはすばらしい出来だ。
結果、ピアストリ、フェルスタッペン、ハジャーのトップ 3。 ピアストリは今回初めて終始レースリーダー。 セーフティカーのタイミングでピットインができたから順位を落とさなかった。 ハジャーは今年デビューのルーキー、きのうの予選で 4 番手タイムを出したのが見事だったし、レースもいろんなごたごたに巻き込まれなかったおかげで、ノリスのリタイアから初表彰台が手に入った。 角田は 9 位。
トップ争いでマシントラブルによるリタイアは結構残念なんだよな。 前兆があったならともかく、普通はドライバーが悪いわけじゃないし。 最近では珍しい気がする。
きのうは、最新の Visual Basic を試したわけだが、こうなると昔の Visual Basic 6.0 (VB6) も気になってきたので試した。
ソースコードは 20250901-Form1.frm。
ビットシフトがないのでかけ算と割り算とべき乗に変更、あと、見ながら打ち込んだのでうっかり昔の BASIC の癖で Str$ と $ まで入れてしまったが気にしないように!
あと i をうっかり Integer (VB6 では 16 ビット) にしてしまったな、ま、いいか。
なお、仮想マシン上の古い環境でビルドしたバイナリ (当然 32 ビット) をきのうと同じ Windows 10 パソコン (64 ビット、Athlon 5350) に持ってきて実行し、計測した実行時間 (秒) を適当にピックアップして小数点第二位を四捨五入して示す。
仮想マシン上で軽く見たところでは、インタープリター (F5 キーでその場で実行) と P-Code コンパイルはほぼ同等という感じだった。 仮想マシンは Ryzen 7 2700 上のためそれでも遙かに速く 13 秒ぐらいの速さであったがw 最適化すると 1.2 秒程度になってしまってあまりにも速すぎて比較が難しいのと、現代の Visual Basic との比較もかねて Athlon 5350 で見ることにした。
で、今の Visual Basic だと一発目が 2.5 秒程度、二発目は 2.3 秒程度と、VB6 より速い。
Free Pascal 版は time でプロセス起動時間も含めて計っているのでちょっと不利だが 2.7 秒程度で、それでも VB6 よりは速い。
Basic なんだからと思えばそこそこ速いんだけど、最適化コンパイルしてもその程度だったのかと、27 年の時の力を感じずにはいられない。
いや、その、なんだ... 27 年って書くと、27 年前のコンパイラーで作ったバイナリが普通に動く Windows の互換性がとんでもないよ... ランタイムライブラリが必要ですみたいなメッセージが出るかと思ったけど何も出なかったよ... すげぇよ本当に...
9 月になっても安定の猛暑日 & 熱帯夜!
最近気づいたけど弁当を買いに行く時に履いていたジャージが綿でそこそこ足に密着するやつで、これも暑い原因だったな、なんて。 ちょっとダボダボのほうが風が通っていいな。 何なら浴衣みたいなののほうがいいかも知れないけどねw でもこの猛暑日では多少着るものを変えたくらいで汗だくにならないわけはない。
近所の小学生達が今日は早く終わる日だったのか帰るところに遭遇したけど、日傘を差していたのが半数ぐらいかな、まぁー暑そう! 暑いって言っていたし! 死ぬなよ! 「なんで小学生は歩いて帰らなきゃいけないんだろうね」「迎えに来てくれたらいいのにね」みたいな話し声も聞こえてきて、...そうだね。 まったくだ。 せめて下校時刻があと数時間遅ければだいぶ違うのにね。
防災の日だったな。 忘れていた。