任意の浮動小数点数を文字列に変換、逆変換して元に戻せるか

総合スコア5944

2015/12/12 01:36

またまた横からですが、ありがとうございます。これが浮動小数点数の精度を維持したまま10進数表現へ変換できる最小桁数のようですね！！でも、どうも説明文が間違っているようで、中々頭が痛い。 DECIMAL_DIGだけは標準規格にあるようですが、 > http://www.cplusplus.com/reference/cfloat/ > Number of decimal digits that can be rounded into a floating-point type and back again to the same decimal digits, without loss in precision. 「10進数表現を浮動小数点化し、再度10進数へ戻しても同じ値に戻る10進数桁数」なので、逆の意味です。MSVCでは17でした。17桁の10進数をfloatへ変換して元の10進数へ戻せるわけないし。説明文が誤っているようです。そして、FLT_DECIMAL_DIGとDBL_DECIMAL_DIGは規格化されてないようですし。下記のような標準規格関係のメールがありましたので規格化する動きはあるっぽいです。（こちらでは正しい意味で使われている模様。） > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1377.htm 皆さんも言っているように、このような使い方には需要がないんでしょうね。 xml形式やJson形式で保存／回復したいケースでは必須なので、そこそこ需要はありそうな気もするのですが．．．値が変化していないことを確認するのに、doubleなら2^64回の比較が必要な気がしてます。丸め方法は複数あるので、ちゃんと辻褄が合うように選択されているのか確信が持てないのです。

2015/12/12 02:00 編集

うわっ、リロードしてませんでした。 > 追記 > Wikipediaの IEEE 754 の下の方にある「文字列表現」に書かれていました。これが答えですね！！十分な桁数の10進数へ変換して戻した時、値が変化してはいけない旨が書かれてました。ならば、実装を信用して良いケースでは浮動小数点で保存できそうですね。 vc3000さんの質問に便乗してしまい、申し訳ありませんでした。でも、以前からの疑問が解消しました。vc3000さんcatsforepawさん、ありがとう。

2015/12/12 01:59

> 以前からの疑問が解消しました。良かったです。9桁/17桁のことは以前から知っていましたが、その根拠を知らずに使っていました（そういうものだと思って使っていた……）。この件で調べて知ることができてすっきりした気分です。この質問はGoodです。

2015/12/13 07:23

ありがとうございます。疑問が解決しましたので、ベストアンサーにして解決済みにさせていただきます。

2015/12/13 07:45

FLT_DECIMAL_DIGとDBL_DECIMAL_DIGはC11では定義済み(N1750 p.31)です。古いgccだと対応していないようですが、手元のgcc 5.3.0では普通にコンパイルが通って、9と17でした。

2015/12/13 07:54

raccyさん、情報ありがとうございます。「-std=c11」を付けたら通りました。そういえば、回答に書こうとして試したときは未指定でした……。

行動規範の内容に同意します

正規化数に限れば10進表現の精度を十分に取れるなら可逆文字列化も可能ですし、+0と-0も"+0","-0"と文字列化していいというルールにすれば表現できますが、NaNや非正規化数が無数のビット表現を持っているのでそれらを一般的な文字列表現（たとえば"Nan"）にしてしまうと情報が失われます。

投稿2015/12/11 11:18

yuba

総合スコア5570

2015/12/11 13:27

すいません。横から失礼します。私も同じ問題が気になったことがあり、あれこれ調べたのですが確認できず、固定小数点で保存／回復したことがあります。 > 10進表現の精度を十分に取れるなら可逆文字列化も可能下記に「十分な桁数をとれば可逆文字列化可能」な旨の証明が記載されてました。 https://docs.oracle.com/cd/E19957-01/806-4847/ncg_goldberg.html#2619 原理的には可能なようです。十分な桁数で文字列化すれば、元の値を回復できることを標準ライブラリが保証しているのかどうか、ご存知ないでしょうか？

2015/12/11 15:43

