Fussy's Diary

先週の後半ごろから風邪をひいて、それがお腹にきたようです。急な腹痛やら下痢やらで結構しんどいです。

追い打ちをかけるように気温も急激に下がってきたのでエアコンが必須な状態となってきました。今度の新しいエアコンは加湿機能付きということで、暖房加湿で運転しています。それでも湿度がどんな状態かは気になるところですが、湿度計までが故障してしまいました。今年はエアコン、液晶モニタと結構高いものの故障が相次いだ年になりました。これが最後になることを願っています(今のところPCは大丈夫そうですけど、これも故障したらシャレになりません)。

ということで温湿度計を探しています。以前は TANITA のデジタル温湿度計を使っていたので、今回はアナログにしようかと、インテリアにもなりそうなものを調べているところですが、結構いろいろな種類があるものです。本格的なのは数万円のものも見つかりました。さすがにそこまで必要ではないですが。

湿度計を持っていると、季節ごとの湿度の変化がよくわかります。夏の蒸し暑い時期は 60% くらいだったのが、冬になると 30 % 台まで下がります。特に冬の乾燥はつらいですね。早いうちに手に入れたいものです。  

今日の「NHK白熱教室」はフェルマーの最終定理の話題から始まって、最後には谷山・志村予想の一端を垣間見ることができました。

先週は「ガロア理論」がテーマだったんですけど、これは見逃してしまいました。来週は最終回なので、忘れずに見ておきたいです。数学の講義そのものも非常に興味深い内容でしたが、それ以上に谷山豊の話にはグッとくるものがありました。谷山・志村予想に関してはサイモン・シン著の「フェルマーの最終定理」にも登場し、これが証明されればフェルマーの最終定理も証明されることになるというのは知ってましたが、肝心の谷山・志村予想についてはあまりよくわかっていなかったので、何となく雰囲気だけでも味わえたのはよかったと思います。
それにしても、係数がそのまま数論の問題の解になるというのは面白いですね。  

名古屋市美術館で現在開催中の「リバプール国立美術館所蔵 英国の夢 ラファエル前派展」を見てきました。日曜日の午後からということで混雑しているのだろうと予想していたら意外にも人は少なくラッキーでした。外にはかなり人が多かったので、おそらく名古屋市科学館の方に人が集中しているのでしょうね。

絵画の知識など無に等しいので、いつも予備知識なしで美術館へ行っています。先入観なしで自分の気に入った絵を見つけるというのが結構楽しかったりします。今回も、名前すら知らなかったりかろうじて聞いたことのある画家の絵でいいなと思ったものをいくつか見つけました。ギリシャ神話を題材にした絵が何枚かあって、昔美術の教科書かなにかで見たことのある「ナルキッソスとエコー」の絵の実物が見られたのには感激しました。ナルキッソスは、池に写った自分の姿を自分と気づかず恋してしまったというナルシストの語源になった人物ですね。

現在、名古屋ボストン美術館では「ヴェネツィア展」、ヤマザキマザック美術館で「聖なる風景」、さらに岐阜県美術館で「最後の印象派」と、他にも見たい展覧会がたくさん開催されています。なんとか全部見に行きたいと考えています。  

パリでの連続テロ事件、ニュースを見たときはビックリしました。昨日は飲み会があったんですけど、横にあったテレビでこのニュースが流れたときは飲み食いするのを忘れて見入ってました。今日は google や amazon などでも追悼の意が捧げられたり、スカイツリーなどはフランス国旗のトリコロールでライトアップされているようです。

フランス国旗のトリコロール、青は「自由」白は「平等」赤は「友愛」を表すとよく聞きますが、これは後付けの話のようです。万能辞典 Wikipedia で調べると、他にも聖職者・貴族・市民を分ける色でもあるみたいですね。
トリコロールの国旗は他にもたくさんあります。調べてみると、イタリアやベルギー・ルーマニア・ロシアもそうですね。日本は赤と白の二色ですが、意外に二色の国旗も多いみたいです。逆に色数の多い国旗はあまりないんですね。  

「グーグル、機械学習システム「TensorFlow」をオープンソース化」という記事を見つけました。TensorFlow へのページを開くと中に tutorial があるので、それを読むだけでもかなり勉強になりそうです。これだけのものを公開してしまうというのもすごいものです。やはり、優秀なエンジニアがたくさんそろっているからこそできるものなのでしょうね。
機械学習は興味はあるけどまだ基本的なところしか理解していないのが実状で、本格的なプログラムを作るにはまだまだ時間が必要です。アルゴルズムを理解するためにはどうしても統計学の知識が必須になるわけで、それだけでもかなり大変なんですよね。こればっかりは地道に努力していくしかなさそうです。

