macでpascal - 過去の栄光と現在の挫折

最初に覚えたPC言語はBASICをだった。
当時はそれしか選択肢がなかったのだが今思えばもっと早くに卒業すべきものだった。
で、その次に覚えて大きな影響を受けたのがturbo pascalだった。
当時のバージョンは3.0.1くらいのころで各社のMS-DOSで動く仕組みを作ったものだ。
（まあ主にNECとFujitsuだけど）
使いやすいし勉強にもなった。

で、最近macbookでいろいろ実験をするうちにふとfree pascalをいじってみたいなって考えて、ついでにGUIも出来たらいいなって余計な欲をだしてLazarusの最新を入れてみた。
そう言えば初期のmacの公式開発言語はobject Pascalだったと思いだしたり・・

C#とかの知識をもとにいきなりimageのcanvasを塗りつぶすって簡単な数行のソースを書いてrunアイコンをクリックしたら threadの絡むエラーを吐いた。

どうしてエラーが書いたソースから離れた箇所から出たかググルにもLazarusでは情報が少なくて困難な感じだ。今後のことを考えて早速の挫折。
以前はWindows上の古い版でmandelbrotの描画をしたりしていたのだから色々調べながらなら書けなくは無いのかもしれないけどmacのお遊びでそこまで踏み込みたくない気もして速攻でapplicationフォルダからリンクをけしてLibrary以下の本体もゴミ箱行きです。

pythonならnumbaやpygameもあるので潔く諦めて過去の栄光に浸るのはやめよう。

久しぶりにハマった

 Excelでmandelbrot集合の描画をする実験が思いの外うまく行ったので気を良くして普通の直線を描画するアルゴリズムを実装しようとしていたんだがここでハマってしまったのでメモ

画素を指定して点単位で色を着けられる画面（つまり今回のExcelのセル幅と高さを1ピクセルに調整してセルの背景色で色を着けられるような場合）マンデルブロのように各点ごとに条件を計算して色をつければ完成するようなものよりも直線の描画のように始点と終点をしていして（必要なら色の指定もして）描画するような操作や中心と半径を指定して円を描画するようなプログラム部品が欲しくなる。

そして直線をなるべく少ない計算量で描画するのがブレゼンハムのアルゴリズムである。
ここで事件は起きた。
まずは手持ちの資料がCだったのでそれを逐語訳的にVBAに置き換えて動かして見た。直接デバッグウィンドウに
drawline 0,0,639,479,vbRed
のように打ち込んで実行するときれいに直線が描画される。しかし
for x=0 to 639:drawLine x,0,639-x,479,vbBlue:next
 等とするととたんにおかしくなる。ｘの区間がある程度までは問題なく描画されるのだがx=80ぐらいから妙なことに画面の中央ぐらいでチラチラするだけでうまく行かない。

単一行だとうまくいくのに連続の実行だと変になる。最初はわけが分からなかった。
ソースをながめること小一時間。あれこれ、パラメータを受けてそのまま作業変数として使ってるぞ。そうか参照渡し（もしくは変数渡し）と値渡しの違いなのか。

Cとかpascalとかは値渡しが基本です。渡された関数(pascalだとprocedureもありね)はパラメータを内部処理でローカル変数と代入し合ったりしても渡したもとのプログラム側では値が変わってしまうことは値渡しということで無い。しかしvbaは基本的には参照渡し。
つまり上記のforの例のように繰り返し管理に使うｘの値が途中で変わってしまって上手く行かなくなったようだ。

ここまでわかれば対策はかんたん。関数(手続き)側のパラメータ宣言部の変数に前にbyvalを付ければ目的は果たせるのだけど今回は呼び出し箇所が1箇所だったので
for x=0 to 639:drawLine (x),0,(639-x),479,vbBlue:next
みたいに呼び出し側で式化して値を渡すようにして逃げた。

仕事で各プログラムだと繰り返しの変数を直接パラメータに渡すような処理を書くようなことがまず無いせいですっかり忘れてたが副プログラムの処理で変数の内容が変わるような副作用を起こせたんだ。やはり基本的な(そして大事な)変数まわりの処理や副作用には常に気を配らねばと思った。

日が変わってやっぱり呼び出し側に気を使わせるよりは手続き側のパラメータ指定にbyValをつけるほうが呼び出しのたびにコピーが生じるとしても正しいと考えて手続きの冒頭を
sub drawline(byVal x1 as integer,・・・・,col)
のように書き直した。
将来の自分が呼び出し側で今回のような配慮や工夫が必要って覚えている保証無いもんね。

