What one likes, one will do well 〜好きこそ物の上手なれ〜

寄り道しながらも、最後は昔から好きな物理とプログラミングに戻ってくる。そんな男の思いをつづるブログです。

小学生でも読める算数が楽しくなる本「数の悪魔」を読みました。

はじめに

数の悪魔を読みました。小学生でも読めて、算数や数学の不思議な話が書いてあり、算数や数学を好きになるそうです。

私も楽しく読みましたし、うちの子（小学3年生）も楽しく読んでいます。

扱っている内容

  • 指数。ホップすると言うらしい。
  • 素数。エラトステネスのふるいを扱っていた。
  • 素数の面白い性質。2より大きい偶数は2つの素数の和、5より大きい奇数は3つの素数の和で表すことができる。
  • ルート。大根と言うらしい。ルートを取るときは、大根を抜くと言うらしい。
  • 1から順に足していくときの和。
  • フィボナッチ数。
  • パスカルの三角形。
  • 組合せ。
  • 階乗。びっくりと言うらしい。
  • 級数。
  • 無理数。

おわりに

内容は高校レベルなのに分かりやすく、小学生でも楽しく読める内容です。中学受験する子は知っている内容かなと言う印象です。

とにかく面白いのでお子さんにオススメです。おまけに算数、数学好きになってくれれば言うことなしですね。 

 

数の悪魔―算数・数学が楽しくなる12夜

数の悪魔―算数・数学が楽しくなる12夜

 

 

数学ガール 乱択アルゴリズムを読みました。

読書

はじめに

数学ガールの乱択アルゴリズムを読みました。仕事や趣味でプログラム書くから、他の数学ガールより簡単に読めるかと思いきや、なかなか難しい内容でした。前にアルゴリズムの本を読んで最後まで読みきれなかったことがあるのですが、やはり私にはアルゴリズムが難しいようです。

それでも数学ガールはわかりやすく、順序立てて書かれているので、理解が深まりました。

読んだ感想をまとめます。

リニアサーチ

アルゴリズムと言えばソートというイメージがあったのですが、最初に検索から入っていました。その方が理解しやすいなと感じました。

少しの工夫で実行ステップ数が改善するのが、面白かったです。今まであまり考えたことがなかったのですが、小さな積み重ねが大きな差になるので、これから気をつけないとと思いました。

確率の公理

確率の公理は初めて知りました。高校で習う数学と大学以上の数学での違いは厳密に定義される点だと感じます。

少しの公理に確率の考えが詰まっていると思うと不思議です。

ソート

検索のアルゴリズムは比較的簡単ですが、ソートになると急に難しくなります。前にアルゴリズムの本を読んだときもたくさんのソートアルゴリズムを読んで途中で断念しました。じっくり読むと理解できるのですが、すっとは入ってこないですね。コードを何度も読んだり、実装するのがよいだと思いつつやってないですね。。。

考え方が理解しやすいバブルソートとよく使われているクイックソートが出てきました。

対角行列

私は行列苦手で、特に対角行列がよくわかってなかったのですが、乱択アルゴリズムに対角行列が出てきて理解が深まりました。

対角化することで計算が楽になります。その計算結果を元の行列の計算結果に戻すのも楽なんですね。

P≠NP予想

P問題は多項式時間で解を発見できる問題。

NP問題は多項式時間で正しい解かを判定できる問題。

PならばNPで、その逆は違いそうという雰囲気はわかりますが、証明できてなくて、ミレニアム懸賞問題にもなっています。簡単そうに見えてとても難しい問題なのですね。

乱択アルゴリズム

ランダム性を取り入れて問題を解く方法で、以下のものが紹介されていました。

  • 全体を把握するための乱択アルゴリズム。ランダムサンプリングによって少ない手間で全体を見渡す。
  • 最悪を避けるための乱択アルゴリズム。固定的な選択によって最悪のケースになりうるとき乱択することによって回避する。
  • 多数の証拠を得るための乱択アルゴリズム。おそらくそうであるという解を得る。

失敗確率がいくら以下かという評価を行うことで乱択アルゴリズムの信頼性がきまってくるので、それをしっかり認識していれば、とても実用的な方法だと思いました。

おわりに

