思考のサルベージ(その12)
各工程で心がけたい思想を掘り起こしてみる
今回は開発中の製品で見つけた不具合の過去製品への「フィードバック」について考えてみます。 ここでは、現在開発中の商品をPRODUCT-2、過去製品をPRODUCT-1と呼びましょう。PRODUCT-1はすでに客先リリース済みで、PRODUCT-2は開発も終盤でステム試験による不具合検出も落ち着いてきます。
PRODUCT-1の再リリース
PRODUCT-1をリリースした顧客から、今後の開発を踏まえPRODUCT-1に「機能C」を追加しての再リリースを要求されました。断るという選択肢はなかなかないのが現実で、スケジュールをやりくりして「機能C」を追加してシステム試験をやり直し、再度顧客に再リリースすることになります。
PRODUCT-2で検出した不具合
PRODUCT-2は、PRODUCT-1をベースに作った製品です。PRODUCT-2で検出したバグにはPRODUCT-1にそのまま残っているバグがあるかもしれません。「機能C」を追加するとともにPRODUCT-2で実施したバグ対策もPRODUCT-1にフィードバックできれば品質が向上し後の憂いがなくなります。
PRODUCT-1とPRODUCT-2の差分
フィードバックするにはPRODUCT-1とPRODUCT-2の機能差分を明確にする必要があります。 例えば、以下のような機能差分があるとしましょう。
- PRODUCT-2には新規に「機能A」が追加されている
- PRODUCT-1の「機能B」は「規格ver1.0」準拠
- PRODUCT-2の「機能B」は「規格ver2.0」準拠
「機能A」についてはPRODUCT-2の独自仕様なのでこれに関するバグ対策はPRODUCT-1へのフィードバックは不要と判断できます。「機能B」についてはちょっと注意が必要で、「規格ver2.0」固有の部分についてのバグ対策はフィードバック不要ですが、「規格ver1.0」「規格ver2.0」共通部分のバグ対策については要フィードバックとしなければなりません。 まとめるとフィードバックが必要なのは以下のようにまとめられます。
- 「機能B」の「規格ver1.0」と「規格ver2.0」の共通部分のバグ対策
- 「機能A」を除いたその他のバグ対策
フィードバック
どこの現場でもたいてい便利なバージョン管理システムや不具合管理システムを連携させて使っているので、どのヴァージョンでどんなをバグ対策をしたか履歴を見れば一目でわかるでしょう。要フィードバックの条件に合致する対策をPRODUCT-1に取り込んでいけばよいだけです。
PRODUCT-1に「機能C」を取り込み、要フィードバックな対策もすべて入れました。フィードバック項目はすべてPRODUCT-2のシステム試験で検証済みなので、再リリース向けPRODUCT-1のシステム試験は「機能C」関連以外はすんなり通るはずでしたが、「機能B」の「規格ver1.0」と「規格ver2.0」の共通部分で引っかかってしまいました。
ちゃんと運用できていますか?
こういうことでした。
PRODUCT-2のシステム試験で「規格ver2.0準拠の機能B」で処理速度が遅いという不具合がありました。処理性能の改善ということで、様々なトライアルをして幾度も評価を繰り返していくうちにいくつかバグが見つかりました。これらのバグが全て「「規格ver2.0準拠の機能B」で処理速度が遅い」という不具合として一括でバージョン管理システムにも不具合管理システムにも登録されていました。その中に1件、「規格ver1.0」「規格ver2.0」共通部分のバグが埋もれていました。正しくは、処理速度の不具合とは別に不具合登録され、別バージョンで対応すべきでした。
何か掘り起こせた?
- 運用ルールを明確に。
- 不具合登録、対策は手間がかかっても各事案ごとに。
せっかく便利なツールあるのに、運用が正しくなかったがために余計な工数を費やすという結果を招きました。今かける手間暇は、近い未来の手間暇を省いてくれる投資みたいなもんですね。
おしまい
でも時々あるんですよね、システム試験チームも設計チームも誰一人、正常な判断能力を失ってしまっている時って。
Singularityでお手軽コンテナ運用! 〜CUDAも使えます〜
Singularityってなに!?
今回はSingularityを使って、コンテナ運用する方法を紹介します。
って、そもそもそれは一体何!?と思われる方も多いかと思いますが、一言で言うとDockerのようなコンテナフレームワークです。
Singularityには下記のような特徴があります。
- 主に一般ユーザーで使用することを想定しているためGPUも扱いやすい
- Dockerイメージをそのまま使用可能のためDockerHUBも使用可能
特に一番目の理由は特に重要のようで、GPUで扱いやすい故、HPCなどで使用されるケースが多いようです。
コンテナ起動時、オプション一つでGPUが使えるようになるのは魅力的ですね。(詳細後述)
- Singularityってなに!?
- インストール方法
- Docker HubからSingularity用コンテナイメージをビルドしよう
- ビルド方法
- 実行方法
- CUDAも使ってみよう!
- TensorFlowコンテナイメージのビルド
- GPUモードでシェルの呼び出し
- まとめ
Audacityの「ノイズ除去」を検証してみる
「Audacityでノイズ除去」では AudacityのNoise Reductionを紹介しましたが、はたしてどんなアルゴリズムなのでしょうか。気になったので少し検証してみます。
- Audacityのソースコード
- 特定の周波数をノイズとして消してみる
- 1kHzの正弦波を生成
- 2kHzの正弦波を生成(トラックの追加)
- 1kHzと2kHzの波形を合成
- 周波数特性
- 1kHzの正弦波でノイズプロファイルを取得
- ノイズの除去:デフォルトパラメータ(ノイズ除去=12dB, 感度=6, 周波数平滑化=3)
- 周波数特性を見る
- ノイズの除去:パラメータを大きく(ノイズ除去=24dB, 感度=6, 周波数平滑化=3)
- 周波数特性を見る
The Continuing Story of Error Correction Code 5
ハミング符号再訪
ハミング符号は誤り訂正の基礎
The Continuing Story of Error Correction Code 2 - Smile Engineering Blog で7ビットハミング符号を構成してみました。
このハミング符号はSECDED、CRC符号、BCH符号、リードソロモン符号などの基礎となっています。
ハミング符号に色々なアイデアを追加して更に強力な訂正符号が作り出されていったわけですね。
これらの符号を理解するためにハミング符号をもっと深堀してみましょう。
今回は訂正符号で頻繁に登場する排他論理和(XOR)について見ていきます。
排他論理和
入力をA、Bとしたときに出力Xが以下のようになる演算が排他論理和です。
0 | 0 | 0 |
0 | 1 | 1 |
1 | 0 | 1 |
1 | 1 | 0 |
なんか、この出力の並びどこかで見たような・・・
The Continuing Story of Error Correction Code 2 - Smile Engineering Blog の「検査符号の計算方法」で登場したこの演算。
これですね。
排他論理和は桁上がりを無視したビットの足し算になっています。
2を法とした演算ですね。
なのでとなります。
ちなみに引き算はどうなってるんよ
とりあえず普通に引き算をしてみましょう。
ここでがになってしまいますが、としかないはずなのにってどうしたらいいんでしょう?
足し算を見てみると計算のルールとしてと定義しているので
よりとしてしまいます。
よって、引き算は以下のようになります。
この演算、足し算と見比べてみると演算の記号がからに変わっただけで他は同じですね。
このビット単位の演算では足し算も引き算も結果は同じになります。
引き算も2を法とした演算と考えれば
となるのでとなります。
排他論理和の不思議な性質
The Continuing Story of Error Correction Code 2 - Smile Engineering Blogで作ったハミング符号の 、 、 を
と表すことにします。、 、 なら
となります。
この3ビットのパリティを加算します。加算は先ほど示したルールに従いビットごとに行います。
3ビットのパリティを3個適当に取り出して加算してみましょう。
とりあえず、、の3個を選んでみました。
答えはですね。 ではこのに再度、、を加算してみます。
答えはになります。
加算した結果に更に同じものを加算すると答えは0になるんですね。
なんか、不思議な感じがしますがこの演算は加算と減算は同じである、ということを思い出すと納得がいきます。
値を加算して、同じ値を減算すれば0になる、という当たり前の話です。
この当たり前が、ビット単位の演算でも成立しているよ、と。
では3個足して、その答えに2個だけ更に加算(減算)するとどうなるでしょうか? を加算(減算)しないと・・・
ちゃんと加算(減算)しなかった1個が残ってますね。 加算と減算の結果が同じということを除くと普通の加算、減算と同じように考えてもよさそうです。
排他論理和でハミング符号を考えてみる
The Continuing Story of Error Correction Code 2 - Smile Engineering Blogのハミング符号は4ビットの送信語がありました。
、、、の4ビットです。
この4ビットのうち1ビットだけが1の時の符号語を取り出してみます。
0 | 0 | 0 | 0 | 1 | 1 | 1 |
0 | 0 | 1 | 1 | 0 | 0 | 1 |
0 | 1 | 0 | 1 | 0 | 1 | 0 |
1 | 0 | 0 | 1 | 0 | 1 | 1 |
だけが1のときのパリティは、だけが1のときのパリティは、だけが1のときのパリティは、 そしてだけが1のときのパリティはになっています。
ではとが1のときのパリティは?
0 | 0 | 1 | 1 | 1 | 1 | 0 |
になっているから!!
正解!!、なんですが実はだけが1のときのパリティとだけが1のときのパリティから計算できるのです。
計算方法はだけが1のときのパリティとだけが1のときのパリティを加算する、だけです。
やってみましょう。
だけが1のときのパリティは、だけが1のときのパリティはだから
もう一個ぐらいやってみましょうか。
送信語の全ビットが1の場合はからまでそれぞれだけが1のときのパリティを加算します。
表をみると確かにになっていますね。
1 | 1 | 1 | 1 | 1 | 1 | 1 |
では、符号語に1ビットの誤りがあった場合を考えてみます。
送信語の全ビットが1を送信したらが誤って0になったとします。
符号語はですが、受信語はになりました。
受信語の、、が1、パリティはなので
で、答えは、これはだけが1のパリティに該当します。
ということで誤っているのはのビットだとわかります。
なんか分かったような、分からんような・・・
延々と言葉で説明してきましたが、そろそろ数学的な表現を導入してハミング符号を表現できるようにしましょう。
まずは、あれですね。
みんな大好き「行列」。
え゛ーーー、って声が聞こえそうですが、慣れるとこのほうが楽ですよ。
いや、本当に。
ということで次回は行列の基礎。
ハミング符号を行列を使って表してみましょう!!