[#34011] Should --verbose be equal to -v ? — Yugui <yugui@...>

Yuguiです。

15 messages 2008/03/10
[#34012] Re: Should --verbose be equal to -v ? — Yukihiro Matsumoto <matz@...> 2008/03/10

まつもと ゆきひろです

[#34105] rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...>

rational と complex が組み込みになったことで、lib/mathn.rb の意義は薄

29 messages 2008/03/22
[#34106] Re: rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...> 2008/03/22

現時点で rational.rb と complex.rb を残しているのは、それが無難だから

[#34107] Re: rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...> 2008/03/22

で、かなり選択肢を絞った叩き台です。

[#34120] Re: rational.rb, complex.rb and mathn.rb — keiju@... (石塚圭樹) 2008/03/24

けいじゅ@いしつかです.

[#34125] Re: rational.rb, complex.rb and mathn.rb — Shin-ichiro HARA <sinara@...> 2008/03/25

原です。

[#34130] Re: rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...> 2008/03/25

> 私も Complex の組み込みは Rational とは比較にならないくらい、仕様が決め

[#34158] Complex組み込み — Masahiro TANAKA <masa16.tanaka@...>

Complexが組み込みになるそうですが、これはcomplex.rbを踏襲して、

49 messages 2008/03/27
[#34161] Re: Complex組み込み — Shin-ichiro HARA <sinara@...> 2008/03/28

原です。

[#34168] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/03/28

> 今までの Complex は、complex.rb にほぼ残して、たとえば Rational 成分

[#34186] Re: Complex組み込み — Shin-ichiro HARA <sinara@...> 2008/03/31

原です。

[#34187] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/03/31

> そうです。Complex が難しい、という話を書いておくと、

[#34193] Re: Complex組み込み — Yukihiro Matsumoto <matz@...> 2008/03/31

まつもと ゆきひろです

[#34203] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/04/01

> |僕としては、/ 演算子の振舞いについて前向きに検討してほしいです。

[#34215] Re: Complex組み込み — Yukihiro Matsumoto <matz@...> 2008/04/02

まつもと ゆきひろです

[#34166] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/03/28

> となるようですが、別の実装として、

[ruby-dev:34178] Re: Complex組み込み

From: Masahiro TANAKA <masa16.tanaka@...>
Date: 2008-03-28 18:29:48 UTC
List: ruby-dev #34178
Tadashi Saitoさんは書きました:
> 斎藤と申します。鋭いかは分かりませんが、できるだけ短めに別角度のツッコミを。

考えていなかった観点をご提示いただき、参考になります。
ありがとうございます。

> >   (2) CやFORTRANの複素数型をラップした、実部・虚部がdouble型の複素数クラス
> 
> 上記案は、互換性の観点では鵜呑みにするのは難しそうですが、それ以外の点でも
> あまりうれしくないかもしれません。というのも、そこまでしなくても
> 
> >  a. 速度で格段に有利。
> 
> になり得るからです。(sizeof(VALUE)*8 == 64bitマシン限定ですが) 笹田さんが
> 以前からおっしゃっていて、先日発表なさった「Float埋め込み」がマージされれば
> 「何もしなくても」現状のComplexのままで高速になると思います。
> 
> Complexインスタンス本体は include/ruby/ruby.h で
> 
> struct RComplex {
>     struct RBasic basic;
>     VALUE real;
>     VALUE image;
> };
> 
> と宣言されていますが、笹田さんの方法ですと既存のRubyスクリプトのみならず、
> API (DOUBLE2NUM()/RFLOAT_VALUE()) を利用してFloat(== double)を利用している
> Cプログラムもすべて、その高速化の恩恵にあずかれるからです (よね?)。

なるほど。これだとクラスチェックが余分にかかるくらいでdoubleを取り出せ
ますね。ただ、演算をおこなう場合は、さらにrealのメソッドを呼ぶので、
そのコストが気になりました。

> もう一つ、
> 
> >  c. 拡張ライブラリからアクセスしやすい。
> 
> というのは
>   double d = RCOMPLEX(val)->real;
> と書ける(かもしれない)から、ということと解釈してよろしいのでしょうか。
> 
> もし上記についてならば、マクロを定義して
>   dobule d = RCOMPLEX_REAL(val);
> とすれば、自分は十分にアクセスしやすく感じますし、タイプ数は逆に減ります。

  complex c = RCOMPLEX_VALUE(val);

とできて、(できるんでしょうね)しかもメモリーコピーですむとよい、
と思ったのでした。

> また1.8と比べて、1.9ではRFOO(obj)でキャストするマクロを用いて直接構造体の
> メンバを読み取るのは、非推奨になる流れのただ中だと思います。せっかく
> 統一的なインタフェースが一斉に作られようとしている時に「RFOO(obj)->member」が
> 必要ならば、「例外的に扱う必要がある」という意味でアクセスしにくく感じます。
> 
> よって c にはあまり説得力がないと思うのですが、どうでしょうか。
> (自分の解釈が間違っているなら、それがまず悪いので御指摘いただけるとありがたい
> です ^^;)

こういう情報は、考えたり納得したりする上で重要だと思います。
ありがとうございます。

田中昌宏

In This Thread