2008年9月30日火曜日

9月30日~列・行・対角線~

 16ビット×16ビットの記憶領域を二次元配列とみなしてさらにすべてが「1」の行・列・対角線の数を特定のレジスタに集計するというアルゴリズムに取り組む…。それほど長くないプログラムで、どのレジスタがどういう役割を担っているのかは注釈を読めば書いてある…。だがわからない…。ということだが、とりあえずGR2ならGR2のトレースだけでもしてみるか…と試すが失敗。次に、問題文の中の例を参考にトレースを開始してみることにする。こういうときA5判は不便だ。やはりトレースするには面積が足らない…。

2008年9月29日月曜日

9月29日~水平パリティ(2)~

 電車の中でCASLと格闘している最中に「全部が全部トレースしなくてもいいんじゃないか」とひらめいて、レジスタGR6がたとえば最初と最後にしか出てこないことをチェック。そうするとGR6の役割は「ラストの語かどうかだけを判断するためのレジスタ」ということが判明、さらに注釈を読んでいくとGR4が水平パリティを格納するレジスタ、GR2がカウントアップして調査する対象のデータを格納するレジスタ…と役割が見えてくる。そうなるとあとはGR2のみを集中してトレースしていけばいいので、ガムシャラに全部トレースしてしまうと時間がかかるわりには正解にたどりつけない可能性に気づく。パリティビットは1か0しかないので、それも頭に入れておくと、かなりすっきり全体像が…。でもそれも設問1のみで設問2になると「なぜ」「どうして」の繰り返し構造だ…。

2008年9月28日日曜日

9月28日~水平パリティ~

 水平パリティのアルゴリズムの問題をじっと考える。通常過去問題を検討するさいには5分以上考えてわからなかった場合にはむしろ解答をみちゃったほうが理解が促進されるようなイメージがある。ただアルゴリズムやプログラム言語の場合には5分では足りなくてむしろ30分以上は考えてしかも自分なりの仮説をもっていないと解説そのものも理解できないケースが…。この問題もレジスタをGR1からGR7まで全部使って、しかもGR2にアドレスを格納、GR7に主記憶のアドレスからの語数を格納するという仕組みになっている。なぜゆえに「2」と「7」という離れたレジスタなのかはわからないが(おそらく意味はあるのかもしれないが)電車の中でトレースするにはかなり苦労…。

9月27日~ウェブモールのデータベース~

 現在、ウェブモールのデータベース問題と格闘中。これが案外面白く、たとえば「楽天」などでも一度購入した商品があれば直近の購入商品と同じ商品カテゴリの商品を表示したり、あるいは他の顧客がその商品と同時に購入している商品をウェブに掲載したりする。当然、これはネットワークに乗せる前になんらかのデータベースを利用して載せているわけだが、その仕組みを理解しようという趣旨だ。重複がないようにしてさらに商品コードの統廃合なども配慮して…と正規化された各種のデータベースをいかに活用していくのか、という視点でみていくと本当に面白い。だが問題は正解がなかなか出てこないことなのだが…。

2008年9月27日土曜日

9月26日~数値データを文字データに置き換える擬似言語~

 データにはそれぞれ「型」があってスタックを利用して数字データを文字列データに置換する…。前はわからなかったアルゴリズムが手に取るようにわかる。わかるとあとは図を書いて丁寧にデータをトレースするだけだ。例として挙げられているデータを代入してそれをトレースすれば解ける問題なのになぜゆえに昔は解けなかったのか…。努力の方向性と量が足らなかったからだろう。


 エネルギーは不思議だ。やっぱりエネルギーを持つ人とコミュニケーションをとるとエネルギーが増幅して返ってくる。人が人と離れずに何らかの形でコミュニティを作っていく理由…一人では弱すぎる、一人ではエネルギーを増幅できない…辛いことが多い世の中できっと少しでも楽しく生きていく理由を探すために人はコミュニティを作るのだと思う…。

2008年9月25日木曜日