乱択アルゴリズムを読んだのをきっかけにアルゴリズムの勉強をもう一度してみようと思いました。

ミレニアム懸賞問題であるP≠NP予想が出てきたことでミレニアム懸賞問題にも興味が出てきました。

本を読むことで興味の幅が広がりますね。でも何でもやりたくなるから、何をやるかの選択が今の課題だと思っています。

 

 

数学ガール/乱択アルゴリズム (数学ガールシリーズ 4)

数学ガール/乱択アルゴリズム (数学ガールシリーズ 4)

 

 

2016年11月のつぶやき

twitter

数学ガール ゲーデルの不完全性定理を読みました。

読書 プログラミング

はじめに

数学ガールシリーズの3「ゲーデルの不完全性定理」を読みました。

この本は難しかったけど、数学についてとてもよく考えさせられる本でした。特に高校数学と大学数学のギャップは大きいと思うのですが、私自身大学数学は何をしたいんだろうと思っていました。その理由がほんの少し分かった気がします。

私はtwitter(@takus69)をしているのですが、今回は「本を読みながらメモを取っていたけど、そのメモをツイートするの面白いかも。」と思い、twitterでその時思ったことをツイートして、その内容をまとめてブログにしてみました。

では数学ガール ゲーデルの不完全性定理を読んで感じたことを書いていきたいと思います。

どうして、数学者は集合を考えるの？

「どうして、数学者は集合を考えるの？」何て考えたことありませんでした。そういうことを考えると大学での数学が分かる気がします。数学で重要なのは計算だけではなく、抽象的に考えること、と言うのは物理などを勉強していて、また前に書いた記事「数学ガール フェルマーの最終定理を読みました。」でも感じました。そういうことを考えさせられました。

音楽では音というコトバ、数学では式というコトバが大切。

なるほどと思いました。プログラムを書く私は、プログラムはコードというコトバが大切だと思いました。

イプシロン・デルタ論法

大学時代に出てくる イプシロン・デルタ論法が出てきました。大学時代になんで必要なんだろうと思ったけど、具体的な問題「一点で連続な関数」を通して、少しその理由がわかりました。

高校では具体的な数値を扱って、大学では抽象的な話ばかり出てきてきます。そのギャップが大学数学の難しさを助長させているのかなと思いました。

数学ガールでは「例示は理解の試金石」という言葉が何度も出てくるけど、具体的な問題があることで、理解が深まると思いました。

カントールの対角線論法

カントールの対角線論法はおもしろいと思いました。ただ数学ガールの問題「実数全体の集合が可算集合でない」ことの証明が理解できていません。何か理解できてない部分があるんだろうなと思います。

ゲーデルの不完全性定理

ゲーデル数を考えて、たくさんの定義にて証明していました。長すぎて途中にあきらめそうになりましたが、最後まで読みました。一つ一つは理解できるのですが、途中で何をやっているかわからなくなる部分もありました。数学者は紙とペンを使いつつ、頭の中でイメージを持って証明しているんだろうなと思いました。

ゲーデルの不完全性定理の証明を読んでいて、プログラムを思い出しました。形式的体系やゲーデル数というのは、機械的に証明する形だと思うので、プログラムでも実装できるのではと思いました。

さいごに

数学ガールを読んでいると「僕」が興奮するところでで一緒に興奮します。それが数学ガールの楽しさだと思います。興奮したのは自然数の「ペア」が整数になる所で、「プラモデルみたいだな」というセリフが共感を覚えました。

数学ガールを読んでいて、線形代数の本を取り出して読んでみました。数学ガールに書いてあることが、ちゃんと書いてありました。昔は気に留めなかった事だったのに、理解が進むと重要なことが分かるようになってきました。

ゲーデルの不完全性定理は、プログラムで実装できそうと思ったので、挑戦してみたいと思っています。実装することで理解が深まると思います。

宿題・課題

数学ガール ゲーデルの不完全性定理を読んでの宿題・課題を時間を見つけてやっていきたいと思います。できたらブログで公開します。

  

数学ガール/ゲーデルの不完全性定理 (数学ガールシリーズ 3)

数学ガール/ゲーデルの不完全性定理 (数学ガールシリーズ 3)

 

 

Qiitaで記事を投稿しました。excel VBAで使えるテストフレームワークを作ってみた。

