Mutable vs Immutable (Re: Complex values on Java)

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。また面白そうな…fj.comp.oopsにクロスポストします。

雨宮さん:
> Javaとは関係ないですが。複素数のかけ算を間違ってました。がびーん。

よくありますよね。:-) 私はこないだ「外積の式は」とかいって30分
以上悩んでました。

> ところで、この multiple()メソッドですが、上のように
> void multiple();
> で、そのインスタンスのフィールド(この場合、realPartなど)を
> 変えてしまうのがよいのか、それとも
> ComplexValue multiple();
> と新しい(この場合は) ComplexValueオブジェクトをつくって
> 返すほうがよいのか、いつも迷ってしまいます。
> どっちでもいいのか、それとも差があるのか皆様どう思われますか。?

悩むこたないです。絶対、常に新しいオブジェクトを作るべきです。
何のためのGCなの? Complex って複素数「値」のつもりでしょう?

> もう一つ、上2つのことを両方やる、つまりそのインスタンスのフィールドを
> 書き換えて、かつ新しい ComplexValueオブジェクト返すメソッド
> ComplexValue multiple();
> もありますよね。
> #java.lang.StringBuffer#append()がそうでした。

StringBufferはmutableだからそれでいいんですけど、「値」として
使いたいオブジェクトがmutableだと後でドツボにはまるんじゃないで
しょうか。

ですから、副作用も欲しいのならComplexとMutableComplexを両方用
意する、それなら分かります。その場合MutableIntegerとか
MutableDobuleとか全部作りましょうね :-)

> 返り値を無視すると、void multiple(); と同じ使い方ができます。
> 結局、この最後の書き方が一番便利なんでしょうね。

便利で決めてはいけませんぜ。自分の主義で決めましょう。

> #一人芝居になってしまったかも。 m(_ _)m

というわけで、んなこたないです。 久野

[N.Amemiya]

雨宮@Nikonです。

ku...@gssm.otsuka.tsukuba.ac.jpさま wrote:
>
> > ところで、この multiple()メソッドですが、上のように
> > void multiple();
> > で、そのインスタンスのフィールド(この場合、realPartなど)を
> > 変えてしまうのがよいのか、それとも
> > ComplexValue multiple();
> > と新しい(この場合は) ComplexValueオブジェクトをつくって
> > 返すほうがよいのか、いつも迷ってしまいます。
>

> 悩むこたないです。絶対、常に新しいオブジェクトを作るべきです。
> 何のためのGCなの? Complex って複素数「値」のつもりでしょう?

はい、値のつもりです。すっきりしました。ありがとうございます。
#さっそく書き直さねば。あせ、あせ。

ただ、実行スピードを比較してみました所、オブジェクトを新しく作る方は、
作らない方に比べて、1.5倍程時間がかかりました。
jdk1.1.5 on Solaris2.5.1(SS-10 33MHz)で 10000回のかけ算で、
それぞれ、145msecと 94msecでした。
スピード命の方には耐えられないかもしれませんが、
コードの可読性があがって、その結果バグ出しの時間が減るのなら私は満足です
。

> > もう一つ、上2つのことを両方やる、つまりそのインスタンスのフィールドを
> > 書き換えて、かつ新しい ComplexValueオブジェクト返すメソッド
> > ComplexValue multiple();
> > もありますよね。
> > #java.lang.StringBuffer#append()がそうでした。
>
> StringBufferはmutableだからそれでいいんですけど、「値」として
> 使いたいオブジェクトがmutableだと後でドツボにはまるんじゃないで
> しょうか。

そんな予感はするのですが、具体的にどんなツボが待ちかまえているのか
書くことができません。マルチスレッドがらみでしょうか。?
mutableオブジェクトのフィールドへのアクセスメソッドは
synchronizedにしないといけなくなるとか。
その結果、スレッドがらみのバグが入りやすくなるとか。
#java.lang.Stringクラスには synchronizedメソッドはなく、
#java.lang.StringBufferクラスにはありました。