9月25日~午後のデータベース~

 宅配便運送のデータベースの問題を解くが、常識的にゆっくり考えていくとかなり易しい問題だ。奇問難問というよりもどれだけ効率的なデータベースの活用ができるかを見ている問題でけっして「ひねくりまわしてる」感じではない。もっとも問題1~3はすべて10点配点なので、問題4の擬似言語と問題5で点数を落とすとかなり辛い結果にはなるのだが…。

2008年9月24日水曜日

9月24日~浮動小数点~

 慣れてくるとそれほど難しくないのが浮動小数点や基数変換。基数変換は現在ではむしろ得意なジャンルになっているが、浮動小数点の計算はやや桁数が多く(指数部が8ビットあるということは256乗まで指数計算がありうるということだし)、仮数部の取り方もケースによっては「0・1」だったり「1・1」だったりと癖のある出題になるとやや難しく感じる自分。平成19年秋の午後問題については一応全部正解だったが、なぜか計算のプロセスが異なっているのでその部分だけでも原因は解明しておかないとまずい。たまたま正解があっただけかもしれず、ちょっと「解説」と自分の答えが合わない理由だけは解明しておきたい。


 朝はちょっと起きるの辛し…。でも頑張ろう…。

2008年9月23日火曜日

9月23日~再配置可能~

 電車の中でアドレス参照方式のところを見ているうちに、インデックスレジスタやベースレジスタの値の「内容」を加算して、アドレスを参照する方式のメリットに気づく。主記憶装置のどこであってもベースレジスタの値を変更すれば主記憶内のどこからでもプログラムを開始することができる…そしてこれってリロケータブル、再配置可能なプログラムのことでは…。知識がリンクするとけっこう忘れないものかも…それにしても一見ばらばらの知識が横につながると強いことは強い…。

2008年9月22日月曜日

9月22日~マスクビット~

 16進数の演算の学習。やや不調なときはハードウェアやソフトウェアの簡単な問題を解くだけでもいいかもしれない。アルゴリズムの長文問題を解く…と考えるとモチベーションが下がるのは間違いなく…。不調なときや疲れているときには、午前の問題の復習が一番だ。

2008年9月21日日曜日

9月21日~EDI標準規約~

 EDIについてはけっこう自分ではわかっているつもりだったが,日本の実務では標準フォーマットが一応定められているものの流通関係の会社ではそのフォーマット以外の形式が用いられているなど,知らないことが多いのに気がつく。いずれ統一フォーマットで全部統一すれば…と考えるのはおそらく素人考えでそれぞれの業種できっとフォーマットを変更できない事情も当然あるのだろう。EDI自体は2台以上のパソコンと2つ以上の企業の「やりとり」と単純に考えしまっても取引をやりとりしてしまえばEDIと呼ぶことはできそうだ。だが考えて見るとMSDOSの時代からずっと変わらないフォーマットでEDIを「実務で活用している2つ以上の企業」というのはかなりあるはずで,それもフォーマットがなかなか統一できない理由の一つかもしれない。半分知っているようで実は知らないことのほうが山ほどあるということに気づく。奥が本当にふかいなあ…。

9月20日~超整理法~

 「超整理法」のファンとなり,まだまだフォーラムには参加できていないもののユーザーの意見や工夫は積極的に取り込むようにしている。いずれも知的生産を独自の工夫で行おうとしている方々ばかりなので,野口悠紀夫教授とはまた違う視点での取り組み方やカスタマイズがとても面白い。おそらく野口教授の趣旨としては,ユーザーの意見を取り入れるということなので一種のオープンソースを提供した感じなのかもしれない。「超整理手帳はいずれ手帳ではなくなるかもしれない」という予測を述べられているが,これまでの既成の手帳とはまったくコンセプトが異なるという点とユーザーがウェブなどを通じてコミュニケーションをしていくというあたりがまたこれまでにないコンセプトだ。ウェブとの親和性をリフィルのダウンロードやA4サイズなどで実現するほか,ユーザーがウェブで交流するというのは野口教授も当初は予想されていなかったのではなかろうか。そして今日,書店でみかけてすぐ購入した「図解超手帳法」(野口悠紀夫著 講談社)はあっという間に読み終わり,すぐさま色々なアイデアを得る。この本にもユーザーが登場して独自の工夫が活字になっているのだが,いずれもオリジナリティが高くしかもそのオリジナリティを読者が自由にカスタマイズして取りこむことができるのが嬉しい。パソコンとの親和性以外に既存のロディア・ファンや無印良品ファン,アシュフォード・ファン,トラベラーズ・ノート・ファンなどとの親和性も高いのが人気を呼ぶ理由だろう。「ノグラボ」からはさらに新しい商品も開発されるみたいなので,今月は超整理法ファンにはたまらない月になりそうだ。

