以下の条件がそろった場合に限り、ロケールあわせですむことに、異論はありません。
o 国際化ライブラリを使っている
o コンマを使う文化圏の存在を前提に、全体の仕様を決めた
でも、そんな人にロケールと国際化の説明なんて不必要。つまり、この場合、正しく、かつ無意味な意見です。
わざわざ説明するからには、相手はこんな状態のはず。
o 国際化ライブラリを使っていない
o 使ってるんだけど、国際化ライブラリが小数点にコンマを
使うなんて知らずに仕様を決めている。「58,4,53」みたいに。
そうであれば、「ロケール一発」という説明は、不足に過ぎる。少なくとも、プログラム全域にわたって、「数の表現にコンマが入っても困らない仕様になっていること」を確認しなおす必要があります。自分が考えるところの仕様の書き方 (の選択肢)、あなたの言うところのガイドラインは、その明らかに不足している部分を、多少は補ってるんでないかなと。
数値表現は文字列の話だよ (スコア:1, 興味深い)
・数値: 1.0とか1,0とか、 -1とか1-とか
・通貨: 1,000,000 とか 1.000.000とか
・パーセント: 10% とか %10とか
そのため、数値は各言語環境で用意している国際化フォーマット用のライブラリを使って文字列に変換します。
標準が変わったとしても、変更があるのは所詮ライブラリの中の話です。
# 数値フォーマットライブラリ使ってないで自分でカンマ入れてる輩は、もとから標準なんて気にしてないでしょう。
数値表現は所詮文字列上での話、大体はユーザーインタフェース周りの話なので、計算機屋さん(高度な数値計算プログラミングをする人?)には大して関係ないのでは。
それともタレコミ人の意図は、「プログラミング言語の文法を変えて、数値リテラルでカンマを使うように変えるかも」ってことなのか?
Re:数値表現は文字列の話だよ (スコア:1)
入出力関係は、補正を足せばOKかもしんないけど(でも、手間はかかるよな)
ついでに言えば、コーディングをする段階にしたところで、ピリオド=小数点なんて言語は嫌じゃなんて動きが出ないとは限らんわな。ソース自体がコンマ=小数点でなきゃ困るなんて動きが出ないことを祈りますわ(笑)
それこそ、この手の問題は突き詰めると、文法改変するのか?になりかねないと思いますが?
開発環境もソフトウェアである以上はね。実際、日本語で開発しましょうなんて製品も過去には出てるくらいで、母国語環境で組めないと満足しない人間もいるのかもしれず。
もっとも、言語に関しちゃ、英語のままで文句を言わない他言語圏の人間が小数点くらいで、ガタガタ言うなとは思いますが。(それともドイツ語圏とかフランス語圏では、母国語表記だとか?)
Re:数値表現は文字列の話だよ (スコア:0)
たとえばJavaの場合だと、数値から文字列にするのも、文字列をパーズして数値を取り出すのもjava.text.NumberFormatを使うことになります。多言語に対応した数値<=>文字列変換はそれしか手段を持っていないので、手間の差を比較することもない。そういうふうにするのがこれからのマルチリンガル環境二対応した言語環境のデザインだと思います。
# String.parseIntはJava整数リテラルをパーズするものという位置づけ
> ついでに言えば、コーディングをする段階にしたところで、ピリオド
文字列の話ではない、仕様の話だ (スコア:1)
たとえば、値域を [最小値,最大値] と入力する、という仕様はどうしたものでしょうか。[1,2,3] って言われても、1.2から3までなのか。1から2.3までなのかわかんないし。
いや、こんな仕様、変えてしまえばいいんですけどね。問題は、仕様を考えるに当たり、「世界中の表記と習慣を知っておけ」といわれたって困る、ってことなんです。
たとえば、世界のどこにも、小数点を "=" で表す習慣はない、なんて、ちょっといえません。いえないんだったら、数字の前後に "=" を入力させる表記法・入力法は誤っている可能性があります。
小数点を統一したいという話は、どちらかというと、この不可知問題の解決方法のひとつと捉えたほうがいいのではないでしょうか。
Re:文字列の話ではない、仕様の話だ (スコア:0)
> 問題は、仕様を考えるに当たり、「世界中の表記と習慣を知っておけ」といわれたって困る、ってことなんです。
だから国際ライブラリ化して、言語の数値リテラルと一線を画するんですよ。
数値リテラルはあくまでリテラルであって、自然言語での数値表現とは別のものにしているんです。
今回
Re:文字列の話ではない、仕様の話だ (スコア:1)
で、数字リテラルに "," が含まれる環境があるので、ふたつの数字リテラルの表示・入力を区切るのに "," を使っちゃいけない。それも了解。
じゃ、ふたつの数字リテラルを区切るのに使ってもよい文字と、それを使ってもよい理由を教えてください。という話です。この部分は、数字リテラル本体ではないので、国際化ライブラリは面倒を見てくれません。
今から、国際化ライブラリに、「コンマと同等なもの」「括弧と同等なもの」というリテラルを追加する、ってのは、いいアイディアです。でも、今すぐの問題解決には役に立ちません。
そもそも、言語や文化によっては、「コンマみたいな」「括弧みたいな」なんて使わずに、逆ポーランドで示してるかもよ。
Re:文字列の話ではない、仕様の話だ (スコア:0)
国際化ライブラリを使う、で現状には特に問題ないのでは。
ようは自然言語の「数値表記文字列」とプログラミング言語文法の「数値リテラル」は最初から「別物として扱っている」ということなのですが。
例を使うと、あるプログラミング言語では範囲を [1.2, 3]としていた場合、自然言語の数値表記標準が変わったからといって[1,2, 3]に変える必然性はまったく無いのです。
1,2というような「リテラル」を使う言語なら文法が[1,2:3]のようにわかりやすくしているでしょう?
Re:文字列の話ではない、仕様の話だ (スコア:1)
「体重:56.4,58」と、体重の範囲を出力するプログラムがすでにあったとして、どうすればいいのですか? このままだと、たとえば仏文環境なら、「(体重のフランス語): 56,4,58」と表示されます。これじゃ、わけがわからないです。
私としては、最初から自然言語の話しかしていないつもりです。
Re:文字列の話ではない、仕様の話だ (スコア:0)
ロケールに応じて、自分でそれぞれ用意したフォーマッタとパーザーを選択すればいいだけでしょ。
この場合だと、パ
Re:文字列の話ではない、仕様の話だ (スコア:2, すばらしい洞察)
というわけで、「国際化プログラミングでは、数値表現は日付や時間と同様にロケールによって変わるものです [srad.jp]」では不十分であり、ロケールによる表現の変化に合わせ、周辺の表現も適切に考えておく必要があります。
また、「変更があるのは所詮ライブラリの中の話です [srad.jp]」だけでは収まらず、ライブラリの変更にあわせて周辺の表現を作り直す必要があります。
たとえ数字と記号しか表示しないプログラムだとしても、サポート各言語ごとに、数字や記号の使用習慣に合わせて、記号の使い方・配置の順序を考え直しましょう。というのが正しい解。だから、仕様の問題なんです。
表示も入力も数字だけなら、ライブラリにお任せでいいんですけどね。多国語化・国際化を考えるプログラムの入出力が数字だけっていうの、珍しいんじゃないかな。
Re:文字列の話ではない、仕様の話だ (スコア:0)
カンマ使っているロケールはすでにあるわけで、国際化をしていればカンマ使ってないロケールのものをカンマ使ってるロケールのものにあわせるだけですむ話では。それ
Re:文字列の話ではない、仕様の話だ (スコア:1)
# 誰か、良いモデレートを。
Re:文字列の話ではない、仕様の話だ (スコア:1)
以下の条件がそろった場合に限り、ロケールあわせですむことに、異論はありません。
o 国際化ライブラリを使っている
o コンマを使う文化圏の存在を前提に、全体の仕様を決めた
でも、そんな人にロケールと国際化の説明なんて不必要。つまり、この場合、正しく、かつ無意味な意見です。
わざわざ説明するからには、相手はこんな状態のはず。
o 国際化ライブラリを使っていない
o 使ってるんだけど、国際化ライブラリが小数点にコンマを
使うなんて知らずに仕様を決めている。「58,4,53」みたいに。
そうであれば、「ロケール一発」という説明は、不足に過ぎる。少なくとも、プログラム全域にわたって、「数の表現にコンマが入っても困らない仕様になっていること」を確認しなおす必要があります。自分が考えるところの仕様の書き方 (の選択肢)、あなたの言うところのガイドラインは、その明らかに不足している部分を、多少は補ってるんでないかなと。
今日。カンマを使っているロケールがあると知ったとして。当然、今日以降のプログラムは、世の中には小数点にカンマ・ピリオド*以外*を使っているロケールがありうることも想定しておく必要があります。また、将来、新に追加になったロケールでは、小数点はカンマでもピリオドでもない可能性があります。--- 昨日まではピリオドを知っていて - 今日はカンマを知ったから - 今日からピリオドとカンマだけ考える --- って考え方、ちょっとアホっぽい。国際化ライブラリを使うからには、プログラムを作った人が知らない、あるいは将来のロケールについてもごく自然と適応することを期待されています。
1つめの方法。 ライブラリ使用側の仕様。がんばって、コンマ・ピリオド以外に小数点で使ってなさそうな記号を探る、国際化ライブラリがどんな記号を勝手に使っても、適応して適切に表示する。
2つめの方法。 ライブラリ使用側の仕様。あきらめて、知っている範囲の言語だけをサポートする。
3つめの方法。 ライブラリ作成側 (の上位の上位の上意) の仕様。世界中の小数点をコンマ・ピリオドのどちらかに統一する。こんなことをうだうだいってちゃ仕事にならないから。
ありうべき表現をどこまでも追求する方法に従う場合、国際化ライブラリでは不十分です。たかだかふたつの数の表示というプログラムを組むにあたってさえ、既存のロケール全てを熟知の上、将来のロケールを予想する必要があります。世界中のどこかに、コンマ・ピリオドのどちらでもない小数点があるかもしれないです。
プログラムを作る人が知っているロケールだけ表示できればいいや、とする方法を採用する場合。国際化ライブラリは、あれば便利ですが、無くったってプログラムは書けます。だって、プログラムを作る人が知ってるんでしょ。仮に使っていたとして、ロケールによっては数の表現にコンマを使いうる、ということを知らずに使ってちゃ、小数点がコンマのロケールの表示は当てにならないでしょう。先の「58,4,53」みたいな表現が出てきて、どれが元コンマでどれが元小数点か、悩んで困ることになります。小数点がコンマでもピリオドでもない場合、もっとひどいことになります。
世界中の数字の表記を統一してしまえ、という方法を採用する場合。これは、何もしなくても勝手に国際化になる、という意味です。この立場では、数の表記は唯ひとつ、国際化ライブラリを使うなんてとんでもない、ということになります。よって、国際ライブラリの規格から、数の表記の部分がごっそりなくなります。すると、国際化ライブラリを使っていたからこそ、作り直しとなります。影響はほとんどないと思うけど。
いずれにせよ、どの立場でも、国際化ライブラリって、不十分または不必要です。
余談。標準が決まった時には、小数点はコロンになってるかもよ。あり得ないとは思うけど、ないとは断言できないし。
Re:文字列の話ではない、仕様の話だ (スコア:0)
この一文で彼が国際化プログラムを何も理解してないことが明らかですね。「いっちまんえーん」本 [amazon.co.jp]でも買って勉強してください。
Re:文字列の話ではない、仕様の話だ (スコア:0)
>また、「変更があるのは所詮ライブラリの中の話です [slashdot.jp]」だけでは収まらず、ライブラリの変更にあわせて周辺の表現を作り直す必要があります。
>たとえ数字と記号しか表示しないプログラムだとしても、サポート各言語ごと
Re:文字列の話ではない、仕様の話だ (スコア:1)
そそ。常識。それはそう。
でだ。本題に従うなら、ここのコメントは、3つのことを考えなければいけないわけだ。
2.については、少なくとも英語圏と日本語圏の人は、いまさら考えなくてもよいだろう。
問題は 3. です。もし、3. が正しいということになったら、既存のロケール小数点表記が変更になるかも。そうすると、ja と en の、全表現を見直せ、ってことになります。メッセージカタログを使っているだけでは、この問題は解決しない。これも常識。
話は戻って。この大元のコメント [srad.jp]、要約すると「ロケール変更、一発」と書いてある。この方法は、1. のレベルの人が前提知識無しに信用すると問題がある。また、3. に対しては何の問題解決にもなっていない。つまり、大元のコメント [srad.jp]は、過剰に省略されていて、かつ非常識なことを書いている。しかも+モデがついている。これをほっといちゃ、問題なんですわ。
ここで、状況を整理して。
ところで。あなた [srad.jp]はtanimachiよりもより適切な知識と意見を持っているように見受けられます。だとしたら、あなたこそ、大元のコメント [srad.jp]に適切な説明コメントをつけ、世間の誤解を解き、正しい知識を教授して、おまけとして+モデをもらうべきだったんでしょう。
この話、国際化ライブラリやメッセージカタログは、副次的な話だと思ってます。新たな言語に対応するときや既対応言語の小数点表記の仕様が変わったときに。重要な点は、小数点表記だけでなく、表現全体を見直し、作り直す必要がある、ということ自体です。その実現方法は、しなきゃいけないことが決まった後の話です。つまり、当たり前のことの再確認が重要、方法はその当たり前の方法と一致していることを評価してから。そういう意味で言うと、ロケール一発というのは、ものの順序、方法、両方とも誤ってますね。
最後に。力説くさいのは自分の表現力不足。精進してみます。
Re:文字列の話ではない、仕様の話だ (スコア:1)
……どんな例がいいのかな。世界中の小数点がコンマで統一されたら、今まで「体重: 56.4,58」と表示されていたのが、「体重: 56,4,58」と表示されるようになります。とでも差し替えさしてください。
それとも、対応済み英語で「weight: 56.4,58」、対応済みフランス語で「(フランス語): 56,4.58」、対応済み日本語で「体重: 56,4,58」と表示されるものが、未対応小数点コンマロケールだと「weight: 56,4,58」と表示されてしまいます (ただし、未対応ロケール時のテキストは英語を使うというソフト限定)。のほうがいいんだろうか。
最初のコメントの人。たとえば、LC_ALLはjaのままでLC_NUMERICをコンマなやつに変えりゃいいじゃん、といっているような気がしてきた。こういう時って、日本語でも、小数点がピリオド用とコンマ用の二通り、あらかじめテキストを用意した上で、現在の小数点表示を一旦確認して、それにあわせて選択するのが正しいのかな。
あらかじめそこまで考えてプログラムを組むのが常識なのなら、こりゃもう、常識を教えてくださいとしかいいようないです。こういう、ロケールの組み合わせによるテキスト選択って、結構ありそう。
Re:文字列の話ではない、仕様の話だ (スコア:0)
は、
Re:文字列の話ではない、仕様の話だ (スコア:0)
現在あちらの文化圏のひとたちは関数の引数やベクトルでの数値間の区切にどんな文字を使っているのですか? 単に数値単体の表現方法ではなく、数学教育にも影響を及ぼすような変更が必要になってくるのでしょうか。
Re:文字列の話ではない、仕様の話だ (スコア:0)
いくら「国際標準に合わせて","を小数点にします」と言われても小数点に"."を使う人はいるし、「入力がまちがっているから意図しない動作をしました」は技術屋の言い訳にもならないだろうし。
Re:数値表現は文字列の話だよ (スコア:0)
eval があるような処理系じゃどうするの?
少なくとも perl じゃ "," を小数点として扱う方法は無いと思うな。
#やっぱ小数点は "." だよなと思う元 FORTRANer
内部データとしての数値と外部表現としての数値(Re: (スコア:0)
漢数字をevalしますか?
evalで解析したいのは 数値リテラルになってる文字列でしょ。
カンマとかピリオドとかの話は、UIとか文章とかに埋めるものでしょ。
もし同じものと思って使っているなら、それはた
Re:内部データとしての数値と外部表現としての数値(R (スコア:0)
perllocaleとかにもきちんと載っている正式の方法ですね。
少し補足すると、OSの機能を使っているので、きちんとロケールがそろっているOSでないとだめですね。(cygwinとかではまだ無理)。
コード例:
use POSIX qw(locale_h);
use POSIX qw(strtod);
use locale;
$l1 = "2 / 5";
$l2 = "3,5";
$n = eval($l1);
$original_locale = setlocale(LC_NUMERIC);
setlocale(LC_NUMERIC, "de_DE");
$nstr = sprintf("%g", $n);
$m = strtod($l2);
setlocale(LC_NUMERIC, $original_locale);
print
Re:数値表現は文字列の話だよ (スコア:0)
じゃあその他の国の人は違和感覚えながら小数点をピリオドでプログラミングしてるんでしょうか。
逆に、小数点をカンマで統一した場合、言語の文法も変えるのでしょうか。
Re:数値表現は文字列の話だよ (スコア:1)
どの国の人でも、用語の意味とか表記でいちいち違和感を感じ続けてたら、その言語でプログラミングなんてやらないと思いますよ。
# C言語のstaticなんて明らかに、英語のstaticで連想できる範疇を超えてるし。
Re:数値表現は文字列の話だよ (スコア:0)
>計算機屋さん(高度な数値計算プログラミングをする人?)
そうなの?
Re:数値表現は文字列の話だよ (スコア:0)
# 高度な数値計算プログラミングをする人ほど、ユーザインターフェース以外の部分で数値を扱っていると思う