Petitverse

1や2の時はFLOORも同じ値ですね･･･
他の0.02や0.5をしてみると正常なことから、バグ(?)かと。

バグと言われると微妙だが、これは治せない現象だと思います。？ 3.99999999とすると4が表示される様に4に達していない数がMに入っています、またなぜ4に達しないかを簡単に言うと機械で小数点があるもので算出すると誤差が出てしまうためです。基本的な解決方法は正確な値を算出したいなら小数点を使わないことをお勧めします。例えば今回のケースでは0.05でなく5にして使用するときでけ100で割ると良いです。

なるほど。
確かに計算プログラムで小数点に弱いって書いてあるのはこういうことか。
感心感心。

これはプチコン3号の実数型（浮動小数点型）の仕様です。
基本的に2の累乗で表現できない小数にはすべて誤差が出るため単純に加算するだけでも誤差がどんどん蓄積されていきます。

その仕組みや対処方法については私のサイトのプチコン3号講座でまとめているのでぜひ参考にしてみてください。
http://ochameclub.web.fc2.com/petitcom3/lecture/floating_point_error.htm

人間の感覚で言うと
0.333333…+0.333333…+0.3333333…
が1じゃなくて0.999999…になるようなイメージ。

1/3 + 1/3 + 1/3 = 1 = 0.99999......


0.0625とか2進数で表し切れる値だと
こういったバグは出にくくなる。

私のプチコン3号講座でも書いていますが、この実数型の誤差はたとえるならば0.3333+0.3333+0.3333を0.9999としてしまうために発生してしまう誤差です。
もしも、プチコン3号が無限の桁数を記録できならば誤差は発生しませんが、2進数で最大52桁の計算しかできないために計算すればするほど誤差が蓄積されていくわけです。

とはいえ、プチコン3号の実数型も10進数換算で16桁弱の演算精度があるため普通に電卓代わりとして使うならば困ることはほとんどないでしょう。
この誤差はプチコン3号で変数の値を表示しても分かりません。（表示の際に小数第9位が四捨五入されるため）
したがって、どの程度の誤差があるのかを知りたければFORMAT$か自作関数PSTR$を使用する必要があります。

この誤差による誤動作防止策としては誤差を許容する記述を行うのが一般的なのですが、表示をイメージ通りに行いたいのであれば自作関数PRを使うのがもっとも簡単です。
これは見た目通りの値に丸める関数なので誤差を無視してくれます。

詳しくはプチコン3号講座に書いています。

誤差を許容するで思い出したが、実数を条件文で使う場合は『一致』と『以上』『以下』は使ってはいけない、『より大きい』か『より小さい』を使うべきって習ったな。

なるほど

小数点以下の値を使うプログラムはプチコン以外でも同じ問題があるので、小数点以下を扱う場合は必ず誤差が発生すると思っておいたほうがよいです。

どうしても小数点以下をちゃんと計算したい場合、シロさんの書いているように小数点以下2桁を使うなら100倍した値で計算しておいて、使うときだけ100で割るというようなやりかたがあります。

このやりかたは実際に VisualBasicの Currency型(通貨型) の内部で使われています。
※通貨だと1円とか１ドル単位で扱うけど１銭や１セントや消費税計算は小数点以下で扱います
※ついでにお金の計算の場合は小数点以下を無限につかうのではなくある程度で切り上げや切り捨てがお金の計算の仕様になるのがほとんどなので問題ないのです。


小数点以下の数値を加算し続ける場合、加算する値を小数点以下で持つのでは無く、整数値と分数の分子と分母を持つというやり方もあります。
0.05は 1/20 なので 1と20をもっておいて、1を加算していって20を超えたら正数部分を+1するというやりかたです。
変数のもちかたとか加算や計算がDEFを用意したりしないとめんどうになるけど、割り切れないような値のBPMを元にビートごとで処理をするみたいなのを誤差の蓄積が無く処理することができます。
※BPMを元にして1フレームごとに処理するには1フレームにどのぐらい値を加算して何の値を超えたかを判定するのにいろいろ計算しないとだったりします