2008年9月20日土曜日

9月19日~平成19年秋午前~

 平成19年午前の問題を10問ほど解く。前半と比較すると後半の問題がかなり易しいような印象を受けるが…。ただ前半はやはり相当に練られた問題であることは間違いない。結果がでなければプロセスを変えて見る。まだまだいろいろ工夫の余地はたくさんありそうだ。

2008年9月18日木曜日

9月18日~4つの山超え~

 区切りがいいというべきか,今日の業務時間中で4つの「山」超える。もっとも明日にはさっそく「色」をいろいろ校正するという作業が残っているのだが,内容を検討するよりもずっと気分的には楽な作業ではある。続く2つの「谷」越えがまた問題で,会社にずっとつめていればいいアイデアがわくというものでもなく,かといって何もしないでおくというわけにもいかない「微妙さ」が難しい…。努力で克服できる部分は時間と力をさけばいいが,最終的にオリジナリティが要求される部分では必ずしも残業がいい結果をうむとは限らない…。

2008年9月17日水曜日

9月17日~4つの山,2つの谷~

 今日もまた残業で早朝当番の傍らも書類に取り組み,会社の行き帰りを利用して平成19年秋本試験問題を解く。考えて解いて見ると非常に理解しやすい上に理解も「立体的に」なるので今の調子で勉強できれば少しは情報処理に対する理解も深まることだろう。
 業務では4つの「山」のうち3つめが一段落。もう一つの「山」は来週に持ち越しになるが,さらにその後,2つの「谷」を飛び越えて,さらにさらに巨大な公的業務に入ることになるが…。連続的に重要かつ赤字を出すわけにはいかない仕事が続く。まあそういう年齢なんだろうなあ,きっと。

2008年9月16日火曜日

9月16日~工夫~

 何かと慌しいのだがとにかく工夫と改善で…。平成20年春期の午前の過去問題を解くが,やはり過去問題を解いていろいろ研究するのはかなり役立つ。もっともちょっと前までは過去問題の出題趣旨すらよく把握できていなかったのだが,そもそも一番大事なのは一番近い時期の過去問題を研究することだった。鉄則に立ち返っていろいろさらに工夫改善…。

2008年9月15日月曜日

9月15日~オーダ~

 喫茶店にて2分探索法の平均オーダを対数変換で導出する処理の学習など。晩御飯はまたもやパスタで…。案外摂取カロリーが多そうで実はそれほど量がないパスタなのでけっこう身体には逆にいいのかも。シーザーサラダと一緒に食べればビタミンも取れるし。

 2分平均法についてはアルゴリズムから何から何までやったつもりだが,やればやるほどまた知らないことがでてくる。それだけよく使われるアルゴリズムだ,ということなのだろう。確かに辞書で単語を引く作業などは人間自身も2分探索法に近い検索をしているのだから,アルゴリズムとしても造りやすい面があるのかもしれない。

2008年9月14日日曜日

9月14日~おやおや~

 気のせいか会社にいくと人気がない…,おやおや…?皆さんお休みをまさか満喫…?え…という孤独な時間を過ごしつつ,電車と喫茶店にて要素領域と管理領域のアルゴリズムを解く。仕組みがわかると正解を出すのは確かに楽だがその「仕組み」をしっかり理解するのが大変なんだよなあ…。ただCASLの場合,こういうビット操作の場合にはこういう命令をする…という一種の役割分担がはっきりしているような気がする。それぞれの命令の役割をしっかり認識しておくと本番でもおそらく緊張せずに第9問,第13問が解けるようになるのだろう。いまさらながらに「スキル標準」とかをてらしあわせて見ているとけっこうそれ自体も勉強になることが判明…。出題趣旨や講評などもネットで見れるので,得点できなかった人間にとっても「公明正大な試験なので仕方がない」という諦めもつく…。