ありがとうございます。「定理 15 2 進の IEEE 単精度数を最も近い 8 桁の 10 進数に変換した場合、必ずしも 10 進数からもとの 2 進数を一意に復元できるわけではない。ただし、9 桁の 10 進数を使用すれば、10 進数から最も近い 2 進数への変換により、もとの浮動小数点数が復元される。」の部分が答えのようですよね。標準ライブラリがどうなっているのかも気になりますね。どなたかご存知のかたがいらしたらご教示いただきたいです。

退会済みユーザー

2015/12/11 17:11

「標準ライブラリ」とはどのようなものを想定されていますか？数値を敢えて10進文字列で持つようなことはしない気がしますが…(単に文字列化する処理なら、可逆で無くてもいいですし)

2015/12/12 21:59

標準ライブラリはCのprintfを想定していました（libcですね）。 printfで変換したものをsscanfすると元に戻るのかと。 PHPやRubyなどはprintfでなく独自の変換関数を持っているかもしれませんが、ウェブ経由で文字列化した実数をやりとりしたとき精度が落ちないのかと気になっていました。

行動規範の内容に同意します

逆変換する側が違う種類のマシンを想定するならば、原理的に不可能です（エンディアンの問題を言っている訳ではありません）。
Cは浮動小数点表現について単一の規格(例えばIEEE)を強要していないので、仮数部、基数部...と分けて送ったとしてもそれらのビット数が異なれば、同じビット列になることはありません。
同じマシンを想定するなら10進数の必要はなくバイナリデータで良いと思います。

投稿2015/12/12 00:07

退会済みユーザー

総合スコア0

2015/12/12 12:59

> 原理的に不可能ですそんなことはありません。私の知っているCPUの浮動小数点形式は全てIEEE 754準拠ですし、VC++に関していえば浮動小数点形式がIEEE 754準拠であることが明確に書かれています。gccもプロセッサ毎にIEEE 754の準拠をどう制御するのかを指定するオプションが用意されています。 > Cは浮動小数点表現について単一の規格(例えばIEEE)を強要していないのでこれについては調べてはみましたが確認できませんでした。ただ、コンパイラの仕様として、事実上の浮動小数点形式の標準がIEEE 754とみなして問題ないと思います。でなければ、言語仕様でIEEE 754準拠を規定しているJavaやC#との連携が取れなくなります。

退会済みユーザー

2015/12/12 23:18 編集

>私の知っているCPUの浮動小数点形式は全てIEEE 754準拠です私の知ってるところでは、PC-9801のBASICの浮動小数点エミュレータくらいでそれ以降、出会った事がありません。 >事実上の浮動小数点形式の標準がIEEE 754とみなして問題ない同意です。たぶん。 >言語仕様でIEEE 754準拠を規定しているJavaやC#との連携が取れなくなります。 VSは単一のマシンでしか動かないので例になりませんが、javaは決まってるんですか。私にとっては以外な事でした。勉強になります。質問者さんが、「原理的に」と表現しているので、「原理的に」と返したくなります。　・Cは計算機の内部表現をそのまま使って計算している　・計算機の内部表現はいろいろ有っても良いという原理・原則を勝手に考えだしまして、 > 原理的に不可能ですと申しました。本当は、「浮動小数点を使ったプログラムの許せる誤差」を説明すれば、printfで良いのじゃないかとか、変換も要らないのではないかと言った結論になります。質問者さんは、原理原則的なバイナリレベルでの整合性を気にしてるようなので、結論は「できません」です。あと、他の言語と連携なんて、Cは考えてませんよ。

2015/12/12 23:42

> 結論は「できません」です。 IEEE 754には文字列形式への変換で完全に一致する旨の規定が含まれており、当然それはバイナリレベルで同じことを指すので、結論は「できます」です。 > 他の言語と連携なんて、Cは考えてませんよ。 Cは考えていなくても、他の言語は考えています。

退会済みユーザー

2015/12/13 02:05 編集

>IEEE 754に.....「できます」私：IEEEで無い場合は、.....「できません」議論になっていませんね。

