ab.com コミュニティ

チェックが遅くなりました。

イグトランスさん、河川屋さん有難うございます。

やっぱりＡＢ上のバグだったのですね。
ＡＢでデータを出力させて、それを読ませてみたりしたのですが、
ｐｒｉｎｔ文の出力ではｅで出力するのに、そのデータが読めないなんて
ずるいな～と思っていたのです（笑）。

私はプログラムソフトに関しては全くの素人なので、
よくわかりませんが、それぞれのソフト（例えばN88とＡＢ）が
完全に互換するというのは難しいと思っているので、
1ユーザーとして、そこまで求めてはいませんが、
本質問のように基本的な所は合わせて欲しいと思っております。
しかし、ver4まで来て誰も気づかなかったのですかね？
（最初はここに質問するのも恥ずかしいくらい、初級、低級の質問かと思って
いたので、よかったです。）

ちなみにイグトランスさんは
”遅くともAB 5.0正式版までには直します”
とおっしゃっていますが、ＡＢの開発に関わっている方なんですか？

指数”ｅ”も大文字小文字関係なく、
読んでくれるとありがたいですね。

とりあえず、イグトランスさんの暫定方法でやってみますが、
ＡＢ5.0で修正されることを期待します。

テキストファイルの中身が、たとえば
"3.1416 2.718"
だとして、

確かにだめですね。この場合のようにatofがものすごく限定的な解であることはわかりますが、AB5が出るまで待ってください、なんて悠長なことを言うよりは、（現実問題として活用できるかどうかはともかく）現時点で使用可能な手段を選択肢の1つとして示すことにしました。

Input（というよりそれが中で呼び出しているVal）が指数表記を認識しないことは、バグとして遅くともAB 5.0正式版までには直します。

・規格で決まっていることというのは、よほどの事情がない限り勝手にかえてはならない。
規格を守らないというのは、規格制定の意味がなくなるから。

残念ながらBASICの標準規格が好例で、正に誰も従わず意味のない状態です。こればっかりはActiveBasicだけでどうにかできる問題ではなく、やるなら他のBASIC処理系の作者さんも歩調を揃えてやらねば意味がないです。しかし、みなBASICを統一したくてうずうずしているという話も寡聞にして知りません。

かと言って、ABはN88互換かと言うと、バージョンが上がる度に非互換な事柄が増えており、独自路線を突き進んでいるのは誰から見ても明らかでしょう。それではだめだという声がないからです。それで良いと思われているのかもしれませんし、思っているが誰も言わないだけなのかもしれません。

・64bit整数で、桁が大きくなると演算結果が正しくない。（倍精度のルーチンを呼んでいる？）
・print 　(64bit整数)で、数値によってはe変換されてしまう。
　　要するに、正しい値が印字されず、近似値となってしまう。

これは、正にABがあちこちで数値をDouble型として扱っている部分があるためです。Long/DWordで表現できる値は、Doubleでも正確に表現できるため、64ビット整数型が無かった時代は、（速度などを気にしなければ）それで問題なかったのです。問題は64ビット整数型が導入されても修正されていないということですが。ちなみに、少なくともPrintのほうは、開発中のAB5で直っているはずです。

> 仕方がないのでVCランタイムを使って次のようにしてはどうでしょうか。
> Open "h:\t.txt" For Input As 1
> Dim s As String
> Input #1, s
> d = atof(StrPtr(s))

それではダメです。
テキストファイルの中身が、たとえば
"3.1416 2.718"
だとして、
input #1, d
input #1,e
ならば、d=3.1416 e=2.718
と読むけど、文字列で読むと
input #1, s　の時点で
s="3.1416 2.718"
となり、データがズレてしまう（N88Basicをはじめとするマイクロソフト系Basicと動作が一致しない）
という、もっとひどい不都合が生じるため。
※一般的に、データファイルのデータは、文字データ、数値データ（普通の小数点付）、数値データ（指数表記）
　　が入り混じっている、ということを忘れずに。

