ぐるぐるコメント_その1

Cで配列に命令書いて実行できないかという件。Unix 系 OS なら 普通はできるんじゃないかと...

確かに データがおいてある領域にコードおいて 実行可能かどうかというのは、 OS や アーキティクチャに依存したりすると思うんですが ... mprotect(2) を使えれば 実行可能にする属性を付けたりできます。 で、この mprotect(2) man 見れば POSIX.1b に含まれているみたいなんで、 POSIX 対応と いう OS ならあるはず。

あと、上とは直接関係ないんですが ... gcc ってスタックにコード 埋め込むような ことするコードが出たりするんじゃなかったかと。 どういう時出るかちょっと知らないんですが、トランポリンとかいうのがあって ... 以下略 (というよりちゃんと説明できず)
これと関係あるかないか も良く知らないんですが、コードを書き換えたら キャッシュをインバリデートしないといけないようなアーキティチャもあって、 なんか gcc 依存の変なコード書いてみたら、CACHE_FLUSH_FUNC で定義された コードが出て 困った覚えあり。(mips だと _flush_cache というのが出たんだったか)

• 場あたりクイズ Q: キャッシュフラッシュしないといけない 変なコードとは... どんなコードでしょう？
• 自己書き換えコードかな？先に命令がフェッチされている分を捨てなきゃいけないから。どうでしょう？

javaVMの仕様になぜnativeOSへの呼出しが入っているんだ という疑問について。

java VM ってVMだと思うから変に感じるのでは？ 似たものをあえてあげると、 MAC エミュレータの executor とか Windows エミュレータ の !FX32 みたいな。( 名称間違っているかも)
要するに userland レベルのエミュレーションと考えると、システムコールだとか dll 呼出しが込みになってても不自然ではない...と思う。 ( 動かそうとするモデルが実在すればエミュレーションだけども ... 実在しないから、ヴァーチャル エミュレーション？ )

ここから妄想モード。hpcmips の バイナリ用 userland レベルエミュレータ があったら個人的に嬉しかったりするんだけども... 嬉しい人他にいないかなぁ。

• なにが嬉しいかというと、hpcmips の セルフmake 環境のように振舞う システムが作れる。そうすれば、cross で package が make できるようになる。 で、make のネックになる、gcc なんかは、native に 置き換えちゃえば、 速度の問題も起きない。

NetBSDのシステムコールエミュレーションと MIPS の命令エミュレータ くっつければ 作れるような気がするんだけども... (LinuxVR用 だってできたり するかも)
fork なんかは、native OS の fork を呼んで VM(っていうのかこれ) ごと fork しちゃえばよさそう。( って実は、別の用途で こういうやつ作ったことがあって それができたのは 確認済)

妄想はつづくよ....

で、NetBSD/m68k あたりを標準のアーキティクチャにして、VM をばらまいちゃえば java に対抗できないかなぁ。--- え？ 無理？

• あー。MAC とか WinAPI とか つらいなぁ。--- いやいや POSIX API が ないシステムが変なのであって、cygwin とか cygmac(ないけど) 使えばよろしい。

妄想おしまい。

create_memscreenできるタイミングについて

あー そうだったのか。MGL1 の方は、フォーマットが決まっていて malloc 呼ぶぐらい だから いつよんでも 全然問題ないけど、MGL2 だと create_memscreen は ラッパーで 処理関数自体を open_graph() で 組み込んでいくので open_graph() 以降でないと ダメっす。この仕様が使いにくいってのは認識しているのだけども、とは言っても 他の良い方法が見当たらず...(以下略)

libdl は、あれっすね。BSD 系は libc に組み込みなのに対して、SVR4、ソラリス、 linux は libc の 外にあるっつうか。気をつけないといけないのは、ELF 系では C の シンボルに _ が付かないのに対し、BSD の AOUT 系では C のシンボルに _ が 付き、dlsym とかの API で _ を付けないといけないことぐらい。

ちなみに、MGL1 も FreeBSD or Linux の X 環境の上で 動きます。 MGL2 と両方インストールすると mgterm がバッティングするんで、ご注意を。

真のプログラマはPascalを使わないの考察 なかなか興味深い。

Pascalで教育を受けたころは、FORTRANしか使えない人のヨタ話ってのは 言いすぎだが、そういう印象を持っていた。今考えると、共感できる部分も 多々あるって感じか。じっくり考えてみたいネタではある。

高速なJIS-EUCコード変換についてで書いた話だけども、簡単な仕様の JIS-EUC コード変換は、72 行ぐらいで書けるけど、これを高速化しようとしたら 全く同じことしか しないのに 866 行になってしまふって例があって、 わかりやすさ とか 保守性とか と やっぱり相容れない面があるよなぁと 思う。 で、866行の方のコードにも 確実に動くとか 拡張性 とか 結構考慮した つもりなんだが、客観的に見て 書いた自分でも 再度ロジックをちゃんと 追ってみるのは やりたくないようなコードになっちゃている。で、 構造化プログラミングとか言われてた(or 出した？)時代では、こういうコード は 無条件にダメコードに分類されるような気がする。って ..今でもか。 866 行のコードって841 行の 関数1つだし...長さだけでダメダメコードに 分類されちゃうんじゃないだろうか。でも、マクロとか 分割とかして何か分かりやすくなったりするんだろうか...。