> ですから、副作用も欲しいのならComplexとMutableComplexを両方用
> 意する、それなら分かります。その場合MutableIntegerとか
> MutableDobuleとか全部作りましょうね :-)

なるほど、そういうふうに用意するのがよいのですね。

> > 返り値を無視すると、void multiple(); と同じ使い方ができます。
> > 結局、この最後の書き方が一番便利なんでしょうね。
>
> 便利で決めてはいけませんぜ。自分の主義で決めましょう。

はい、肝に命じておきます。
主義というほどのものではございませんが、強靭なクラスが
できたらいいなと思ってます。

--
E-mail: a...@nikongw.nikon.co.jp

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

雨宮さん:

> ただ、実行スピードを比較してみました所、オブジェクトを新しく作る方は、
> 作らない方に比べて、1.5倍程時間がかかりました。
> jdk1.1.5 on Solaris2.5.1(SS-10 33MHz)で 10000回のかけ算で、
> それぞれ、145msecと 94msecでした。

ベンチマークしたらそんなもんでしょう。実用プログラムとなった時
のオーバヘッドも知りたいですね。

> スピード命の方には耐えられないかもしれませんが、コードの可読性
> があがって、その結果バグ出しの時間が減るのなら私は満足です。

すばらしい。

> そんな予感はするのですが、具体的にどんなツボが待ちかまえている
> のか書くことができません。マルチスレッドがらみでしょうか。?

そんな難しいことしなくても、ある場所でずっと持ってる値をついどっ
かで外に渡してしまい、渡された方はそうとは知らずそれに対して掛け
算をする。すると突然、ずっと持ってる値がN倍に変化しちゃうですよ
ね。

こういうバグは取りにくいですよー 久野

> 主義というほどのものではございませんが、強靭なクラスができたら
> いいなと思ってます。

P.S. すばらしい主義です。ちなみに私は「美しい」というのを目指してい
ますがなかなか難しい(作るのも説明するのも)。

[N.Amemiya]

雨宮@Nikonです。

ku...@gssm.otsuka.tsukuba.ac.jpさま wrote:
>
> ベンチマークしたらそんなもんでしょう。実用プログラムとなった時
> のオーバヘッドも知りたいですね。

はい。実用プログラムでどうなるかが重要なデータということですね。
光線追跡プログラムをつくってますので、
完成したら時間を比べてみたいと思います。
Javaが「やってごらんよ」といっている分散環境での処理も
Immutableオブジェクトの方が親和性も良さそうですし。(?)

> > そんな予感はするのですが、具体的にどんなツボが待ちかまえている
> > のか書くことができません。マルチスレッドがらみでしょうか。?
>
> そんな難しいことしなくても、ある場所でずっと持ってる値をついどっ
> かで外に渡してしまい、渡された方はそうとは知らずそれに対して掛け
> 算をする。すると突然、ずっと持ってる値がN倍に変化しちゃうですよ
> ね。
>
> こういうバグは取りにくいですよー 久野

ありがとうございます。理解できました。
こういう基本的かつ重要なことを、いままで Java本で読んだことが
なかったんですが、私の脳が読み飛ばしていただけなんでしょうね。
OOPな方々には、常識なんでしょうね。

> > 主義というほどのものではございませんが、強靭なクラスができたら
> > いいなと思ってます。
>
> P.S. すばらしい主義です。ちなみに私は「美しい」というのを目指してい
> ますがなかなか難しい(作るのも説明するのも)。

ほめていただき、うれしいです。
#今夜は雪見酒で祝杯です。¥(^ ^)/ ばんざーい。
--
E-mail: a...@nikongw.nikon.co.jp

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

雨宮さん:
> はい。実用プログラムでどうなるかが重要なデータということですね。
> 光線追跡プログラムをつくってますので、完成したら時間を比べてみ
> たいと思います。

そうですね。蛇足ですが私は「まずすんなり動くように設計して作り、
速度が不満ならそのとき改めて考える」というのが好きです。

> Javaが「やってごらんよ」といっている分散環境での処理も
> Immutableオブジェクトの方が親和性も良さそうですし。(?)

