インタプリタな.NETをみたいからPythonする

Cなんていうのは作る人が使うプログラミング言語だと思うんだ。
まぁまさにそうで、Linuxなんかを作ってるのはCですからね。
けど、それ単体の機能がほとんどないし、いろいろあって細かい部分の面倒まで見る必要がある。
まぁ、Win32 APIを使えば、高機能だしWindowsもかなり面倒を見てくれて楽だと思います。
JavaとかC#・VB.NETなんかはJava VM、.NET Frameworkが面倒を見てくれるので非常に便利。
まぁこの辺まで来ると使う人が使うプログラミング言語ですよね。
けどそれでもコンパイルするのめんどくさいというのはあるし、インタプリタのような環境はありがたいものです。
作るプログラムのほとんどはPerlであるというのはまぁその辺の加減です。
しかし、.NET Frameworkで動くインタプリタあったりいいねとかも思うわけだ。いやあるんですよ。


IronPythonですね。以前ちょっと話したことがあったと思うけど。
なんでこんなものがあるのかという話だが、
作者であるJim Huguninは、「CLI(.NET Frameworkなどのこと)の設計は動的言語との相性が悪い」という論文を発表したらしい。
それでそれを確かめるために作ったのが、IronPythonとなったわけなんだが、
実は、.NET Frameworkでは動的言語であるところのPythonが結構うまく動くと。そういう結果だったらしい。
もうなんかすごい高速だったらしい。まぁさすが.NET Framework、実用的な環境ですね。
まぁなんというか変な経緯でできてますけど、.NET Framework上で動く有名なインタプリタです。
IronRubyというのもあるらしいが、やはりIronPythonだと思う。
Pythonという新しい言語を勉強して使うことになるが、Pythonしたいというより.NETしたいわけで。
導入法ですがかなり簡単です。IronPythonからBinの方をダウンロード。
それで、展開したフォルダをC:\Program Files\IronPythonなどとします、そして、環境変数のPATHの最後に追加。
これで便利に使えます。


まぁしかしPythonというのはPerlの正反対とも言えるようなやつですね。
Perlは非常に下品だが、いろいろな書き方を便利に取り扱うことができる。自由なやつです。
一方、Pythonは、そんなにやり方はたくさんなくて、きれいなソースでしか書けないという、小さいやつです。
まぁPerlは本当にひどいからね。しかしそれがよいのではないかというのも確か。
さて、それで上のように導入したら、コマンドプロンプトを立ち上げてipyとする。
すればIronPythonの対話環境が立ち上がる。

print "Hello Python!"

まぁ見ればわかるが普通に動作する。別にIronPythonでなくてもこうなります。
さて、せっかくだからプログラム書いてみようか。Ctrl+Zで出ましょう。
それで、こんなtest.pyでも作る。

# encoding: utf-8
def main():
strs=["IronPythonやりたいね","その前に練習やるよ"]
strs.append("Python知らないけどね")
strs.insert(0,strs.pop())
i=0
for cur in strs:
i=i+1
say(cur,i)
say("というお話でした");
def say(str,times=1):
if times==1:
print str
else:
for i in range(times):
print "%s(%d)"%(str,i)
if __name__ == '__main__':
main()

なんてことない、Pythonですね。まぁ一応Linuxのpythonでも動いたし。
で、ipy test.pyとすれば動く。
#encoding:utf-8は使ってるエンコーディングに合わせて書く。これだけでうまく動く。
さて、サブルーチンはdef main():のように書くのだが、範囲はインデントで示す。
しかも、1行1文が普通。まぁ確かに;で区切って複数書けるし、いちいち終わりに;を打っても副作用はないけどね。
リストは[ ]で囲んで書く。
まぁさすがにオブジェクト指向プログラミング言語言うだけあって、リスト操作も便利。
だけど、Perlほど機能が豊富というわけではない。まぁやはり小さなもんです。
for cur in strs:のように繰り返しは書く。まぁforというがC#で言うforeachみたいなもんです。
それで使うのが、range関数。rangeは開始数値、終了数値(この数値を含まない)、増分で、
増分が1なら省略可、さらに開始数値が0なら省略可。
まぁPerlの範囲演算子に類似していて、リストを作るものらしい。
“%s(%d)”%(str,i)のような表現があるが、これはsprintfのような役目を果たす%演算子を使ったやつ。
(str,i)のようなものをタプルというのだが、タプルは変更不可能のリストと思えばいい。
それであてはめて表示すると。Perlみたいに”$str($i)”とか、Rubyみたいに”#{str}”とかはないと。
最後の2行は、モジュールとして読み込まれたときは、__name__にはモジュール名が入るけど、
このファイルから実行されたら”__main__”が入ってるので、そのときだけmainを実行すると。
まぁそういうことです。Pythonの詳しい勉強はまたすればいいよ。
実行速度だが、ipyの初期化に時間がかかるので遅く感じてしまうかな。
カレントディレクトリにtest.pyを置いてipyからこうすると速い。

import test
test.main()

まぁこれじゃあIronPython関係ないですね。
以前のlivehack.dllをIronPythonで扱ってみようかと思ったのよね。
いちいちC#で書くとめんどくさいから、気軽に動かせんもんかって。

# encoding:utf-8
import clr
clr.AddReferenceToFile('livehack.dll')
import System
from hidemaro import livehack
def main():
mylive=livehack(livehack.mode.Office)
arg=["",mylive]
mytimer = System.Threading.Timer(System.Threading.TimerCallback(tickdo),arg,0,100)
print "なんかキー押したら終わるよ"
System.Console.ReadKey(1)
mylive.remove()
def tickdo(obj):
str="IronPython時報が%s時%s分をお知らせします!!"%(now.ToString("HH"),now.ToString("mm"))
if str!=obj[0]:
obj[1].send(str)
obj[0]=str
if __name__ == "__main__":
main();