プログラミング

「ケントベックのテスト駆動開発入門を読みました。 - What one likes, one will do well 〜好きこそ物の上手なれ〜」で書いたように、excel VBAのxUnitを実装しました。

テスト駆動開発入門でテストフレームワークを作るのはとても楽しかったです。実践してみてケントベックが行っていた、「脳外科医が自分の手術する」といった表現がよくわかりました。最初はどこがテストでどこがテストフレームワークなのか混乱していて、その区分けを理解するのに時間がかかりました。

テストファーストを実践して、プログラムがさらに楽しくなりました。次はこのテストフレームワークを使って、VBAのツールを作りたいと思います。

 

Qiitaの記事は以下です。

qiita.com

 

ソースコードは以下のgithubにあります。

github.com

アジャイルソフトウェア開発の奥義を読みました。

プログラミング 読書

はじめに

アジャイル開発に興味があり調べていると、「アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技」と言うのがオススメされていて読んでみました。コードがたくさん書いてあり、具体的で体系的にまとまれていて、とても読み応えがあり、楽しかったです。かなり分厚い本なので、最後は息切れしてしまいましたが。。。読んで心に残ったことをまとめます。

アジャイル開発

最初はアジャイル開発のアジャイルアライアンス宣言や原則、エクストリームプログラミングのプラクティスがまとめられています。顧客が受け入れテストを書くと言うのが目からうろこでした。

実際にリファクタリングをする例やプログラミングエピソードで実際にペアプログラミングでテストファーストを実践している例がコードと共に書かれていて、具体的にイメージできました。かなり勉強になりました。

アジャイル設計

設計における原則が書かれていました。難しい内容も多かったのです。後の章で実際のコードと共に原則を使っており、とても大切なことがわかります。自分の理解を整理する上でも内容をまとめます。

  • 単一責任の原則は、クラスは一つの責務を持つこと
  • オープンクローズドの原則は、修正せずに(クローズド)拡張できること(オープン)。具体的には、ポリモーフィズムを利用して、サブクラスを追加する事で機能追加できる設計
  • リスコフの置換原則は、スーパークラスをサブクラスに置き換えても正常に動く状態。これを満たしていないとオープンクローズドの原則が満たされない可能性が高い。またサブクラスがスーパークラスのメソッドで使わないものがあれば違反している
  • 依存関係逆転の原則は、上位がインターフェースを提供し、それに下位が合わせる状態。上位が下位を使うと下位に依存する。下位が上位に依存するのが正当。そうすれば同じインターフェースを持つ下位を自由に使える。実現において重要なのは抽象化
  • インターフェース分離の原則は、関連がうすいインターフェースを分離すること。関連のないインターフェースの変更の影響がそれを使うクライアントにいかない事が大切
  • 原則はたくさんあるが必ず守る必要はない。しかし一度問題が発覚したら、次は起こらないように原則を適用して改善することが大切

給与システムのケーススタディ

抽象化することでオープンクローズドの原則に則って実装されのが具体的にわかりました。クラス作りすぎるのは煩雑だと思っていたけど、変更に強いし、理解すればわかりやすいです。コードがたくさんでボリュームがありますが、コードを読むことで理解が深まりました。このケーススタディで使われていたデザインパターンが最初にまとめられていたので、自分の理解を整理するためにまとめます。

デザインパターン

  • Commandは、クラスにコマンドを実装
  • Template methodパターンは、処理のテンプレートを実装して、それを継承し、詳細な処理を実装する
  • Strategyは、必要な処理をインターフェースに移譲し、処理を実装する。実際の処理を実装しているクラスと処理しているクラスが分離される
  • Facadeは、汎用インターフェースをシンプルに使いやすくする。ラッパーと似てると思うけど、違うかわからなかった。汎用インターフェースに使用方針や制約を課す
  • Mediatorは、Facadeと同じく方針や制約を課すのだけど、リスナーなどを使用して、意識することなく課される
  • Singletonは、自身のインスタンスをstaticで持ち、コンストラクタはprivateにし、インスタンスの生成は決まったstaticなメソッドで行い、staticな自身のインスタンスを返す事で、インスタンスが一つしか発生しないようにする
  • Monostateは、変数をstaticにし、別のインスタンスからでも同じstaticな変数を返すため、全て同じインスタンスのように振る舞う
  • Null Objectは、何もしないオブジェクト。クラスにstaticなNull Objectを保持し、インスタンスが生成できない条件のときに返す。Nullのときのメソッドの処理を調整し、存在チェックをシンプルにできる。（例:DBに存在しないときは、Null Objectを返すなど）

