#11175のN88P.BASの改造版、以下。単精度でも倍精度でも同じです。Iも13、SQR(N)も13なのだから、合成数と表示されるのが正当。実際、うちでは想定どおり動いています。ところが、konnoさんのところでは、単精度型ではこの比較式が成り立たず、ELSEに落ちてしまっている。倍精度型ではきちんと動いている。なんか、エミュの挙動がおかしいとしか思えない。前にも書きましたが、N88BASICの仕様では、関数の結果は引数と同じ型になることになっています。Nが単精度ならSQR(N)の結果も単精度のはず。以下の細かいところの値が出てくることがおかしい。したら、次のような簡単なプログラムでも、実機とエミュで差が出たりして。A#,B!これ、実はN88のマニュアルに載っているサンプルです。1.23457となるべきなのだそうです。エミュでこうならないとしたら、それはどこかがおかしい。エミュの作者に調査を依頼してもいいかも。これでいいんでしょうか。N88BASICでは、言語仕様として、THEN節に空文を許します。ときは、何もせずに、次の行に進むことになります。これ、#11169で触れているとおりです。これ、実はN88のマニュアルに載っているサンプルです。なるべきなのだそうです。NP2でやってみた結果です。1.23457表示は全く同じですね。表示と内部の数値がズレているのかなぁ。他のエミュの結果は全て以下の数値でした。1.23456898エミュの表示が上の数値で内部的には下の数値だとしたら、計算が合わないのも合点ですね。なるのかがわからないので、とっても気になります。エミュでこうならないとしたら、それはどこかがおかしい。エミュの作者に調査を依頼してもいいかも。表示は全く同じなので、おかしくないということですね。N88BASICでは、言語仕様として、THEN節に空文を許します。ときは、何もせずに、次の行に進むことになります。これ、#11169で触れているとおりです。想定どうりということですね。NP2でやってみた結果です。他のエミュの結果は全て以下の数値でした。表示は全く同じなので、おかしくないということですね。(違う!)NP2と他のエミュで差が出る、というところは一つの突破口かも。少なくともNP2以外のエミュは仕様どおりではないということで、バグ報告は可能だと思います。四捨五入するときの桁数を誤っていると想定されます。仕様上は、有効桁7桁、出力のときは7桁目が四捨五入されて6桁で表示、ということになっているのですから。以後は、NP2と実機の差異をどうするか。本来は7桁以上は格納してはいけないものを7桁以上格納している、その上7桁以上で比較してはいけないものを7桁以上で比較している、というように見えるわけですよ。usingを使う以外に、何かいい方法はあるかなぁ。実際、この程度の小数の誤差がどの程度影響するかはわかりませんがね。したら、昔からゲームなんかでも使われている可能性はあるわけで。konnoさんは、例えばバルーンパンチなんてゲームを覚えておられませんかね。シーソーに乗った人が交互にジャンプして上のほうで動いている風船を割っていく、というゲームです。このゲームで飛んでいる人間は、まるで重力で引かれるような感じで頂点に向かって減速して、また落下するときは加速するわけです。このゲームに限らず、まるで重力に引かれたような動きをする、だとか、慣性が働いているようになかなか加速しない上に速度が乗ったらすぐには止まれない、といった動きをするようなゲームでは、もしもそれなりに理論的なアルゴリズムを使うならば、物体の位置決定に二次関数を使う必要があるわけです。実際に使っているアルゴリズムがどこまで理論的に正しいものになっているかはわかりませんけどね。二次関数を解くためにはSQR関数が必要。ゲームによっては三角関数を使っているものもあるかもしれない。画面のXとYの座標は当然整数。ときどき、当たり判定がバグっているゲームというのが話題になることがありますが、あれっていうのはもしかしたら、小数と整数の比較の際の誤差の問題かも。実機だと正常に動いていたのにエミュだとおかしい、というゲームなどがあった場合、それこそこのような小数の誤差の可能性は高いかも。倍精度だとやっぱり重くなるので、たいていは単精度を使うでしょうし。NP2と他のエミュで差が出る、というところは一つの突破口かも。四捨五入するときの桁数を誤っていると想定されます。ことになっているのですから。したら誤解させてしまったかもしれません。他のエミュとは、98エミュ以外の、J31とかDOS/V系のエミュのことです。NP2以外の98エミュは確認していません。同じ結果になると思ったので。N88コンパイラ、インタプリタでも確認しました。表示は全く同じでした。MSのGW-BASICだと思います。T-BASICなどは漢字処理を覗けば恐らくほとんどそのままの互換性だと思っているのですがNECのN88BASICは、あちこち変えているようですが、単精度の精度もわざと落としているように見えます。その辺がエミュでの誤動作の原因になっているのではないかと愚考します。konnoさんは、例えばバルーンパンチなんてゲームを覚えておられませんかね。私はこの手のゲームはあまりやっていないので覚えていません。あれっていうのはもしかしたら、小数と整数の比較の際の誤差の問題かも。それこそこのような小数の誤差の可能性は高いかも。今回のことを踏まえるとそう考えられますね。倍精度だとやっぱり重くなるので、たいていは単精度を使うでしょうし。N88BASICは8ビット時代の互換性重視ではないかと思いますが、8ビットの貧弱なCPUでゲームの速度を上げるためにわざと単精度の桁を落としたのではないかと思います。16ビット版になっても互換性のためにそこを変えることが出来なかったのかも。したら誤解させてしまったかもしれません。他のエミュとは、98エミュ以外の、J31とかDOS/V系のエミュのことです。続報をいただいたことで、誤解は氷解しました。NECのN88BASICは、あちこち変えているようですが、うん、まぁ、その前のN-BASICからの互換性というのがありますからね。そちらのほうでいろいろと変えていたところはあるかもしれません。単精度の精度もわざと落としているように見えます。こちらについてはどうなんだろう。ないというわけではなく、根拠不足というか、これまでのところでは、私にはそう思えるだけの挙動はないような気がしています。いうことで、ちょっと調べてみました。単精度は4バイトであらわす実数、倍精度は8バイトであらわす実数。これは、調べた範囲では、どこも同じみたい。80年代の8ビットパソコンのBASICでも、21世紀の64ビットパソコンのCコンパイラでもおおむね一緒。ところが、倍精度のほうが、最近の国際規格とN88BASICで異なるみたい。