大切な家族のペットの健康を守るため、今できることを一生懸命に。

前回ペルチェ式クーラーを作ることを書きましたが、そうなると、性能試験用に温度・温度湿度の測定や、最終的にはユニットのOnOffコントロールのためのマイコンが必要になります。

今までの電子工作では、H8Tiny (H3694F)を秋月電子から購入していましたが、プログラミングに使っていたHEWはずっと新版がでず、Windows 7に正式対応してないようで、ルネサスはH8Tinyはもうどうでもよくなったように感じるので、プラットホームを変更することにしました。

まず最初に検討したのはRaspberry Pi。Linuxが動くのでいろいろできそうですが、温度測定、FANのPWM駆動、AC電源のONOFFをするだけにLinuxうごかすのは面倒というか、オーバースペック。複数作る場合、H8なら一台目だけ開発ボードのような少し高めのキットを買い、二個目からはマイコンボードだけ買ってきて安くできますが、Raspberryは毎回高いボードを買わなければならないようなので、コストパフォーマンスも悪そうです。

そこで今回採用したのがArduinoです。8bitでIOピンも20本とH8Tinyよりもタイニーですが、Visual Studioで開発可能なのは◎です。純正はちょっと高めですが、得体のしれない互換機なら1000円しないというのもいいですね。拡張ボード(シールト゛)も多数出てているし、GitHubに様々なライブラリーが公開されているので、プログラミングの手間も省けてGood。開発言語もC/C++を拡張した言語なので、とても使いやすそうです。

とりあえず、Arduino UNO R3 互換ボード と LCD シールドモジュール を買ってみました。とどいたら早速サーミスタで温度計を作ってみようと思います。

ペルチェ素子を使った密閉空間用除湿ユニットの作成を考えています。具体的には、70cm * 57cm * 57cm (227.43L)の密閉庫内の空気を、外気とは混入させず、また温度上昇を伴わないで、湿気を取ろうということです。

単純に庫内に除湿器を設置した場合、たいていの除湿器は温度を上昇させてしまうので使えません。そこで、庫内からチューブで空気を吸引し、庫外に設置したペルチェの冷却面にあてて結露・除湿し、乾燥した空気を庫内に戻す装置を作ってみようと思います。

とりあえずペルチェとフィン・ファン組み立て済みユニット(DC12V ペルチェ式 ポータブル 保温庫 温冷庫 ユニット 完成品 KOZIMA オリジナル パッケージ おまけ付)とDC12V電源(【ガーデン アダギョウ】 Garden adagio 直流安定化電源 AC DC 12V コンバーター 安全保護 回路 装置 最大 (20A))を購入して、冷却・除湿性能を調べてみようと思います。

わがFC岐阜、前々回の記事から2試合戦って1勝1敗。結局20位に戻ってしまいましたが、降格可能性はどのように変化したでしょうか。さっそくシミュレーション結果です。

J2降格可能性 39節終了時 (単位は%)

現順位	チーム	現勝点	21位	22位
16	横浜FC	45	0.9513	0
17	京都	44	1.6327	0
18	讃岐	44	1.9678	0
19	水戸	42	8.9144	0.1129
20	岐阜	42	10.6395	0.2915
21	大分	38	68.2568	7.7714
22	栃木	34	7.6375	91.8242

　降格圏争いはほぼ4チームに絞られましたね。最下位争いもほぼ栃木に決まりか...岐阜と栃木は残り3試合で8ポイント差。栃木が全部勝って、岐阜が2敗1分けか3連敗だとひっくり返りますが、あと1勝すれば即降格からは免れます。

　大分との差は4ポイント。微妙な差ですね。それでも次節岐阜が勝って大分が負けなら、降格圏の可能性がなくなります。とにかく次節勝って降格争いから抜け出してほしいものです。

前回、J2のリーグシミュレーションをおこないましたが、そのプログラムをつくっていてが付いたことがあります。
パフォーマンス解析ツールがVisual Studio Ultimateじゃなくても使えるようになったので、モンテカルロシミュレーターをC#6.0で書き直したついでにパフォーマンス測定してみたところ、乱数発生系と順位並べ替えがホットスポットになっていました。まあ、この両者がシミュレーターのキモの部分ですから当たり前なんですが、とりあえず早くできないものかと並べ替え系を検討してみました。
Github
class Main
{
  List<TeamResult> Teams;

  void Order()
  {
    Teams = Teams.OrderBy(r => r, new リーグ順位Comparer()).ToList();
  }
}

class リーグ順位Comparer : Comparer<TeamResult>
{
  static int count1, count2, count3;

  public override int Compare(TeamResult x, TeamResult y)
  {
    count1++;

    int ret = 勝ち点得失点差で判定(x, y);
    if (ret != 0)
      return ret;

    count2++;

    ret = 当該チームの成績で判定(x, y);
    if (ret != 0)
      return ret;

    count3++;

    return 抽選(x, y);
  }
}

