Training in Commercial Pilotage with FTD - Lead Design for Glide Path

都内某所で Flight Simulator による F/O 訓練。B737-800 で 1.5H。このお気に入り機種は、なんとなんと、まもなく退役で ... 詳細未公表のため詳しく書けないが、今後は B7x7-xxx (6 軸モーション！) と A3xx になるらしく、今回が私の B737-800 Last Flight に (╥_ ╥) ｱｲﾁｬｸｱﾙ ﾋｺｰｷ ﾄﾉ ｵﾜｶﾚ ｻﾐｼｲﾖ ... 機種移行訓練せねば ٩(ˊᗜ ˋ*)و ﾒｹﾞﾃﾙ ﾋﾏﾊ ﾅｲ!

Acceleration / Deceleration Step Check

本日の訓練は Acceleration / Deceleration (増減速) の Step Check。

いつもの通り RJTT RW 34R から Take Off して 6,000 ft へ上がること 2 回。少し Power の絞り方が遅かったために 3 kt ほどオーバーしたりもするが、以前のようになかなか逸脱が収束しないということもなく、おおむね良い感じ。

今日は Acceleration / Deceleration がメインで、その練習をしてから Step Check に挑む予定だったのだが、教官の連携がうまくなく、240 → 280 kt の Acceleration を 1 回やったのみで N 教官へ引き継がれ Step Check へ。前回の反省を活かして Alt を維持する Pitch 調整を安定的にやったため、滑らかな A/S 移行ができたが、Acceleration より難しい Deceleration の練習をしないままの Step Check 突入であるため、当然、低速域では Lead 設計がうまくなく Deceleration の Exit は粗が目立つ。しかも最後は Stall 直前の 140 kt まで A/S を大幅に下げた Slow Flight をやることになったため、Pitch & Power 調整にかなり苦労する。それでも、レシプロ実機訓練で培った技量で、激しく逸脱することはなく収束させ、Step Check をクリアする。

この過程で発見したことだが、トレンドベクターは、Power を操作して A/S が動き始めたことを理由として動くのではなく、Pitch を傾けるだけでも感応する。A/S のトレンドベクターは A/S のみを情報源としているわけではなく、明らかに Pitch や Power の状況もすべて含めて複雑な「計算」をしている *1。

後半の訓練は Constant Rate Climb / Descent。「500 ft/min で Climb」と教官に言われて、グイっと適当に Power を +10% くらい動かし、500 ft/min 前後を維持する。教官に「240 kt を維持して」とさらに要求され、「ん、Constant Rate で、かつ、Constant Speed で Climb って、N1 を何 % にするのか Power 設定を知っていなければできないでしょ」と心の中で反応しながら A/S に目をやると Climb 開始時に 242 kt くらいだった A/S が 244 kt → 245 kt と徐々に上がりつつある。教官がシミュレータを止め「なぜ Power を入れた？」と問う。 なんと答えたらよいかわからず「なぜって ... Climb だから ...」と漏らすと、「それは Power 水準で Alt がほぼ決まり、慣性を気にしなくてよいレシプロ機の操作方法だ」と返される。

ジェット機では「まず Pitch で姿勢を作って A/S ⇔ Alt (Climb / Descent の場合は VSI) の位置・運動エネルギー変換を行い、所望 Alt / VSI に設定したときに過不足する A/S を Power で補う」「先に Power 調整を行う *2 と調整の所要量がわからず A/S, Alt, VSI, が乱れて、整えるための操作をする必要に迫られるものの安定する水準を捉えられない結果、逸脱を収束させられずにワチャワチャすることになる」とのこと。さきほどの操作でいえば、Climb 開始時に 242 kt であったのであるから、まず、Pitch を上げて上昇し、240 kt に下がる間に 240 kt & 500 ft/min を維持できる Power を探る、ということになる。「Power は A/S 見合いで微調整するものであり、N1 = XX % という絶対水準を目指すものではない、だからこそ Power 出力水準を表示する EICAS はパイロットの視野中心から外れたところに配置されている」とも。