って、書いてみたが、同じロジックを分かりやすく書く方法はあるかも知れない。 機会があったら、よくよく考えてみたいって気もしてきた。 それが何なの？と思う人は多いかも知れない....うーん。複雑なものとどうつき合って いくかというのは、自分にとってわりと重要なテーマであって...(以下略)

とりあえず、翻訳をみつけた。( 真のプログラマはPascalを使わない )

• あと ここ とか (from 有野さん)

あらためて、内容を読んでみると やっぱり過激な表現がいっぱいあったりする。 .. core ダンプを見るのにデバッガを使わない.. とか 実際そういうことを しないといけなかったという経験はあるが... やっぱりデバッガが使えるのなら 使うよねぇ。ここらへんは、真のプログラマには(必要な場合は)デバッガなしでも 問題の原因を見付けることができる とかそういう風に解釈しないと 何を主張しているのかまったく理解できない。 実際 昔目を通したときには、主張したいことが理解できていなかったと思う。

それはともかく、有野さんの例

linux/kernel/sched.c

void interruptible_sleep_on(struct wait_queue **p)
{
        SLEEP_ON_VAR

        current->state = TASK_INTERRUPTIBLE;

        SLEEP_ON_HEAD
        schedule();
        SLEEP_ON_TAIL
}

だけの情報でどこまで読めるか という 命題は 興味をそそる。 ( このコードははじめて見るわけではないが、はじめて見たとして 解説してみると)

ファイル名で、Linux カーネルの スケジューリングのコードである。

という情報は得られる。

そして、

interruptible_sleep_on(struct wait_queue **p)

という関数名と引数の nameing だけで、プロセスが sleep し、sleep する ための リソースは、waitキューである。ということがわかる。 それに interruptible というオプションが付く。 ( sleep がどういう意味か というのは、OS の構造を知っていれば 既知の知識)

interruptible というオプションについては、interrupt されてどうなるかというと、 起きてくる以外には考えにくいので、そういうものだろうと想像はしておく。 ただし、名前だけ見て決めつけるのは、まったく外している危険性があるから、 確認すべし。

当然 sleep したからには、wait_queue を引数にして 起こすための wakeup というメソッドが用意されているはずだし、 オプションがない sleep_on もあるだろうということも これだけでわかる。

で中身をみると

{
        SLEEP_ON_VAR

        current->state = TASK_INTERRUPTIBLE;

        SLEEP_ON_HEAD
        schedule();
        SLEEP_ON_TAIL
}

となっていて、オプションがない sleep_on との違いは、state にいれるもの が違うだけだろうと思える。SLEEP_ON_VAR - SLEEP_ON_HEAD - SLEEP_ON_TAIL が マクロになっているのは、同じものを 2 箇所以上で使っているからであって、 inline 関数や関数にしていないのは、たぶん。複雑でないから。

• これは、実際にマクロを見てみると間違っていることがわかる。マクロに しているのは、SLEEP_ON_VAR で 登録する キューのエントリーを スタック上に 取りたいから。

また、マクロの中身は、SLEEP_ON_HEAD で waitキューにつなぎ、SLEEP_ON_TAIL で wait キューから外すもののはずである。なぜなら、schedule() には渡っていかない から。あと、SLEEP_ON_VAR は、当然その操作に必要な変数の宣言。

• ここは、マクロの中身の知識が前提になってしまっている。 上の情報だけで というのはウソ だなぁ。schedule() に渡っていかずとも、wakeup で、waitキューから外す 設計も有り得るわけで、ここまでは判断できない。 とりあえず、マクロは見たという前提をいれることにする。

waitキューから外すということを wakeup 側でするような実装も考えられるが、 Linux では、自分でwaitキューから外す。これは、interruptible というのと 無縁ではなさそうだ。たぶん interrupt して起こす側は、waitキューを知らなくとも 良い インターフェイスになっているのだろう。

また、waitキューと schedule() で使うはずの runキュー は別の構造である。 同じ構造(runキューから外して waitキューにつなぐような) の場合は、この ような 処理にはなり得ない。(wakeup の中で waitキューからrunキューにつなぐ ことになる)

schedule() は名前から プロセスを切替える処理のはずである。 それがどのように処理をしているかは、知る必要はないが...

current->state が状態として 重要なもので なおかつ 唯一のもの(sleep_on にとって)であることはわかる。

また、current は、(いま sleep しようとしている)実行中の プロセスを 指す変数である。 ( Linux が SMP 対応であることを知っていれば 、変数ではあり得ない .. どこかにマクロが定義されているはずである という想像もできる)

想像できる範囲はこれぐらい。コードそのものだけではなく、 それが関連している他の情報も読んでしまうことはできると言える(と思う)。