2015/12/13 02:31 編集

質問者さんが何を知りたいのかを理解しようとせず、提案もせず、理屈をこねて否定ばかりを続けている以上、議論にならないのは当然ですね。

退会済みユーザー

2015/12/13 06:13

catsforepawさんの根拠は私の回答を後押しする事例であるのに、結論が違うのです。　・VC++に関していえば浮動小数点形式がIEEE 754準拠 --->マシンは単一x86だけの例　・gccもプロセッサ毎にIEEE 754の準拠を　　　どう制御するのかを指定するオプション　--> IEEEに準拠していないことも想定している?（できれば何のオプションなのか教えてほしいのですが）。　・JavaやC#は決まっている --> マシンは仮想。どんな風にも作れるからこんな事ができる例。みなさんに有害な情報で無い限り、他人のコメントに反対意見を書くことはどうかとおもいます。いろいろな意見があって良いと、私は考えます。

2015/12/13 06:29 編集

そもそも質問者さんは「32ビット、IEEE形式」という前提を明示しています。であるならその前提に沿って話をするのが自然の流れです。にもかかわらず、NoritakaSuzukiさんはそれを否定し「不可能」と言い切ることが本当に無害なことか、判断は保留しますが、気になったのでコメントしたまでのことです。

退会済みユーザー

2015/12/13 08:59 編集

>質問者さんは「32ビット、IEEE形式」という前提を明示しています。私もそこを重要視しています。catsforepawと同じです。しかし、同じマシン同士なら浮動小数点のフォーマットを気にする必要なんか無いのに、あえてIEEE単精度だと宣言しているということは、その違いも気にする？と考えたのです。 catsforepawさんには、初めのコメントで「流れが違う」とコメントしてほしかった。そうすれば自分はこう考えるけれど・・・・・と議論ができます。

行動規範の内容に同意します

C99以降であればstrtofとprintf系のa/Aを用いることで、16進数表記(バイナリ表記)でやりとりできます。
cppref: strtof, strtod, strtold
cppref: printf, fprintf, sprintf, snprintf, printf_s, fprintf_s
printf系では普通の10進数小数点数表記以外にaまたはAを使うと16進数表記にすることができます。この表記は標準の桁数がその型が持つ精度を正確に(exact)表現できる桁数(基数が2以外の場合は補足参考)となっており、(桁数を設定しない限り)精度や進数の違いにより情報が落ちることはありません。そして、strtofはその16進数表記をそのまま解釈して変換できます。strtofは-0やinf、nanにも対応しているのでそちらも問題ありません。なお、doubleとlong doubleも同様にできます。

変換を確認できるかも知れないサンプルコード(なぜかC11)

C
1#include <stdio.h>
2#include <stdlib.h>
3
4int main(int argc, char *argv[])
5{
6  for (int i = 1; i < argc; i++) {
7    float f;
8    char *end;
9    f = strtof(argv[i], &end);
10    if (argv[i] != end) {
11      printf(u8"  通常表記: %f\n", f);
12      printf(u8"16進数表記: %a\n", f);
13    } else {
14      fprintf(stderr, u8"変換できません！\n");
15    }
16  }
17  return 0;
18}

補足: FLT_RADIX(floatとかの基数)が2の乗数以外の場合

ほとんどの実装では浮動小数点数に2進数を用いており、このような2の乗数が基数の場合は16進数でも正確に表現できるため問題にはなりません。しかし、C言語では2進数でなければならないという制限はないため、16進数であっても正確に表現できるとは限りません。その場合については、別途規定されており、double型において区別するのに十分な(sufficient to distinguish values of type double)桁数とされています。詳しくは、C11仕様書(draft) N1570 §7.21.6.1 8 a,A p.313-314をご参考下さい。

補足2: strtofが正確なのかについて