ということで、再度、Constant Speed & Rate Climb / Descent に挑戦すると ... なんだ、維持すべき基準点が Alt = 一定 すなわち VSI = 0 ft/min から VSI = 500 ft/min になるだけで、Straight & Level Flight とやることは変わらない！ この訓練を始めたときは、こんな重い Yoke で Pitch 髪の毛 1 本のコントロールなんてムリ、まして、Constant Speed & Rate Climb/Descent なんて神業と思っていたが、自分にもできる！ Climb / Decent Exit のリードは、レシプロのときと同じく、VSI = 500 ft/min なら 50 ft 前と VSI の 1/10 の数値 (= そのままレートを維持するとしたら 6 秒前相当) になる、また、今後 Traffic Pattern などをやっていく上で 750 ft/min が基本になるという。

最後にエンジン音を消すと、途端に操縦がガタガタになり、やってはならない VSI 追従をしてしまう。いかに普段、視覚以外の情報に頼っていたかがわかる試行だった。次回以降は 6 軸モーションを使うこともできるため、新しい発見があるかもしれない。

次回以降に備えて、降下角 3° (Final Approach)、4° (TOD からの Descent)、3.5° (いま話題の RJTT RW 16R/16L Approach) の Descent Rate と A/S の関係を計算しておく *3。

Air Speed (kt)		Descent Angle (degree)
		3.0	3.5	4.0
Descent Rate (ft/min)	500	110	95	83
	750	165	142	124
	1,000	221	189	165
	1,250	276	236	207
	1,500	331	284	248
	1,750	386	331	289
	2,000	441	378	331

本日の重要ポイント

• Constant Speed & Rate Climb の操作方法
  • まず Pitch で姿勢を作って A/S ⇔ Alt (Climb / Descent の場合は VSI) の位置・運動エネルギー変換を行う
  • 位置・運動エネルギーの過不足は A/S に現れるため、A/S の過不足の量をみて Power を調整する
  • 基準点を所定 VSI に置くだけであり、Straight & Level の操作と本質は変わらない
• Exit Lead は VSI の 1/10 の数値 (= 6 秒前相当)
• Traffic Pattern では 750 ft/min が基準となる

*1:トレンドベクターは 10 秒後の状況を予測しているとのこと。

*2:ジェット機でも Power = 63%, Alt =6,000 ft と固定目標を定めておけば、理論上は A/S = 240 ft へ徐々に収束することになるが、Pitch が揺らげばそれだけ Drug となり、Gust 等でも諸元を狂わされるため、実際には収束しないという。

*3:こうして計算してみると Final Approach の Glide Path を 3° → 3.5° にすると、Descent Rate を維持するなら A/S がかなり減じられる = 迎角が大きくなってパイロットの視線と滑走路が成す角度は 0.5° 以上に大きくなり、また Stall すれすれの低速になるため安全バッファーがなくなる、一方で A/S を 165 kt に維持するなら Descent Rate を 2 割増の 900 ft/min 程度にしなければならず、これまた判断や操作のリードタイムが削られ安全バッファーがなくなることがよくわかる。

Functional Programming w/ C# LINQ

C# 8 switch 式の威力はすごい。EntityFramework Core 用の Upsert が実質 3 行 *1 で記述できてしまった *2 。

public static void Upsert<T>(this DbSet target, IEnumerable<T> source) where T : class, IDbMappable =>
  source
    .GroupJoin(target                    ,
               l      => l.GetKeyObject(),
               r      => r.GetKeyObject(),
               (l, r) => r.FirstOrDefault() switch { // data-driven table operation with side-effect expected
                 null                     => target.Add(l) as T, // Insert
                 var f when ! f.Equals(l) => f.Substitute(l)   , // Update
                 _                        => l                 , // Nop
               })
       .ToList();

同一キーレコードであるものないもの、同一値レコードであるものを GroupJoin() と switch 式を用いることでグループ分けし、データドリブンで次のアクションを Insert / Update / Nop (何もしない) と振り分ける。

