[
新規
] - [
ツリー
] - [
スレッド
] [
未解決
] [
緊急
] - [
優先
] - [
検索
] - [
なでしこTOP
]
「なでしこv1」開発掲示板
なでしこv1のバグや要望を書き込む掲示板
→
書き込み(
#1908
)を編集する:
名前
タイトル
本文
元スレはこちらですね: http://nade.jp-pro.net/bbs/bbs1/mbbs.php?m=thread&threadid=16 この問題は浮動小数点数全般に起こることなので、どうしようもありませんね。 （元スレでも VB の場合について言及されていますが、他の言語でも同様の例を作ろうと思えば作れると思います） 内部的には Delphi の Extended をずっと使っているので、 特定バージョン以降に限るバグということでもありません。 もっと言うと Delphi でも Extended 型を Trunc すると同様のことが起こります。 確かに *1.05 という計算においては誤差が下側に出る割合が他の言語と比べて多い気がしますが、 だからと言ってこの現象がバグだという訳ではありません。 この計算では Double で誤差が上に出て Extended で誤差が下に出やすいだけのような気がします。 数値型の浮動小数点の精度には倍精度（Double）を採用する言語が多く、 一方なでしこ（Delphi）では Extended を採用しているためこの差が出る、と。 Extended の方が精度が良いので、当然、計算誤差そのものは Extended の方が小さいハズです。 元スレで既に解決していますが、一応こういう場合のより一般的な対処方法も紹介しておきます。 (a) 浮動小数点計算を可能な限り避ける: 1900*105/100 (b) （小数点以下で）四捨五入する: 1900*1.05を60で小数点四捨五入 (c) 固定小数点型 / 有理数で計算する。 （なでしこにはどちらもないので自前で実装しない限りこの方法は使えません）
優先度
低
中
高
緊急
状態
未処理
詳細求む!
調査中
議論中
修正中
確認待ち
再修正依頼
解決
---
重複
---
アイデア
感想
告知
感謝
確認キー
👆お手数ですが、いたずら防止のために、「真夏」の読み方を記入してください。
編集キー
編集時に使うキーを入力(省略可能)
添付ファイル
🎁
ファイルを選択...
画像ファイル(最大300KB)を添付可能