Rのdeparse
Rのオブジェクトをファイルに保存する方法を考えていたのだが、deparse()を使うと良いようだ。
d<-list(1, 2, c(1, 2, 3)) deparse(d)
とすると、そのまま"list(1, 2, c(1, 2, 3))“となる。つまり、この頭に"d<-“をつければ、そのオブジェクトを作るコードが保存できることになる。なるほど。
Rのdeparse
Rのオブジェクトをファイルに保存する方法を考えていたのだが、deparse()を使うと良いようだ。
d<-list(1, 2, c(1, 2, 3)) deparse(d)
とすると、そのまま"list(1, 2, c(1, 2, 3))“となる。つまり、この頭に"d<-“をつければ、そのオブジェクトを作るコードが保存できることになる。なるほど。
ベクトルとスカラー、リストとデータフレームの違い
Rはグラフソフトとして使っていて、これまで言語としてとらえていなかった。また、一貫して勉強したことが無いので、その言語の特徴をいまいち理解していない。しかし、くせはあって組みにくいけど、なかなかおもしろい言語のように思えてきたので、少しずつ勉強していけたらと考えている。
Rには様々なオブジェクトがあるが、どれだけの種類があるのだろう。オブジェクトの種類は、typeof()で調べることができる。
Rのオブジェクトにベクトルがあるが、これにはさらに五つの型があって、異なる型のデータを入れることはできない。つまり、c(1,“2”)とはできない。実は、スカラーもベクトルと考えているようだ。‘1’[1]としたら"1"が返ってきたし、“1”==c(“1”)はTRUEとなる。
異なる型を配列にできるオブジェクトとしては、リストがある。また、それぞれの要素には成分名をつけることができるので、連想配列のように使うこともできる。例えば、d<-list(a=1,b=2)としておけば、d[[1]]でも良いが、d$aでもアクセスできる。ファイルからデータを読み込むときにつくるデータフレームにアクセスの仕方が似ていると思って、試しにデータフレームをtypeof()で調べてみたら、listとなった。つまり、データフレームはリストだったようだ。しかし、d<-list(a=c(1,2),b=3)とすると、d$bは当然3になるが、d<-data.frame(a=c(1,2),b=3)とすると、d$bはc(3,3)となる。厳密には多少違うようだ。
まだまだ勉強する必要がありそうだ。
Rの環境
Rでグラフを書きながら、測定の様子を観察していると、待っているときに、Rで楽にグラフが書けるようにRをいろいろといじってしまう。言語としてのRは、それなりに興味深い仕様になっている。
関数を定義すると、その中で定義された変数はローカルになる。しかし、外の変数を読むこともできるので、その変数がどの変数なのかが分からなくなってしまう。変数をすべてグローバルにしてしまえば、ややこしくはなくなるが、どうしても変数名が重複する可能性が出てくるので、変数はローカルであるべきだ。
次のような例を考えてみよう。
x<-1 test<-function(){ cat(x) x<-2 cat(x) } test() cat(x)
この実行結果は121となる。testという関数が呼ばれて、最初にxを見ると、関数の外で定義されたxの値となり、関数の中で代入するとその値になる。そして関数の外で見ると、元の値になっている。つまり、関数の中の一個目と二個目のxは別のxになっているのである。
こうなってくると、関数から外の変数の値が見えるのが、便利なのか不便なのかが分からなくなってくる。
このような場合には、関数内だけの環境を作って、その環境を指定して変数に代入したり呼び出したりすればよい。長くなるけど、こんな感じになる。
x<-1 test<-function(){ cat(x) testenv<-new.env() assign("x",2,env=testenv) cat(get("x",env=testenv)) } test() cat(x)これで、xの意味合いがはっきりとする。しかもtempenvは関数の中のローカル変数なので、外からは見えない。でも、面倒だな。
液晶ディスプレイの修理
本日、ある人から、液晶の割れたディスプレイを頂いた。これで、手元にある故障している液晶ディスプレイが三台となった。通常、壊れたものが三つあれば、うまく組み合わせれば、二つぐらいはうまく動くものが作れる。というわけで、部品を入れ替えて、ディスプレイの復活を試みた。
割れた液晶パネルを、別の液晶パネルと入れ替えれば、とりあえず一台は復活するはずである。しかし、そう単純では無かった。一台はbenq、一台はSharpで、もう一つはIODATAと、三つともかなり違うメーカーのものだった。液晶パネルの大きさが微妙に違うのである。どれも同じ19インチだったので、共通の規格だろうと思っていたら、縦横と厚さも違っていて、うまくいかない。それならばと、液晶パネルを分解して、最前面の液晶板だけを入れ替えようとしたが、これも厚さの違いによって挫折。最終的には液晶パネルと筐体の間にできた隙間にスペーサーをつめて、強引に組み立てた。なんとか一台は復活したが、納得がいかないやり方になってしまった。
最後の一台の部品も流用できないかも検討したのだが、これはまた規格が違っていた。通常は上部にあるコネクタが下部にあり、さらに陰極管のコネクタも他のものとは違っている。互換性という意味では、他のパネルとは入れ替えることができない。
三台から二台を復活させるつもりだったが、中途半端な一台だけしか復活させることができなかった。微妙に敗退感がある。
Rでファイルの読み込み
グラフを書くときに使っているRだが、プログラム言語としてもそれなりに使える。統計的な計算を含んだ簡単なプログラムの場合には、別の言語でその統計処理のルーチンを書くよりも、Rに元からある関数を使う方が早い場合がある。
しかし、Rの目的は通常のプログラムを作ることではないので、他の言語では簡単にできることが、Rではどのようにしたら良いのか分からない場合もある。その一つがファイルからのデータの読み込みである。data frameにデータを取り込む場合には、read.tableを使ってやっているが、通常の文章などのファイルを読み込む方法がこれまで分からなかった。もしあるとすれば、readなんとかという関数だろうと思って、help.search("read")としてみると、readLinesというのがあって、ファイルの内容を行単位で読み取ることができる関数を見つけた。Rではもっといろいろなことができるのだろうが、良いリファレンスマニュアルは無いのかな。
Rubyではこのmethodを使えば良いということが分かっても、それと同じことをするRの関数が分からないとプログラムを書くのに四苦八苦してしまう。試しに、文字列操作の関数のRubyとRの対応表をつくってみよう。
R | Ruby |
paste(x,y,sep="") | x+y or a.join("") |
substr(x,start,stop) | x[start..stop] |
sub(pattern,replacement,x) | x.sub(pattern,replacement) |
gsub(pattern,replacement,x) | x.gsub(pattern,replacement) |
strsplit(x,split) | x.split(split) |
2010/8/31追記 rubyのa.join("")に対応するのは、Rのpaste(a,collapse="")かもしれない。
ちょいパソ
久しぶりにパソコン工房のhomepageを見ていたら、「ちょいパソ」というものを見つけた。ARM9を搭載して、600gで一万五千円程度である。ディスプレイは七インチで800*480とまあまあである。また、USBポートもある。非常に魅力的に感じたか、致命的なのがOSで、WindowsCEである。これをlinuxかBSDで動かすことができれば、買いなのだが、少し検索したところ、まだ情報はあまり無いようである。いずれはだれかがやってくれるだろうが、それまでは待ちかな。
以前、mobile gearIIにNetBSDを入れてしばらく使っていたが、emacsなどを立ち上げると、かなり遅く感じた。最近はめっきり使っていないが、まだ可愛いので捨てるのを躊躇している。sharpのNetWalkerZ1が出たときには、linuxだったので、良かったのだが、キーボードの評判が良く無かったので、見送った。しかし、次に出たT1では、キーボードが改良されるのではなく、無くなってしまったので、購入候補からは完全に外れてしまった。ちょいパソの今後に期待できると良いのだが。
AVRでCNC
必要な小型の部品が必要なときに、ちっちゃなNCフライスを使っている。最近は酷使しているので、いつか壊れないか心配している。しかし、市販のものはそれなりに高価である。しかし、ミニフライスにステッピングモーターを取り付けて、それをPCから制御するようなCNCフライスなら、結構安く手に入るらしい。
そこで、いろいろと調べてみたら、専用のソフトを使ってPCのパラレルポートでパルスを作り、それをモータのドライバーに入力している。パラレルポートは、今後姿を消す可能性が高いし、PCでパルスを作っていると、別のタスクが走ると、速度が変化する可能性がある。PCは1ms以下の時計を持っていないので、それ以下の時間制御は苦手で、おそらく空のループを回して時間を制御しているのだろう。そう考えると、PCから座標などのデータを送って、マイコンでパルスを作るようにした方が理想的である。というわけで、AVRでNCを制御する時の問題点を考えてみた。
まずx軸とy軸の同時移動である。直線的に動くためには、x軸とy軸にパルスをどのようなタイミングで送るかを決めなければならない。これは以下のようにすれば良い。それぞれの軸方向にdx,dyだけ動かすとして、dx>=dyとする。このとき、常にx軸にはパルスを送る。x軸にパルスを送るときに、変数にdyを加算し、もしそれがdxの値以上だったら同時にy軸にパルスを送り、dxを減算するということを繰り返す。すると、x軸にdx回パルスを送ったときに、y軸にdy回のパルスを送ることができる。
次に問題なのが、加速と減速時のパルス間隔をどのように決めるかである。加速度を指定したときには、どのようにパルス間隔を変化させれば良いかを、適当に数式をいじって導いた。加速度をa、一つのパルスで動く距離をdとすると、最初のパルス間隔をw0は、sqrt(d/q)となる。現在のパルス間隔w(i)に対して、w(i+1)/w(i)=w0**2/(w(i)2+w02)とすれば良いようだということが分かった。このパルス間隔の割合の数列をあらかじめAVRのFlashに記録しておき、それを用いてパルス間隔を変化させていけば良いだろう。
まだ検討中の課題としては、バックラッシュをどのように処理するかとか、円弧を描くときにはどうするか、などがある。
AVRとCNCで検索をかけると、AVR-CNCというのがすでにあるらしい。同じようなことを考える人はいるものだ。不完全な日本語のページもあったが、機械翻訳がひどかったので、日本語訳を投稿しておいた。いつか採用されるかな。AVR-CNCに関しては、いつかdownloadして、どうゆうものか調べてみよう。
2010/8/20追記 AVR-CNCを読んでみた。まず、PC側のソフトはWindows用だった。AVR側では、加速などは行わず、いきなり特定の速度で軸を動かすようになっていた。直線補間は、先に書いたようなことをx,y,zの三つの軸で行っている。さらに円弧補間もあったが、math.hを使っていたので、tinyでは難しいだろう。バックラッシュの処理はおそらくPC側で行っているのか、AVRのソースには見当たらなかった。
括弧付きの化学式の処理
scanはこれまであまり使ったことが無いmethodだったが、なかなか便利そうである。これを使えば、括弧付きの化学式を簡単に扱えるのではと思って、scriptを書いてみた。
def bracket(fml) while fml=~/^(.*)\(([^\)]*)\)([\d\.]*)(.*)$/ head=$1 inside=$2 number=$3.to_f tail=$4 inside.scan((/([A-Z][a-z]?)([\d\.]*)/)){|s| s[1]=1 if s[1]=="" head+=s[0]+(s[1].to_f*number).to_s } fml=head+tail end fml end
括弧の中を、その後に続く数倍して、括弧を取り除くことができる。これを式量計算のスクリプトで処理すれば、括弧付きの化学式でも、式量を計算できることになる。
古いscriptのバグ
かなり前に書いた、windows用のgpibをrubyから使うためのscriptにバグを発見した。自分のhomepageに載っているものを見ていたら、何か変だと思ったら、バグだった。ibwaitというほとんど使っていないメソッドだったので、これまで気がつかなかったし、それほど大きな問題にならないだろうが、一応訂正しておいた。
このプログラムは、いつ頃書いたのか忘れたが、おそらく2003年ぐらいだったと思う。それまで、計測用のプログラムは、LabView, VisualBasic, IgorProなど、いくつかの言語で書いていたが、いずれも苦痛だった。そこで、rubyで計測用のプログラムを書こうと思い立ち、windowsのrubyからGPIBを使う方法を調べた。ある掲示板には田鎖さんという方が、そんなことをやっていたという形跡は見つかったのだが、よく分からない。それなら自分で書いてしまえということで作ったのです。C言語の使用例などはあったので、Win32APIを使えばあっけなく動きました。Win32APIの使い方もよく理解していなかったのだが。その後、windowsでしばらく計測をしていたが、今ではlinuxに移行したので、私自身はこのscriptはほとんど使わなくなってしまった。その代わりに、田鎖さんのruby-gpibを利用させて頂いている。
ところが、最近の市販の測定システムのほとんどがwindows上で動いている。windowsは、セキュリティー上で問題になるばかりでなく、測定中に再起動しようとしたりしていろいろと面倒なのだが、そのような流れになってしまっている。このような装置を自分でGPIBから制御するときには、windows用のGPIBが役に立つ。
さて、linux上で測定をしている人はwindowsほどは多くないようで、なかなか情報交換の機会が無い。そのため、それぞれ独自の手法を取ることが多いように感じられる。私は、ruby+ruby-gpib+Tkで測定をしている。Tkはくせがあってあまり好きではないが、GUIを作る時にはある程度の苦痛は我慢するしかないだろう。
rubyで式量計算
私は、データ処理の大部分にrubyを使っている。物質を扱っていると、式量を計算する必要が出てくることがあるが、これもrubyで計算している。具体的には、formula.datに元素記号と原子量のデータを入れておいて、化学式の中に含まれる、元素記号と数字を読み取って、原子量と数をかけて足している。かなり前に書いたスクリプトがこれである。
def fmlwt(fml) awt={} IO::foreach("formula.dat") do |l| awt[$1]=$2.to_f if l=~/([A-Z][a-z]?)\s+([\d\.]*)/ end fw=0 while fml.size>0 break unless m=/([A-Z][a-z]?)([\d\.]*)/.match(fml) aw=awt[m[1]] an=(m[2]=="")?1:m[2].to_f fw+=an*aw fml=m.post_match end fw=1 if fw==0 return fw end
原子量のデータを一行ずつ読んで、hashに記録して、その後で化学式を一元素ごとに正規表現でマッチして処理している。しかし、かなり長い気がする。そこで、久しぶりに書き直してみた。まず、書いたのがこれ。
def fmlwt2(fml) awt=Hash[*IO.readlines("formula.dat").map{|l| l.strip.split(/\s+/)}.flatten] fml.split(/(?=[A-Z])/).map{|e| awt[$1].to_f*(($2=="")?1:$2.to_f) if e=~/([A-Z][a-z]?)([\d\.]*)/ }.inject{|s,x| s+x} end
原子量のデータは一気に読んで行列にして、一行の前後の空白を除去してから空白で区切って、それをhashに変換している。ここで、コードの節約のために、原子量はまだ文字列のままである。その後で、各元素ごとに区切ってから、正規表現を使って処理して、それを最後にinjectで足している。だんだんゴルフ感覚になってきた。もう少し短くできた。
def fmlwt3(fml) awt=Hash[*IO.read("formula.dat").strip.split(/\s+/m)] fml.split(/(?=[A-Z])/).grep(/([A-Z][a-z]?)([\d\.]*)/){ awt[$1].to_f*(($2=="")?1:$2.to_f) }.inject{|s,x| s+x} end
ファイルを行をくっつけて読み込んで、それをそのまま配列にしてからhashにしている。後半はgrepを使って正規表現部分をすっきりとさせた。昔書いたコードを見ると、美しく感じられないことが多い。徐々にスクリプトを書く流儀が変化しているからなのだろうが、まだまだ未熟な気がする。しかし、短く書けば良いというものでも無い。後半の処理は良くなったと思うのだが、原子量のhashを作る部分は、最初のやつの方が何をしているのかはっきりしているようにも感じられる。化学式に関して言えば、本当は括弧などにも対応したいのだが、再帰を使えば出来そうな気がしているが、まだ手をつけていない。しかし、こういったプログラムを使うときには、単純な入力ミスが、誤ったデータ処理につながるので、逐一ミスが無いことをチェックすることが重要である。
2010/8/15追記 分かりやすさと短さを考えて、こんなのはどうだろうか。
def fmlwt4(fml) awt=Hash[*IO.read("formula.dat").strip.split(/\s+/m)] r=0 fml.scan(/([A-Z][a-z]?)([\d\.]*)/){|s| s[1]=1 if s[1]=="" r+=awt[s[0]].to_f*s[1].to_f } r end
2010/10/11追記 scanを{|a,n|}で受ければ、s[0]とか書かないでも良くなることに気がついた。