よいポイントですね。

> こういう基本的かつ重要なことを、いままで Java本で読んだことが
> なかったんですが、私の脳が読み飛ばしていただけなんでしょうね。
> OOPな方々には、常識なんでしょうね。

いえ、Java本にはほとんど書いてないでしょう。手もとの本にも書い
てないし…困ったことですね ^_^;

手元の古い雑誌記事 ^_^; では結構詳しくmutable/immutableについ
て解説してあるようですが。

共有に伴う副作用というのは古くからある問題ですが、オブジェクト
指向になったら一層重要な問題なわけですから、きちんと書かれていて
しかるべきですよね。ついでに、データ抽象以前は「内部では書き換え
可能だが外から見た仕様としては書き換え不能に見える」というワザは
存在しなかったわけですし…

> #今夜は雪見酒で祝杯です。\(^ ^)/ ばんざーい。

いけるクチですね :-) 久野

[TAKAGI Hiromitsu]

In article <34FD08...@nikongw.nikon.co.jp>

"N.Amemiya" <a...@nikongw.nikon.co.jp> writes:
> > > ところで、この multiple()メソッドですが、上のように
> > > void multiple();
> > > で、そのインスタンスのフィールド(この場合、realPartなど)を
> > > 変えてしまうのがよいのか、それとも
> > > ComplexValue multiple();
> > > と新しい(この場合は) ComplexValueオブジェクトをつくって
> > > 返すほうがよいのか、いつも迷ってしまいます。
> >
> > 悩むこたないです。絶対、常に新しいオブジェクトを作るべきです。
> > 何のためのGCなの? Complex って複素数「値」のつもりでしょう?
>
> はい、値のつもりです。すっきりしました。ありがとうございます。

:
> ただ、実行スピードを比較してみました所、オブジェクトを新しく作る方は、
> 作らない方に比べて、1.5倍程時間がかかりました。

先日、Java for High-Performance Netowrk Computing というJavaに興味を持っ
た数値計算屋さん+αな人達のコミュニティのワークショップに出てきたので
すが、その基調講演で Gosling が、
Noting is decided, Don't depend it, It's just for discussion
と前置きしながらも、数値計算屋さん達からの要望の強い、
複素数プリミティブ、オペレータオーバーロード、多次元配列、丸め方向の
設定、実数に対する零除算等の exception 化、などなどについて、いくつか
の案を交えながら議論を見せてくれました。

その中で、複素数を普通のクラスとして用意すると遅くなる という問題
について、

final フィールドのみからなる final クラスはインライン展開される
ようにする。

という案 (Lightweight Objects) を示していました。

そこで例示された Complex クラスは、もちろん、首藤さんが Message-ID:
<SHUDOH.98...@cafe.olu.info.waseda.ac.jp> で示したものと同じ
ような構成で、フィールドとクラスが final になっているものでした。

そりゃそうです。私も賛成です。

高木 浩光＠名古屋工業大学
http://www.center.nitech.ac.jp/‾takagi/

[KANDO Takayuki]

神戸＠川崎です。

TAKAGI Hiromitsu <tak...@center.nitech.ac.jp> wrote in article

> > ただ、実行スピードを比較してみました所、オブジェクトを新しく作る方は、
> > 作らない方に比べて、1.5倍程時間がかかりました。

> その中で、複素数を普通のクラスとして用意すると遅くなる という問題
> について、
> final フィールドのみからなる final クラスはインライン展開される
> ようにする。
> という案 (Lightweight Objects) を示していました。

おお、そういう案が出ていますか。
そうなってくれれば、Complexに限らず使い捨ての小さなオブジェクトが
(気分的に)作り易くなりますね。

--
Kando. Takayuki <ka...@flab.fujitsu.co.jp>
High Performance Computing Research Center (FUJITSU LABORATORIES LTD.)
1015 KAMIKODANAKA, NAKAHARA-WARD, KAWASAKI-SHI, KANAGAWA, 211-88 JAPAN
Phone: (Intl Prefix)+81-44-754-2670