給与システムのパッケージング

給与システムのケーススタディのクラスをパッケージングしていました。最初にパッケージ設計の原則があり、その後使うデザインパターンの説明、最後に実際のコードでパッケージングしていました。難しかったです。。。

パッケージ設計の原則

  • 再利用リリース等価の原則は、再利用されるパッケージとリリースの単位が等価であること。再利用されるパッケージがリリースの単位より小さくなることはない。
  • 全再利用の原則は、パッケージ内のクラスは一緒に再利用されるべきで、関係ないものは含まないということ。パッケージには強い関連性があるもののみを含む
  • 閉鎖性共通の原則は、単一責任の原則のパッケージ版。変更に対して閉じているべきで、変更はパッケージ内全てに影響を及ぼすが、他のパッケージには影響しない。同じ理由で変更される可能性のあるクラスをまとめることでもある
  • 非循環依存関係の原則は、依存関係を循環させないこと。循環すると結局全てのパッケージと依存関係が生まれ一つの変更で全てビルドリリースが必要になる。解決するには依存関係逆転の原則を使う。AがBを使っているとする。Aが使うインターフェースを作る。Bはインターフェースを利用したクラスを提供する。Bがインターフェースに依存するので、依存関係が逆転する。またAとB両方が依存する新しいパッケージを外出して作るのも循環を防ぐ。パッケージ構造は変化し成長するもの。トップダウンでは設計できない
  • 安定依存の原則は、安定していて変更したくないパッケージに依存するようにして、変更したいものは依存されないようにすること。依存関係は安定するものに流れるようにする
  • 安定度抽象度等価の原則は、パッケージの安定度と抽象度は同程度でなければならないこと。安定するということは、抽象化されているということ

デザインパターン

  • Factoryは、インスタンス化することを請け負う。具体的なインスタンス化は、依存になる。依存をさけるためFactoryを作成し、インターフェースのみにつながる。しかし複雑なため乱用は勧めない

パッケージ設計で注意すべき点

  • パッケージは似た機能をまとめるだけではダメ。依存される「責任がある」パッケージと依存しない「独立した」パッケージがある。「責任がある」パッケージは、抽象化され再利用可能なもの。「独立した」パッケージは、変更が頻繁な詳細な処理を持つ。しかし保守性や再利用背性と依存関係の複雑性はトレードオフでパッケージの利用によって検討する必要がある。
  • パッケージ内で処理を完結させる
  • メトリック。凝縮度、内側に向かう結合度、外側に向かう結合度、抽象度、不安定度、主系列からの距離。定量的に測る

気象観測所のケーススタディとETSのケーススタディ

これ以降は内容が難しくなってきて、一応読んだもののケーススタディはほとんど理解できませんでした。何とかまとめたデザインパターンだけ記載しておきます。

  • compositeは、同じ処理を繰り返し行うときに使う。既存の処理は変えずに、リストに入れ、繰り返し処理すればよい
  • observerは、何かを監視するときに使う。observerを登録して、subjectに変化がありnotifyされたら、登録されているobserverのupdateを読んで更新する。更新にはpull型とpush型がある
  • abstract serverは、インターフェースをいれて、具体的なクラスが直接依存しないようにする。インターフェースを定義するときにクライアント側の名前にするのがコツ
  • adapterは、ソースコードを持っていない対象にabstract serverパターンを適用する時に使う
  • bridgeは、中間にコントロール層を作って管理する。複雑になるためおすすめはしない
  • proxyは、ビジネスロジックとDBの処理を分離すること

まとめ

アジャイル開発の原則からプラクティス、プラクティスの具体例に、デザインパターンとケーススタディのコードと盛りだくさんでした。まえがきで「コードをじっくり読んでほしい」とあるが、まさにその通りで、コードを読むことで学ぶことがたくさんありました。（最後は読み切れませんでしたが。。。）