ラムダ式を要求する LINQ によるデータ処理であるため switch 式を使うのだが、switch 文 ではなくわざわざ switch「式」を使っているにも関わらず、副作用に依拠してテーブル処理しており、逆に出力 ToList() は何も利用していないのがトリッキーである。switch 式がすばらしいのは、変数宣言式が使えない現行 C# にあって、var f として型推論・変数代入で受けられるところ。これにより手続や条件分岐を冗長に記述することなく Equals ()や Substitute() *3 といった式にかけられる。

LINQ を使っていると、データ変換の一連の式の内部で途中結果を複数回参照する場面が多々あり、

var obj    = new { Text = "Sample", Value = 1 };
var result = (var x = obj.Value + 1) * x;

のように、式の流れを止めずに変数宣言式を用いて中間変数を定義したいところだが、これができない。今後は、代わりに

var result = (obj.Value + 1) switch { var x => x * x };

と中間変数を受けるだけの目的で switch 式を使うようになるかもしれない。

*1:Upsert の本質は (l, r) ～ f.Substitute(l) の 3 行。

*2:IDbMappable はデータベースにマップする Record が具備すべきインターフェースとして定義しており、主キーとなるオブジェクトを返す GetKeyObject() メソッドをデフォルト実装している。

*3:Substitute() は Record の全プロパティ値を引数のそれに置き換えるメソッドとして定義している。= で代入すると変数の中身ではなく参照が置換されてしまうため。

Training in Commercial Pilotage with FTD - Scanning

都内某所で Flight Simulator による F/O 訓練。B737-800 で 2.0H。

Acceleration / Deceleration

本日の訓練内容は Acceleration / Deceleration (増減速)。前回と同じ K 教官。

前回 Take Off からの Climb & Level Off がうまくいったため、今回もある程度うまくいくかと思いきや、Heading 100 へ右旋回を指定されていたため転針に気を取られ、教官に指摘されるまで上昇を続けてしまい、700 ft も Overshoot してしまう。前回と比較するといろいろとブレるものの、それでも以前よりも Scanning と操作が丁寧になっており、大きく逸脱することはない。ということで増減速の練習開始。

10 回弱の増減速訓練と教官の助言により開眼。これまで一切できていなかった操作のリード設計ができるようになり、また、操作と Scanning が連動するようになる。操縦とは (Pitch & Roll の) 逸脱を収束させることと悟りけり。実感として得たポイントは下記のとおり。

本日の重要ポイント

Pitch の揺らぎと Roll (Bank) の揺らぎを同時に制する

• 全般
  • Pitch も Bank も Power も (所望方向へ動くために) 変化させたら (安定する水準へ) 戻す
  • Yoke はきちんとグリップし、Pitch Up / Down ともに反応が遅れないようにする*1
  • Yoke 操作する腕はアームレストを使い、Pitch を固定できるようにする
• Altitude
  • VSI の揺らぎを "先読み" してフゴイドを収束させる
  • ただし、操作の基準水準は Pitch に置く (VSI を基準にすると Delayed Feedback により揺らぎが発散する)
  • 増減速では Power 操作後、徐々に変化していく VSI 揺らぎの強さと水準に応じて Pitch の基準水準を変えていき、Altitude を維持する
  • 高速時は Pitch に対する Altitude の感応度が高いため、Pitch は特に精緻に制御する
  • 低速時, 減速/降下 Exit 時は Power に対する Altitude の感応度が高いため、Power 操作は適切なリードを設計する
• A/S
  • Altitude を維持していれば、徐々に意図した方向へ増減速していく (Altitude を維持しないと A/S が意図した方向へ安定的に移行しない)
  • Trend Vector (A/S 加速度 を示す Green Arrow) が Target A/S の Bug を超えないように徐々に Power を修正して Exit を図る