やっぱりrubyを消した。

 昨年7月に「いまさら」と前置きしてメイン開発機のwindows10に再度rubyを入れたんだけど2か月後に追記して全く使ってないことを書きました。半年してみてやっぱり心が動かなかったので貴重なSSDのエリアを1GBも占有されるのもなんだかと思って消したらすっきりしました。

今時windows用のrubyは不要かなって感じてしまいますね。もともとruby界隈の人もlinuxやmac推しの人が使ってることが多かったしそうかといってmacで使って楽しそうだったかと言えばかなり疑問だし。まあWSLの方ならいつでも使えるのでCUIで使えれば十分でしょ！

あのASCIIから書籍が出まくっていたころが僕にとってのrubyの最初で最後の黄金期だったね

サヨナラruby（って言ってもWSLの方はいつでも動くけどね）

excelでmandelbrot (ってjuliaじゃないんかい！)

 とある会社の請求・給与・勤怠管理をプログラミングしてるときに出力がExcelというのがあってExcelのひな型をさわっていてふと思いました。

以前のExcelはカラム数が255までだったけど今はどれくらいなのだろう？

答えはググってすぐに16384列（XFDまで）とわかりました。
で、以前1セル1ドットに見立ててフラクタル書いてみたんだけどやはり粗いしすぐに興味を失ったんだけどいまならもう少し行けるんじゃね。っていうことでやってみました。

26進数でカラムを数えて640=XPってことで見えてるようなセル番号になってます。
マウスで列とか行とかの高さや幅を調整するとピクセル数も出るので楽でした。

いやはや結構良いんじゃないでしょうか?

よく噛ませ犬みたいに古いBASICで比較のために書いたりしてましたけどもういい加減懐古趣味からは卒業しようと思っていたのでこれからはExcelを比較の最初にしようかと思います。画像がちょっと前に宣言してたjulia集合の図と違うのはまだお手本無しに書けないからです。（さすがにmandelは回数書いてますから）

斜めの直線を書いたりするのはちょっとしんどいけどちょっとしたグラフィックの実験なら別に環境を用意するとか無しに使えて面白いです。特に集合系の描画はドット単位の色ずけがほとんどなので・・

今年のフラクタルはジュリア

 ここ数年(昨年末まで)はmandelbrot集合を描くプログラムをしばしば条件をなるべく揃えてベンチマーク的に書いてきた。

これはmacbookでpygameとnumbaを併用して0.5秒ほどで得られたもの。

計算対象区間を変えるといろいろと楽しい画像が得られるのはフラクタルならではなのだがいつもいつも8色のmandelbrotでもあるまいということで今年からは計算対象を変えたいと思う。

同じくフラクタルのjulia集合の画像です。

まだ経験値が低くて他の方のプログラムをネットから探してくて少しアレンジを加えた程度です。

julia集合の何が面白いかというと計算の元になる複素数を少し変えるだけで得られる結果の画像がかなり大きく変化することと描画のための色を決定する方法が色々あって楽しめるようです。c.f. https://codezine.jp/article/detail/310 

上の2つは同じパラメータで得た画像だけど各点における色の計算を変えるだけでこんなにも違う画像になるみたいです。

いろいろと少しずつでも広げていかないと・・・

Viva!エミュレータ

 エミュレータが好きである。
コンピュータで別のコンピュータやゲーム機を模するソフトが面白くて仕方ない。
当然、昔からの専用のエミュレータソフトも楽しい。
しかし最近はPCの性能が上がって効率的なエミュレーションができるようになってきた。

その最たるものがVirtualBoxだ。（異論もお有りでしょうけど・・）
そのmac上で動くターゲットOSが[PC-DOS2000J,Windows 98SE,Windows2000pro,WindowsXP,Windows7(Home 64bit)]とあるのだがせっかくmacで動いても残念なのがPC-DOSなのである。

現状autoexecでfilmtnが起動するようにしてあって下記のような画面になる

で、カーソルで移動しつつEnterでフォルダを掘ったりしながら作業を自在にすすめることができる。で、テキストファイルでEnterを押すとまずはテキストビュアーで見える。