今年中に済ませておきたかった「アルゴリズムのコーナー」の「JPEG 法」が更新できました。サンプル・プログラムの準備に予想以上に手こずって、アルゴリズムそのものは全く同じなのに過去のサンプルに比べて圧縮率が悪いというよくわからない問題も発生したものの、結局 YUV 変換の部分で差異を見つけて解決できました。ちなみに、過去のプログラムはバグがあったのでそれも修正したものを再アップロードしています。  

暦の上では冬。しかし、まだ寒いというほどではないのがせめてもの救い。

昨日、インフルエンザの予防接種をうけてきました。すでに流行しているところもあり早めにうけておきたかったのですが、10 月はワクチンが品薄で結局 11 月に入ってからということに。まあ、仕方ないですね。
しかし、インフルエンザ予防に一番効果があるのは、できるだけ人混みを避けることと、外出後には手洗いとうがいをすることの二つだと思います。予防接種をうけてもかかる人はいるみたいですしね。そうは言っても、今のところインフルエンザにかかったことはないので、ワクチンの効果も少なからずあると信じたいですね。

JPEG 法の紹介記事はほぼ完成しました。あとはドキュメントの見直しくらいで、余裕があれば過去のサンプル・プログラムのバグ取りをしようと思います。来週には公開したいと思います。  

いろいろあって、ただいま充電中です。

JPEG 法の紹介記事の更新を進めています。サンプル・プログラムの見直しがほぼ終わり、あとは実際にテストしてドキュメントをまとめるだけですが、もうしばらく時間がかかりそうです。実は、以前に作成したソース・コードにはバグがあって、画像が正常に復元されない問題があります。今回のサンプル・プログラムではそれは発生していないのですが、元のソースのどこに問題があるのかが見つかっていなくて、修正版を用意するかどうか悩んでます。結構前にある方から指摘されて、修正しなければと思いつつずっと放置していたので、修正版も公開しておこうかと考えているものの、デバッグにまた時間が必要となりそうです。おそらく、アルゴリズムの問題ではなくて、型の使い方の問題だと予想していますが。。。

今年中に、確率・統計関係のソースコードをまとめたものも公開しようと企んでいます。これが結構なボリュームになって、ようやく先が見えてきたかなというところ。しかし、まだテストとデバッグの作業が残っています。ある程度は確認していますが、まだ完全ではないので、今年中に間に合うか不安なところです。  

エラー処理の話の続きです。

C++ での例外処理でよく話題になるのが「コンストラクタで例外を使ってよいか」という件。今ではガンガン使うようにしています。
コンストラクタは戻り値が得られないので、インスタンス化に失敗したかどうかを知るためには、成否を判断するためのフラグをメンバ変数として設けておいて実際に利用する前に判断させるというのがよく使われる方法です。以前は例外の使用は極力避けるようにしていたのでこの方法を採用していましたが、コンストラクタ内で利用する関数が例外を投げた場合を想定してきちんと捕捉して処理しなければならずコーディングが面倒になるし、単にフラグだけでは内部で何が起こったのかわからないので呼び出し側から見ても使いづらいところはあります ( メッセージ出力したり、エラー・コードを管理する手もありますがますますコーディングが大変になってきます) 。なので、今では逆に例外を多用するようにしています。

コンストラクタでの例外を禁止する理由は一般に「メモリ・リーク」の原因になるというものですが、内部で例外が発生したのならそれを捕捉して後処理をしてから再スローすれば済みます。あるサイトで見かけたのがこういうタイプのもの。

SomeClass* p = 0;
try
{
  :
  p = new SomeClass();
  :
}
cacth (...)
{
  (後処理)
}
delete p;

コンストラクタ内で例外が発生したら、p にアドレスが代入される前に catch 節に写ってしまうので、最後の delete p でもオブジェクトは解体されず、メモリ・リークになってしまうように見えます。しかし、ここはちゃんと対策されていて、コンストラクタで例外が投げられたら自動的に delete がよばれ、SomeClass 用に確保されたメモリはきちんと開放されます。但し、SomeClass のデストラクタは呼び出されないので、コンストラクタ内で new を使っている場合は例外を捕捉して後処理を行うことは必須となります。

クラス内で使うメンバのサイズが大きくなければ、new を使って動的にメモリ確保しない方がソースはすっきりしますが、そういうわけにもいかないですよね。