[#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:34176] Re: Complex組み込み

From: Tadashi Saito <shiba@...2.accsnet.ne.jp>
Date: 2008-03-28 16:36:50 UTC
List: ruby-dev #34176
斎藤と申します。鋭いかは分かりませんが、できるだけ短めに別角度のツッコミを。

On Fri, 28 Mar 2008 01:52:09 +0900
Masahiro TANAKA <masa16.tanaka@gmail.com> wrote:

>   (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プログラムもすべて、その高速化の恩恵にあずかれるからです (よね?)。

# 上記Float高速化のマージ以前にも、Complex/Rationalを特化命令を対応させて
# 高速化を期待する方法もあります。よね…

もう一つ、

>  c. 拡張ライブラリからアクセスしやすい。

というのは
  double d = RCOMPLEX(val)->real;
と書ける(かもしれない)から、ということと解釈してよろしいのでしょうか。

もし上記についてならば、マクロを定義して
  dobule d = RCOMPLEX_REAL(val);
とすれば、自分は十分にアクセスしやすく感じますし、タイプ数は逆に減ります。

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

よって c にはあまり説得力がないと思うのですが、どうでしょうか。
(自分の解釈が間違っているなら、それがまず悪いので御指摘いただけるとありがたい
です ^^;)

-- 
斎藤ただし

In This Thread