count1, count2, count3の数を調べたところ、count2とcount3の値が非常に近い値になっていました。抽選になるケースって実際のリーグではほぼ発生しない事象ですので、この二つの変数の値はかなり大きな差が付かねばなりません。当該チームの成績で判定()にバグがあるかと検討しましたがとくにない。はっときがついて、Compareメソッドの先頭に
Github
public override int Compare(TeamResult x, TeamResult y)
  {
    if (x == y)
    {
      count0++;
      return 0;
     }
    count1++;

    int ret = 勝ち点得失点差で判定(x, y);
    if (ret != 0)
      return ret;
    .
    .
    .

参照同値性の判定ルーチンを加えたとことろ、count0の値が相当な数になりました。LINQのOrderByメソッドがどんなソートロジックを使っているか知りませんが、ユニークな要素しかない列挙で同じオブジェクトをCompareしているとは予想していませんでした。ICompare<T>の解説ではたいていいきなり内容の比較から入っているサンプルばっかりでしたので、そういうものだと思ってリスト1の書き方をしていたのですが、値型ならいざしらず、参照型の場合は真面目に参照同値性とnullチェックを入れないとだめなのですね。というわけで最終的には
Github
public override int Compare(TeamResult x, TeamResult y)
{
  if (ReferenceEquals(x, y))
    return 0;
  else if (ReferenceEquals(x, null))
    return -1;
  else if (ReferenceEquals(y, null))
    return 1;

  int ret = 勝ち点得失点差で判定(x, y);
  .
  .
  .

というように、IEqaulity<T>でよく書く参照同値性とnullチェックを入れてみましたところ、40％のスピードアップをマークしました。いやいや、これは他のプログラムのコードも書き直さないかんぞ...まあこのプログラムほど比較系がパフォーマンスに影響しているコードは書いてないから急がなくてもいいですが...

10月に入りJ2リーグも佳境に入りました。わがFC岐阜は、一時期の低迷をどうにか脱しつつあるようですが、まだ降格圏の少し上、全然安心できません。
きょうのJ2結果は引分けが多く、なんと17位から22位まで全チームが引分け！おかげで降格争いに変化が起こりませんでした。
しかし残り6節、まだまだ降格可能性のあるチーム多いですが、モンテカルロシミュレーションで、今年のJ2リーグの結果を予想してみました。

まずは、優勝・昇格争いから。単位は％です。10%以上の項目は太字にしています。

チーム名	昇格(1-2)	プレーオフ(3-6)	合計(1-6)
大宮	99.92	0.08	100.00
磐田	60.98	39.02	100.00
福岡	24.62	75.34	99.78
C大阪	14.34	85.44	99.78
東京V	0.09	56.44	56.53
長崎	0.03	45.90	45.93
千葉	0.02	45.45	45.47
愛媛	0.01	38.14	38.15
札幌	0.00	5.09	5.09
岡山	0.00	3.17	3.17
熊本	0.00	1.91	1.91
金沢	0.00	1.64	1.64
徳島	0.00	1.07	1.07
北九州	0.00	1.15	1.15
群馬	0.00	0.13	0.13
横浜FC	0.00	0.03	0.03

というわけで、大宮が圧倒的に有利。優勝確率も98.02%、もう当選確実ですね。2位争いは少し熾烈で磐田、福岡、セレッソのどこが来るか、まだなんとも言えませんね。プレーオフは実質的に現在8位の愛媛までに絞られたでしょうか。

それでは、肝心の降格争いです。

現順位	チーム名	入替戦(21)	降格(22)	合計(21-22)
15	群馬	0.25	0.02	0.27
16	横浜FC	0.92	0.12	1.04
17	讃岐	4.73	1.05	5.78
18	京都	8.30	2.98	11.28
19	岐阜	9.44	3.17	12.61
20	水戸	18.14	7.90	26.04
21	大分	33.06	30.10	63.16
22	栃木	25.13	54.66	79.79

一応、12-14位も0.01-0.02%の確率で入れ替え戦ですが、省略しました。表中でも合計5%以上の17位讃岐以下に降格争いは絞られてるとみてよいでしょう。
わが岐阜は降格は3.17%なので、やっと尻に火が付いた状態からは脱出できましたが、入れ替え戦もあわせた合計確率は12.61%とまだまだ実現可能な数字です。本当は今日京都に勝って順位が入れ替われば最高でしたが、みんな仲良く引分けは下位が不利ということで、まあ、よかった方だったのかなと感じるべきでしょうか...

ちなみに、今年から、JリーグのWebPage直接読み込んでシミュレーションできるようになりました。WebClientで読み込んで、NuGetのSgmlReaderでXMLに変換し、LinqToXMLで解析しました。マークアップ言語はほとんど素人ですが、LINQにさえもちこめればこっちのもの。一晩で作成できました。いままで手で入力してたのに比べると、ほんとに楽です。