[#27638] tcltkstub cause SEGV — KIMURA Koichi <kbk@...>
木村です。
なかだです。
山本です。
[#27651] [TIPS] .ext へのコピーの負荷低減 — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
なかだです。
山本です。
[#27663] refactored shellwords.rb has bug? — KIMURA Koichi <kimura.koichi@...>
木村です。
[#27666] patch for Makefile.in — Takahiro Kambe <taca@...>
pkgsrcの方で、Min Sik Kim氏により加えられた変更です。
[#27674] Numeric#div — Koji Arai <jca02266@...>
新井です。お久しぶりです。
[#27680] patch for BeOS (HEAD) — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
山本です。
In article <20051111081454.EDF9CD78.ocean@m2.ccsnet.ne.jp>,
山本です。
[#27695] trap & sleep doens't work on windows HEAD. — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
[#27711] Re: [ruby-list:41557] Re: Windowsにおける共有フォルダーでのDir.globは一覧を返さない? — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
山本です。
こんにちは、なかむら(う)です。
山本です。
こんにちは、なかむら(う)です。
山本です。
こんにちは、なかむら(う)です。
小西 弘将です。
こんにちは、なかむら(う)です。
山本です。
[#27729] Thread deadlock when signale handler raise exception — Tatsuki Sugiura <sugi@...>
こんにちは。杉浦です。
[#27735] FNM_CASEFOLD on case-sensitive system — nobuyoshi nakada <nobuyoshi.nakada@...>
なかだです。
山本です。
山本です。
なかだです。
なかだです。
山本です。
なかだです。
山本です。
[#27738] File.split("A:a/b") and File.split("A://///") on mswin32 — Tanaka Akira <akr@...17n.org>
ちょっと調べていて気がついたのですが、
こんにちは、なかむら(う)です。
[#27754] ruby-mode の emacs 収録 — Seiji Zenitani <zenitani@...>
はじめて投稿します。
[#27758] File.dirname("///foo/bar/baz/qux") on cygwin — Tanaka Akira <akr@...17n.org>
次に cygwin における
こんにちは、なかむら(う)です。
In article <20051121093604.3A67.USA@garbagecollect.jp>,
こんにちは、なかむら(う)です。
わたなべです。
In article <1191-Mon21Nov2005112905+0900-eban@os.rim.or.jp>,
こんにちは、なかむら(う)です。
In article <20051121120453.3A70.USA@garbagecollect.jp>,
In article <87ek5a665s.fsf@m17n.org>,
こんにちは、なかむら(う)です。
なかだです。
こんにちは、なかむら(う)です。
なかだです。
こんにちは、なかむら(う)です。
なかだです。
なかだです。
こんにちは、なかむら(う)です。
なかだです。
こんにちは、なかむら(う)です。
In article <20051121191101.3A88.USA@garbagecollect.jp>,
[#27766] 1.8.4 preview2? — "URABE Shyouhei aka.mput" <root@...>
卜部です。間が空きましたが
まつもと ゆきひろです
なかだです。
[#27818] Re: [ ruby-Bugs-2872 ] TCPServer should not use SO_REUSEADDR in Cygwin port — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
こんにちは、なかむら(う)です。
こんにちは、なかむら(う)です。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
[#27825] 1.8.4 preview test failed (soap/ssl/test_ssl.rb) — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
[#27836] autoload with const_missing — SASADA Koichi <ko1@...>
ささだです。
[#27839] ruby 1.8 dumps core — Tanaka Akira <akr@...17n.org>
最近、boron でやっている chkbuild で ruby-1.8 が test-all 中
山本です。
In article <20051128190225.14D66C20.ocean@m2.ccsnet.ne.jp>,
In article <20051130210645.7228E2B0.ocean@m2.ccsnet.ne.jp>,
山本です。
In article <20051219120911.F876DDD0.ocean@m2.ccsnet.ne.jp>,
山本です。
山本です。
In article <20051219203218.8E517368.ocean@m2.ccsnet.ne.jp>,
まつもと ゆきひろです
[#27846] parser_params heap — Tanaka Akira <akr@...17n.org>
struct parser_params の heap ですが、Ripper のときとそうでな
[#27851] tail call and conservertive GC — Tanaka Akira <akr@...17n.org>
x86_64-linux で、gcc 4.0.3 20051111 なるものを用いて ruby
なかだです。
In article <TYOMLEM04FRaqbC8wSA0000003d@tyomlvem02.e2k.ad.ge.com>,
[#27871] Numeric と Complex — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
けいじゅ@いしつかです.
まつもと ゆきひろです
けいじゅ@いしつかです.
05/11/30 に 石塚圭樹<keiju@ishitsuka.com> さんは書きました:
まつもと ゆきひろです
卜部です。
まつもと ゆきひろです
うらべです。
まつもと ゆきひろです
原です。
まつもと ゆきひろです
けいじゅ@いしつかです.
まつもと ゆきひろです
けいじゅ@いしつかです.
まつもと ゆきひろです
[#27890] rb_funcall2() for protected method — nobuyoshi nakada <nobuyoshi.nakada@...>
なかだです。
まつもと ゆきひろです
[ruby-dev:27788] Re: Matrix class is broken without mathn
けいじゅ@いしつかです.
In [ruby-dev:27730] the message: "[ruby-dev:27730] Re: Matrix class is
broken without mathn", on Nov/18 02:02(JST) Shin-ichiro HARA writes:
>原です。
>ちょっと間が空いてしまいました。すいません。Integer成分の
>determinantの話の続きです。
いえ, こちらこそ.
まず, 原さんの意見に賛成するのですが, いくつか誤解があるようなので,
そちらから:
>私が誤解しているのか、どうも石塚さんの話がぴんとこないのです
>が、、、私は、現行ではRationalをrequireするだけでなく、更に
>各成分をRational化してdetに放り込まなくてはならないのが問題
>だと思うのです。
話をはしょり過ぎましたかね.
detの定義の中でrational.rbをrequireし, かつquoで計算するようにしよう
というのが, 私の主張でした.
quoで計算することになりますので, 成分をRational化をする必要はなく, quo
が出てきた時点でRational化されます.
>>det計算中Rationalをrequireする場合,
>>すべてがIntegerの場合, 結果は必ずInitegerになり,
>>行列中1要素でもFloatが入っている場合, 結果は必ずFloatになり,
>>Rationalになることはありません.
>
>今回問題になっているのは、整数行列の行列式はどうあつかうべき
>か、ですよね?
です. ここで言いたかったのは, 成分にFloatが混じっていてもちゃんと動作
するよといいたかったのでした.
>>ですので, (内部の計算がどうなっているかは別として), それぞれの
>>クラスに応じた自然な結果が出ることが必ず保証できます.
>
>細かい話ですが、整数行列の成分をRational(x, 1)で全て有理数
>化してdetを計算させると、結果はRationalですよね。mathn.rbを
>導入するとIntegerですけど。
そうなりますね. 整数行列のdet結果はRational(x,1)になります.
# 上で述べてあるように, Rational化は特に必要ないです.
>>あと, パフォーマンスのことを気にするなら, 最初っから要素は
>>Floatにすべきだと思います.
>
>私がquoを使った方がいいと思うのは、整数行列のdetを計算したと
>きとんでもない値が出るのを防げるからという理由で、ただその一
>点に尽きます。
>それに対して石塚さんはrational.rbをrequireして各成分、
>Rational()でラップしてくれ、と主張しているわけですよね。
>私はそれは面倒すぎるのではないかと、そして今後も忘れて
>意図しない結果に悩む人が大勢出るのではないかと思います。
上で述べたように私の案でもそういう問題は解決しています.
>それならちょっとかっこ悪くても「quoでFloat」でいいのでは
>ないでしょうか。
>現行をquo式にしたメリットデメリットまとめると、
>
>--------------------------------------------------------------
>成分 | 現行 | quo式
>-------------------+--------------------+---------------------
>全てInteger | NG | 戻値:Float
> | | 誤差が気になることも
>-------------------+--------------------+---------------------
>全てInteger | NG | 戻値:Rational
>rationa.rb導入のみ | | 遅い
>-------------------+--------------------+---------------------
>全てRational | 戻値:Rational | 戻値:Rational
> | 遅さは気にならない | 遅さは気にならない
>-------------------+--------------------+---------------------
>全てFloat | 戻値:Float | 戻値:Float
> | 誤差は気にならない | 誤差は気にならない
>-------------------+--------------------+---------------------
いちおう, Rational+quoだと:
--------------------------------------------------------------
成分 | 現行 | Rational+quo式
-------------------+--------------------+---------------------
全てInteger | NG | 戻値: Integer(にできる)
| | 遅い
-------------------+--------------------+---------------------
全てInteger | NG | 戻値: Integer(にできる)
rationa.rb導入のみ | | 遅い
-------------------+--------------------+---------------------
全てRational | 戻値:Rational | 戻値:Rational
| 遅さは気にならない | 遅さは気にならない
-------------------+--------------------+---------------------
全てFloat | 戻値:Float | 戻値:Float
| 誤差は気にならない | 誤差は気にならない
-------------------+--------------------+---------------------
という感じです. ですので, quo式よりもRational+quo式の方が安全よりになっ
ていると考えたわけです.
ただ, Rational+quo式 は, detを計算すると勝手にrational.rbをrequireして
しまうので, det前と後でquoを用いているメソッド(inv等)の振る舞いが変わっ
てしまうことに気が付きましたので, やはりまずいかなぁ. と思っていたとこ
ろでした(^^;;
>更にもう一つ提案なんですが、整数行列のdetの計算には、互除法
>を使ったそこそこ速いのがあります:
> def determinant_e
(中略)
> end
>これは、整数行列をRatinal()してから、現行detを計算するより
>かなり速いです。次は15次行列の整数成分の行列式を5回計算させ
>たのにかかった時間です。
>
>determinant : 4.278sec.
>determinant_e : 0.329sec.
おー. すばらしい.
>------------------------------------------------------------
>成分 | quo式 | determinant_e
>-------------------+----------------------+-----------------
>全てInteger | 戻値:Float | 戻値:Integer
> | 誤差が気になることも | やや遅い
>-------------------+----------------------+-----------------
>全てInteger | 戻値:Rational | 戻値:Integer
>rationa.rb導入のみ | 遅い | やや遅い
>-------------------+----------------------+-----------------
>全てRational | 戻値:Rational | 戻値:Rational
> | 気にならない遅さ | 気にならない遅さ
>-------------------+----------------------+-----------------
>全てFloat | 戻値:Float | NG
> | 気にならない誤差 |
>-------------------+----------------------+-----------------
>
>そこで提案なんですが、Matrix のdetはquo式にし、と同時に
>determinant_e(det_iという名前もいいですが)も定義しておいて、
ちなみに, determinant_e の eは何の省略形です?
> 【整数行列を扱う場合の注意】
> 整数行列の行列式を計算させるときは、Matrix#det_iを使いましょ
> う。Matrix#detは、rational.rbをrequireしていない状態でFloat、
> requireしている状態でRationalを返します。
>
>と、マニュアルに記述するのです。
>
>どうでしょう?
>ちなみに、determinant_eは[ruby-math:625]のコードをシンプルに
>したものです。他にも幾つかバリエーションを試してみたのですが、
>結局[ruby-math:625]のコードが速いのでこちらの方がいいかもし
>れません。
オリジナルdetと形がすごく似ているので, det_625 の方がよいかなぁ...
って感じです.
結論としては, 原(新)案に賛成です.
ただ, 行列の要素にはいろいろなものが入る可能性があるので, det_eがちゃ
んと動作する条件を明確にした方がよいかと思います.
__
---------------------------------------------------->> 石塚 圭樹 <<---
---------------------------------->> e-mail: keiju@ishitsuka.com <<---