きのうの夜は暖房無しで寝られた。 室温 13 度ぐらいあるとまぁ、何とかなるもんだな。
未明に降っていた雨は昼前にとっくにやむ予報かと思っていたが、昼ご飯の頃はまだ降っていて、食べ終わって店を出てきたら日が差し始めていた。 そんな天気。
F1 はシーズンオフであまりニュースがないと思って読む頻度が下がっているが、フジテレビの F1 解説で有名な今宮純氏が、今年初めに亡くなっていたという、10 日のニュースを今頃知った。 あらら。 有料放送になってからフジテレビの F1 中継は見ていないため、あの声は懐かしい感じだが、F1 ニュース記事ではまだ名前を見かけていた。 虚血性心疾患とニュースに出ているので突然のことだったみたい。RIP。
なんか急に冷えてきたというか、週末の天気予報に雪マークが付いている。 その割には気温は低くない予報。 来週は最低気温が低そうだが、それでも氷点下行くか行かないかぐらい。 暖冬か。
足し算引き算で符号の扱いはどうしているのだろうか、と考えてみたんだけど、単純に、人がやるのと同じように、符号を見て、符号を除いて足し算をするパターンと、符号を除いて大小比較をして、どっちかの向きで引き算をするパターンに分ければいいのか。 コンピューターちっくに 10 の補数なんて手も考えてみたけど、電卓の作りには合わない気がする。
買った電卓には +/- キーが付いている。1+ と押してから、+/- キーを押して、それから 2= とすると、1 と出る。+/- キーはその時の状態にかかわらず、画面に出ている内容の符号を反転するというわけである。
なお、もしパソコンで動く 8 桁電卓のシミュレーターを作りたいだけなら、今時なら 32bit 整数値を使って作ってしまったほうが楽だと思う。 いや、10 桁や 12 桁だとしても 64bit 整数値を使えばいい。 小数については、2 進数の浮動小数点で扱うと誤差が出てしまって、電卓らしい挙動にならないので、32bit や 64bit の整数値に 10 のべき乗 (0 以下) を掛けた数として扱うことになると思う。 その形式なら入力中に 0.000 などとなっているところも表現ができる。 符号については、入力時は -0 があり得るので別扱いがいいが、計算後は -0 はあり得ないので 2 の補数で扱ってもいいのかな。
と、まぁ、考えていると、小型化された電卓というのは日本ではそろばんを置き換えるものとして登場して普及したんだな、という気がしてきた。 そろばんは雑に言えば数の記憶装置であり、それこそ家計簿を付けるだとか、買い物をする時の合計金額を出すだとか、そういう時に計算を間違えにくいように使われていたわけである。(自分が子供の頃にはすでに電卓やレジが普及していたけど、どこかの小さな商店でそろばんが使われているのを見たことがある気がする。) 電卓も数の記憶装置だけど、計算もしてくれる。 コンピューターらしい 2 進数による計算ではなく、10 進数で計算してくれるので、まさにそろばんをはじくのと同じ結果が得られる。
その後、より多くのデータを計算する目的では、パソコンの表計算ソフトも普及したんだけど、それは 2 進数による計算が一般的なので、小数を扱う場合は注意が必要である。IT 業界ではよく知られている話だけど、例えば 10 進数の 0.1 は 2 進数では循環小数になる。 軽い気持ちで +0.1 とか +0.2 とかした数を扱うと、引き算などで簡単に誤差に遭遇してしまう。 例えば 0.1 の桁までしか使わないことがわかっているなら、あえて 10 倍した整数値を使うといった工夫が必要になることもあり得る。 電卓を使うのにもしそういう知識が必要だったとしたら、そろばんがもっと生き残っていたかもね?
職場のビルの停電案内、突入電流のおそれがあるから機器の電源は外しておいてくれというのはいつもの案内だけど、機器の例としてペンタブというのがあって、ペンタブって省略形は一般的なのかなと思いつつ、それってあのスタジオ会社以外にあるんだろうかと...
DAA 命令。 TF テストプログラム使用。JMP FAR AL により ALU の手前のテンポラリーレジスターに残っている値を調べた。
上位 8 ビットは 0xff、8 ビットのメモリー読み取り時と同様の挙動で、下位 8 ビットには足した数が残っているっぽい。 ...えっ? DAA 命令って 2 回に分けて足すんじゃなかったの? そうか。 結果は同じだから、ALU の使用回数を減らすために、まとめて足していたのか。 ということは、どちらかと言えば現行の Intel SDM に載っているオペレーションに近いのでは? 9 との比較で AF と CF を必要に応じてセットして、AF と CF に基づいて足す数を作って、加算実行、みたいな。 そしてたぶん、9 との比較は ALU 使わないでできるようにしてあって、それで 4 クロックで済んでいるのかも。0x99 との比較は下の 9 との比較結果と上が 9 と等しいか大きいか、そのへんの組み合わせだろうな。 この前みたいに JavaScript 風に書けばこんな感じ:
function daa(AL,CF,AF){
if((AL&0xf)>9)AF=1;
if((AL&0xff)>0x99)CF=1;
AL+=(CF?0x60:0)+(AF?6:0);
return [AL,CF,AF];
}
この様子で行くと DAS 命令も同じノリだろうから、DAS 命令は一部の組み合わせだけ試そう。
やはり同じだな。 フラグは OF が未定義だが、見た感じ普通に演算結果が反映されているかな。DAA 命令のほうもオーバーフローになる値を試してみよう。
それっぽい。AAA 命令については先月少し試したが、その前半の処理、AL に対して足し算を行う部分は DAA 命令の半分と同じだと思う。SF 何これって書いているけど、もしかして足し算の時に出た SF が残っているのかな。0 でも足しているってことかな。AND はどうやっているのかよくわからないけど、ハードウェア的に下位 4 ビットだけを取り出す仕組みを作ってあるのだろうか、あるいは、AH に 1 を足すだけに 4 クロックもは掛からず、ALU で AND までやっているのかも知れない。
しかし... クロック数のチェックでは AAA 命令はどうやら足さない場合に 1 クロック長いっぽいことが判明している。 なんでだろうな? フラグレジスターの関係だろうか? DAA 命令の感じで行くと、AF も CF もセットだけでクリアはしない。AAA 命令も AF はセットだけで良いけど、CF については AF と同じ値にセットするなりクリアするなりしなければならない。 例えば AAA 命令は DAA 命令の半分だけでいいので、CF も AF と同じようにセットするような仕掛けがあるのか? それで CF のクリアが必要だと 1 クロック追加になるのか? いや、もしかして半分じゃなくて、全部、完全に DAA 命令と同じことを一度やっているかも? どうせ 0xf でマスクしちゃうから、途中で何やっていても結果はわからないんだよね。
その AAA 命令をもうちょっと試すか。
フラグの様子を見る限り、未定義の OF, SF, ZF, PF はすべて、AND を取る前の AL の足し算の結果と見てよさそう。 そして、0x9f を超える値を AL にセットしていても、SF がセットされている、つまり、0x66 を足した結果にはなっていないので、DAA 命令と全部同じことをやってはいないらしいことが把握できた。
しかしそうすると、やっぱり 1 クロックは不思議だな。 素直にフラグを反映しながら 0 を足せば AF も CF もクリアできるんだから、何も難しいことはなさそうなものだけどな。 まぁそれを言ったら AH だってそもそも AL に変更がないなら足す必要もないので、マイクロコードってそこまで制御の自由度はないものなのかも。 かけ算割り算はだいぶクロック数に幅があるから自由度高そうに見えるんだけどな。AAA 命令も、AH の足し算は CF と一緒に 0 を加える ADC 命令相当のことをやっていそうな気が。
寒い日。 雪が降った。
JavaScript は、計算のアルゴリズムを試すくらいなら非常に便利だなとあらためて思った。HTML に適当に JavaScript を書いて web ブラウザーで開いて確認するだけでなく、web ブラウザーに付いている Web Console 機能を使えばその場で変数の中身の確認や各関数の呼び出しもできるし、console.log() を使って途中経過を Web Console に出力させることもできる。Web Console には地味にコマンドヒストリー機能も付いているし、複数行の入力も可能だし、関数の中身を差し替えることも可能である。
こうして遊んでいると、やっぱり、昔のパソコンの BASIC にあたるものは JavaScript じゃないかと思うのである。 ややとっつきにくさがあるかも知れないが、今時のオペレーティングシステムが普通にインストールされているパソコンさえあれば、他のソフトウェアの購入やインストールが一切不要で、すぐに実行結果が確認でき、簡単な計算から、興味があるならアクションゲームみたいなものまで作れる。 問題はとっつきにくさかな、コンピューターで計算がしたいというならまだ触りやすいと思うが、インタラクティブなアプリケーションを作ろうと思うと HTML の知識が必要になるのでわかりにくいかも。 そういう人向けの情報がまとまっている本があればいいんだろう。(ないわけがないけど。)
足し算引き算の場合、小数点の位置を合わせて計算することになるが、この位置あわせは最初に行われ、はみ出す桁はそこで捨てられる。 例えば 8 桁の電卓で 99+0.000001 はもちろん 99.000001 で 8 桁に収まっており何も問題はなく、99.999999 もキャリーが処理されて正しく 100 になるが、さらに足しても 100 より増えない。 足し算ではおそらく、どういうアルゴリズムで処理しても、数字 8 桁分で切り捨てるならそうなると思う。 しかし、反対に 100-0.000001 を計算しても 100 が出てくる。 同じ 8 桁処理であっても、アルゴリズムによっては以下のような流れで別の数になるのではないかと考えたが、そうではなかったということだ。
0.0000000 (0 に 1 桁ずつ答えを入れていく形でスタート) 0.0000009 (0.000001 の 1 を引く時に対応する桁がないため 0 と見なして計算) 0.0000099 (以下ボローを処理) 0.0000999 0.0009999 0.0099999 0.0999999 0.9999999 9.9999999 99.999999 (100 は百の位まであるため、ここで一番下の桁を捨ててボローを処理) 099.99999 (もうひとつ桁を捨ててボローを処理し 0 が出る) -> 99.99999
なお、桁数が多い 10 進数の演算の確認には bc -l コマンドを使用している。 これはデフォルトで小数点以下 20 桁の演算ができる便利なコマンドである。
電卓内部にはもう少し多い桁数のバッファーがあるのではないか、と想像していたがちょっと違うかも知れない。 かけ算、どうしているんだろうな。 ひとまず桁あふれを簡単に調べたところ、2.1111113×9 みたいな計算をしても 19.000001 と出ており (一番下の 7 が切り捨てられている)、下の桁から計算していそうな雰囲気はある。(上からやれば 2×9 の時点で 18 が出てしまい、一番下の桁にたどり着かないと見た。)
平方根は、ずいぶん昔に開平法のやり方を教えてもらって、BASIC でその方法で 10 進数演算のプログラムを書いたことがあるが、開平法のやり方は忘れてしまった。 しかし、ぼけっと数学的に考えていたら、うまくやれば足し算引き算だけでもできそうだなと思った。(x+1)^2-x^2=2*x+1、というシンプルな関係があるので、各桁を 1 ずつ増やして大小比較をして確定させていくのはそう難しい話ではないんだ。 足し算引き算だけにするのは置いておくとして、頭の中で考えていた方法をもとに、試しに 200000000 の平方根の整数部分 14142 を整数演算で求める簡単なプログラムを書いてみると以下のようになった:
(function(x){
var a=0,c=1,c2=1;
while(x>=c2)c*=10,c2*=100;
while(c>=10){
c/=10,c2/=100;
var d=c2+2*c*a,dd=c2+c2;
while(x>=d)a+=c,x-=d,d+=dd;
}
return a;
})(2*100000000);
これもやっていることは実は開平法と同じかも知れない。2*100000000 の 2 を 1 から 9 まで変えて試すと結果は以下のようになった:
10000, 14142, 17320, 20000, 22360, 24494, 26457, 28284, 30000
よさそう。
そういえば、きのう・今日とセンター試験の日だったな。 たまたま通りがかった国立大の最寄り駅の前や、私立大の入口前に、センター試験関連の誘導担当っぽい人や、センター試験会場の看板を見かけた。 センター試験って今年が最後らしいけど、始まったのは 1990 年らしい。 へぇー。 なんとなく昭和から続いていたのかと思っていた。 その前は大学共通第 1 次学力試験という似たようなのがあったものの私立大は別だったらしい。
東村山のほうのハードオフまでバイクで行ってみた。 ふんふん。 それから東大和のほうに向かおうとしたら、なぜか新青梅街道の案内がなくて久米川駅のロータリーを抜ける羽目になってしまった。 なんで案内がないんだよw ひでぇなw
噂の Microsoft Edge の新しい Chromium ベースのバージョンを自宅 Windows PC にインストールしてみた。 この PC では前から Microsoft Edge を主に動画再生に使っていて、それは動画再生の調子が良いのが理由。 それと、Mozilla Firefox はプライベートブラウジングの設定にしてあるので、有料動画配信サービス DAZN にログインしっぱなしにしておくのに便利というのもある。 別の格安ノート PC でも有料動画配信サービス DAZN の動画再生がなめらかという事例もあって、結構大事なポイントなのである。
で、インストールしてさっそく DAZN を開いてみると、ログインされていない。 クッキーは飛ぶのか。 なんてやつだ。 移行してくれよ。 まぁいいや。 ログインして、適当に動画を再生しようとしたら、エラー 11_012_012。 おいおい、なんだよそれ、困るよ。 アニメが増えていてタッチがあったので選んでみたけどやっぱりエラー。 何かエラーなく再生できる動画はないか、探したら、サッカーの見逃し配信が再生できた。 しかし... ちょろっと 2, 3 秒再生しては、10 秒ほどくるくる表示で止まる、のを繰り返している。 タスク マネージャーで CPU 使用率を見るとめちゃくちゃ高い。 タブはひとつしか開いていないのに Microsoft Edge がいくつもあって、しかもそれらがめちゃくちゃ CPU リソースを消費している。 えー。
動画サイト全般がだめなのかと、YouTube を開いてみたら、YouTube は問題なく再生できる。 画質を 1080p にしても問題なさそう。 つまり DAZN 側の問題はあるのかも知れないが、しかし今までの Microsoft Edge ではむしろスムーズに再生できていたのである。 まぁ何か DAZN 側が変わったのかも知れないので、新しい Microsoft Edge をアンインストールして、今までの Microsoft Edge で DAZN を開いてみると、エラー 11_012_012 も出ないし、サッカーの試合も引っかかりなく再生できた。 ウーン。
アンインストールするとなんでアンインストールしたのか理由を教えてみたいなページが開いた。 なぜか英語だったので、クソみたいな英語で DAZN 見られないから消した的なことを書いておいた。4 月になったら勝手にアップデートされちゃうんだっけ? どうすりゃいいんだよ...
特に問題がないという人もいると思うけど、たぶん低スペック PC での動画再生がやばいのではないか。 自宅 Windows PC は Athlon 5350 をクロック周波数を落として 1.1GHz で使っているし、格安ノート PC は Atom x5-Z8350 だから、試していないけどおそらくさらに厳しいやつだ。(昨今の CPU の脆弱性対策のため同程度のスペックでも Intel CPU のほうがより厳しい状況になる。) GPU の動画再生支援が働かないのか? でもそれなら YouTube が問題ないのは説明ができない。 単に Chromium の実装がタコなのでは...
そんなわけで Chromium を試してみたらどれもエラー 11_064_011 で再生できなかった。Mozilla Firefox では再生はできるんだけど、やや重そうな感じ。
138 円/l。 燃費計算 17.8km/l。 燃費表示 20.5km/l。
前回の給油が雑だったのでこれである程度補正される。 前回分と合わせて計算すると 19.7km/l になる。
かけ算のやり方を考えていた。 きのうの 2.1111113×9 のように、下の桁からやっていそう、しかし出力が 8 桁なのでどこかで切り捨てをしなければならない、じゃあ下の桁から確定していく方法かな、などと考えていたのだけど、下の桁から確定していくのはそれはそれで面倒な上にありがたみが少ない。 一番下の桁同士を掛けたら一番下の桁が確定し、2 番目の桁と 1 番目の桁の組み合わせ (2 個) をそれぞれ掛けて足せば 2 番目の桁が確定し、というふうな計算は理論的には可能だけど、一番下の桁が確定した時に 2 番目の桁へ繰り上がるというか、2 桁目の数があってそれを残しておかなければならず、しかも被乗数と乗数を最後までとっておかなければならないので、メモリーに制約がある場合はなかなか厳しそう。
で、そういえば 4004 には乗算命令はない。1 桁同士のかけ算結果を小さな ROM に載せておくことは不可能ではないだろうが、1 桁同士のかけ算結果の 2 桁を足していくにしても、キャリーを処理しなければならないので、毎回何桁もの足し算を行う羽目になる。 それだったら... 普通に全桁の足し算をしてもよくないか? 少なくとも計算用に 8 桁のメモリーが追加で必要なのは間違いなさそうだし、一番下の桁からやるなら 0 にして桁あふれのキャリーをそこに足すようにすれば、例えば 2.1111113 を 9 回足して、9.0000017 と、桁あふれの 1 が 9 のところに代わりに入る的な感じで... (あまり深く考えてはいないので何か間違っているかも知れない。)
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU