[#43767] UDP通信時のエラー検出 — "中田雅美" <mimiger2007@...>
中田(雅)と申します。
小西 弘将です。
In message <6DC7D411CB0FB4konishi@raax.co.jp>
中田(雅)です。
In message <407af920708010215n6cb6a4a7o32a164da7d0b6901@mail.gmail.com> 2007-08-01T18:15+0900,
[#43777] gsub! で定数を書き換えられてしまう — 古川大輔 <mogya99@...>
はじめまして。もぎゃ と申します。
[#43781] WEB公開されるML投稿記事について — REI OKAMOTO <okamoto@...>
昨日投稿した岡本です。
[#43796] mod_ruby 環境の Rails での日本語文字列の truncate — "IKEDA Katsumi" <ikedak@...8.so-net.ne.jp>
池田と申します。
[#43806] Procの仕様について — "SHIMADA Koji" <snoozer.05@...>
しまだです。
[#43809] 配列についての質問 — "142QN4969@..." <ohrsts@...>
小原です。御世話になっています。
[#43815] 日本Rubyの会のHPでHikiError — "SHIMADA Koji" <snoozer.05@...>
しまだです。
[#43846] 質問:シェルスクリプトにすると uninitialized constant DATA — sw@...
環境は Windows XP
なかだです。
コメント、ありがとうございます。
[#43857] Hashへの生成順は保障されないのか? — Hiroshi Kasamatsu <qqmn89yb9@...>
こんにちは、笠松と申します。
Hiroshi Kasamatsu wrote:
皆さん、早速のレスありがとうございます。
Hiroshi Kasamatsu wrote:
Urabeさん、笠松です。レスありがとうございます。
Hiroshi Kasamatsu wrote:
cuzic です。
cuzic wrote:
In article <46C9E7BB.4060100@ruby-lang.org>,
おお、田中さんを満足させる説明ってのは結構ハードル高そうだな。
# 出遅れたので、レスすべきメールが判らなくなってしまったので、手近なのに
まつもと ゆきひろです
なかだです。
ささだです。
まつもと ゆきひろです
なかだです。
At Tue, 21 Aug 2007 13:59:43 +0900,
ささだです。
At Tue, 21 Aug 2007 19:29:11 +0900,
In article <86sl6dgikh.knu@iDaemons.org>,
In article <87zm0kaz60.fsf@fsij.org>,
Yuguiといいます。
まつもと ゆきひろです
ささだです。
[#43868] ruby1.8でssl通信@stmp/pop3 — "Tomo Matsumoto" <tomoyuki28jp@...>
松本と申します。
[#43923] [ANN] isi-1.1.3 released! — NISHIMATSU Takeshi <t_nissie@...>
西松と申します。
[#43939] Windows で正確なファイル名を取得するには — Five point Five <5.5@...>
Five point Five です。
[ruby-list:43938] Re: Hashへの生成順は保障されないのか?
大久保です。
丁寧なご返答どうもありがとうございます。
説明いただき、私の懸念は杞憂に終わりそうな印象を持ちました。
時刻 2007/08/25 02:34:14
Yukihiro Matsumoto さんは書きました
> まつもと ゆきひろです
>
> In message "Re: [ruby-list:43936] Re: Hashへの生成順は保障されないのか?"
> on Sat, 25 Aug 2007 01:59:53 +0900, m-ohkubo@sakura.email.ne.jp (Mitsuhiko OHKUBO) writes:
> | 「大クラス主義」が良くわからかったのですが、「少機能のクラス
> |を多数用意するよりも多機能なクラスを少数用意しましょう」というこ
> |とだろう、と思っての提案なのですが、違ってたらご指摘ください。
>
> そういうような意味です。
了解しました。
> | Hashインスタンス生成時に順序維持の特性を持つハッシュライブラ
> |リの実装を使うか、持たないハッシュライブラリの実装を使うかを指定
> |できるようにはならないでしょうか?順序維持の特性が重要な場合があ
> |る一方で、他の特性(メモリ使用量とか)が重要な場合もありますので、
> |選択できる道を残しておいて欲しいです。
>
> 選択肢が多い方がよいかと言うと必ずしもそうではないのです。と
> いうか、ハッシュエントリひとつあたり2ワードの増加が問題にな
> るような局面ではRubyの使用そのものが不適切な可能性が高いと思
> います。
このケースでは、ユーザが選択を行うコストに比べて得られる利益
が少ない、ということですね。了解しました。
使用そのものが不適切、という指摘はそのとおりかもしれません。
私の場合、自分用プログラムを組んでいるので、使って楽しいのが一番、
という理由(だけ)で使用しています。仕事では通らない理由ですね。
> | 将来、さらに高性能なハッシュライブラリが現れた場合に、Hashの
> |仕様が順序維持を含むために、Hashの実装にそのライブラリを利用でき
> |ない、という状況は起き得ることなのでしょうか?
> | もう一つ、同様の場合に、Hashの実装にそのライブラリを利用する
> |ためにHashの仕様から順序維持が外される、という状況は起き得ること
> |なのでしょうか?
>
> これはknuさんの懸念ですね。ですが、ハッシュと言うのはかなり古
> 典的なアルゴリズムですし、これから極端に性能が違うライブラリ
> が登場する可能性はかなり低いと思います。Judyのような「キャッ
> シュラインを意識した高速でHashっぽいライブラリ」というのは存
> 在しますが、JudyはHashではありませんし。
ハッシュライブラリはほぼ煮詰まっている、ということなのですね。
了解しました。
*-------*-------*-------*-------*-------*-------*-------*-------
大久保 光彦