目次
02日 外食
14日 エアコン不調
17日 受験終了
21日 プログラム中級者からの質問
27日 家族旅行行ってきました
次女は２月半ばに高校受験。
昨年末ごろから休みがない。年末年始も塾で特別講義があったし、年明けからは土曜日も塾で日曜日は模試。
さすがにストレスが溜まっているようで、テレビCMを見ていて美味しそうなものがあると「食べたい」と言っている。
もう半年くらい前から「ミスド行きたい」とは言っていた。最初聞いたときに食べさせてやろう、とドーナツを買っておいたのだが、食べたいのは「ミスター飲茶」だった。
ミスドのラーメンはあっさりしていて特別な味わいだ。あれが食べたいという。
模試の日は朝からあるのだが、夕方は早く終わる。先々週の模試の後、車で迎えに行った帰りにミスドの前を通り、また「食べたい」と言い出した。
なるほど。夕方だから時間的な余裕はある。ただ、この時は急だったのでそのまま家に帰る。
で、先週の日曜日、模試の帰りに食べることにした。
次女だけ優遇するのは悪いので家族に「ミスド行きたい人」と募ったら、全員で行くことになった。この日は家族でミスドが夕食。
ところで、平日の塾は夜１０時ごろ終了する。
遅いので車で迎えに行くのだが、帰宅すると１０時半。そこからご飯食べて、お風呂入って…すぐ寝ないで趣味を始める。
僕は先に寝てしまうので後は妻任せだが、１時過ぎまで起きているらしい。で、翌朝起きれず、６時半から時々起こし続けて、７時半にやっと起きる感じ。
試験当日は朝７時に家を出ないといけない。逆算すると６時には起きないといけない。
こうした生活習慣は簡単にできるものではなく、体を慣らすのに２か月は猶予が欲しいのに２週間前でもまだ身についていない。
そして次女が CM を見ていてまた言った。朝マック食べたいと。
なるほど。日曜日の模試のスケジュールを考えると、朝マックを食べてから行く余裕はある。
朝６時に起きて、７時までに身支度を済ませられたら朝マックに連れて行こう、と約束した。
約束したのが確か水曜日あたり。
本試験に向けて生活リズムを作るのがいかに大切かを…以前も説明したのだが、あらためて説明した。
さすがに２週間前なので本人も思うことがあったのか、翌日から寝るのが早くなった。
で、約束した今日。ちゃんと６時に起きることができた。
時間を考えると７時半ごろ家を出るのが良かったので、７時には家族も起こす。前日に「朝マック行きたい人」と募ったら、また全員で行くことになったのだ。
コロナ以降、家族旅行も行けていなかったし、コロナ明けても長男の大学受験、長女の高校受験などあって旅行に行けてないまま。
特に何でもない日に、ジャンクフードを食べにわざわざ家族で外食、というのもちょっとしたイベントで悪くない。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
この手の日記を書くのは何度目だろう…
２階で使用しているエアコンが不調になった。
…という書き出しもあえて同じに。
昨年末に修理したばかりだが、１月中旬にまた運転中に停止するようになり、昨年末に修理に来てくれた人と連絡しながら原因を探っていた。
結局原因がわからず、メーカーに相談したところ、直接確認したいので…ということで２月初旬の来訪となった。
で、１５分くらいいろいろな場所を確認して、原因特定。エアコン内の冷媒循環パイプが腐食しており、おそらくそこから冷媒が漏れているという。
エアコン自体の保証期間は１年だったので他の業者を頼んでいたのだが、冷媒回路は５年保証で、保証期間内の扱いで無償修理してくれるという。
しかし、部品取り寄席などで１週間少し時間がかかる。そのため今日が修理だった。
故障個所を確認してもらう前は、「時々止まってしまう」とはいえ、しばらくは動くのでだましだまし使ってきた。
でも、故障個所が特定されたら、「危険なので使わないでください」といわれてしまった。
おりしも、ここ数十年で最強、という寒波が来るところだった。
この一週間は暖房もなく、寒かった。
といっても、故障したのは２階のエアコンで、１階にはエアコンがある。外気温が氷点下でも、室内は13度より下がることはなかった。ありがたい。
仕事部屋は二階なので、コートを着てひざ掛けをして仕事してた。でも、キーボードを打つ手が寒いんだ。
修理の際にはエアコン外すので、有料でよければ丸洗いもしますよ、といわれたのでお願いした。
通常は外して、丸洗いして、取り付けて、改めてガス冷媒入れて…という作業で７万円くらいらしいのだが、洗う以外の作業は無料の保証工事になるので、洗うだけなら２万円。
午前中にすべての作業が終わり、正午あたりからエアコンが復活した。
とてもきれいになって、新品同様。何よりも「暖かい」という当たり前のことがありがたい。
一昨日あたりから南風も吹いて暖かくなってきたが、来週はまた寒波が来るという。
その前に修理できてよかった。
同じテーマの日記(最近の一覧)
別年同日の日記
16年 クリストファー・レイサム・ショールズの誕生日(1819)
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
次女が、高校入試の日程を一通り終えた。
お疲れ様。
私立はすでに合格通知をもらっているが、本命は公立の方。
先週金曜日と、今日月曜日の２日に分かれた試験だった。
落ち着いていつも通りの感じでできたようなので、模試などでの想定通りであれば問題はないはずだ。
後は発表を待つしかないが、発表まで２週間もあるんだよね…
「受験終わったら、～～やりたい！」といろいろ我慢していたが、今日から解禁である。
同じテーマの日記(最近の一覧)
別年同日の日記
15年 クリストファー・レイサム・ショールズ 命日(1890)
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
知人が趣味で C 言語の勉強を始めたそうだ。
Pascal は大学の時に学んだらしいが、その程度の知識。趣味でもプログラムは作っていない。
C の方が「よりハードウェアを理解できる」と聞いてやってみようと思った、とのことで、実用性を求めていない。なので、C++ でも、Python や Javascript でもない。
まぁ、そこは良い。「わかんないところがあるんだけど」と質問されて、それが面白かったので書き留めておきたい、と思っただけだ。
彼がわからなかったのは、プログラム自体の質問ではない。
初心者向けでもないが、上級者なら当たり前すぎて疑問にも思わない。中級者くらいが気になる質問だった。
本やネットで答えを探しても、こうした中級者向けの話題自体が少ないそうだ。
▼平均を求めよ、という例題があったのだけど、足してから割るのと、割ってから足すのはどちらがいい？
なるほど。
例えば、３～５を足した平均、というのは、数式で書けば
(3+4+5) / 3
となる。３つの数を足しているから、３で割る。
でも、分配側を使えば次のようにもかける。
3/3 + 4/3 + 5/3
数学では、この２つは同じものだ。
彼は直感的には最後に１度だけ割り算をした方が良さそう、と思ったそうだ。一応 Pascal をやっていて、丸め誤差などの存在は知っていた。
でも、実際の所どうなのか、と思って質問してきたのだった。
僕の答え。
最後に割り算、というので基本的にはあっている。割り算は誤差が生じるし、コンピューターの処理としては重い処理なので、できるだけ少ない回数で済ませたい。
ただし、「桁あふれ」が生じそうなときは、あらかじめ割る場合もある。
例えば、「銀河系の星の地球からの平均距離（km）」を知りたかったとしよう。
１つの星への距離も大きな単位で、これがまさに星の数ほどある。「先に全部足す」などをすると、桁あふれを起こす。このような場合は、溢れない程度の数ごとにまとめ、グループ内の平均をとった上で、その平均をさらに平均化する…というような処理になるだろう。
しかしまぁ、そんなのは特殊例。基本としては割り算は最後、でいい。
n / 3 / 4
みたいに何度か割り算をする場合は、 n / (3*4) というように、割り算が減るように変形したいところ。
今のコンピューターは十分速くなっているのであまり気にしないでよいのだが、それでも割り算処理は重い。
▼if の後に１命令しかないとき、 { } はつけるべき？ つけないべき？
案外知られていないが、構造化言語の文法では、if は「続く１命令を」実行するかしないか、という機能しかないことになっている。
しかし、現実には１命令ではなく、ひとまとまりの命令を制御したいし、ちゃんとできている。
そこで出てくるのが「複文」という概念だ。複数の命令を { } で括ると、それ全体が１つの命令としてふるまう。
（彼は言語の教科書を読んで勉強中なので、ここまでは正しく理解していた）
そして疑問となる。１命令しかないときに、わざわざ複文を作るべきか否か。
これは、完全に個人のルールだろう。僕が作る場合も、状況により使い分けている。
会社によっては、プログラムが俗人的になるのを嫌い、「必ず { } をつける」などのルールを定めている場合もある。
たとえば、以下のようなプログラム
if(x< 0) x= 0; if(x>255) x=255; if(y< 0) y= 0; if(y>255) y=255;
僕はこの場合には { } を付けない。つけない方が見やすいからだ。
でも、１命令でも { } をつけることはある。
if(longFlagVariableName){
longReciveVariableName = longFunctionName(longParameterVariableName);
}
ここで { } を付けたいと思う理由はいくつかある。
まず、if の後ろで改行したいため。改行の理由は、変数や関数の名前が長いから。
改行しないと、エディタの１行に収まらずに読みにくくなるかもしれない。
改行するなら、明示的に「どこまでが if の影響範囲か」を示したい。
次に、関数呼び出しを含んでいるため。
上手く動かないときに、デバッグのために、「関数を確かに呼び出してる」「呼び出した変数の値」「受け取った変数の値」などを、プリントデバッグするためのコードを追加したくなるかもしれない。
こうした可能性を考えて、最初から { } で複文にしちゃう。
つまりは、ここら辺は「論理」ではなくて、長いプログラマー生活の経験則、勘だ。
こういうものは、本やネットに書かれていない、というのは非常によくわかる。
▼ループ変数は、ループの外で使っても良いの？
こんな感じのプログラムを見たらしい。
for( i=1; i<=10; i++ ){
sum = sum + i;
}
print("sum(1～%s) = %s", --i, sum);
1～10 を足して、 sum(1～10) = 55 と表示するプログラム。
…なるほど。10 ではない数までを足したいとき、for の最後の条件を変えても、正しく動く。
彼はこのプログラムが気持ち悪い、という。
まぁ、僕もこういうことはしないだろう。最後の数(10) を変える場合を想定するのであれば、そこを変数にする。
そしたら、外側でループ変数の最後の値を使わないでも、「終了条件の値」の変数を使えばいい。
しかしまぁ、これも程度問題。ループ変数をループ外で使ったって別に問題はないし、状況によっては悪くない使い方ができるかもしれない。
ただ、ループ変数をループ外で使うのは、無用の混乱を招きやすい。
つまりは、「バグの元」という意味だ。
そこで、最近の言語ではこんな書き方もできる。
for( let i=1; i<10; i++ ){
～
}
最近の javascript 等では、上のように for のループ初期化の際に let で変数を定義できる。
すると、この変数は定義されたループの中でしか使えない。
そうすることで、ループ変数をループ外で使用する、という「無用の混乱」を避けられるのだ。
＃let は、先に書いた「複文」を示すブロック内で使うと、そのブロック内でしか参照できない変数になる。
しかし、for は少し特殊で、「複文」の外側にある、for の条件定義部分で let を使った場合でも、ブロック内の定義と見なされる。
▼パスカルの三角形を生成する、という例題があった…
質問が長かったので、解説しながら書く。パスカルの三角形とは次のようなもの。
1
1 1
1 2 1
1 3 3 1
1 4 6 4 1
上の段の数字の「間」に、上の段の２つの数字を足したものを書く。両端は 1 にする。
これを計算で作りだせ、という例題があったのだそうだ。
この時、「両端は１に」というのが、特殊な処理になる。
以下、１行の数値を配列に入れて処理している、という前提で話を進める。
1) 両端を含めたループを作り、ループ内で if を使って両端を認識、1 を出力する。
2) 両端を取り除いたループを作り、ループの前と後ろで 1 を出力する。
3) 両端を含めたループで処理はするのだが、両端は正しく処理できないので、後で 1 で上書きする。
彼がネットなどで調べたら、上記の３つのパターンがあったらしい。
どの方法でも結果は出せるのだが、どれを使うべきだと思う？ と問われた。
僕の答え。
まず、3 は論外。「うまく処理できない」というのが、ここでは配列の「まだ初期化していない部分」をアクセスしてしまって計算結果が不定、というようなものだったらしい。
ここで、両端を１にすることで、「次の処理の」ための数値は初期化される。
まぁ、動くことは動くかもしれないが、初期化していない変数にアクセスすべきではない。
また、計算した結果を後で上書き、という無駄をするのであれば、計算しない方が良い。
1 は、初心者向けにはわかりやすいと思うが、両端の処理のためだけにループ内に if を持ち込むのであれば、持ち込まない方法を考えた方が良い。
そして、if を持ち込まない、と考えると、答えは自然と 2 に落ち着く。
彼としては、計算がループというブロック内に収まらず、その前後に処理がある、というのに「美しくない」印象を受けていたようだが、どんな処理にも前処理と後処理はあるものだから、例外部分をそこに寄せていると思えばよい。
これは、ループ内は何度も処理されるので、処理が軽い方が良い、という単純な理屈だ。
ここで「ループの影響を受けない計算は、ループ外に追い出すと良い」という話をした。これは最適化の話で、初心者のうちはあまり考えないでよい。でも、気になり始めたらすでに中級者なので、知っておいてよいと思う。
▼今聞いてきたような話、少しでも効率よくなるように書くべき？
これが最後の質問。
最初は気にしない方が良い。効率化は最後に考えるもの。
もちろん、慣れてくればある程度効率的な方法で書いたり、後で効率化しやすい方法で書く、ということはできる。それでも、最初から効率化しない方が良い。
プログラムは必ず仕様変更するもの。
「ある状況」を考えて最適化されたプログラムは、別の状況になると全く役立たずだったりする。
効率化されていないプログラム、というのは、ある意味では「シンプルで変更しやすい」プログラムだったりもする。
僕がプロとして心がけているのは、動くものを早めに作ることだ。
まず確実に動けば、処理が遅いとか、問題点もわかってくる。早めに仕上がっていれば修正の時間はあるので、そこから効率化を考えればよい。
最後に、Cのようなコンパイル言語では、ある程度の効率化は勝手にやってくれる、という話もした。
最近は Javascript でも、書いたプログラムを直接ブラウザで動かす、ということは減っている。Javascript から「効率の良い Javascript」へと変換する、トランスパイルと呼ばれる作業を入れることがあるのだ。
もちろん、アルゴリズムから効率化されているプログラムは高速に動く。
しかし、小手先の効率化くらいであれば、コンパイルなり、トランスパイルなりの際に自動的にやってくれることも多い。
以上。
いずれもたわいもない話だし、正解はない。でも、確かに中級者のころは、僕もこうした部分でいちいち躓いていた気がする。
ネットにはあまり情報がない、という話だったので、あえて日記として残してみる次第。
初級者から中級者にステップアップする際に、こんな話は、他にもいくらでもありそう。
同じテーマの日記(最近の一覧)
別年同日の日記
19年 ファミリーベーシック V3(1985) ディスクシステム(1986)の発売日
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先週末の三連休のうち、２２日（土）～２３日（日）で家族旅行行ってきました。
コロナとか子供の受験とかで、５年間家族旅行行ってませんでした。
今年度は次女が高校受験（試験がすべて終わったばかり）、来年度は長女が大学受験なので、長女が忙しくなる前に旅行に行った、という感じ。
旅行記をすぐに書こうと思ったのですが、忙しくて少し時間がかかりそうなので、「行った」ということだけ記しておきます。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |