Web Analytics

Technically Impossible

Lets look at the weak link in your statement. Anything "Technically Impossible" basically means we haven't figured out how yet.

42 Piscine Examを読み解く 印象、考察、そして余談。

4週間のPiscineにおいて、毎週金曜日は試験日のようだ。最初の三週間は各4時間のExam 00~02、最終金曜日は8時間のFinalということらしい。

他の投稿で参照しているようなPDF資料を見つけることはできないかと探索してみたものの、信頼できそうなものは見つからなかった。フランス語版の英訳らしきPDFファイルは、文章は英文だが、出力例の部分がフランス語のままであったり、また検索にヒットする情報のほとんどはASCIIファイルで、むしろPDFの方が信憑性が疑わしくなる。
それら、見つかったASCIIファイルはレベルごとのフォルダに整理されている場合がほとんどで、何らかのトレース(採点結果?)を伴う場合が多く、こちらの情報の方が信頼性が高いのではないかと判断した。

今回のまとめでは、これら数々のASCIIファイル、並びにそれらが格納されているフォルダにまとめられた情報に基づいて、印象的だった部分を紹介する。
ここで紹介する情報が東京校のPiscineに通用する保証はなく、内容の正しさを保証するものでもないことを申し添えておく。Piscine資料に記載されている如く、Piscineに伴う噂がまた一つ増えた、程度に受け取ってもらえればと思う。

• Only this page will serve as reference; do not trust rumors.
Watch out! This document could potentially change up to an hour before submission.

注意

Piscineそのものが4週間の試験だが、その試験期間中に実施される「試験」ということで、引用している情報の各所を伏字「*****」とした。これまでの投稿と異なり、参照先も明示しない。
分からなければインターネットで調べ、それでも分からなければ人に聞く、のが42のスタンスなので、どうしても問題を知りたい人はインターネット検索から始めてみればよいと思う。そうしたところで真偽判定は当事者次第なのだが。
ちなみに、参照情報の出所は42SV、そしてパリ校と推測している。英語であることはもちろんだが、所々にフランス語が混ざっているのだ。

問題と難易度

レベルごとに用意された問題の数々を確認していくと、いくつかのことに気付く。

  1. 該当週までの課題で取り上げた領域からの出題
  2. 日々の課題からの出題、類題が多数
  3. コードではなく、その出力結果を評価?
  4. 問題ごとに異なる配点

試験問題は、日々の課題と同等レベルのものが出題されている。例えば42SV Day02 Exercise 02の課題はft_print_numbersという、数字を一行に昇順列記して出力せよ、というものだった。仮に試験問題の類題として、

  • 降順列記せよ
  • 数字を列記するのではなく、アルファベットを順番に...
  • アルファベットを順番に、奇数番目は大文字で...

などと出題されたところで、よほどの勉強不足でない限り、難易度が上昇する、課題のレベルを著しく超える、とは感じられないはずだ。
再帰Brainfuck、メモリ・ダンプ、何にせよ確認した限りの試験問題では、終始このような感じだった。

成果物は何らかの出力を求められている。試験は、この結果を採点対象としているようだ。確認した問題には何らかのトレースが記録されたファイルが添付されており、次のようなdiffコマンドが記録されている。情報源はフランス校だろうか。引数の文字列にフランス語が記述されている。

🔎Diff

