『「計画力」を強くする』 加藤昭吉 著
ところどころで顔を出す日本人論的なものに、なんというか安っぽさを感じて信頼度も少し下がってしまうのだけど、内容自体は「なるほど、その通りだ」と思うようなことが書かれている。あまり目新しく感じることは書かれていなかったけど、普段漠然と感じている事をこうして明確に意識することは大事なことだろう。
で、「なるほど」と思ったからその通り実行できるかというと、それはまた別問題だ。うーん、なぜ別問題になってしまうんだろう。この本に書かれていることを実践しようと言う意識が少ないのかな。
実際に自分がやっていることが自分で把握できてないのかもしれない。だから、こういう本を読んでも実際に自分の行動の何を修正すべきかが見えないのかもしれない。
時間制限のある試験で、思わぬ力を発揮することがあるように、時間的制約のあるほうが、脳はより活発になれるようです。
そうなんだよな。だから(?)忙しい時に「後でやろう」と思ったことは時間ができてもやらないことが多い。誰かにものを頼むときは忙しい人に頼むのが良いとマーク・トウェインだったか誰だったかが言ったらしいけど、そういうものなんだよな。何かができない時に何らかの制約のせいにしがちだけど、自由でも実はできなかったりする。
感性とか直感とか、あるいはフィーリングとよんでもよいですが、それらが論理的に推測されたものに劣るとは限りません。直感もまた認識の有力な手段です。直感は論理的思考では見出せないものを見出し、認識できないものを認識することができます。
そうなんだよ。勘は重要だよな。
目先の問題解決にウエイトをかけすぎるのが、私たち日本人がもっとも陥りやすい評価の落とし穴でしょう。目先の問題解決の積み重ねは、短期的によくても長期的に見るとまずいことがよくあります。
そうなんだよな。俺はこの落とし穴に落ちてばっかりだ。分かってるんだけど自ら落ちに行ってしまう。
経営学で知られているピーター・F・ドラッカーは著書の『未来への決断』(上田惇生/佐々木実智男/林正/田代正美訳)の中で「大統領になるための六つのルール」を挙げています。その一つは「大統領は細かいマネジメントにタッチしてはならない」というもので、「やらなくてもいいことは、実は大統領がやってはならないこと」なのだそうです。
この本で唯一、今まで考えたこともなくてなるほどと思ったのはこの引用部分だ。やらなくていいところまで気を配れればもっと良いのかと思っていたけどそうじゃないんだな。
あー、でも考えてみれば似たようなことは感じてるか。管理職の人に対して、そんな実務やらなくていいからもっと管理してよ、といつも思っている。そういう事か?
「集合とはなにか」 竹内外史 著
後半はほとんど理解できていないのだけど、当たり前のように思っている事の根本を突き詰めていくと当たり前じゃない世界が現れる感じが楽しめて良かった。
一般の文章を次の形で考えてみます。
主語xが性質Pをみたしている。
私達の今おこなっている述語の主語化は次の形で考えられるといってよいでしょう。
"性質Pをみたすもののなかにxが入っている"
これを私達は、
"性質Pをみたすものの集合のなかにxが入っている"
というふうに表現します。
すなわちここでやっていることは、性質というものを何かの属性としてではなく、思考の対象として、主語としてとりあげているのです。実はこれが集合の本質に外ならないのです。
俺にとっては新鮮な考え方で面白いのだけど、なんかレトリックにだまされてる感じがしないでもない。そんなことないか。
例えば、偶数を集めて「偶数の集合」を作って、「この集合が偶数です」と言われても、なんかすっきりしない。集合を作る段階ですでに偶数の性質を知っているから「偶数の集合」が作れたわけだ。うまく表現できないけど、鳥と卵のどっちが先かみたいな話をされているような気分だ。
したがって、有限集合Aの場合に、Aが{1,2,……,n}と一対一の対応があるときAの濃度をnと定義しますと、このnは一対一の対応のさせ方にはよらずAだけによって定まって、Aの元の個数と一致します。
カントールが証明したいろいろのことのなかで、上の定理"AとP(A)とは違う濃度をもっている"はセンセーショナルな出来事だったといってよいでしょう。それまで、"0,1,2,……それに無限"と"無限"は区別のない唯一の無限でした。それが、無限にも濃度とよばれる個数があること、しかもいろいろ異なった濃度(大きさ)の無限があることを上の定理は示したのです。
俺の理解がどこまで正しいかは自信がないけど、整数の数も偶数の数も10の倍数の数も、全部同じ無限だ。でも、偶数は整数の半分しかないし、10の倍数は整数の10分の1しかない。その差を濃度という言葉で表すのは面白いししっくりくる。
「ふつうのHaskellプログラミング」 青木峰郎 著
関数自体を扱うソフトを作りたかったのと、最近名前をよく聞くなあということで、ちょっと参考に読んでみた。最初はネットで少し調べたのだけど、なんだか数学の話が出てきて良く分からなかったので、とりあえず理屈は置いておいて言語を調べてみる。
特徴はなんとなく分かった気になったのだけど、その利点はいまいちぴんとこない。もっとも後半はほとんど理解できてないのだけど。
リストの構造が値とそれ以降のリストの組でできているとか、引数が2つ以上あるように見える関数も実は1つの引数と関数を返す関数からできているという再帰的な構造はちょっと興味をひかれる。
これ以上Haskellについて調べていくかどうかは分からないけど、ラムダ計算については理解したいなあ。
ラムダ計算 - Wikipedia
「Effective C++ 改訂第2版」 スコット・メイヤーズ 著
前に読んだ時よりだいぶ理解できたのだとは思う。でも、前にどの程度「理解できなかった」のかをすでに忘れていて、理解できたという実感は今回もあまりない。とは言え、いろいろ発見があって得るものはあった。
印象に残ったところを少し。本題とは少しずれたところだけど。
クラスAを継承したクラスBがある。引数の型がAの関数にBのオブジェクトを値渡しで入れると、Aのオブジェクトが作られるので、Aとして振舞う。リファレンスで渡すと、オブジェクトはあくまでもBの型なのでオーバーライドしたメンバ関数はBのものが使われる。
こういう振る舞いがやっとイメージできるようになってきた。
std::numeric_limits
これでintの最小値が取得できる。知らなかった。
俺が今まで見た限りでは、「標準ライブラリ」の説明というと「標準テンプレートライブラリ(STL)」の説明が主だったのだけど、STLではなくて「標準ライブラリ」についてももう少し知りたいなあ。
面白かったのは第6章「継承とオブジェクト指向」だ
だから私は、C++のさまざまな機能が実際にはどういう意味を持っているのか、ある特定の機能を使ったらあなたは実際には何を言ったことになるのかを重点的に説明することにしたい。たとえば、publicな継承の意味は「その一種である」であり、それ以外の意味を持たせようとしたら面倒なことになる。同じように、仮想関数には「インターフェースを継承せよ」という意味があり、一方、非仮想関数には「インターフェースと実装の両方を継承せよ」という意味がある。これらの意味を区別できなかったために、数多くのC++プログラマが人知れず苦しんできたのである。
実装時に便宜的にいろいろ変更していると収拾つかなくなることだけは身に沁みて実感している。
スタックも猫もさまざまな型を扱うという点は共通しているが、あなたが自ら問うべき質問は「型Tは、そのクラスのふるまいに変化をもたらすか?」である。もし、Tの違いによってふるまいが変化しないのであれば、テンプレートを使える。Tの違いによってふるまいが変化するのであれば、仮想関数が必要であり、したがって継承を使うことになる。
当たり前といえば当たり前でほとんど無意識に判断しているような事だ。だけど、無意識のうちに行っていた判断を意識できるようにすることは先に進む上で大事なことだ。無意識の判断のちょっとしたずれが積み重なっていく。
こうしてあなたは多重継承の誘惑に直面することになる。表面的には多重継承のほうが簡単そうに見えるのだ。
(中略)
プログラマは、既存の階層構造を大勢のクライアントが使っていることを知っている。ライブラリの変更が大きければ大きいほど、クライアントの混乱も大きくなる。プログラマは、そのような混乱は最小限に留めようと決心する。選択肢の数々を吟味したプログラマは、次のことに気がつくだろう。もしGrasshopperからCricketへ向かう単一のprivate継承リンクを追加すれば、この階層構造には他の変更は必要なくなる。この考えにプログラマは満足の笑みを浮かべるだろう。ほんの少しの複雑さを加えただけで、機能を大幅に増加できる見込みが付いたのだ。
そのメンテナンスプログラマが、もしあなただったらどうだろうか。誘惑に負けてはいけない。
絶対誘惑に負ける。一人で開発してるのなら修正できるかもしれないけど、こういうふうに他人が、しかも大勢が絡んでくる状況では絶対負ける。さらに締め切りまであったりしたらもう誘惑に負けざる得ないだろう。
こういう状況をソフトランディングさせるには、プログラミング技術や設計技術とはまた別の技術が必要だ。
携帯経由でPCのネット接続
ずっとやろうとしていてやってなかった携帯からのネット接続をやっと試してみた。
まずauの場合、PacketOneとPacketWinがある。
で、auのPacketWinの紹介ページにはデータカードで通信すると書いてあるので、てっきり普通の携帯ではPacketWinが使えないのかと勘違いした。
http://www.au.kddi.com/mobile/packetwin/index.html
で、始めはPacketOneのリンクをたどって行った先にあるドライバを入れていろいろ試してみたんだけど、結局こいつは成功しなかった。
で、よく分からないまま今度はPacketWinのリンクをたどってドライバも入れ直して設定も変えてみたら、やっと接続できるようになった。特に何も申し込んでないけど使えるようだ。
まだ良く分かってないけど、俺の環境だとPacketWinしか使えないのか? まあ、そっちの方が早いのでそれで良かったんだけど。
料金体系もまだ良く分からない。
PacketWinサービスとPacketWinシングルサービスとがあるんだけど、シングルサービスは定額払えば1パケットあたりの料金が安くなるということか? でもそうしたらシングルサービスの中の一番安いコースはPacketWinサービスと同じパケット料だし、どこで得になるんだ?
とりあえずシングルサービスの存在は一旦忘れよう。
PacketWinサービスだと、1パケット0.1円。税込み0.105円。細か!
パケット通信は無料通話に含まれるけど、パケット通信割引サービスに入っていると無料通信の対象にはならないとの事。また、パケット通信料は、「パケット通信料定額サービス」や「パケット通信料割引サービス」の上限額の対象とはならない。なるほど。なんのことだかさっぱり分からない。
俺の明細を見ると無料通話料と無料通信料のどちらもあるみたいなんだけど、無料通話料に含めてくれるのか?
今あらためて明細を見てみるとEZ WINのオプション料金が取られてる。これを払ってるから通信ができるのか? なんか見てるともっと月々もっと安くできそうな気がしてきた。この際だからもうちょっと料金について調べてみようかな。
まあ、それはちょっと置いておいて、1パケット0.105円。1パケットは128バイト。これだとどの使うといくらになるかが良く分からないな。1Mで860円。
yahooのトップページを丸ごと保存してみると、その容量は117,508バイトだった。ということは単純計算で918パケット。96円。1ページ100円くらいで考えればいいのかな? 実際にはオーバーヘッドがどのくらいになるか分からないけど。
ああ、そうだ。通信の状態を表示させてみよう。受信と送信があるけど、どっちもカウントされるのか? とりあえず受信だけで考えてみよう。PC起動から今までの受信量29,028,543バイト。ということは226785パケット。23812円! あれほんと? 高けっ! なんか特別に大きいページ見たかな? ああ、そういえば画像がたくさんあるページは見たな。あれのせいか?
速度は2.4Mbps対応地域だったら2.4Mで、それ以外だと144kbpsとの事。そうなのか。昔はたしか携帯は1kだったか10kだったかそのくらいでPHSが64kだからPHSの方が早いみたいな話だったけど、そんなのはとっくに昔話になっていたらしい。
通信速度計測サイトで試してみると、ばらつきはあるけど0.7とか0.8M、よければ1Mbpsでるようだ。おれがいるところは2.4Mbps対応地域のようだ。
通信中に携帯に電話してみる。通信よりも着信を優先するようだ。メールを出してみる。ちゃんと届いた。ただし、その間PCの通信は切断されてはいないけど通信できないみたいだ。
だいぶ感じがつかめてきたけど、料金だよな。料金体系が良く分からない。
「パケット通信料の目安」というページの説明では1パケット0.2円とある。さっきの倍だ。
http://www.au.kddi.com/ryokin_waribiki/packet_waribiki/ryokin_meyasu.html
http://www.au.kddi.com/mobile/packetwin/ryokin/packetwin_service.html
「パケット割引サービス」紹介のページにあるのは「ダブル定額」「ダブル定額ライト」の二つだ(俺が使ってる携帯はCDMA 1xWINというやつらしいので)。
http://www.au.kddi.com/ryokin_waribiki/packet_waribiki/index.html
だけど、「PacketWin割引サービス」の紹介ページにあるのは「パケット割WINスーバー/WINミドル」だ(シングルは良く分からないので無視)。
http://www.au.kddi.com/mobile/packetwin/ryokin/waribiki.html
PCでの通信だと別料金なのか?
「パケット通信ご利用にあたってのご注意」のページを見るとPCの通信も特別扱いじゃないみたい? 上限が適用されないだけか?
http://www.au.kddi.com/ezweb/service/packet/index.html
携帯での通信はたぶん数ヶ月に1度くらいだけど、使うときにはかなりの金額になりそうだ。でも大体使う時期は決まってるし、プランの変更は翌月から適用されるようなので、こまめにプランを変えていこうかな。そうしないと大変な事になるかもしれない。
コンテナの初期化
最初からコンテナに入れたい初期値となるデータがある場合はどうやるのが効率がいいんだろう。コンストラクタの定義を見ると、値を指定した場合すべての要素が同じその値で初期化されてしまうようだ。別のコンテナからコピーしてくる方法はあるようだけど、それだとコピー元のコンテナをまず初期化しなければいけないので結局問題は解決されない。配列のように初期化で値が書けるといいんだけど。
「STL標準講座」という本を見てみると、配列をリストにコピーする例が書いてある。これだ。
しかし、copy()の第2引数はend()の要素、つまりコンテナの最後の要素の次を入れるようになっている。このコードでも10個の要素を持った配列numsを用意し、copyの第2引数には&nums[9]を入れている。そしてその結果はnums[8]までがコピーされている。最後の要素はコピーされないのか。まあ、ひとつ余分な最後を表す要素を入れておけばいいので、かまわないと言えばかまわないのでけど、なんとなくすっきりしないかな……
と思って今度は「C++プライマー」という本を見てみると、ちゃんと初期化について書かれている。さすが厚いだけあるぜ。
ポインタはイテレータであるから、組み込み型配列を指す一対のポインタでコンテナを初期化できても驚くには当たらない。
char *words[] = {"stately", "plump", "buck", "mulligan"};
// wordsの要素数を計算する
size_t words_size = sizeof(words)/sizeof(char *);
// 配列全体を使ってwords2を初期化する
listwords2(words, words + words_size);
ここで、sizeof(5.8節、p.193)を使って配列の大きさを計算している。配列の先頭を指すポインタと、出外れポインタをアーギュメントとして渡している。
「驚くに当たらない」という微妙に場違いな感じのする語感が好きだ。
それは置いておいて、出外れポインタって何? イテレータのend()が指すところと同じような、最後の要素の次を指すポインタだろうと想像はつくけど、一般的な言葉なのかな? そして配列でもそれはありなのか?
この本の「配列とポインタ」の章にはこうある。
ポインタ算術が合法なのは、元のポインタと新しく求めたポインタが同じ配列の中の要素を指しているか、出外れポインタであるときに限る。
配列あるいは一般にオブジェクトの直後のアドレスを求めることは合法である。そういうアドレスを持つポインタを参照剥がしすることは違法である。また、直後よりさらに先のアドレス、または、配列の先頭より手前のアドレスを求めるのも違法である。
ああ、そういえば微かな記憶が。Cの知識だな。今手元にはC++の本しかないのだけど、これらを探してもこの事は書いてなかった(もちろん探し方が悪いのかもしれない)。
そうか。イテレータのend()みたいなのはポインタ計算でもあったのか。そういえばあったよなあ。すっかり記憶から消えていたけど。
ところでさっきの例題に出てきた文字列、"stately", "plump", "buck", "mulligan"ってなんだろうと思って調べてたら、ジェイムズ・ジョイスの「ユリシーズ」の冒頭だった。なぜここに? ずいぶん高尚だな。
"Stately, plump Buck Mulligan came from the stairhead, bearing a bowl of lather on which a mirror and a razor lay crossed."
is-a関係、has-a関係
「is-a関係、has-a関係を混同するな」という話はよく聞くのだけど、今までは「そんなの全然違うんだから間違えねぇよ」と思っていた。思い上がりだった。
classA <---(継承)--- classB
classC <>---(包含)--- classD
こんな関係があったとして、簡単にするためにすべてのメソッドとメンバがpublicだとすると、classBのインスタンスはclassAのメンバやメソッドを使える。classCはclassDのメソッドとメンバがすべて使える。つまり、意味を考えずに実行することだけ考えるなら、is-a関係とhas-a関係は入れ替え可能だ。