• Power
  • 6,000 ft なら増減速 Exit 時に安定する Power Settings は 220 kts = 61%, 240 kts = 63%, 280 kts = 67% くらい (現在は訓練のためいつも重量固定としている *2 )
  • 適切なリード, タイミング, 変量を設計する (早くても遅くても Altitude か A/S が大きく狂う)
  • 急操作はしない (急操作をするとその後の変化にうまく対応できなくなる確率が高い)
  • EICAS は凝視しない、しかし、Power 操作前の水準、操作後の水準と左右出力差は必ず確認する
  • 左席から右手で Throttle 操作をすると小指側 (右エンジン) の出力が相対的に低くなる傾向がある
• Bank
  • PFD 上部を見て Bank Indicator の揺らぎを収束させる
  • ND は結果としての Heading Deviation がわかるため、これを情報源とすると事後修正しかできない
  • Bank が 0 であれば Heading はズレない
  • Bank 0 ±0.2° (1 ドット) 以内で収束させる精度が身につけば
    • Bank/Heading 調整は PFD 上部/下部の Bank Indicator/Heading Indicator で完結する
    • エンジン左右の出力差が Heading に与える影響を感じられるようになり、N1 Power Balance を繊細に制御するようになる

*1:これまで Up Trim ぎみにセットし Yoke を常に押すことで Neutral としておき、圧を緩めることで Pitch Up していたが、その方法だと Up / Down が非対称となる。特に Trim が Fit する点以上に Yoke を引かなければならない時に圧緩和から Yoke を握り直して人差し指で引く操作へと必要動作が変わってしまうため、スムーズな移行と繊細な操作ができておらず Pitch Up の反応が遅れる傾向にあった、と思う。

*2:本来、諸元は高度と重量に依存する。

Training in Commercial Pilotage with FTD - The Best Take Off Climb

都内某所で Flight Simulator による F/O 訓練。B737-800 で 2.0H。

Acceleration / Deceleration

本日の訓練内容は Acceleration / Deceleration (増減速)。前半戦は初対面の K 教官。前回の Straight & Level Check の完了後、その感覚を忘れないように訓練頻度を高めようと 3 週間おきに 2 回の予約をしていたのだが、体調不良で 1 回欠席し、結局 1 ヵ月半ぶりの訓練になる。この間、イメージトレーニングもほとんどしていなかったのだが、今回、操縦し始めてみると自分でも驚くくらい、滑らかに安定してコントールできている。高度・速度調整も細かく、旋回しながらでも滑らかにこなす。

6,000 ft に上がったところで Acceleration / Deceleration をやってみましょうということで、これまで 240 kt 一定だったところを 200 ～ 280 kt で変化させてみる。A/S・Alt・Power の相互変換と Pitch との関係などはきちんと理解しており、正しい方向に対応できるのだが、やってみて難しいのはやはり Power 変量やリードの適切な設定がわからないということ。教官から助言してもらったのは、A/S ゲージに表示されている、グリーンの矢印 (= A/S 変化率) の先がマゼンタのバグ (= A/S 目標値) に近づいたら Power を「じわじわ」と戻す、ということ。これがまさしく正鵠。この方法を実践すれば困ることがない。

教官から「これだけうまく操縦できるのなら Straight & Level や Acceleration / Deceleration だけではもったいない、いろいろやってみましょう」と言われ、RJTT RWY 34R から Take Off → Landing をすることになる。ここで FD (Flight Director) なるもの *1 を使ってみる。アナログの ILS 指示器は 1 ～ 2 度使ったことがあるが、FD を利用するのは初めて。十字となっているところに ADI の中心点をもってくればよい、ということでそのようにしてみるが ... 大きな操作を大して必要としない Traffic Pattern を飛んでいるはずなのに FD があっちへ行けこっちへ行けと上下左右に激しく動き回り、外の景色もグワングワン揺れている！ たまらず「なぜこんなに激しく動き回るのか？」と教官に聞いてみると「十字を追従する操作が激しいから」だと言う。なるほど、十字と中心点との位置合わせに夢中になってしまうと、目標コースに対し機位は合っても運動量が合わず Overshoot することになるわけで、目標コースへ徐々に Intercept することを心掛け、滑らかに十字追従すればよいと理解した後は、Smooth Flight になる。3,000 ft, 165 kt の低高度・低速で飛行を続け、そうこうするうちに RWY 34R Short Final で PAPI が見えてくる。最後 Power を絞るタイミングを教官に Cue 出ししてもらったものの、 ジェット機で初めての Smooth Landing。あまりに Center Aligning だったため、次に Take Off するときに設定初期化済みだと勘違いしてしまったほど。

