体育のレポートを要件に従って書く
今日2つ技能教習を入れていたのだが、1回目の技能教習の後半で効果測定して第一段階の技能教習を終えた。
すなわち仮免許試験を受けられるようになったと言うこと。というわけで明日は仮免許試験だ。
というわけで2つ目の予約は消してもらって、おしまい。標準回数を3回越えての第一段階終了だった。
今日は体育のレポートを書いていた。
このレポートにはこんな要件がある。
ワープロの場合は、A4用紙を用い、1ページ30行、1行の文字数40字に設定する
というわけでこういう設定をしないといけない。めんどくさい話だ。
OOoではページ設定の行数と文字数で設定する。
ここで標準では1文字のサイズが18ptになっているが、これでは1行に40字も入らない。
そこで1文字のサイズを12ptぐらいに下げる。これなら40字入る。
こうすると罫線が見えるので、打ち込んでいく。すると1文字ずつ罫線の中に入っていく。
これで指定の文字数に出来るというわけだ。
ところで見出しなどで1文字のサイズよりも大きな字を書くとどうなるか。
その場合は複数のマスを使って1文字として表示される。そのため妙に間延びした字になる。
そうやってレポートをかりかり書いていった。
ところでこれはなんのためなのかという話ですが、このレポート、分量に制限がある。
400字原稿用紙で10枚以上20枚以下
ワープロの場合の要件だと、A4用紙1枚あたり400字詰め原稿用紙3枚ということになる。
僕はこのレポートでA4で5枚になったのだが、これは400字詰め原稿用紙15枚ぐらいに相当する。
そのためこの要件を満たしていることが一目でわかる。ということを意図しているらしい。
そんなレポートのネタですが、陸上競技の計測技術について調べた。1/100秒の闘いを支えている技術ですね。
ただ、調べてみると意外とローテクだよなとも思った。だってトルソーの位置を手動で決めてタイムを決めるんだし。
去年の冬休みにも同じようなレポートがあって、そのときは背泳ぎのバサロ泳法について考えてみた。
まぁそういうのが4・5年ではあるようで。
Author : hidemaro
Date : 2010/08/19(Thu) 23:00
コンピュータ | comments (0) | trackback (0)
録画してたらf4vという謎コンテナを手に入れた
高専カンファレンス in 奈良では例によってUstreamでの配信をしていたようだ。
最初はトラブルがあったのだが、最初の発表の途中からは正常に配信できていたよう。
果たしてどうだったのかはよくわからないけど。
その配信にはAdobe Flash Media Live EncoderとUstreamを組み合わせて使っていたようだ。
neue cc - UstreamでFlash Media Encoderを使って高画質配信するためのまとめ
ローカルでエンコードした物をUstreamにアップロードして、高画質配信ができるようになってるらしい。
今回の配信担当者がこういうのを見つけてがんばってたのだ。
さらにFlash Media Live Encoderにはローカルに保存する機能が付いている。
これを使ってローカルに保存すればネットワークの不調で配信がうまくいかなくても少なくともローカルにはあるから安心。
Ustreamの機能として録画機能があるけど、結局Ustreamのサーバーまで届かないと意味がないですからね。
さて、この機能で録画したファイルを今日取り出して見てみようと思った。
ファイルを開くとAdobe Media Playerで表示してくれる。と思ったら、なんかファイルが壊れてるとか言われる。
えーっと思ったが、どうも正しく読めていないだけのようでいろいろ調べてみた。
よく見てみると拡張子が見慣れない.f4vだった、
.f4vというのは、MP4コンテナに動画を入れたときに使われる.m4vという拡張子ととても似ている。
MP4コンテナを応用してFlash Videoに適するようにしたものらしい。
そしてH.264をVideoのコーデックに選択すると.f4vで出てくるらしい。
ちなみにVP6の場合は従来から知られている.flvで出てきます。この場合は大した問題はありません。
うーん、どうしたものかと思って調べたのだが、この形式に今のffmpegは対応しているらしい。
例えばこれに付いているffmpegは対応しているらしい。
ffmpegさえあれば、映像・音声のストリームはそのままにコンテナを移し替えることも簡単にできる。
ffmpeg -i in.f4v -vcodec copy -acodec copy out.mp4
in.f4vから映像・音声をそのままout.mp4に移すだけ。これで一気に取り扱いやすくなる。
もともと映像はH.264、音声はMP3でエンコードされているので、純然たるMP4コンテナに移せば特に問題ない。
まぁあんまりH.264とMP3の組み合わせは見ないのでうまくいかないこともあるかもしれないが、
ffmpeg -i in.flv -vcodec copy -an video.mp4 ffmpeg -i in.flv -acodec copy -vn audio.mp3
とか分ければいいだろう。
こういう操作がffmpegでは簡単にできてありがたい。
それにしてもなんで.f4vはよくあるMP4コンテナと同じように処理できないことが多かったのだろう。
どうも見てる感じではMP4コンテナであることにには違いないようだが、
普通は入ってないものがたくさん混ざっててそれで失敗しているように感じた。
それにしても自分のところのプレイヤーですらうまく再生できんってどういうことさ。
全く不便なものだ。
Author : hidemaro
Date : 2010/07/20(Tue) 23:59
コンピュータ | comments (0) | trackback (0)
ブートローダーを知っている人ができること
今日はVerilogでいろいろなものを書いてみてた。
論理合成の結果見るとおもしろいですね。
FPGAに載ってる加算回路やマルチプレクサを呼び出して使ったり使わなかったり。
賢いですなぁ。
今日、研究室でVerilogやってたら、クラスメイトがやってきた。
どうも彼の研究室のPCが立ち上がらんらしい。
行ってみると、「NTLDR is missing」と表示されて起動しない。
NTLDRに問題があるようだ。
Webで調べるとNTLDRがないという意味らしい。なんでだろうね。起動ディスクでとりあえず立ち上げて、NTLDRをコピーするという方法をよくとっていたが、
残念ながらそれはできない。というわけで修復コンソールで直すことに。
修復コンソールを起動して、こういう操作をする。
> cd C:\ > copy E:\i386\ntldr . > copy E:\i386\ntdetect.com . > copy E:\i386\bootfont.bin . > bootfix /rebuild
NTLDR関係のファイルを転送して、bootfixでboot.iniを生成する。
これで完了。無事起動するようになった。
しかし、これだけで済まなかった。その後、またやってきた。
今度はMBRがぶっ壊れたらしい。なんかいろいろあったらしい。
これも修復コンソールでなおす。
> fixmbr
これで、NTLDRを呼び出すように仕向けることはできたが、OSが壊れてたらしく結局無理だった。
こういうブートローダーまわりを理解している人は少ないようです。
OSが起動すると言うことは、BIOSがMBRを読み取ってブートローダーを呼び出して、これがOSを起動させるというのが実際です。
しかし、BIOSからOSまでの間になにが起きているか理解している人は少ないと。
まぁマルチブートとかやったことある人なら知ってるかもしれないが、そうでもなければ知らんで済むからね。
そんなのだから画面を見ても、何が起きてるかもわかってないというのが実情のようです。
この点においても理解が進めば解決すべきことがわかってくるんでしょうけどなかなか。
Author : hidemaro
Date : 2010/05/27(Thu) 23:59
コンピュータ | comments (0) | trackback (0)
大阪市営地下鉄でLOP!
大阪市営地下鉄で取り得る最長ルートはどんなルートかという問いはたいへん難しい。
まず、どんな形のルートかも予想も付かない。
JRの最長ルートなら、北海道から本州を経て九州へ至るルートという想像は付く。
近鉄にしても八木～中川は含むことぐらいはわかる。けど大阪の地下鉄はそうもいかない。
結局これこそ総当たりで当たるしかないことなんですね。
最長ルートを求めた先行事例としては葛西隆也さんらの求めたJRの最長片道きっぷが有名ですね。
ここではJRの最長片道きっぷのルートについて整数計画法および全探索で求めたことが書いてあります。
僕はソルバーなんて持ってないから全探索の方法を参考に求めてみようと思った。
ところがここには重大なことが書かれていた。
それは北海道から本州を経て九州へ至るルートが最長であるという仮定です。
どうもそうしないとやってられないらしい。まぁそれもそうだ。
これを使えば北海道区間は長万部からの最長ルート、九州区間は小倉からの最長ルートを考えればいいなどなる。
ところが、大阪の地下鉄は全くそういうことがわからない。なのでスタート地点はどこかわからないと。
はて、どうしたものか。というわけで話を戻すことにしました。
問題の分析の章で最長ルートにはLOPの三類型があると書いてある。
Lの場合は発駅・着駅ともに終端駅が最長のはずであるが、Pの場合はそうではないこともあるとある。
Pの場合は終端駅が発駅になる場合(Pe)と、分岐駅の1つ隣が発駅になる場合(Pn)があると書いてある。
だから千日前線しか通ってない鶴橋が最長ルートの発駅になることはあり得るんですね。
分岐駅である谷町九丁目の隣で今里の隣でもあるから。
ただ、JRの最長ルートを全探索で求めるときには分岐駅の1つ隣が発駅になることを考えて求めることはやらなかったわけです。
しかし今回は一応考えないとまずいかなと思った。
というわけで路線を定義していく。
分岐駅とその隣の駅で区切って、区切られたそれぞれの区間の距離を入力していく。
梅田,淀屋橋,13
0.1kmを1とする単位で距離は入力していった。
西梅田・梅田・東梅田はそれぞれ別々の駅として書いて、西梅田・梅田間、梅田・東梅田間をそれぞれ0kmの線路で結んでおいた。
そうやって区切っても73個で済んだ。
ここから駅名を読み取って、登録されてなかった駅名だけ登録して、それでそれぞれの区間を読み込んで、それから全探索するプログラムを書いた。
全探索の方法はJRの方法と一緒ですね。二度同じ駅を通るか終点にたどり着いたら終わりってルールね。
初めこれをPerlで書いてたのだがどうにも遅いのでC++で書き直した。
それで登録された駅全てからの最長ルートを求め、その中で最長のルートを答えにした。
それで求まった答えだが、LOPでいえばLだった。
なかもず―(御堂筋線)→天王寺―(谷町線)→谷町九丁目―(千日前線)→今里―(今里筋線)→緑橋―(中央線)→森ノ宮―(長堀鶴見緑地線)→蒲生四丁目―(今里筋線)→太子橋今市―(谷町線)→谷町六丁目―(長堀鶴見緑地線)→長堀橋―(堺筋線)→動物園前―(御堂筋線)→大国町―(四つ橋線)→住之江公園―(ニュートラム)→コスモスクエア―(中央線)→阿波座―(千日前線)→なんば―(御堂筋線)→江坂
結局のところなかもず～江坂という御堂筋線を縦断すれば済むようなルートが出てきた。
距離で言うと78.9kmです。これは営業キロで実際の距離は違ったりするらしいのけどささいな問題よね。
ちなみにL型ならその特性上逆に乗っても片道きっぷにはなることができるので江坂からなかもずのルートでもいいですね。
それを路線図で表してみた。(元とした路線図 : 大阪市営地下鉄・ニュートラム路線図 (大阪市交通局))
大阪市営地下鉄最長ルート
大国町となんばとか谷町六丁目と谷町九丁目とか隣の駅であるところをぐるっと回ってるなというのがよくわかる。
乗ってみたいと思った人もいるかも知れない。
そのためには運賃が必要ですね。
運賃は江坂～なかもずの運賃でOKです。最短距離で計算した運賃で遠回りしてもOKのようです。
具体的には360円で済みますね。
ついでに北大阪急行の最長ルートにも挑戦してはいかがでしょうか。
江坂から千里中央までの一本道ですね。たった120円で済みます。あわせて480円ですね。
御堂筋線に乗って終点まで乗るだけで達成できますね!
しかしまぁ、こういうのはコンピュータで計算してみないとなかなかわからんもんです。
初めはO型になるんじゃないかとか思ってたんですけど、結局の所L型になりましたからね。
計算してみて初めてわかったことですね。
Author : hidemaro
Date : 2010/03/11(Thu) 23:59
コンピュータ | comments (0) | trackback (0)
バイノーラル録音という衝撃の技術
映画館に行くと、大量のスピーカーが貼り付けられている。
いろんな場所で音を鳴らして、実際に音の配置に近づけようと言うことだろう。
けどよく考えて欲しい。人間の耳の穴は高々2つしかない。
というわけでバイノーラル録音ってのが世の中にはある。
百聞は一見にしかず、というので聞いてもらおう。ん?なんかおかしい。
これをヘッドフォンで聴くといい。スピーカーで聴くと効果は見えない。
不思議なものだが、どこで音が鳴っているかというのが見えてくる。
これこそがバイノーラル録音である。
理屈はけっこう簡単で、頭の形をしてて耳の穴にマイクが入ってるダミーヘッドでもって録音するだけです。
そこに人間を置いて、その人間の耳で聴くのと同じように録音して、その音を耳に聴かせればよいと。
そういうわりと簡単な仕掛けです。これはおもしろい。
頭の形をしたもので録音するので気味が悪いですが、まぁそれは仕方ない。
ちなみに人間の耳にマイクを付けて、それで録音することも出来るようです。当たり前ですが。
なんでこんなことを話題にしたのかというと、以前とあるところでバイノーラル録音のサンプルがあったんですよ。
これはなんなんだろうと思って聴いてみた。そしたら驚いた。
初め、イヤホンを片方しか付けてなかったのだが、何かおかしいと思って両耳付けたら、いやすごかった。
こんな風に立体的な音を作れるんだなと大変驚きました。
仕組みを調べてみると案外簡単だなと思ったものです。
ただ、イヤホンで聴かない限り使い物にならないので、使用できる用途は案外限られるのかも知れませんね。
確実にイヤホンで聴く用途でない限り使えんということだからな。ドラマCDなら使いようもあるか。
Author : hidemaro
Date : 2010/02/09(Tue) 23:58
コンピュータ | comments (0) | trackback (0)
電車でレポートを書くライフハック
昨日・今日と電車でレポートを書いている。
レポートを書いているとは言うけど、それはノートPCで書いてる。例によってdv2ですね。
僕は通学時間が結構長いんですね。そのうち電車の時間は1時間。結構な時間です。
ただ、活用の仕方に悩む時間でもあります。
そりゃ小説読んだりネットラジオをまとめ聞きしたり、そういうことには容易に使えますけど。
そこに日常生活の中で時間を食うレポートというのを入れられるとなればうれしいですね。
dv2はバッテリーは3時間持つから、1時間ぐらいはどうってことはない。
持ち歩くときはスリープ状態にしておけば復帰など速くて便利。
電車で作業するのは座席に座れるのが前提だな。
数学の問題を立ちながら解いたことはあるが、さすがに立ちながらノートPCをカタカタやる気は起きない。
座れれば膝の上にノートPCを広げて作業すればよいと。
ただ、膝の上しか自由に使えないので不便なこともある。
例えば実験データを横に置いて作業できないね。左手にデータを持って、右手で打つとかしないといかん。
それとマウスの便も悪い。光学式なもんで。キャリーケースの内面をマウスパッド代わりに使っている。
ただ、少々問題があって座れないと作業が出来ないんですね。
そのためには混んでない電車を選ばないといけない。ちょっとここで工夫するわけです。
例えば、急行ではなくそれより遅く出て途中で追い越される各停に乗るとか。そっちの方が空いてる。
それでも乗換の便などが変わらないのなら問題ないですよねって。
あと各停だと乗ってる時間が長い、すなわちは作業できる時間も長く取れるからいいですよね。
まぁ待合室でノートPC開いて作業してもいいんですけどね。
そんなことをやってたら2日間でレポートの7割ぐらいが完成してしまった。
ここまで効果絶大だとは思わなかった。
元々、放課後のゆとりを使ってレポートを書くために買ったものですが、こんなところで役に立つとはね。
いやはや、おかげで早くレポートが完成しそうです。
Author : hidemaro
Date : 2010/01/20(Wed) 23:31
コンピュータ | comments (0) | trackback (0)
HDDを入れ替えてみる
今使ってるHDDって長いこと使ってるよねって。
詳しく調べたら2006年11月購入、ただすぐには使用を開始せず、2007年5月の入れ替えからシステムに使っている。
なので高々2年半しか使っていないのですが、やはり思うところもあるわけです。
2006年7月にAthlon 64を採用したPCを作りました。
このときSATAが使えるので、これからはSATAだと購入したわけです。
当時はWindows Vistaの発売が噂されていたときで、VistaになればSATAにしようと言っていたわけだが、
どうにもVista導入する気にはならず、SATAのHDDだけが放置されていたと。
まぁ放置していたんじゃなくてデータ領域に使っていたんだけど。
ただ、PATAのHDDの容量がやや少なかったし、2007年5月の故障後の修理のときに変えました。
このときにAthlon 64からAthlon 64 X2(当時)にCPUが変わったわけです。
その後に電源が壊れて、メモリを1GBから2GBに増やして、メモリが壊れて、メモリを3GBに増やして現在に至ると。
2008年9月のメモリ故障のときに早とちりして再インストールしたことがあります。
普通再インストールというとフォーマットしてとやるのだが、それはどうにも具合が悪かった。
というのもデータを待避させるHDDがなかったから。なので随分苦労して再インストールした覚えがある。
そのときの問題だったのか、なんか消えないフォルダとか開けないフォルダとかというのが出来てしまったわけです。
それからもごまかして使っていたのだがどうにも気持ち悪い。
SATAのHDDは家に1つしかなかった。今は増えたけど予備があるわけでもない。
だから予備が欲しいというのとそのHDDが論理的におかしいからフォーマットしたいという希望があって、
そういうことをできるようにするためには新しいHDDが必要だったと。
というわけで日本橋界隈で見ていると250GBも320GBも500GBも値段はさほど変わらず5千円弱のようだ。
せっかくなので500GBのを購入することに。
帰宅して元のディスクを抜いて新しいディスクにWindows XPをインストール。
もうSATAへのインストールも慣れたもんで、事前にディスクを用意してF6でドライバを読み込ませるようにした。
こうやって無事インストールできた。
いろいろやって日曜日の夜には一応完成しました。
あまり使わないソフトウエアはインストールしなくしたり、
フリーウエアの一部を流行を読んで変えてみたりということもやりました。
一応は元のディスクからも無事にコピーできたかなと思っています。
まぁまた頃合いを見計らってフォーマットしてしまおうと思います。
フォーマットしてもこれといった使い道はないんだがな。バックアップに使うぐらいか。
Author : hidemaro
Date : 2009/11/16(Mon) 23:57
コンピュータ | comments (0) | trackback (0)
どっちもいまいちTuple、どっちも便利Tuple
そういえばC#ってジェネリックメソッドに型推論機能あったんですね。
知らんかったんですが、これでできることは多そうですね。
ということが実はSystem.Tuple.Create<>()だったりするわけですが。
C++は可変長テンプレート引数がきっかけとなってboost::tupleが標準ライブラリに編入。
.NET FrameworkではF#の導入に際してSystem.Tuple<>が導入されることになりました。
ということでこれは注目するべき事であるという話になるわけです。
そもそもタプルとは何かというと、型の違ういくつかのオブジェクトを投げ込む固定長のコンテナですね。
例えば、int・int・doubleの組を表すデータ構造が欲しかったとき。
Cではいちいち構造体を自作していた。
struct mystruct{
int x; int y; double z;
};
struct mystruct a={10,3,3.3}; //POD式初期化Perl・Rubyではハッシュリストを使うのが普通かな。a={:x=>10 , :y=>3 , :z=>3.3 } //Rubyハッシュ使うとかチートっぽいけどね。まぁRubyだとこういうことは配列かハッシュでやるというのが相場ですかね。
しかしPythonにはタプルという仕組みがある。
a=(10,3,3.3)なお、Pythonのタプルは一度作ったら変更できないというのが特徴ですね。
x=a[0]
なので安心してハッシュの添字にできるというのがウリ。
まぁ、Pythonのタプルは基本的には配列と一緒ですわ。
そういう意味で言うとPerl・Ruby・Pythonいずれも配列か何かでそれは実現できると。
しかしC++にせよC#にせよそういうわけにはいかないんですね。
なぜならば型というシステムがあるから。
RubyではFixnumもStringもArrayも同じ変数に入れられる。そして実行するときにそれが何があるか判定する。
けどC++もC#も、コンパイル時にこの変数はこの型のオブジェクトだと決めておくわけですね。
それでコンパイル時にかなりのことがわかるのでエラーが減って便利ですねと。
C# 4.0からはdynamicもあるけど、あれは例外だ。
というわけで型データの飛ばないことが重要だと。
タプルではないけれどC++にはstd::pairってのがありますね。あれは2個だけだが。
firstとsecondというフィールドがあります。まぁこの辺はC++でSTLといろいろやっていれば理解していると思います。
それを何個もにしたいということでboost::tupleとして導入されました。
その実装からして10変数までですね。まぁそれでもたいしたもんです。
そしてC++0xでは可変長引数テンプレートがあるので、無限にいけるはずだと。
可変長引数の使えるGCC4でコンパイル。
#include <iostream>なんで全部intやねんとか言わんといてね。実験のために適当にやっただけなんです。
#include <tuple>
int main(void){
std::tuple<int,int,int,int,int,int,int,int,int,int,int,int> a(1,2,3,4,5,6,7,8,9,10,11,12);
//auto a=std::make_tuple(1,2,3,4,5,6,7,8,9,10,11,12);
std::get<2>(a)=100;
std::cout << std::get<2>(a) << std::endl;
}
なんかすごいめんどくさい書き方していますが、今のGCCでは無理だが、最終的には//で消したとおりのやり方で行ける。
さて、タプルから要素を取り出す方法がちょっと変な感じですね。
補助関数std::get<N>()を使います。補助関数がいるというのが何とも言えないところです。
多分Nが変われば型が変わるからでしょうねぇ。
なお、C++では値は変更できます。それはまずいと思うのならconstつければOKです。
auto使ってたらどうするか? const autoにすればOKです。
C#のSystem.Tupleは可変長型引数とかないので、7個以下のオブジェクトを収めることしかできない設計です。
それでいいんかいという話だが、まぁその辺はちゃんと考えがあるわけです。
存在するSystem.Tupleのクラス(静的クラスは除く)は
System.Tuple<T1>
System.Tuple<T1,T2>
System.Tuple<T1,T2,T3>
System.Tuple<T1,T2,T3,T4>
System.Tuple<T1,T2,T3,T4,T5>
System.Tuple<T1,T2,T3,T4,T5,T6>
System.Tuple<T1,T2,T3,T4,T5,T6,T7>
System.Tuple<T1,T2,T3,T4,T5,T6,T7,TRest>
驚いたことが2つある。こいつら抽象クラスとか継承していないわけですよ。
だからこれらのTupleのクラスは兄弟クラスですらないわけです。
もう1つですが、8つ目のクラスはTRestというのがあります。これはTupleの型を書くらしい。
一体どうやって使うのかということ。
実際の使い方ですがこんな風にします。
var t1=System.Tuple.Create('a',10);
System.Console.WriteLine("{0}x{1}",t1.Item1,t1.Item2);
var t2=System.Tuple.Create(1,2,3,4,5,6,7,System.Tuple.Create(8,9,10,11,12));
System.Console.WriteLine(t2.Rest.Item2);まず、基本の使い方ですが、これも補助メソッドで作って型推論で受けるのがおすすめです。ジェネリックメソッドに型推論機能があることが分かったので安心して使えますね。
要素はItem1とかいう風なプロパティで取り出せます。簡潔でよろしい。
さて、8つ以上の要素を持つためにはどうするかというと、初め7つを投げ込んで、それ以降はそれでタプルにするという方法を取ります。
そのためのSystem.Tuple<T1,T2,T3,T4,T5,T6,T7,TRest>です。
とはいえ、これも作るのは補助メソッドで作って型推論で受けるのがおすすめ。
ここではintが12要素あるタプルを作っています。
しかし面白くないのはこの仕組みを使っても8つ目以上の要素を取り出すにはRestの何番目とやらないといけない。
だからここでは9番目を取り出しているのだが、わかりにくいですね。
というかこれなら8要素のTuple作って、使い方の提案としてこういう使い方を書けば良かったのに。
8要素Tuple作りたい人も7要素+Restに1要素Tuple入れて使わなきゃならんとかどうよ。
あと型名もずいぶん長くなってしまいます。型推論の導き出した型名は
System.Tuple<System.Int32,System.Int32,System.Int32,System.Int32,System.Int32,System.Int32,System.Int32,System.Tuple<System.Int32,System.Int32,System.Int32,System.Int32,System.Int32>>
とかいう長すぎる型名。var便利ですね。
ちなみに、C# 3.0ですでにタプルは存在したという意見もあります。それ匿名クラスね。
しかし匿名なので使い道が限られる。返り値にできないですからね。
あといちいちクラスを生成するのはどうよというのもある。
というわけでやっぱタプルちゃうわというのが普通の考えだと思います。
やっぱりタプルの使い道って返り値だと思いますから。そのための選択肢ができたのはよろしい。
.NETのは2～7要素の品質はかなりいいですから便利に使えると思います。
C++のそれも決して悪くはありません。ちょっと混乱するところではあるけどね。
ああ、もちろん返り値の型名は型推論は使えないのでちゃんと書いてね。
けど受ける方は型推論でOKなので活用しちゃって下さい。
Author : hidemaro
Date : 2009/08/22(Sat) 22:22
コンピュータ | comments (0) | trackback (0)
半分を作るチキンレース
といわれてどうやって求めるかというのはなかなか難しい。
多分総当たりしかありません。が、少しは賢いやり方を考えてみましょう。
幸い数は少ないので、8個程度かなと。それならいくら頭が悪くても28回試せば終わりですよね。
まずかならず半分超えない組を選ぶことにしよう。
(0,1,2,3)とそれ以外と、(4,5,6,7)とそれ以外は同じ意味ですからね。
今までの結果でもっとも優秀な結果は誤差なんぼだというのがわかってれば、
半分-誤差だけ積むことは絶対に出来ないならばそこからさき計算する意義はない。
なので残り全部積んだら何個かというリストを作って利用する。
チキンレースみたいですね。まぁこういうのもよろしいでしょう。
Perlで作ってみた。
my @list=(10, 7, 17, 8, 4, 1, 16, 2);まずリストを降順にならべる。が、元のリストを崩さないように添字で並び替える。
my @idxs=sort{$list[$b]<=>$list[$a]}(0..$#list);
my @rlist=();
my $sum=0;
for(reverse @idxs){ unshift(@rlist,$sum); $sum+=$list[$_]; }
my $best=0;
sub half{
my ($ii,$s)=@_;
if($ii==@list){
if($s>$best){ $best=$s; return ($s); }
else { return (); }
}
my ($ii,$s) = @_;
my $i=$idxs[$ii];
my @r0; my @r1;
@r1=half($ii+1,$s+$list[$i]) if $s+$list[$i]<=$sum/2;
@r0=half($ii+1,$s) if $s+$rlist[$ii]>$best;
return @r0 if @r0;
return (@r1,$i) if @r1;
return ();
}
my @result=half(0,0);
print "$result[0] / $sum\n";
print "$_," for @result[1..$#result];
そしてこれを後ろから足していって、自分より後ろに何個の数があるかというリストを作る。
この場合は(48,32,22,14,7,3,1,0)ってリストができます。
これを使ってさっきの条件を満たすように半分以下でもっとも半分に近くなる組み合わせを再帰的に作ると。
最後まで条件を満たしたままたどりついた組み合わせがいままでの最高記録よりいいかチェックして、
それを満たすならリストを返すが、そうじゃなければ空リストを返す。
なのでhalfはそれまでの最高記録よりも悪い記録は絶対に返さないと。
そうやって求めています。
この関数の呼び出し回数ですが、調べると高々22回で済んでいます。
とはいえ、いくらこの仕組みでも数が増えればかなり悪くなってきますね。
50個のランダムなリストを作ってやると1446047回も呼び出されていた。
結構時間がかかる。
とはいえ、総当たりすると250=1.126×15回もしないといけないはずなのでかなり効率はいいか。
Author : hidemaro
Date : 2009/08/04(Tue) 23:34
コンピュータ | comments (0) | trackback (0)
役に立ちそうで役に立たないけど時々役立つフローチャート
何がめんどくさいのかといえばフローチャートを書くのがですね。
僕はOpenOffice.org DrawをWriterのドキュメントに埋め込んで書いている。
Drawにはそのためのパーツが充実しているからですね。
まぁこれで課題はできますよと。
それで何を書くかということだ。
たとえばLEDを1個光らせるプログラムのフローチャートとか書こうとしても困ると。
だってLEDを点灯させるぐらいしかやることないから。
やることが1つしかないなら書いてもしゃあないなぁって。
あと枝分かれも何にもなくて一直線に連なってるだけのも残念ですね。
まぁしかし書かないとだめなんだからしょうがない。
しかしフローチャートってプログラム作るときに使ってるんかと思ったのだが、どうも最近は使ってないらしい。
確かにフローチャートで全体の流れをつかんでこんなものを用意しないとなとか考えられるけどね。
だから全く使ってないわけではないはず。だが積極的に使ってるという話も聞かない。
まぁしかしオブジェクト指向プログラミングとかされたら訳分からんからね。
あとデータ構造をうまく表せないとか。
UMLとかそういうことをするために使う道具ですよね。
方法はどうであれどんなことをしないといけないか考えてやらんといかんと。
細切れにしてやれば作るのは楽になるのでこれでうまくいくと。
まぁとはいえ、フローチャートはなにをしているかわかりやすいですねというのは確か。
なので物事の説明にはよく使われています。
どんなものを作ったのか説明せよというときにはちょうどいいと。
実にレポートとかプレゼンテーション向けの道具のようです。
まぁ開発よりもそっちのほうが役に立ちますねなんて話も結構ある。
というわけでぼちぼち書いていきましょう。
Author : hidemaro
Date : 2009/06/26(Fri) 23:15
コンピュータ | comments (0) | trackback (0)