まぁ非常におもしろい。所々慣れてない部分があって詰まったが、納得のいくやり方だった。
.NETのライブラリを使う場合はその前にimport clrとする。
その上でDLLはclr.AddReferenceToFileで読み込む。clr.AddReference(“System.Windows.Forms”)とかいう風なやり方もある。
importには2つ使い方があって、import Systemとすれば、System名前空間以下はSystem.Stringのように使える。
一方でfrom hidemaro import livehackは、hidemaro.livehackを単にlivehackと使える。
from hidemaro import *とかできるけど、そんなことはしない。だって下品だから。
さて、Pythonでのコンストラクタは、newなしでクラス名をそのまま書く。なるほどね。
なんというかあとはC#とかと扱い一緒なんだよね。
Timerのコンストラクタの引数は、毎度実行するSystem.Threading.TimerCallback型のデリゲート、
毎度渡すオブジェクト、何ms後に開始するか、何ms間隔で実行するか。
デリゲートは普通にコンストラクタを動かして作るだけでいいし、
毎度渡すオブジェクトはいらんかったらNone(null相当)、必要だとしても結構適当に書いていい。
受け取る方もむちゃくちゃいい加減ですね。C#でこんなの書いたらコンパイル通らないよ。
ちなみにobjの型はIronPython.Runtime.Listですね。あれ?


いろいろ試してみたのだが、引数に.NET Frameworkの配列(System.Array)を渡すとき、
読み取り専用ならタプル、それ以外は、System.Array[T](list)の要領で変換する必要があると。
あと、配列の作成は、System.Array.CreateInstance(T,length)の要領でやる。
System.Array.CreateInstance(System.Int32,10)のように。
IronPythonでSystem.Int32と書くと変数でSystem.Type型なのね。

mylist=['Yamada','Taro']
import System
System.String.Join(' ',tuple(mylist))
arr=System.Array[System.String](mylist)
System.Array.Reverse(arr)
mylist=list(arr)
while len(mylist):
print mylist.pop()

やはり考え方があまりに違う言語同士相容れないところはあるのかもしれません。
もちろんSystem.Array[System.String]もforで回せますよ。IEnumerableだから当然ですね。
最後のはこんなこともできるんだよと書いただけ。
どうもコンストラクタを使えばいろいろ相互変換できるように工夫されてるみたい。すばらしい。
なおタプル、リストとSystem.Array[T],System.Collections.ArrayList,System.Collections.Generic.List[T]、
辞書型はSystem.Collections.Hashtable、System.Collections.Generic.Dictionary[T1,T2]に変換できる。
他にもいけるのはあるかもしれない。
しかしこういう点を除けばIronPythonは非常に便利だと思いますよ。
そもそもSystem.ArrayとPython・Perl・Ruby・PHPの配列なんかを比べちゃいけない。
むしろそのための方法がそれなりに整備されてるIronPythonに感謝するべきだろう。
さて、クラス作りとかやりたいなとか思うけど、これ以上長い記事を書くと夜が明けるので今日はここまで。
あと、カテゴリ名がPerl・PHP・Ruby・Pythonになったよ。長すぎる…

税金と称して120円取られること

テスト終わり!けどこれからが忙しい。
まぁそうは言うのですが、明日は不可A試験日でお休みです。
後期はかなりハードです。毎週各日7・8・7・7・8限(1限45分)と、信じられない時間割。
まぁしかしこれは仕方ないですよね。まだ7限の日がたくさんあると考えましょう。


さて、夏休みに学校に奉仕しに行きました。
それでお金は振り込まれてたのですが、非常に中途半端な金額。
なぜだろうと思ったのですが、原因は源泉徴収でした。
今日、給与明細を受け取りました。いや本当に給与明細なんですよ。
はがき状になってますが手渡しです。多分非常勤講師の加減でしょう。
うちの学校の設置者は独立行政法人国立高等専門学校機構なんですけど…
これは全国で1つのところがいろいろまとめてやってると言うことです。
で給与のこともそうで、多分学校がなにやらやるわけではなくて、中央で集中してやってるんでしょう。
以前こういうことがあった友人に聞いたところ、やたら厳格ですなぁみたいなことを言われたし。


で、源泉徴収ですが、これは所得税のポピュラーな徴収方法です。
多くのサラリーマンが使ってるのだが、
月あたり支払われる給与から、所得税の金額を予想して、毎月給与から徴収していくと。
そして年末に、過不足を調整して、会社が納付してくれると。
税金を払う手間は省けるし、税金の捕捉率もよくなるし、何かとありがたいことです。
これがサラリーマンの税金の捕捉率がほぼ10割であると言われる原因です。
自営業とかかなりセコイからねぇ。店舗兼住宅だとどこまでが自宅かよくわからないという話ですし。
この辺が、消費税を上げた方がいいと言われる原因らしい。消費税も捕捉率高いし。
けど消費税じゃ累進課税できないしねぇ…
で、実は4000円の給与に対して、120円源泉徴収されました。
まぁこれは仕方ないのかもしれません。なんせ非常勤講師の給与と同列に考えてるっぽいので。
この120円がどうなるかには2つの考えがありますね。
1つは高専機構が年末調整を実施して120円、僕の口座に払い込むこと。
もう1つは源泉徴収票を受け取って税務署に持って行って、そこで還付手続きをして振り込んでもらうこと。
どっちかというと前者のほうがありがたいですね。しかし手間がかかりすぎる。
普通はそのとき職場にいない人は、後者の方法で処理しろということになります。
まぁめんどくさい。何がめんどくさいって、お金が返ってくるまでえらい時間がかかる。
手続きは簡単なんですよ。国税庁のHPで書類を作って郵便で送るだけです。
けどね、返ってくる金額が120円だから、郵便で送るとそれだけで80円取られるのよね。
なんという嫌がらせ。まぁそれでも受け取りに行かないわけにはいかないけど。


まぁ、きちんと年末調整してくれればこの手間はないので、高専機構に期待せざる得ないだろう。
ところで住民税の集め方はちょっと違う。
住民税は、市町村民税と道府県民税をまとめて市町村が徴収するのだが、
これは前年の所得について今年課税するという方法なので非常にわかりやすい。
サラリーマンは専ら特別徴収ですね。会社経由で徴収するので特別徴収と。
で、税額を決める根拠は、所得税の申告なんですね。なので基本的には気にしなくていいと。
まぁしかし、4000円だと、所得税も住民税もどっちも非課税ですよね。
あまり気にしないこととしましょう。

1加えることなんて好きに書いてよろしい

友人から電話がかかってきた。明日プログラミングの試験なもので。
さて、その質問の中で「++iとi++って違うの?」というのがあったのだが、まぁ違うけど気にしないと答えた。

