aravis解析 その5 [aravis]
aravisを読めるようにするためにGObjectをさらっとみている。前回はGObjectの大まかな構造を確認した。インスタンス構造体とクラス構造体があって、Objective-Cのisaポインタみたいなのがインスタンス構造体の先頭にあるということを見た。今日はクラス構造体のほうと、マクロ展開するための名前の規則なんかについて....
Raspberry Pi 4Bだって [Raspberry Pi]
つい昨日、Raspberry Pi 4Bというのが発表された。それを知ったのでちょっと書かずにはいられない。
4Bは3B+から比べるとCPUコアがCortex-A53からA72に、クロックが1.4GHzから1.5GHzに、GigEがちゃんとギガビットのスループットに、4つのUSBのうちふたつがUSB3になった。4k30pディスプレイが2台も繋がるらしいけど、Raspberry Piユーザにそんな人っているのかな....
4Bは3B+から比べるとCPUコアがCortex-A53からA72に、クロックが1.4GHzから1.5GHzに、GigEがちゃんとギガビットのスループットに、4つのUSBのうちふたつがUSB3になった。4k30pディスプレイが2台も繋がるらしいけど、Raspberry Piユーザにそんな人っているのかな....
プレステVRでげろげろに [日常のあれやこれや]
昨日、息子が友人から手に入れたというプレステVRでエースコンバット7をやってみた。イージーモードのミッション1でも敵のロックオンから逃げようとするとぐりんぐりん回ってしまって、すぐにどっちが地面だか空だかわからなくなって、そのうちめまいがしてきた(急な屋根から滑る落ちる夢だ、墓穴を覗き込むんだ、キム・ノヴァクだ)。15分ほどやっただけでゴーグルを脱ぐと、首の後ろが重くなって完全にげろげろになってた。気持ち悪くてそのまま半日寝たままで過ごすことになった。
たまたま帰ってきた娘がそのあとやったら、娘はすぐに慣れて、きゃあきゃあ言いながら次々ミッションをクリアしていった。僕は娘がやってるのを固定モニタで見てるだけでまた気持ち悪くなってきたので逃げた。
何が違うんだろ。歳の差だけではないような気がする。でもどっちにしても僕はもうやらない。もういい。
.....息子はバイオハザードも持ってるらしい....きっとグロ怖いんだろうな.....
たまたま帰ってきた娘がそのあとやったら、娘はすぐに慣れて、きゃあきゃあ言いながら次々ミッションをクリアしていった。僕は娘がやってるのを固定モニタで見てるだけでまた気持ち悪くなってきたので逃げた。
何が違うんだろ。歳の差だけではないような気がする。でもどっちにしても僕はもうやらない。もういい。
.....息子はバイオハザードも持ってるらしい....きっとグロ怖いんだろうな.....
aravis解析 その4 [aravis]
ということで、これまで(その1、その2、その3)でほんとうにざっとaravisの使い方をおさらいしてみた。みてわかるように、aravisを使うのは非常に簡単になっている。それはGObjectが使いやすくできている(書きやすいとは言ってない)のと、aravisがGObjectの思想に忠実に従ってできているからだろう。
最初aravisのswiftラッパを作ろうと思っていたんだけど、ほとんどそんな必要はないぐらい簡単だし、そんなものを作ってもaravisのクラスをswiftのクラスに読み替えて、文字列の変換をして、パブリックなメソッドが単にaravisの関数を呼ぶだけのものになってしまう。
Objective-Cラッパなら少しは意味があったかもしれないけど、今更そんなものを作るつもりはない。
そうするとやはりGObjectをswiftのクラス/構造体で書き換えて、glibやgettextやintltoolなどのlinux固有のライブラリの依存をなくすというのが正しい方向だろう(本当は、そんなものをやめて素直にaravisをそのままmacOSでも使うというのがもっとも正しい方向だけど)....
最初aravisのswiftラッパを作ろうと思っていたんだけど、ほとんどそんな必要はないぐらい簡単だし、そんなものを作ってもaravisのクラスをswiftのクラスに読み替えて、文字列の変換をして、パブリックなメソッドが単にaravisの関数を呼ぶだけのものになってしまう。
Objective-Cラッパなら少しは意味があったかもしれないけど、今更そんなものを作るつもりはない。
そうするとやはりGObjectをswiftのクラス/構造体で書き換えて、glibやgettextやintltoolなどのlinux固有のライブラリの依存をなくすというのが正しい方向だろう(本当は、そんなものをやめて素直にaravisをそのままmacOSでも使うというのがもっとも正しい方向だけど)....
aravis解析 その3 [aravis]
aravis解析 その2 [aravis]
aravis解析 [aravis]
先日コメントをもらって、その気になってしまった。Gen<i>Cam規格カメラのLinux上のドライバであるaravisの中身を見ることにする。
仕事ではそんなことをやってる場合じゃないくて、時間があるならまっ先に書かなきゃいけないアプリケーションとかがあるんだけど、これもいずれは必要になるはずなのでLowest Priorityでやることにする(でも仕事のプライオリティって簡単にひっくり返るからなあ。それに比べて技術進捗の帯域ってずっと狭いもんな)。ちゃんと細部まで解析できればswiftで書き換えてmacOS版のドライバにするところまでいければいいけど、また途中でほったらかすかもしれない。そのときはごめんなさい....
仕事ではそんなことをやってる場合じゃないくて、時間があるならまっ先に書かなきゃいけないアプリケーションとかがあるんだけど、これもいずれは必要になるはずなのでLowest Priorityでやることにする(でも仕事のプライオリティって簡単にひっくり返るからなあ。それに比べて技術進捗の帯域ってずっと狭いもんな)。ちゃんと細部まで解析できればswiftで書き換えてmacOS版のドライバにするところまでいければいいけど、また途中でほったらかすかもしれない。そのときはごめんなさい....
Swift5の数関連プロトコル [Swiftプログラミング]
いつのまにかSwift 5になってた。勉強途中なので追いかけるのが大変。基本的なprotocolに変更があった。詳しくレポートしてくれる人がいた。
数関連のprotocolが代数構造に似ていると思っていたけど、AdditiveArithmeticはいかにも.zeroを単位元とする加法群という感じになっている。ただし逆元があるかどうかや、結合則に従うか、可換性を持つかどうかは実装に依存する形になってるので、Loopかモノイドかそれともアーベル群なのかは具体的な型の実装に任されている。まあ、そこまで代数をモデル化してもプログラミングの役に立たなかったら意味がないので当然だろう。
その結果というかNumeric protocolは積の演算だけが定義されるprotocolになった。Numericには積の単位元である.oneは定義されていないので、Numericは乗法に関して単位元のない半群を持つ環のような感じになってる。比較的身近な環にクォータニオンがある(正確には整域なのか)。また$n \times n$正方行列全体も環をなす。どちらも乗法に関して非可換な環である。また、この人が指摘してるように$n$次元のベクトルは加法群をなす。
ところがなぜかこないだちょっと見たsimdライブラリではベクトルもクォータニオンも行列もこれらのprotocolをadoptしていない。演算子定義なんかはそれぞれ勝手にやってる。大した手間ではないとは言えるんだけど、せっかくprotocolを整理したのに一方では無視すると言うのは美しくない。simdライブラリがCではなくSwiftに書き換えられた時点でちゃんとするのかもしれない(simdライブラリなんか、やろうと思えばあっという間だと思うんだけど。SwiftはOjbetictive-CよりCのほうが相性がいいのではないか、と最近は感じるようになった)。
ついでに言えば、simdライブラリにクォータニオンがあって同次座標のベクトルと行列の定義はないのもちょっと残念。同次座標ベクトル \begin{equation} \left( \begin{array}{c} x \\ y \\ z \\ w \end{array} \right) \equiv \left( \begin{array}{c} x / w \\ y / w \\ z / w \\ 1 \end{array} \right) \end{equation} の同値関係をEquatable protocolにadoptした形にすれば美しいのに。まあそれがどのくらい便利か、はなんとも言えないけど。
Swift 5での数関連protocolの継承関係をMathematicaでgraphにしなおすと、
となる。今回はprotocolだけにした。グレーのprotocolは数ではなく文字列からの変換を表すprotocolである。
MathematicaのGraphLayoutはいろいろできるんだけど、見やすい形にするのは難しい。結局これもIllustratorで細工した。あまり意味ない。
数関連のprotocolが代数構造に似ていると思っていたけど、AdditiveArithmeticはいかにも.zeroを単位元とする加法群という感じになっている。ただし逆元があるかどうかや、結合則に従うか、可換性を持つかどうかは実装に依存する形になってるので、Loopかモノイドかそれともアーベル群なのかは具体的な型の実装に任されている。まあ、そこまで代数をモデル化してもプログラミングの役に立たなかったら意味がないので当然だろう。
その結果というかNumeric protocolは積の演算だけが定義されるprotocolになった。Numericには積の単位元である.oneは定義されていないので、Numericは乗法に関して単位元のない半群を持つ環のような感じになってる。比較的身近な環にクォータニオンがある(正確には整域なのか)。また$n \times n$正方行列全体も環をなす。どちらも乗法に関して非可換な環である。また、この人が指摘してるように$n$次元のベクトルは加法群をなす。
ところがなぜかこないだちょっと見たsimdライブラリではベクトルもクォータニオンも行列もこれらのprotocolをadoptしていない。演算子定義なんかはそれぞれ勝手にやってる。大した手間ではないとは言えるんだけど、せっかくprotocolを整理したのに一方では無視すると言うのは美しくない。simdライブラリがCではなくSwiftに書き換えられた時点でちゃんとするのかもしれない(simdライブラリなんか、やろうと思えばあっという間だと思うんだけど。SwiftはOjbetictive-CよりCのほうが相性がいいのではないか、と最近は感じるようになった)。
ついでに言えば、simdライブラリにクォータニオンがあって同次座標のベクトルと行列の定義はないのもちょっと残念。同次座標ベクトル \begin{equation} \left( \begin{array}{c} x \\ y \\ z \\ w \end{array} \right) \equiv \left( \begin{array}{c} x / w \\ y / w \\ z / w \\ 1 \end{array} \right) \end{equation} の同値関係をEquatable protocolにadoptした形にすれば美しいのに。まあそれがどのくらい便利か、はなんとも言えないけど。
Swift 5での数関連protocolの継承関係をMathematicaでgraphにしなおすと、
となる。今回はprotocolだけにした。グレーのprotocolは数ではなく文字列からの変換を表すprotocolである。
MathematicaのGraphLayoutはいろいろできるんだけど、見やすい形にするのは難しい。結局これもIllustratorで細工した。あまり意味ない。