ruby-dev

えぐち＠エスアンドイー です。

>>> In message [ruby-dev:8869] Re: DoubleFloat
    On Fri, 7 Jan 2000 15:08:06 +0900, gotoken@math.sci.hokudai.ac.jp (GOTO Kentaro) said:

ご> In message "[ruby-dev:8867] Re: DoubleFloat"
ご>     on 00/01/07, EGUCHI Osamu <eguchi@cagiva.shizuokanet.ne.jp> writes:
ご> >ところで、SigleFloat の存在理由ってどういう物がありますか？
ご> >SingleFloat の特徴を考えると、、
ご> >
ご> > + メモリ消費量は殆んど変わらない
ご> > + 演算速度は殆んど変わらない
ご> >   (C 言語が float を double に昇格して演算するので)
ご> > + 精度か落ちる
ご> >
ご> >の様に思え、これだけを見ると存在価値に少々疑問を感じます。
ご> >＃むしろ C の long double に対応するクラスが望まれているかも、
ご> 
ご> 主に精度の問題です。実測データの多くは1に十分近い値であり、
ご> なおかつ精度も高々4桁くらいしかありません。そのため数値デー
ご> タはfloatのビットマップとして扱うことが通例であるという点が
ご> まず1点。それから多くのfortranのライブラリ関数は単精度のイン
ご> ターフェイスを持っていますが、毎度キャストするのは効率が悪い
ご> 上に、精度的に問題があります。

いまの Float が必要以上の精度を持っている(局面がある)
と言う事については同感ですが、かといって、、
  精度を落しても、メモリ消費や演算速度に良い影響が期待できない以上、
  系を複雑にしてまで、導入する動機は希薄に思える。
と言うのが私の意見です。

それとも、低精度の実数の「精度が低い事」そのもの価値を
見い出しているのでしょうか？

また C では、float -> double -> float の２回の型変換で、
精度が失われない事を処理系に要求していますので、これ自体が
現状で精度に問題を生じてはいないと思います。

＃内部表現は float でも演算の度に double に昇格するのが
＃C 言語の仕様ですので、(暗黙の)キャストは不可避です。

ご> これらの点を昔まつもとさんに認められて実装は自分でしてねって
ご> ことでお墨付をいただいた次第です。

「お墨付」には弱いのですが(笑)
上の理由で、SingleFloat の必要性や有用性に若干の疑問を感じます。

ご> >＃むしろ C の long double に対応するクラスが望まれているかも、
ご> 
ご> long double というか拡張倍精度形式に自由度があって処理系依存
ご> 性が高いので低速なソフトウェア実現をしないといけないでしょう。

処理系への依存性は確かに高いですが、たとえば、

  #include <stdio.h>
  main()
  {
    printf("%u\n", sizeof (long double));
  }

って大体今の処理系では通りませんか？
＃ただ、例えば printf() が "%lf" をサポートしているか等は微妙！
また、long double をサポートしていない処理系では、
ソフトウェアによる実装よりも、未サポート例外か、Float で代替
が良いように思えます。

ご> >まだ実装には移していませんが、この種のアプローチ(高速低精度な実数)に
ご> >需要はあるでしょうか？
ご> 
ご> 数値の需要は高速性よりも、ポータビリティの要求が大きいです。
ご> その点でいうと、浮動小数点数ではなく2バイト整数というのが欲
ご> しい局面は結構あります。ちなみに整数の規約はCのレベルにしか
ご> 存在しないためにずっと緩いので、2バイト整数の実装は面倒です。

あぁ、なるほど、結局 C の float や short の挙動と完全に一致する
クラスを(データの)ポータビリティの為に欲しいと言う事ですね。
特に精度についての互換性を要求している様に思えますが、
この理解であってますか？

	えぐち

Thread

Prev Next

In This Thread

Prev Next

[#8797] some peep hole optimizations and etc. — nobu.nakada@...

[#8817] Cross Compiling Ruby — WATANABE Hirofumi <eban@...>

[#8820] BEGIN as stmt. ? — EGUCHI Osamu <eguchi@...>

[#8824] [REQ] Integer#{hex,dec,oct,bin}, String#bin — gotoken@... (GOTO Kentaro)

[#8828] Re: [ruby-list:20054] Re: == === case — Shugo Maeda <shugo@...>

[#8848] cvs — gotoken@... (GOTO Kentaro)

[#8858] [PATCH] 2000/1/5 ruby_1_4 commit — Katsuyuki Komatsu <komatsu@...>

[#8859] [PATCH] 2000/1/5 1.5.0 commit — Katsuyuki Komatsu <komatsu@...>

[#8866] DoubleFloat — gotoken@... (GOTO Kentaro)

[#8886] Complex#divmod — Masahiro TANAKA <masa@...>

[#8893] Re: [ruby-list:20142] Re: Range expansion? — Akinori MUSHA aka knu <knu@...>

[#8900] [BUG] Marshal.dump — Koji Arai <JCA02266@...>

[#8927] [PATCH] Ruby/Tk (tktext.rb and tkcanvas.rb) — nagai@...

[#8930] [PATCH] SEGV at alias & super in module — nobu.nakada@...

[#8932] isnan.c NaN — "Shigeo Kobayashi" <shigeo@...>

[#8941] [BUG] recycle the ruby_dyna_vars — Koji Arai <JCA02266@...>

[#8953] rb_str2inum() — "Shigeo Kobayashi" <shigeo@...>

[#8959] [PATCH] getoptlong.rb — nobu.nakada@...

[#8980] 1.4.3 patch for near-future *BSD IPv6 support — Jun-ichiro itojun Hagino <itojun@...>

[#8986] sort — gotoken@... (GOTO Kentaro)

[#9004] DEFAULT_KCODE in rbconfig.rb — OKUNISHI -GTO- Fujikazu <fuji0924@...>

[#9007] too many warn — Minero Aoki <aamine@...>

[#9008] [PATCH] Array#flatten! for recursive array — nobu.nakada@...

[#9024] Re: [ruby-math:00115] Re: precedence of ** — matz@... (Yukihiro Matsumoto)

[#9025] % — "Shigeo Kobayashi" <shigeo@...>

[#9029] [1.4.3 BUG] Dir.grab["/*"] — gotoken@... (GOTO Kentaro)

[#9042] Ruby's overhead — "Shigeo Kobayashi" <shigeo@...>

[#9043] getrlimit — WATANABE Hirofumi <eban@...>

[#9044] setitimer — WATANABE Hirofumi <eban@...>

[#9047] rb_read_check is missing in rubyio.h — kenn@...

[#9048] [PATCH] OS/2 patch improved for 1.5.0 — kenn@...

[ruby-dev:8870] Re: DoubleFloat

Thread

In This Thread

[#8932] isnan.c 　 NaN — "Shigeo Kobayashi" <shigeo@...>