i++; ++i; i+=1; i=i+1;

この4つの式は単独で使う限りはどれも意味は同じ。
普通は単独で使うと思うよ。
ただ計算結果が違う。i++は、加算前のiが計算結果。++iは加算後のiが計算結果。
ただ計算結果を使うことは最近では少ないのでは?そうでもないか。
問題になるというとこういうコードか…

int i;
i=10;
while(i--) printf("%d ",i);
i=10;
while(--i) printf("%d ",i);

i–の場合は、iが1のとき、iは0になって計算結果は1で、真だからiが0になってループが回る。
–iの場合は、iが1のとき、iは0になって、計算結果も0で、偽なのでループ終わり。
こういう違いがありますが、非常に紛らわしいので、forなどでインクリメント・デクリメントと条件チェックは分けた方がいいかと。


まぁしかし、インクリメント演算子、デクリメント演算子言いますけど、
これは確かにシンプルに書けますが、別にi+=1でもいいじゃないかというのはありますよね。
Visual Basicにおいては、VB.NETからはこの演算子が導入されたのですが、インクリメント・デクリメント演算子はありません。
けど僕はこれでいいと思いますよ。
i=i+1はiを2回書くので書き間違えが起きやすそうですが、
+=のような代入演算子さえあれば困らないかなと。整数型以外はこれ使わんからねぇ。
もっともC++においてはインクリメント演算子はかなり重要なものだったと思いますけど。
STLにiteratorというのがあったのだが、こいつは++で次に進むだったみたいだ。
.NET Frameworkではこれに相当するのはIEnumeratorだけど、こちらは前進専門。
そう、iteratorは前進後退可能だったり、ランダムアクセスすら可能なのもあったと。
でポインタみたいに振る舞うものだったらしい。なんというかC++は演算子のオーバーロード好きですね。
まぁその辺の都合もあるみたいです。
しかし、.NET Frameworkのライブラリは演算子のオーバーロードはあまりしない。
もしiteratorがあれば、Next、Prevとかいうメソッドを用意してただろう。まぁないんだけどさ。
operator ++が定義されてるのは、System.Decimalだけだった。しかも構造体だからC++のような問題は無いね。


そのC#でせっかくなのでi++と++iの動作の違いをILで見てみることにした。
結論から言えば、結果を使わないならば、++; ++i; i+=1; i=i+1;はいずれも同じ動作。
結果を使うにしてもちょっと順番が変わるだけでやることは変わらない。
まぁCの時代は結果を使わない場合すら、この4つの計算の動作が違ったらしい。
しかしそれはコンパイラの問題だと思うけどね。もっとも便利な動きに最適化されるはずだし。
まぁこれは検証する気にならないけど、ILは非常に読みやすいので…
まず、結果を使わないでインクリメントすること。全部一緒ですよ。

  ldloc.0
ldc.i4.1
add
stloc.0

まず、iの値をldloc.0で積んで、その上に1を積んで、2つを足したのを代わりに積む、それをstloc.0でiに納める。
非常にわかりやすいですね。どのように書いても、i=i+1のように解されることがわかりますね。
まぁ実にILの仕様は単純なものです。1加えるだけにしてもinc命令とかないんですね。
少なくとも.NET Framework上ではどれも性能は同じであると。
さて、結果を使う場合。p=i++に相当するILです。

  ldloc.0
dup
ldc.i4.1
add
stloc.0
stloc.1

2つ目のdup命令と、最後のstloc.1、これはpに代入する命令だけ増えました。
ldloc.0でiを読み込んで、これをdupで2つにコピー。この上の方と、その上に積んだ1を加算して代わりに積む。
その上の方をstloc.0でiに納める。これがiに1加算する行為です。
そして始めにコピーしたやつを結果として使うと。そういうことです。
一方、p=++iに相当するIL。

  ldloc.0
ldc.i4.1
add
dup
stloc.0
stloc.1

dupの順番が違いますね。
まず、iの値をldloc.0で積んで、その上に1を積んで、2つを足したのを代わりに積む、ここまでは結果を使わないときと同じ。
この結果をdupで2つにコピーして、まずstloc.0でiに納める。コピーしたもう1つを結果として使うと。
やってること自体はあまり変わりませんね。
まぁあえて言うなら、p=i++はこれでスタックが3つ必要ですが、p=++iはスタック2つで済んでいると。
その程度ですね。


++iでもi++でもあまり差はないと。けど結果を使う場合は++iの方が性能がいいかもしれないと。
それはCの頃からそうで、C++においてはこの辺の事情があって前置インクリメントが主流みたい。
いやなんか後置インクリメントだと、コピーコンストラクタを動作させないといけないと。
C#もどうもoperator ++を定義するときは、インスタンスをコピーしろらしい。そりゃ流行らんわな。
まぁ確かにC++になって発生した問題かもしれないけど、昔から++iの方がいいと考える人も多かったはず。
けどC++は++Cじゃないんですよね。なぜだろう。
K&Rという有名な本があるんだが、そこではi++のような表記が好んで使われていたらしい。
なぜだろうかと思ったけど多分こう言うことだと思う。

char s[11];
int i=0x30;
char *p;
p=s;
while(i<0x3A){
*p++ = i++;
}
*p='\0';

僕はこんなのは嫌いなんだけどねぇ…まぁしかし実にCらしい。
p++を使うことで、今のpについて処理して、pを進めると言うことが直感的に書ける。
i++も同様。今のiを代入して、iを進めるということができる。
こういうシンプルだけど不気味な記述が多い本らしいです。K&Rというやつは。
以前取り上げた気がするけど、strcpyの実装例として、こんなのが推奨されてると。

void strcpy(char* sf,char* st){
while(*st++ = *sf++);
}

さっきのとほとんど一緒。だけどループの条件わかりにくい。
*sfが0のときには、*st++ = *sf++の結果は0、すなわち偽なので、ここで終了と。
まぁひどいですね。こういう操作が流行したんでしょう。だからCの拡張をC++と呼ぼうとかなったんでしょう。
僕はJavaScriptの頃からC++という言語もあるのだし、1加えることは専らi++と書こうと考えてきたけど、
実はこういうことがありそうです。しかし気にせず好きな表現を使うのが一番いいでしょう。