1 時間たったところで教官交代して後半戦、また Acceleration / Deceleration の訓練。RJTT RWY 34R Take Off からいつものように 6,000 ft, 240 kt を目指す。過去最高の Smooth Climb & Level Off で 5,000 ft から 1 分 23 秒で 6,000 ft ± 20 ft, 240 kt ± 0.4 kt, Heading + 1°にて Stabilize する *2 ... のだが、教官が「Stabilize したらコールしてください」と言うため、ここから Deviation を潰さなければならないのかと考えるも集中力がなくなり、時間が経つうちに Deviation が ± 60 ft、± 2 kt と却って広がってしまう。敗因は Deviation を潰そうと意識しすぎて維持目標を Pitch から VSI に移してしまったこと。VSI は結果として動くものであり、変化の初動と方向を捉えるのには向いているが、遅行指標である VSI を目標とすると Delayed Feedback に基づいて操作することになり Overshoot するという基本をうっかり忘れてしまう。

集中力は切れたものの、教官からは「現役パイロットと勝負できるくらい繊細なコントロールができている」との評価をいただき、Acceleration / Deceleration へ進む。後半戦をやってわかったことは、Acceleration よりも Deceleration の方が仕上げるのが難しいということ。Climb よりも Descent の方が Level Off するのに難しいことに似ている。低速はコントロールが効きが悪いこと (加えて、ジェットはレシプロに比べてエンジンのレイテンシーが長く、諸元変更時の反応が悪いこと) に起因している。逆に高速は Pitch のわずかなズレが Altitude の大きなズレを招く。 減速・低速・降下時は仕上げに、高速時は Pitch に特に意識を向ける必要がある。

また、Power Setting のために EICAS に視線を向けると Pitch が大きく狂うのが弱点。克服するには、Throttle レバーをどれだけ動かせば ΔN1 = 1% か感覚を掴み、EICAS は水準を確認するためにちらっと一瞥するにとどめる必要がある。さきほどの Climb to and Level Off at 6,000 ft の時と同じく、VSI ではなく、目標を定めて Pitch を固定することが重要。Scanning の 70% は Pitch であるべき、とは教官談。たしかに Pitch を一定枠内に固定しておきさえすれば A/S, Altitude, Power の修正量は簡単に把握でき、また、微修正で済む。

その後、Constant Rate Climbing / Descent, Constant Speed Climb / Descent 等 (いま Guam の Instrument Flying コースにて不定期で実機訓練している) 科目に取り組む。教官から矢継ぎ早に指示出し。その中で、6,000 ft から 7,000 ft に上昇しましょう ... (心の声：はいはい、いつものとおり Throttle を 7 - 8% Up と) ... Climbing Rate は 500 ft/min で ... (Constant Rate Climb ですな、500 ft/min なら穏やかな Alt Transition、適切な Pitch を穏やかに探って) ... その間に 260 kt から 220 kt へ落としましょう ... (なに！？ Throttle を戻す、いや、かなり絞らないと) ... なんて応用問題も。

得たインサイトが多く、また、自身の技量向上をはっきりと自覚した有意義な訓練であった。

本日の重要ポイント

• Scanning の 70% は Pitch
• (Pitch も FD も) ゆっくり動かし、じっと耐えて安定させ、必要変量を見極める
  • VSI を目標にすると Delayed Feedback により Overshoot する
• Throttle レバーの必要操作量を手感覚で掴む
  • 1 kt = 20ft = ΔN1 1% (戻し操作必要) のトレードオフと合わせて覚える
