[#27711] Re: [ruby-list:41557] Re: Windowsにおける共有フォルダーでのDir.globは一覧を返さない? — "U.Nakamura" <usa@...>

こんにちは、なかむら(う)です。

16 messages 2005/11/15
[#27717] Re: [ruby-list:41557] Re:Windowsにおける共有フォルダーでのDir.globは一覧を返さない? — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/11/16

山本です。

[#27718] Re: [ruby-list:41557] Re:Windowsにおける共有フォルダーでのDir.globは一覧を返さない? — "U.Nakamura" <usa@...> 2005/11/16

こんにちは、なかむら(う)です。

[#27719] Re: [ruby-list:41557] Re:Windowsにおける共有フォルダーでのDir.globは一覧を返さない? — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/11/16

山本です。

[#27720] Re: [ruby-list:41557] Re:Windowsにおける共有フォルダーでのDir.globは一覧を返さない? — "U.Nakamura" <usa@...> 2005/11/16

こんにちは、なかむら(う)です。

[#27721] Re: [ruby-list:41557] Re:Windowsにおける共有フォルダーでのDir.globは一覧を返さない? — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/11/16

山本です。

[#27722] Re: [ruby-list:41557] Re:Windowsにおける共有フォルダーでのDir.globは一覧を返さない? — "U.Nakamura" <usa@...> 2005/11/16

こんにちは、なかむら(う)です。

[#27723] Re: [ruby-list:41557] Re:Windowsにおける共有フォルダーでのDir.globは一覧を返さない? — 小西 弘将 <konishih@...6.so-net.ne.jp> 2005/11/16

 小西 弘将です。

[#27735] FNM_CASEFOLD on case-sensitive system — nobuyoshi nakada <nobuyoshi.nakada@...>

なかだです。

15 messages 2005/11/18
[#27737] Re: FNM_CASEFOLD on case-sensitive system — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/11/18

山本です。

[#27758] File.dirname("///foo/bar/baz/qux") on cygwin — Tanaka Akira <akr@...17n.org>

次に cygwin における

26 messages 2005/11/19
[#27768] Re: File.dirname("///foo/bar/baz/qux") on cygwin — "U.Nakamura" <usa@...> 2005/11/21

こんにちは、なかむら(う)です。

[#27769] Re: File.dirname("///foo/bar/baz/qux") on cygwin — Tanaka Akira <akr@...17n.org> 2005/11/21

In article <20051121093604.3A67.USA@garbagecollect.jp>,

[#27770] Re: File.dirname("///foo/bar/baz/qux") on cygwin — "U.Nakamura" <usa@...> 2005/11/21

こんにちは、なかむら(う)です。

[#27771] Re: File.dirname("///foo/bar/baz/qux") on cygwin — WATANABE Hirofumi <eban@...> 2005/11/21

わたなべです。

[#27772] Re: File.dirname("///foo/bar/baz/qux") on cygwin — Tanaka Akira <akr@...17n.org> 2005/11/21

In article <1191-Mon21Nov2005112905+0900-eban@os.rim.or.jp>,

[#27773] Re: File.dirname("///foo/bar/baz/qux") on cygwin — "U.Nakamura" <usa@...> 2005/11/21

こんにちは、なかむら(う)です。

[#27774] Re: File.dirname("///foo/bar/baz/qux") on cygwin — Tanaka Akira <akr@...17n.org> 2005/11/21

In article <20051121120453.3A70.USA@garbagecollect.jp>,

[#27776] Re: File.dirname("///foo/bar/baz/qux") on cygwin — Tanaka Akira <akr@...17n.org> 2005/11/21

In article <87ek5a665s.fsf@m17n.org>,

[#27777] Re: File.dirname("///foo/bar/baz/qux") on cygwin — "U.Nakamura" <usa@...> 2005/11/21

こんにちは、なかむら(う)です。

[#27778] Re: File.dirname("///foo/bar/baz/qux") on cygwin — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/11/21

なかだです。

[#27779] Re: File.dirname("///foo/bar/baz/qux") on cygwin — "U.Nakamura" <usa@...> 2005/11/21

こんにちは、なかむら(う)です。

[#27781] Re: File.dirname("///foo/bar/baz/qux") on cygwin — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/11/21

なかだです。

[#27782] Re: File.dirname("///foo/bar/baz/qux") on cygwin — "U.Nakamura" <usa@...> 2005/11/21

こんにちは、なかむら(う)です。

[#27783] Re: File.dirname("///foo/bar/baz/qux") on cygwin — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/11/21

なかだです。

[#27766] 1.8.4 preview2? — "URABE Shyouhei aka.mput" <root@...>

卜部です。間が空きましたが

17 messages 2005/11/20
[#27798] Re: 1.8.4 preview2? — Yukihiro Matsumoto <matz@...> 2005/11/21

まつもと ゆきひろです

[#27818] Re: [ ruby-Bugs-2872 ] TCPServer should not use SO_REUSEADDR in Cygwin port — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>

山本です。

15 messages 2005/11/25
[#27819] Re: [ ruby-Bugs-2872 ] TCPServer should not use SO_REUSEADDR in Cygwin port — Yukihiro Matsumoto <matz@...> 2005/11/25

まつもと ゆきひろです

[#27821] Re: [ ruby-Bugs-2872 ] TCPServer should not use SO_REUSEADDR in Cygwin port — "U.Nakamura" <usa@...> 2005/11/25

こんにちは、なかむら(う)です。

[#27823] Re: [ ruby-Bugs-2872 ] TCPServer should not use SO_REUSEADDR in Cygwin port — "U.Nakamura" <usa@...> 2005/11/25

こんにちは、なかむら(う)です。

[#27839] ruby 1.8 dumps core — Tanaka Akira <akr@...17n.org>

最近、boron でやっている chkbuild で ruby-1.8 が test-all 中

32 messages 2005/11/28
[#27862] Re: ruby 1.8 dumps core — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/11/28

山本です。

[#27911] Re: ruby 1.8 dumps core — Tanaka Akira <akr@...17n.org> 2005/12/01

In article <20051130210645.7228E2B0.ocean@m2.ccsnet.ne.jp>,

[#28046] Re: ruby 1.8 dumps core — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/12/19

山本です。

[#28048] Re: ruby 1.8 dumps core — Tanaka Akira <akr@...17n.org> 2005/12/19

In article <20051219120911.F876DDD0.ocean@m2.ccsnet.ne.jp>,

[#28050] Re: ruby 1.8 dumps core — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/12/19

山本です。

[#28057] Re: ruby 1.8 dumps core — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/12/19

山本です。

[#27871] Numeric と Complex — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

37 messages 2005/11/29
[#27872] Re: Numeric と Complex — keiju@... (石塚圭樹) 2005/11/29

けいじゅ@いしつかです.

[#27873] Re: Numeric と Complex — Yukihiro Matsumoto <matz@...> 2005/11/29

まつもと ゆきひろです

[#27875] Re: Numeric と Complex — keiju@... (石塚圭樹) 2005/11/29

けいじゅ@いしつかです.

[ruby-dev:27788] Re: Matrix class is broken without mathn

From: keiju@... (石塚圭樹)
Date: 2005-11-21 08:16:49 UTC
List: ruby-dev #27788
けいじゅ@いしつかです.

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 <<---

In This Thread