2進数などの基数が2の乗数の場合、16進数表記であれば正確に解釈されます(N1570 §7.22.1.3 5 p.343参照)。しかし、これも基数が2の乗数で無い場合は、別途規定されており(N1570 §7.22.1.3 8 p.343参照)、正確に解釈できないため、その環境における丸め込みが行われます。上記の補足で述べた区別できる十分な桁数であれば丸め込みが起きても元々の情報から抜け落ちが発生するかどうかの規定は見受けられませんでしたが、「区別できる十分な桁数」という表現からすると、丸め込みが発生しても保持されるのに十分という解釈もできるかも知れません。2進数ではないC言語の実装系が手元に無い(というか、私は一度も見たこと無い)ので、詳しい検証はできていません。

補足3: NaNは保証できない

IEEE 754-2008では、NaNについてsignaling NaNとquiet NaNの2種類を区別するようになっていますが、C言語の仕様ではそのような区別が存在しないため、区別することができません。また、符号ビットや仮数部(ただし、全て0ではない)について任意の値が可能ですが、いずれの値もNaNと解釈され、C言語上では区別することができません。ビット列が異なるにもかかわらず、上記のprintfなどを用いた方法では"nan"としか表示できませんし、逆もまた同じで、strtofでNaNの時の各ビットを指定する方法がありません。つまり、この方法では精度を落とさずC言語上での同じ意味にすることはできますが、必ず同じビット列にできる方法ではありません。

投稿2015/12/11 22:26

編集2015/12/13 01:40

総合スコア21739

2015/12/12 22:01

大変勉強になりました。ありがとうございます！

2015/12/13 01:44

補足3で書きましたが、NaNについて問題があるため、この方法は忘れてください...orz

2015/12/13 03:30

raccyさんがリンクしてくれていた「C11仕様書(draft) N1570 」を確認してみました。 C言語規格は、浮動小数点の表現時、IEC 60559(=IEEE 754)に対応することを求めているようです！！更に、このドラフトでは、DECIMAL_DIG群の説明も正しく「バイナリ→文字表現→バイナリの時に値が変わらない桁数」であることが記載されてました。つまり、C11規格に準拠した処理系なら、文字列変換後回復しても値は維持されるはずということですね。ただ、IEC 60559で文字列との変換時の丸め方式を１つに定めているのかどうかが分かりません。なので、処理系が異なる時、常に同じ値を復元できるかどうか不明です。つまり、msvcのprintfで出力した浮動小数点文字列を、gccのscanfで回復した場合に常に値が維持されるのかどうか確信が持てません。同様に、例えばmsvcでビルドしたperlが出力した浮動小数点文字列をgccでビルドしたperlが元の値を回復できるのかちょっと心配です。そもそもC/C++言語の標準ライブラリに頼らず自力で実装していたら杞憂ですが。ま、でも、せいぜい最下位の桁が1つ化けるだけなので、余程シビアなアプリ以外は気にしないでよさそうです。 NaNについては、区別が必要ならプログラムでそれぞれに文字列化すれば良いと思います。数値の方はちゃんと値が回復できているのかの検証さえ困難なので、処理系が保証してくれないと中々厳しいのです。

2015/12/13 07:34 編集

> Chironian さん私の記憶によるとIEEE 754と同じでなくてはならないとはなってかなかったと思います。基数は制限されていませんし、指数部も仮数部も一定以上であれば多くてもかまわないとなっていますから。NaNの時の具体的なビット列も書いてなかったと思います。ただ、考え方が丸め誤差の仕方とかはIEEE 754と一緒だけなのかなと。丸めの方式はマクロ FLT_ROUNDS で取得できたと思います。そうなると、10進数→2進数のような変換が発生したときの丸め込みは環境依存のようですので、どの方式でも変わらないぐらいの桁数が DECIMAL_DIG だと思っているのですが、仕様書読んでもよくわからないです。余談ですけど、RubyにはMarshalというオブジェクトを文字列にダンプする仕組みがあるのですが、浮動小数点数についてはsprintfやstrtodの実装に依存しないようになっています。ソースコードを見てみると、なにやら自力でsprintfもどきをしたり、丸め誤差を吸収したりしているようなので、参考になるかも知れません。