07/04/30 22:28:02
>>906-909
PGが絶対口にしてはいけない一言
ｽﾚﾘﾝｸ(tech板)l50
911:デフォルトの名無しさん
07/05/01 01:55:23
>>889
ライブラリにクラスを追加するとか、演算子オーバーロードが出来るようにするとか
よりも、プリミティブな複素数型を言語に追加してくれってこと。
複素数は機種依存するもんじゃないし、
たとえばFFTや平面座標上の点の計算に活躍する。
912:デフォルトの名無しさん
07/05/01 02:00:43
小数点演算すらソフトウェア実装なのに面倒なことさせるな。
913:デフォルトの名無しさん
07/05/01 07:17:37
> 現時的に業務に絡んでないやつらが多すぎなんじゃ？
現実的に国内で業務システムに絡んでる奴は
頭弱すぎて割り込めないだけ。
914:デフォルトの名無しさん
07/05/01 07:49:23
>>911
> たとえばFFTや平面座標上の点の計算に活躍する。
の用途のために、何故
> プリミティブな複素数型を言語に追加してくれってこと。
が必要なのかわからん。クラスじゃ何でダメなんだ？
あと「プリミティブな」ってVM変更（バイトコードインストラクションを拡張）しろって話？
たぶん、そんな要求してもマトモに相手にされないと思うけど。
915:デフォルトの名無しさん
07/05/01 08:19:29
この人は、単に複素数リテラルと演算子のオーバロードが欲しいだけだと思う。
言葉が不自由なので、自分の要求を正しく伝えられないのでは？
916:デフォルトの名無しさん
07/05/01 08:35:19
>VM変更（バイトコードインストラクションを拡張）しろって話？
言語仕様の追加みたいだけど、どこからVM仕様追加の話になるんだ？
C99のようにゴニョゴニョっとまねして、チャチャッ実装しちゃってくれってことじゃないのか。
まあ、あれば便利だし、有難く使わせてもらうけど。
917:デフォルトの名無しさん
07/05/01 08:42:26
自分で実装してJCPに提案しろｗ
918:デフォルトの名無しさん
07/05/01 08:54:09
演算子をオーバーロードして、BigDecimalの割り算はどうやって丸め指定を表現するんだろ
919:デフォルトの名無しさん
07/05/01 08:56:26
Javaの複素数演算用クラスって、どっかになかったか？
いちいち、引数をとらないといけないし、Fortranなどマシン語レベルの
ライブラリ充実している言語と比べると、スピードが出ないだろうけど、
だからといって、VM仕様から変更は影響が大きすぎるだろ。
920:デフォルトの名無しさん
07/05/01 09:06:24
>VM仕様から変更
だからどうしてVM仕様変更の話になるんだと小一時間（ｒｙ
921:デフォルトの名無しさん
07/05/01 09:14:02
>>920
URLﾘﾝｸ(java.sun.com)
922:デフォルトの名無しさん
07/05/01 09:36:30
>>912
strictfpで宣言しない限り結局はFPUに計算させてない？
923:デフォルトの名無しさん
07/05/01 10:37:21
>>916
>>911 の
> ライブラリにクラスを追加するとか、演算子オーバーロードが出来るようにするとか
> よりも、プリミティブな複素数型を言語に追加してくれってこと。
から。
クラスもダメで、演算子オーバーロードもダメで（たぶんリテラルもダメ）、
プリミティブな型を追加と言われたらバイトコード拡張なのか？ ってのは至極当然。
924:デフォルトの名無しさん
07/05/01 11:13:54
意味なしリクエストは却下
925:デフォルトの名無しさん
07/05/02 04:33:33
>>916
>>921
>>923
それがどうやって実装されるかということを君達がアレコレ妄想する必要はない。
それがあればどう世界が変わるかだけを考えろ！
926:デフォルトの名無しさん
07/05/02 07:43:02
まったく変わらない。
以上
927:デフォルトの名無しさん
07/05/02 08:46:01
>>915
複素数リテラルって何？
3.1i
1 + 2i
"3 + 4i"
とかのことか
それと演算子オーバーロードは、
Complex,Matrixクラスの話題とよくセットで出てくるが、
その程度で演算子オーバーロードを実装するのはコストが
高いなどの論点とは今回は関係ないようだ。
おまえは思い込みが激しいようだな。
928:デフォルトの名無しさん
07/05/02 08:57:25
言語不明瞭意図不明。
929:デフォルトの名無しさん
07/05/02 09:03:14
>>927
>>928
おまえ誰だよ。早く消えちまいな。
930:デフォルトの名無しさん
07/05/02 09:35:38
野次と荒らしは2chの花
931:デフォルトの名無しさん
07/05/02 11:39:25
>>930
ｦﾀとDQNが抜けてるぞ
932:デフォルトの名無しさん
07/05/03 06:00:15
>>925
どう実装されるかはしらんが、プリミティブ型を追加するという時点でVMに手をいれないといけないのは決定だろ。
933:デフォルトの名無しさん
07/05/03 09:20:31
C99だと
struct complex {double real, imag;}
struct complex {double z[2];}
とかで実装されてるんじゃないか。
だからコンパイラの拡張のみでマシーン（VM)の方に手を入れることはない。
というか、一般人が実装のことを考える事自体が意味ないじゃん。
934:デフォルトの名無しさん
07/05/03 09:32:36
配列で大量に計算する用途だとクラスよりC#の値型のようなものがあるとベターだな。
935:デフォルトの名無しさん
07/05/03 09:58:40
>>933
えーと。
結局、プリミティブな複素数型は特に必要がなくてクラスでやってもOKって話かな？
本当に複素数型欲しいなら
現時点でGPLで配布されてる javac に複素数型導入して公開したり、
そのパッチを ksl に投稿してみるとか、
BugDatabaseに行って、RFE出すとか既存のRFEに投票するとか、
その bugID 晒して、皆に投票呼びかけたりとか、
もちっと前向きな行動した方が良いと思うよ。
ここで複素数追加みたいなネタ振られたって、
皆でどーゆー実装するのか妄想して遊ぶぐらいしかできないでしょ。
936:デフォルトの名無しさん
07/05/03 10:09:09
座標上の点の計算には便利そうだ。特に回転とか。
複素数クラスがあってもnewしまくるから遠慮してたけど、
言語に追加されるなら便利そうだけどな。
今のトレンドは言語に複素数を追加することなんじゃないか。
C,D,Pythonは既に言語レベルでサポートしてるし。
937:デフォルトの名無しさん
07/05/03 10:25:59
トレンドってほど支持する流れも否定する流れも大きくないと思うが……
938:デフォルトの名無しさん
07/05/03 10:37:45
>>933
頭悪そう
C99を使ってろ
939:デフォルトの名無しさん
07/05/03 10:53:07
>>936
ちなみに、何を作りたくて複素数型が必要なんだ？
940:デフォルトの名無しさん
07/05/03 10:57:23
>>934
C#の値型は、クラスと比べてどんなメリットがあるの？
コンパイル時に最適化されて
ランタイム負荷が小さいとか？
941:デフォルトの名無しさん
07/05/03 12:34:41
>>940
クラスのオブジェクトに比べ生成と削除のコストが低い。
値型は参照を介せずにスタックに直接値が格納されたり、
配列やクラスのメンバーとして直接その領域に値が格納されるので
ボクシングが発生しない限りGCの必要な実体が作られることがない。
このためプリミティブ型に近いパフォーマンスを発揮する。
942:デフォルトの名無しさん
07/05/03 12:45:20
>>939
必要ないんでしょ。
ってか、実際に複素数型が必要な分野のプログラム組んでる人間が
「演算子オーバーロードよりもプリミティブな複素数型」なんて言うとは考えられないし。
943:デフォルトの名無しさん
07/05/03 14:50:30
>>941
値型ってのが広い範囲を表すからいいたいことがあいまいだぞ
944:デフォルトの名無しさん
07/05/03 15:00:41
下手に構造体チックなものが登場されてもBeanの文化が壊れるから
ByteBufferで我慢が出来ないなら諦めてくれって方針で十分。
945:デフォルトの名無しさん
07/05/03 19:32:28
>>933
だから、それはプリミティブ型じゃないだろ。
946:デフォルトの名無しさん
07/05/03 20:49:44
Ｃ＃の値型みたいなのがほすぃ
って言いたかっただけなんじゃないか、と。
947:デフォルトの名無しさん
07/05/03 21:32:14
>>946
Java に C# の値型みたいなの導入すると
コンパイラ弄るだけじゃすまなくて、それこそ VMの変更が必要なりそうだし。
メソッドの戻り値で値型を使う場合とか。
それに、C# は最初から値型があったから良いけど、
Java の場合は generics 導入しちゃった後だからねぇ。
今から C# の値型みたいなものを追加したとしても
現時点でのプリミティブ型みたいに generics で使えなさそうだし。
948:デフォルトの名無しさん
07/05/03 21:52:46
Javaも遅かれ早かれVMの拡張は必要になると思うのだがいつごろ来ると思う？
949:デフォルトの名無しさん
07/05/03 22:05:05
>>948
おいおい……
バイトコードインストラクションの話ならJSR-292のinvokedynamic追加の検討中。
後は>>893がfunction type関連でVM拡張とか言ってる。
950:デフォルトの名無しさん
07/05/03 22:13:31
>>949
さんくす。複素数の議論でVM拡張は避けるべき的な話が出てたので確認してみた。
別にVM拡張前提で話をしてもかまわないわけだよね。
951:デフォルトの名無しさん
07/05/03 22:21:32
>>950
ここは「次世代Javaの動向」をヲチるスレだから、
新機能追加の要望とか、単なる妄想オナニーなら他所でやってくれ。
952:デフォルトの名無しさん
07/05/03 22:24:40
だれもVM拡張は避けろといってなくて、プリミティブ型を追加するならVM変更という話と、そんな無意味な要求は却下されるよという話が同時進行してただけかと。
953:デフォルトの名無しさん
07/05/03 22:28:41
>>951
ヲチするだけとはどこにも書いてないわけで。
しかも、最初から要望とか妄想オナニーばかりのスレで、950も過ぎてから言ったところで説得力ない。
954:デフォルトの名無しさん
07/05/03 22:32:05
>>953
今回ので言えば、既に >>935 で他所行けって出てるし。
他の話題でも他所行けってのは散々出てるし。
955:デフォルトの名無しさん
07/05/03 22:38:34
つまり、スレの流れについていけなくてわめいてるってわけか。
956:デフォルトの名無しさん
07/05/03 22:41:32
>>953
便所に落書きしても要望だとは思われないよな。普通は。
957:デフォルトの名無しさん
07/05/04 01:17:58
複素数を扱うライブラリがあれば便利だと思うが
言語仕様に含めるのはやり過ぎです。
ところで値型って、VBのByValを指しているの？
958:デフォルトの名無しさん
07/05/04 01:45:44
>>957
ここは予想や感想を述べる場所じゃないとのことなので、
そういう動向は今のところ無いということでおしまいらしい。
値型はVB.NET以降では、ユーザー定義型（Structure）、Enum、クラスを除くVBの基本データ型をさす。
VBのデータ型と.NET(CLR)のプリミティブ型は若干違うから注意。
ここではユーザー定義型（Structure）の意味で使ってる。
.NET(CLR)ではValueType C#ではstruct。
Javaだと参照型以外の型＝プリミティブ型＝値型という理解でいいのかな？（自信は無いが）
あとは質問か雑談スレへとかいわれそうだ。
959:デフォルトの名無しさん
07/05/04 03:50:43
>>956
「普通は。」ってなんだよ 9m(^x^
960:デフォルトの名無しさん
07/05/04 09:51:42
C#：全部ヒープに置いたら遅いだろ！struct導入する！
Java：エスケープ分析で自動的にスタックに置くｳﾏｰ
961:デフォルトの名無しさん
07/05/04 12:14:58
どうもsturct(値型）の話になってるようだけど、なんなら
typedef double complex[2];
でいいじゃん。どう実装されるかなんかはベンダ任せなんだけどね。
962:デフォルトの名無しさん
07/05/04 19:07:54
ベンダ任せなわけがない
963:デフォルトの名無しさん
07/05/04 20:59:25
Hさん、居るよね。
964:デフォルトの名無しさん
07/05/05 21:03:27
MさんとKさんもいるよね。