ＡＢの動作において、
x=3.14e20
のような数値をprint文で書き出すと、数値はe変換で出力されるから
ＡＢ自身が出力した数値を正しく読めない、ということになり、どういう観点でみてもバグに該当。
※print文で書き出した場合、ゼロをたくさんつけて、ｅ変換しないのであれば
　　正当性を認める。ただし、N88Basic互換を名乗ることについては正当性を認めない。
（こういう基本命令については、当然ながら、他の言語のランタイムを使わなくても
　正しく動作しない限り、仕様としてはオカシイことになり、素の状態で正しく動作しない
　ことは明らかにオカシイ。）

なお、MicrosoftBasic互換(N88Basic互換含む)と謳うなら、
e変換以外にｄ変換（3.14ｄ20という表記であり、e変換と意味は同じで、単精度と倍精度を明示的に区別するという違いしかない。）
も動いてもらわないと変。JIS(ISO)規格なら動く必要は無いけど。

なお、工学ではアタリマエのことを書くけど、
・こういう基本命令に対し、ライブラリとか非標準バンドルの関数で解決するのは反則であり、
基本命令だけではどうにもならない、ということ自体がものすごく変。
※アセンブラのあとに高級言語が生まれた理由を考えてね。これにケンカを売っていることになります。
・規格で決まっていることというのは、よほどの事情がない限り勝手にかえてはならない。
　規格を守らないというのは、規格制定の意味がなくなるから。
で、
・#N88BASIC　　という命令は、OSによる差異の吸収だから、MicrosoftBasic非互換でも認める。
・CVSやMKS$関数は、実数の内部表現がN88Basic時代とかわってしまったから欠落していてもそれを認める。
こういうのはいいんですよ。（規格を守ってないよ、ということを明記していれば。でも、ＡＢは明記してないが。）
でも、
・LINE INPUT# が使えない。
・暗黙の型宣言が使えない。
・CInt関数（近接丸めで整数にする関数）がいつのまにか切り捨て丸めになってしまった。
　　※近接丸めは、ＪＩＳ　Ｚ8401で規定される方法であり、四捨五入とも異なる。
・変数名で大文字と小文字は別扱い。
　（N88BASICでは、変数名を小文字で入力しても大文字になる。QBやVBも大文字小文字の
　区別なし。ＪIS(ISO)規格のBASICも大文字小文字の区別なし。）
・Do Until ～loopが使えない。　（While～Wendという旧式文法しか使えない。）

こういうのは、規格に合ってないと明記してあっても明らかにオカシイです。（明記してないともっと問題。なお、明記とは、「ここは合っていない」と列挙することをいうのであり、機能説明
といしての記述を意味しない。）
※規格どおりにつくった場合、メーカーに関係なく製品の互換が取れる、
　　とういうのが規格のそもそもの存在意義。Microsoftみたいに、
　　「自身でデファクトスタンダードを作る力」を持っていない限り、
　 規格に逆らうのはやめたほうがいいと思うが。
　　規格を外すのは、単に、「規格どおりに作るだけの技術がない」とみるのが世間一般の評価
　　なんです。例外として、MicrosoftBasicは、IS(ISO)規格制定以前に作ってしまったから、
　　「技術がない」とはみなされないし、既存ソフトの互換性という錦の御旗のためＪIS(ISO)規格に合致しないことは許されるるけど、ＡＢはそうじゃない。
　　MicrosoftBasicか、 ＪIS(ISO)規格か。どっちにも合わなくて、さらにどっちにも合わないだけの
　　理由が説明されていなければもうだめ。「技術がない」とみなされても文句いってはダメです。

また、
・64bit整数で、桁が大きくなると演算結果が正しくない。（倍精度のルーチンを呼んで
いる？）
・print 　(64bit整数)で、数値によってはe変換されてしまう。
　　要するに、正しい値が印字されず、近似値となってしまう。

これなぞ、「数学」にケンカを売る、という、更に勝ち目のないことをやっている
としか思えないのだけど......

AB 4.24で試してみましたが，確かにEより手前の部分までしか認識されませんね。Valでも同じです。

仕方がないのでVCランタイムを使って次のようにしてはどうでしょうか。 C言語のatofは文字列からdouble型の数値に変換する関数です。

ＡＢ初心者です。
なかなか解決しないので、投稿することにしました。

ＡＢの INPUT#1,A
とかでデータの
2.23E-9
とか
2.23E+10
を読ませるためにはどうしたら良いのですか？

N88BASICからプログラムの移し換えを行っているものです。。。
よろしくお願いします。