ノートPCと飛行機
2025.08.18
ノートPCは、手荷物検査でカバンから出し、トレイに入れて検査機に通さなければならないのでひと手間かかります。
上着を脱いでトレイに載せろとか、ズボンのベルトもはずせとか、ポケットの小銭とか、ただでさえ面倒くさいのに。（恨むならテロリストを恨め）
たぶんバッテリーが問題になるのだろうから、取り外し可能な機種なら取り外して（家に置いて）持ち込んだらどうか？と思いつき。その場合、検査に通さなくて良いのかどうか。
外出先ではバッテリーで使えなくて不便と思うだろうけど、だいたいコンセントのある場所で使うので問題なし。バッテリー自体、劣化していてあまり役立たない。
たぶん、バッテリーの有無にかかわらず、検査に通せと言われるだろうなと。かえって、そこで係員とのやりとりで時間をとられそう。
ただでさえ面倒くさくてイライラしている人がいて、つい感情がでてしまい「爆弾を仕込んだ」とか冗談を言えば、しゃれにならん結果に（笑）
私、個人的には（過去の経験から）手荷物検査をスムーズに抜けたいので、とにかくなんでも預けてしまい、手元にはスマホだけといった具合。スマホは搭乗に必要。
だから・・・まだ時間があるからジュースでも、と思ったらポケットにお金が無く、なんとかペイはスマホから消しちゃったから使えず、というオチも。
ノートPCは預け荷物にもできるが、破損の可能性がある。あまりおすすめではない。
専用のクッションカバーとか着替えなどでしっかり包んでおけば、気休めにはなるかなと。
海外に行った時に預けたが、盗まれる事も壊れる事もなく、でもたまたまかもしれない。
出張先には宅急便で送っておくという手がある。往復送料はかかるけど、ほかの資料とか機材も仕事で使う必要があればそうした方が良さそう。なるべく身軽に移動したい。
空港は知らないうちにルールが変わっていたりするので、最新情報を確認したほうが安心。
上着を脱いでトレイに載せろとか、ズボンのベルトもはずせとか、ポケットの小銭とか、ただでさえ面倒くさいのに。（恨むならテロリストを恨め）
たぶんバッテリーが問題になるのだろうから、取り外し可能な機種なら取り外して（家に置いて）持ち込んだらどうか？と思いつき。その場合、検査に通さなくて良いのかどうか。
外出先ではバッテリーで使えなくて不便と思うだろうけど、だいたいコンセントのある場所で使うので問題なし。バッテリー自体、劣化していてあまり役立たない。
たぶん、バッテリーの有無にかかわらず、検査に通せと言われるだろうなと。かえって、そこで係員とのやりとりで時間をとられそう。
ただでさえ面倒くさくてイライラしている人がいて、つい感情がでてしまい「爆弾を仕込んだ」とか冗談を言えば、しゃれにならん結果に（笑）
私、個人的には（過去の経験から）手荷物検査をスムーズに抜けたいので、とにかくなんでも預けてしまい、手元にはスマホだけといった具合。スマホは搭乗に必要。
だから・・・まだ時間があるからジュースでも、と思ったらポケットにお金が無く、なんとかペイはスマホから消しちゃったから使えず、というオチも。
ノートPCは預け荷物にもできるが、破損の可能性がある。あまりおすすめではない。
専用のクッションカバーとか着替えなどでしっかり包んでおけば、気休めにはなるかなと。
海外に行った時に預けたが、盗まれる事も壊れる事もなく、でもたまたまかもしれない。
出張先には宅急便で送っておくという手がある。往復送料はかかるけど、ほかの資料とか機材も仕事で使う必要があればそうした方が良さそう。なるべく身軽に移動したい。
空港は知らないうちにルールが変わっていたりするので、最新情報を確認したほうが安心。
2025.08.18 10:06
| 
乱数(MSXの)
2025.08.17
MSX BASICのソースを見れば乱数発生の仕組みがわかると思うけど、いや、昔調べたような気がする。覚えてない。
学生時代に同級生がテトリスを自作して、その時に使った乱数ルーチンはMSXのROMではなく、独自に組み込んだもの。Z80マシン語秘伝の書に載っていた乱数ルーチンをアレンジしたと思う。
当時でも議論したけど、じつは乱数ってのは意外と難しく、完全な乱数って作れないのです。
BASICに内蔵されている乱数は、算術乱数というやつだったと思う。計算で次の値を求めている。どうしても偏りがある。
ある数に別の数をかけたり足したりして、その下位桁を取るとか、そんなやり方です。だからパターンが決まってしまう。不確定な要素が含まれてないわけ。
MSX-BASICにはTIMEという変数(カウンタ)があって、1/60秒ごとにインクリメントされているから、これを利用する手がある。何か押した瞬間の値を取るとか。プログラムをRUNした時に値を取り込んで乱数の種にする。
別に、TIMEに依存しなくても入力を待っている間にカウンタを適当に回しておいて、HIT ANY KEYで押した時の値でも良い。
パチスロ機の場合は、ハードウェアカウンタを回しておき、レバーを叩いた瞬間の値をとるというやり方でした。
これは昔、体感機で同期できてしまっていたので、その後に対策がとられて、ずっと高速で回るようになっていると思われます。
完全な乱数が必要なら物理乱数になります。電気的なノイズを利用したものがよく使われると思うけど、それだって外乱を受けるようではダメです。
MSX用乱数発生カートリッジとか？ 需要ないだろうな。
あと、円周率を小数点以下何万桁までテーブルに記憶しておいて、そこから値を拾ってきて使うと乱数代わりになると本で読んだ事があるけど、良いのかどうか知らない。
この場合でも、順番に読むんじゃなくて、さっきのキーを押したタイミングでどこを読むかというやり方を組み合わせたものだと良さそう。
乱数の再現性を求める場合は、あらかじめデータとして蓄えておかないといけないな。ゲーム等では再現性は求めない場合がほとんどだろうから、いかにばらつかせるか、偏らせないかということになる。
学生時代に同級生がテトリスを自作して、その時に使った乱数ルーチンはMSXのROMではなく、独自に組み込んだもの。Z80マシン語秘伝の書に載っていた乱数ルーチンをアレンジしたと思う。
当時でも議論したけど、じつは乱数ってのは意外と難しく、完全な乱数って作れないのです。
BASICに内蔵されている乱数は、算術乱数というやつだったと思う。計算で次の値を求めている。どうしても偏りがある。
ある数に別の数をかけたり足したりして、その下位桁を取るとか、そんなやり方です。だからパターンが決まってしまう。不確定な要素が含まれてないわけ。
MSX-BASICにはTIMEという変数(カウンタ)があって、1/60秒ごとにインクリメントされているから、これを利用する手がある。何か押した瞬間の値を取るとか。プログラムをRUNした時に値を取り込んで乱数の種にする。
別に、TIMEに依存しなくても入力を待っている間にカウンタを適当に回しておいて、HIT ANY KEYで押した時の値でも良い。
パチスロ機の場合は、ハードウェアカウンタを回しておき、レバーを叩いた瞬間の値をとるというやり方でした。
これは昔、体感機で同期できてしまっていたので、その後に対策がとられて、ずっと高速で回るようになっていると思われます。
完全な乱数が必要なら物理乱数になります。電気的なノイズを利用したものがよく使われると思うけど、それだって外乱を受けるようではダメです。
MSX用乱数発生カートリッジとか？ 需要ないだろうな。
あと、円周率を小数点以下何万桁までテーブルに記憶しておいて、そこから値を拾ってきて使うと乱数代わりになると本で読んだ事があるけど、良いのかどうか知らない。
この場合でも、順番に読むんじゃなくて、さっきのキーを押したタイミングでどこを読むかというやり方を組み合わせたものだと良さそう。
乱数の再現性を求める場合は、あらかじめデータとして蓄えておかないといけないな。ゲーム等では再現性は求めない場合がほとんどだろうから、いかにばらつかせるか、偏らせないかということになる。
サイコロ、オモテとウラ
2025.08.17
プログラムが残っていました。中学生の頃の古いノートからです。
改良前のプログラムで、バカ正直にIF文で処理しています。
バカだなあ・・・と笑ってやってください。
一方で、動けばいいんだ、という考えの方もいらっしゃると思います。
オモテとウラ、というのはコインの裏表の確率をシミュレーションしています。
乱数RNDはゼロから指定の数値未満まででした。確か。
それにわざわざ+1して1～6にしたのでしょうけど、最初から1～6を0～5に置き換えて処理したって構わないわけです。
表記としてはわかりにくくなるかもしれませんが、計算をひとつ削って処理時間を少しでも節約できます。
冒頭のRND(-TIME)は乱数のタネでしょう。（初期値）TIME変数を元にしています。
それから、
いま何回目かを常時表示しているとその表示に時間をとられます。そこで、たとえば100回とか1,000回おきに表示したかった。
これも馬鹿正直にIF文で判定させています。そうじゃなくて、1,000で割り切れて余りが0かどうか見ればよかったのではないか。あるいは、別にカウンタを回してIFで判定するほうが早ければそっちを採用しても良かったのではないか。
当時そのことは気づいていて、実際にそのような判定を入れた記憶があります。
処理速度を上げるには、整数型変数を使うようにプログラム先頭にDEFINT A-Zとすれば改善が見込めたものと思います。
しかし32767までしか扱えないのと、相対度数の計算で小数点が出てきます。
とりあえず3万回までのシミュレーションに限定すればよいでしょう。
あとは、相対度数の計算に関係する変数だけ浮動小数点のままにすればよかったでしょう。
改良前のプログラムで、バカ正直にIF文で処理しています。
バカだなあ・・・と笑ってやってください。
一方で、動けばいいんだ、という考えの方もいらっしゃると思います。
オモテとウラ、というのはコインの裏表の確率をシミュレーションしています。
乱数RNDはゼロから指定の数値未満まででした。確か。
それにわざわざ+1して1～6にしたのでしょうけど、最初から1～6を0～5に置き換えて処理したって構わないわけです。
表記としてはわかりにくくなるかもしれませんが、計算をひとつ削って処理時間を少しでも節約できます。
冒頭のRND(-TIME)は乱数のタネでしょう。（初期値）TIME変数を元にしています。
それから、
いま何回目かを常時表示しているとその表示に時間をとられます。そこで、たとえば100回とか1,000回おきに表示したかった。
これも馬鹿正直にIF文で判定させています。そうじゃなくて、1,000で割り切れて余りが0かどうか見ればよかったのではないか。あるいは、別にカウンタを回してIFで判定するほうが早ければそっちを採用しても良かったのではないか。
当時そのことは気づいていて、実際にそのような判定を入れた記憶があります。
処理速度を上げるには、整数型変数を使うようにプログラム先頭にDEFINT A-Zとすれば改善が見込めたものと思います。
しかし32767までしか扱えないのと、相対度数の計算で小数点が出てきます。
とりあえず3万回までのシミュレーションに限定すればよいでしょう。
あとは、相対度数の計算に関係する変数だけ浮動小数点のままにすればよかったでしょう。