これはDos/V用のスペードテストの結果の冒頭でこのエミュレータが5.3GHzクロックのPentiumとして認識されているのがわかる。大昔のPC-XTの8435倍だと・・
それは大変うれしいのだがここで更にEnterを押すと指定のエディタで編集に入ることができるのだが入力が思うままにならない。まず漢字変換のモードに出来ない。
なぜってmacに全角／半角キーがないから、その他PC-DOSの結構複雑な漢字変換周りのキーがほとんどうまく操作できない。日本語が入れられないのは寂しいので一応緊急用及び他のPCで実験用にコンパイルしたオブジェクトの実行用に保存はしておくがmacでソースをいじる事は無いであろうことは確実。ああ、残念。

macbookのmacosを更新した

 昨夜から今日にかけてmacbook pro(2013 late)のOSをsierraからmojaveに更新した。
買ったときはmavericks(10.9)だったのを昨年、結構考えてsierra(10.12)にしたのだが今回さらなる更新に及んだのである。

ハード(2013 late)とmacosの乖離が大きくなるほど導入後にいろいろな傷が出てくると思うのでいよいよこのmacbookでのOS更新も最後であろうかと思う。
そもそもsierraからhigh sierraにするのをためらっていたのもSSDのフォーマットが大きく変わることへの不安が大きかった。で、1世代見送って様子をみて今回のmojaveである。

変えてみて思うのは、本当にmacはよく出来ていてOSを上げても体感上の重さはほとんど感じない。また僕が入れている程度のmacのソフトはそのまま動いている。最終的にどのように感じるかは現時点ではわからないけどtime machineでバックアップも取ってあるので不安は少ない。いざとなればもとに戻すだけのことだ。

parallelsで入れているwindows10は先回のOSアップでboot campとの併用はできなくなってしまったのであくまでもmacos使用時にどうしてもwin10を使いたくなったときの逃げ場として動くかどうか見ておく。最初メモリーを2GBふってあったのだがやっぱり重くなりやすいので3.5GBに変更した。あとは以前のままだが結構サクサク動くので驚き。（ただしmacbookの左の下は結構熱くなる。）

まあ仕事でどうしてもmacじゃなきゃだめってものは現状無いので気楽に楽しく付き合っていこうと思う。

すっかりアルゴリズムなし脳になっているので数字パズルを解く

 超ひさしぶりに頭を使うことにしよう。

結構ポピュラーな数字パズルを解く。
　SEND
＋MORE
-------------
MONEY

を考える。言語はなんでも解けると思うけど今はpythonで

最初は総当たりのもっとも原始的なループでの方法を考える。
変数 S,E,N,D,M,O,R,E,Yをすべて０−９のループで回す。

できたのがこれ

#SEND+MORE=MONEYを総当たりで解く

for s in range(10):

for e in range(10):

for n in range(10):

for d in range(10):

for m in range(10):

for o in range(10):

for r in range(10):

for e in range(10):

for m in range(10):

for y in range(10):

if (s*1000+e*100*n*10+d)+(m*1000+o*100+r*10+e)==m*10000+o*1000+n*100+e*10+y:

if s>0 and m > 0:

print(s*1000+e*100*n*10+d,m*1000+o*100+r*10+e,m*10000+o*1000+n*100+e*10+y)

なんだかすごいことになっている。ちょっとこれはないわ。プロンプト帰ってこないし・・

あ、eとmがダブってループしてました、酷い。

そもそもいくら総当たりとはいえrangeですべて回すのは頭悪すぎ
14行めのif s>0 and m>0: はこれが無いと平気で 3009,301,3310とか出力してきちゃうので各変数文字の重複を禁止するのと4桁なり5桁の数値の頭が0じゃない判断くらいはしろよと・・

で、ほんのちょっとだけ数学的に考えると同桁の数値を足して繰り上がるのは1しかないのでm=1は確定だし下からの繰り上がりを考慮してもm(=1)と足して繰り上がることができるｓは8か9になる。この辺りの縛りと重複を避けるようにして先程のプログラムに手を入れると

#SEND+MORE=MONEYを総当たりで解く

#各変数は重複せずm=1,sは8 or 9で考えると

m=1

for s in [8,9]:

kouho = list(range(10))

kouho.remove(m)

kouho.remove(s)

for e in kouho:

kouho.remove(e)

for n in kouho:

kouho.remove(n)

for d in kouho:

kouho.remove(d)

for o in kouho:

kouho.remove(o)

for r in kouho:

kouho.remove(r)

for e in kouho:

kouho.remove(e)

for y in kouho:

if (s*1000+e*100*n*10+d)+(m*1000+o*100+r*10+e)==m*10000+o*1000+n*100+e*10+y:

