orange
さんがブースト
そのときは設計を別経路からやりなおす(バックトラックする)か、壁を乗り越えるサブ問題を設定する(再帰的にやる)べきなのであって、結局その「壁にぶつかってその存在を知る」フェーズは設計の本質を知るのに必要ではないのではと
で、メンタルモデルとしては、「設計できるようになるには、自分で考えるクセをつけるのが大切でしょ！？＞＜」って事で、嫌がられるのが前提で、「じゃあそれをするのはどうやってやればいい？＞＜」って問い詰めていく方法って実際に有用だったかもって言いたい＞＜；
その、調査したつもりの制限という壁に突き進んでいても実際にぶつかるまではなかなか気づけないよ！＞＜みたいな事が言いたい・・・＞＜
orange
さんがブースト
orange
さんがブースト
orange
さんがブースト
「ソートせよ」が存在しないというのは、命令の一覧を眺めることで知ることができるわけで、それは設計という作業を通して知るべき知識ではなくて、設計に先立って把握しているべき条件や知っているべき知識から察せられるべき事柄ですよね
最終的には当然そうなるし、脇道を極めていけば目の前の計算機ではその方法では処理できないので新しく考えた計算機を作るんだけどその為には鉱石を採掘・・・みたいな話にもなるかも＞＜
そういう脇道は無限（比喩）にあるし、真に全ての前提条件を記述する事も不可能だし、その部分であっても初学者が理解するのは困難（というか混乱させる）なので、実際にぶつかる場所で「じゃあそれはどうやってやればいいとおもう？＞＜」って聞いて結果的にとめるのも重要かも＞＜（とめなくてもいいけど＞＜）
orange
さんがブースト
その「できるのかを知る」は低位のレイヤーにいくとたとえば「コンピュータアーキテクチャを知る」などになるわけで、それは必要な知識かもしれないけど、やりすぎればもはや設計とは別のレイヤーではと思います
例えばすごく第一歩として言うのであれば、CPUの命令表には「ソートせよ」とは書かれてない＞＜ そういう意味での制限＞＜
それは全ての前提条件ではないかも＞＜ 制限としての前提条件のうちのかなり限られた部分集合かも＞＜；
オレンジが言いたい事はそういうことじゃなく、それができるのかを知るためには、それをさらに分解して考えていく必要があるみたいな事が言いたい・・・＞＜
orange
さんがブースト
たとえば CPU で実行可能なあらゆる命令が列挙されているとして、それはソートアルゴリズムを必然的に記述できるので設計が完了しているとは見做せませんよね
orange
さんがブースト
それはバックトラックと再帰的な問題の分割により達成されるものなので、前提条件と無関係では……？
そもそも「よく考えたら出来ない」というのがどう判定されるかというと、「操作の最小単位まで分割できなかった」という条件によるわけで、結局最小単位がわかっていないと失敗判定もできないような
前提条件を真に全て細かく出せてしまったら、それはそれ自体が設計かも＞＜（それはつまり前提条件により必然的に決まるので＞＜）
ストレスフルなのもわかるけど、設計って自分が思いついたアイディアが、自分にとって未発見の制限にぶつかって取り下げる事も大きく含まれると思うのでなんとも＞＜； 「あ！＞＜； よく考えたら出来ない！＞＜；」って大切かも＞＜ じゃなきゃ設計にならない＞＜
orange
さんがブースト
それは最小単位を組み合わせて大きなものを作ろうとするから混乱するのであって、それはまあわかるんですが。
かといって、大きいものから分割していこうというとき、最小単位を隠すというのは回答者にとってストレスフル(かつ実践的とは限らない)のではないか、というのが考えです
orange
さんがブースト
で、私の言う「完了条件」というのは、「目的の動作を、『片手で一度に一枚までカードを持つ』などなどの前提条件を満たすような操作のみに分割できたこと」という風なものです
オレンジはそのイラッとさせながら教えてるかも＞＜； じゃないと前提の見つけ方自体を学べないかも＞＜
それを教えないと「設計とは全く迷わずに一回でできるもの」みたいな誤った発想にもなりそう＞＜
orange
さんがブースト
ここで「カードを持てるのは片手までです」とか「一度に注視できるカードは一枚までです」とか、そういう前提条件の提示は、ソートアルゴリズムを設計するうえで解答を記述することにはなりませんよね
- ＠orange_in_space
2017年 4月に登録
