micro:bitのプログラミングがある場所では動作しなくなる?

ちょっとmicro:bitのプログラミングに関していろいろとやってみる機会があったので使っていたのですが、その中で気が付いたこと。ほかのサイトでも書かれていますが、こちらでもちょっと触れてみたいと思います。この件は一部の環境の人にはとんでもなく刺さる問題になっています。

 

micro:bitの主要なプログラミングツール

皆さんが使うのは大体このあたり、ということで示しておきます。

Microsoft MakeCode for micro:bit (https://makecode.microbit.org/)

インターネット環境とブラウザでプログラミングできる環境として有名です。使おうと思えばAndroidでもiOS系でも使用可能です。その場合は作成したhexファイルをどうやって転送するのか、を考える必要があります。ちなみに2020年6月にバージョンアップしてv3になっています。そのため、いくつかのブロック(Scratch)が追加されていたり、対応言語が増えているなどかなりの恩恵があります。対応している言語は「Scratch」「JavaScript」「Python」です。Pythonの場合はパッケージ指定がいらないので作成にはもってこいかもしれません。しかしながら、このバージョンアップがある悲劇をもたらしています。それは後ほど。

Micro:bit offline App – MakeCode (https://makecode.microbit.org/offline-app)

こちらはインターネット環境およびブラウザが利用できない場合に利用可能な方法です。Windows10とMacOS対応です。インストールが必要なのが欠点ですが、v3ベースの開発環境が使えるので実験する量が多い人はこちらをインストールしてしまうのもありかもしれません。Windows10の場合はストアアプリから同様のものを手に入れることが可能です。言語はオンラインv3版と同様。

Python Editor for micro:bit (https://python.microbit.org/)

Pythonを使う、と決めているならこちらを使ってみるのもよいかもしれません。こちらの場合はMicroPythonで動かすことを前提にプログラムを組むのでMakeCode版とは微妙に作り方が違うことに注意が必要です。ファイル転送に関してもpyファイルおよびデータファイルを指定すればhexファイルにくっつけた形で転送可能です。プログラムのサイズに限界があるmicro:bitにとってはデータファイルが使えるのでうまく組めばMakeCode版に比べて規模を大きくすることが可能です。

Muエディタ (https://codewith.mu/)

Pythonのエディタです。こちらに付属するmicro:bitの転送ツールを使うとpyファイルおよびデータファイルを転送することができます。こちらもMicroPythonベースですので気を付けましょう。

Androidアプリ or iOSアプリ

スマートフォンしか手元にない場合はこれらのアプリを使って作成&転送ができます。転送方法はBluetoothで、micro:bit側を特殊な待機状態にしてペアリングし、プログラムデータを転送します。失敗するとPCからhexファイルの送り直しになるという救援が必要ですが、ちょっとした実験やPCが台数分確保しづらい学校環境などではこれをインストールしてもらって実行する、というのもありかもしれません。

 

MakeCodeのブラウザでIEのサポートが外れたため大変なことに

v3へとバージョンアップしたときにInternetExplorerのサポートが打ち切られました。これ自身はまあかなり古いブラウザので仕方がないのかもしれませんが、ちょっと問題になっているらしいのが「学校で使用できるブラウザとしてInternetExplorerが強制されていることが多く、サポートがなくなって使えなくなってしまう」というものです。学校の環境では自由にインターネットをさせるとまずい場面があるため、それの制限が必要なのですが、IEを使用させてEdgeを使用不可にしている、というパターンが多いようです。このため、プログラミング演習がちょっと厄介なことになっています。

 

回避策は…

学校環境を前提にしていくつかありますが、どれも微妙です。

・MakeCodeのv2版を使う

一応過去版が使用可能です。過去版はv2版でURLに直接「/v2/」を入れる必要がある、つまりhttps://makecode.microbit.org/v2/への直接リンクが必要で、入力作業がかなり面倒だったりします。まあ、ショートカットを使ってごまかすことはできそうですが…ほかにもv3版で追加されたブロックやPythonが使えないこと。さらに根本の問題としてMakeCodeのv2版の期限が2022年まで、ということであと2年後にはIEの制限が解けない限りは同じ問題が起こることになることです。管理ソフトを作っている人たち、この問題は早めに解決しておかないとそもそもIEで正常にアクセスができないサイトがだいぶできていて問題ですよ、と言いたい。G Suite関係もサポート外になりそうですし。

・オフライン版のインストール

PCへのインストールが可能ならばこれで避けることは可能です。しかもv3版になりますのある程度新しい部分まで使うことができます。問題点は「インストールが可能ならば」のポイントで、環境を変えてしまう等の理由で認められない場合には使うことができません。無念…。

・Android版やiOS版のアプリを導入したタブレットで行う

特にコード入力ではなくScratchによるプログラミングを行うことが前提となる小学生レベルならばこのほうが逆に簡単かもしれません。問題は必要となる台数を確保できるか、というところ。まあ、このコロナ禍の影響でコンピュータなどの導入計画が早まっていますのでアプリが導入できるならこちらもありかもしれません。相変わらず導入制限があるとうまくいきませんが。

ちなみに、実機転送を行わずにシミュレータのみで動作を見る場合はタブレットからMakeCodeにアクセスさせる、という手段をとることができます。タブレットの場合はブラウザがChromeかSafariになるはずですのでMakeCodeの制限は越えられると思います。

・ポータブル版のブラウザを授業毎に導入して終了後無効にする

ちなみにたいていの学校のPCはちゃんと環境復元ソフトがある(もしくは学習環境管理ソフト内に同等の機能があるはず)なので、先に起動させておいてブラウザだけ入れておく、終われば即シャットダウン、という形でごまかすことが可能な環境はあると思います。もちろん、これはPC管理のポリシー違反になる可能性が高いのでかなり危ない回避方法だといえるかもしれません。私も考えはしましたが多分使わないでしょうね…。

 

今年の回避策はv2版になるのかな…

まあ、たいていの学校は演習でmicro:bitを使う場合はこれになるのでしょうね。よほど込み入った演習をやる予定か、プログラミング演習でコードを用いる演習をしたくて、かつそのコードにPythonを選ぶ、という場合でもない限りは、ですが。一応JavaScriptもあるので、Pythonをやらなければならない理由がないのであればそちらで頑張ってみてください、ということになるでしょうかね。

 

MEGA BIG1等が出るまで対象回の当選確率表を更新していく

ちょっと楽しくなってきたのでMEGA BIGの1等当選確率の推移(当選者が出ない確率など)をどんどん更新していってみたいと思います。今回から各回における1等当選確率も同時に表示するようにしています。まあ、グラフにするようなものでもないので表の形で出したいと思います。

回数 口数 不成立試合数 1等が出ない確率 (1等が出る確率)
1154 1,817,907 0 89.16% 10.84%
1158 964,243 0 94.25% 5.75%
1164 681,109 0 95.94% 4.06%
1165 738,106 0 95.60% 4.40%
1166 766,803 0 95.43% 4.57%
1167 979,506 0 94.16% 5.84%
1168 929,445 0 94.46% 5.54%
1169 1,288,401 0 92.32% 7.68%
1170 1,301,594 0 92.24% 7.76%
1172 1,277,528 0 92.39% 7.61%
1174 1,364,647 1 67.46% 32.54%
1175 943,168 0 94.38% 5.62%
1176 1,228,281 0 92.68% 7.32%
1178 1,514,454 0 90.97% 9.03%
1180 1,460,009 1 65.19% 34.81%
1181 962,565 0 94.26% 5.74%
1182 1,149,320 0 93.15% 6.85%
1183 2,402,965 0 85.68% 14.32%
1185 2,531,145 0 84.91% 15.09%
1187 2,508,561 0 85.05% 14.95%

ここ何回かは少しだけ口数が上がっていますが、それでも当選確率が20%を下回っているのでかなり厳しいですね。ちなみにこれで前回(1187回)のMEGA BIGの口数とBIGの口数は大体同じです。

なお、次の回に1等が出ない確率に今までの出ない確率などは一切関係しません。これはくじの結果はそれぞれの回での独立試行と考えられるためです。なので、口数の変化はそこまでないでしょうから、次回も1等が出る確率は良くても20%位になるのでは?と推察されます。ちなみに確率論で間違えないで欲しいことは当選者が出ない状態が積み重なったからと言って次回当選者が出やすくなるわけではない、ということ。まあ、キャリーオーバーと確率を考えると次回当選者が出ればほぼ確実に12億円だということくらいですし、完全に確率論だけでこの手の当選状態が支配できるようなものでない可能性もごく微少にはある可能性もない訳ではない…のか?

参考までにMEGA BIGが今までに1回も1等当選者が出ない確率は計算すると約9.785%となります。高いのか、低いのか…。

 

MEGA BIGに1等が全く出ていないのは不自然なのか?その確率は?

ということで、またもや確率ネタです。今回もおそらく数Aレベルで分かる話になっています。単純にこの記事を書いている8月末現在でMEGA BIGは一回も1等が出ていません。一応当たれば12億円となるだけのキャリーオーバーがたまっていますが…。この記事を書いている今週末には台風が来る予想になっていると言うことで、もしかすると試合が中止になって確率が上がり、当選者が出るかもしれませんので書いています。それが自分だとうれしいのですが…。

まあ、それはさておき。これを確率的に追いかけてみるとMEGA BIGの確率がBIGなどに比べるとかなりやばいということが分かる、という話です。抽選方法が出た時点から「最低でもキャリーオーバーがたまって12億円の払い戻しができるようになるまで行かないと割に合わない」とは言われていました。そして人によっては機械のランダムに何かあるのでは?と疑いたくなる人もいるかもしれませんが、これを数学的に解いていきます。

 

結論としては「十分にあり得る状態」であるといえそう

計算結果は8月末の状態で約16.5%の確率で「ここまで1等が一つも出ない」と出ています。16.5%といえば1/8より大きいですのでそれなりにあり、というところでしょうか。個人的にはもっと低い状態、だいたい10%を切るくらいのところで、「珍しいくらい」と書きたかったのですが…。ちなみに厳密にしたいのであれば検定を行うべきなのでしょうがそれは省略しています。この時点で確率として極端に低いわけではないですので。

 

くじの確率の前提知識

一般的な「偏りのない場合」で単純に当たりか外れかを考えるだけのくじについて考えます。くじのパターンがn通りで当たりがh通りとする場合、

1本引いてそれが当たりの確率:h/n

1本引いてそれが外れの確率:1-(h/n) [余事象の確率]

くじを確認したら戻す(復元抽出)とき、m本引いてすべて外れの確率:(1-(h/n))^m [反復試行の確率]

これと「独立な試行において2つの事象が同時に起こる確率はそれぞれの確率の積になる」を使うと今回目的の確率を出すことができます。

 

問題はMEGA BIGの確率が小さすぎる点

通常のMEGA BIGにおいて、くじのパターンは4^12通りとなるので、計算すると16777216通りとなります。BIGの3^14通り=4782969通りに対して約3.5倍という状態となり、かなり厳しい確率になっています。確率の減少度合いと1等金額の上昇が微妙に釣り合っていないんですよね…。なので「キャリーオーバーがたまるまで割に合わない」となるわけですが。これに追加してBIGより購入口数が少ないことも響いて、こんな感じの表ができあがります。

 

確率計算をしてみると…

こんな感じの表になります。

回数 総口数 欠試合数 パターン数 1等なし確率
1154 1817907 0 16777216 89.73%
1158 964243 0 16777216 94.41%
1164 681109 0 16777216 96.02%
1165 738106 0 16777216 95.70%
1166 766803 0 16777216 95.53%
1167 979506 0 16777216 94.33%
1168 929445 0 16777216 94.61%
1169 1288401 0 16777216 92.61%
1170 1301594 0 16777216 92.54%
1172 1277528 0 16777216 92.67%
1174 1364647 1 4194304 72.23%
1175 943168 0 16777216 94.53%
1176 1228281 0 16777216 92.94%
1178 1514454 0 16777216 91.37%
1180 1460009 1 4194304 70.60%
1181 962565 0 16777216 94.42%
1182 1149320 0 16777216 93.38%
1183 2402965 0 16777216 86.66%
連続1等不当選確率 16.49%

口数については公式発表のページより持ってきています。計算はExcel任せですが、一応関数電卓でも計算させてありますので数字に間違いはないと思います。あと、一部の回で試合が中心になった影響でくじのパターン数が減少したものがあるのでそれも加味しています。(詳しくは前のページを参照)

そうだとしても、1等が出ない確率が各回単体で見るとでかなり高いのが分かります。総口数が(パターン数に対して)少ないため、BIGのように毎回出るか?出ないか?という感じにならないわけですね。試合が中止になればちょっとましになりますが、それでも70%以上の確率で1等はでない、という状態になっているようです。これだとくじのパターンを決めるアルゴリズムは公平だとしても、当選が出るのはそれなりに珍しい、という結論に至るかと思います。

まあ、口数を公式発表から持ってこなくてもここまでのキャリーオーバーの金額およびそれぞれの分配率から大体の確率は計算可能です。試合の中止による確率上昇は加味できませんが。

 

早く1等を見てみたい…

さすがにここまで1等当選が出ないのは予定外なのかもしれません。CMもそれなりに打ち始めているようですし、その影響で最新回は今までの中で総口数が最も多くなっているため、1等が出ない確率は多少下がっています。これくらいの口数があり、かつ1試合中止になれば当たりも見込めるのではないでしょうか。という希望的な観測を書いて終わりにしたいと思います。

 

BIGの一等当選確率はどれくらい試合中止になると二等レベルになるのか?を計算してみよう

ということで、ちょっとした数学ネタになります。試合が中止になりやすい今だからこそ少し考えてみたい話題です。

 

前知識:BIGやMEGA BIGの一等の確率について

確率を考えるときにはBIGやMEGA BIGがどのようなくじか確認する必要があります。確認すると

  • BIG:特定の14試合について勝ち・引き分け・負けをコンピュータがランダムに選ぶ
  • MEGA BIG:特定の12試合について総得点を4パターンで表し、それをコンピュータがランダムに選ぶ

というものです。ということで、それぞれ一等の確率を考えると、すべて当たったときが一等なので

  • BIG:1/(314)=1/4,782,969
  • MEGA BIG:1/(412)=1/16,777,216

となります。この確率の計算はそれぞれ3通り(BIG)or4通り(MEGA BIG)の試合結果がそれぞれあり、その試合が14試合(BIG)or12試合(MEGA BIG)なので、積の法則からこれが成り立ちます。試合の結果はそれぞれ独立なのでこれでOKですね。ちなみにこれを見てもらうとわかるとおり、確率的にはMEGA BIGの一等はBIGの一等の1/3以下の確率になっています。なので当選金額としては大分不利ではないでしょうか。

 

では二等の確率はどう計算される?

次は二等です。二等は「いずれか一試合の結果が外れていた場合」となります。今回の確率の計算で注意が必要なのが「いずれか」の言葉。どの試合の結果が外れていてもよいので、考えられるパターン数は「外れの試合の結果のパターン数×全試合数」となります。つまり、

  • BIG:パターン数は(3-1)×14=28通り。よって確率は28/314となり、約170,820分の1になる
  • MEGA BIG:パターン数は(4-1)×12=36通り。よって確率は36/412となり、約466,034分の1になる

という結果になります。LOTO6やLOTO7に比べると一等と二等の確率にだいぶ開きがあることがわかるでしょうか。

 

試合が中止になった場合はどうなる?

試合が中止になった場合は「その試合はどのパターンでも当たりとする」となります。ちょっと言い換えると「ある特定の試合だけ外れていてもよい」となります。注意が必要なのが「特定の試合だけ」というもの。いずれか、ではないので1試合の場合一等のパターン数は「1試合のパターン数」しか増えません。複数の試合になると積の法則から「(一試合のパターン数)(中止になった試合数)」が一等のパターン数となります。例えば1試合ならば

  • BIG:1試合のパターン数は3なので、確率は3/314=1/313=1/1,594,323となる。
  • MEGA BIG:1試合のパターン数は4なので、確率は4/412=1/411=1/4,194,304となる。

ということで、確かに確率は上昇していますが、二等レベルまでは増えていません。もし二等レベルまで来るとしたらそれは二等のパターン数と見比べると

  • BIG:3試合の場合のパターン数が33=27通りなので、3試合中止くらいで通常時の二等くらいの確率
  • MEGA BIG:2試合の場合のパターン数が42=16、3試合の場合のパターン数が43=64なので、2試合中止ではまだ足りないが3試合中止まで行けば十分

となります。ちなみに確率を比べてみると通常のBIG1等の確率と1試合中止でのMEGA BIG1等の確率が(大雑把ですが)やっと同じくらいになります。このことから1試合中止が確定している場合で十分にキャリーオーバーがあり、BIGのキャリーオーバーが少ないならMEGA BIGを買う、という選択肢もなくはない、という結論に至ります。あまり勧められませんが。

 

結局一等を当てやすいのは試合中止が決まっているときの100円BIGという話に

○億円レベルの当たりが期待でき、という条件だとこうなるのではないか、と思います。口数が稼げるので確率も(多少ですが)増えますので。まあ、コロナウイルスの影響で全試合中止など4月のような状態になればそうも行っていられなくなるのでしょうが…。ちょっとした考察でした。

 

真面目に48TBファイルサーバを構築してみる(6) サーバ設定編

ここからはどちらかというと余談になります。いろいろと作業をしていくなかであった発見や「なるほど!」と思った現象について少し書いてみたいと思います。

 

ZFSの圧縮の効果がこんなところに

とりあえずすべてデータを転送してみたのですが、気になることが一つ。それはmdadmで確保されたRAID領域(ファイルシステム依存の領域)からZFSにコピーしたのですが、使用容量が8%ほど下がりました。おそらくZFSによる圧縮の効果だと思うのですが、アルゴリズムは速度優先でlz4を指定しているためそれほど圧縮されないはずですし、大抵のファイルが一度圧縮を行っているファイルのはずなので、圧縮はあまりかからないはずだったのですが…。圧縮をかけられるデータやファイル名などのメタデータが圧縮を受けるとどれだけ容量が削減できるかがよくわかりました。速度に問題がなければほかの領域でもかけたくなりますね。

 

QEMUの設定をRedHat系からDebian系に移すのはかなり難しい

こちらは苦労した点。設定ファイルを直接持って行ってどうにかなるのか?というと「基本的にはうまくいかない」が回答のようです。仮想マシンの実行ファイルはRedHat系とDebian系で名前が異なっているため変更が必要、VirtIOがうまく動作せず起動させるとブルースクリーン行きになる、設定ファイルをインポートするとコマンドライン指示の部分(ポート開放処理を記述)は削除される、などがありました。結局一時的に別のUbuntuServer機を用意してそちらにGNOMEとQEMUをインストールして「グラフィカルな環境で設定を行い動作したもの」+「そのときの設定ファイル」を再度コピーする、という手順でなんとかする羽目になりました。VirtIOはドライバのバージョンが古すぎたのかな…とも考えています。

 

mdadmによるソフトウェアRAIDは別PCにストレージだけをつけ直しても検知はされる

これは今回チェックできた中でよかったこと。ちゃんとSuperblockに設定が残っているらしく、OSが入れ替わったとしてもちゃんとmdstatに状態が表示され、mountをかけると普通にファイルが見えました。これでmdadmで構築した場合にインタフェースが故障してもある程度大丈夫ということがわかりました。ただし、mdadmからアレイを削除すると普通に見えなくなりますし、検知された段階で詳細をファイルに保存する(mdadm –detail –scan > /etc/mdadm.conf)ことを忘れるとその後見えなくなったときに二度と構築できなかったりとしますので注意は必要ですね。(元の計画では、HDDとインタフェースカードのみ追加して一時的にHDDを付け替えてコピーする、という算段をしていたが、これがうまくできるのかどうかわからなかったので諦めてPCを一台組んだ、という経緯がある)

 

SELinuxが動いている環境で設定ファイルを/etcにコピーする、というやり方は失敗する可能性がある

再度のFedora環境の移行時に起こった出来事。どうせ同じサービス環境を復元するので移行前の/etcを取り出しておいて移行先で必要なファイルだけ展開してコピーすればいいや、と思って作業をやるとこういう出来事に引っかかるのですよね…。今回引っかかったのはhttpdの秘密鍵と公開鍵の部分。移行前のサーバと同じものを使うためにコピーしてhttpdを起動させるとうまく起動しない。起動しない原因が(日本語に訳すと)「公開鍵ファイルが読み込めないため実行できない」というもの。ファイルのパーミッションは間違いがないのでおかしいな?と思っていたらこのことを思い出して設定を調べてみて判明。特に「/etcに元から存在しないファイルを外からコピーすると/etcのファイルに設定されるべきコンテキストが設定されないため読み込めない」という事態になることが判明。近くにあるファイルのコンテキストをls -dZで確認してchconで設定する、という作業が必要になります。

 

I219V(e1000e)はLinuxと相性が悪い?

どうもそのようです。e1000eに関するいろいろな記事が出ていますが、移行前および移行先のサーバともNICはI219Vを使用しており、移行後のサーバにネットワーク負荷をかけたところかなりの頻度で通信が切断される、という現象が起こったためいろいろと調べてみた結果の結論です。この症状が出るとログに頻繁に「Detected Hardware Unit Hang」が報告されれ、NICのリセットが行われる、というシーケンスが発生します。なお、私の場合はこれが発生しすぎたためかネットワーク経由でサーバにアクセスすることができず強制的に電源断を行わざるを得なくなりました。

原因としてはTSO(TCP Segmentation Offload)が有効になっているとNICへの負荷が高くなって切断される、というもののようで、セグメント分割の処理をCPU側に戻すとよいようです。方法としてはNICをeth0だとすると

# ethtool -K eth0 rx off tx off tso off gso off

のようにして関連する処理をすべてoffにすればOKです。面倒なのがこれを基本的には「起動時に」行う必要がある点。これについてはFedora32やUbuntu 20.04 LTSでは互換性維持のためrc.localによる記述が有効(ただし、Fedora系は/etc/rc.d/rc.local、Debian系は/etc/rc.local)であることを利用して

#!/bin/sh
ethtool -K eth0 rx off tx off tso off gso off

のような感じのrc.localを用意して実行権限を付与すればOKです。

ちなみに、JumboFrameを有効にするとCPUのC-Stateによる省電力が一部使えなくなるようですが、サーバ用途なので気にしなくても大丈夫だと思います。BIOSの設定でC-stateを無効にしても表示されていたのでどうしようもないかも。

ついでに見つかったのが/etc/resolv.confのシンボリックリンクがなぜかstub-resolv.confを指していて、NICリセット時に一時的に127.0.0.53をDNSサーバと勘違いしていた点。修正しましたが、こちらもなぜこんな設定だったのかは不明。

 

とりあえず安定状態に持って行くことができた

今回はファイルのコピーにとんでもない時間がかかってしまったのでサーバの設定時間の方がよほどやることがあって進んでいた印象があるのが今回の移行作業でした。また、今回はUSBメモリによるLinuxインストールを何回も行うことになりrufus(USBメモリに起動可能なデータを設定する)が大活躍しました。まあ、これだけOSを切り替えながらやる計画性のないやり方は今回限りにしたいですね。