そのうち定期券買わんとあかんなぁと

もうすぐ定期券が切れるんで、父から定期代をもらってきました。
4月と10月に定期券を買うんだが、4月は春休み明けすぐに買わないとだめなので、
わざわざ証明書を学生課にもっていって検印をもらって、すぐに買いに行ったものです。
で、10月の方だが、普段は休日に近所の駅で買ってるので、金を預かることはしてなかった。
けど、今回定期券の期限が、件の旅行の前日に切れる。
旅行中は定期券はいらないので、旅行から帰ってきた次の日から有効の定期券を買おうとした。
期限切れるのが遅くなれば、その分4月にゆとりができますからね。
ところが、新規の定期券は7日前からしか買えないけど、その間休日はない。
しかも最寄り駅は定期券を売らない駅なので、学校の最寄り駅か、途中の駅で買わんといかんと。それでね。


ところで通学定期券はすごく安いです。
以前計算したら、通学定期の通勤定期に比べての割引率は、近鉄は近所の他の私鉄とさほど差はないと。
JRに比べればかなり安いけど、それはJRの通学定期の割引率がさほど高くないだけ。
「これはスーパーダンピング定期券だな」の記事に書いてあります。
一方で、近鉄の定期券は、普通運賃に比べてそれなりに割引されている。特に長距離。
とまぁ、そういう背景があるみたいですが、僕の定期券は6ヶ月で3万円を切るぐらいの値段です。
友人からは、距離の割には安いと評判です。距離は4倍近く違うのに、値段は1.2倍程度ですから。
こういうのを聞くと、長距離通学してるんだなという感じはあるけど、
ひたすら山の中なんですごく速いですからね。乗り換え・停車あるのに、平均53km/hって…
結構速いんじゃないですか?まぁまだまだいけるかもしれんけど。
まぁそういうわけなので、時期になったら買うことにしましょう。証明書出しとかんとなぁ。


ところで、父は一部電車で通勤してるのですが、その定期券は6ヶ月で10万円強と。
あれ?そんなに高くないね。JRの通勤定期は安いからかな。
と思って調べてみたのだが、どうも普段通学してる区間の通勤定期の値段とそう変わらんみたい。
まぁ距離は僕の方が長いんだけどね。さすが山を避けて遠回りしてるだけのことはある。
安い定期券というのはいろいろとありがたいものです。
だって通勤定期と同じ値段だったら、6ヶ月定期って半年の授業料と同じぐらいするわけだし…


ところで最近は定期券の自動券売機ありますよね。
近鉄だと黄色いあれです。結構いろんな駅に置いてありますね。
通勤定期だとあれで買う方がむしろ早く済むとか。
ただ、通学定期は年度内の継続以外は使えないので専ら窓口のお世話になってます。
今回のこれは継続ではなくて新規なので、窓口でしか買えませんね。
まぁ通学証明net申請サービスというのをやってるらしいが、これを使えば自動券売機でも買えるんだけどね。
けど使ってる学校少ないから。
説明を読む限りではインターネットを使えるコンピュータだけ用意すれば使えるみたいだけどね。
まぁ欠点として、自動券売機でしか買えなくなるというのがあるので、ちょっと難しいんだけど、
そのうち自動券売機は多くの駅に配置されるんじゃないかな。そうすればね。
まぁ今は近鉄だけだけど、仕組みはさほど難しくないと思うんだよね。まぁ普及するか知らんけど。

宇宙を作ってる4つの式の1つと対峙する話

今日は電磁気の試験でしたと。
まぁその電磁気の前にこれも電磁気をやってた物理の試験があって冗長ですよね。
と言いたいけどそれはない!
物理の方の電磁気は磁気がメインでした。見えやすいからね。
ローレンツ力の向きどっちだっけとか迷いますけど、右手の法則は便利ですね。
フレミングの右手の法則は、右手の親指を速度、人差し指を磁束密度、とすると中指の向きに誘導起電力が発生。
ほらわかりやすい。左手の法則の方が有名ですけどね。
負電荷は電位の低い方に集まりたくなるはず。だから電子は中指の付け根の方に集まってくるよ。
というのはまぁいいんですよ。


今回の試験は、積分で電界を求めることと、ガウスの法則の微分形、ポアソン方程式。
一体何言ってるんだという話です。
まぁ1つ目の積分で電界を求めることは、例えば導体棒にある電荷を細切れにしてそれぞれの作る電界を足していくと。
これ積分。「最後の仕上げの積分が一番困る」の記事でその話は取り上げました。
何が言いたいかというと、仕組みは難しくないけど、計算は難しいかもねということです。
幸いなことに今回の試験ではこんな積分はしなくて済んでよかった。
次のガウスの法則の微分形だが、見るに堪えない式。
D
きれいな式ですねなんて言っちゃだめですよ。問題はなんです。
の中身ですが…見えないなら残念。
またMathMLです。Firefox・Opera以外のひとごめんなさい。
まぁこういうベクトルです。太字なのはそのためです。


いきなりガウスの法則の微分形を見ると大変なので、
電位の傾きは電界であるということを表した式、-V=Eを見るとわかりやすい。
ベクトルのスカラー倍はベクトルの中身全部にスカラーをかければいいと。
Vですが…見えないなら残念。
にスカラーをかけることをgradという演算子で表すらしい。gradは勾配の意味。
∂は偏微分の記号で、ラウンドディーとかデルとか読むみたい。
∂V/∂xはVをx以外の変数も定数と思い込んでxで微分するということ。
多変数のときはdV/dxと書かずにこう書くと。
まぁこれで電界が求まるわけです。騙されてる気はするけどね。


