Recursive enumerationを使った電卓プログラム（四則演算しかできないけど） [Swiftプログラミング]
仕事の合間にSwiftの勉強をしてるんだけど、ちんたらやってるとSwift本体の方がどんどん新しくなって追いかけるのに苦労する。最新のSwift 5の勉強をしようと思って、Appleのドキュメントをみていた。Opaque typeとか、＠で始まるAttributesとか、必要性はわかるんだけど自分で使うかどうかよくわからない機能が多い。SwiftUI関連の拡張（SwiftUIを理解せずに言語仕様だけ追っても何がやりたいんだか全然わからない）も多くてフォローしたいんだけどまだそんなところではない。
その中で、今日たまたまRecursive enumeration（再帰的列挙）を知った。これはSwift 5で新しく導入されたものではなくて、その前からあったらしいんだけど、僕は知らずにいた。
これまでSwiftではバイナリツリーみたいな構造はclassでないとできないと思ってたんだけど、これを使えばenumでできる。ちょっと手に馴染ませるために簡単なものを作ってみようと思った。とりあえずこのドキュメントの下の方の「Recursive Enumeration」にあるArithmeticExpressionを拡張して四則演算できるようにしてみた．．．．
その中で、今日たまたまRecursive enumeration（再帰的列挙）を知った。これはSwift 5で新しく導入されたものではなくて、その前からあったらしいんだけど、僕は知らずにいた。
これまでSwiftではバイナリツリーみたいな構造はclassでないとできないと思ってたんだけど、これを使えばenumでできる。ちょっと手に馴染ませるために簡単なものを作ってみようと思った。とりあえずこのドキュメントの下の方の「Recursive Enumeration」にあるArithmeticExpressionを拡張して四則演算できるようにしてみた．．．．
ジェネリクスとプロトコルなど [Swiftプログラミング]
個人的にちょっと困ったことが起きている。でも僕が何かして解決する内容ではないので、とりあえず頭を低くしてやり過ごすのを待つことにしてる。それですめばいいんだけど。
ところで全然話は違うけど、Swiftで書いててまたよくわからないことができた。こんどはジェネリクス．．．．
ところで全然話は違うけど、Swiftで書いててまたよくわからないことができた。こんどはジェネリクス．．．．
共用型の比較 [Swiftプログラミング]
勉強と慣れをかねてObjective-CをやめてSwiftでいろいろ書いてる。今日書いてて、Swiftのassociated valueつきのenumについて、ふとわからないことができた。誰か教えて．．．．
素因数分解 [Swiftプログラミング]
久しぶりに仕事でやらかしてしまった。新しいガラス非球面レンズの設計で、ちょっとした計算間違いをして、それをもとに金型作ってレンズまで起こしてしまってから間違いに気がついた。レンズは使えなくはないんだけどもとの仕様は満足しない。ある仕様が微妙に違うだけで同じ設計思想に基づいたレンズの5機種目で気が緩んでいたのと、似たようなレンズなのに新規に金型から起こすのには僕自身は反対だったせいで、気乗りがしなかったのもあった。
急いで設計し直してから四方に頭を下げて回って、金型の追加工ができる範囲か硝財は使い回せるか加工成形スケジュールに押し込めるか客先への弁解はどうするかなどなど、慌てて善後策を探ってまわっているところ。もう5機種目で編集設計のレベルになってしまって、実は最終評価まで退屈なルーチンワークになっていた。そのせいかこういうドタバタのほうにかえって張り合いを感じてるのにふと気がついた。そういうのはジジイならでは、なんだろうな。もちろん周りには迷惑をかけることになるので、それはごめんなさい。
それはいいとして（何もよくないけど）、こないだからSwiftの練習のために、これまでObjective-Cで書いたアプリをSwiftに書き直している。仕事に使っているのと遊びで作ったのとを一緒に、書き換えやすい簡単なものからやっている。ずっと昔ここで公開して、そのあとほったらかしにしてるSpaghettiMazeMakerやSTISPlotなんかも書き換えようと思ってるけど、このどちらも僕の書いた任意長さのFFTを使っていて、やはりfftwを使わずにそれも書き換えたい、と思った．．．．
急いで設計し直してから四方に頭を下げて回って、金型の追加工ができる範囲か硝財は使い回せるか加工成形スケジュールに押し込めるか客先への弁解はどうするかなどなど、慌てて善後策を探ってまわっているところ。もう5機種目で編集設計のレベルになってしまって、実は最終評価まで退屈なルーチンワークになっていた。そのせいかこういうドタバタのほうにかえって張り合いを感じてるのにふと気がついた。そういうのはジジイならでは、なんだろうな。もちろん周りには迷惑をかけることになるので、それはごめんなさい。
それはいいとして（何もよくないけど）、こないだからSwiftの練習のために、これまでObjective-Cで書いたアプリをSwiftに書き直している。仕事に使っているのと遊びで作ったのとを一緒に、書き換えやすい簡単なものからやっている。ずっと昔ここで公開して、そのあとほったらかしにしてるSpaghettiMazeMakerやSTISPlotなんかも書き換えようと思ってるけど、このどちらも僕の書いた任意長さのFFTを使っていて、やはりfftwを使わずにそれも書き換えたい、と思った．．．．
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で細工した。あまり意味ない。
SIMDライブラリの行列とクォータニオン [Swiftプログラミング]
CPUが持っているベクトルユニットを陽に使うためのSIMDライブラリの一部が、Swift Standard Libraryの中に取り込まれていることをこないだ確認した。アセンブラを見ると作業量が少ない場合は、Standard Libraryにある関数を呼ぶのではなく、ベクトルユニットの命令が直接インライン展開されていることがわかる。ソースは確認してないので実際にどうなのかはわからないけど、@inlinable属性がついていてその通りのコードが出力されているということだろう。
またこのStandard Libraryとは別に
またこのStandard Libraryとは別に
import simdで、SIMD関連の追加がされることを知った。simdのインポートによって4次元までのベクトルと行列の基本的な演算がいろいろ可能になる。ちょっとだけ前回の追加．．．
SIMDがStandard Libraryに [Swiftプログラミング]
こないだSwiftの勉強で光線追跡エンジンを書き直してる話を書いた。そこでは勉強なのでベクトル行列演算もベタに自分で書いてたけど、Objective-Cで書いたやつではAccelerate frameworkを呼んでいる。よく見るとSwiftのStandard LibraryにSIMDが入っている。知らなかった。
SIMDはもともとCPUのベクトルユニット使うためのライブラリで、昔は確かAccelerate frameworkの一部だったと思う（一番最初は、懐かしいAltiVecを使い倒すために導入されたと覚えている）。整数や浮動小数点数を4つなり8つなりまとめて、ベクトルユニットが可能な演算を定義してあった。
今見ると、Accelerateからは独立してるようである。Swift Standard Libraryに入れるためにそうなったんだろうか。Metalのshaderにも構造体が流用されているようなので、その関係なんだろうか。Swift Standard LibraryのSIMDドキュメントはかなり簡素でこれだけ見てもなかなかよくわからない。たぶんAccelerateにあったやつのラッパになってるんだろうと思う。僕は昔ならいざ知らず今後SIMDを単独で積極的に使うことはあまりないとは思うんだけど、Swiftの勉強になりそうなので詳しく見てみる．．．．
SIMDはもともとCPUのベクトルユニット使うためのライブラリで、昔は確かAccelerate frameworkの一部だったと思う（一番最初は、懐かしいAltiVecを使い倒すために導入されたと覚えている）。整数や浮動小数点数を4つなり8つなりまとめて、ベクトルユニットが可能な演算を定義してあった。
今見ると、Accelerateからは独立してるようである。Swift Standard Libraryに入れるためにそうなったんだろうか。Metalのshaderにも構造体が流用されているようなので、その関係なんだろうか。Swift Standard LibraryのSIMDドキュメントはかなり簡素でこれだけ見てもなかなかよくわからない。たぶんAccelerateにあったやつのラッパになってるんだろうと思う。僕は昔ならいざ知らず今後SIMDを単独で積極的に使うことはあまりないとは思うんだけど、Swiftの勉強になりそうなので詳しく見てみる．．．．
またSwiftでわからないことが [Swiftプログラミング]
昔Objective-Cで書いたアプリをSwiftに書き直しながらSwiftの勉強をしょぼしょぼ続けている。でも単に逐語的に変換したのではSwiftの勉強にはならないので、Swiftらしい言い回しになるように考えながらやってる。CodeWarriorのC++からObjective-Cに切り替えるときもそうやって苦労した。そんなことしてると全然進まない。慌てることはないとは言うものの、仕事でもmacOSに書くことがある（というかソフトウェアで解決しないといけないことはよくあってそのときは僕にはmacOSしかない）ので、いつまでもObjective-Cというわけにはいかない。悩ましい。
古いのを書き直してる中でまたよくわからないことに出くわした．．．．
古いのを書き直してる中でまたよくわからないことに出くわした．．．．
SwiftのProtocolが面白い [Swiftプログラミング]
Swiftの勉強をちびちび続けている。どうせAppleのことだからSwiftのランタイムがObjective-Cのコードに依存しなくなったら、あっという間にObjective-CをObsoleteにするに違いなくて、その準備をしないといけない。この歳になって新しいことを勉強するのは厳しいけど、いまさら他のプラットフォームに移るなんてことはもっと大変なのでしょうがない。
最初、僕はSwiftを「ようするにCとおさらばしたObjective-Cという感じ」だと思っていたけど、ちゃんと勉強を始めてみると、結構Objecitve-Cとは違っていて面白い、と思うようになってきた。単に文法をすっきりさせて流行りを取り込んだだけ、というわけではないらしい。
なんとなくわかってきたのが、LLVMの解析能力をフルに使えるような工夫がいろいろあるように思えるところ。ARCはその最たるものだし、整数や実数なんか（Cではスカラ型と分類される）までStructの仲間にしておきながら、実行時のメモリや命令のオーバーヘッドはCと変わらない、というのもできる限りコンパイル時点で解析して静的に解決するような言語仕様になっているからだろう。Objective-Cとは真逆の考え方である。
さらにProtocolの位置付けがObjective-Cとはかなり違っている、というのに気がついた。特にSwift Standard Libraryに含まれる基本的なProtocolは数学のあるものによく似ている．．．．．
最初、僕はSwiftを「ようするにCとおさらばしたObjective-Cという感じ」だと思っていたけど、ちゃんと勉強を始めてみると、結構Objecitve-Cとは違っていて面白い、と思うようになってきた。単に文法をすっきりさせて流行りを取り込んだだけ、というわけではないらしい。
なんとなくわかってきたのが、LLVMの解析能力をフルに使えるような工夫がいろいろあるように思えるところ。ARCはその最たるものだし、整数や実数なんか（Cではスカラ型と分類される）までStructの仲間にしておきながら、実行時のメモリや命令のオーバーヘッドはCと変わらない、というのもできる限りコンパイル時点で解析して静的に解決するような言語仕様になっているからだろう。Objective-Cとは真逆の考え方である。
さらにProtocolの位置付けがObjective-Cとはかなり違っている、というのに気がついた。特にSwift Standard Libraryに含まれる基本的なProtocolは数学のあるものによく似ている．．．．．