9月13日~睡眠と眼鏡~

 「活字」を読むのが商売の種のような部分もあり,日がな一日活字を読んでいると目が疲れてくるのを自覚。新しい眼鏡を作ってみるとこれが本当に楽なんだなあ…。旧モデルよりも明らかに軽くてしかも鼻や耳に負担をかけないのでコンタクトレンズよりも楽な部分も発見。確かに脳は大事だけれど,目や背中など脳以外の部分も大事なので…やはり,運動不足を解消するなんらかの方法を考えないとだめかな…。

2008年9月13日土曜日

9月12日~メモリープール~

 メモリープールについていろいろ調べて見るとアセンブラ言語でメモリープールの処理を扱うのはわりと理にかなった出題だということがだんだん理解できてくる。アルゴリズムでは,管理領域と要素領域に区分されているのだが,実際にはジョブ(パソコンがこなす仕事)をメモリープールという論理的な区分に分割して管理すると未使用の領域などがあらかじめ判明するので,ジョブの達成がかなり楽になる。主記憶領域や補助記憶領域の効率的な管理にはかなり役立つ「考え方」なので,特定のビット操作で記憶領域の使用状況を管理する手続きや仕組みは単なるアルゴリズムを超えてパソコンの「あり方」などを考える上で有効だ。

2008年9月11日木曜日

9月11日~返却値~

 いよいよ条件分岐の3番目を迎えるが,要素領域で使用中の要素が解放されるので管理領域のフラグを1から0に戻すというアルゴリズム。理屈はわかるし,注釈を読んでいるとこのレジスタにマスクビットが格納されているのだろう…といった推察まではできるが,それから先が苦戦。トレースも大事だが,CASLの命令はもともと数が少ないのだから,何をどうしようとしているのがもう少し「推理力」が必要かも。

2008年9月10日水曜日

9月10日~初期化と要素の割り当て~

 長いアルゴリズムを読むときには注釈と問題文の手続きがかなりヒントになる。あとは分岐条件をみると解答可能な部分は確かにあるが,それでも最低限はトレースをしておいたほうがいい場面も。「要素の割り当て」のアルゴリズムをさらに極めてオーバーフローなどの復習もあわせて確認していく予定。仕事は今日,大きな「山」のうちの1つがまずは一区切り。

2008年9月9日火曜日

9月9日~メモリーループ~

 管理領域と要素領域の2つに区分された状態で,要素が未使用から使用済みかを判断してその後,さらに処理を追加するアルゴリズム。非常に難しい…。電車の中でトレースしようとしてみたが,解答できたのは一番最初の問題だけ。あとはかなり難しい。前後関係の脈絡から選択肢を選ぶという方法や考え方もあるが,これだけ難しいアルゴリズムになると本当に手ごわい…。

2008年9月8日月曜日

9月8日~2分木,2分探索木,ヒープ~

 木構造のデータ構造の復習。基本情報技術者では2分探索木とヒープ木が一番出題頻度が高いと言われているが確かに2分木だけではどうにも利用のしがいがないのでそれはやむをえないのかも。A5サイズのノートにとにかくまとめて後は気になる検索ルートの復習も必要。

2008年9月7日日曜日

9月7日~掃除~

 掃除ばっかりの日曜日というわけでもなかったのだが,DVD関連の機器を新しく購入したので配置にこまって家具を移動させているうちに次第におおがかりなものとなり,パソコンを中心に机を凹形にしてしまった…。さらにいらなくなったゴミなどをまとめているうちに一日が暮れて…。しかしだいぶ快適な状態になったことは事実なので,明日からまたさらに効率的に勉強できるような…