$> ./*****
$> diff -U 3 user_output_test1 test1.output | cat -e

Diff OK :D
Grade: 1

$> ./***** "voiCiI un Test POur la longueurs des arg" "Ici" "i"
$> diff -U 3 user_output_test5 test5.output | cat -e

Diff OK :D
Grade: 1

仮に模範となるコードが存在していたとしても、それを回答コードとdiff比較して採点するのは困難だろう。一方、求められている出力結果が予測可能なものであれば、それをdiff比較するのは効率的ではあるものの、コードそのものの評価はどうなるのか、が気になる。
あるいはコード自体は評価対象とされないのかもしれない。それはDay00に配布される資料の一つ「The art of peer-evaluation」での言及に通底する考えだ。該当箇所を引用する。コードの記述では採点しない。コードが動作するか否かで採点する、と言っている。

Don’t grade how the code has been written. Grade if the code works or not.

回答が何らかの方法で採点され、最終評価が出力される。不思議なのがsuccess/Failureの基準だ。一番左が点数だとしても、1~2でFailureもあれば、0でSuccessもある。訳が分からない。

🔎Success/Failure

Start time: **/**/**** **:**:** UTC
End time: **/**/**** **:**:** UTC
Mode: real
Final grade: 75/100

Assignments:
Level 5:
2: ***** for 10 potential points (Failure)
1: ***** for 15 potential points (Failure)
0: ***** for 20 potential points (Failure)
0: ***** for 16 potential points (Success)
0: ***** for 16 potential points (Success)
1: ***** for 11 potential points (Success)
0: ***** for 16 potential points (Failure)
0: ***** for 16 potential points (Success)
0: ***** for 16 potential points (Success)

問題は課題と同等レベルで、英語が難解というわけでもない。そうなると問題が適切に回答できること以外の意図があるのだろうと勘繰る。
42の特徴はpeer learningであり、その仕組みは自力で学習し、学習内容を他者に説明し、理解させて答え合わせする、というものだ。これに通じる何かがあるのではないか?と考えるとことろで考察が始まる。

考察

仮にテストが100点のA氏、0点のB氏がおり、彼らは過去に二回、お互いreviewer/revieweeを経験するpeer learningを実施していたとする。このときA氏の100点、B氏の0点は数字通りに評価できるだろうか。例えば、A氏には次のような懸念がある。

端的にできない 教える能力がない 100点を取る実力があるのに、その知見を他人に教育できない。
できるのにできない
できるのにしない
教える能力不足 100点を取る実力があり、それを教えられるのに、他人に伝わらない。あるいは伝えられない。

一方B氏にも、次のような懸念がある。

端的にできない 学習能力がない 100点を取る実力者と同席しても、何の進歩もない。
できるのにできない
できるのにしない
学習能力不足 100点を取る実力者から教えられても、結果として何も理解、学習しない。あるいはしようとしない。

A氏とのpeer learningは、B氏に何の効果、貢献もなかった、という見方もできれば、B氏はA氏とのpeer learningから何も学ばなかった、という見方もできる。
もしpeer learningの結果を評価対象とするならば、review、reviewee共に高得点であることを見つけるだけでなく、peer learningの結果として生じる得点上昇を測るべきだろう。点数そのものが高得点であると同時に、peer learning相手との点数格差が小さい者が、42の学習スタイルに適していると判定できないだろうか。
つまりPiscineは、このような人達を識別する試験ということだ。

  • 自ら高得点であり、自らと同等レベルに他者を引き上げられる経験者
  • 自ら高得点であり、より高レベルの他者と同等に成長できる初学者

peer learningの効果を評価するには、特に初学者の点数が、努力によって経験者の点数に迫れる程度に差が開く必要があり、大差が開くほどの難易度の問題は避けなければならない。
同時に、特に初学者が勉強、理解し、それを「習得」していることを判定するには、過去にできなかったことが、できるようになっていること、を発見できるのが有意義だろう。
日々の課題、その類題は、その発見を識別するために適した問題であり、だからこそ意図的に試験問題として出題しているのではないだろうか。

グループ・プロジェクトにしても同様だ。所属メンバー各人による説明から、「最低」の説明が評価対象となる。このことは、プロジェクト資料の読み解きで触れた。
コードが実施していることを理解していないメンバーには、それを理解させる説明が必要だろうし、それを理解させるに必要な知識が不足しているならば、やはり誰かが、それらを理解させなければならない。
「最低」のものを可能な限り「最高」に近づける努力が求められているし、そのように仕掛けられている。経験者の独走を許さない仕組みだ。これに通じる仕組みが、あらゆる評価機会に反映されているのではないだろうか。

余談

初学者は経験者に貢献できることがことが少なく、レビュー(peer learning)に臆するのだという。考察した仕組みが機能するとすれば、レビューでの貢献は問題でなく、むしろ期待すらされていないことになる。経験者へ有意義に貢献しようとするならば、特にPiscineにおいては、レビューを通じて学んだことを試験に反映できるほど確実に初学者が「習得」すること、ではないだろうか。

報酬を求めた外発的動機によってなされる行動は、報酬が無くなれば、その行動がなされなくなる、というアンダーマイニング効果と呼ばれる現象がある。EXPと呼ばれるポイントのやり取りに終始したレビューでは、この効果の発現リスクがあり、初学者の積極的参加も難しくなるだろう。
アンダーマイニング効果のリスクは失われないものの、その報酬をPiscine通過に収斂させることができれば、アンダーマイニング効果はPiscine期間中は無力化できるだろうし、初学者に対する、経験者からの積極的なサポートも期待できる。

この観点からPiscineにアプローチするならば、他人と積極的に対話するだけでなく、それを通じて自分自身の成長を示すと同時に、試験やプロジェクトで実績として残す行動が求められるだろう。

By Odin, by Thor ! Use your brain !!!