[#17002] strict prototype for c++ — Takaaki Tateishi <ttate@...>
立石です.
At Fri, 3 May 2002 02:59:36 +0900,
[#17017] 標準添付案 — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
At Wed, 8 May 2002 19:50:17 +0900,
At Wed, 8 May 2002 22:45:06 +0900,
At Thu, 9 May 2002 00:47:46 +0900,
田中です。一応 blade は見てます。
堀之内です。
堀之内です。
At Tue, 14 May 2002 14:45:28 +0900,
[#17031] double acosh — WATANABE Hirofumi <eban@...>
わたなべです。
なかだです。
わたなべです。
まつもと ゆきひろです
わたなべです。
[#17037] here document2 つで __LINE__ がずれる — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
[#17053] socket in Win32 — nobu.nakada@...
なかだです。
[#17059] [PATCH] mswin32 configure — nobu.nakada@...
なかだです。
[#17060] rb_warn — Tadayoshi Funaba <tadf@...>
ふなばです。
[#17095] irb & jarh — Tanaka Akira <akr@...17n.org>
ふと、irb で jarh をいくつか試したのですが、うまく扱えないものがあるようです。
けいじゅ@日本ラショナルソフトウェアです.
In article <200205160811.RAA31441@ishitsuka.com>,
[#17112] [Cleanup] rb_thread_select() — nobu.nakada@...
なかだです。
[#17122] Array#bsearch — Beyond <beyond@...>
[#17128] Thread: deadlock trouble — nagai@...
永井@知能.九工大です.
At Fri, 17 May 2002 14:47:53 +0900,
[#17134] argv[0] — Tanaka Akira <akr@...17n.org>
ふと ruby インタプリタの C における argv[0] を知りたくなったんですが、
まつもと ゆきひろです
In article <1021723554.017958.5113.nullmailer@picachu.netlab.jp>,
In article <1021723554.017958.5113.nullmailer@picachu.netlab.jp>,
[#17144] Re: msvcrt — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
わたなべです。
こんにちは、なかむら(う)です。
わたなべです。
こんにちは、なかむら(う)です。
わたなべです。
こんにちは、なかむら(う)です。
こんにちは、なかむら(う)です。
なかだです。
[#17158] else without rescue — nobu.nakada@...
なかだです。
[#17179] コマンドラインオプションの順序制約 — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
まつもと ゆきひろです
なかだです。
まつもと ゆきひろです
なかだです。
[#17194] [RCR] Array#rotate{,!} — nobu.nakada@...
なかだです。
まつもと ゆきひろです
[#17208] Etc — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
[#17223] race condition on Queue#pop? — Tanaka Akira <akr@...17n.org>
なんとなく thread.rb を眺めていて、Queue#pop に race condition がある
なかだです。
まつもと ゆきひろです
なかだです。
[#17228] Re: [ruby-list:35305] Re: ((1.2)..(3.4)).to_a — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
たけ(tk)です。
まつもと ゆきひろです
たけ(tk)です。
まつもと ゆきひろです
あづみです。
[#17238] Re: [ruby-list:35304] Re: ((1.2)..(3.4)).to_a — siena@... (Siena.)
Siena. です。
[ruby-dev:17238] Re: [ruby-list:35304] Re: ((1.2)..(3.4)).to_a
Siena. です。
なんだか、引っかき回した上に間が空いてしまってすみません。
▼ [ruby-list:35304] < Shin'ya Adzumi さん
》> |刻み幅を指定できるくらいはできてもいいように思います。
》> |それを Range (or another) が担うのか #succ が担うのかはともかく。
》>
》> それはRange#stepでは?
》
》to_a するときに、という話かと思ってましたが、どうなんでしょう。
あづみさんのご指摘のように、to_a でというのを考えていました。
succ, each の話と to_a の話が入り乱れていて、ちょっと混乱気味
だったように思います。更に、[ruby-list:35301] で、Range#step に
触れたのも、もしかするとそれに拍車をかけてしまったかもしれません。
自分なりに整理するため、疑似コード (以下、Range4 ^^;) を
書きながら [ruby-dev:6018] 以下を読んだりしていたのですが、
概念的には両端の開閉も含めて Range3 に類似するものでした。
[ruby-dev:6244] までを読むと、Range3 は「整数値の列」
という事でしたが、基本的にここだけが異なる点でした。
Range4 では、Enumerable を Range4 が表す{連続,離散}区間中の
離散的な部分集合を切り出し、その上を走査するものと位置づけました。
整理させていただきますと、Range4 は次のようになります。
# 基本的には解釈を変えて見直したというところで、
# 目新しい事はなく冗長な説明かもしれません
1. Comparable な (全順序が定義された) 集合中の連続した区間を表す
2. 刻み幅を属性として持つ、(定規のような) 目盛り付きの区間として扱う
3. Enumerable のメソッドは、この刻み幅ずつ走査する
Range4 の基本的な定義は 1. で、「連続した区間 (*)」を第一義とします。
基本的に全順序集合上で定義される事を前提としているので、仮に
区間演算が定義されたとした時、連続区間/離散区間のいずれであっても、
この区間演算は機能する (ように自然に作れる) と期待できます。
少なくとも互換性のある全順序集合上の区間どうしであれば、ですが。
(*) 稠密な集合である「連続区間」と、両端点を除いて、隣合う全ての
要素が含まれている (空のない)「連続した区間」を区別しています
これに、Enumerable という特殊な一面を持たせるのが 2. と 3. です。
2. の resolution (scale resolution) は Range4 作成時に与えられ、
デフォルト値は、数なら (全順序集合上で定義される) 単位量、さもなくば
succ 1 回または単位量とし、単位量が定義されていなければ 1 とします。
3. の動作の基本となる each は、数ならば + を、
それ以外なら succ または + を利用するように定義します。
この辺りは、[ruby-dev:17228] からの議論と基本的に共通すると思います。
最初は + 優先で考えていたのですが、やはり String などが。
もう一つ、+ 相当のメソッド xxx を仮定して、xxx -> + -> succ の順で
最初に見つかったもので each を定義するというのも案としてあります。
Range4 の要求事項が多くなってしまうため、ひとまず保留しました。
xxx がなければないで、+/succ を使うので気にする必要ないかもですが。
ちょっと、先走った事になりますが、与えられた resolution が
負であれば、上記とは逆方向の走査をする事としました。
即ち、Range4.supremum を起点として Range4.infimum の方向へ走査し、
その動作は、+/succ ではなく -/prec (precede) に従うとしました。
もちろん、これらが定義されていない時にはエラーとします。
あえて分けたのは、succ しかできない、もしくは prec の実装が困難、
succ と実装が全く異なるという場合もあるかもしれないと考えたからです。
Enumerable のメソッド名が汎用的なものなので連続区間には
そぐわないものもありますが、そこは便宜のため目をつむりました ^^;
必要なものは、別のメソッドとして定義するという方向で。
メソッドを再定義して既存のスクリプトと共存できなくなっても
困りますし、再定義不可能もしくは困難なものも多く、一部だけが
Enumerable と異なるというのも混乱を招きやすいと判断したためです。
Enumerable との互換性に問題がなく、かつ明確に定義可能であれば、
再定義してしまってもいいかもしれませんが、判断が難しいですね。
更に余談ですが、resolution に nil を与えられた時に、Enumerable の
メソッドを無効にして、連続区間として定義可能なものだけ再定義するとか、
連続区間なメソッド優先と Enumerable のメソッド優先の切替を可能に
するとか、姑息な事も考えてみましたが、これは案の定いまいちでした ^^;;
》[ruby-dev:6184]
》> Range#sizeとRange#to_a.sizeが違うのは避けたいです.
この点については、次のような定義を与えてました。
Range4#size := Range4.to_a.size
Range4#length := Range4.supremum - Range4.infimum
現在のスタンスをまとめてみましたが、余り進展らしい
ものも見られず、取り留めもなく長くなってしまいました。
まだ自分の中で検討が足りないようです。
あまりごちゃごちゃという資格がないですね ;_;
---
Siena. <mailto:siena@cr.chiba-u.ac.jp>