print(s*1000+e*100*n*10+d,m*1000+o*100+r*10+e,m*10000+o*1000+n*100+e*10+y)

となる。だけど上の方法ではうまくループが回らない。
（ああ、ここでもeを重ねてループしてるわ、リハビリ必要）
e以下のremoveを止めると・・・・あー分からない　もう少し頭を冷やして考えよう

そもそもいろいろ忘れていてコードの効率が悪い。
重複のチェックにsetを使うことまでは頭が回るけどkosuu= set()
kosuu.add(m)みたいに8個の変数でやる。これは素人以下。頭を冷やそう。

#SEND+MORE=MONEYを総当たりで解く

#各変数は重複せずm=1,sは8 or 9で考えると

m=1

for s in range(8,10):

for e in range(10):

for n in range(10):

for d in range(10):

for o in range(10):

for r in range(10):

for y in range(10):

if len(set([m,s,e,n,d,o,r,y]))==8:

send=s*1000+e*100+n*10+d

more=m*1000+o*100+r*10+e

money=m*10000+o*1000+n*100+e*10+y

if send+more==money:

print(send,more,money)

結局上のリストのようになりました。なんだかシンプル。まだまだpythonの基本がわかってない。

単に途中までパズルをときかかったのでもう少し進めると

m=1、s=8 or 9より判った分の文字と数値を入れ替えて　s=8と仮にすると
　８END
＋１ORE
-------------
１ONEY　となる。桁上りするのでE+0＞１０なのだが千の桁が桁上りすると０がゼロになるがそれだとE+O>10が満たせないのでS=9が確定、同時に０はゼロ　これをはめ込むと
　９END
＋１０RE
-------------
10NEY     である。さらにこれでN=E+1なのでE+1+R(+1)=10+Eでカッコのの桁からの繰り上がりの有無を考えると、必要となるので（９が使われているので）R=8となる。見難いけど
　９E(E+1)D
＋１０８E

１０(E+1)EY　２・３桁目は桁上りだけなのでD+E=10+YでDとEは(7,6)(7,5)のいずれかの組合せとなる（6,5)では和の１桁目が１となり既に使用済み。E=7とするとN=8となり不可
E=6なら
　９６７D
＋１０８６
１０７６Y　となり繰り上がれるDは５のみだがY=1になるので不可　よってE=5

　９５６D
＋１０８５

１０６５Y　で繰り上がれるDは７でYは２となる。

ちなみにパズルの答えは正しく　

Send = 9567
More = 1085
Money = 10652

一応記述したプログラムも同じ解を表示しているので今日は良しとする。

年間1万行計画

 この1年を通していろんなソフトウェアに関する見識を広めたい。

で、年間1万行のコードを書くことを決めた。まあ週に200行ってことだ。
毎日コードを書くことを生業にしている人から見たら笑っちゃうぐらい小さな目標だけど有意なコードをこのペースで書くって意外としんどいと思うので自分には分相応なかんじ。
三賀日は3日で評価して以後は毎週末に200行で何を書いたか見せられたらいいね。

で、早くも自分への甘々な性格が鎌首をもたげてきて勉強になるちゃんと1つの動く形のソースなら写経でも可能とするとした。（特に習慣化してエンジンがかかるまでは広い目で・・）

まだ少し早いけど現時点で見せられるのはこれ

C#だとmacで動かなかったり（本当は動くらしいけどWindowsとGUI共通でない）するので標準的な試行言語(なんとなく手を動かして試行錯誤するうちに目的のものが書ける感じ)としてpythonを使いたい。で、そのGUI開発のライブラリとしてPySimpleGUIを評価し始めたのだけどなんとmacbook(のmacos)だとテキストボックスが編集できない。対策としてwxPythonベースのPySimpleGUIWxを使うことにした。ソースのimportのターゲットだけwx付きに書き換えたら動くことを確認したのが上の画面。wxの方がちょっとウィジットのバランスが悪い気もするけどちゃんと編集できたので嬉しいからよしとする。

これでGUI系の写経で100行くらいゲットしたわ。（新年早々からずっこいこと）

上記の必要でwxPythonを入れたのでついでにBASICを弄りたい。なんて邪心を抱いてwxBASICをmacbookで入れようとしたらうまく入らなかった。きっとこれはBASICなどというもの貴重な時間を用いずにpythonに励めという天啓だと思い肝に銘ずる事にした。

ついでにLazurusもクロスプラットフォームだと頭をよぎったけど・・