コグノスケ

Scalaでバイナリ解析2

前回の続き（2014年1月6日の日記参照）です。

おさらいすると、Booleanのリストをビット列に見立てて、任意のビット数を上位ビット〜下位ビットにOR演算し、Intのリストとして返すという処理をします。

ビット列 (0, 1, 0, 0, 1, 1, 0, 0, 0) に対して、(1ビット取る, 3ビット取る, 5ビット取る) という処理を行って、結果として (0, 4, 24) が返るイメージです。

（入力1）
List(
  true, false, false, true, true, false, true, false,
  true, true, true, false, true, false, true, true
)

（入力2）
List(1, 2, 3, 4, 5, 6)

（出力）
List(1, 0, 6, 11, 21)

ビット列に相当するリストが入力1、何ビットずつまとめるか、という別のリストが入力2になります。

前回は特に触れませんでしたが、入力1と入力2の合計が異なるときの扱いについては悩みどころです。余ったリストを返すのが一番親切かもしれませんが、出力が3つになってしまいます…。

今回は、一番楽に（入力1＞入力2）なら例外スロー、（入力1＜入力2）なら切り捨て、としています。

前回の反省

前回使ったmapでは（入力:出力）の要素数を（1:1）にする必要があります。そのため(n:1）にしたければ、入力はあるが、出力はない「穴が空いた」状態を表現する必要が生じます。

Option型を使って、値はSome(値), 穴はNoneとし、最後にflattenを呼んでNoneを全部捨てましたが、あまり効率的とは思えません。

foldLeftはどうか？

入出力の要素数が一致していなくても構わないのがfoldLeftです。

object BooleanToInt {
  def apply(g: List[Int]): ((List[Int], Boolean) => List[Int]) = {
    val o = new BooleanToInt(g)
    o.folder
  }
}

class BooleanToInt(g: List[Int]) {
  private var v = 0
  private var p = 0
  private var mp = g(0)
  private var gg = g.drop(1)

  def folder(a: List[Int], b: Boolean): List[Int] = {
    v <<= 1
    if (b) v |= 1
    p += 1

    if (p >= mp) {
      val result = a :+ v
      v = 0
      p = 0
      mp = gg(0)
      gg = gg.drop(1)
      result
    } else {
      a
    }
  }
}


val a = List(
  true, false, true, false,
  true, true, false, false,
  true, false, false, true,
  false, true, true, false
)

val b = List(1, 2, 3, 4, 5, 6)

val c = a.foldLeft(List[Int]())(BooleanToInt(b))

println(c)

コードがScala素人くさいのはさておき、SomeとかNoneが出てこない分、mapより良さそうです。

val c = (List[Int]() /: a)(BooleanToInt(b))

初期値のリストが長いときはfoldLeftを /: で書く手もあります。個人的には右側が被演算子になると読みづらいし、使うことはないですね…。

Scalaまだまだトライ中

最近はScalaとお友達ですが、未だに文法やら動きがワケわかりません。俺、この言語向いてないのかなー、なんて思いつつもチマチマと書いています。

そんな状態なので、Scalaっぽくない書き方をして後で気づいたり、間違えてバグらせたりで、気づいたら「死んでる…」となっていることが多いです。

グチャグチャになる前にテストを書こう、後でリファクタリングするときの役にも立つ、と思い立ちました。

思い立ったまでは良かったものの、Scalaのメジャーなテストフレームワークについて何も知りません。JavaでいうJUnitのようなスタンダードがあるととても助かりますが…。

ScalaTestがおすすめ？

Scalaのテストを調べてみるとScalaTestというのが有名処のようです。ScalaTestでは「テスト」ではなく「スペック」というようです。

私の理解だと「テストのためにプログラムの動作結果の羅列するのはおかしいんよ。振る舞いや期待する仕様を書けばテストになる方が自然なんよー。」というスタイルみたいです。振る舞いを書くところから開発するスタイルをBDD（Behavior Driven Development、Wikipedia ビヘイビア駆動開発の項）と言うそうです。へぇー。

思想は素晴らしいのですが、ScalaTestは従来のJUnitのような「テスト」から、振る舞いを書く「スペック」まで、何でも出来るようにしてしまったせいで、ゴチャゴチャです。初心者には何を使えば良いか判断がつきません。

とりあえず、良くわからないままですけどFlatSpecで書くことにしました。

ScalaTestとIntelliJ IDEA

私のScalaプログラミング環境はIntelliJ IDEA＋Scala Pluginですので、これとScalaTestを連携させたいと思います。

といっても何も難しいことは無く、下記のようなFlatSpecのスペッククラスを書いたらProjectのツリー図から右クリックして、Runを選ぶ、ほぼそれだけです。

import org.scalatest.FlatSpec

class HogeSpec extends FlatSpec with Matchers {
  val hoge = "hoge"
  val fuga = "fuga"
  "hoge" should "starts with 'h'" in {
    hoge.startsWith("h") should be (true)
  }
}

テスト結果はIntelliJ IDEAの結果表示ウインドウに、ツリー状に見やすく配置されます。IntelliJ IDEA＋Scala Plugin＋ScalaTestのトリオはなかなか素敵です。

複数テストを同時に行うには？

スペックを書く方法はわかりましたが、1度に複数のスペックを動作させるにはどうしたら良いのでしょう？

さらに言うと1度に複数のスペックを動作させた結果が、IntelliJ IDEAの結果表示ウインドウにも出て欲しいですが、どう書いたら良いのでしょう？？さっぱりわかりません…。

まとめ用のクラスAllSpecから、先ほどのHogeSpecと新たにFugaSpecを1度に動作させるという想定で、思いつく手だてを試してみたいと思います。

executeしてみる

まずは素直に、まとめ用のクラスで各クラスのオブジェクトを作りexecute() を呼びました。

import org.scalatest.FlatSpec

class HogeSpec extends FlatSpec with Matchers {
  val hoge = "hoge"
  "hoge" should "starts with 'h'" in {
    hoge.startsWith("h") should be (true)
  }
}

class FugaSpec extends FlatSpec with Matchers {
  val fuga = "fuga"
  "fuga" should "starts with 'f'" in {
    fuga.startsWith("f") should be (true)
  }
}

class AllSpec extends FlatSpec {
  new HogeSpec().execute()
  new FugaSpec().execute()
}

HogeSpec:
hoge
- should starts with 'h'
FugaSpec:
fuga
- should starts with 'f'
AllSpec:
AllSpec

コンソールへの出力ではまとまって実行されているように見えますが、入れ子になっていないし、IntelliJ IDEAは「NO TEST」という悲しい結果を表示します。ダメですね。

シングルトンの関数

次にHogeSpecとFugaSpecをシングルトンにしてスペックは関数内に入れ、まとめ用のクラスから呼んでみました。

import org.scalatest.FlatSpec

object HogeSpec extends FlatSpec with Matchers {
  def hogeTest {
    val hoge = "hoge"
    "hoge" should "starts with 'h'" in {
      hoge.startsWith("h") should be (true)
    }
  }
}

object FugaSpec extends FlatSpec with Matchers {
  def fugaTest {
    val fuga = "fuga"
    "fuga" should "starts with 'f'" in {
      fuga.startsWith("f") should be (true)
    }
  }
}

class AllSpec extends FlatSpec {
  HogeSpec.hogeTest
  FugaSpec.fugaTest
}

AllSpec:
AllSpec

何も出なくなりました。ダメだこりゃ…。

トレイトでMix-in

最後にHogeSpecとFugaSpecをトレイトにして、まとめ用のクラスにMix-in してみました。

import org.scalatest.FlatSpec

trait HogeSpec extends FlatSpec with Matchers {
  val hoge = "hoge"
  "hoge" should "starts with 'h'" in {
    hoge.startsWith("h") should be (true)
  }
}

trait FugaSpec extends FlatSpec with Matchers {
  val fuga = "fuga"
  "fuga" should "starts with 'f'" in {
    fuga.startsWith("f") should be (true)
  }
}

class AllSpec extends FlatSpec 
with HogeSpec
with FugaSpec {
  //empty
}

AllSpec:
hoge
- should starts with 'h'
fuga
- should starts with 'f'
AllSpec

コンソールへの出力ではまとまって実行されていて、IntelliJ IDEAにもテスト項目が認識されています。これはなかなか良さそうです。しかし、

• 異なるスタイルのスペックを混ぜられない（FlatSpecとFunSpecなど）
• HogeSpecやFugaSpecを単独で実行できない

という欠点もあってイマイチです。でも良い方法がわからんす、困ったもんです。

折り返し乗車は不可

「大回り乗車」ができる区間であっても、同じ経路を折り返して2度通ると不正乗車になります。下記路線でB駅からD駅に行く切符で、B → A → B → C → Dと乗ることはできません。B → A → Bの分を払わずに乗っているためです。

A - B - C - D
|       |
E - F - G

どうしてもB → A → B → C → Dという経路で行きたいなら、どこかでB → A → Bの運賃を追加で払う必要があります。

ええ？そんなのどうやって払うの？と一瞬考えましたが、A駅で一度降りて再び乗れば特に問題ないですね。面倒くさいけど。

折り返せると便利？

折り返したら何が嬉しいか？というと、

• 隣接のA駅が主要駅（快速停車）かつ近い
• 最寄りのB駅がヘボ駅（快速通過）
• 目的地のD駅が遠い
• A駅方向への電車がすぐ来る
• D駅方向への電車がしばらく来ない

という条件のとき、通常の経路B →(普通)→ A → C → Dを使って行くより、B →(普通)→ A →(快速)→ B → C → Dと乗る方が早く着くことがあるので、嬉しいのです。

例えば、つくばに居た時の、研究学園駅（車停めたい時の最寄り）とつくば駅（主要）ですとか、今住んでる摂津富田駅（最寄り）と高槻駅（主要）が当てはまります。

実際には良くても5〜15分早く着くだけでしょうし、そのために追加運賃と乗り換えの手間を掛けることを考えると効果は微妙…。よほど急いでいる時でない限り、積極的にはやりたくないですね。

大回り乗車

Facebookに「路線がループしているときの運賃の扱いがよくわからん」的なことを書いたら「大回り乗車」を教えていただいたので、ちょっと調べてみました。

電車の基本ルールとしては、乗る時に使った切符の範囲外に行ってはいけません。例えば、下記路線でB → Cの切符で乗りDまで行った場合、C → Dの運賃を追加で払う必要があります。

A - B - C - D

しかし途中に環状線が入ってたらどうなるでしょう？下記路線でB駅からD駅に行く切符で、B → A → E → F → G → C → Dと乗る場合です。一見するとB駅からG駅までの運賃も払う必要がありそうです。

A - B - C - D
|       |
E - F - G

ところがこの場合、ある条件を満たせばB駅からD駅の切符で乗車できます。これがいわゆる「大回り乗車」です。

大都市圏近郊区間

路線がループしている大都市圏には、運賃計算の特殊ルールが存在します。JRの説明によると「実際に乗った経路に関わらず、最も安い経路で運賃が計算される」というルールです。

このルールを逆手にとって、1駅分の切符を購入し、出発駅→目的の駅→出発駅の隣接駅、と乗ること（大回り乗車）が可能です。条件としては、

• 圏内を出てはならない
• 同じ駅を2度通れない（交差はダメなのか？？）
• 途中下車できない
• 定期券は使えない
• （条件ではないが）駅員に乗車経路を聞かれることがある

です。駅から出ない乗り方、例えば電車や駅の写真を撮りたい人、電車に乗るのが好きな人に向いていますね。駅の外に出たい場合には使えませんけどね。

鉄道関連の法律

ちなみに、不正乗車の罰については、鉄道営業法という古い法律（明治三十三年施行）に述べられているようです。罰則を述べていそうなところを摘んでみると、

第十八条の二

有効ノ乗車券ヲ所持セス又ハ乗車券ノ検査ヲ拒ミ又ハ取集ノ際之ヲ渡ササル者ハ鉄道運輸規程 ノ定ムル所ニ依リ割増賃金ヲ支払フヘシ

第二十九条

鉄道係員ノ許諾ヲ受ケスシテ左ノ所為ヲ為シタル者ハ五十円以下ノ罰金又ハ科料ニ処ス

第四十二条

左ノ場合ニ於テ鉄道係員ハ旅客及公衆ヲ車外又ハ鉄道地外ニ退去セシムルコトヲ得

要は、運賃チョロまかすなんてナメた真似しようもんなら「割増料金を取る」「罰金刑」「電車から叩きだす」ぞ、わかったかこの野郎。ということですね。

個人的には、罰金50円（※）の辺りに時代を感じます。さすが明治施行の法律です。

（※）罰金50円なら超安いしｗ余裕ｗｗってのは思い違いで、実際には1万円か2万円になるようです（罰金等臨時措置法）。
JRの割増料金も洒落にならないし（鉄道運輸規程 第十九条）、不正乗車はやめた方が良いですねー。

エンジニアなら

エンジニアを成長させる、たった6つの指針。｜クックパッドCTO橋本健太に訊く！［前編］

一番わかりやすいコミュニケーションは、「動くもの」と「数字」。エンジニアならば、「これだよ」と作って見せてみる。
（記事中「議論のための議論はしない〜動くものと数字で示す」より引用）

エンジニアなら、ほんとこれしかないと思います。「本番で動くモンはこれ、どう？便利でしょ？」って見せるんです。

ここがダメなら、どんな資料も説明も意味無いでしょう？だってテメーの商品のことはわかった、だが気に入らん、と言われてるに等しいのだから。

メモ: 技術系？の話はFacebookから転記しておくことにした。

Intelと組み込み系

Intelは組み込みで勝っているとは言えないけど、なぜだろう。

• CPUの性能が合わないから？
• IP売りしてないから？
• PC/ATじゃないから？

性能？

Atomは電力/性能比はイマイチかもしれないけど結構速い。多くのSoCベンダが採用する省電力プロセスのARM Cortex A9ならいい勝負らしい。

ARM社のデュアルコアCortex-A9、低消費電力版でも性能はAtomを上回る

IP売り？

Atomは以前IP売りしたみたいだけど、売れた様子はない。

元麻布春男の週刊PCホットライン - IntelとARMが目指す、それぞれの隣の芝生

PC/AT？

次世代機のPS4, XBox Oneはx86かつPC/ATではない組み込み機器だけど、勝ったのはIntelじゃなくてAMD だった。

PS4もXbox OneもAMDはいってる：2013年末、いよいよ“新生AMD”が新たなステージへ

単純な問題ではないのだろうなあ…。

メモ: 技術系？の話はFacebookから転記しておくことにした。

さすがIntel

【イベントレポート】IntelのSDカード型コンピュータ「Edison」の詳細が判明 〜512KBメモリ、2GBストレージ、無線機能などを詰め込む - PC Watch

Quarkが去年発表したモデルから2倍くらい速くなってることと、実際にSDカードサイズのボードを作ってしまう辺りが流石Intel って感じ…。

メモ: 技術系？の話はFacebookから転記しておくことにした。