それを input にしてさらに、他のコードも読む。そのときには、どのようなコード であるかも想像が膨らんでいるから、想像と違うところを重点的にチェックすれば 良い。

さて、コードを読む際に、コメントは必要であっただろうか... 構造化という 話と関係があっただろうか... もっとも重要なものは何だったであろうか？

必要な知識がない人がコードを読む場合は？ コメントがあったら理解できた であろうか... プログラムの構造は重要なのだろうか？ ... もっとも重要なものは何だろう？

実は 上記でこのコードを説明したことにはならない。どのようなものか が分かっただけで、動かないかも知れず検証するという立場だと もっと知らないと いけない。何を知らないといけないのか...

• まず、wakeup との関係。マクロを見ると wait_queue は、 lock してキューにいれたり外したりしている。 なんとなく安全そうに見えるが本当だろうか....
  キュー自身は、lock で保護しているから整合性が取れているはずである。 しかし wakeup がキューを見て プロセスを見付け 実際に wakeup しようとした瞬間に は、sleep 側が先に進んでしまうかも知れない。そのことは interruptible_sleep_on で何も保証していない ということは、コードから読みとっておく必要がある。

• interrupt は、いつ起こり得るのか...
  current->state を書き換えて、 schedule() を呼び出すまでの間に起こり得るとすれば、schedule() に入ったときは current->state が 変更されてしまっていそうである。interrupt する側、 schedule() と interrupt_sleep_on() の関係を state をキーワードにして 正しく理解する必要があるだろうということは、 コードから読みとっておく必要がある。

上で書いたことを知らないと、current->state の変更と SLEEP_ON_HEAD の 順番を 逆にしても動くのかどうか すら 判断できない。そういう意味では 、上のコード読みのレベルでは何も理解できていないということは 認識する必要がある。

真のプログラマー の内容とは違う方向に話題が進んでしまったが...

上の2点に気を付けないといけない ということを このコード見ただけで 私が、なぜ考えたのか...結局のところ、この種の問題についてよくよく考える 機会が過去にあった.. ということになるんだろう。

結局 経験がパターンとして蓄積 されているので、コードは、どのパターンかを判断するために 過不足のない情報量を 持っていると 非常に読みやすい。パターンとして蓄積されていない人にとっては、 最初は意味ないのであるが、新たにパターンとして蓄積しようとしたとき意味が 出て来るのではないか という気がする。構造化というのは、コードをどのように 書くか... ということよりも概念に識別子を与えるという点で重要だったりしない のだろうか？ これは、ランダムに名前を与えた同じコードが分かりやすいか... という実験をやってみれば はっきりするかも知れない。

ただ、真のプログラマはPascalを使わない では、これすら否定しているようなところがあるんだよなぁ。 goto 文の塊から、WHILE や DO などの制御構造を読み取ることができる --- ひょっとしたら、名前がない 制御構造のパターンも読み取れるといっているの かも。それだけではなく、名前のない複雑な制御構造のパターンをパターン認識で 見つけだし、適切に理解することができる... これってやっぱりすごいことではないかと思う。

interruptible_wake_up(struct run_queue **p)
{
        RUNQUEUE_VAR

        current->state = TASK_INTERRUPTIBLE;

        RUNQUEUE_ADD
        schedule();
        RUNQUEUE_DEL
}

私レベルだと、ちょっと名前を 変更しただけで、完全に混乱しそう。 これはいったい何だと問われたら、実際とはかけ離れた想像をしてしまうだろう。
その推測を元に他のコードを読み進めると どこかで矛盾があることに気が付く。 矛盾の本質を探していくと、最初から間違っていたことが分かるだろう。 で、間違いを元に全てを訂正するわけだ。この時でさえ sleep のパターンである ことに気が付かないかもしれない。正しい理解がかなり進んだ時点で、はっと気が 付くかも。sleep というキーワードだけでタグ付けされた知識は役に立たなかった わけだが... たぶんこの時点で、sleep の知識に別のタグが付く。 こうやって、経験をつんでいけば はたして真のプログラマーとなれるのか？... 真のプログラマーへの道とはかくも厳しい長い道のりなのだろうか...

そうそう、真のプログラマーの悲哀についてもコメントがあったような。 上のような、名前すらついていない概念/パターンを 名前を付けないまま扱えても、 他の人と共有できず、理解させることはできない。そういうことなんだろうと 私は理解した。それを救うのは、結局のところ 名前が付いていないものに 対して デザインパターンとして名前を付けるという 行為なのだろうか？

問題は、新たな デザインパターンの登録ということだけでは(たぶん)ない。 あるものを 既知のデザインパターンと結びつける 認識術 というのもまた 重要だろう。こんなものをちゃんと体系化できるのか... かなり疑問ではある。 しかし、真のプログラマーとして客観的に認知したいとしたら、こういうこと をやっていかないといけないのではなかろうか。

暗記が好きな人、嫌いな人

私、暗記が嫌いな人です。

