OGURISU Osamu
oguri****@lagen*****
2004年 11月 24日 (水) 18:35:57 JST
小栗栖です。
> これは、オブジェクトのコピーのセマンティクスをまだはっきり
> 決めていないためです。できればこういうジェネリックな操作は
> 全ライブラリで統一したいわけですが、じゃあcopy-objectは
> 一般的にdeep copyをすべきかshallow-copyをすべきか、
> 構造の共有がある場合なんかの処理も考えるとコンテキストを
> 渡していった方がいいか、なんていうあたりをまだちゃんと
> 考えていなくて、それが決まるまであんまりおおっぴらにしたくない、
> という心理が働いていたりします。
なるほど、了解しました。
> 無難な方法としては、array-copyというのを用意しとく、という
> 手はありますね。それならarray限定のセマンティクスを与えておけます。
> list-copyやvector-copyとの対応でいけば、shallow copyになるでしょう。
なるほど。えっと、shallow copyはオブジェクト内部のスロット
は、元の参照先と同一オブジェクトをそのまま参照させるような
コピーですよね。例えば、<u8array>であれば同じ
backing-storageを共有することになると。(あれ？もとのarray
と同じshapeのshare-arrayを作るのともしかして同じのような？)
いまのcopy-objectは<u8array>に対してはbacking-storageもeq?
でないものがつくられて、こちらはdeep copy的だと。
とりあえず、今、個人的にはdeep copy的なものが欲しいので、
copy-objectを真似てarray-deepcopyみたいなのを作って使って
おきます。
> > 2つ目は純粋に質問で、SRFI-10に複素数のuvectorがないのはど
SRFI-10じゃなくて4でした。すみません。
> たぶん、srfi-4を作った時はそこまで考えてなかった、というところじゃ
> ないでしょうか。もともとsrfi-4のベクタ自体、ハードウェア表現を
> 意識していて、Schemeの抽象的な数値階層とは完全に対応していない
> わけですし。
ああ、そうですね。たしかに。f32vectorだとかビット数を明示
的にするなんてのもあまりSchemeっぽくないなあと、使いはじめ
たときに思いました。
> gauche.uvectorを拡張して複素数をサポートすること自体には
> 技術的な障害はないと思います。
はい。とりあえず実数と複素数でAPIが違うのは嫌な感じなので、
f64vectorをbacking-storageにして
#,(<z64vector> 1+1i 2+2i 3+3i 4+4i)
とか書けようにとか<z64array>は作って試してみているところな
んですが、、、
> Aubrey Jafferが提案したもうひとつのarray APIであるsrfi-47には、
> 複素数とビットアレイが入っていますね。そっちを効率良くサポート
> することになったらもしかすると入れちゃうかもしれません。
おお。そちらを期待して、z64vectorとかであんまり凝るのはや
めます(^^;
--
小栗栖 修 / OGURISU Osamu