9月6日~コントラストのアルゴリズム~

 16ビットの1と0が途中から左右対称になっているかどうか調べるアルゴリズム…。はたして実用性がどれだけあるかは横に置くとして,考え方は非常に合理的だと思った。ビット列を他のレジスタにコピーして,片方は論理左シフトであふれが生じたかどうかをオーバーフロービットでチェック,コピーしたもう一つのビット列を右シフトしてこぼれ出たオーバーフロービットをチェック。右シフトの場合には,こぼれでたビットがオーバーフローに収納されるので,1か0かがチェックできる。こうして同時にそれぞれのオーバーフローをチェックして8ビットまで繰り返せばすべてが一致しているかどうかがわかるという仕組み。最大限1回から8回までの繰り返しとなるアルゴリズムだが,非常に面白い。ただし実用性がどれだけあるかはまた別の話でCASLの場合はやはりアセンブラ言語なのでその点はしょうがないか…。一番エンターテイメントとしても楽しめるのはVBなのだが,これは正直,遊びに近い感覚の言語になってしまうし…。

2008年9月5日金曜日

9月5日~ぐったり~

 朝から晩まで長時間の会議。さすがに帰宅途中CASLのコントラストを確認するアルゴリズムを読み解こうとしてぐったり…。

2008年9月4日木曜日

9月4日~お見舞い~

 同僚が病に倒れてそのお見舞いにいく。人生は本当によくわからない。風邪すら引かなかった人が急に倒れてしまう。いや,自分だって数年前に過労で倒れたのだけれど。

 午後のプログラム設計の問題をさらに読み解く。プログラム設計の流れ図は「意味」を読み取ることが重要で変数の代入はやはり問題ではない。またレコードの形式が異なった場合の処理などは,流れ図の中から自分で読み取る事で解答を出すのがポイントのようだ。その意味ではアルゴリズムよりもずっと「思考力」が試される問題になるといえるだろう。モジュールに分解する作業だから,モジュールの意味をしっかりおさえておくことが重要。

2008年9月3日水曜日

データベースの独立性

 応用プログラム(excelやアクセス,そのほか給与管理ソフトなど)によっていちいちデータの形式を変更するのは面倒だ。そこで一元的にデータを管理するためにデータベースシステムが構築される。データの重複を避けるとともに,データの機密保持や標準化などがデータベースの主目的で,こうしたデータベース構築の概念はパソコンだけではなく,メモやノートの管理にももちろん使える。
「どこかにメモしたはずだが,どこに買いたのかわからない」
といったデータの場所が特定できない事態を避けることができるわけだ。今はもうネットワークデータベースの時代だが,このネットワーク,特にgoogleを利用したデータベースの構築はかなり重要なアイテムかもしれない。まだメモやノートは転記することで対応しているが,たとえばパソコンに入力していつでもどこでもデータを更新できるようにしておけば,パソコン内部で検索するよりもずっと便利。対象世界をモデル化するスキーマという作業も,仕事とプライベートに限定してしまえば,それほど複雑なスキーマは必要ない。googleによるデータベースの構築は個人的にも有用なものだろう。あとは必要に応じてプリントアウトすればいいわけだし。実表からそれぞれビューを抽出するのも個人用に限定してしまえば相当に楽な作業となる。なんとか,この勉強を日常生活に活用できる方法はないものか。きっとあるはずだと思うのだが…。