「暗記数学」ってのは わかるような気がするが、それと 「単語帳で単語暗記」 というのが 自分的にはつながらない。この関係について解説していただけると 嬉しいです。

高校ぐらいのときを思いだしてみても.. どうも 抽象的なものは覚えられるけれども、 デジタルなものは ダメ って感じだったと思う。

高校数学は得意で、「問題」と「その解法」の関係はわりとよく覚えられたように 思う。でも、「定理」をちゃんと覚えるのは苦手だったような... 記憶にある「定理」が信用できなくなると、最初からそれを「導き出す」ことを していたような憶えすらある。

「理解と暗記の関係」というのも実はよくわからない。自分のなかでは、 理解=アナログ、暗記=デジタル というイメージがあって... (以下略)

。どうもありがとうございます。

そう、年号暗記もダメでした。ってのはおいておいて...

受験において、全部の問題を条件=解き方の組み合わせで覚えておく事 は確かに 必要で 実際やっていたはず。 でも、私が高校の数学で楽しかったのは、条件=解き方の組み合わせを発見する プロセスだったような... 理解するだけなら答え見れば良いわけで、 理解 そのものにはそういうプロセスは、必要ないのは同意できるんですが、 そうなると 「高い応用力が必要な難問」 をやる必然性は、論理としてどう説明 できるんでしょう？ 理解することは、解き方を覚えておく。そしてそれ以外は 必要ないとすれば、高い応用力が必要な難問 をやる必然性は、解き方 を覚えたかどうかチェックする以外になく、既出のパターンである必要があって それは難問とは言えないはず。そのあたりが引っかかります。

あと、単語帳による暗記について... 数学の説明と良く似た話だとすると、 実は 理解が先にあって、単語帳による暗記というのは、反復による理解の固定化 と呼ぶべきもの... なのかなぁと 思いました。となると 私が暗記だと思っていた ものとはちょっと違うかも。

私がもっているイメージだと、

• 地図をみて 必要なものを覚え、現地にいって役に立てられる。

というのと

• 現地にいった経験をもとに、地図を(くりかえし)みて 経験を知識に変える。

ぐらいの違いがあるような... 私は、前者は全然ダメで、後者は好き。

おお、ながいコメントが。私の 質問につきあってくれて、恐縮です。

とりあえず、テーマは、"難問を暗記する" ということと、"英単語が先か長文が先か" の2つ かなぁ。

でも、問題の方が気になって気になって... そっちから

問題みて

• とりあえず、y と z が対象だから楽できる
• 1+4=5 というのに注目して、XX^2 + YY^2 = 1 + 4 の形にできないか
  と思いました。

で、それにしたがって、すなおにやれば

    (x - y -z)^2 + y^2 + z^2 = 0 + 1 + 4

つうのが出て来るっす。y,z は 正だから x - y - z = 0 ということが言えて y = 1 , z = 2 or y = 2, z = 1 が言え、どちらの場合も x = 3

... と書いたものの、実は、はまった。式をこねくり回しすぎて、変なところに 落ち込んでしまったのでした。

• どうはまったかというと、y+z でとりあえずまとめてみるのは良いとして

      (y+z)^2 + (z - x)^2 + (y - x)^2 - x^2 = 5
      (z - x)^2 + (y -x)^2 + (y+z-x)(y+z+x) = 1 + 4 + 0
  

  と変形してしまったため。たぶん y+z-x = 0 で、x - z = 1, x - y = 2 (y と z は交換可能)という結果だろうとは想像できるんだが、証明しようと するとあれあれ？ということに。

     (y+z)^2 - 2(y+z)x + x^2 + y^2 + z^2 = 5
  

  とできていれば、上の結果にもって行けたんだが...
  こういう 因数分解(って用語自体も忘れてたけど) の やりかたはすっかり忘れているなぁ。
  それはともかく、因数分解をやろうとしたのは、XX^2 + YY^2 = 1 + 4 の形に できるはずだという 予想にしたがったため。結果は XX^2 + YY^2 + ZZ^2 = 0 + 1 + 4 だから予想は ちょっと違ったわけだ。考え方をかえれば、3 つに分けるのが 自然で 2つ にわけるのを予想するのは 甘い という気はしなくはないが...

とりあえず... 落ち着いた。

で、暗記数学の話にもどると... 公式とかほとんど全て忘れているんだけども、 XX^2 + YY^2 = 1 + 4 の形にできないかということだけは 覚えている。 これはパターンなんだろうけど、暗記したもの なんだろうか やっぱり。

まぁ、いろいろな条件とともに覚えたけども、すこしづつ忘れていって、 それだけが残ったというものかもしれない。昔は、理解したものは忘れるわけが ないと思っていたのだが... 実際 理解していたはずのものが、理解できないようになっている というのを 体験してみると.. 理解というのは 記憶の一形態であるということは納得できる。 でも、公式は暗記だけど、パターンの記憶は暗記じゃないような気がするなぁ。