付録にある「皮肉な運命」や「ソースコードは設計である」はとても興味深い内容でした。

全てを読み切れなかったし、読んだ部分も全てを理解できている訳ではないので、何度か読みなおしたい本です。本を見ればわかるように分厚く、かなりのボリュームです。その分内容もかなり深いと思います。オススメの一冊です。

 

 

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

 

 

ケントベックのテスト駆動開発入門を読みました。

読書 プログラミング

はじめに

ケントベックのテスト駆動開発入門を読んだ。3，4年前に読んで今回が2回目。最初に読んだ時も衝撃を受けたが、2回目読むとさらに理解が深まり、ケントベックのすごさが分かった。

今回読んで心に残ったことを記載していく。

テスト駆動開発の基本

テスト駆動開発の基本は、

だと感じた。

テストを素早くパスさせるために、定数を返すなどのコードを書くのだが、それが抵抗感があった。しかしテストコードとコードに同じ定数があるため、重複を取り除くためにリファクタリングを実施する。すると求めているコードになっていく。

前回は理解できていなかったが、今回少し理解できた気がした。

テスト駆動開発のパターン

アサートファーストが「おっ！？」と思った。テストを作成するときにどこから書けばいいのか迷う。まずクラス考えて、メソッドを考えて、引数を考えて、戻り値を考えて、アサートするというように上から順に考えていた。でもアサートファーストということで、アサートから考えるのがよいようだ。オブジェクトから何を得るか。結果から考えることで、テストを書きやすいと感じた。

レッドバーに関するパターン

「パソコンには安価な机。プログラマには良質な椅子。」と言うのはおもしろかった。やはり開発する環境と言うのは大切だと思う。

テストに関するパターン

「1人でプログラミングをしているときは最後のテストを失敗のままにして終える。」と言ういのは、やってみようかと思った。失敗のテストにより前の状態を思いだそうと考えるきっかけができる。

前にたまたまテストが失敗の状態でしばらくコードができないことがあった。失敗のテストのおかげで、前の状態を思い出したことがあったので、1人のプログラミングの時はやってみようと思う。

グリーンバーに関するパターン

仮実装などの話。上記の「テスト駆動開発の基本」でも書いたが、やっと少し理解できた。

xUnitに関するパターン

例外のテストの部分は参考になった。エラーが起きた時は何もせずに、エラーが発生しなかったときはテストを失敗させる。例外のテストは難しいと感じていたので、やってみたい。

デザインパターン

デザインパターンは難しく、まだ全ては理解できない。でも他の書籍を読んだり、実際にコードを書くことで、理解できるパターンが増えてきた。一番重要なのはコードを書くことだと思う。

リファクタリング

マーチンファウラーの「リファクタリング」を読んでいたせいか分かりやすかった。こちらの方がコンパクトにまとまっていて、分かりやすかった。すでにリファクタリングを読んでいたおかげだと思う。

TDDの習得

「途中でどのようにTDDに切り替えるのか」と言うのが興味があった。全部ではなく変更のスコープを決めて切り替える。確かにその通りだと思う。少しずつTDDに切り替えていきたい。

 おわりに

テスト駆動開発入門を2回目読んで本当によかった。さらに理解が深まり、プログラミングへの熱意も高まった。もっとコードを書きたい、テストを書きたいと思った。

実はxUnitの例はまだ読んでいない。それは、エクセルのマクロ用のxUnitを書こうと思っているから。

仕事ではエクセルのマクロなどで少しコードを書くことぐらいしかない。マクロでコードを書くときもテストを書くのだが、自分オリジナルで書いている状態だ。マクロのxUnitも使いたいと思っているが、モジュールなどをたくさん読みこまないといけないようだから躊躇している。

一方でもっとテストをシンプルに綺麗に書きたいと思っているので、勉強もかねて自分でマクロ用のxUnitを実装してテストを書こうと思っている。コンセプトとしては、「読みこむモジュールは1ファイルだけ」だ。完成したら公開したいと思う。

 

テスト駆動開発入門

テスト駆動開発入門

  • 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2003/09
  • メディア: 単行本
  • 購入: 45人 クリック: 1,058回
  • この商品を含むブログ (162件) を見る