9月3日~ファイルシステム~

 あまりに「疲労蓄積」したのか,今日は会社を休んで療養。土曜日は出勤,夏休みも6日出勤とかなり無茶が続いていたが,無茶をしなければ期日に間に合わないのも事実。といってここで倒れるわけにもいかない…。

 ファイルシステムについて学習する。段階的詳細化というと最初は難しく感じたが,要は「大まかに設計」してあとは「詳しく設計していく」というブレイクダウンの構図を情報処理では「段階的詳細化」というのだと気づく。外部設計(システムをサブシステムに詳細化),内部設計(サブシステムをプログラムに詳細化),プログラム設計(プログラムをモジュールに詳細化),プログラミング(プログラムをモジュールに詳細化)といった具合だ。おそらく世間的にいうプログラミングはプログラムをモジュールに分割する程度のイメージだが,一番最初の要求定義や外部設計の段階は理系というよりもむしろ文系的な発想のほうが重要な気がする。実際にコーディングが必要となるのは,プログラム設計の後半とプログラミングの工程だから,理系的要素はこの部分しかないと考えるのが妥当なのではないか。SEの書籍をみても古典文学や小説の読書を進める本が多いのは,全体像からシステムやサブシステムを抽出するあたりは,文学的な要素すらあるからかもしれない。モジュールに分割する段階でモジュールの「仕様」が問題となる(TS分割とかSNS分割などの工程を経た前後の段階で〉。入力データ構造と出力データ構造の「変換のしかた」(=モジュールの論理構造)をしっかり組み立てた上でプログラム設計ではモジュールに分割していく必要性があるという流れだろう。モジュールの制御領域や影響領域などにも当然配慮する必要があり,よく午前で出題されるモジュール結合度の強弱などはまさしくこのプログラム設計段階でのモジュール分割をいかに適切に行っていくかという意味での出題なのだろう。

 しかしどうも午後の問題で出題される「プログラム設計」は内部設計も含めての出題と考えたほうがよさそうだ。DFDでデータの流れを「見える化」したあと,各機能の入力と出力,使用ファイルの分析をしてプロセスフローを作成する。外部設計で分析した物理データ設計や入出力設計を詳細化していって,受注ファイルや発注ファイルなどファイルの概要をまとめていく段階は内部設計の段階だが午後試験ではこのファイルの概要がデータとして与えられている場面が多い。そしてキー項目を設定して「システム流れ図」を作成するが,午後ではこの「システム流れ図」をいかに読み取っていくべきかという出題もあるように思われる。これが内部設計書だが,内部設計書をもとにしてプログラムの構造化設計(モジュールへの分割)が行われるが,おそらく午後のプログラム開発は内部設計の後半から内部設計書,内部設計書からモジュールの構造化設計の段階というあたりがポイントだろう。モジュール間でどういうデータをやりとりするかというモジュール仕様を流れ図にした問題,それが平成19年春午後試験の問題5ということになる。モジュール仕様の作成の方法にはワーニエ法など種々あるが,一般的には「流れ図」で出題されるようだ。しかしアルゴリズムの流れ図ではなく,これはモジュールの流れ図であるということを認識していないと変数を代入するなどといった違うアプローチで問題を解くような間違いは防止できるはずだ。

2008年9月2日火曜日

9月2日~プログラム設計~

 マスタファイルとトランザクションファイルのつき合わせの問題にさらに取り組む。解答はなんとかでてくるのだが,同じ流れ図でもファイルシステムの流れ図はひょっとするとアルゴリズムの流れ図とは別個に考えるべきではないかと思い始める。確かに手順を説明している図ではあるのだが,ファイルを開いて入力して「その結果どうなったのか」を考えていくと,変数がどうしたこうしたではなく,データをいかにして合理的に扱うべきか…といった発想に結びついて行く。もう少しプログラム設計のこのジャンル,深く考えて行ったほうが良さそうだ。

2008年9月1日月曜日

8月31日,9月1日~データベース~

信じがたいほど長い会議を出たり入ったりで朝の10時から夜の6時まで。その間で本来業務をこなし,さらに帰り道にデータベースの問題を解いていると頭痛が…。マスタファイルとトランザクションファイルをつき合わせて新しいマスタファイルを作るという原理的には非常に簡単な問題で,ある程度推測で選択肢を選んでも正解にはなるのだが,自信をもって正解と断定できないのは,おそらく「ファイルの更新」という概念が具体的に体感できていないためではないかと思われる。一度でもデータベースを更新するという作業をすれば,もう少しデータベースの問題を体感できるのかもしれないが,紙の上で「つじつま」をあわせているような何かそうした手ごたえのない勉強になっているような気がする。原理をつかんで,さらにその周囲の質感みたいなものをつかみ取る…。これが情報処理という分野の難しいところだなあ…。