[#32945] Shift_JIS variants and UTF-16 support — "U.Nakamura" <usa@...>

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

22 messages 2008/01/07
[#32953] Re: Shift_JIS variants and UTF-16 support — Martin Duerst <duerst@...> 2008/01/07

中村さん、こんにちは。

[#32955] Re: Shift_JIS variants and UTF-16 support — Yukihiro Matsumoto <matz@...> 2008/01/07

まつもと ゆきひろです

[#32959] Re: Shift_JIS variants and UTF-16 support — "NARUSE, Yui" <naruse@...> 2008/01/07

成瀬です。

[#32960] Re: Shift_JIS variants and UTF-16 support — Yukihiro Matsumoto <matz@...> 2008/01/07

まつもと ゆきひろです

[#32992] ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — "NARUSE, Yui" <naruse@...>

成瀬です。

18 messages 2008/01/08
[#32994] Re: ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — Yukihiro Matsumoto <matz@...> 2008/01/09

まつもと ゆきひろです

[#32995] Re: ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — Martin Duerst <duerst@...> 2008/01/09

At 18:13 08/01/09, Yukihiro Matsumoto wrote:

[#33011] Re: ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — "NARUSE, Yui" <naruse@...> 2008/01/11

成瀬です。

[#33012] Re: ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — Yukihiro Matsumoto <matz@...> 2008/01/11

まつもと ゆきひろです

[#33014] Re: ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — "NARUSE, Yui" <naruse@...> 2008/01/11

成瀬です。

[#33015] Re: ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — Yukihiro Matsumoto <matz@...> 2008/01/11

まつもと ゆきひろです

[#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>,

11 messages 2008/01/21
[#33240] Re: [ruby-cvs:22386] Ruby:r15149 (trunk): * string.c (rb_str_each_char): move forward. — Nobuyoshi Nakada <nobu@...> 2008/01/21

なかだです。

[#33303] Time#strftimeのエンコーディング — rubikitch@...

るびきちです。

13 messages 2008/01/23
[#33305] Re: Time#strftimeのエンコーディング — Yukihiro Matsumoto <matz@...> 2008/01/23

まつもと ゆきひろです

[#33368] summary of script encoding — "U.Nakamura" <usa@...>

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

22 messages 2008/01/25
[#33375] Re: summary of script encoding — Yukihiro Matsumoto <matz@...> 2008/01/25

まつもと ゆきひろです

[#33376] Re: summary of script encoding — "U.Nakamura" <usa@...> 2008/01/25

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

[#33387] HashからStructを作る — rubikitch@...

るびきちです。

19 messages 2008/01/25
[#33455] Re: HashからStructを作る — Yukihiro Matsumoto <matz@...> 2008/01/28

まつもと ゆきひろです

[#33505] Re: HashからStructを作る — rubikitch@... 2008/01/29

From: Yukihiro Matsumoto <matz@ruby-lang.org>

[#33507] Re: HashからStructを作る — Yukihiro Matsumoto <matz@...> 2008/01/29

まつもと ゆきひろです

[#33508] Re: HashからStructを作る — rubikitch@... 2008/01/29

From: Yukihiro Matsumoto <matz@ruby-lang.org>

[#33433] Win32OLE: set encoding to OLE string — "U.Nakamura" <usa@...>

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

16 messages 2008/01/28

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

19 messages 2008/01/28
[#33473] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — Nobuyoshi Nakada <nobu@...> 2008/01/28

なかだです。

[#33503] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — MORITA Hideyuki <h-morita@...> 2008/01/29

森田です。

[#33514] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — Nobuyoshi Nakada <nobu@...> 2008/01/29

なかだです。

[#33518] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — MORITA Hideyuki <h-morita@...> 2008/01/30

森田です。

[#33545] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — Ryutaro Amano <wn9r-amn@...> 2008/01/31

天野竜太郎と申します。

[#33546] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — MORITA Hideyuki <h-morita@...> 2008/01/31

森田です。

[#33547] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — Ryutaro Amano <wn9r-amn@...> 2008/01/31

天野です。

[#33551] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — MORITA Hideyuki <h-morita@...> 2008/01/31

森田です。

[#33488] 現在の script encoding の値を得る方法は? — Hidetoshi NAGAI <nagai@...>

永井@知能.九工大です.

20 messages 2008/01/29
[#33491] Re: 現在の script encoding の値を得る方法は? — Yukihiro Matsumoto <matz@...> 2008/01/29

まつもと ゆきひろです

[#33500] Re: 現在の script encoding の値を得る方法は? — Hidetoshi NAGAI <nagai@...> 2008/01/29

永井@知能.九工大です.

[#33501] Re: 現在の script encoding の値を得る方法は? — "NARUSE, Yui" <naruse@...> 2008/01/29

成瀬です。

[#33515] Re: 現在の script encoding の値を得る方法は? — Hidetoshi NAGAI <nagai@...> 2008/01/30

永井@知能.九工大です.

[#33516] Re: 現在の script encoding の値を得る方法は? — "NARUSE, Yui" <naruse@...> 2008/01/30

成瀬です。

[#33519] Re: 現在の script encoding の値を得る方法は? — Hidetoshi NAGAI <nagai@...> 2008/01/30

永井@知能.九工大です.

[#33522] Re: 現在の script encoding の値を得る方法は? — "NARUSE, Yui" <naruse@...> 2008/01/30

成瀬です。

[ruby-dev:33186] Ruby1.9 String バイト列へのインデックス アクセス

From: "Hisanori Kiryu" <hkiryu@...>
Date: 2008-01-19 14:43:14 UTC
List: ruby-dev #33186
長文失礼します。

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になっています。どうぞよろしくお願いします。


In This Thread