[#39464] Re [ruby-dev:23297] 大文字・小文字の区別がDOSISHかどうかで変わる、パス名マッチ関数の提案 — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>

山本です。

25 messages 2004/04/01
[#39608] Re: Re [ruby-dev:23297] 大文字・小文字の区別がDOSISHかどうかで変わる、パス名マッチ関数の提案 — pegacorn@... 2004/05/02

遅い反応&File.fnmatchは使った事ない&ruby-devの方では

[#39609] Re: Re [ruby-dev:23297] 大文字・小文字の区別がDOSISHかどうかで変わる、パス名マッチ関数の提案 — pegacorn@... 2004/05/02

File.fnmatch(と Dir.glob)をちょっと使ってみたのですが、

[#39610] Re: Re [ruby-dev:23297] 大文字・小文字の区別がDOSISHかどうかで変わる、パス名マッチ関数の提案 — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2004/05/02

山本です。

[#39611] Re: Re [ruby-dev:23297] 大文字・小文字の区別がDOSISHかどうかで変わる、パス名マッチ関数の提案 — matz@... (Yukihiro Matsumoto) 2004/05/02

まつもと ゆきひろです

[#39613] Re: Re [ruby-dev:23297] 大文字・小文字の区別がDOSISHかどうかで変わる、パス名マッチ関数の提案 — pegacorn@... 2004/05/02

From: matz@ruby-lang.org (Yukihiro Matsumoto)

[#39616] Re: Re [ruby-dev:23297] 大文字・小文字の区別がDOSISHかどうかで変わる、パス名マッチ関数の提案 — matz@... (Yukihiro Matsumoto) 2004/05/02

まつもと ゆきひろです

[#39620] Re: Re [ruby-dev:23297] 大文字・小文字の区別がDOSISHかどうかで変わる、パス名マッチ関数の提案 — pegacorn@... 2004/05/03

From: matz@ruby-lang.org (Yukihiro Matsumoto)

[#39621] Re: Re [ruby-dev:23297] 大文字・小文字の区別がDOSISHかどうかで変わる、パス名マッチ関数の提案 — matz@... (Yukihiro Matsumoto) 2004/05/03

まつもと ゆきひろです

[#39622] Re: Re [ruby-dev:23297] 大文字・小文字の区別がDOSISHかどうかで変わる、パス名マッチ関数の提案 — pegacorn@... 2004/05/03

From: matz@ruby-lang.org (Yukihiro Matsumoto)

[ruby-list:39553] Re: int/int in Ruby2?

From: Masaaki Sakano <mas@...>
Date: 2004-04-15 04:27:44 UTC
List: ruby-list #39553
坂野 正明です。

議論が結構盛り上がっていて、嬉しく思います。

一点。現在の Ruby の仕様の理解が十分でない場合がしばしばありそうに
拝見しました。
# つまり、それくらい、「/」は一般的なのに、.quo とかはなかなか一般的
# にならない(導入されたのが比較的最近なのも大きな理由でしょうけど)…
# というわけで、やはり「/」の挙動は重要ポイント、Ruby2 で変えられる
# ものなら…、という意を強くしたものでありますが。
拙投稿で恐縮ですが、[ruby-list:39453] に現在の仕様のポイントを簡単に
まとめてありますので、必要でしたら御参照下さい。
必須キーワードは、
  ・rational
  ・mathn
  ・quo
  ・div   (divmod も参考に)
辺りでしょうか。
気になるのは、整数への「/」で、C言語との"一致"を言う人を散見しますが、
現在、Ruby の「/」とC言語の「/」との挙動は"異なります" (似ていますけど)。


[ruby-list:39484] で私の意見のまとめとして、
	int/int => rational
と書いていますが、この表現は多少、誤解を招く部分があったかも知れません。
表現したかったのは、
	rational/rational => rational
が原則とし、分子、分母、結果いずれも、当たりが出れば Integer
(Fixnum/Bignum) になり得るという形になりましょうか。
         6/2        => 3         (分子、分母、結果とも Fixnum)
         6/(3分の2) => 9         (分子、結果が Fixnum、分母は Rational)
  (2分の3)/(3分の2) => 1         (分子、分母が Fixnum、結果は Rational)
  (2分の3)/(7分の2) => (3分の7)  (分子、分母、結果とも Rational)
要するに、現在、mathn を require した時の挙動そのものですが。

この利点については、[ruby-list:39484] で私見をまとめておりますので、
ここで再度述べることは避けます。

このように「/」を除算にすることで、Polymorphic な状態に(Rational
以下の範囲内で)最も近くなりそうですね ([ruby-list:39473] [ruby-list:39484])。
# Polymorphism (ポリモルフィズム) は、Ruby本(まつもと/石塚; アスキー)で
# 「動的結合」(4.1章)と訳されているもの。メッセージ(演算)を送る際に、
# データ型を意識しなくて良い、という概念、と理解しています。


なお、もちろんこれとは少し異なって、Rational というクラスを厳然と
Integer とは異なったものとしてユーザーに意識させる仕様も一つの考え方
でしょう。現在、rational のみを require した時の挙動です。
(私は mathn 仕様の方が優れていると感じますが、あえて考えますに)その
場合でも、そんなに困ることはないように思います。弊害は、
「Integer === foo」のような書き方をしている場合でしょうか(ご存知の
ように、これは、Ruby ではあまり推奨されていない書き方のようですが)。
これ以外の困る場合は、結局、「/」が整除でないと困る場合、と
同じことになりましょうか。具体的には、[ruby-list:39484] で私見を
述べております --- 十分かどうかは皆様の御判断を仰ぐとして。


別の場所で議論していて気付いたことですが、integer (クラスの
オブジェクト)の演算だから結果も integer で自然という意見を見ました。
これは説得力を感じませんでした。というのも、現在でも、
	bignum/bignum => fixnum
というように、クラスが変わる例はいくらでもあります。あるいは、
仮に Fixnum クラスの下に偶数クラス、奇数クラスというのを定義して
みた場合を考えてみてはどうでしょう。
	奇数 + 奇数  => 奇数(!)
なんて仕様にしたとすると、かなり奇妙に感じます。
他はいざ知らず、数の演算の場合は、クラスを強くは意識せずともシーム
レスにつながっていた方が、驚かなくて済みましょう。

今回の議論で、私が最も説得力を感じた表現は、藤高さんの ↓ でした。
| Subject: [ruby-list:39530] Re: int/int in Ruby2?
| Message-Id: <20040410124125.FBD4.FUJITAKA@kt.rim.or.jp>

| 長い目でみたら人間の思考コストは軽減される気がします。
| Rubyでは思考コストを追求し、

そう、思考コストを問題にしたいですね。長い目で見た時の。


-----

さて、以下は余談です。本題から離れますので、興味のある方だけ。

[ruby-list:39552]
At Thu, 15 Apr 2004 10:23:41 +0900,
<taca@back-street.net> wrote:
> In message <OF1B254A83.4FA7C9F0-ON49256E74.002F1D06@mail.dnp.co.jp>
> 	on Mon, 12 Apr 2004 17:34:41 +0900,
> 	Itou-T15@mail.dnp.co.jp wrote:
> > 手計算に一致する、でしょうか?
> > 
> > たぶん内容的には、十分な桁数の10進演算あたりかな
> > 小数部が長い時は切り捨てられてもしょうがない。
> > そうでないときは数学と一致。
> こういう計算を行う電卓のようなアプリケーションはあってもよいかもしれま
> せん。しかし、数値演算一般に適用するには曖昧で、実装も使い勝手も悪いで
> しょう。

「小数部が長い時は『切り捨て』」たりすると、曖昧になり得ますが、
通常のリテラルの数字は(切り捨てなしに)正確に rational (integer も含む)
として扱うなら、曖昧にはなり得ないと思います。
1.5 とあれば 3/2 (2分の3) になるだけですから。
# 1.5e2 とあれば、150 になるだけですね。指数表記のリテラルも
# rational として扱うかどうかは別問題として。

実装も複雑とは思えません。感じとしては、たとえば、[ruby-list:35966]
を、コアの部分として使えばいいわけです。パーサーが数字と判断した
部分の文字数を桁数(の保守的な見積り)として渡してやる、と。
# [ruby-list:35966] は、Float-to-Rational なので、実際は完全に
# 同じわけではありませんが。

使い勝手も、ほとんどいいことばかりだと思いますが。
悪くなることは、
  ・速度が落ちる
	→ Float にすればいいだけですね。
	   Float用のリテラルを用意するのが一番スマートでしょうか。
	   Float() などで変換してもいいわけですが。
  ・(リテラルを書く必要が出ることで)Float 数字を書き込む手間が増える
	→ 思考コスト優先の Ruby で、Float をどうしても使いたい場面が
	   そんなに多い気はしないのですが…?
  ・他言語のプログラムからRubyへの移植の手間が若干増える?
	→ Float の丸め誤差まで完全に一致させたい場合はそうかも
	   知れませんが、そこまで必要な場合が多いかは???
	   いずれにせよ、それが移植のボトルネックになるとは考えにくい?
  ・他言語習得者がRuby屋に乗り換える時、違和感を感じる??
	→ Float でないと生理的に我慢できない、という場合(と速度が
	   必要な場合と)を除けば、習慣通り、(5.6 などと)書いて
	   もらって問題ないでしょう。
	   # その"他"言語で、"5.6" と表記すれば、Floatを指すと仮定して。
くらいかと考えます。
つまり、問題にならない、と。


ただ…、"余談"と断りました通り、そういうこともできるし、それはそれで
悪くない(個人的には、いい)とは感じますが、これを Ruby2 の仕様へと
強く主張するつもりは全然ありません。

--
坂野 正明


In This Thread