Day: July 25, 2015

Swift:整数と浮動小数点の見分け方

この方法でいいかどうはわかりませんが、・・・。

Anyobjectを文字列、整数、配列にそれぞれキャスティングする方法は先日書いた通りですが、この中で不十分だったのが整数。

整数か浮動小数点か見分ける必要があり、これは整数部分を引き算し、小数点以下だけを切り出して0でないなら浮動小数点とすることにしました。結果、この方法で問題がないことがわかりました。

また、配列はfor inで抽出したものをvalueとして利用すればいいです。ただし、これは配列が想定内のときに限られるはずで、そうでない場合、NSArrayで展開して何らかのシンタクスチェックをする必要があるかもしれません。

徒然:生きる理由、その目的?

長く生きていると、たまに「なぜ生きているのか?なんのために生きているか?」考えることがあります。

ポール・ゴーギャンは、「我々はどこから来たのか 。我々は何者か。 我々はどこへ行くのか。Where Do We Come From? What Are We? Where Are We Going?」という題のを描きました。自分の存在理由と目的を知りたいという願望は、いつの時代にも共通した、きっと避けて通れないテーマなのでしょうね。

多くの場合、明確な答えがない質問は忘れがちですし、そうすることは、どこまでも続く堂々巡りに潰れてしまうよりか、理にかなっています。何日か、何ヶ月か、場合によっては何年も忘却したまま生きてしまうのはあり得ることです。テーマ(命題)に対して答えが明確でないので、ついつい横に置いてそのままになってしまうのは、仕方ありません。

年を取り老い先が短くなってしまうと、そうしたつまらないことをあれこれ考えたり、思い出したりします。

振り返ってみると、結局、17歳の頃に思い浮かべたものと実際の人生は全く違ったものになってしまいました。こんなはずではなかったというよりか、想像さえしないものになってしまったのです。良し悪しの判断は自分にはできませんが、何事にも夢中になって向かって行ったのは、きっとそれが楽しかったからでしょう。何回か、もうそれ以上ついていけない思いがしてきて、投げたこともありましたが、それは保身とか保全という意味で良いことだった気がします。

今は先が閉ざされていることが感覚的にかなり明瞭に理解できます。そして、自分にできそうなことの限界もおのずから浮かび上がります。それだけに、ひとは何かするために生まれてきたのでも、何か理由があって生きているのでもないような気がしてなりません。個々の成功や失敗はとても小さな事象で、それ自体には、たいして意味や価値はなく、生きるエネルギーとは関係ないように思われます。

Swift:設計ミス

配列のデータ構造の持ち方を変更しました。

そもそもという話をすると、配列に定義してあるキーワードと一致したとき、そのvalueによって個々の変換が必要なとき、3次元配列にするとreadのアクセスは問題ないのですが、writeのアクセスが発生する場合、処理が面倒になるので、変換テーブルだけを別の配列で定義していました。

しかし、これだとやたらとif文によって判別する処理が出てくるため、行数も増え煩雑になってしまいます。それで、処理の種類は、①変換しない、②プログラムによる変換、③変換テーブルによる変換、④キー不一致で変換しないの4種類らしいということはわかっていたので、3次元配列(NSArray)に変更し、処理の種類を入れ込むことにしました。

let trArrayCGI:NSArray  = [  
 [“Int”,  “😄”, “ColorModel”,  “色空間”, “”, [ ]],
 [“Int”,  “😄”, “PixelWidth”,   “画像横幅(ピクセル)”, “”, [ ]],
 [“Int”,  “😄”, “PixelHeight”,  “画像高さ(ピクセル)”, “”, [ ]],  
 [“Int”,  “😄”, “Orientation”,  “画像方向”, “”, [  
    [“1”, “1: Horizontal (Normal)”, “1: 水平 (ノーマル)”],  
    [“2”, “2: Mirror Horizontal”,    “2: 左右反転”]

これは基本設計レベルの大きな方針変更であり、修正に2日間を要しました。しかし、休み休み慎重にやったので、ほとんど問題なく動きました。ライン数が減り、プログラムが単純化できました。

それでも、まだ腑に落ちない問題は、入力辞書を読み込み、キーを.keyで取り出したあと、.valueの取り出しのとき、データ型がAnyobject相当で不明であることにより型変換エラーが起こさないで取り出す方法がわからないことでした。文字列か数値または浮動小数点か、配列のいずれかなのですが、それを知る方法がわからなかったのです。もちろんworkaroundとして”\(wItem.value)”のような表現で文字列化できていたので、決定的なクリティカルイッシューではないのですが、何となく嫌な感じでした。

しかし、これは意外と単純で、たとえば配列かどうかはif (pInDic[cm.rcKey] as? NSArray) == nil(pInDic辞書の中のcm.rcKeyのvalueはnilか)のように聞き、nilでないなら配列、nilなら文字列か数値とすればいいことがわかりました。

 if wItem.value as? String != nil {
   cm.rcValue  = wItem.value as! String
} else  if (pInDic[cm.rcKey] as? NSArray) == nil {  
   cm.rcValue  = String(wItem.value as! Int)

前述した通り、この処理は、元々、“\(wItem.value)”のような表現で文字列に変換していたものです。これが真っ当な方法かどうかわからなかったので、Anyobjectの型を知る方法がないか、ずっと考えていた次第です。