さて、D=ρに戻ります。
なぜこうなるのかメモしようと思ったのだが、えらいことになったからやめる。
電束密度ベクトルのX成分のxでの微分と、Y成分のyでの微分、Z成分のzでの微分を足すと、電荷密度だと。
小さな箱があると考えて、大きさはΔx,Δy,Δzだと。
左の電束密度のX成分がD1xのとき、電束の本数はD1xΔyΔzだと。
入ってくるD1xと、出て行くD2xの差をΔDxと書くと、
左右方向の電束の変化は、ΔDxΔyΔz本。ところで電束はQ[C]の電荷からQ本でるものだと。
左右方向だけでΔDxΔyΔz[C]の電荷があるはず。これを三方向足し合わせたら全部だ。
ΔDxΔyΔz+ΔDyΔxΔz+ΔDzΔxΔy[C]あるはずだと。
しかしなんかΔだらけでうざいので、箱の体積のΔxΔyΔzで割って、電荷密度にする。
ところで電荷密度というと、線電荷密度(文字:λ)、面電荷密度(文字:σ)、体積電荷密度(文字:ρ)があるけど、体積電荷密度ね。
すれば、ΔDx/Δx+ΔDy/Δy+ΔDz/Δz=ρとなると。
これを偏微分で書くと…というのをを使ってすっきり見せたのがさっきの式。
Dですが…見えないなら残念。
何のことかわかるだろうか…内積は成分表示されてたら、X成分同士のかけ算、Y成分同士のかけ算、Z成分同士のかけ算の和になる。
それを利用して、あんなシンプルな式に書いたんだと。
迷惑すぎる…ごちゃごちゃしてるけどガウスの法則の積分形の方がよっぽどイメージしやすい。
あれは閉曲面を用意して、面を細切れにして、面に垂直な単位ベクトルと電束の内積を足し合わせると。
非常にわかりやすい。2年生の途中で出てきて、確かに一様な電界、閉曲面に直角に出るという条件付きだけど簡単にあつかえたし。
けどね、積分って微分の逆なのよね。だから積分形も微分形も意味は一緒なんだよ。これはひどい。


まぁこんなのを延々と授業でやってたわけです。
しかしこんな複雑な式が出てきたところで、この式はあまりにひどい。
僕もそうだし、近所の友人もそういうが、「かけるって1回微分するってことだよね」というぐらいのイメージだ。
人間が取り扱うときは、この機能をフルに使うようなことはしない。と思う。
今回の試験ではX方向だけ考えればいい問題ばっかりだった。
電位の勾配は電界というあれはX・Y・Z方向全部あったけど、あれはただの偏微分だ。
さて、電位の勾配は電界というのと、ガウスの法則の微分形を組み合わせてこういう式が作れる。
V=-Eだが、DEの関係があるので、
DE=-εV=ρ
なんじゃこりゃ。の内積って何だ。2回微分みたいな意味ですね。
これで、2V=-ρ/εと書けるのだが、
これをポアソンの方程式というと。
電位を2回偏微分するようなことをしたら、そこの電荷密度がわかるということですね。
ところで普通は空中には電荷はないですよね。
まぁどうも空中に電荷があることを考えるときに使う式らしいです。
このρ=0とした、2V=0をラプラスの方程式と言うらしい。


まぁしかし、きれいだけど実は腹黒い式というのがよくわかりましたね。
このガウスの法則の微分形は、電磁気を4つの式で表したというマクスウェル方程式の1つらしい。
確かにたった4つの式で表せると言ったのはすごいのだけど、
けどだらけでもう…
残りの3つの式のうち1つか2つは3年生のうちに会うかもでしょうとまぁ…
まぁこの式とばかり対面しててもなかなかわからんものです。
こんなだらけの世界を図で書いたものを授業で配布してくれた。
実はそこから、なんでD=ρやねんという説明をここに改めて書いたわけだけどね。
そう小さい箱。実は小さい箱の絵が描いてあったんですね。
「色は匂へど 散りぬるを 我が世誰ぞ 常ならむ
有為の奥山 今日越えて 浅き夢見じ 酔ひもせず」
というのは仏教の難しいことをわかりやすく説明したものならば、
その小さな箱の図は、ガウスの法則の微分形をわかりやすく説明したものなんだろうと。そう思えるかなとか。

Live Messengerを操作するライブラリを作る

Windows Live MessengerはきっとWindows Liveのソフトウエアでもっとも使われているでしょう。
IMとしてはYahoo! Messengerの方が好きなんだけど、かなりの友人がMSN Messengerの時代から使っていて、
それに合わせて僕もWindows Live Messengerを導入しています。
ちなみにLive IDは持ってますが、Hotmailは使ってませんよ。
新しくメールアドレスを作る必要がないので、わかってもらいやすいのでおすすめ。


さて、このLive Messengerのおもしろい機能というと、表示メッセージの機能。
僕はずっと表示名を「Hidemaro ◆3rRY3LJ8tc」としている。
まぁ当然なんだけど、これに加えて、「キーボード故障中」ということを知らせたい。
そんなとき、この表示メッセージ欄に書くといいと。
表示メッセージはメイン画面で簡単に変更することができるので便利。
けど、近所の人は、「Hidemaro ◆3rRY3LJ8tc //キーボード故障中」とかする人が多いですね。
この表示メッセージに対応してないクライアントもあるからですね。
しかし、気軽に使えるというのがこのいいところです。あまり大切な事は書かない方がいいです。
ここを音楽の再生に合わせて変えることができる。
Windows Media Playerを筆頭に多くのソフトウエアが対応してる。ユーザーによる対応も多い。
foobar2000においては、MSN Now Playingなどのプラグインで対応することができる。
仕組みだがどうも知られているらしい。
.NET FrameworkからもDllImportすれば使えるようだ。
yuuAn’s Note / “再生中の曲”を表示 @MSN Messenger:あたりを参考にやってみた。


ところで調べてみたのだが、この送信モードは三種類あると。
Musicは音楽、Gamesはゲーム、Officeはよくわからない。
よくわからないのでOfficeを専ら使ってみるけど、まぁGamesで、「SimCity4」とか表示するのもいいかもしれない。
せっかくなのでライブラリを作ってみた。
Win32APIの操作を.NET Frameworkから簡単に取り扱うことのできるクラスですね。