• 増減速時の Pitch 変化、Yoke の Feedback は徐々に変化していく
• 増減速の仕上げでは、グリーンの矢印 (= A/S 変化率) の先がマゼンタのバグ (= A/S 目標値) に近づいたら Power をじわじわと戻す
• 減速・低速・降下時は仕上げに、増速・高速・上昇時は Pitch に特に意識を向ける

*1:Flight Director : PFD (Primary Flight Display) 上で、目標とすべき Pitch, Bank をマゼンタの十字 FD Command Bars で示すもの。

*2:スクールの Allowance は Altitude ± 20 ft, A/S ± 1 kt, Heading ± 1°。

Training in Commercial Pilotage with FTD

都内某所で Flight Simulator による F/O 訓練。B737-800 で 2.0H。

Straight & Level Flight

いつものとおり Take Off from RJTT RWY 34R から 6,000 ft, 240 kts での Straight & Level Flight。

この一か月は多忙でイメージトレーニングできず、また本日は体調が悪いため、ステップチェックの水準には至らないと N 教官に予告しておく。「では、１時間だけいつもの通りの訓練をしたら、羽田・成田でトラフィックパターンでもしますか」と提案されるも、新しいことを始めたら操縦の感覚が狂うような気がして逡巡する。いつものメニューをだらだらとして過ごすのが今日のところはベストということにしておく。

K 教官と 1 時間 15 分ほどいつものメニューを基本としつつ、高度を 6,000 ft, 7,000 ft, 8,000 ft の間で変えてみたり、240 kts を 220 kts にしてみたり、重量を重くしてみたり、オートパイロットにして諸元修正のリードをモニターしてみたり、と少しだけ逸脱してみる。そのおかけでいろいろと発見あり。「今日は収穫があったな～、後でビデオを見て復習し、次回のステップチェックに備えよう」と思った矢先 ... N 教官から「さて、ではステップチェックしましょう、K 教官からエンドースが出ました」と。いやいやいや、今日はムリでしょうと思いつつも、まあダメもとでやってみる。

Take Off から 5,000 ft までは、Heading Deviation もなくきれいに安定して上昇する。5,500 ft から 6,000 ft までは、Power の適切なリードがいまひとつわからず 60 - 68 % くらいのレンジで上げたり下げたりして VSI が大きく揺らぐ。さきほど撮影したオートパイロットのリードを参考にして復習してからチェックに臨もうとしていたくらいであるため、Transition がまるで設計できていない。

5,000 ft 超えて 2 分以内に 6,000 ft で Stabilize、そのまま 2 分維持という目標に対し、x 分 xx 秒 *1 で Stabilize @ 6,000 ± 5 ft、240 ± 0.1 kts, Heading 337 ± 0。不合格かと思いきや「合格者の平均タイムの半分で優秀だった」と合格。体調が悪く今日はないなと思っていた Straight & Level Flight のステップチェックをクリアしてしまった。

本日の重要ポイント

• VSI の針が Neutral Position にまとわりつくよう (= 針 1 本以内) に Deviation を抑える
  • ただし、操作の対象は Pitch であり、VSI を目標にしてはならない
• Pitch 維持・調整には、ADI の中心点だけではなく Model Plane の Wing の上辺・下辺も含め近隣の Gauge の上辺・下辺に最も近い部分を効果的に利用する
• Constant Rate Climb / Descend のスキャンは、ADI の Pitch ⇔ VSI (500 ft/min 未満は針、500 ft/min 以上は下辺の数値) の間を行き来する
• 重量増加、低速の場合の安定姿勢はより Pitch Up になる、安定する Pitch を早めにつかむ
• オートパイロットによる Transition は２段階で Intercept する
  • VSI レートが高いと目標高度への Intercept が難しいため、マニュアル操縦も 2 段階調整による Intercept をするとよい
  • あらかじめ、± 1,000 - 2,000 ft @ 500 ft/min などの穏やかな Transition のレートやリードを憶えておき、1 段階目はこのレートへ落とすことを目標にする

