晴れ。 暑い日。 またしても猛暑日が続いている。 もはや機械の助けがなければ人が生きていける世界ではない。 今年はまだモバイル扇風機は使っていない。 この気温じゃ熱風が吹いてくるだけじゃん...
毎日朝に体重と体脂肪率と腹囲と血圧を測って記録するようになってわかったこと。 やっぱり飲み会の翌日は体重が増える。 飲み会に限らず、あまりコントロールできていないなって食事の後はそんな感じ。 体重には前日の夜の食事が影響する感じがある。 例え夜中にお腹が空いていてもそう。 きのうの飲み会は刺身とかサラダとか揚げ物とかが中心で、ご飯物を食べなかったためか夜中にお腹が空いたが、今朝の体重は増えていた。 普段食べている、野菜をぶち込んだ炊き込みご飯のほうが、腹持ちがいい上に体重が増えない。
あと、運動をすれば翌日ちょっと体重が減る傾向もあるように感じる。 食事と運動による体重変動は割と一貫性があるみたいなのでこれは参考にできそう。
しかし体脂肪率・腹囲・血圧に関しては正直何もわからん。 今年の体重の最小値は今月 7 日の 70.1 kg。 その前日の 70.4 kg も次に低い値で、腹囲はその 2 日は 80 cm をわずかに割っていた。 しかし体脂肪率は 23.3% とか 23.5% で特に低くはない。 体脂肪率は数日前の 22.7% が今年の最小値で、その時の体重は 71.0 kg。 別に運動した翌日でもないし、食事も同じパターンの時で、相関がわからない。 血圧も別に塩辛い物を食ったわけでもないのに収縮期血圧が 120 を超えてくる日もある。
とはいえ振り返ると 5 月はまだ 72 kg 台からやっと 71 kg 台が出るようになったくらいだったんだな。 血圧も拡張期血圧が 80 前後の日もあったみたいだ。 野菜いろいろチャレンジは落ち着いて、にんじん・キャベツ・長ネギ・ゴボウあたりが定番パターンになった。 時々オクラを入れたり、ピーマンを入れたり、加熱調理後にミニトマトを入れたりしている。 タマネギに血圧を下げる効果があると聞くけど、長ネギも切っていたら涙が出てくるし似たようなものなのでは? (適当)
晴れ。 あっつい。
ニュースになっていた東名高速の追突事故の映像、3 番目の通行帯で渋滞最後尾の車にノーブレーキとおぼしき勢いで突っ込んだものだ。 死者が出なかったのは何よりであったが、なんで 3 番目の通行帯が渋滞? と思って調べてみたら、現場は上り線、東京インターチェンジ出口の近く。 近くといってもだいぶ離れていて、本当の出口近くは出口の第 1 通行帯と首都高に向かう第 2 通行帯の間に車線変更禁止区間があるようだけど、現場はまだ普通に 3 車線の区間。 つまり首都高に向かう人達は右側を走っていて、首都高の渋滞が伸びるとそうなることがあるってわけかぁ。
例えば常磐道は三郷料金所で首都高につながるけど、もともとはそこに出口がなくて、今は三郷スマートインターチェンジがあるって形で、降りる人も首都高に向かう人もギリギリまで皆同じ通行帯を使うので、そういう変な偏りは起きにくい。 中央道は高井戸インターチェンジを過ぎたら首都高だけど、もっと手前で 2 車線に減る上、出口は普通の左分岐なので、東名高速ほど極端に流れの差はできない。 (入口が右合流なのでやや右側のほうが流れが悪くなる傾向はある。) あと現金は均一料金区間にあたり出口に料金所がなく、首都高の永福のそばの料金所までスーッとつながっているのもスムーズな一因か。 東北道から首都高へはあまり使ったことがないので記憶にないが... 東関東道も確かそんなに危なっかしい作りではなかった気がする。 東名高速が要注意なんだな。
東名高速も今は東名川崎インターチェンジで降りてしまうので、東京インターチェンジの渋滞がそんな危なっかしいことになっているという認識はなかった。 2007 年に東名高速から首都高を経由して常磐道まで運転したのが最後じゃないかな。 あのときは東名高速は夏休みの日曜日の渋滞ですごく流れが悪かったような気がする。 そして現金払いで日奈久からの 25050 円を払ったらしいw 2016 年は東京インターチェンジで降りていて首都高へは行っていない。
晴れ。 暑い日。
相変わらずの猛暑日な上に午後に微妙に雨がぱらつきそうな天気予報で出かける気がそがれるけど、バイクで八王子に大分ラーメンを食べに行き、その先の大垂水峠を久しぶりに越えて、相模原市の城山のほうにくるっと回って、町田街道と野猿街道を経由して帰ってきた。 曇っていた時間もあったけど雨には降られなかった。 60 km そこそこしか走っていないけどおしり痛かった。
日野バイパスの万願寺駅近くのところ、「災害対策基本法に基づく車両通行止」の標識が出っぱなしになっている。 なんだぁ? なんか出ているぞと思いながら通過したんだけど、これってどういう扱いなんだ。 大量の車が違反ってことにならないか?
パンデミックになってから藤野に行かなくなったので大垂水峠もめったに通らなくなった。 標高 300 m ぐらいだっけなと思っていたら 392 m って書かれていて笑う。 あっちのほうはあんまり景色は変わっていない。
さがみ湖リゾートプレジャーフォレストがあるところだよな、と思っていたらさがみ湖 MORI MORI に名前変わったんかい。 ほー。
多摩市から稲城市にかけての都道 41 号・川崎街道の 50 km/h 制限が取っ払われていた。 ここ 10 年ぐらいで結構いろんな道の制限速度が引き上げられてきたけど、今更まだ上げるんだなぁ。 そしてここはどうなのかな、60 km/h はちょっと危ない気もする。 こういう決定は何ドリブンなんだろうな。
テレビでやってた映画『崖の上のポニョ』。 2008 年の邦画。
Tool Command Language, Tcl は比較的古いスクリプト言語。 1988 年誕生なので日本で言えば昭和。 学生の頃にちょっぴり触ったくらい。
puts "Hello" で Hello って出る。
素直だな、って思うけど...
puts {Hello} でも Hello って出る。
んんん?
puts {"{Hello"}"} で "{Hello"}" が出る。
if 1 "puts \"Hello\"" で Hello が出る。
{ } を使えば見た目はそれっぽく書けるけど、それも全部文字列、つまり、if 文の条件成立時に実行される部分すら文字列!
そして、変数のセットも set コマンドで行うという、何もかもがコマンドで行われるスタイル!
set a {puts "Hello"};if 1 $a でも Hello が出る。
このタイプのスクリプト言語はインタープリターでないと実行できないもので、バイトコードすら生成しづらい難しいやつだけど、インタープリターの実装自体はかなり簡単にできると思われる。
Tcl はもちろんアプリケーションに組み込むスクリプト言語として優秀だが、Lua というのも 1993 年登場ということでだいぶ経っていて、性能面でも有利なので Tcl が流行らないのはそのへんかも知れない。 実は SQLite のビルドに Tcl が必要というので、なんで? と思って調べたらもともと Tcl での利用を想定していたらしくて... つまり作者が慣れているんだな。
アプリケーションに組み込むスクリプト言語として JavaScript はないのか、調べてみると QuickJS が出てきた。 QEMU の作者が作っているということで、謎の安心感がある。 Just-in-time compiler は使っていなくて、バイトコードで動くらしい。
晴れ。 あつい。
保冷剤を背中と脇につけるアイスベストとやらを買ってみたので弁当屋に行く時に使ってみたけど、猛暑日の強烈なコンディションではそれに日傘を組み合わせても汗が出てくる。 まぁないよりはマシか。
ABEMA の将棋、ABEMA トーナメント 2025。 決勝、17 時スタートの生中継。 チーム藤井 VS チーム天彦。 チーム藤井がぐいぐいいくのかと思いきや、2-2, 2-3, 3-3, 3-4 とかなりの接戦で。 一人 3 回までしか出られないのが味噌で、藤井七冠が 3 勝するとしても、残り 2 勝は他の人が決めないとチームとしては勝てない。 最初の方に別の人が 1 勝はしたけど、3-3 時点で藤井七冠が 2 勝という、チーム藤井が優勢とは言えない展開。 4-4 で藤井七冠 3 勝、3 局とも相手は佐藤天彦九段で藤井七冠が先手だった。 佐藤天彦九段は対局前の署名がきれいだった以外にいいところなかったな。 藤井七冠の強さもさることながら、チーム天彦の増田八段も今回も負けなしの強さ。 藤井七冠とあたっていたらわからなかったけどね、運良くあたらなかった。 最後は斎藤八段と広瀬九段の対局、広瀬九段が先手。 泣いても笑っても勝ったほうのチームが勝ち! コンピューターの評価が何度もひっくり返る熱い展開で、それぞれに悪手があったと思うんだけど、最終的に広瀬九段が勝った! おもしろかった。 チーム天彦が優勝!
上野駅近くにある国立科学博物館 上野本館に行ってみた。 常設展示と特別展示があるらしい。 常設展示は一般・大学生の入館料 630 円。
「火山のおはなし」っていう防災講演会があった。 国立科学博物館 理学研究部の佐野 貴司氏と、気象庁 地震火山部 火山監視課 火山防災推進室・火山防災調査官の高木 朗充氏のおふたり。 8 月 26 日が「火山防災の日」になったということで。 日本国内では防災面で注目するのはやっぱり桜島らしい。 何といっても、ここ 30 年毎年必ず 1 回は噴火しているほどの活発な火山が、60 万人規模の人口を抱える鹿児島市のすぐそばにある。 まわりに人がまったくいない無人島ならば、大正大噴火のような噴火が起きたって基本被害が出ない、つまり火山活動としては注目するところがあっても、防災としては問題にならない。
ってことで大正大噴火の話がたくさん出てくるのかと思ったら別にそういうわけではなく、火山に関してこういう研究があるんですよ、防災のために気象庁はこういうことをしているんですよという紹介だった。 まあそれはそれでおもしろく、山体膨張を監視するために GPS や傾きセンサーなどを設置、マグマの動きの監視 (だったかな?) のため揺れの観測装置を設置、など、実際に設置されているところの写真や、気象庁の監視の様子 (本当にたくさんのモニターが並んでいて何かの映画みたい) もあった。 世界的にはインドネシアの火山が多い上に噴火による被害も相当らしくて、被害の人数で並べるとトップ 10 に 6 つもインドネシアが入ってくる、みたいな表が。 なおトップ 10 に日本では雲仙岳が入っていて、1991 年ではなく 1792 年の噴火のほう。
気象庁は噴火警戒レベル 1 から 5 で火山の情報を発表していて、2 以上はすべて警報であり、気象庁としては 2 以上の火山はすべて重点的にチェックしているらしい。 1 に関しては、時々巡回して調べる程度らしい。 鹿児島出身者としては気になる科学不信の碑の話を後でチラッと聞いてみたところもちろんご存じであり (気象庁 150 周年とのことでその 150 年の間に大正大噴火は起きているわけで)、現在は基本的にはあのときのようなことにはならないですとのことだったが、それはレベル 2 以上は警戒しているからだ。 レベル 1 に関してはそうじゃないんですねと聞いたら、まあその通りで、なので住民などから早急に報告が届くような体制を目指しているようだ。 昭和新山というのを質問されていた人もいた。 これは山でも何でもなかった畑が急に噴火して火山になってしまったらしい。 そういう事例は他にはないそうで... さすがにそういうのは難しいよなー。
防災講演会はそのくらいにして。 国立科学博物館って、鹿児島市立科学館みたいな、こう、触ると光る球体みたいなのがあるような、そういうイメージでいたんだが (笑)、全然違った。 それっぽいのは地球館のほうにあった気象観測衛星の仕組みや八木・宇田アンテナ、ラジオの電波を遮断してみようみたいなやつ、電磁気学系のそういう展示くらい。 他には人や動物、植物などの展示が多く、恐竜もあのジュラシックパークみたいな結構でっかいやつがひとつあったし、あと昔の家のつくり、木の種類や、屋根の仕上げなんかの展示があった。 それでさ、隣には別に東京国立博物館があるんでしょう? 訳がわからないよ! なお反対側の隣には国立西洋美術館があり... 少し離れたところに上野動物園と東京都美術館がある... すげぇわ東京...
あと、国立科学博物館の施設として、筑波実験植物園の名前がある。 そう、元筑波大学生なら名前だけは大変見覚えのあるアレである。 へぇぇぇ。
晴れ。 あつつつつ
上野へはバイクで行った。 要人来日都心交通規制ありみたいな表示は数日前から出ていたんだが、都心ってどこだ、まさか新宿じゃないだろ、ってわけで甲州街道をひた走っていたところ、新宿御苑を過ぎたあたりでなんか車線規制やっていた。 はぁ、それならこのへんなのね、早く言ってよね。 ってわけでそこを過ぎたなら関係ないやと半蔵門・皇居まで突っ走ったところ、やはりもう規制はなさそうだったが、何度も警察車両とすれ違った。 いやすれ違うのはいいんだが、やたらと制限速度を割ってけんか売っているみたいな走りの車が何台もいたのは何だったんだ。 前誰もいないんだからはやくいけ。 真後ろ見えているだろ。 ゆっくりしたいなら譲れ。 ブロックすんな。 秋葉原は中央通りは歩行者天国だっけと思って前職開発室だったところの前の道を通ってから末広町経由して上野方面、上野駅前自動二輪車駐車場というのが一日最大 800 円で結構台数も多くてペデストリアンデッキで日陰もあってヨシ。 ただし駅の地下通路を使わないと出入りできない。 上野は割とレトロな駅で、構内マップを見てもよくわからないけど、まぁ行きは公園を目指せばいいので何とかなる。
帰りはペデストリアンデッキをたどって駐車場が見えたはよかった、地上からは横断禁止の道路の向こうでたどり着けない島であることがわかっただけだった。 じゃあどこから駅の通路に入るのか、訳がわからない... 適当に戻って遠回りして入ったような感じになってしまった。 後で地図を見たらペデストリアンデッキで駐車場を行きすぎてから地下鉄のほうに降りるのが正解だったっぽいな。 地図見ないで入ったのは浅草口。 まぁ何とか駐車場には戻れて、帰り道は末広町で曲がってまた同じ道を戻り、今度は靖国神社前を通って、四ツ谷には行かずに新宿に向かった。 いわゆる旧アルタ前! その先分岐で甲州街道方面に向かってすぐ信号が右折信号になったので右折して (ぉぃ)、都庁の横の公園の道に左折して、どっかで右折するんだよなーと思っていたら首都高に乗りそうになったので側道に行ったら甲州街道。 ヨシ。 また甲州街道をひた走って帰ったがとにかく暑かった。
上野って良くも悪くも東京のごちゃごちゃ感が出ていてよい。 そもそも昔は常磐線なり東北方面への列車の始発駅だったわけだ。 そのせいってわけじゃないだろうけどややあか抜けない雰囲気がある。 そこに京成上野駅も加わり、「成田空港へ、一直線。」の文字がまたなんか田舎臭さを醸し出している。 そして西側に行くと上野公園で、上に書いたようにいろんな施設が集まっていて、たぶん 1 年間毎週のように来ても何かしら楽しめるものがあると思う。 公園では普通に音楽ライブみたいな音も聞こえてきていた。
晴れ。 相変わらず猛暑日・熱帯夜なんだけど、もうそろそろ小学校の夏休みも終わり始める頃なので、お天道様にはもうちょっと雲に隠れて頂かないと...
土曜日の ABEMA トーナメントの対局は無料で見られるようになっている:
ABEMAトーナメント2025 - 本戦 - [本戦 決勝戦]第9局 斎藤慎太郎八段 対 広瀬章人九段 (将棋) | 無料動画・見逃し配信を見るなら | ABEMA
これが最後の熱い対局だった。 チーム天彦は作戦勝ちとも言われるしそれはそうなんだけど、それは誰もが認める現役最強の藤井七冠に対して、いまいち調子が上がらない佐藤天彦九段が毎回相手となり、残る 2 人は藤井七冠以外の 2 人に全力を尽くせたことにあって、それができたのはチーム藤井のオーダーが読めていたからでもある。 広瀬九段は予選で一度藤井七冠に勝っていたこともあって、決勝でも当たる可能性を想定してはいたみたいだけど、結局はそうはならなかった。
放送中のテレビドラマ『ちはやふる―めぐり』でも「オーダー読み」が出てきたところだった。 競技カルタと違って将棋のチーム戦は歴史が浅いけど、オーダーについてはある意味考え方は似たものがありそう。
未だに GNU Emacs を EUC-JP で使っている自宅サーバー PC。
なぜだかわからないけど EUC-JP の a1bd, ダッシュ記号がなぜか \u2015 と出てくる。
と思ったら shell の出力を介したらちゃんと出る。
はて?
C-x = で確認すると微妙に差がある。
8213, #o20025, #x20158212, #o20024, #x2014保存すると同じなのだけど Unicode に差があるわけだ。 GNU Emacs 的にはどちらも同じ EUC-JP に変換されて保存はされるが、画面上は上は変換されずに出るという差がある。 iconv は上、nkf は下を使っているみたい。 ATOK の出力は Unicode なのかな? それが上になっているから妙なことになったみたいだ。
この前 QuickJS について調べたときに知ったんだけど、JavaScript には BigInt というのがあるらしい。
符号付きの整数型で、クソデカ数を扱える。
数字の後ろに n を付けると BigInt 型の定数になる。
Firefox の Developter Tools Console で試すと、2n**(65536n*8n) は出る。
つまり 2 進数で表しても 64 KiB + 1 ビットもの長さを必要とする整数値が表せる。
おもしろいなと思うのは、結構潔い仕様ながら非常に役に立ちそうなところ。 Visual Basic には Currency 型というのがかなり昔からあって、これは 64 ビットの固定小数点の型だった。 BigInt は小数の扱いは捨ててプログラムで何とかしろという代わりに、64 ビットなんていうちんけな制約を取り払っているのだな。
晴れ。 相変わらず猛暑日・熱帯夜。 出社した。
職場近くの時間貸しバイク駐車場は数カ所あるが、もっとも近いのは自治体がやっているやつで、台数は多いんだけど安いので満車率が高め。 ただしこの季節は空いていることが多い。 学生の夏休みとの関連が疑われる。 んで、その次に近いところは大型二輪も OK の民営のところだが、近隣の中でももっとも高い。 12 時間で 660 円ぐらいの設定だったはずだが、今日見たら 700 円になっていたような? まぁ、数年前まで 550 円だったのが、660 円になってからは満車率は下がったような気がするし、700 円になったならさらに空くかな?
三鷹の電車庫のところの跨線橋、2023 年に閉鎖されてから、しばらくはそのままで、去年の途中くらいからだっけ、のんびりと撤去工事が進み始め、でっかいクレーンでがっつりやっていたのが今年の年明け頃だったっけな。 その後、北側の階段部分が最後まで残っていたのが、今年ゆっくりと解体されてきて、今はそれも完全になくなって工事完了の様子。 そこのバス停は未だに跨線橋前だけどね。
職場で最近ほとんど使っていないパソコンの Debian を 13 にアップグレードしていたら、例によって時間で画面ロックされてしまい、解除できなくなって、スクリーンセーバープロセスを探したんだけどなかった... Xfce だったんだけどそのへん MATE とは違うのか? だいぶ焦ったけど、幸い apt コマンドはもう終了していたので、再起動で問題なかった。
Linux のコンソール、最近の高解像度ディスプレイではフォントをめいっぱい大きいのにしても文字が小さすぎる問題があって厳しいが、さらに、ディスプレイが省電力モードに入らないケースも... 結局は、X サーバーと軽めのディスプレイマネージャー、LXDM ぐらいは入れておいたほうが何かと都合がいいのかも知れない。 Wayland も軽いやつあるのかな? あってもよさそうだよな、知らんけど。
QuickJS の性能はどんなもんなのかと、前に C やアセンブリ言語で書いた、N クイーン問題を解くプログラムを、JavaScript に書き直して実行してみた。 N=8 から N=15 まで出す。 Ryzen 5 3500U で雑に計測。
gcc -O3 (native): 0m0.777semcc -O3 (WebAssembly) + node: 0m1.156semcc -O3 -sWASM=0 (asm.js) + node: 0m1.348semcc -O3 -sWASM=0 (asm.js) + 一部書き換え + qjs: 1m20.699s相変わらず Node.js は速い。 QuickJS には just-in-time (JIT) compiler がないので、こんなものかな。 特にこの手のプログラムには JIT がきくだろうし。
QuickJS だと Emscripten の asm.js はエラー出力の処理がかみ合わないみたいで、そこだけ消して試した。 実行時間も長くて、さすがに JIT なしで実行するには asm.js は冗長になってしまうようだな。
晴れ。 熱帯夜は回避できても相変わらず猛暑日。
夜ちょっと車を動かしたら、明らかにスターターモーターの回り方が重かった。 おお。 この暑い中でこの調子だといよいよバッテリーの寿命が来るか? (←とっくに寿命だろという突っ込みはなしで。) まぁ最近あまり遠くまで乗っていないので充電不足になっている可能性が高い。 一回 20 分未満で止めるような乗り方だとだめだろうね。 交換からもうすぐ 12 年になるので内部抵抗が高くなっているのは間違いなくて、ちょっとした充電不足でも大きな電圧降下につながってしまうんだろうな。
晴れ。 少し涼しくなった (真夏日 & きのうから今日にかけては熱帯夜)。
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 位。
トップ争いでマシントラブルによるリタイアは結構残念なんだよな。 前兆があったならともかく、普通はドライバーが悪いわけじゃないし。 最近では珍しい気がする。