[#32910] NKF,Kconv — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
[#32913] openの"b"とencoding — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
[#32922] SEGV by regexp match in while loop — Tanaka Akira <akr@...>
Debian GNU/Linux (sarge) の gcc-3.4 を使ってビルドした ruby
[#32935] queue and timeout — Tanaka Akira <akr@...>
timeout で Queue#pop に時間制限をつけた時、タイムアウト時に
まつもと ゆきひろです
[#32940] ripper cannot build on win32 — yukimi_sake <yukimi_sake@...>
雪見酒です。
[#32945] Shift_JIS variants and UTF-16 support — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
中村さん、こんにちは。
まつもと ゆきひろです
成瀬です。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
成瀬です。
こんにちは、なかむら(う)です。
成瀬です。
こんにちは、なかむら(う)です。
まつもと ゆきひろです
[#32946] replica と alias の違い(encoding) — KIMURA Koichi <kimura.koichi@...>
木村です。
[#32987] error with open-uri (instance_eval?) — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
[#32988] Re: [ruby-cvs:22194] Ruby:r14957 (trunk): * encoding.c (rb_enc_init): UTF-{16,32}{BE,LE} are not builtin. — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
[#32992] ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — "NARUSE, Yui" <naruse@...>
成瀬です。
まつもと ゆきひろです
At 18:13 08/01/09, Yukihiro Matsumoto wrote:
成瀬です。
まつもと ゆきひろです
成瀬です。
まつもと ゆきひろです
なかだです。
まつもと ゆきひろです
[#32996] binmode and ASCII-8BIT — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
[#33069] Re: [ruby-cvs:22244] Ruby:r15007 (trunk): * enc/make_encdb.rb: added. search enc/*.c and make encoding database. — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
まつもと ゆきひろです
[#33076] Encoding.compatible? and dummy encodings — sheepman <sheepman@...>
こんにちは sheepman です。
成瀬です。
まつもと ゆきひろです
[#33078] NEW REPLICA ENCODINGS AND ENCODING ALIASES — "NARUSE, Yui" <naruse@...>
成瀬です。
[#33101] String#valid_encoding? shoud be strict? — Masayoshi Takahashi <maki@...>
高橋征義です。1.9のエンコーディングとString#valid_encoding?について。
[#33139] Bignum#* might invoke GC parallelly? — "Yusuke ENDOH" <mame@...>
遠藤と申します。
[#33156] default script encoding and -K option — sheepman <sheepman@...>
こんばんは sheepman です。
こんにちは、なかむら(う)です。
まつもと ゆきひろです
[#33164] default encoding for Marshal.load — "Shugo Maeda" <shugo@...>
前田です。
まつもと ゆきひろです
[#33185] コンパイルの問題 (r15218) — Martin Duerst <duerst@...>
r15128 当たりで (実はもう少し前から) コンパイルできなくなりました。
[#33218] Re: Ruby1.9String バイト列へのインデックス アクセス — "Hisanori Kiryu" <hkiryu@...>
> ちなみに、byte のではなく bytes の方が妥当だと思います。
[#33224] printf "%0x" — Tanaka Akira <akr@...>
printf の %0x に負の整数を与えると、値によって .. がついたり
[#33226] [PATCH] warnings of enc/trans/utf_16_32.c — Nobuyoshi Nakada <nobu@...>
なかだです。
[#33239] Re: [ruby-cvs:22386] Ruby:r15149 (trunk): * string.c (rb_str_each_char): move forward. — Tanaka Akira <akr@...>
In article <200801210259.m0L2x3CW017171@ci.ruby-lang.org>,
なかだです。
In article <20080121065650.55F60E0662@mail.bc9.jp>,
なかだです。
まつもと ゆきひろです
[#33247] requests to transcode — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
[#33303] Time#strftimeのエンコーディング — rubikitch@...
るびきちです。
まつもと ゆきひろです
なかだです。
西山和広です。
[#33368] summary of script encoding — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
まつもと ゆきひろです
永井@知能.九工大です.
[#33387] HashからStructを作る — rubikitch@...
るびきちです。
まつもと ゆきひろです
From: Yukihiro Matsumoto <matz@ruby-lang.org>
まつもと ゆきひろです
From: Yukihiro Matsumoto <matz@ruby-lang.org>
まつもと ゆきひろです
From: Yukihiro Matsumoto <matz@ruby-lang.org>
まつもと ゆきひろです
[#33399] regexp match /.../n against to UTF-8 string — Tanaka Akira <akr@...>
以下のように、つけてもいない正規表現の n オプションに関して
[#33400] /#{}/e.encoding — Tanaka Akira <akr@...>
以下のように /#{}/e の encoding が US-ASCII になります。
[#33403] wrapped String#gsub — "Park Ji-In" <tisphie@...>
こんにちは、朴 芝印です。
[#33417] コンパイルの問題 — Martin Duerst <duerst@...>
現在 (r15264 で) コンパイル使用とすると、エラーになります:
At 16:28 08/01/27, you wrote:
[#33433] Win32OLE: set encoding to OLE string — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
成瀬です。
助田です。
こんにちは、なかむら(う)です。
こんにちは、なかむら(う)です。
[#33452] enc/euc_kr.c (euckr_mbc_enc_len) euc_kr.c is also used by CP942 — "NARUSE, Yui" <naruse@...>
成瀬です。
まつもと ゆきひろです
成瀬です。
[#33461] Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — MORITA Hideyuki <h-morita@...>
=1B$B?9ED$H?=3D$7$^$9!#=1B(B
なかだです。
森田です。
なかだです。
森田です。
天野竜太郎と申します。
森田です。
天野です。
森田です。
天野です。
森田です。
天野です。
森田です。
天野です。
[#33488] 現在の script encoding の値を得る方法は? — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
まつもと ゆきひろです
永井@知能.九工大です.
成瀬です。
永井@知能.九工大です.
成瀬です。
永井@知能.九工大です.
成瀬です。
In article <47A00E86.4010701@airemix.com>,
成瀬です。
In article <47A03C9D.2090008@airemix.com>,
In article <87hcgvu1ng.fsf@fsij.org>,
[#33521] nkf の CP932 — Martin Duerst <duerst@...>
成瀬さん、皆さん、こんにちは。
[#33548] block parameter of String#gsub — "NARUSE, Yui" <naruse@...>
成瀬です。
まつもと ゆきひろです
[ruby-dev:33186] Ruby1.9 String バイト列へのインデックス アクセス
長文失礼します。
Ruby1.9でのBinaryStringの取り扱いについて質問があります。
(ruby-list に出すべきでしたでしょうか?
初めてメールをするので判断がつきませんでした。)
Ruby1.9のStringクラス(以下S19と略)では、
Ruby1.8以前のStringクラス(S18と略)での [](idx), []=(idx, value)
のような、Substringを介しないバイトの読み込み、
書き込みができなくなるのでしょうか?
メーリングリストを見たり、Ruby1.9をインストールをしたりしましたが、
相当するメソッドが見つからなかったので、
ないものと仮定して以下の話を続けます。
(あるなら教えていただけませんか?)
バイトへのインデックスアクセスができないとすると、
S18では何の問題もなかった次のような例で問題が発生します。
=========================================
例1.(画像処理)
256階調のグレースケールのビットマップ画像が
Stringクラスに読み込まれているとする
これに対して、隣接するピクセルの値で
平均化するぼかし操作を行う。(簡単のため境界の扱いは省略)
nx, ny = 10, 10
bmp = (0...(nx*ny)).inject(""){|s,i| s << rand(256); s} #input data
r = (-1..1) # neighbor index
val_x1 = bmp[0,ny] # value[x-1][0...ny]
(1...(nx-1)).each{|x|
val_x1_y1 = bmp[ny*(x-1)+0] # value[x-1][y-1]
(1...(ny-1)).each{|y|
val_x1_y = val_x1[y] # value[x-1][y]
val_x1[y] =
(r.inject(0){|zx,dx|r.inject(zx){|zy,dy|zy+bmp[ny*(x+dx)+(y+dy)]}}/9.0).to_i
bmp[ny*(x-1)+(y-1)] = val_x1_y1
val_x1_y1 = val_x1_y
}
val_x1[ny-2] = val_x1_y1
}
bmp[ny*(nx-2)+1,ny-2] = prev_x[1,ny-2]
ビットマップ画像のデータは,通常0-255までの数値をとるベクトルとして表されます。
様々な画像処理アルゴリズムはこの数値列に対してランダムアクセスをします。
バイトアクセスをbmp_S19[i].ord, bmp_S19[i] = integer.chr で行うと
((ピクセル数)x10個)程度の一文字Stringを生成することになります。
そもそも数値列と思っているものを部分文字列に変換しなければならないというのは、
論理的におかしく、通常は、言語の悪用をしているとみなされると思います。
そう思うとこのような操作はArray#pack,String#unpackを経由してArrayクラスで操作を
行うことをS19が強制していることになります。
例2.(バイオインフォマティクス)
2本のDNA配列の間の類似度(edit distance)を動的計画法の一種
(Needleman-Wunschアルゴリズム)で求める
gap_score, substitution_score = -3, Array.new(4){|i|Array.new(4){|j|
(i==j ? 0 : -1)}}
n1, n2 = 10, 10
nuc = "ACGT" # nucleotide (or DNA) character set
dna1, dna2 = [n1, n2].map{|n| (0...n).inject(""){|s,i|s <<
nuc[rand(4)]; s}} # input data
nuc_to_ord = (0...4).inject({}){|h,i|h[nuc[i]]=i; h} # ad hoc encoding
table
[dna1, dna2].each{|dna| (0...dna.size).each{|i| dna[i] =
nuc_to_ord[dna[i]]}} # dna.encode("DNA")
cur_scores = Array.new(n2+1)
prev_scores = Array.new(n2+1){|i| gap_score * i}
(1..n1).each do |i1|
cur_scores[0] = (gap_score * i1)
(1..n2).each do |i2|
cur_scores[i2] = [prev_scores[i2-1] +
substitution_score[dna1[i1-1]][dna2[i2-1]],
prev_scores[i2] + gap_score,
cur_scores[i2-1] + gap_score ].max
end
end
edit_distance = cur_row_scores[n2]
一文字の挿入・削除には-3のペナルティを与え、
文字の置換に-1のペナルティを与えるとしたとき、
片方の配列を編集してもう片方の配列を得るために最低必要なペナルティが求まります。
例が適当でなかったかもしれませんが、要はDomainSpecificなエンコーディング法を
Ruby上で書くのにも数値へのindexアクセスは
重要でないかということをいいたかったのです。
新しいエンコーディングの国際標準が現れることは少なくても、
Application Specificな独自EncodingをRubyスクリプトで書きたいことはあるではないでしょうか?
また、その目的を正規表現やbytes.eachのみで果たすことは
難しいこともあるのではないでしょうか?
・S19ではこのようなbyte列の使いかたに対して厳しいペナルティを与えているといえます。
・もちろんこれらの操作はStringからArray#pack,String#unpack を使ってArray上で行うこともできます。
・しかし例1、例2のどちらでも入力のサイズが数十、数百Megabytesになることは
珍しくありません。
・S18では素直にかけたのになんでS19でこのような記号的な引数の(unpack,pack)
コードを挿入しないといけないのかという気にもなります。
・Rubyの計算速度では、上のような計算で真に使えるライブラリはできないという意見もあるかもしれません。
しかし、例え現時点でパブリックなライブラリとして耐えるスピードでなくとも、
プロトタイプつくりや、
そんなにスケールの大きくないプライベートな問題での使い道はとても広いのではないでしょうか?
(私にとってはそうです)
・S18までのバイトアクセスは、そんなによくない仕様だったのでしょうか?
・このようなバイト列の扱い方でどんなすばらしいアプリケーションが生まれるかわからないのに
そのような機能をごっそり捨ててもよいのでしょうか?
==================================
私の意見は、Stringにはバイト列にインデックスでランダムアクセスし、
その数値をダイレクトに読み書き
するメソッドが必要なのではないかというものです。
私はこの6年間ほどで、数百のRuby Scriptを書いてきました。
しかし、プログラミングについてはいまだ素人レベルで、
Rubyの内部構造もよく知らず、
Encodingについても、ちょっとグーグルで調べた程度であり、
どのような仕様がよいかを言える立場ではないのは分かっています。
ですが、素人なりの暴論を以下に述べたいと思います。
私にとってベストな仕様は次のようなものです。
my_best_string[idx] #=> string_S19[i].ord を返す。
my_best_string[idx] = integer #=> string_S19[i] =
integer.chr(string_S19.encoding)
?文字 #=> ?文字.ord
利点:
0.バイト列を数値列と思ったとき最も自然。
1.ASCII文字列、バイナリ列の場合にS18と何の変化もない
S18を自然にEncoding対応にしたものと思える。
2.文字のordinalがFixnumに収まる限り文字の比較が高速(推測)
3.スクリプトのEncodingが文字列のEncodingと等しく
なければ結局文字列中でも数で指定しなければならない。"\u{0x..}"
(4.)EncodingがASCIIでないときランダムアクセスでない(多分)というのはS19でも同じなので問題ない
欠点:
1.文字を整数値にしたときEncoding情報を失うので複数Encodingが混ざるとき安全でない。
=>・安全性が疑われるときは、一文字Stringを使えばよいのではないでしょうか?
・推測ですが、hexの数値を直接扱う方がプロ向けなのではないでしょうか?
Rubyはプロ向けに十分な配慮がなされるはずです。
・Encodingについて詳しくないので、根本的な問題があるのかもしれませんが...
(character_string.ord.chr(character_string.encoding)が一意でないとか..
ord の値がascii-7bit文字部分でincompatible なEncodingがあるとか...?)
・文字リテラルを書きにくくなる? しかし、所詮 ?文字 と "文字”は一字しか違いません。
・それにS18までにそんなに多くの問題があったのでしょうか?
・Rubyのもっとも重要な応用はウェブアプリケーションなので、
HTTPからどんなEncodingの文字列が来るか分からない状況に対応するため、
Web言語としてエンコーディングの"*型*一致性・安全性”を重視するのだと言われれば
返す言葉はないのですが。。。
しかし、その代償は私にはとても大きく思えます。
2.一文字Stringを取得するのにstring[i]と書きたくなってしまう。
=>・私もRubyを知ったころはそうでした。しかし今では数値を返すS18の仕様に納得し、
Rubyらしい(と私が勝手に思っている)軽快さやPragmaticさが気に入っています。
・String#[](i)のような大事なメソッドがString#[i,1]の機能的なエイリアスでよいものでしょうか?
・S19にはString#chrがあるのでこれを引数つきにしてstr.chr(idx)などとすれば、
str[idx,1],str[idx..idx]よりは意図が明確になるかも知れません。
3.一文字を書き込むのにstring[i]="あ”と書きたくなってしまう。
=>・確かにそうかも知れませんが、string[i]="あいうえお”などとの連続性を考えると、
一文字の置き換えとは考えられず、
部分文字列の置換(string[i,1]="あ") と考える方が適切に思われます。
それに比べると string[i] = integer の方は
まさに一文字に対する代入という意味しか持ちえずより適切なのではないでしょうか?
・一文字の書き込みにstring[i..i]やstring[i,1]を使いたくないというのはあるかもしれません。
しかし、これは上に挙げた利点とのバランスで考えると
それほど大きなものではないのではないでしょうか?
([]との対称性を犠牲にして、[]=(i,val)がIntegerとStringの両方のvalを受け取る (S18#<< のように)という策もあるかも知れません) 4.「string[i]は文字列」とパブリックにいった以上あとには戻れない。 =>・お察しします。これはあくまで素人の暴論です。 ・しかし、Byte列の取り扱いについては、 まだ議論が続いているようですので、一縷の望みをかけて 思い切った意見を述べさせていただいています。 その他の案:String#ord(idx) => 数値 => ・数値列と考えたとき、ordinalという名前は不適切では? ・書き込みにset_ord(idx, value) ?String#get(idx), String#set(idx, value) => ・うーん。こうなったら残念です。[ByteStringとString] や[String:BINARYとString:ASCII-8BIT]など、異なるクラスや状態で[],[]= が文字列を返したり数値を返したりするかが変わる。 => ・どちらの振る舞いを望むかで、 str.to_byte_st!
r, str.force_encoding などのコンバージョンが 入り乱れるようになるのでは? ・どんな状態か分からんからとにかくforce_encodingする、というような プログラミングの習慣ができたらRuby言語の Love/hate ratio が暴落するのではないでしょうか?現在のRuby1.9の仕様に至るまでには膨大な議論が積み重ねられていることと思います。string[i]=文字列が決定したのはずいぶん昔のことのようでその経緯をメーリングリストのアーカイブからは見つけることはできませんでした。私の提案したようなことがうまくいかないことに、納得の行く理由があれば簡単でよいので、説明していただけませんか?そのときは、素直にあきらめることにします。Ruby1.9は、Enumeratorなどに素晴らしい機能があり,すぐにも使いたいのですが、上に述べた問題のために、移行にreluctantになっています。どうぞよろしくお願いします。