[#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:34024] Re: MurmurHash problem

From: "NARUSE, Yui" <naruse@...>
Date: 2008-03-11 18:34:41 UTC
List: ruby-dev #34024
成瀬です。

Yukihiro Matsumoto wrote:
> まつもと ゆきひろです
> 
> In message "Re: [ruby-dev:34020] MurmurHash problem"
>     on Tue, 11 Mar 2008 17:32:57 +0900, Nobuyoshi Nakada <nobu@ruby-lang.org> writes:
> 
> |これではalignされていないwordアクセスを許さないシステムでは動き
> |ません。murmurhashaligned.cppというのもあるようですが、これまた
> |
> |* intが32bitでないとならない
> |* little endianでないとならない
> |
> |という制限がありそうです。
> 
> そうかあ。残念だなあ。またJenkinsハッシュに戻すかなあ。
> 
> |intが64bitのシステムでも32bit整数がある保証ってあるんでしたっけ。
> 
> 保証はないでしょうね。
\
C99 の stdint.h では uintN_t (N は 8,16,32,64) が必須になっていますから、
C99 対応のコンパイラならば存在します。
なので、32bit のシステムでは言うまでもなく、
64bit 対応のシステム (=これからのシステム) でもまず確実に 32bit 整数が
存在すると言ってよいかと思います。

以下のようなものを defines.h においたうえで uint32_t を使うようにすればよいかと。

#if HAVE_STDINT_H
# include <stdint.h>
#else
# if SIZEOF_INT == 4
#  ifndef int32_t
typedef int int32_t;
#   define int32_t int
#  endif
#  ifndef int32_t
typedef unsigned int uint32_t
#  endif
# endif
#else
# error ---->> int32_t is not defined. <<----
#endif


エンディアンは常にバイトごとに取っていくとかですかねぇ。
最新のコンパイラだとそのへんちゃんと良きにはからってくれそうな気がするのですが、
場合分けした方がいいのかなぁ。
# 厳密にやろうとすると実行時分岐が必要そうなのですが・・・。


ところで、Ruby 1.9 ってどの程度まで前提にしていいのですっけ。
* ANSI C である
* char は8bit で CHAR_BIT は 8
* char が singed 前提は不可
* int, long, pointer は32bit 以上の 2 の累乗
* int == long 前提不可 (LP64等 (多くの UNIX 系))
* long == pointer 前提不可 (LLP64等 (Win64))
* long long 前提不可 ?
* C99 前提は不可
* エンディアンは big/little を考慮 (__BIG_ENDIAN_ 等を前提にしてはならない)

あとは int と long の使い分けでしょうか。なんとなく、
* int はただの整数。
* long は文字列長や文字位置等、ポインタとの演算が行われうるもの。
かなぁと思っているのですが、LP64 だとint において 64bit 化の恩恵が受けられず、
LLP64 だと int == long != *void なので long を分ける意義がないなぁとか。
後者は intptr_t にしてもよさそうな気もします。

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

In This Thread