• なんとなく、暗記したものってあいまいさがないような印象がある。 で、そういうものは、覚えているか忘れるかどちらかであって、どちらとも 言えないという状態 (たぶん こうだが、違うかも ... みたいな) あんまり ないんじゃないだろか。

"英単語が先か長文が先か" という話。実は そのこと自体は知っているとは言える 状態ではないので、あえて、地図と現地 で 表現することにします。

地図を見て役立てるのは、ダメと書いたけど、嫌いではなく、見ても分からない のです。地図みて現地へいっても なんど確認しても 地図の知識が全然使えない。現地で右往左往するのだけれども...後で地図みれば 地図がよくわかる。 たぶん、名前なしで理解して、あとで名前を与える ような 記憶方法しか 得意ではないんじゃないかと。--- これは損なんで、なんとかしたい なぁ と 思っている次第。

話がどんどん展開 していますが...

ひとつコメント。暗記は悪 から 暗記数学は悪 みたいな話の流れがひとつありますが、 私は、悪 的な イメージはもっていないです。むしろ、どうやって それを 他の人に伝えられるような、暗記的知識にできるのか という 方法論に興味があって いろいろ 意地が悪いような(自分ではそういうつもりはないんですが、 そう受け取れ兼ねない) 質問になっているわけです。

ポイントは ある共有できていない知識なり理解を 人にどうやって伝えるか ( 伝えられる形にできるか) ということではないか。 自分の中では整理できてしまっていて、人に伝えられそうだというものもあるんだけ ども、実際 やってみると、既に知っている人には伝わるけども、知らない人には 伝わらないということが多々あって、そのあたりの話が一番興味あるところ。

• 立場を逆にすると、知らないことを どうやって理解するかということでも あって、表裏一体なのかも。 既に知ってることを改めて理解する というのは できる。

まあ現在前振り中なんで(笑)
実際に悪、というイメージは、世の中には私はあるとは思いますが、 今書いてるのは、 それよりも今後の暗記と理解の関係についての説明の為の準備です。--有野

• 了解です。今後の展開に期待してます。