namespace hidemaro {
/// Windows Live Messengerに状態を送信するクラスです。
public class livehack {
private IntPtr mylive;
private mode curmode;
/// コンストラクタです。Live Messengerのハンドルを確保します。
public livehack(mode curmode) {
this.mylive=FindWindow("MsnMsgrUIManager",null);
if (mylive==IntPtr.Zero) throw new NullReferenceException("送信先が見つかりません");
this.curmode=curmode;
}
/// 送信モードの列挙型です。
public enum mode {
/// 音楽モードです。
Music,
/// ゲームモードです。
Games,
/// Officeモードです。
Office
}
/// 状態を送信します。
/// 送信する文字列
public void send(string str) {
datastruct data=new datastruct(
string.Format(@"livehack\0{0}\01\0{1}\0\0\0",this.curmode,str));
try { SendMessage(mylive,0x004A,0,ref data); } finally { data.Dispose(); }
}
/// 状態を解除します。
public void remove() {
datastruct data=new datastruct(
string.Format(@"livehack\0{0}\00\0\0\0\0",this.curmode));
try { SendMessage(mylive,0x004A,0,ref data); } finally { data.Dispose(); }
}
/// デストラクタです。
~livehack() {
this.remove();
}
private struct datastruct : IDisposable {
public int dwData;
public uint cbData;
public IntPtr lpData;
public datastruct(string str) {
this.dwData=1351;
this.cbData=(uint)(str.Length+1)*2;
this.lpData=System.Runtime.InteropServices.Marshal.StringToHGlobalUni(str);
}
public void Dispose() {
System.Runtime.InteropServices.Marshal.FreeHGlobal(this.lpData);
}
}
[System.Runtime.InteropServices.DllImport("user32.dll")]
private extern static IntPtr FindWindow(string lpClassName,string lpWindowName);
[System.Runtime.InteropServices.DllImport("user32.dll")]
private extern static int SendMessage(IntPtr hWnd,int msg,int wParam,ref datastruct lParam);
}
}

まぁ具体的な使用例はあまり書かなくてもOKだろう。
livehackクラスのコンストラクタでmodeを指定して、インスタンスを作って、
それで文字列をsendすればいいと。プログラムを終了する前には必ずremoveするようにしてほしい。
一応忘れても大丈夫なように~livehackというデストラクタを用意してある。
けどデストラクタはいつ呼びされるかよくわからない。まぁ念のために用意しておいただけです。
まぁIDisposableを実装しておいてusing構文を使いましょうとまでは言わないけど、忘れないようにね。
そもそも複雑な操作じゃないけど、これならかなり扱いいいですね。
IronPythonとか.NETを取り扱うことのできるスクリプト言語なら、気軽に書くだけでLive Messengerを操作出来る。


さて、実際の動作だが、あらかじめ、user32.dllより、FindWindow、SendMessageの2つの関数を読み込んでいる。
まぁこういうことができるのは.NETの強みではありますよね。
それでコンストラクタでFindWindowを用いて、送信先を探す。まぁいい加減だがこれでOK。
もし見つからなかったらNullReferenceExceptionがスローされる。なんでやねんと言われそうだが。
実際の送信だが、送信する文字列はこんな具合で書く。

Application\0Mode\01\0Format\0Title\0Artist\0Album

ここで下線を引いたものは自分で当てはめて欲しいという意味。
\0はU+005CとU+0031の二文字のことで、NULL文字ではないので注意!
1つ目にアプリケーション名。今回は全部livehackです。2つ目はモード。
3つ目はわかりにくいが、1です。送信するときは1で、消去するときは0です。
消去の時は以後の項目は何も書かなくてOKです。けど\0は残しておかないとなんかうまくいきません。
4つ目はフォーマット。実は今回全部ここに押し込めてあります。Musicのときは{0} – {1}を指定するのが多い。
5つ目はタイトル、6つ目はアーティスト名、7つ目はアルバム名。それぞれFormatの{0},{1},{2}に展開される。
もし{0},{1},{2}を使わないにしても\0は消さずに残しておく。じゃないとうまくいかない。
実は音楽モードで送信もできるけどあまりおすすめしない。{0},{1}を使ったものを作って欲しい。
文字列などを納めるdatastruct構造体だが、結構わかりにくい構造ですね。
ここで文字列だが、UTF-16の配列としてアンマネージドな領域に送られた。
その加減でかならず破棄しないといけない。けど構造体なのでデストラクタを使うわけにもいかない。
それでIDisposableを実装してみたが、SendMessageで送信するとき、refキーワード付きなのでusing構文が使えない。
使うところはlivehackクラス内2箇所だけなので、その部分ではtry~finally構文で書いてあげた。
構造体をrefで渡すというのはC#では流行らんが、Cではよく使われた技です。
構造体の分のメモリをmallocで確保して、ポインタばっかり使うと。C++・Java・C#で言うクラスみたいなもんです。
まぁ流行らんわなぁ…
それでSendMessageで送信すれば反映されると。めでたしめでたし。


まぁこんな仕組みでして、一から作ってもすぐできます。
しかしよくわからないCの世界をC#で見るのは非常にわかりにくい。
なのでこういう風にクラスを作って、それを専ら使うのが便利だとおもいます。
livehack.lzh (3.37KB)
まぁこれを展開して、適当なところに置いて、参照設定にファイルの参照で追加すれば使えます。
多分XML Documentationも読めると思う。
参考になればと思って、適当なサンプルを付けています。IDEを使わずに書いたからめんどくさかった。
ちなみにこれのコンパイル法はVisual Studioコマンドプロンプトなどを用いて次のようにする。

csc test.cs /r:livehack.dll

まぁこんな具合です。DLLも簡単に読み込めていいですね。

Blognplusにはカテゴリーという機能があるんですよ

ちょっとBlog変わりました。
まず見た目、最下部に過去・未来のバーを設置しました。これはかなり便利です。
あとカテゴリーの名前と区分を変更しました。
まずLinuxをLinux・Webに。これはずっと無視してきてた問題だからね。
その上で、コンピュータよりPerlの記事、LinuxよりPHPの記事をPerl・PHP・Rubyカテゴリを新設し移行。
日常カテゴリより日常からかけ離れた内容を社会カテゴリを新設し移行。
それでカテゴリは
日常、コンピュータ、Linux・Web、Perl・PHP・Ruby、電気、社会
となるわけですね。


