numpyにはまる

pretty_midi のユーティリティが、バグった。

どうしてもある小節でテンポが合わない。

調べてみると、numpy float64では、実表記としては17桁持っているらしく、

7桁計算とは誤差が大きくなって、round すると、ズレる。

うう。

 

先を急ぐのでこの、追求はやめて、フロントのJavaScript で逃げた。

 

連休の中日にでも、追求しよう。

 

帰宅したら、息子がdockerでハマっていた。親子して。。なにやっとんのじゃ。

おっとっと

おっとっと。あまり過激に進化しないのが年寄りプログラマだな。

午前は軽くバグ取りして、午後はつまらないことではまって、夕方また

つまらないことで、はまった。JavaScript だいぶ、慣れてきて

思うがままにかけるようになってきているが、やっぱり、よくわからんな。

近年の言語だと、list、arrayに差が出てくる。いつも、わけわかんなくなって、

Swift 配列検索とかJavaScript 配列コピーとか。。昔々のcの人間なんで、

むしろ、ポインタによる、forward、backward チェーンの方がわかりやすかったりもするな。

 

帰ったら、自然言語解析の質問が来てたけど、今ってもしかしたら、Ngramとかも

機械学習っていうのかも。

Borland c++

なんとiPadバージョンがあるんだ。。

360円なので験そて見る気になれないけど。

そういえば、c++は、ほぼ マザーランゲージなんだけど、STLにはあまり

接点がなかった。こんなん、いるのおー。という感じだったけど、

にわかにopencvしてみて、こんなに、気合いれれば、ありかも。

とは、思わなんだ。  やっぱ、根がPythonista なんよなあ。

image

意外にハマるのがイメージハンドリング。

昔はbitmapでせいぜい16bitカラーとか言って威張っていたが。。#いつの時代だと言われそう。

32ビットあるいは4kとか。 さらにはretinaで2倍解像度。

フォーマットは各種入り乱れて、それを、便利な描画関数がいい感じで処理してくれちゃう。

一見同じ大きさに、見えてる画像。 

この同じ大きさに見えてるというが逆にハマりポイントで、いま1280x780も

1440x1080だろうが、写真は同じサイズで見える。ただ解像度が違うだけ。

ドット数が大きい方が解像度が高い。

当たり前なんだけど、これ逆に考えると面倒。つまり、同じjpegファイルがあったとして、

2つの機械で、同じ大きさで表示できる。さあ問題はこれからで、そのjpegの、同じ位置に例えばグラフィックで文字を、入れようとする。

グラフィック関数は、不幸なことに座標系で指定するのでマシンAではそれがx座標390で

y座標が230に描画するようにするとぴったりとハマるとする。このマシンの解像度が1280x780だった

とする。

これをマシンBで解像度が1440x1010だとどうなるか。

答えはいくつもある。 これは、座標系を、1 ドット数に合わせる場合、 2 解像度に合わせる

場合で、違ってくるからだ。

 

まあ、今の人はこういうロウレベルグラフィックスそもそもやらないから、関係ないけどね。