こんにちは、岡本です
切削データをエクセルに渡して、計算結果を得たのですが、値が小数点以下
長い桁です。最低でも小数点以下第3位までを保持したいのですが、single
doubleどちらを使ってもVBでうまく扱えません。他に型があるのであれば
教えてください。
どうも、こんにちは。
>最低でも小数点以下第3位までを保持したいのですが、single
>doubleどちらを使ってもVBでうまく扱えません。他に型があるのであれば
>教えてください。
との事ですが。
VBで小数点以下を保持する「型宣言文字」は、SingleとDoubleの2つです。
(少なくとも、僕の知る限りで。)
ですので、Format関数もしくはRound関数を使用して、小数点以下第3位より下を切り落とした方が良いと思います。
メモリ消費はSingleの方が少ないので、そちらをお勧めします。
案1
1000倍してDouble型の整数値として扱う。
文字列に変換するときは、そのまま文字列に変換してから小数点を自力で挿入
案2
Currency型を検討
> 切削データをエクセルに渡して、計算結果を得たのですが、値が小数点以下
> 長い桁です。
つまり、有効桁数が多いのか?
> 最低でも小数点以下第3位までを保持したいのですが、
それとも…有効桁数少ないのか?
> single doubleどちらを使ってもVBでうまく扱えません。
具体的に、どう上手く扱えないんだ?
Double型の精度は…えーと、10進で15桁くらいはあったと思うんだけどなぁ…
一応Decimal型とかCurrency型とかもある。
ただし、DecimalはVariantの内部形式だったと思われる。
後は自前で装備するとか。
俺、最近被りすぎだ…>orz
decimalでどうぞ
出遅れたので、他の方の回答への補足事項を。
ひろさんが、固定小数点型(Currency)を挙げられていますが、これを使って
演算するときには、「演算結果のデータ型」にも注意するようにしてください。
たとえば、「Currency型 + Currency型」の演算結果は Currency型ですが、
「Currency型 / Currency型」の演算結果は、Double型となるため、
単純に割り算などを行ってしまうと、結局は誤差を生じる可能性があります。
それから、影さんが Format関数やRound関数を紹介されていますが、
これらを使う場合にも、若干の注意が必要です。
まずFormat関数は、OSによって丸め方が異なる可能性があります。
[Windows XP 環境への既存アプリケーションの移行] - [数値の「丸め」処理に関する問題]
http://www.microsoft.com/japan/technet/prodtechnol/winxppro/deploy/exappmigratoxp.mspx
また、Roundに関しては、ExcelのROUNDワークシート関数が四捨五入なのに対し、
VBのRound関数が銀行型丸め(bankers rounding)を採用している点も要注意です。
# bankers roundingは、浮動小数点表現(IEEE 754)のデフォルトの丸めモードです。
〈Excelワークシート関数〉
=ROUND(1.2325, 3) → 1.233
=ROUND(1.2335, 3) → 1.234
=ROUND(1.2345, 3) → 1.235
=ROUND(1.2355, 3) → 1.236
=ROUND(1.2365, 3) → 1.237
〈VB6/VBA版〉
Round(1.2325, 3) → 1.232
Round(1.2335, 3) → 1.234
Round(1.2345, 3) → 1.234
Round(1.2355, 3) → 1.236
Round(1.2365, 3) → 1.236
〈VB.NET版〉
Math.Round(1.2325, 3) → 1.232
Math.Round(1.2335, 3) → 1.234
Math.Round(1.2345, 3) → 1.234
Math.Round(1.2355, 3) → 1.236
Math.Round(1.2365, 3) → 1.236
あと、ガッさんがDecimalについても言及されていますね。
精度がどうしても気になるなら、このDecimal型を使ってみると良いでしょう。
これは、VB6ならばVariant型の内部データ型(CDec関数で生成可能)ですが、
VB.NETならば、Decimal型という専用のデータ型となっています。
Decimal型であれば、VB6のCurrency型とは異なり、割り算を行っても、
「Decimal型 / Decimal型」が、Decimal型のまま演算される事になりますので、
演算誤差は少なくなります。
私も回答を書いていたのですが、被るので省略... orz
弁さんから、丸めの話が出ていますので、便乗してちょっとだけ。
丸めには、
・http://jeanne.wankuma.com/tips/math/02-roundup.html
・http://jeanne.wankuma.com/tips/math/03-rounddown.html
・http://jeanne.wankuma.com/tips/math/04-halfajust.html
・それと、JIS 丸め (偶数丸め) があります
たいてい、小数点 3 位までの業務が多いので、気にしてませんでしたが、
やはり Decimal にした方が良いかなと、思案中...
WindowsXPの丸めの仕様はSP1で変更されています。
(この関係でSP1適用必須としたアプリは数知れず・・・)
http://support.microsoft.com/default.aspx?scid=kb;ja;418691
個人的には、1000倍してから演算するだけでも、
誤差をある程度抑えられるような気がしますけど。
丸め誤差の話はこのサイトの過去ログでも何回かでてますね。
厳密な計算が必要なら、自分で分数処理しましょうって事で。(汗)
http://madia.world.coocan.jp/vb/vb_bbs2/200407_04070172.html
でも今回の場合、そこまで厳密な計算が必要なら、元の切削データ自体を
Excelに "文字列" として渡してから、Excel側でセル書式を数値型にし、
あとからExcelのワークシート関数等で演算させた方が安全かも知れない。
VB/VBAと違って、データ型とか有効桁数の問題とかを考えなくてすむから。
VB6だと、P-Codeコンパイルか最適化ネイティブコンパイルかで
結果が変わる事もあるみたいだからねぇ。
> WindowsXPの丸めの仕様はSP1で変更されています。
> (この関係でSP1適用必須としたアプリは数知れず・・・)
> http://support.microsoft.com/default.aspx?scid=kb;ja;418691
このURLは、
> [Windows XP 環境への既存アプリケーションの移行] - [数値の「丸め」処理に関する問題]
> http://www.microsoft.com/japan/technet/prodtechnol/winxppro/deploy/exappmigratoxp.mspx
からもリンクされていますね。
補足に補足すると、Format関数の丸めについては、
OLEAUT32.DLL が v2.40系以下またはv3.50.5016以上ならば、四捨五入。
それ以外だと、銀行型丸めになるみたいです。
ついでに書くと、OLEAUT32.DLL のバージョンによるVBの動作の
違いというのは、他にも幾つかあるらしいです。
今回の丸めの話とは関係ないけど、環境の違いには気をつけましょうという事で紹介。
http://madia.world.coocan.jp/vb/vb_bbs2/200310_03100018.html
http://www.gj.il24.net/~nakasima/vb/trap/#VBTRAP19
・・・いっぱいあるので、被らないように、少しだけ。
小数点以下の、それぞれの桁数です。
・Double 14桁
・Single 6桁
・Decimal 最大28桁
・Currency 4桁
・・・合ってるかなぁ? 心配ですが、一応補足続きという事で。
ツイート | ![]() |