[#34011] Should --verbose be equal to -v ? — Yugui <yugui@...>

Yuguiです。

15 messages 2008/03/10
[#34012] Re: Should --verbose be equal to -v ? — Yukihiro Matsumoto <matz@...> 2008/03/10

まつもと ゆきひろです

[#34105] rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...>

rational と complex が組み込みになったことで、lib/mathn.rb の意義は薄

29 messages 2008/03/22
[#34106] Re: rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...> 2008/03/22

現時点で rational.rb と complex.rb を残しているのは、それが無難だから

[#34107] Re: rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...> 2008/03/22

で、かなり選択肢を絞った叩き台です。

[#34120] Re: rational.rb, complex.rb and mathn.rb — keiju@... (石塚圭樹) 2008/03/24

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

[#34125] Re: rational.rb, complex.rb and mathn.rb — Shin-ichiro HARA <sinara@...> 2008/03/25

原です。

[#34130] Re: rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...> 2008/03/25

> 私も Complex の組み込みは Rational とは比較にならないくらい、仕様が決め

[#34158] Complex組み込み — Masahiro TANAKA <masa16.tanaka@...>

Complexが組み込みになるそうですが、これはcomplex.rbを踏襲して、

49 messages 2008/03/27
[#34161] Re: Complex組み込み — Shin-ichiro HARA <sinara@...> 2008/03/28

原です。

[#34168] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/03/28

> 今までの Complex は、complex.rb にほぼ残して、たとえば Rational 成分

[#34186] Re: Complex組み込み — Shin-ichiro HARA <sinara@...> 2008/03/31

原です。

[#34187] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/03/31

> そうです。Complex が難しい、という話を書いておくと、

[#34193] Re: Complex組み込み — Yukihiro Matsumoto <matz@...> 2008/03/31

まつもと ゆきひろです

[#34203] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/04/01

> |僕としては、/ 演算子の振舞いについて前向きに検討してほしいです。

[#34215] Re: Complex組み込み — Yukihiro Matsumoto <matz@...> 2008/04/02

まつもと ゆきひろです

[#34166] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/03/28

> となるようですが、別の実装として、

[ruby-dev:34032] Re: uint32_t

From: "NARUSE, Yui" <naruse@...>
Date: 2008-03-13 08:30:41 UTC
List: ruby-dev #34032
成瀬です。

KIMURA Koichi wrote:
> 木村です。
> 
> 例によって報告だけです。
> 
> 01:53 Tuesday	ruby	
> Commit by matz :: r15743 /trunk/ (ChangeLog string.c):
> 
>     * string.c (hash): replaced by MurmurHash described in <http://murmurhash.googlepages.com/>.
> 
> この修正の結果、uint32_tやらその辺の定義がないコンパイラで
> ビルドできなくなっています。

この時点では uint32_t でなく unsigned int なので実際に uint32_t になるのは r15760 ですね。
なにはともあれ r15762 でビルドは通るようになっていると思います。

ただ、MurmurHash の意図している機能は発揮されていなくて、
h 等も unsigned int でなく int32_t にする必要があると思います。
また、m の初期値が最新版では 0x7fd652ad から 0xc6a4a793 に変更されているので、
これも追従した方がいいでしょう。
さらに、align や pack は len と演算が行われるので、型をそろえた方がいいかもしれません。

--- string.c    (revision 15762)
+++ string.c    (working copy)
@@ -1697,20 +1697,21 @@ rb_str_concat(VALUE str1, VALUE str2)
 #endif

 /* MurmurHash described in http://murmurhash.googlepages.com/ */
-unsigned int
-hash(const unsigned char * data, int len, unsigned int h)
+uint32_t
+hash(const unsigned char * data, long len, uint32_t h)
 {
-    const unsigned int m = 0x7fd652ad;
+    const unsigned int m = 0xc6a4a793;
     const int r = 16;

     h += 0xdeadbeef;

     if (len >= 4) {
 #if !UNALIGNED_WORD_ACCESS
-       int align = (VALUE)data & 3;
+       long align = (VALUE)data & 3;
        if (align) {
            uint32_t t = 0, d = 0;
-           int sl, sr, pack;
+           uint32_t sl, sr;
+           long pack;

            switch (align) {
 #ifdef WORDS_BIGENDIAN

なお、この hash() は static がついていませんが、intern.h にも記述されていませんし、
他のファイルから使われている形跡もなく、名前が一般的なあたりから、
非公開を意図された関数だと推測したのですが、static のした方がいいのではないでしょうか。

-- 
NARUSE, Yui  <naruse@airemix.com>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA

In This Thread