[#5809] mod_ruby-0.0.7 — Shugo Maeda <shugo@...>

前田です。

63 messages 1999/03/01
[#5845] Re: mod_ruby-0.0.7 — Shugo Maeda <shugo@...> 1999/03/01

前田です。

[#5860] Re: mod_ruby-0.0.7 — moochan <moochan@...> 1999/03/02

moochan です.

[#5892] Re: mod_ruby-0.0.7 — Shugo Maeda <shugo@...> 1999/03/02

前田です。

[#5855] Re: mod_ruby-0.0.7 — Shugo Maeda <shugo@...> 1999/03/01

前田です。

[#5919] Re: mod_ruby-0.0.7 — Shugo Maeda <shugo@...> 1999/03/03

前田です。

[#5895] [REQ] 中置の def — EGUCHI Osamu <eguchi@...>

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

18 messages 1999/03/02
[#5907] Re: [REQ] 中置の def — EGUCHI Osamu <eguchi@...> 1999/03/03

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

[#5965] Re: Precision in Mathematica (Re: Bigfloat) — keiju@... (石塚圭樹 )

けいじゅ@日本ラショナルソフトウェアです.

28 messages 1999/03/04
[#5981] Re: Precision in Mathematica (Re: Bigfloat) — gotoken@... (GOTO Kentaro) 1999/03/04

ごとけん

[#6053] Re: Precision in Mathematica (Re: Bigfloat) — matz@... (Yukihiro Matsumoto) 1999/03/06

まつもと ゆきひろです

[#6150] Re: Precision in Mathematica (Re: Bigfloat) — matz@... (Yukihiro Matsumoto) 1999/03/09

まつもと ゆきひろです

[#6159] Re: Precision in Mathematica (Re: Bigfloat) — EGUCHI Osamu <eguchi@...> 1999/03/09

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

[#6197] Re: Precision in Mathematica (Re: Bigfloat) — keiju@... (石塚圭樹 ) 1999/03/10

けいじゅ@日本ラショナルソフトウェアです.

[#6203] Re: Precision in Mathematica (Re: Bigfloat) — EGUCHI Osamu <eguchi@...> 1999/03/10

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

[#6224] Re: Precision in Mathematica (Re: Bigfloat) — keiju@... (石塚圭樹 ) 1999/03/11

けいじゅ@日本ラショナルソフトウェアです.

[#6238] Re: Precision in Mathematica (Re: Bigfloat) — EGUCHI Osamu <eguchi@...> 1999/03/11

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

[#6302] Re: Precision in Mathematica (Re: Bigfloat) — keiju@... (石塚圭樹 ) 1999/03/12

けいじゅ@日本ラショナルソフトウェアです.

[#6304] Re: Precision in Mathematica (Re: Bigfloat) — EGUCHI Osamu <eguchi@...> 1999/03/12

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

[#5970] [REQ] variable of regex — keiju@... (Keiju ISHITSUKA)

けいじゅ@日本ラショナルソフトウェアです.

43 messages 1999/03/04

[#6090] Thread#kill — Shugo Maeda <shugo@...>

前田です。

24 messages 1999/03/08

[#6328] Re: Ruby 1.3.1-990315 — WATANABE Hirofumi <watanabe@...>

わたなべです.

41 messages 1999/03/15
[#6329] Re: Ruby 1.3.1-990315 — matz@... (Yukihiro Matsumoto) 1999/03/15

まつもと ゆきひろです

[#6331] Re: Ruby 1.3.1-990315 — Wakou Aoyama <wakou@...> 1999/03/15

青山です。

[#6338] Re: Ruby 1.3.1-990315 — matz@... (Yukihiro Matsumoto) 1999/03/16

まつもと ゆきひろです

[#6347] Re: Ruby 1.3.1-990315 — Wakou Aoyama <wakou@...> 1999/03/16

青山です。

[#6348] Re: Ruby 1.3.1-990315 — matz@... (Yukihiro Matsumoto) 1999/03/16

まつもと ゆきひろです

[#6350] Re: Ruby 1.3.1-990315 — Wakou Aoyama <wakou@...> 1999/03/16

青山です。

[#6353] Re: Ruby 1.3.1-990315 — matz@... (Yukihiro Matsumoto) 1999/03/16

まつもと ゆきひろです

[#6354] Re: Ruby 1.3.1-990315 — Wakou Aoyama <wakou@...> 1999/03/16

青山です。

[#6434] Time#+ — Koji Arai <JCA02266@...>

新井です。

19 messages 1999/03/22
[#6442] Re: Time#+ — matz@... (Yukihiro Matsumoto) 1999/03/22

まつもと ゆきひろです

[ruby-dev:6145] Re: Range (Re: array[last..first] (Re: Subseq of Array))

From: Wakou Aoyama <wakou@...>
Date: 1999-03-09 05:34:03 UTC
List: ruby-dev #6145
青山です。

Tue, Mar 09, 1999 at 09:25:20AM +0900 において
Tadayoshi Funaba さん曰く:

> 通過駅をどう考えるか、ということもありますが、僕はあくまでも、10..1 は、
> 大きさが  0 になると考えたいです。これが大きさ 10 だと言えるなら、方向
> も自ずと決まるという話になります。そうすると、別個に step に正負がある
> というのはヘンに思うんですけど。
>
> もちろん、Range の大きさと、歩数とは関係ないということもできるかもしれ
> ないですけど、それでは大きさの意味がないです。

大きさ 0 はちょっと無理があると思います。距離でも角度でも重量、面積、
速度、時間、等々、どの場合も Range が 0 というのは違和感がありますから。
そして、どの場合も正負両方向の参照が存在するのは自然だと思われます。

> このあたり、よくわからないのですけど、Range が step を利用しないことも
> あるんですか? で、その場合は max..min の挙動が変る?

ruby-dev:6096
> max..min を許容する場合 step を省略した場合の方向を a-->b とし、step
> の絶対値を 1 という感じです。(step が省略された場合は a 始点 b 終点の
> 鈍行という感じ)

という事で、step を省略した場合というのは for i in a..b のような場合です。
方向を明示する場合は for i in (a..b).step(n) という感じですね。

> チェックせずに、おまかせにするのが良くないといわれますが、それは違うと
> 思いますよ。それも含めて論理を決めているんですよ。それを捨てるのは決定
> 的な違いで、 今現在の仕様からいっても、 僕の考えでも、10..1 を 10,9..1
> のように解釈してもらおうとするほうが、望ましくないと思います。オマカセ
> せずに、 upto、downto、step などを直接につかうべきでしょう。良い方向で
> の不便さとは思いません。

この件に関しては max..min についての結果が出た後でと思います。a..b に
とって a < b が必要条件であるかどうかという結果が出ない限りはそれに関
する挙動は決められませんから。

> なんでもかんでも each を基本にしているのでは不足ではないか、という議論を
> 思いだしていました。

おお、なるほど。そのような議論もありましたか。ですが、これもまた今回の
場合とは異なると思われます。Enumerable は機能拡張の為の Mixin であり、
Enumerable というオブジェクトを生成する為のクラスではありませんから。

> いや、それは違うんじゃないですかね。マニュアルに書いてあるし、それを信
> じて、クラスを書いている人もいます。

これは現在の事ですよね。step が導入された場合は当然ながら変更される事
になります。


-- 
青山 和光 Wakou Aoyama <wakou@fsinet.or.jp>

In This Thread