という訳で徐々に仕込んどいたネタを使いはじめましたがどうでしょう？ 別に本当にいじけてる訳では無いんですが、 まあ読み物、という事で導入があんな感じになってます(^^;--有野

とりあえず まとめてみる。

暗記シリーズ数学編スレッド

• 暗記が好きな人、嫌いな人 --- 暗記、暗記数学、理解と暗記の関係、単語帳で単語暗記
• 暗記数学と単純暗記 --- 条件=解き方の組み合わせで覚えておく事、青チャート、鉄則、理解=暗記しなければいけないいくつかの事を暗記した状態、暗記数学派
• 暗記とか数学とか --- 難問のパターン、定着を確認、単語に理解も何も無い、暗記以外の要素としての理解は無い
• 作戦を考えてみる
• シリーズ暗記数学第２回 --- 暗記は悪
• 暗記と数学第3話 --- 記憶神話
• 暗記数学第４回 --- 理解と暗記、暗記というのはソラで言えるようになる事、数学理解学派、暗記至上主義、パズル、文書化可能、暗記数学派向け参考書、キッシュイーター
• シリーズ暗記数学第５回 --- 伏線回収、探す努力が貴い系の意見、暗記をすると考えなくなる、第６、７、８回予告
• シリーズ暗記数学第６回 --- 単語の暗記、暗記の方法、本文読む時間、 辞書を引く時間、「うーん」と考える時間、必要な項目の消化、 方法論が数学に比べて開拓されていない、量をやるのが正しいという神話、10回前後予告。
• シリーズ暗記数学第７回 --- 理解について、理解=必要な事を全て暗記していてそれが思い出せる事、 考える=暗記した物を使う力、考える=暗記した物を思い出す事、 考える力をつける=簡単に思い出す事が出来るようになる事、 訓練では思い出せるかどうかは重要視しない
• シリーズ暗記数学第８回 --- 合格至上主義、理由は人それぞれ、合格するような所まで行けば、必要な事はおおむね暗記されている、後で役に立つかは気にしない、「一生懸命やればいい」的考えは基本的には駄目、使うだけの暗記もアリ、コスト
• シリーズ暗記数学第９回 --- 暗記項目として取り出す、取り出さずに暗記というのは実際は暗記しているかは自明ではない、理解=暗記であると信じているかどうか、練習問題への接し方も変わる物が多い、前回やった受かれば良い
• シリーズ暗記数学第１０回 --- 受験観とまとめ、最初から望みを達成しようと考えず受験勉強をするのは悪い、 受験というのはなかなか良く出来ている、先に進むには大量の事をやらなくてはならない、再検証する必要が出てくると暗記数学に行きつく、実際暗記は楽しい、 受験は悪だという風潮に合わない

ここで(第5回時)、リクエストを書いてみるテスト(もっと長くしてどうする！)

• なんとなく、Web日記とか 可能な限り文章を書く というのは、 暗記至上主義となんからの関連があるような気が...もしそうなら 解説してもらえると嬉しいです。
  簡単に説明すると... こうやって私が文章書いているのは、読んでもらうため だけではなく、書くこと自体が自分にとって有益ではないかと思っているため。 いままで何かを書く習慣がなかったので、くだらない話でも書くこと自体で かなり苦労していますが... さらに 何かを書く習慣を説明すると、まず、授業での ノート、取ろうと努力をしたけれども取れたことがない。そこから始まって 、あらゆるメモも役に立てたことが少ないかも。

• 有野さんのコード読みで、"全部読む" とか いう話が出て来るのですが、実は、正確には理解できない。 暗記至上主義となんからの関連があれば解説してもらえると嬉しいです。
  これも説明が必要かも、全部読んだ経験は少ないです。 だいたい読むテーマがあるわけですが、可能な限り、読まないで済むことを 考えて 読んでいるみたいです。こう書くと普通そうだろう と思うのですが、 可能な限り というのがたぶん違う。読まないで済むために、本当にいろいろ 考える習慣がある模様。コードを想像するのもその一つか。

ここで(第6回時)はっきり認識したことがある。

私は、「うーん」と考える時間は、 条件=解法の組み合わせで覚えておいた知識(= パターン)を駆使する訓練にすぎない とは思っていたが、有野さんがいっていることは、"同じ知識しか駆使しないので あれば、レベルが上がったときにやった方が効率的だ。"ということに思えてきた。

なぜ少ない知識を、駆使しようとするのか？... ここらへんがやっぱり本質的な 差かも知れない。

で、上のコード読みの例 だと、私は覚えなければならない知識を減らそうと工夫 しているわけだ。だから、有野さんの読み方と本質的な差があるに違いない。 そして、私は理解数学派 ってことになるのか。

書くことについては、どうか。表現することは、知識の具体化でもある。 具体化されたものは、あいまいさがない(or すくない) 状態であるはず。 すくなくとも暗記しやすい状態になっているのは間違いない。 表現することに苦労する --- これは、暗記数学派とは遠い位置にいるという証明 かもしれない。

もちろん、すべてのことについて表現することに苦労するわけではないし、 すべての問題について、少ない知識を駆使しようとはしていない。 だから、基本的にトレードオフの問題だと思うけれども...そのバランスは 新たな認識のもとに、見直してみる必要性がありそうだ。

ここで(第7回)、各地の反応が... という話が、まあ10回まで予告されたら 話の腰を折るわけにもいかないから、静聴するしかありますまい。
.. そうすると まとめる必要が...

とりあえずここへの反応は全部終わってからの予定です。
一応当初予定していた流れ、というのがあるので(^^;--有野

ようやく、終りました。どうもごくろうさまでした。

ふうむ、読み終って 実は一番知りたいことが、第9回、第10回にかかれていたり します。暗記項目の抽出には相当のコストがかかるわけですね。で、それを あえてやるには、それが必要であるという信念/覚悟が必要 --- このあたりのことまで違うように感じられるのか！なんて思いながら読んでいた もので....

• 抽出作業は、たくさんやると楽にはなると思います。 また、最初から抽出されてる参考書を選ぶ、というのも重要かと。--有野

さて、私はまあ発端になった人間であり、そもそも興味をもって読んだわけだから、 書いてあることはよくわかったつもりだが、他の人はどうだったんだろうか？

• 長くて難しくて読んでもさっぱりわかんねー

的反応がありそうなのは、よくわかるような気がする。 だいたい文章を読んで、読み手の体験にMapping できないと 読み手は 簡単には理解できない。 で、多数派の意見 を知らないと 落しどころというか説明のポイントが、 微妙にずれがちというのは、ありがちのような気がする。同じことを何回か 説明すれば、回を増す毎に 説得力が増える.. そういうものじゃないかと いう気がしてます。

私自身は、自明でない なにかを説明しなければならなかったことは、 経験として それほどないんですが、一度極端に複雑なことを説明しようと 試みて、その結果、読み手の体験にMapping できるはずもない 話 ... というのはそもそも説明不可能 ぐらいに思うようになりました。

• ちょっと説明しておくと、 仕事関係ですが、ある自明でないことを説明したんだけども、 自明でない ことを説明につかっていて、 さらにそのことを説明しようとすると さらに自明でない ことが含まれている。で、説明していくと文章が 軽く 1000 行を越えたことがありました。
  まあ、そんなものでも、つきあってくれた人がいたから はやばやとあきらめず書くことになったわけでもあるんですが...
  もちろん、理解させようと いろいろ考えて書いたわけですが... でも、長いプログラムを見せて、これがちゃんとうごくことを 検証して信じろといっているようなもので、それは 一般には無理な話だと思える。
  あと、捕捉しておくと、自明でないことというのは、全部自分の中では自明だったり したわけです。あと 読み手にとって、なんとなく分かるような 内容なんだけども、 それと対立する論をならべてみると、結局どっちが正しいのか判定できない。 で、最も重要なのはどっちが正しいかということで、そういう意味では何も理解させ 得られない...みたいな内容。

で、なにがいいたかったかというと、 読み手がなにを経験してなにを経験していないか わからない状態で、 多数派に理解してもらうのは、たぶん無理なんじゃないか... だから、推敲したから よくわかる ようになるわけではないかも知れない。
というわけで、悲観するにはあたらないじゃないかと。 ... 同じことを2度3度説明したとしたら、 たぶん より多くの人がわかるようになるんじゃないかと...。

• まあ悲観してる、という感じでは無いんですが。
  ただ書き終わって聞いた第一声が「わからん」だったのでちょっと悲しい、 というだけです(笑)--有野
• そういえば、明らかでないことの説明って、俺の事馬鹿っていってるだろ というレベルまで踏み込まないと 理解不可能ってのも経験したような...
  で、どこかで誤解が生まれたりして 感情的な反応したり/されたり...
  かなり難しいっす。

内容についての 私の考えというのは、また別途。よおく読んでからでないと、 ..というより、上記の話と関連あるんだけども、どういうとき暗記項目の抽出 というやつをやるべきか そしてどうやって実践していくか というのが 1つの課題で もうひとつは、暗記を楽しく... 。前者は、いままでも ある程度やってみていたけれども 認識が少しかわればやりかたも変わってくる だろうと思っている。後者は..楽しいものとそうでないものがあって、 楽しくないと思えるものはいままでやっていない。楽しいと思えるにはなにが 必要かということを考えだすということだろうと思っている。
これは単に印象であって、考えがまとまるのは もっと時間がかかるだろうし、 結論そのものは、ずっとずっと後に出るんだろう。

とりあえず途中で出ていた質問に関しては、 それなりに答えもあった気もしますが、 答えて無いのとか、 答えてるつもりに私がなってるだけの物等いろいろある気がします。 どうしましょ？--有野

とりあえず、質問に答えてもらったかという観点だと、

• Web日記とか 可能な限り文章を書く という質問には、自分のメモ的な用途と いうのは はっきり指摘があったけども... 知りたいのはその理由だったりします。 基本的に 有野さんの書くものは、他の人と比べて圧倒的に量がある。 そうしている理由というのか... なんとなく わかっているつもりなんですが、私自身は 経験が浅く量を書くのも 難しく感じているわけですし、理解が浅い可能性が高いかも。

• 読み方についても、役に立つんだということは指摘があった。 意識がちがえば、接し方が違うはずというのは理解できたけども、 やっぱり、どう役にたつか というのはイメージできない。実際どうやっているから 役に立つという話までほりさげてもらえると... ただ、本当に説明しようとすると 膨大な説明が必要だけども、私自身は、自分の体験との差でイメージを 得るような 読み方するから、書いてもらった量に対して私が受け取る量がずいぶん少なくなる。 となると、説明してもらうのも申し訳ないような気がするわけですが... 読むとき 何をしているか を 具体的に分かるようにしてもららえれば、 もっと 求めているものを 具体的に 質問できるかも。

• あと、ある共有できていない知識なり理解を 人にどうやって伝えるか、 知らないことを どうやって理解するかということ については、少なくとも 暗記項目の抽出(かそれに類すること)をやる必要があって、楽々こなせるよう な話ではなさそう。という印象があった。でも、上の2点に 関して 臨時日記をみている限り 楽々ではないにしても、 普通の人とは敷居が低いような印象もあって、 その差 は、意識の差であると いわれても 納得できるような気がしない。 やはり、知りたいことは理解できていない ような 気がしている。 これは、上の2つの質問に集約できる話かもしれないけど。

という感じかなぁ。

いやいや、どうも。コメントありがたいです。

長く書く理由

暇だから、とか？(ぉ
いや、別に長く書こう、などとは思って無いのですが。 書くネタによって理由は違う気がしますが、 実は一緒なのかなぁ。

自分の考えている事を一時的に保存する為に書く場合、 考えてる事は割と膨大な上に、 普通は明文化せずに思考しているので、 文章に落とす時には長い文章になるのはしょうがない。

また、物理学科、というのは、基本的に学校でやる事は議論する事です。
議論とは、なんか良くわからない事とかを言葉にして、 質問する、という事でしょうか。
相手の言う事で良くわからない事はやっぱり言葉にして説明する訳です。
普通は扱うのがそこそこ複雑なので、 説明というのは正確で長くなりがちです。
そこらへんと関係しているかもしれません。--有野

私の場合、

• 考えてる事は割と膨大な上に、 普通は明文化せずに思考しているので、 文章に落とす時には長い文章になるので しない。

• なんか良くわからない事とかを言葉にして、質問/説明する ときに、 そこそこ複雑なので、その文章は、正確で長くなりがち...だから、 はしょってみたり、議論することをあきらめる。

なんていうことをやりがちだったりします。で、訓練だと思って 面倒なのを あえてやっていくと...

• あまり他人と共有するのは難しい事とは思わなくなる

のに違いないと思っている。--- というのが、なんとなく わかっているつもりの 内容なのだろう。

ちなみに、有野さんの言葉を全部借りているのは、 やっぱり言葉にして説明することが出来ていないから、 上のことは、自明だったりするのかも知れませんが、私にとっては自明という レベルの認識ではないはず、なぜなら出来ていないから。

こういうことが、自分の体験との差で理解するということで、ずいぶん上の 方で述べた 新しい認識 ということだと考えています。

他人と共有するのは難しい事とは思わなくなる必要を感じているわけで、 面倒がゆえに やりがちなことを 意識してやらないようにするというのが、 言動の差になってくるはず。

ソースの読み方

ソースを何故全部読むか、、、って別に私も全部は読みませんが。
私の場合は、ソースを勉強で読む事が最近は多いので、 全部読む事が多い気がします。 MINIXとかL4とかemacsとかSCMとか。 という事で全部読む事が多い。 動かしたい、とか、こういう機能を付けたい、 という訳では無いので、 普通は勉強したい所は全部読むと思います。 うーん、暗記等との関連は無い気も。

• え？ そうなんですか？ 本当に？ 勉強で読む 、勉強=暗記を意識する という 関係はあるんじゃぁ。
  私の場合、どおかなというと、勉強で読むから全部読む というのは必ずしも 明らかなことではないような... 勉強であっても、 たぶん分かった(つもり) の部分は、読みとばしている。その結果、 訓練の機会を逃したり、理解が浅かったり ってのはありがちかも。
  • うーん、あんまし暗記を意識してはいませんねぇ。
    恐らくプログラムの上達を第一義に考えるなら暗記する方が良いのでしょうけど、 現状では趣味、という事でダラダラと非効率にやってます。--有野

相手の知らない事をどう他人に伝えるか

普通の人とは敷居が低い、というのはどういう意味かちとわからんのですが(typoだとは思うけど、本来の文がなんだったのかがわからない)、

• すいません、たぶん typo でないです。正確に書くというのができていない。
  敷居が低い= (有野さんは)ある共有できていない知識なり理解を 人にどうやって伝えるか、 知らないことを どうやって理解するかということをやろうとする のに抵抗を 感じない ということが言いたかった。さらに、"楽々でないにしても" を 付けるのが適切かも知れない。typo でないというのは、わざわざ削ったりした から...どうも重複するモノってのを削るようなクセがあって、推敲した結果 パズルのような文章(=文脈を考慮すると一意になるに違いないと思える程度に短い) になる傾向があるらしいです。説明するにも こういう傾向があるのは自覚している んですが、なかなかうまくできない。(主語がないとか文としておかしいとか 気にならないどころか、どうも日本語はまどろっこしいと思うことすら。 キーワードの羅列で説明したいとか。文脈がある場合はそのキーワードすら 同じでないことも気にならないぐらい。しかもそういうことを実際に やっている..らしい。)
  • typoではなかったのですか。 「普通の人と比べて(有野は説明する事の)敷居が低い」か、 「普通の人は(suzさんより)敷居が低い」かのどちらかだと思ったのですが。
    上の説明を見る限り前者の様ですね。--有野

基本的に、 ある一定量の文を書いても良い状況であれば、 あまり他人と共有するのは難しい事、 とは思ってません。

共有しづらい事はありますが、 大抵の事は相手に読む気があれば、 理解させる文は作れる、とは思います。
分量が多くなるし、 相手に読む気があれば、という前提は普通はなりたたないのでやりませんが。--有野

上で、だいたい自分の体験との対比というのは説明できたと思うけどコメント すれば、

• 相手に読む気があれば... 理解させる文を作るのはやぶさかではない
  • そうですね。むしろ読む気がある人がいる可能性があれば、とか、 読む気があるかもしれなければ、程度でも十分説明する気にはなります(量にもよりますが)--有野

たぶん、私は実践するのに相当苦労しそう。まあこれが現状認識で、 それをするために、上のことができている人の 感覚というかそういうものを 知りたかった わけです。
いやいや、本当に ありがたいです。

• いやいや、私はそんな大した者じゃない気もしますが(^^;
  来春から新人研修とか受けるしたっぱですし。--有野

お、速読英単語入門編 というのがアルですか。... ということで それの CD BOOK を買ってみた。

ゆっくり読んでくれる。Paced Reading というやつと 普通の Normal Speed の 2種類 が録音されていて、Paced Reading は聞き取れるけど Normal Speed は、なかなかうまく聞けない。

私のレベルにちょうど良いではないか... ってことは高校受験レベル？ ... まあいいけど。

で、次に 速読英単語の必修編 がひかえていて、 その先は 横山ロジカルリーディング講義の実況中継 .. さらに アルクの速読速聴大特訓 ... 先は長いなぁ。

有野さんから、英語の勉強方法についてのコメントが ...

コメント TOEICの勉強方法

私はこれが良いと思うなんていうコメントはできるレベルにないが... どういう風にやるつもりか ぐらいは 書けるはず。

後でまとめてみたい。