*1:ネタバレになってしまうため、タイムとクライテリアは非公開とする。

Functional Programming w/ C# LINQ

Python は好きになれない。

Python の長所と言われているものは、プログラミング初心者相手のごまかしであるか、あるいは C などの古い言語に対するアドバンテージであり、ライバルとなる他のモダン言語に対するものではない。オフサイドルールも弊害が大きくて嫌いであるが、一番の嫌いな点は、列挙 (Enumeration) の論理構成が直感に反し、思考がいちいち妨げられることだ。思考の順序と異なるために読みにくいし、書くときはカーソルを右に左に大きく動かさなければならない。

列挙の扱い方を C# (LINQ メソッドチェーン) と Python とで比較してみる。

1 から 10 までの整数のうち、偶数には 'Even', 奇数には 'Odd' を付してタプルを返す

  // C#
  Enumerable.Range(1, 10)
    .Select( x => x % 2 == 0 ? (x, "Even") : (x, "Odd") );

偶数なら 'Even'、そうでないなら 'Odd'。条件式 → 結果１ → 結果２ と並ぶ。

  # Python
  [ (x, 'Even') if x % 2 == 0 else (x, 'Odd') for x in range(1, 11) ]

'Even' を返すよ、偶数なら、そうでないなら 'Odd'。結果１ → 条件式 → 結果２と並ぶのは非常にみづらい。
なぜ、条件式を結果ではさむのか。

1 から 10 までの整数のうち、偶数のみを２乗して返す

  // C#
  Enumarable.Range(1, 10)
    .Where( x => x % 2 == 0 )
      .Select( x => x * x );

1 から 10 を対象として、偶数に絞り、２乗する。お題の指示の順序の通り。

  # Python
  [ x * x for x in range(1, 11) if x % 2 == 0 ]

２乗を返すよ、1 から 10 を対象として、ただし偶数のみね。うーん。なぜ、列挙を map と filter ではさむのか。
２乗を返すよ、から始めるならせめて、２乗を返すよ (map)、偶数のみね (filter)、1 から 10 を対象として (enumerate)、にならないものか。

ジャグ配列をフラット化する、フラット化して各要素を２乗する

  // C#
  var arr = [ [1, 2, 3], [4, 5, 6], [7, 8, 9] ];

  arr.SelectMany( i => i );                      // フラット化
  arr.SelectMany( i => i.Select( j => j * j ) ); // フラット化して各要素を２乗

SelectMany で要素を掴む i が IEnumerable<int> 型であることを意識すれば難しくない。

  # Python
  arr = [ [1, 2, 3], [4, 5, 6], [7, 8, 9] ]

  [     j for i in arr for j in i ] # フラット化
  [ j * j for i in arr for j in i ] # フラット化して各要素を２乗

[ j for j in i for i in arr ] と書きたいところ。なぜ arr と要素変数 i, j がこのような並びになるのか。

Python は列挙を扱える点において古い言語よりアドバンテージがあるが、その文法は

• 列挙走査 (for) は後置する (ただし、複数の for はネストの上位から下位に向かって並べる)
• if は後置する (if - else 三項演算子は後置 if の語順を踏襲した発展形)

というようになっている。

Perl の if 修飾子を参考にしたのか、全体的に SQL の語順に似ているが ... と想像をめぐらすが、いずれにせよちぐはぐ感は否めない。列挙に対する map, filter, reduce 操作をスムーズに記述するだけの統合感・先進性には欠けており、思考を乱す順序でしかロジックを記述できない言語であると思う。データサイエンティストに好まれるというのが信じられない。

Training in Commercial Pilotage with FTD

都内某所で Flight Simulator による F/O 訓練。B737-800 で 2.0H。

Straight & Level Flight

いつものとおり Take Off from RJTT RWY 34R から 6,000 ft, 240 kts での Straight & Level Flight。

ADI での Pitch 維持を中心に据えることを心掛け、前回よりも安定するようになってきたが、まだ 2 分で安定させるに至らず。
今回は特に Tips なし。ただイメトレあるのみ。