ところで、Perl・PHP・Rubyは1つのカテゴリなのに、C#はなぜコンピュータカテゴリに残されてるの。
というのはあるかもしれないね。まぁWindowsと組み合わせて使うことが多いからなんだけど。
ただどちらかというと、Perl・Python・Ruby・PHPはちょっと特別だと。
そういえばあんまりRubyの記事書いてないけどカテゴリ名にRuby入ってるね。まぁ念のためです。
その割にはPythonは入ってないけど。けどヘビつかいじゃないし。
まぁそれはともかく、この4つのプログラミング言語は軽量プログラミング言語という分類をされることがあります。
軽量というのはプログラマの負担が軽量という意味かな。
ゲタのように使える、インタプリタのような環境で動かすプログラミング言語ということです。
Linuxの上にせよ、Windowsの上にせよ、Apacheの上にせよ、やりたいことは結構似ていると。
そういうことを解決するのに使えるよねということです。
まぁそのあたりがC#とかとは違うよと。そういう考えです。


それにしてもPHPは異端ですよね。
あれは関数名が長すぎるのが困る。htmlspecialcharsとか長すぎ。
整理して欲しいんだけどなぁ…
まぁちょっとその辺があって、普段使いには不便かも知れないね。
けど関数の数はすごく多いからこのあたりは便利で、それだけで何でも出来るというのはありますね。
目的もWebプログラミングが主で、他はあまり使わないけど、Webサイトの管理とかでは使えるときもあるかも。
慣れてるPHPで全部やればいいじゃないとかそういうことです。
まぁちょっと目的は違うけど、Perlとかと考えとしては似てないこともないからいいですね。


まぁしかしカテゴリで分けると過去の記事をきっちり探しやすくなるかな…
と思ったけど、どうも横断的な記事が多いのでなかなか。
実際は本文検索をかけた方が便利かも。
まぁしかしせっかくある機能ですし、よい方に持って行きたいですよね。

ωと見て角周波数というのは悪癖かな?

以前、なんかの物理の問題について書いてある記事を見てたのだが、
そこでその人が電界やら磁界やら言ってたと。まぁそれ自体は何でもない気がするけどね。
それについて電場、磁場じゃないの?というコメントが付いていたと。
とはいえ、ずっと電界、磁界の言葉を聞いてきてたものとしては何がおかしいんだろと思ったものだ。
と思って調べてみたのだが、理学では電場・磁場、工学では電界・磁界を使うことが多いと。
ところで重力場という言葉があるのだが、まぁこういうなんかが周囲に影響を与えるところのことを場というと。
そういう風考えれば電場・磁場の方がいいけど、もう電界・磁界で定着してるからまぁ気にしないことにしようと。
ちなみにどっちにしろ英語で言えばElectric field、Magnetic field。そうfieldなんですね。


昨日、電気機器の試験があったわけで、直流電動機がなんやらかんやらというのがあったわけだ。
回転数というのが出てくる。単位はrpmですね。1分あたりの回転数とちょっと不気味。
60分の1すれば1秒あたりの回転数でわかりやすい気もする。別に単位Hzでいいじゃないかと思うんだけどね。
しかしHzって言うと、どうも周波数みたいだな。
そういえば物理で「光の振動数ν[Hz] 」とか書いてあるけど、まぁ光の周波数と書いても意味は一緒やわな。
それはともかく、電機子起電力の計算に角速度が必要だと。
電機子起電力というのはモータが回転すると発生する起電力のこと。
角速度というと文字はωだな。単位はrad/sと。
そういえばこのωって文字よく交流回路の計算で使うんだよね。
周波数f[Hz]、実効値E[V]の正弦波交流電圧の瞬時値を、v=E√2 sin(2πft+θ)[V]と表すと。
それ自体はどうでもいいんだが、この2πf=ωと置くことが多い。
するとコイルとかコンデンサとかの入った回路の計算がわかりやすくなる。まぁそういうもんです。
それでこの一見意味不明なωのことを角周波数と言うと。まぁ角速度というと変だしね。
まぁよくわからん話だが、便利なので気にしない。まぁそれでωを見ると角周波数と言いたくなってしまうよねと。
しかし直流電動機の問題の中で「角周波数ω[rad/s] 」と書いてあるのはどうなんだろう…角速度だよね。


まぁ言葉の問題なんですけどね。
けどちょっと気になったのでね。
しかしこういうことってあるもんですね。注意せねば。

まぁやはりイヤホンは買えと

以前から散々言ってるが、松下電器産業他の社名がパナソニックやらに変わると。
ブランドも全部Panasonicに統一されると。
まぁPanasonicの炊飯器というのは何だろうかという疑問はあるけど、
きっとSDとか刺さるんですよ。嘘です。けどそんなイメージでかっこいいかもしれません。
しかし、NationalにせよPanasonicにせよ字体は同じなのであんまり変わった気がしないのでいいですね。
D-Snapは以前からPanasonicであったこともあって昨日の記事では全部Panasonicと書いたわけだな。
まぁしかし一番気になるのは未だに電池では唯一Nationalを維持してるマンガン電池がどうなるかですね。
多分アルカリ電池と同じデザインになると思うけど。けど今のNationalマークをPanasonicマークに変えただけだったら残念。


さて、昨日の記事には間違いがあった。
PanaSenseなどで取り扱ってるイヤホンにはノイズキャンセリング関係の機能はない。
なのであんまりよくはない。その後気付いたんだけどね。
さて、電話で聞くことにした。説明書にかいてある番号にかけた。あえて公衆電話。
すると、「うちは冷蔵庫などを取り扱ってる部門で、D-Snapなどは別の拠点なので番号を言うのでかけ直して欲しい」
というわけでかけ直し。けど電話代1分10円だったんだが、教えてもらった番号に3分10円なのである意味ありがたい。
さて、それで保証書に「保証期間 本体1年間」とあるがイヤホンなどはどうなのか聞いた。
どうも付属品の類はどれもその本体ではないと言う。
まぁ違う見解もあるかもしれないけど、それでトラブルになると困るので修理に出すのはあきらめた。
それで、念のため付属のイヤホンと同じイヤホンは買えるだろうかと聞けば、
「うちではどこでどの商品が買えるかは知らないので販売店に聞いて欲しい」
といわれた。まぁ安くないのはわかってるので、こちらもまぁいいかと。


さて、いろいろ考えたのだが、カナル型のイヤホンであれば雑音は無視できそうだと。
カナルとは外耳道を指す言葉だが、すなわち外耳道に挿して使うというイヤホン。
なかなか不気味だが最近では結構よく使われている。
D-Snapの付属イヤホンもそれで、実際ノイズキャンセリングを使う必要はほとんど無し。
そこでカナル型のイヤホンを高く評価していたわけだけどね。
まぁそれで電器屋で探したが、安いのがありましたね。1780円ですね。安いね。
メーカーはJVCと。まぁJVCとPanasonicばっかりですね。
僕はよくJVCというけど、日本ではむしろVictorでよく知られてますね。
日本ビクターはアメリカのビクタートーキングマシンの日本法人として作られたのだが、
そのビクタートーキングマシン自体はその後買収され、よくわからない。
まぁそれはともかく、その日本ビクターがVHSを作ったと。それで世界中で知られるようになったと。
それで日本以外では専らJVCというブランド名でやってるんだよね。
日本でもVictor/JVCと併記されてますよね。まぁ特にJVCと書く意味はないが、文字数の節約にはなるわな。
最近JVCで目立つのというとEverioかねぇ。HDD式のビデオカメラなんだけどね。おもしろいですよね。
そのJVCは松下グループなんだが、最近KENWOODと統合を進めていると。楽しみですね。


それで前から気になってたこと。
スピーカーの類にはエージングという処理をすると音質が向上すると。
エージングとは老化の意味。
工場出荷時の状態は不安定であるので、適当な方向である程度老化させると適当に安定すると。
どういうものなんでしょうね。確かなことは使い始めは音は安定しないということですね。
ただある程度安定すればいいわけですよ。確かに何十時間とエージングすればよい状態にはなるかもしれない。
けどそれは寿命を縮めてるんですよね。それは違うと言うかもしれないけど。
さて、具体的な方法だが、いろんな周波数を含んでいて、音量が安定している音を流せばいいと。
ピンクノイズを使って行うのが一般的ですね。
まぁ音質は向上しないかも知れないけど、安定すればそれでよしと考えればいいだろうかな。
普段使うときより少し大きめの音量で1時間ピンクノイズを流してみた。
何も変わった気はしない。が、まぁ心なし安定したような気もする。初めが肝心と考えるならまぁこれでOKかなと。
まぁしかし、普段音楽を聴いている内にも安定してくるものでしょう。それで十分。
実のところあまり気にしてないと言うことです。
それはともかく、このイヤホンやたら丸いな。おもしろいけどつかみ所のない形だなぁ…

表皮効果とか言うからイヤホンはもろいのかな

最近イヤホンの断線がひどい。
まぁ6ヶ月持てばまぁいい方かなというぐらい。
より線を使って断線対策はしてるんだろうけど、そもそも線は細いんだからねー。
PCで使ってるSONYのとD-Snapのが同時に断線してしまうと言う。
PCの方は左の耳付近、D-Snapの方はプラグ付近が怪しい。
D-Snapの方はどんどん悪化していってた気がする。以前からモニタモードが使えなかったし。
まぁPanasonicに相談してみるけど、いかんせん販売店が遠いのでめんどくさい。
しかも、保証が「本体1年間」となっていて、本体でなく付属品である専用イヤホンはどうであるのかは不明。
故障かな?のところにもイヤホンの故障は考慮されてないし。


まぁ困ったもんです。
ところで線が細いと言ったけど、これはきちんと理由があるんですね。
こういうイヤホンとかで使う線はリッツ線というものなんですよ。オーディオ関係ではよく使われているらしい。
細い線を絶縁して束ねて使うと。とにかく細い線。天寿を全うされたその手のケーブルがあったら分解するといい。
単線より折れに強そうだけど、細すぎるのも考え物だよね。
細いといいのかというと、いいんですね。
当然だけど音声信号は交流ですね。それも結構周波数は高い。まぁ60Hzとかより高いということね。
交流では表皮効果というものがあると。
電流が流れると磁界が出来ますよと。磁界はH=I/2πr[A/m]、距離に反比例すると。
均一に電流が流れていれば導線の中心付近は磁界が大きいと。まぁしかし直流電流を流してる分には何も問題なし。
ところが電流が変化すると、電磁誘導が発生する。
左から右に電流が流れていたのが増えた。すると磁束は増える。
自然は変化を嫌がると言うけれど、これもそうで磁束を減らそうとする。逆方向に電流を流したくなる。
すると右から左に電流が流れるように起電力が発生する。
まぁわりと簡単な理由ですね。
これが原因で中心付近は電流密度が下がって、表面付近に集中すると。
抵抗というのは断面積が狭くなると抵抗は大きくなるし、オームの法則を見ればわかるように流れる電流が増えると電圧降下も増える。
中心付近は誘導起電力の影響でまともに流れない、外側は電流が集中して電圧降下発生しまくり。
これこそ表皮効果。
表面積を増やせばこれは解決できると。だから絶縁した細い線を束ねると。なるほどね。
超伝導送電が難しい原因の1つに表皮効果があるみたいですね。まぁ冷却もそうだけど。
もっともその記事を読んだときは電磁気を勉強してなかった中学生の頃だったような気がするけど。
超伝導物質に電流をたくさん流すと超伝導じゃなくなる。というものらしい。
直流送電なら簡単だけど交流送電はその辺が難しい。これも細い線をたくさん用意することで解決してたはず。


まぁなんというか音響関係の機器というのは難しいものです。
多分この表皮効果対策をしないと都合が悪いんでしょう。
明らかに抵抗が増えますからねー。
ところでD-Snapのイヤホンは通販で買えます。PanaSenseはこういう商品もよく取り扱うところだし、
調べたらAmazonとかJoshinとかの通販でも買えるようになってる。まぁ在庫は少ないとか取り寄せとかだけど。
値段もさほど高くなくて3300円とか。
まぁさすがに安くはないけど、専用のもので、ノイズキャンセリングの片割れであることを考えれば良心的ですね。
外からの雑音がノイズキャンセリングなしでもある程度カットできてるのでいいと思うんだよね。
けどやはり安くないので、まぁ別に買うかも知れんね。
まぁその前にまずはPanasonicに質問することだ。もしかしたら簡単に交換してくれるかも知れない。
実はPanasonic(今はNational製品を作ってるかも知れないけど)の工場は行こうと思えばいけるところにあるし。
まぁその前に明日はテストだと。もちろんその辺はぬかりないけど。