2024年が明けました。
今年は元旦から能登で大地震があったりして、大変な年になりそうです。
亡くなられた方々のご冥福をお祈りいたします。

そんな世相を鑑みて簡単な御挨拶で済ませてしまいますが
今年もよろしくお願いします。


＃ うう、年末の無理が祟ったか、風邪をひいてしまいました。(ﾟ゜)☆＼(--#)ﾅﾆﾓｼﾃﾅｲﾀﾞﾛ
　　喉は痛いし食欲もなく、1日おじや1杯でしのいでいます。(;_;)

konnoさん

　あけましておめでとうございます。
　バタバタ、ヨロヨロしていて、新年のご挨拶が遅れました。
　まあ、けっこうゆっくりしてるのですけどね。
　年末年始は、一生懸命、１日１時間のダラダラ散歩ができましたし。
　白内障の手術、無事にいってくれることを祈っています。

　まだまだ部屋と頭と心の整理に忙しく（違うな、やりたくないのだろう！）
ＰＣ（Ｖｚ＆ベーシック＆ＤＯＳエミュ）方面はさっぱりですが、昨年の
konnoさんのご活躍には刺激を受けました。
　まだまだＤＯＳ＆Ｖｚでいきましょう！　僕はその気ですよ！

松の内ぎりぎりですが，明けましておめでとうございます。

いろいろな意味で大変な年になりそうな予感がしますが，
思うべきことは思い，言うべきことは言い，淡々と過ごしたいと思います。

今年もよろしくお願い申し上げます。

辰年ですが立ちません，下から支えようと思う今日このごろ。

文太さん、今年もよろしくお願いします。

> 　年末年始は、一生懸命、１日１時間のダラダラ散歩ができましたし。

長生きするには散歩が良いですよね、私も風邪の病み上がりで息切れしてます。(;_;)

> 　白内障の手術、無事にいってくれることを祈っています。

お気遣いありがとうございます。OFF会楽しんでくださいね。

> 　まだまだ部屋と頭と心の整理に忙しく（違うな、やりたくないのだろう！）
> ＰＣ（Ｖｚ＆ベーシック＆ＤＯＳエミュ）方面はさっぱりですが、昨年の
> konnoさんのご活躍には刺激を受けました。
> 　まだまだＤＯＳ＆Ｖｚでいきましょう！　僕はその気ですよ！

この年になって振り返ってみると、昔取った杵柄しか残ってないんですよね。
私の場合それがVZとBASICだったということです。
これからは自分の痕跡を残すためにやりたいことだけやっていきますよ。

そんな1年にみなさんでしていきましょう。

めざらさん、今年もよろしくお願いします。

> いろいろな意味で大変な年になりそうな予感がしますが，
> 思うべきことは思い，言うべきことは言い，淡々と過ごしたいと思います。

事件、事故も多いので、巻き込まれないように注意深く、慎重にして、1年無事に乗り切れるといいですね。

> 辰年ですが立ちません，下から支えようと思う今日このごろ。

なにやら意味深な書き込みですね。(^^;
私も急速な老化現象を感じて、アレなんですが、
今年の抱負というか、やりたいことの一つに、お願いがあります。
別発言で書きますね。

めざらさん、としきさん
突然ですがお二人にメール送ります。

もう16年前になりますが、うちの掲示板の検索を、全ログの改行またぎ検索に改造しました。

#2794：掲示板の検索機能強化 　投稿者：konno 　 2008/01/04(金)
#2821：掲示板の改行跨ぎ検索 　投稿者：konno 　 2008/01/12(土)

おかげさまで検索が非常に便利になりましたが、実はこの時野ざらし言と板塀にも
全ログ検索を導入してほしいと思っていたのですが、反応が薄くそのままになっていました。
今年は一念発起して、全ログ検索ルーチンをメールで送りつけることにしました。(^^;


find.cgi　は、wforum.cgi の中の2つのサブルーチンを抜き出したものです。

#  検索フォーム  #
sub find {

#  検索実行  #
sub search {

この2つのルーチンを置き換えるか名前を変えて追加するかして試してみてください。
エラーが出なければたぶん問題なく動作していることと思います。
内容は好きなように改変してください。

この全ログの改行またぎ検索を是非お二人の掲示板に導入してもらいたく、無理やり送りつけてしまいました。
なにとぞよしなに。m(__)m

konno さん

細かな理由はメールにて返信しましたが，
要は「気が向いたらネ」ということで．(^^;

> 要は「気が向いたらネ」ということで．(^^;

はい、気が向かれましたらよろしくです。(^_^)

野ざらしのアーカイブが進んでいないというご指摘も頂戴したので，
もう十年以上も放置していたログを上げようとしたところ，
過去ログに破損と番号の重複があることが判明してしまいました。(^^;

いきさつとしては，ちょっと長くなるやつですが……

Web Forum の確定した過去ログをnifty形式にするマクロで整形し，
Siさんの LOGSORT で整列させようとしたところ，
ヘッダの形式が異なるからダメよ……というメッセージで停止してしまいます。
で，いまさら Si さんのお手を煩わせるわけにもいかないと考えたので，
仕方なく LOGSORT.DEF を作ったわけですが，さて処理しようとしたとき
何を考えたのか間違えて元のWFログを指定してしまいました。それなりに待った挙げ句
何も出力されないので，なぁぜ・なぁぜ？と思ったら整形前の元ファイル。
それが判明した瞬間，なんなら元のWFログをソートすればよいのではと気づきました。
だって，先頭に発言番号のある1行1アーティクルなんですから……何故気づかなかった！？

どうせ HSORT を使うのならと三つの元ログをマージして処理したら，これが一瞬です。
しかし，三つも一遍に統合して並べたのにそれなりに空き番号があるではないですか。
実は，番号が飛ぶのが嫌で嫌で，掲示板利用者が自分で削除したような場合，
ログを編集して番号を詰めているんですよ。そういう性分だから仕方がない。
スパムも削除した後に番号をわざわざ詰めているんです。面倒ですけど。
要は，ある人が発言削除したとき，番号を埋めようとログを編集している最中に
その当人がコメントを書き直して書き込むということが発生していたのが原因です。
（ふつうの勤め人は書き込まないような時間帯だったので最悪のタイミングだった）

さて，どうしようかな。重複した一方を削除するのが簡単だけど，
とりあえず空き番号を割り当てられないか検討してみることにします。

そんなわけで，アーカイブも少々先送りという事情を長々と説明しました。

なんでこんなにクドクドしているかというと，ログソート及び空き番号列挙という
ふたつのマクロを久々に仕立て上げたのに，まるで無駄骨になってしまったから。
ちょっとしたリハビリでした，はい。……そんで飲んじゃった。ってわけ。

現時点では非公式版となっている2008年版の logsortw の存在を教えていただき，
実行してみたところ，ヘッダ不正問題は解決し，めでたく重複発言番号ありの
エラーによって停止しました。(笑)

さて，どうしようかな。
それに絡んでと思われるログ破損（一部消失）もあるので悩み中。
ログは固定されちゃっているので，ゆっくり考えればいいかな。

有難うございます＆御免なさい ＞ konnoさん

> 現時点では非公式版となっている2008年版の logsortw の存在を教えていただき，
> 実行してみたところ，ヘッダ不正問題は解決し，めでたく重複発言番号ありの
> エラーによって停止しました。(笑)

メールでのやりとりで、たまたまだったのですが、解決できたようでなによりです。

> さて，どうしようかな。
> それに絡んでと思われるログ破損（一部消失）もあるので悩み中。
> ログは固定されちゃっているので，ゆっくり考えればいいかな。

考えることは老化防止にいいですね。(^^;
私は全ログ検索出来てからは過去ログのアーカイブはこだわらなくなりました。
過去にやったことをなかなか思い出せなくなり、シナプスが繋がるよりも速く
全ログ検索で知りたい結果が出るので、もはやクラウドブレインです。
ブレインスモッグじゃないよ。(^^; ﾀﾌﾞﾝ

> それに絡んでと思われるログ破損（一部消失）もあるので悩み中。

ログの一部消失って、何とかなりました？
いや、一瞬だけ野ざらしに何やら書かれていたようですが、現在では削除済みの
ようなので。
なくなったのがどこかにもよりますが、その気になれば、野ざらしに具備されている
スパム対策用の強烈ログから復帰できる部分があるかもしれません。

あらっ，見られちゃってますね。(笑)
こちらに書くのも変なのですが，流れということでご勘弁ください，konnoさん。

ログをソートしてみたら，3882番から3909番が消失していることに気付いたのですね。
対応する時期としては 2011年のあの大震災の直前にあたる時期だったため，
1個以上のスレッドを現行ログから過去ログに移動するタイミングで，
震災に起因する突然の停電などに巻き込まれたに違いないと思いました。
Internet Archive にも前後数年が保存されておらず，スレッドのタイトルも不明。

ところがですね，手元の古〜いバックアップに残っていたのですよ。
そのバックアップが2012年2月の現行ログのバックアップだったので，
震災などの影響はまったくなかったと考えられるわけです。
そんなわけで消失告知を削除したという経緯です。

いやぁ，バックアップって取っておくものですね。

そもそもバックアップを日々保存していた理由が，
スパムが書き込まれたときに直前バックアップで上書きすると超ラクチンだから。
そのためにも定期的にバックアップをしようとしようと改めて思った次第です。

それでも，現時点で過去ログが不備な状態なので，何とかしないと，
たとえ「気が向いて」も全ログ検索機能を取り込めないという状況なんですね。

> そもそもバックアップを日々保存していた理由が，
> スパムが書き込まれたときに直前バックアップで上書きすると超ラクチンだから。

うちの板塀も、同じ理由でまめなバックアップは取っていたのですがね。
目的が目的なんで、バックアップの保存場所は同一サーバー内。
つまり、サーバーマシンがお亡くなりになると一蓮托生。
なので、現在ではそれはやめて、定期的に、lacoocanの非公開エリアにバックアップ
しています。

> そのためにも定期的にバックアップをしようとしようと改めて思った次第です。

定期的に何かをしようと思ったら、コンピュータに仕事をさせましょう。
私は、Windows純正のタスクスケジューラに仕事をさせています。
コマンドラインからサーバにアクセスするftpスクリプトを書いて、それをバッチで
呼び出していますが、そのバッチをタスクスケジューラに登録しています。
これであとはタスクスケジューラの設定次第で、月に１回だろうが週に１回だろうが、
裏で自動的にお仕事をしてくださっています。

確かにタスクスケジューラを使うと手間がないのかもしれませんね。
うちの場合は，常時起きているPCがないのと，日常の必要性もないので，
書き込みのあったタイミングでバックアップすることで十分に思います。

> うちの場合は，常時起きているPCがないのと，日常の必要性もないので，

ここがポイントか。
たとえば、週に１回、日曜の午前１０時、とかに設定する。
普段の日曜なら午前１０時にはPCを使っていない。
でも、ごくまれに、たとえばお天気の事情なんかで立ち上げていることもあるかも
しれない。
とすると、両方のアンド条件で、平均して月に１回のバックアップ達成、とか。
ここはあくまでも平均なんで、３週連続バックアップが行われたり、３ヶ月もの間
バックアップされなかったり、ということもおきえますが。
この辺、自分のPCの使い方と条件設定次第で、いかようにもできるかと。

実際の話。
常時起きているPCはないけれど，常時起こすことのできるPCはあります。
メインマシンは「休止状態」が有効なので，その気になれば制御可能です。
ただ，野ざらしの書込み頻度は五日に一度。
日常的に自動バックアップの必要性はないんじゃないかな〜

頻度の捕らえ方とか、まじめさが違うのかもしれない。
月に１度のバックアップでも頻繁だと感じるか。
週に１度でも、まれなことだと感じるか。
何らかのトリガを元に、必ずバックアップしないとまずいと思うか。
バックアップがないせいで復旧が困難を極めても、まぁいいかで済ませるか。

私自身は昔、PC-98でDOSのころは月に１回、HDDをフルバックアップしていました。
現在、Windowsになったら、フルバックアップなんて数年に１回。
堕落したものです。

頻度はまぁ，痛い目に遭った回数の反映か，性格かというところでしょうか。
ただ，痛い目というのは忘れやすいことも確かで，それこそ命の危険とか，
命よりも大事なデータ（そんなものあるのか？）とかでないと……とも思えます。

バックアップって，ふつうは自分で時間をかけて作成したものをするもので，
要するに時間にかける保険ですね。カネで買えるものは正直どうでもいい。
……はずなのですが，年金生活ともなると，そうも言い切れないわけで。

実際の話。
定期的にバックアップしているのは，メインの NAS。
これには USB で HDD が繋いであり，毎日夜中に自動バックアップしています。
また，半月に一度くらいの頻度で，サブの NAS 及びサブのデスクトップに繋いでいる
USB 接続の外付け HDD の二箇所にフルバックアップしています。
（フルと言ってもエロ動画なんかのディレクトリは対象外ですが）

前者は疑似ミラーですが，後者ニ個所は追加バックアップ。
メインから削除されたものも残っています。
ある意味安心なのですが，容量逼迫の原因なので，管理が面倒です。
少なくとも重複ファイル検索ツールをときどき使う必要があります。
（ディレクトリ名を変更したり，移動したものは重複してゆく）

その一方で，日々作成しているデータファイルのバックアップは怠っている状態。
今回のとしきさんとのやり取りで，そこ何とかしようか……と自覚しました。
要するに，もっともバックアップしなければならないファイルを放置していて，
メインのラップトップが逝ったら数ヶ月分の作業が失われる可能性があるということ。
ここは自動化や習慣化を考えなければいけないでしょうね。
腰を上げるきっかけを作ってくださり，有難うございました。

今までとしきさんに何度も指摘されていた msgview 個別発言のツリーのバグですが
としきさんに私の msgview.cgi を見て頂き、修正していただきました。
おかげさまでツリー表示は完璧になりました。＼(^^)／ ﾔｯﾀ-

としきさん、ありがとうございました。m(__)m

いやぁ、何とか動いてくれたようで助かりました。
一応、かなり複雑なツリー構造も含め、一通りの動作確認はしていますがね。
何せ、使ったデータが、うちの板塀のデータですから。
どんなチェック漏れがあるやら、想像もつきません。
というか、コードを書いた人が想像できないところにバグが忍び込むわけで。
そのうち、異常なパターンが発覚したら、そのたびに直すしか。
だって私、konnoさんのコードを読みきって修正したわけではなく。
正常な出力のallreadと異常なmsgviewを比較しただけなんで。
どういうロジックでツリーを出力しているのか、いまだによくわかっていない。
ま、動けば正義、というのはあるわけで。
とはいえ、動かないとき、だとか、動かなくなってしまったとき、のことを考えて
プログラミングしておいたほうが、いろいろと楽ができるとは思いますけど。
かつて、２０年ぐらい前だったかな、同じ職場にいた人で、この人は楽をしたくない
のかな、わざと難しくなることを好んでいるのかな、マゾっ気があるのか？　と
思わせられる人がいたことを思い出したりしました。

としきさん

> いやぁ、何とか動いてくれたようで助かりました。

としきさんのチェックなら間違いないと思っていました。
ありがとうございました。

> 一応、かなり複雑なツリー構造も含め、一通りの動作確認はしていますがね。
> 何せ、使ったデータが、うちの板塀のデータですから。
> どんなチェック漏れがあるやら、想像もつきません。

なるほど、人任せではなく自分でもチェックはした方がいいということですね。
お送りいただいた msgview3.cgi と自分の wforum.cgi で比較してみました。
wforum.cgi
		($no,$re,$lx,$sub,$eml,$url,$nam,$dat,$msg,$lt,$ho,$pw,$wrap,$oya,$sml,$com) = split(/<>/);
		$j++;
		if ($in{'oya'} == $oya) { push(@new,$_); 

msgview3.cgi
		($no,$re,$lx,$sub,$eml,$url,$nam,$dat,$msg,$lt,$ho,$pw,$wrap,$oya,$sml,$com) = split(/<>/);
		if ($in{'oya'} == $oya) { push(@new,$_); 
			$j++;

うげ、$j++; の位置が分岐前から分岐後になってる！！
他にも $mx=0; が追加されたり "}" の位置が、if の前になったりしていますね。
違いはこのくらいでしょうか。

実は昨日から STIME.EXE のソースを弄っていたのですが、うまく動かなくて・・・
色々調べたら、変数の設定を if 分岐の前にやっていたのが原因でした。(>_<)
どうやら私は分岐で躓く傾向があるようです。

> とはいえ、動かないとき、だとか、動かなくなってしまったとき、のことを考えて
> プログラミングしておいたほうが、いろいろと楽ができるとは思いますけど。

メールで言っていた、インデントや不要なコメントなどですね。
これからは気を付けるようにします。

> かつて、２０年ぐらい前だったかな、同じ職場にいた人で、この人は楽をしたくない
> のかな、わざと難しくなることを好んでいるのかな、マゾっ気があるのか？　と
> 思わせられる人がいたことを思い出したりしました。

うう、私のソースってそんなふうに見えているのですか・・・　(;_;)

実は私自身、$mxの初期化漏れってそんなに影響があるとは思っていませんでした。
でも、なんかうまく行かなかったので、わりと早い目に追加しました。
そして、$jは配列の添え字。
配列を設定する側で添え字のインクリメントが間違っていたため、配列を読み出す
部分で配列の正しい位置にアクセスしてもデータが取り出せず、未定義の情報で
条件判断するはめになってしまい、"┃"と空白のどちらを出力するかという部分が
うまくいっていなかったのでした。

> メールで言っていた、インデントや不要なコメントなどですね。

不要なコメントの部分、あれはほんと、まるで迷彩のような。
軍事用語でもありますが、私がコードを読んだ第一印象は、マージャン漫画での
この言葉。そして、ＳＦへのマジレスでよくある、透明人間は回りを見ることが
できないとの説から、光学迷彩を放った本人（konnoさん自身）が迷彩にやられて
しまった、という感じも受けました。

インデントのほうはねぇ。こちらはちょっと長くなります。
これは、コーディングスタイルとかいって、スタイル、つまり美学の領域。
美学って確か、文太先生の専門だったような気もする。
それはさておき。
たとえば、最近のkonnoさんのＢＡＳＩＣのコード。
最近いじった部分がわかるほうが良い、と思う人なら、昔のコードの部分は行番号
があって大文字、最近いじった部分は行番号無しで小文字にする、とか。一方で
統一感があったほうが美しいと思う人なら、全て大文字で行番号つきに統一、と
いろいろな考え方があるわけです。
でも、どの立場に立とうが、プログラムの論理構造、つまり順次・選択・反復と
いった構造をわかりやすくするためには字下げしかありません。既に３０年以上
前から、これは当たり前のこととされています。昭和６０年ごろに書かれた本には
「いまや字下げをしないプログラマは・・・」などという記述があったりします。

えぇと、いい機会だから書いてしまおうかな。
上記の本の紹介。#10398でも書いていますね。

林晴比古著「BASICによるプログラミングスタイルブック」
ISBN4-930795-28-1
定価1800円
昭和60年12月25日初版発行

私の持っているのは昭和61年11月の第4刷。
この本が出る2年位前からOh!PCに掲載されていたものがまとめられたのですがね。
この本が出た前後で、Oh!PCに掲載されるサンプルコード、特に学習用の講座などの
コードはみんな、なだれを打って、という感じで、読みやすいコードになりました。
その後、ベーマガのコードはあまり変わったようには見受けられませんでしたが、
ASCIIやI/Oのコードは、数年後には少し変わったかも。


> うう、私のソースってそんなふうに見えているのですか・・・　(;_;)

ま、私がとりわけぐうたら、と言うのもありますが。
プログラムを作るのって、結果が欲しいから作るものだと思っております。
なので、過程は楽をしたい。つまり、デバッグは楽なほうがいいと思っています。
だけど、あのコードは、なんかわざわざデバッグそのものを楽しむためのコードの
ような。
「デバッグ楽しいなぁ〜(;_;)」という経験の多寡でも考え方は変わるかも。

> 実は私自身、$mxの初期化漏れってそんなに影響があるとは思っていませんでした。
> でも、なんかうまく行かなかったので、わりと早い目に追加しました。
> そして、$jは配列の添え字。
> 配列を設定する側で添え字のインクリメントが間違っていたため、配列を読み出す
> 部分で配列の正しい位置にアクセスしてもデータが取り出せず、未定義の情報で
> 条件判断するはめになってしまい、"┃"と空白のどちらを出力するかという部分が
> うまくいっていなかったのでした。

うう、やっぱり基本がわかっていないとこういうミスを出しやすいのですね。
今回 BASICでも同じようなところで躓いて直すのにえらく時間がかかってしまいました。

> 不要なコメントの部分、あれはほんと、まるで迷彩のような。
> 軍事用語でもありますが、私がコードを読んだ第一印象は、マージャン漫画での
> この言葉。そして、ＳＦへのマジレスでよくある、透明人間は回りを見ることが
> できないとの説から、光学迷彩を放った本人（konnoさん自身）が迷彩にやられて
> しまった、という感じも受けました。

私も義体化が進んできたので、バトーのようになるのでしょうか。（違）
BASICではコメントを緑に表示しているので、マジで迷彩服のようになってます。(^^;

> 上記の本の紹介。#10398でも書いていますね。
> 林晴比古著「BASICによるプログラミングスタイルブック」

うう、いまさら聞けないBASIC みたいに微妙な・・・　見かけたら読んでみたいですね。(^^;

> だけど、あのコードは、なんかわざわざデバッグそのものを楽しむためのコードの
> ような。
> 「デバッグ楽しいなぁ〜(;_;)」という経験の多寡でも考え方は変わるかも。
　　　　　　　↑　　　　　↑
ククッ、、思わず吹いてしまいました。
まさに私のことを的確に言い当てているような。(^^;

追伸というか。
きちんと理解できていないというのもあって。
もしかしたら、$mxの初期化って、それほど重要ではないかもしれない。
ただ、少なくとも、allreadのほうでは初期化してあったような。
それに、初期化しておいて害になることもないし。

> > 上記の本の紹介。#10398でも書いていますね。
> > 林晴比古著「BASICによるプログラミングスタイルブック」
> うう、いまさら聞けないBASIC みたいに微妙な・・・　

私には、文体が引っかかるんですよ。
ただ、この時代のコンピュータの本を書く人って、特徴的な文体の人が何人かいて。
もう一人、ナツメ社あたりからアセンブラか何かの本を出していた人で、どうにも
文体が肌に会わなかった人がいたような記憶もある。
さて。
よく見たらタイトルが微妙に違う。
「BASICによるプログラミング・スタイルブック」
と、中黒があるのが正解。
章立ては

STEP1 基本を知る
STEP2 型にはめる
STEP3 サブルーチンの整理
STEP4 視点を変える
STEP5 工夫に、工夫を

となっている。中身に文法解説はほとんどない。
章の中の各節は、抜粋ですがたとえば

１　BASICの能力を見直そう
５　字下げをしよう
９　意味のわかる変数名にしよう
12　ブロック構造にしよう
15　マルチステートメントは上手に使おう
16　空白を入れよう
19　行番号をそろえよう

といった項目が46個あり、各節の中でそれぞれ根拠と共に例示がなされている。
当時の普通科高校生でも十分読める文章でしたから、文章としては今なら中学生
にも理解できると思う。いや、BASICのほうを解説してやらんとダメか。


さて、それでは、ちょっと一休みして。
つぎはいよいよ、konnoさんご希望の、掲示板検索ルーチンに取り掛かってみますか。
って、いつ開始するか全くめどは立っていませんが。

　ククッ、、思わず吹いてしまいました。
　会話の意味がまったく分からない。これが日本語であることは認知して
おりますが。

　それより、おお、そんな会話があったのか、１年ちょっと前。すごい
記憶力　＞としきさん。もちろん、検索したのは分かりますが。
　というわけで、 林晴比古著『BASICによるプログラミング・スタイルブック』
を図書館で探してみましょう。（注）

解説：まったく本腰が入ってませんが、僕は BASIC に興味をもっている
のですね。だから、この前のオフ会にも岡田元治さんの BASIC コンパイラの
マニュアル・プリントアウトを持って行ったのです。「ハノイの塔」の
コード・プリントアウトとともに。

　学習は「ハノイの塔」とは何か？　から始まる予定。まだ始まらない……。

>小さい円盤の上に大きいものを重ねることはできない。 [補説]フランスの数学者
>リュカによって1883年に考案された。 発売時に、アジアに伝わるパズルという
>架空の設定で宣伝されたため名付けられた。

　という語源だそうです。ベトナムはベトナム戦争の前までフランスの
植民地でした。日本もほぼ瞬間的に植民地化しましたけれど。
　ああ、インパール作戦。

konnoさん、
　konnoさんのお祈りのおかげで、例の地獄の作業、あの日のうちに終わりました。
いまは次の修羅場に備えております。ふらっふらになった記憶は新しいのですが、
そのとき、ちゃんと konnoさんに感謝し、お祈り返しもいたしました。m(__)m

鈴木康弘大先輩、
　お初です！　いらっしゃいませ！！！　Win7マシンでパーティション切り、ＤＯＳ
（FAT16）ドライブ！！！　やるぅ。
　「Ｖｚマクロほんとの入門」の作者さんですよね！！！　お世話になりました。

　江戸地方、今日は晴れです。（う、孝義さんだった。弟さん？）


（注）しかし、こういうのばっかですねぇ、＞己。_Software Tools in Pascal_は、
Ｖｚ黒本の隣に鎮座している。ここから１メートル以内。

> もしかしたら、$mxの初期化って、それほど重要ではないかもしれない。
> ただ、少なくとも、allreadのほうでは初期化してあったような。
> それに、初期化しておいて害になることもないし。

変数の初期化は最近の速いCPUでは特に必要かもしれませんね。
初期化してないせいでタイミングが狂い挙動がおかしくなることもありそうで。

> よく見たらタイトルが微妙に違う。
> 「BASICによるプログラミング・スタイルブック」
> と、中黒があるのが正解。

内容の紹介を見て、読んでみたくなりました。
ちょっと前までは本を読む気にもならなかったのが、目が復活したら読書欲も復活？

> さて、それでは、ちょっと一休みして。
> つぎはいよいよ、konnoさんご希望の、掲示板検索ルーチンに取り掛かってみますか。
> って、いつ開始するか全くめどは立っていませんが。

おお、期待しています。(^_^)
ログ形式が同じならそのまま動くのではないかと思っています。

> 　学習は「ハノイの塔」とは何か？　から始まる予定。まだ始まらない……。

「ハノイの塔」って、再帰のサンプルとしては非常に有名。
プログラム初心者に再帰を説明するのは「ハノイの塔」かフィボナッチ数列か、
というくらい。再帰を使ったほうがシンプルなものって、実生活ではあまり
見かけませんからね。
また、再帰でできるものは必ずループでもできるらしい。
なので、再帰からループへコードを変更するための題材にも使われるらしい。
で、ループならどうということもないのですが。
８ビットパソコンの時代のBASICでは、再帰というものが使えませんでした。
なので、そこでわざとループを使わず、いかに擬似的な再帰を実現するか、という
のも、ちょっと気取ったプログラマたちの力試しの例題に使われていたりして。
ま、再帰が使えない、という意味ではVzのマクロも同様。
だけど、Vzのマクロでも「ハノイの塔」はしっかりあるわけで。
結局、アルゴリズムなんて、どんな言語で実現しようが大差はないはず。
もちろん、向き不向きはあるでしょうが。

としきさん、

　詳細にありがとうございます。もともと「再帰」を狙ってあのサンプルを
選んだわけではなくて、単に「BASIC って読みやすいね。英語じゃん」という
だけだったのですが、この際ですから、「再帰」と「ループ」がどう違うのか
分かってやろうじゃないの、という気分になっています。
　多謝です。

　とはいえ、もうちょい待って。次々いろいろ起こるのですよねぇ、、、。
とほほ。

　ま、岡田元治さんのコンパイラに通るコードは、構造化もできるし、
「再帰」もできるし、十分にモダンなもの、ということですね。
　あ、マニュアルにね、FortranとかPascalとか出てきて（もちろん、
過去と歴史の話として）、そしてＣは出てこなくて、そうですかぁ、よい
ですねぇ、その語り口というものでした。
　まったく無駄話をしない学者肌な方ですが。

　行くぞ、ハノイ！　３月あたり。「ハノイへ行ってみよう！」とかいう
タイトルで、少しは勉強してから、再帰いたします。

　ありがとうございます。

　そうそう、BASIC のユーザ変数に「型」がある、そのトークンがある、
というけっこう前の解説にも感謝していました。重ねてありがとうございます。

　血糖値（糖尿）のあとは、胃がんか？　やれやれ。
　長生きするぞ！

　どうでもよい追記です。書くのを忘れていました。少し古い話。
　近場のも都立のも、図書館にはありませんでした。ＰＣ関係の古い本って
わりと廃棄される可能性が高いような印象。
　というわけで、いちおう古書店をサーチ。ビンゴ！　送料込み \1220 。
　こうして、書庫の肥やしが、いえ、さらなる幸福コレクションがもう１冊、
本棚に追加される予定です。今日か明日には、着くのではないかしら。
　ま、どうでもよいことですが。

> 本棚に追加される予定です。今日か明日には、着くのではないかしら。

もう届いていそうですね。
ま、気が向いたら本文を読みましょう。
推理小説でもありませんから、結末から読まなくても大丈夫。
＃おいこら
とりあえず、序文と目次くらいは読んでおいてもいいかも。
内容に対する批判はあったかもしれないけど、文体が合わない、というのは私くらい
のものでしょう。あ、でも、雰囲気が合わなくて上村さんの本に手を出さなかった、
というのはめざらさんでしたっけ。
そして、私の場合、文体ではなく内容のほうは、とても勉強になりました。
本文で作者は

> だから、筆者の書くプログラムは使用する言語がBASICだろうがCだろうがPascal
> だろうが、ほとんど同じスタイルをしている。

と書いていますが、私も、BASICだろうがPerlだろうがVzマクロだろうが、ほとんど
同じようなスタイルのプログラムになっています。この辺はまさに、この本からの
影響でしょう。

文太さん

> 　行くぞ、ハノイ！　３月あたり。「ハノイへ行ってみよう！」とかいう
> タイトルで、少しは勉強してから、再帰いたします。

ハノイの塔の話題が出たので、見てみたら VZマクロと Turbo Basic のサンプルソースにありました。

Turbo Basic のはそのままコンパイルできて、USモードで実行出来ました。
プレート 17枚でも数秒で完了するほど高速で、目に見えないので ウエイトを入れました。
自分好みの改造が整ったら公開しようかな。？

VZマクロは、軟体にある田野村さんのマクロで、プレート12枚まで実行出来ますが、流石に遅いです。
枚数を 14枚まで増やしたり、高速化の改造をして、ある程度形になりました。
秒数の比較

		　オリジナル　　　	　改造
数n	回数i	W80*25	W136*35		W80*25	W136*35

12	4095	89秒	95秒		47秒	52秒
13	8191					112秒
14	16383					240秒

　　　　↑
1枚増えるごとに約２倍の回数というのが面白いですね。

さて、これらのマクロや BASIC（実行ファイルのみ）をアップしたら
文太さんの勉強にかえって邪魔になってしまうかな。(^^;


＃　タイトル変更した。これで安心。(^^;;

　ハノイへようこそ、じゃないな。
　手を動かさず、クチばっかり動かしている文太です。
　目で活字を追うだけの日常は、まだまだ続くのですが。
　あ、体ぜんぶを使って、雪かきはしましたよん。

　さてさて、良書だろうと思います。ちらちら眺めただけですが。

>私も、BASICだろうがPerlだろうがVzマクロだろうが、ほとんど
>同じようなスタイルのプログラムになっています。

　こうなるでしょうね、この抽象度の高さだと。
　えーと、あれだけ詳細に内容を紹介していたので、あ、わたくしに
買えと仰ってる、と誤解したのです。これは、konnoさんが勧められて
いる本でした。
　が、僕も楽しくよめそうですよ。BASICのコードを覚えながら。

　konnoさんが勧められている点とは違いますが（？）、−−ごめん
なさい、長すぎて引用できません　＞konnoさん−−、たとえば、
p.231。まあ、広義に文体と言ってもいいですが、この作者の読者
への姿勢みたいなのは、僕も鼻につきました。僕は、何かを伝える
人が偉そうなのは好きです。僕に何かを教えてくれる人はみな先生で、
「先生はいつも偉い、絶対的にエライ」と思っています。

　が、ここ、しつこい。「自己満足におちいり、自己陶酔にひたる」。
ここでお仕舞でいい。この上の段落も４行ぐらい削除したい。この
段落も残り全部カットしたい。説教がうるさすぎ、という印象ですね。
　具体的に中身のあることを語れ。

　ま、これも一度はまると、このムチが快感、となることもあるので、
こちらの気分次第という面もあろうかと思いますが。

　と、同調して批判的なことを書きましたが、これがなければ、という
気持ちです。ゆっくり３回読む価値はあるな、と思っています。

　本を手に取れる人にしか通じない書き方でごめんなさい。
　konnoさん、僕はちょっと時間がかかりそうですので、熱いうちに、
としきさんに借りてみましょう！

　田野村さんでしたか、そんな記憶がおぼろげにありましたが……。
　あの人、そういう本格的な王道を生きた人でしたね。
　が、僕の手、動かず。

タイトルに合わせてこちらにレスします。

ハノイの塔のマクロ関連情報を得ようとnifty会議室の過去ログを検索しましたら
としきさんの書き込みがありました。

> 18134/19000 PEB03250  としき           再帰マクロ
> (15)   01/03/24 00:49                     コメント数：2
> マクロで再帰を使う実験をしてみました。
> = フィボナッチ数
> 
> では、ついでにもう一つ。
> 昔、再帰が使えない N88-BASIC で使った、配列を擬似的なスタックとして使うと
> いう技をマクロで使ってみました。別にスタック領域が足りない訳でもないのだ
> から、素直な push pop でもいいと思いますが。
> = ハノイの塔

今回はソースは省略しますが、#11066 の としきさんの書き込みを思い出しました。

> プログラム初心者に再帰を説明するのは「ハノイの塔」かフィボナッチ数列か、
> というくらい。再帰を使ったほうがシンプルなものって、実生活ではあまり
> 見かけませんからね。
> また、再帰でできるものは必ずループでもできるらしい。
> なので、再帰からループへコードを変更するための題材にも使われるらしい。

23年前に実際にマクロコードを書いていたのですね。流石です。

> で、ループならどうということもないのですが。
> ８ビットパソコンの時代のBASICでは、再帰というものが使えませんでした。
> なので、そこでわざとループを使わず、いかに擬似的な再帰を実現するか、という
> のも、ちょっと気取ったプログラマたちの力試しの例題に使われていたりして。
> ま、再帰が使えない、という意味ではVzのマクロも同様。

この再帰というのが私はいまいち理解できていなくて。
BASIC で言えば、サブルーチンの中でそのルーチンの先頭に飛んで条件を満たすまで繰り返す。
みたいな感じでいいのかしら。
実際VZマクロでもそういう動作をしているように思いました。

としきさんのコード、わかりやすそうですね。
いつか使わせてもらうかもしれません。

雪は夜更けすぎに、雨へと変わるだろう、サイレ（以下略）

俺は何を歌っているのだ。
いやぁ、２月５日は深夜、２３時ごろになって大雪も峠を越えて、みぞれか雨か、
というものが弱く降ってくるだけになったので、そこから雪かき開始。
だって、６日は日勤で出社しないといけないのだもの。
結局、１時間あまり汗を流して、自宅前の道路の雪は概ね撤去。
撤去した雪のほとんどは、自宅の庭に放り込みました。他に置く場所がないから。
多少は側溝にも押し込みましたけどね。
それから入浴して就寝は２時過ぎ。
だけど、夜通し続いた落雪の音がまるで爆撃のようで、一晩中まんじりとせず。
６日は普通に５時起きして、いつもより５分早く６時前には出社。眠い。
ちなみに、７日も日勤なので５時起き予定。
あぁ、掲示板に書き込んでる余裕なんてない。はず。
７日も眠そうだ。


それはさておき。

> 　さてさて、良書だろうと思います。ちらちら眺めただけですが。

以前にも書きましたが、内容については、王道も王道。
重箱の隅はともかく、全体的には、あまり批判できない。

ところで、この本、雑誌連載をまとめたものです。
不定期連載みたいな形で、１年ぐらいに渡って書かれたものだったかと。
当然、読者からの感想みたいなものが編集部に届くわけですよ。
そんな中に「これはもはや宗教だ」みたいな内容が混じっていたことがあったらしい。
でも、決してそんな事はない。
他のえらい学者さんたちが唱えたことのBASICでの実装例をひたすら紹介しているだけ
の、単なる工学の本です。
ただ、対象とする読者層の設定には苦労したと思う。
だって、中身は大学の学部情報科の初級クラス。
だけど、実際にその雑誌を読んでいる人や読んでほしい人といったら、プログラムを
専門としていないけど業務命令その他でプログラムを作成するハメになった社会人
から小中学生まで、多岐に渡るわけです。そして、それら全ては素人前提。
いわば、英語の先生が、大学英文科で教えるような正当な文法を、小学生から社会人
までをすべて対象とする１冊の教科書を作る、みたいなもので、ある程度の無理が
発生するのは当然かもしれません。そして、そのしわ寄せとか作者へのプレッシャー
といったものが、どこかで発現してもおかしくはないと思います。
だけど、雑誌連載時も否定的な意見は届いたはずだけど、そこそこ少ないはず。
なぜなら、連載継続とか単行本出版という結果に至ったわけだから。
ということは、ある程度の成功と推測してもいいんでしょうね。

としきさん

　雪かきと落雪の爆撃への守り（寝れんぞ）、お疲れ様でした。
　すごいなぁ、その体力。うらやまし。

>他のえらい学者さんたちが唱えたことのBASICでの実装例をひたすら
>紹介しているだけの、単なる工学の本です。

　はい、「構造化は BASIC でも十分できる」という本ですね。
　「えらい学者さんたち」とは、クヌース、カーニハン、リッチー、
ダイクストラ、Ｎ・ヴィルトなんて人たちです。
　プログラミングって何？　と思ったことのある人なら、聞いたこと
のある名前たち。
　王道。
　（僕的には、〔少し嘘かもしれないけど〕榊原さんがsyoさんに
教えていたことの反復、という印象でした。自己評価、高すぎかな？）

　僕としては、ここ３年くらい、楽しく考えてきたこと（Fortran, Pascal,
Ratforなどを題材に）が、きれいに整理されてるな、というのが
『プログラミング・スタイル』についての最初の感想でした。

>いわば、英語の先生が、大学英文科で教えるような正当な文法を、
>小学生から社会人までをすべて対象とする１冊の教科書を作る、
>みたいなもので、

　あまり良い比喩とは言えないかと愚考いたします。そんなの、まず
僕には無理で、嫌だ、そんな仕事、やらないからね、と言うような
問題設定。

　でも、初出雑誌が何だったか思い出せませんが、やっぱり
「プログラミングって何？」という興味と動機のある人たちが読者
だったんじゃないのかな、と想像します。
　「動いた、楽しい！」という経験がある人たち。

　おお、Ｃも出てきた。林先生、この時期にコンピュータの全体像を
把握されていらっしゃったのですね、と思いました。
　この本の初版は、「昭和６０年１２月」＝１９８５年。僕の本は、
２刷（昭和６１年）。僕が、将来まさかＰＣ方面に関心をもつなんて、
夢にも思わなかった時代の本。

　すごい本ですね。自信はありませんが、色あせない本です。

> 　あまり良い比喩とは言えないかと愚考いたします。そんなの、まず
> 僕には無理で、嫌だ、そんな仕事、やらないからね、と言うような
> 問題設定。

確かによい比喩ではないと思う。
でも、ならどう例えればよいかというと、あまり思いつかない。
文太さんは知っていると思うけど、私、あまり例え話が得意ではないので。

ちなみに、初出雑誌は、当時の日本ソフトバンク社の月刊「Oh!PC」。
当時のソフトバンクが出していた、いわゆる機種別誌というヤツですね。
広告によると、当時は他に
月刊「Oh!MZ」
隔月刊「Oh!FM」
季刊「Oh!HC」「Oh!55」
などといった雑誌が出ていたようです。
最初の掲載は1983年10月。本棚から引っ張り出してきました。
懐かしいですね。というか、しまいこまれず本棚にあると言うのがなんとも。
最初の掲載時は、まだその後が続くとは思われておらず、特集扱いでした。
あ〜、読み直しているうちにだんだん思い出してきた。
最初のうちは、それほど文体にも引っ掛かりを覚えなかったんですよ。
単なる、淡々とした文章だ、と言うだけで。
なので、単行本化されたときも大して加筆されていないという評判を聞いたもので、
なら雑誌掲載記事は全て持っているわけだからわざわざ買うには及ばないな、と判断
して、すぐには購入しなかったのですよ。ただ、やはり毎回大きいサイズの雑誌を
引っ張り出すよりは小さくまとまった単行本のほうがいいという判断で、最初に発売
されてから２〜３年ぐらいしてから購入したのでした。
だから、私の持っているのは昭和61年11月の第４刷。
たぶん、62年か63年になってから買ったはず。

上記、1983年10月号の目次をみると、以下のような記事があります。
まず、目次で特集の次に並んでいるのは、海外のCG展示会の記事。
次が「新作ゲーム画面集」。やっぱりみんな、ゲームが好きなんですよ。
ついで「超大型オリジナルプログラム第１部」としてPC-9801用の家計簿プログラム
が「パーソナルバランスシート」なる大仰なタイトルで載っている。
これは連載というより、複数回掲載の初回、という感じ。
そして「４つのBASICへの入門」というサブタイトルのついている講座。おそらく、
NECの各機種用のBASICの差異の解説まで踏み込もうとしているのではないかなぁ。
でも、このときはまだ第３回。
さらに「マシン語超入門講座」や「機械語熟語集」といった連載では８ビットのZ80が
対象。
「ミニフロッピーの活用法」という連載もあるけど、この号は番外編で、拡張メモリ
をフロッピー的に扱うソフトが掲載。ま、RAMディスクですね。しかも、これの対象は
８ビットパソコンであるPC-8001とPC-8801。他の号をみていないけど、この連載が
そもそも８ビットパソコン対象なのかも。
そして、ハードウェア工作の「PC工作入門」は、この号ではPC-9801用の記事だけど、
それまでの記事はみんな８ビットパソコン用だったらしい。
さらに、機種別のページも、取り上げられているのは８ビットマシンだけ。
つまり、業務にもバリバリ使える１６ビットパソコンは、まだまだ黎明期。
この時期のこの雑誌が、ソフトウェア工学の、ある意味で理論的な記事を掲載すると
いうのは、少なくともニーズとしては顕在化していないはず。
というか、ミスマッチもいいところ。
また、商業的な意味では冒険というか、よく掲載に踏み切ったものだと思います。
そして実際、このときか２回目の掲載のときか、連載陣の一人がけんかを吹っかけた
というか婉曲に批判したけど、そもそもけんかにならず、逆にその人の連載が終了
するハメになっていたり。さすがに打ち切りではなく、最終回まで掲載されたけど。

ということで

> 「プログラミングって何？」という興味と動機のある人たちが読者
> だったんじゃないのかな、と想像します。

これはどうなんだろう。
konnoさんならあのころのベーマガとかの雰囲気を覚えているかもしれない。
みんな、いかに自分のアイディアを実装するかしか考えていないような感じ。
なので、その先、というか、どうすれば効率的にバグなく実装できるか、などという
ところまでは思い至っていないんですよ。
特にゲームなんかはある意味で一発勝負のようなところもあったし。

> > 「プログラミングって何？」という興味と動機のある人たちが読者
> > だったんじゃないのかな、と想像します。
> 
> これはどうなんだろう。
> konnoさんならあのころのベーマガとかの雰囲気を覚えているかもしれない。

このころベーマガとか読んでいたかは覚えていませんが、BASICはやってましたね。
当時円弧と直線の交点だったかを求めるのに方程式がわからなくて困ってしまい
ポケコンのBASICで２分法というのを使って、それですました記憶があります。(^^;

> みんな、いかに自分のアイディアを実装するかしか考えていないような感じ。
> なので、その先、というか、どうすれば効率的にバグなく実装できるか、などという
> ところまでは思い至っていないんですよ。

まさにそのとおりで、プログラムを組めば仕事が楽になるという思いで必死でした。

パソピア１６を見つけた時は、「こいつ、動くぞ」とつぶやきながらマニュアルをめくり
「武器はないのか」と見たら、BASIC で動いているのがわかり、自分でテキをやっつける
武器を作り、大危険に突入していったのでした。(^^;

> まさにそのとおりで、プログラムを組めば仕事が楽になるという思いで必死でした。

最近konnoさんが公開されたBASICのコードを見ても、必死さはにじみ出ている感じ。
だけど

> 「武器はないのか」と見たら、BASIC で動いているのがわかり、自分でテキをやっつける
> 武器を作り、大危険に突入していったのでした。(^^;

作った武器が手作りの竹やり同然、かもしれず。
＃この艦では勝てない･･･

先般、見せていただいたPerlのコードなんかも、工夫の跡は見て取れるのですが、
これ以上、どこにどう手を入れてよいかわからない。
いや、高度に完成されて手を入れる余地がない、という意味ではなく。
ちょっと手を入れたらすべて崩壊しそうなジェンガというか砂上の楼閣というか。
ソフトウェア工学の教育を受けていないから仕方ないのですが。
全面的なリファクタリングをしたくなってしまう。
逆にいうと、konnoさん、伸びしろは無限大。
今からでもきちんとソフトウェア工学の基礎を勉強してみるのも一興かと。
 

> 作った武器が手作りの竹やり同然、かもしれず。

ランボーなら竹槍でテキを全部やっつけられるかも。(^^;
私はランボーではないので、乱暴なコードになってしまうのです。

> ちょっと手を入れたらすべて崩壊しそうなジェンガというか砂上の楼閣というか。
> ソフトウェア工学の教育を受けていないから仕方ないのですが。

まったくそのとおりです。
なんせ自分で昨日書いたコードが読めないのですから。(-_-;)

> 今からでもきちんとソフトウェア工学の基礎を勉強してみるのも一興かと。

最近物忘れが地方レベルになってきてるので、難しいですね。(^^;

> 最近物忘れが地方レベルになってきてるので、難しいですね。(^^;

アップル認定の世界最高齢のプログラマは現在８８歳だとか。
そういう人にkonnoさんのせりふを聞かせたら「最近の若い者は〜」とか言いそう。

それはさておき。
konnoさんに勉強してもらってきれいなコードを書いてもらいたい、というのは決して
konnoさんのためではなく。
ざっくりレベルで、今のままのkonnoさんがバグのありそうなコードを３つ書き上げる
のに要する同じ所要時間で、勉強したkonnoさんならバグのなさそうなコードを５つは
書き上げられそう、という見積もりをしたのですよ。
つまり、それだけアウトプットの質・量が向上すると、私を始めみんながうれしい、
ということ。つまるところ、私利私欲なわけですよ。
あるいは、先日BASICのコードを公開されたように、今後はオープンソースの方向に
舵を切っていく、とか。

> アップル認定の世界最高齢のプログラマは現在８８歳だとか。
> そういう人にkonnoさんのせりふを聞かせたら「最近の若い者は〜」とか言いそう。

うう、それを言われたら弱音を吐けないではないですか。(^^;
まあ、何故か今は色々プログラミング欲が出てきて同時に2〜3種のコードを見てたり。(^^;

> ざっくりレベルで、今のままのkonnoさんがバグのありそうなコードを３つ書き上げる
> のに要する同じ所要時間で、勉強したkonnoさんならバグのなさそうなコードを５つは
> 書き上げられそう、という見積もりをしたのですよ。
> つまり、それだけアウトプットの質・量が向上すると、私を始めみんながうれしい、
> ということ。つまるところ、私利私欲なわけですよ。

そ、そんなこと言われたって木に登ったりなんかしないんだからね！ (^^;

> あるいは、先日BASICのコードを公開されたように、今後はオープンソースの方向に
> 舵を切っていく、とか。

私はあくまで個人的な趣味でやっているので、その辺は変わらないかもしれないです。

MS-DOS Player が立て続けに更新されていました。
http://takeda-toshiya.my.coocan.jp/msdos/index.html

---------------------------------------------------------------------

2024/2/19
strcpy_s()で、指定したバッファ長よりも長い文字列をコピー元として指定したときに、
例外0xc0000417が発生することがあるようです。
ひとまずstrncpyで処理をするように対策をいれました。

2024/2/18
cracyc様のforkから、更に修正を取り込ませていただきました。
INT 67h, AX=5B00h/5B01h/5B04hについて、BHに00h以外を指定したときにエラーを返すようにしました。
MDA（Monochrome Display Adopter）をサポートしました。
その代わりに、コンベンショナルメモリの上限がB8000hからB0000hとなり、32KBだけ減少しています。
（それでも、VGAのVRAMがない分だけ、通常の環境より64KB大きいのですが）
CRTC, Status Registerも、MDAのアドレスでアクセス出来るようにしたのと、同期信号を50Hzにしました。

2024/2/15
cracyc様とroytam様のforkから、修正を取り込ませていただきました。
FCBを使ったファイルアクセスと、MAME版i386コアのFPU周りの例外の修正などです。
また、MAME版i386コアのDAA/DAS/AAA/AAS/AAM/AAD命令を、DOSBoxの実装を基に修正しました。
Pentium4版で、testi386.exeが実機と同じ結果が得られるようになっています。

NP21/WのI386コアを、ver0.86 rev92 beta2相当に更新しました。
また、ビルド時のワーニングが出ないように修正しました。

環境変数のアクセス時に、正しくない環境テーブルを参照したときのチェックを強化しました。
最近のビルドでtesti386.exeが動かなくなっていた問題が解決しています。
メモリアクセスの処理を効率化しました。
基本メモリ、拡張メモリ、予約領域（VRAMなど）の順に、少ない条件分岐でアクセスできるようにしています。
微妙に処理速度が上がっているかもしれません。

---------------------------------------------------------------------

主にメモリやCPU関係の修正のようです。
処理速度が上がっていたらうれしいですね。
作者様に感謝します。

TurboBasicで素数を表示、カウントするテストプログラムを作りました。
DOSVAXJ3 や MS-DOS Player の JP モードで動きます。

自己流で考えて作ったので間違いがある可能性はあります。
指定範囲は２０から １０万まです。配列数や時間的な限界がこの辺ということで。
一応、1000 までは 合っていました。

Wikipediaを見ると
--------------------------------------------------------------------------
最も素朴な方法は、2 から √n 以下の素数まで順番に割っていく、試し割り法と呼ばれる方法である。
n が √n 以下の全ての素数で割り切れなければ n は素数である。
試し割り法は、n が大きくなるに従って、急速に速度が低下するため、実用的ではない。
--------------------------------------------------------------------------

私が考えた方法は、どうやらこの方法と同じようですね。
１万を超えると急速に速度が落ちて、１０万くらいが限界のようなので。(^^;


　 SOSU4.EXE Ver.240220

・DOSVAXJ3 の VGAで動く 素数表示テストです。
・DOSVAXJ3 を起動したら、chev jp でVGAモードにして、SOSU4.EXE を起動してください。
・MS-DOS Player では、chej jp でVGAモードにすれば動作します。
・VTDOS では動作しません。
・ソースも付けます。
・1000までは合っていると思いますが、それ以上は保証できないので表示しません。
・1000を超えたら 数字や時間情報を SOSU.DAT に追加出力します。
・数字が大きくなると急速に速度が落ちるので、初めは 100くらいから始めてください。

・更新履歴
2024-02-20 公開用に色々弄りました。
2024-02-17 とりあえず作成？

　動作保証はでき無いので実行は自己責任で。　　

自作、改作アプリの放置部屋に置きました。
http://tamaneko.world.coocan.jp/execom.htm

ハノイの塔マクロ HANOI.DEF を改造しました。
オリジナルは、T.Tanomura さんの名作です。作者様に感謝です。


===== hanoi_k.def ハノイの塔 =====

; ハノイの塔マクロ HANOI.DEF
; （VZ Editor version 1.5/1.6 共通）
; (C) T.Tanomura, 1992/7/5, 1994/7/31
;   h.konno 2024-02-22  円盤の枚数 1〜15 に改造、速度アップ


【機能】
　ハノイの塔の問題を解きます。

【用法】
　編集モードで起動し、円盤の枚数として 1〜15 の数を入力してください。
ハノイの塔の問題を知らない方は、最初は 3 にするといいでしょう。

【補足】
　'Q' を押すと、中止になります。★##k
　'G'（＝go）を押すと、残りの移動を一気に行います。
　マクロの連続実行を中止するには [ESC] を押せば止まります。★##k
　マクロを中断したり実行後おかしくなったらオプション初期化してください。
　改造して速度が倍近く上がっています。（当社比）★

下のリンクをクリックすると hanoi_k.def のソースが表示されます。
当社の新リンク機能です。(^_^)

#txt:hanoi_k.def 

BBSのオートリンク機能を応用して新リンク機能が出来ました。(^_^)
#11098 で使っています。

ソースは、wforum.cgi の最後の方

#--------------#
#  自動リンク  #
#--------------#
sub auto_link {

#	#txt:FILE  text macro doc etc
	$_[0] =~ s/(^|[\x81-\x9F\xE0-\xFC][\x40-\x7E\x80-\xFC]|[^0-9a-zA-Z\/\#\"]+)#txt:([A-Za-z0-9_-]+\.[A-Za-z0-9]+)/$1<a href='http:\/\/tamaneko.world.coocan.jp\/bbs\/count\/count.cgi?mode=download;target=http:\/\/tamaneko.world.coocan.jp\/vz\/$2' title='Text'>#txt:$2<\/a>/g;

このように、サーバーのフォルダに置いたファイル名を指定すれば $2 の変数に置き換えて表示出来ます。
書式は

#txt:ファイル名

この機能を実現することでいくつかのメリットがあります。

・長いソースファイルも５文字のコマンド＋ファイル名の直リンクで手軽に見ることができる。
・長いソースを張り付けて掲示板の閲覧性を損ねることを防げる。
・長いソースを張り付けてコピペするよりこのリンクを右クリックで即ファイル保存のほうが楽かも。
・長いソースやドキュメント類を見たくない人にも優しい。
・リンク済みのファイルは誰でも記事中に直リンクして手軽に参照できるので便利。
・手持ちのソースやドキュメント類を記事中で参照希望のメール送付等は前向きに検討します。
・オートリンクにカウンタを仕込んであるので閲覧数を確認できる。

この機能を思いついた動機は、上に書いていますが、本当は個人的趣味で不純なので内緒。(^^;

この機能が便利だと思ったらぜひとも他の掲示板でも採用願いたいです。(^^;

> ハノイの塔マクロ HANOI.DEF を改造しました。
> オリジナルは、T.Tanomura さんの名作です。作者様に感謝です。

実行してみました。gコマンドの速度は速いですね。
ただ、画面の表示が正しくないです。何が悪いのかな。
konnoさんのところではきちんと表示されているのでしょうから、私の環境かな。
Tanomuraさんのマクロは、正しく表示されています。

で、まぁ、マクロコードを読もうとしたのですが。
あきらめました。
なぜって、コードとコメントの混在で。
一応、読もうと努力はしたんですよ。
だけど、例えばコードの最初のほう、属性などのいくつかの変数をプッシュする
コードがコメントアウトされていて、でもその理由が明記されているわけでもなし、
明記せずとも暗黙で理解できるようなコードでもなし。
まぁ、コード本体というか内部ではこれらの属性が変更されていないからプッシュ
されていないのだろうな、とは想像できますが、ならばなぜ、わざわざ記載した
上でコメントアウトされているのか、全くの謎。
おそらく、konnoさん的にはこういうコードが理解しやすいのでしょう。
でも、申し訳ない、私は脱落しました。
もっとも、世の中には、いわゆる「汚いコード」というのがいくらでもあって、
そういうのに比べればkonnoさんのコードは、まだまし、といったところでしょう。

実行してみたところ，数回の移動でコマンドラインに降り，最終的に VZ が落ちました。
（「落ちた」は正確ではなく，VZの子プロセスから離脱……かな。戻れず強制終了。）

まず，最初にきれいに積み上がっていないです。

次のコードがあります……
 #E #m #[ &k
……が，実行中にコマンドラインに降りるのは何故なのですか？
ここの意図についてコメントがないので，想像もつきませんが……

> なぜって、コードとコメントの混在で。

（外野の言い訳になってしまうけれど）他の方のプログラムを改造する場合，
わたしも元の行をコメントアウトした上で，改造コードを記載してしまいます。
「ここをこうしたよ」ということを明示しているつもりなんですよね。
そういうのは，プログラミングに慣れた人には嫌われるのでしょうか。

田野村さんはタブを使わず4字下げだったので，それをそのまま行にコメントすると，
字下げが4の倍数にならずにグチャグチャした印象を与えてしまいますね。

> 属性などのいくつかの変数をプッシュするコードがコメントアウトされていて、
> でもその理由が明記されているわけでもなし、

グローバル変数のプッシュ／ポップの辻褄を合わせる努力をするよりも，
ローカル変数にしてしまえば他に影響はないという考え方なのでしょう。

ただ，はっきり言ってしまうと，典型的な「スパゲティ」になっているコードを
改善する気がない表明とも受け取られかねないわけで，見た目の印象以上に
コードを追う気力を失わせることはままあることかもしれないと思います。(自省)

上記は，自分への反省とか注意喚起という意味あいの方が強いかもしれません。

それより，わたしがちょっと引いたのは，
「マクロを中断したり実行後おかしくなったらオプション初期化してください。」
かな。

中断が予想される場合は，その処理を入れておくのがふつうかなと思います。
（まぁ，&k で拾う場合は終了処理が無理なことも多いんですけどね。）

> 実行してみました。gコマンドの速度は速いですね。
> ただ、画面の表示が正しくないです。何が悪いのかな。
> konnoさんのところではきちんと表示されているのでしょうから、私の環境かな。

試していただきありがとうございます。
画面表示は具体的にはどんな感じになるのでしょうか。

> Tanomuraさんのマクロは、正しく表示されています。

Tanomuraさんのマクロの回数の数字だけ増やしても80*25画面で平気で動作しますね。
環境に左右されないようしっかり作られているのは流石です。

> で、まぁ、マクロコードを読もうとしたのですが。
> あきらめました。
> なぜって、コードとコメントの混在で。

す、すみません、公開するなら修正前の不要なコメントは消すべきでしたね。
修正して差し替えます。m(__)m

> 実行してみたところ，数回の移動でコマンドラインに降り，最終的に VZ が落ちました。
> （「落ちた」は正確ではなく，VZの子プロセスから離脱……かな。戻れず強制終了。）

げげ、これはヤバいですね、オプション絡みでしょうか。
スタートして直ぐと終了時に時間計測のためにコマンドラインに降りていますが
移動中は関係ないし、もしかして EP かなぁ。
時間計測部分はコメントにします。

> まず，最初にきれいに積み上がっていないです。
オリジナルで問題無いなら何かのオプションの影響ではないかと思いますが・・・

>  #E #m #[ &k
> ……が，実行中にコマンドラインに降りるのは何故なのですか？
> ここの意図についてコメントがないので，想像もつきませんが……

上に書いたように時間計測のために追加したのをそのままにしていました。
プロンプトを $t$p$g にして時間表示させ、マクロの実行時間を測定しています。
これが悪さをしている可能性があるのでこの部分はコメントにします。
不完全なままアップしてすみませんでした。m(__)m

めざらさんのところでも同じようですが、うちも最初が正しく積みあがっていません。

> わたしも元の行をコメントアウトした上で，改造コードを記載してしまいます。
> 「ここをこうしたよ」ということを明示しているつもりなんですよね。
> そういうのは，プログラミングに慣れた人には嫌われるのでしょうか。

コメントアウトされているのが全て改造前、ということがわかれば私はOKです。
それでも見づらいことは見づらいので、プログラミングに慣れた多くの人は嫌う
かもしれない。
概ね、プログラミングの世界では、例えばバグの混入を避けるなどの目的で、可読性
というものが重視されます。これもある種の理想論なんで、現実にはメモリ量とか
速度とかを目的として最適化というものも行われますが、でも最適化は最後の段階。
実際、遅いのはアルゴリズムが悪いことが多いので、アルゴリズムの見直しを行い、
それでも所要の性能が出ない場合に最適化する、というのが通常の段取り。

そういう潮流なので、コードが読みやすいことが尊ばれるのですよ。
ある種、読みやすさは正義、みたいな。
そして、読みやすくするためにはどうするか、という様々な研究もあって。
その中に、余分な情報は少なければ少ないほうが良い、というのもあります。
余分な情報は正しい認識を阻害する、ということから、私は迷彩という表現を使って
います。そして、このコードは何をする、というコメントなら多くの場合問題はない
のですが、旧のコードと新のコードが並列されていて、単にコメントアウトされて
いるだけ、という場合、混乱を招きやすいのではないかなぁ。
だって、行の途中を読んでいて、その行がコメントであるか確認するために行の先頭
に視線を戻して、という手間が発生するので、少なくとも私には心理的負担。

あるいは、例えばウィルスなんかだと「コードの難読化」なんていう技術が使われて
いたりします。つまり、わざと読みづらくすることにより、どういう挙動を示すか
わからないようにしているのですが、だから一部の口の悪いプロのプログラマーは
「そんなウィルスのようなコードを書くな」
などと後輩に指導して、もはやこの表現はパワハラ案件だという冗談もあるくらい。

> > 属性などのいくつかの変数をプッシュするコードがコメントアウトされていて、
> > でもその理由が明記されているわけでもなし、
> グローバル変数のプッシュ／ポップの辻褄を合わせる努力をするよりも，
> ローカル変数にしてしまえば他に影響はないという考え方なのでしょう。

すごい、きちんと読まれたのですね。
もう私、プッシュポップをしていないということは、これらは内部では使われて
いないんだ、というところでそれ以上読むことをあきらめていました。

> それより，わたしがちょっと引いたのは，
> 「マクロを中断したり実行後おかしくなったらオプション初期化してください。」
> かな。

私は逆というか、この表現を見た瞬間、画期的だと思いました。
積極的にオプションを初期化するって発想がなかったもので。
でも、過去の多くのコードを見てきためざらさんがそういう反応をするということ
は、これはいわゆるマクロ師的には邪道なのかもしれませんね。

まず、うちの環境では、めざらさんのところと違い、落ちたことは一度もありません。

> 画面表示は具体的にはどんな感じになるのでしょうか。

円盤が３枚のときの初期画面。（右側省略）

■
             ■■
■■■
 ~~~~~~~~~~~~~~~~~~~

円盤が３枚のときのgコマンドでの終了画面。（右端まで）

■  ■
                                                             ■■
■■■■■■      ■■■
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

円盤の表示位置が正しくないようですが、空白での上書き消去は正しく行えているので
ゴミが残っている、というようにも見えます。

> （外野の言い訳になってしまうけれど）他の方のプログラムを改造する場合，
> わたしも元の行をコメントアウトした上で，改造コードを記載してしまいます。
> 「ここをこうしたよ」ということを明示しているつもりなんですよね。

そのとおりなんですが、私の場合統一性が無く文字通りぐちゃぐちゃになってました。
流石にこのままアップしたのは不味かったですね。m(__)m

> 田野村さんはタブを使わず4字下げだったので，それをそのまま行にコメントすると，
> 字下げが4の倍数にならずにグチャグチャした印象を与えてしまいますね。

これは公開を考えたら統一するべきでしたね、修正します。m(__)m

> > 属性などのいくつかの変数をプッシュするコードがコメントアウトされていて、
> > でもその理由が明記されているわけでもなし、

修正前のコードをコメントして残すなら理由を明記するべきでしたね。

> グローバル変数のプッシュ／ポップの辻褄を合わせる努力をするよりも，
> ローカル変数にしてしまえば他に影響はないという考え方なのでしょう。

そのとおりですが、実際には不具合が出たようで、難しいですね。

> ただ，はっきり言ってしまうと，典型的な「スパゲティ」になっているコードを
> 改善する気がない表明とも受け取られかねないわけで，見た目の印象以上に
> コードを追う気力を失わせることはままあることかもしれないと思います。(自省)

m(__)m  m(__)m  m(__)m

> それより，わたしがちょっと引いたのは，
> 「マクロを中断したり実行後おかしくなったらオプション初期化してください。」
> かな。
> 中断が予想される場合は，その処理を入れておくのがふつうかなと思います。

中断とは、マクロを Ctrl Break などで強制的に止めるという意味だったのですが
このマクロは止まらないみたいですね。
なので、中止のコードを追加したのですが、そうするとプッシュポップの辻褄が合わなくなります。
変なところにポップしてメモリを壊すよりは変数保存のプッシュポップをやめるのがいいかと。
プッシュポップの辻褄が合わなくてもマクロを終了したら SP は初期化するかな。
と思ったのです。

不要なコメントを整理してコードも見直しますのでしばしお待ちください。m(__)m

> > 画面表示は具体的にはどんな感じになるのでしょうか。
> 
> 円盤の表示位置が正しくないようですが、空白での上書き消去は正しく行えているので
> ゴミが残っている、というようにも見えます。

げげ、これはひどいバグですね。すみませんでした。m(__)m
80*25の画面でスペースがはみ出てしまってますね。
途中で数値変更して確認していませんでした。お恥ずかしい。m(__)m

諸々修正して再アップします。しばしお待ちください。m(__)m

ハノイの塔マクロ HANOI.DEF 改造の差し替え版です。
オリジナルは、T.Tanomura さんの名作です。作者様に感謝です。

バグバグの物を上げてしまいすみませんでした。m(__)m
コメントも整理しました。
これでめざらさんのところで問題なく動きますように。(-人-)


下のリンクをクリックすると hanoi_k.def 差替え版のソースが表示されます。

#txt:hanoi_k.def 

ふつうに実行できました。

結局，何が問題だったのか分からないままでしたが……

> ふつうに実行できました。
> 結局，何が問題だったのか分からないままでしたが……

問題なさそうで、ホッとしました。(^^;
コマンドラインに降りたのがまずかったと思い、EP0 にしたくらいですが
多分違いますよね。(^^;
ともあれ良かったです。(^_^)

いや、ほとんどT/Oで申し訳ない。
酔ってるもんで。

> いや、ほとんどT/Oで申し訳ない。
> 酔ってるもんで。

あ、全然気が付きませんでした。(^^;

おめでとうございます。（って、自分に言うか）

> ハノイの塔マクロ HANOI.DEF 改造の差し替え版です。

やっと試すことができました。
きれいに動いています。
ただ、うちでは、マシンのせいなのか、konnoさんのところほどTanomura版との差は
大きくなっていません。１２枚で、Tanomura版だと４５秒強、konno版だと３５秒弱、
といったところです。
なお、実行したのはVTDOS、画面サイズは横８０桁、縦５０行です。
でも、konnoさんのところでは、画面サイズで実行速度が変わる、というのは面白い
ですね。速度が画面サイズに依存しないようにする、という改造もいいかも。

> TurboBasicで素数を表示、カウントするテストプログラムを作りました。

中身を見させていただきました。
どうも解せない部分がいくつか。
冒頭、「DEFINT A-Z」と宣言されています。
これはいわば、ある意味お約束のようなものかもしれません。
でも、実際にコードの中で使っている変数は、整数の範囲外までサポートするため
実数型。だもので、いちいち実数指定の「!」が必要になっています。
これ、冒頭の整数宣言を外してしまったほうがよくありませんか？
コード全体をざっくり見た範囲で、整数型の変数は末尾の時間計測ルーチンで使って
いる変数ぐらい。なら、こちらのほうに整数指定をするほうがいいような。

で、尻尾から見ていって。
9050行、もしIERLが10000より大きければ、THENそのとき10000となっていますが、
THEN直後の数値はその行番号へのジャンプ。でも10000行ってないのですが、これで
いいのですか？
って、これ、コメント文になっているぅ〜！
またぞろ、konnoさんお得意の迷彩にやられちまったぜ。

9030行、「RESUME 9032」となっていますが、RESUME文て指定した行番号に処理を
飛ばす、という挙動だったはず。この処理系ではその他の副作用があるかもしれない
のですが、このステートメント、本当に必要ですか？
あ、ERRとERLがクリアされてしまうとかあるのかな。
であってもなくても、わざわざIERRとIERLに代入せず、そのまま表示してしまえば
余分な変数も使わずに済むし、コードはよりシンプルになる気がする。
ま、私のような処理系の挙動を把握していない人向けのコメントは不要として、
処理系の挙動を知っている人ですら疑問を抱きそうな部分にはきちんとコメントを
つけたほうが言いと思う。

と、言うところで、根性と時間がつきました。
今日のところはそんなところで。

> やっと試すことができました。
> きれいに動いています。

無事に動いたようでなによりです。(^_^)

> ただ、うちでは、マシンのせいなのか、konnoさんのところほどTanomura版との差は
> 大きくなっていません。１２枚で、Tanomura版だと４５秒強、konno版だと３５秒弱、
> といったところです。
> なお、実行したのはVTDOS、画面サイズは横８０桁、縦５０行です。

うーむ、差が少ないのは気になるところですね。私の各種環境で比較してみました。

VTDOS　　　　　　　org　 69秒
VTDOS　　　　　　　kon　 33秒
CKWV+VTDOS　　　　 org　 63秒　　80*25
CKWV+VTDOS　　　　 org　 69秒　　136*34
CKWV+VTDOS　　　　 kon　 33秒　　80*25
CKWV+VTDOS　　　　 kon　 36秒　　136*34
DOSVAXJ3 64　　　　org　 70秒
DOSVAXJ3 64　　　　kon　 34秒
M Player pen4_x64　org　171秒
M Player pen4_x64　kon　 71秒

ckwv のが時間が掛かると思いましたがそうでもないですね。

> でも、konnoさんのところでは、画面サイズで実行速度が変わる、というのは面白い
> ですね。速度が画面サイズに依存しないようにする、という改造もいいかも。

移動のたびに &d で全画面表示しているので大画面の方が不利かと思いましたが
オリジナルでも大画面の方が遅いですね。
MS-DOS Player は画面表示が遅いのかな、また検証してみます。

> 冒頭、「DEFINT A-Z」と宣言されています。
> これはいわば、ある意味お約束のようなものかもしれません。
> でも、実際にコードの中で使っている変数は、整数の範囲外までサポートするため
> 実数型。だもので、いちいち実数指定の「!」が必要になっています。
> これ、冒頭の整数宣言を外してしまったほうがよくありませんか？
> コード全体をざっくり見た範囲で、整数型の変数は末尾の時間計測ルーチンで使って
> いる変数ぐらい。なら、こちらのほうに整数指定をするほうがいいような。

全くその通りです、手抜きのために既存のルーチンを stime などから寄せ集めたもので。
冒頭の「DEFINT A-Z」も、
 ON ERROR GOTO 9000:DEFINT A-Z
このように、エラールーチンにくっ付いていたのをそのままにしていたのでした。

> 9050行、もしIERLが10000より大きければ、THENそのとき10000となっていますが、
> THEN直後の数値はその行番号へのジャンプ。でも10000行ってないのですが、これで
> いいのですか？
> って、これ、コメント文になっているぅ〜！
> またぞろ、konnoさんお得意の迷彩にやられちまったぜ。

これも同じで、エラー処理が無いといきなり終了するので、とりあえず張り付けたのでした。
としきさんは、TAGLIGHT.EXE はお使いではないですか。
コメントなどが色分けされて非常に見やすくなります。って言い訳。

> 9030行、「RESUME 9032」となっていますが、RESUME文て指定した行番号に処理を
> 飛ばす、という挙動だったはず。この処理系ではその他の副作用があるかもしれない
> のですが、このステートメント、本当に必要ですか？
> あ、ERRとERLがクリアされてしまうとかあるのかな。
> であってもなくても、わざわざIERRとIERLに代入せず、そのまま表示してしまえば
> 余分な変数も使わずに済むし、コードはよりシンプルになる気がする。
> ま、私のような処理系の挙動を把握していない人向けのコメントは不要として、
> 処理系の挙動を知っている人ですら疑問を抱きそうな部分にはきちんとコメントを
> つけたほうが言いと思う。

これも同じ手抜きで、以下同文。m(__)m

MS-DOS Player の更新でメモリ関連が速くなったかもしれないので、
素数計算 SOSU4 で、各CPUのエミュレーション速度を計測してみました。


23-12-14版                      24-02-19版
PC1  MS-DOS Player 231214       PC1  MS-DOS Player 240219   
                                                            
ia32_x64                        ia32_x64                    
Number = 10000      0: 0' 3     Number = 10000     0: 0' 2  
Number = 20000      0: 0' 9     Number = 20000     0: 0' 6  
                                                            
                                pentium4_x64                
  無し                          Number = 10000     0: 0' 5  
                                Number = 20000     0: 0'14  
                                                            
i486_x64                        i486_x64                    
Number = 10000      0: 0' 4     Number = 10000     0: 0' 2  
Number = 20000      0: 0'14     Number = 20000     0: 0'14  
                                                            
i386_x64                        i386_x64                    
Number = 10000      0: 1'40     Number = 10000     0: 1'39  
Number = 20000      0: 5'31     Number = 20000     0: 5'27  
                                                            
i286_x64                        i286_x64                    
Number = 10000      0: 0'45     Number = 10000     0: 0'50  
Number = 20000      0: 2'29     Number = 20000     0: 2'42  
                                                            
v30_x64                         v30_x64                     
Number = 10000      0: 0'43     Number = 10000      0: 0'45 
Number = 20000      0: 2'21     Number = 20000      0: 2'30 
                                                            
ia32_x86                        ia32_x86                    
Number = 10000      0: 0' 3     Number = 10000      0: 0' 3 
Number = 20000      0: 0' 9     Number = 20000      0: 0' 9 
                                                            
                                pentium4_x86                
  無し                          Number = 10000      0: 0' 6 
                                Number = 20000      0: 0'20 
                                                            
i486_x86                        i486_x86                    
Number = 10000      0: 0' 6     Number = 10000      0: 0' 6 
Number = 20000      0: 0'18     Number = 20000      0: 0'18 
                                                            
i386_x86                        i386_x86                    
Number = 10000      0: 2' 4     Number = 10000      0: 2'13 
Number = 20000      0: 6'51     Number = 20000      0: 7'22 
                                                            
i286_x86                        i286_x86                    
Number = 10000      0: 0'47     Number = 10000      0: 0'56 
Number = 20000      0: 2'33     Number = 20000      0: 3' 6 
                                                            
v30_x86                         v30_x86                     
Number = 10000      0: 0'36     Number = 10000      0: 0'45 
Number = 20000      0: 2' 2     Number = 20000      0: 2'28 
                                

こうしてみると、新しい版が少し速くなっているようですね。
でも i286 以下では逆に旧版より遅くなっているような。
計算式のアルゴリズムとの相性もあるかもです。
私が間違えてる可能性もあります。

i386 以下は CPU エミュレーション率が高いのか、遅くなっていますが
特に i386 が突出して遅いのが気になります。

CPUエミュレーションのルーチンはいくつか種類があると思いますが、
速さより正確さを優先した結果ということでしょうか。
うーん、この結果を武田さんに送ってみようかなぁ。

新しい版の ia32_x64 がメモリ速度では良さそうですね。
みなさん、CPUを選ぶときはこの表も参考にしてね。

私のようなずぼらと違って、konnoさんはまめな人なのか。
私の場合、何回も登場する実数型変数にいちいち型指定の接尾辞をつけるくらいで
あれば、何とかしてそれを省略できる方法を考えたりするわけですよ。打鍵数の節約
を含めて。そして、DEFINTの型指定範囲をどうにかできないか、というのが最初の
候補になる。
あるいは、konnoさんは昔の遅いインタプリタ時代のBASICに苦しめられた経験が
少ない、とか。
少しでも速度を稼ごうと思ったら、ループの中で多用される変数を整数型にする、
というのは基本として、もし実数型不可避となったら、短い変数名にしたり、とか、
いちいち型指定の接尾辞をつけずに済ませようとしたり、とか考えるわけです。
今回のコンパイラでは大丈夫、と読みきってそうしているのであれば、私の言って
いることは余計なお世話なので、大変申し訳ない。

手抜きというか楽をするために既存のルーチンをかき集める、というのは私もよく
やるし正しい行いだとは思いますが、でも、寄せ集めのそれらのルーチンがそれぞれ
何をやっているか把握しないでただくっつけるだけだと、しつこく取れないバグの
巣窟になることが多い。それはあとからボディブローのように効いてきて、トータル
では全く楽にならない、むしろ複雑になる、というのが非常によくある結末。
やっぱりkonnoさん、深層心理では楽をすることを嫌っているとしか思えない。
私のように、骨の髄まで楽をする事を考える人間とは大違い。
あるいは、バグが取れたという結果よりもバグ取りという過程のほうが好き、とか。
世間一般の多くのプログラマは、コーディングが楽しいとか完成してきちんと動いた
ときに満足感を感じる、という人のほうが多いらしいし、私もそうなのですが、何が
楽しいかなんていうのは当然ながら人それぞれ。
いつまでたっても動かないプログラムを永遠にデバッグしているのが楽しい、という
人がいたっておかしくないし、実際にkonnoさんのコードを見ると、konnoさんは
そういうタイプに見える。
プログラムが簡単に完成したらつまらないんでしょう。

TAGLIGHTは、HTMLの編集が楽になりそうなんで気にはなっているんですけどね。
色物はあんまり好きではないんですが、導入したほうがいいかなぁ。
でも、最終的なプログラムコードは、そういうものに依存するべきではないと思う。
ま、これは私の個人的な意見なんで、異論は認める。
私、昔はBASICだったし、あるいはポケ３でコードを組んでいたこともあって、白黒
がデフォルト。紙とペンでコーディングするときも、せいぜい赤ペン止まり。
プロのプログラマだと、紙とペンでコーディングする場合でも多色のマーカーを
使っていた、なんていう話は聞いたことがあります。
だから、以下のような替え歌ができたんだ、そうです。

　胸につけてるマーカーで修正
　自慢のデバッガでバグを撃つ
　派遣の会社から僕らのために
　来たぞ我らのプログラマー

２０年とか３０年前に聞いた歌詞なんで、もはやうろ覚え。
元歌に沿って、替え歌のほうも３番とか４番まであったはず。
上記の１番も、１行目はたぶん間違いないと思うけど、２行目以降はかなり妖しい。
だからなんだ、という話ですが。

TurboBasicで素数を表示、カウントするプログラム SOSU5 に更新しました。
DOSVAXJ3 や MS-DOS Player の JP モードで動きます。

自己流で考えて作ったので間違いがある可能性はあります。
指定範囲は２０から ３０万まです。配列数や時間的な限界がこの辺ということで。
一応、300000 までは 合っていると思います。

今回指定数を3倍までにし、速度アップもしました。
起動時オプションで動作変更できます。


SOSU5.ZIP　サイズ 30297bytes　 24-02-27 new!

　 SOSU5.EXE Ver.240227

・DOSVAXJ3 の VGAで動く 素数表示テストです。
・DOSVAXJ3 を起動したら、chev jp でVGAモードにして、SOSU4.EXE を起動してください。
・MS-DOS Player では、chej jp でVGAモードにすれば動作します。
・VTDOS では動作しません。
・ソースも付けます。
・300000までは合っていると思いますが時間が掛かりすぎるので注意。
・数字や時間情報を SOSU.DAT に追加出力します。
・起動時オプション 1 で S000.DAT に素数を出力します。
・起動時オプション 2 で 表示もファイル出力もしません。カウントのみ。
・数字が大きくなると急速に速度が落ちるので、初めは 100くらいから始めてください。

・更新履歴
2024-02-27　V5　バグ取りや速度アップやファイル出力など。
2024-02-20　V4　公開用に色々弄りました。
2024-02-17　V1　とりあえず作成？

　動作保証はでき無いので実行は自己責任で。　　

http://tamaneko.world.coocan.jp/execom.htm

> 私のようなずぼらと違って、konnoさんはまめな人なのか。

逆に私はずぼらで、としきさんはマメな人だと思っていました。

> 私の場合、何回も登場する実数型変数にいちいち型指定の接尾辞をつけるくらいで
> あれば、何とかしてそれを省略できる方法を考えたりするわけですよ。打鍵数の節約
> を含めて。そして、DEFINTの型指定範囲をどうにかできないか、というのが最初の
> 候補になる。

昔は私もそういうことを考えていた気がします。今は劣化して考えられなくなっただけかも。

> あるいは、konnoさんは昔の遅いインタプリタ時代のBASICに苦しめられた経験が
> 少ない、とか。

としきさんには私はそう見えるわけですね。
私は私なりに遅いインタプリタでいかに処理速度を上げるかで必死だったんですけどね。
そのために「スーパーBASIC」という本を買って、色々参考にした覚えがあります。

> 少しでも速度を稼ごうと思ったら、ループの中で多用される変数を整数型にする、
> というのは基本として、もし実数型不可避となったら、短い変数名にしたり、とか、
> いちいち型指定の接尾辞をつけずに済ませようとしたり、とか考えるわけです。

昔はそういう考えが基本的にあったと思います。今は何も考えていないですね。(^^;

> 今回のコンパイラでは大丈夫、と読みきってそうしているのであれば、私の言って
> いることは余計なお世話なので、大変申し訳ない。

コンパイラになって、変数名の長さとか関係なくなってあまり気にしなくなったのはあります。

> 何をやっているか把握しないでただくっつけるだけだと、しつこく取れないバグの
> 巣窟になることが多い。それはあとからボディブローのように効いてきて、トータル
> では全く楽にならない、むしろ複雑になる、というのが非常によくある結末。

確かにその通りですが、私はとりあえず動くのを優先に考えてしまう癖があるようです。

> やっぱりkonnoさん、深層心理では楽をすることを嫌っているとしか思えない。

これは無いと思いますが、そう見えるのですか。

> 私のように、骨の髄まで楽をする事を考える人間とは大違い。

私にはそうは見えなかったり、考え方が人それぞれなゆえですかね。

> あるいは、バグが取れたという結果よりもバグ取りという過程のほうが好き、とか。

私はバグが無い方がいいし、バグ取りは基本嫌です。

> いつまでたっても動かないプログラムを永遠にデバッグしているのが楽しい、という
> 人がいたっておかしくないし、実際にkonnoさんのコードを見ると、konnoさんは
> そういうタイプに見える。

見え方は人それぞれですから、しかたがないですね。

> プログラムが簡単に完成したらつまらないんでしょう。

そういう境地になれたらいいなとは思います。絶対になれないので。

> TAGLIGHTは、HTMLの編集が楽になりそうなんで気にはなっているんですけどね。
> 色物はあんまり好きではないんですが、導入したほうがいいかなぁ。

Windowsの高機能エデイタは大抵色分け機能を持っていますね。
そういうのを使ってみたいとは思うのですが、VZの使い勝手は別格と思うので。

> だから、以下のような替え歌ができたんだ、そうです。

替え歌がさくっと出来るのもクリエイターならではですね。(^_^)

コードからにじみ出てくる人柄なんて当てにならない、というのが結論でしょうか。

> 逆に私はずぼらで、としきさんはマメな人だと思っていました。

この辺は相対的なものもありますがね。
親戚一同から学生時代の友人、会社での知り合いにいたるまで、他人からの評価
では、世間一般の平均からすると私はずぼらの範疇に入るらしい。マスコミなんか
の報道やネットニュースを参照することによる自己評価でも、やっぱり私はずぼら
だと思っています。
うちの父はマメな人でしたが、うちの母は
「うちの子供たちはみんな私の血を継いだ」
なんていっていて、自分でもそのとおりだと思っています。

> 昔は私もそういうことを考えていた気がします。今は劣化して考えられなくなっただけかも。

> 昔はそういう考えが基本的にあったと思います。今は何も考えていないですね。(^^;

もしかしたら、この辺がキモなのかも。
私も、最近になってプログラミングのスタイルが変わったというところはありません
けどね。かつては、特にインデントの桁数で、いろいろと変遷があったはず。
昔、N88-BASICでは、タブ幅が８桁固定で、さすがにこれは下げすぎだと思い、面倒
だったけど、空白３桁のインデントで、一生懸命スペースバーを叩いていた。
学生時代、PascalはTurboPascalと大学の大型機を使ったけど、両方でソースを統一
したくて、確かインデントは６桁。
その後、TurboCとVisualCの統合環境では、何桁だったかなぁ。
とくに、VisualCに触れたことって、ほとんど一瞬のようなものだったし。
両方とも、確か４桁だったと思うけど、全く自信なし。
その後すぐにVzに触れて、拡張子ごとにタブを４桁と８桁に設定できるようになって、
今ではこれなしにはいられない。

> 確かにその通りですが、私はとりあえず動くのを優先に考えてしまう癖があるようです。

あ〜、なんとなくわかるような。
なんと言えばいいかな。
私の場合は「長期的ずぼら」とか「ライフサイクルずぼら」。
konnoさんの場合は「近視眼的ずぼら」。
なので、konnoさん、トータルでの労力がかえって増えてしまうと思う。

SOSU5 の速度アップとバグ取りですが、他の素数計算プログラムを参考にしました。
旧版は、一桁の素数を決め打ちでやっていました。

for i!=2 to 10
  if i!=2 then gosub print1:co!=co!+1:co1%(co!)=i!
  if i!=3 then gosub print1:co!=co!+1:co1%(co!)=i!
  if i!=5 then gosub print1:co!=co!+1:co1%(co!)=i!
  if i!=7 then gosub print1:co!=co!+1:co1%(co!)=i!
next i!

これを全部コメントにして、２だけ決め打ちにしました。
さらに、偶数チェックを FOR STEP 2 で出来ることがわかり、以下のように

i!=2:gosub print1 :co!=co!+1:co1%(co!)=i!		'★ 2は素数に決め打ち
a!=0
for i!=3 to no!-1 step 2				'★ 偶数をスキップ
loop1:
'  no1$=str$(i!)					'★ FOR steo 2 の
'  le=len(no1$)						'★スキップにより
'  a!=val(right$(no1$,1))				'★この4行が
'  b!=int (a!/2):if b!=a!/2 then i!=i!+1:goto loop1	'★要らなくなった
  gosub loop2		'
next i!

これで少し速度アップ出来たようです。

SOSU4.EXE
Number = 50000 	  0: 0'34 	Prime Number = 5133 
SOSU5.EXE
Number.50000	  0: 0'32 	Prime Number = 5133 

うーん、誤差範囲かな。(^^;
あとは配列の見直しで、10万までだったのを30万まで拡大出来ました。
速度的にも

Number.300000	  0:12'20   Prime Number = 25997 

12分もかかるので、この方式はこの辺が限界ですね。(^^;
さて、次はもっと速い別のアルゴリズムにしましょう。

MS-DOS Player がまた更新されていました。
http://takeda-toshiya.my.coocan.jp/msdos/index.html

---------------------------------------------------------------------

2024/2/28
INT 21h, AX=4404h/4405h/440Ahを修正しました。
BXでハンドルを指定するか、BLでドライブを指定するか、間違えて処理していました。
AX=440Ahはハンドル指定、AX=4404h/4405hはドライブ指定に修正しています。

内蔵デバッガを改良しました。
プロテクトモード時のコードページの処理を修正しました。
また実行トレースに、各命令を16bit/32bitのどちらで実行したか記録するようにしました。
（V30の場合は8080モードか否かを記録）
Uコマンド、UTコマンドで正しく命令を表示できるようになっているかと思います。

roytam様のforkを参考に、conhost-v2のクラッシュ対策を入れました。
カーソルが最後の行にあるときにウィンドウサイズを変更するとクラッシュし易いようです。
また未確認ですが、Windows NT4.0 / 2000で動作するための修正も取り込んでいます。

---------------------------------------------------------------------

VZにはあまり影響無さそうですが、更新が続いていることに感謝します。

MS-DOS Player の更新で CPU速度の変化が気になったので、
素数計算 SOSU4 で 各CPUのエミュレーション速度計測しました。

23-12-14版                      24-02-19版  24-02-28版
MS-DOS Player 231214            240219      240228
                                         
ia32_x64                        ia32_x64    ia32_x64 
Number = 10000      0: 0' 3     0: 0' 2     0: 0' 3  
Number = 20000      0: 0' 9     0: 0' 6     0: 0'10  
                                         
i486_x64                        i486_x64    i486_x64 
Number = 10000      0: 0' 4     0: 0' 2     0: 0' 5  
Number = 20000      0: 0'14     0: 0'14     0: 0'18  
                                         
i386_x64                        i386_x64    i386_x64 
Number = 10000      0: 1'40     0: 1'39     0: 1'56  
Number = 20000      0: 5'31     0: 5'27  
                                         
i286_x64                        i286_x64    i286_x64 
Number = 10000      0: 0'45     0: 0'50     0: 1' 4  
Number = 20000      0: 2'29     0: 2'42  

最新版の速度計測は手抜きですが、少し遅くなったような気がします。
条件判定などが増えたからでしょうか。

sosu5.bas を読ませてもらっています。
まだ冒頭のほうだけなんですけどね。

で、質問。
配列の確保で
dim co1%(32700)
と宣言されています。
その少しあとで入力プロンプトだと思いますが
  PRINT "Prime Number (20 TO 327000)";
とあったり
    if no!>327000 then inp1
となっているのですが、これはそれぞれ値は正しいのですか？
いや、似たような数値なので、ミスタイプを疑ってみました。
というか、できればこういうのは変数に定義したほうがよろしいかと。
例えば、

max=32700
dim co1%(max)
  PRINT "Prime Number (20 TO "; max*10; ")";
    if no!>max*10 then inp1

みたいなコードになっていれば、いらぬ疑問は招かないかと。
バグの混入も防止できるし。
アセンブラですら数値を定義して名前をつけるという機能があるのに、高級言語の
BASICでそういう機能を使わないのはもったいないと思う。
また、最近のＣ言語なんかでは、文法書に、この手の即値はマジックナンバーであり
使うことは悪い習慣だと書かれてしまっているらしい。そうだろうねぇ。

> 配列の確保で
> dim co1%(32700)  と宣言されています。
> その少しあとで入力プロンプトだと思いますが
>   PRINT "Prime Number (20 TO 327000)";
> とあったり
>     if no!>327000 then inp1
> となっているのですが、これはそれぞれ値は正しいのですか？

正しくはないというか、適当です。(^^;

> いや、似たような数値なので、ミスタイプを疑ってみました。
> というか、できればこういうのは変数に定義したほうがよろしいかと。

配列の数字と入力最大値とは関連はありません、たまたま同じ数値にしただけです。
なので、例題のようには出来ないです。

> バグの混入も防止できるし。
> アセンブラですら数値を定義して名前をつけるという機能があるのに、高級言語の
> BASICでそういう機能を使わないのはもったいないと思う。
> また、最近のＣ言語なんかでは、文法書に、この手の即値はマジックナンバーであり
> 使うことは悪い習慣だと書かれてしまっているらしい。そうだろうねぇ。

ご意見に従い、入力の最大値は max! にしてみました。
なるほど、修正が楽になりますね。
SOSU5 で最終と思っていましたが、修正ついでにもっと限界まで攻めてみました。

dim co1%(32766)			' これ以上は64Kオーバーエラー

  max!=1000000
  PRINT "Prime Number (20 TO ";max!;")";

最大値はもっといけるかもですが、時間的に100万までにしました。(^^;
こんどこそ打ち止めです。(^^;

TurboBasicで素数を表示、カウントするプログラム SOSU5 に更新しました。
DOSVAXJ3 や MS-DOS Player の JP モードで動きます。

自己流で考えて作ったので間違いがある可能性はあります。
指定範囲は２０から １００万まです。配列数や時間的な限界がこの辺ということで。
一応、1000000 までは 合っていると思います。

今回指定数を100万までに拡大しました。
起動時オプションで動作変更できます。


SOSU6.ZIP　サイズ 30299bytes　 24-03-01 new!

　 SOSU6.EXE Ver.240301

・DOSVAXJ3 の VGAで動く 素数表示テストです。
・DOSVAXJ3 を起動したら、chev jp でVGAモードにして、SOSU4.EXE を起動してください。
・MS-DOS Player では、chej jp でVGAモードにすれば動作します。
・VTDOS では動作しません。
・ソースも付けます。
・1000000までは合っていると思いますが時間が掛かりすぎるので注意。
・数字や時間情報を SOSU.DAT に追加出力します。
・起動時オプション 1 で S000.DAT に素数を出力します。
・起動時オプション 2 で 表示もファイル出力もしません。カウントのみ。
・数字が大きくなると急速に速度が落ちるので、初めは 100くらいから始めてください。

・更新履歴
2024-03-01　V6　指定できる最大値を100万までに拡大。
2024-02-27　V5　バグ取りや速度アップやファイル出力など。
2024-02-20　V4　公開用に色々弄りました。
2024-02-17　V1　とりあえず作成？

　動作保証はでき無いので実行は自己責任で。　　
http://tamaneko.world.coocan.jp/execom.htm

> 最大値はもっといけるかもですが、時間的に100万までにしました。(^^;

SOSU6.EXE の実行時間です。

SOSU6.EXE
Number.10000	  0: 0' 2   Prime Number = 1229 
Number.100000	  0: 1'40   Prime Number = 9592 
Number.400000	  0:23'20   Prime Number = 33860 
Number.600000	  0:52'55   Prime Number = 49098 
Number.1000000	  1:52'40   Prime Number = 78498 

これだけ時間が掛かりますが、他の計算プログラムと結果は一致しています。
うっかり計測開始してしまったときは、Ctrl+Break で止まる設定ならあるいは。(^^;
まあ、いざという時は DOSVAXJ3 の窓を閉じればいいんだし。(^^;

MS-DOS Player がまた更新されていました。
http://takeda-toshiya.my.coocan.jp/msdos/index.html

---------------------------------------------------------------------

2024/3/2
INT 21h AH=43h, BL=08hが、BL=06hと同じ動作になっていた問題を修正しました。

内蔵デバッガを改良しました。
Rコマンドでレジスタ以外にフラグの値の変更もできるようにしました。
また、V30のディスアセンブラを、i386用のディスアセンブラと統合しました。
V30専用命令以外で正しく認識されない命令があったのが解決しています。
レジスタ名も標準的な名前で表示されるようになっています。

conhost-v2のクラッシュ対策の改良と、WindowsNT 3.51/4向けの修正をしています。

---------------------------------------------------------------------

クラッシュ対策とは、最近のWindowsのIMEの問題などでしょうか。
エミュレータ作者の影の苦労がうかがわれますね。
更新に感謝です。

> TurboBasicで素数を表示、カウントするプログラム SOSU5 に更新しました。

N88-BASICもあらかた忘れ始めているので手元のDISK BASICのリファレンスを見ながら
ですが、TurboBasicはやっぱりかなり違うようです。
上のほうから見ていって、まず気がついたのがLOCATE文。
  LOCATE 1, 26, ,1
というのがありましたが、N88では引数は３つまで。
つまり、カンマの数は２つまででした。
次がCOLOR文。
  COLOR 14, 0
とありますが、N88では最初の引数は0から7までだけでした。
２番目と４番目の引数なら14も使えるようです。

あ、なんか、消し忘れのようなもの見つけてしまった。
a!=0
ってあるんですが、この変数、他では使われていないっぽい。

あ〜、なんか、N88-BASIICに移植したくなってきた。
といっても、動作環境は手元にはない。
実家にはDOS BASICはあるはずだけど、DOS BASICとDISK BASICって何が違っていたか
もう思い出せない。
ちょっと無謀だな。

> どんなチェック漏れがあるやら、想像もつきません。

いやぁ、やっぱりまだ何かおかしいですね。
#11097とか#11098からのツリーの、本来「┗」でなければいけないところがいくつか
「┣」になっていますね。
OKなところとNGなところの条件から追いかけてみましょう。
とはいえ、今日はもう終わり。
明日以降でね。

> 上のほうから見ていって、まず気がついたのがLOCATE文。
>   LOCATE 1, 26, ,1
> というのがありましたが、N88では引数は３つまで。
> つまり、カンマの数は２つまででした。

Turbo Basic と TBasic のマニュアルが腐海から救い出せました。
思いもよらぬところの奥底に沈んでいました。(^^;
それによると、LOCATE 文の引数は 5個まであります。

LOCATE 縦位置,横位置,カーソル表示スイッチ,カーソル開始位置,カーソル終了位置

私がN88系と違うと思ったのは、縦と横が逆なところです。
他の構文は、横、縦なので、間違えやすいですね。MS系の歴史でしょうか。

> 次がCOLOR文。
>   COLOR 14, 0
> とありますが、N88では最初の引数は0から7までだけでした。
> ２番目と４番目の引数なら14も使えるようです。

これもMS系と大きく違うところですね。
詳しくは以下略。(^^;

> あ、なんか、消し忘れのようなもの見つけてしまった。
> a!=0
> ってあるんですが、この変数、他では使われていないっぽい。

う、消し忘れてましたね。(^^;

> あ〜、なんか、N88-BASIICに移植したくなってきた。
> といっても、動作環境は手元にはない。
> 実家にはDOS BASICはあるはずだけど、DOS BASICとDISK BASICって何が違っていたか
> もう思い出せない。
> ちょっと無謀だな。

ネットには、N88系準拠のフリーなBASICもありそうです。
移植するなら、他の素数プログラムが良いと思います。
私のは全く実用的でないので。(^^;
これからアップしますね。

> #11097とか#11098からのツリーの、本来「┗」でなければいけないところがいくつか
> 「┣」になっていますね。

見てみましたが、これは正しいツリーだと私は思います。
うちのツリーは横幅を狭くしたくて見た目がいまいちなのです。(^^;

TurboBasicで素数を表示、カウントするプログラム PRIME2.EXE です。
元にしたのは、十進BASIC に入っていた サンプルソースです。

https://hp.vector.co.jp/authors/VA008683/
ここのダウンロードページの Windowsアーカイブ版の中の
　BASIC7868.zip (1,292,876バイト)を落として展開すると
Mathフォルダがあり、その中にある
PRIME.BAS 　319bytes
を Turbo Basic で動くように改造しました。

特徴は、処理が非常に速く、桁数の制限がほぼ無いことです。
DOSVAXJ3 や MS-DOS Player の JP モードで動きます。

自己流で改造したので間違いがある可能性はあります。
指定範囲は２０から １億までにしました。
起動時オプションで動作変更できます。


PRIME.ZIP　サイズ 30299bytes　 24-03-01 new!

　 PRIME2.EXE Ver.240301

・DOSVAXJ3 の VGAで動く 素数表示テストです。
・DOSVAXJ3 を起動したら、chev jp でVGAモードにして、PRIME2.EXE を起動してください。
・MS-DOS Player では、chej jp でVGAモードにすれば動作します。
・VTDOS では動作しません。
・ソースも付けます。
・20000000までは実行できると思います。
・数字や時間情報を SOSU.DAT に追加出力します。
・起動時オプション 1 で P000.DAT に素数を出力します。
・起動時オプション 2 で 表示もファイル出力もしません。カウントのみ。
・起動時オプション 100以上で 指定した数字で間欠カウント表示。若干速くなるかも。
・数字が大きくなると時間が掛かるので、初めは 1000くらいから始めてください。

・更新履歴
2024-03-03　V2　バグ取りやファイル出力やオプション追加など。
2024-02-27　V1　とりあえず作成

　動作保証はでき無いので実行は自己責任で。　　
http://tamaneko.world.coocan.jp/execom.htm

> 見てみましたが、これは正しいツリーだと私は思います。

あれ？
うちとkonnoさんのところでは、表示のされ方が違うのかな？
そんなことはないと思うけど。

たとえば、#11097から始まるツリーの#11117とか#11126が、本来は「┗」でなければ
いけないけれど「┣」になっているように見えます。
これ、konnoさんのところでは正しく「┗」になっているのか。
それとも私の勘違いで「┣」が正しいのか。
ちょっと混乱しています。

> 自己流で改造したので間違いがある可能性はあります。

プログラムの中身はぜんぜん読めていませんが。

> ・起動時オプション 1 で P000.DAT に素数を出力します。
> ・起動時オプション 2 で 表示もファイル出力もしません。カウントのみ。

ソースリスト冒頭のコメントで

'  IF DSP=1 THEN 	print			'画面出力
'  IF DSP=1 THEN 	print out dat		'ファイル出力
'  IF DSP=2 THEN 	no print		'カウントのみ

となっているのですが、これはコメントが間違っているのかな。

LOCATEなんていう、割と基本的なところからして違うものなのですね。

> LOCATE 縦位置,横位置,カーソル表示スイッチ,カーソル開始位置,カーソル終了位置
> 
> 私がN88系と違うと思ったのは、縦と横が逆なところです。
> 他の構文は、横、縦なので、間違えやすいですね。MS系の歴史でしょうか。

えと、LOCATEが縦、横の順というのは、Turbo Basic と TBasic の両方ですか？
それともどちらかだけ？
ちなみに、N88の場合は

LOCATE 横位置,縦位置,カーソル表示スイッチ

だけです。
カーソルの開始位置、終了位置ってなんだろう。
横長のカーソルを表示できるのかな。
それとも、その制限の範囲にカーソルがこない場合は表示されない、とか。

> 移植するなら、他の素数プログラムが良いと思います。

konnoさんの新しいのもリリースされたし、そっちを狙おうかな。
とりあえず、SOSU6の方を移植するとなると気になる部分がひとつ。
もしかしたら16ビットのBASICでは改善されているかもしれませんが。

loop2:			' 数値を確定した素数で割り切れれば合成数
  for ii!=1 to co!-1
    b!=int(i!/co1%(ii!)):if b!=i!/co1%(ii!) then noflg=1:goto lpend2
  next ii!
lpend2:

8ビット時代のBASICでは、こういうループの脱出方法をは推奨されなかった。
FORのループを完了させずに途中で脱出すると、スタックにデータが詰みあがった
ままになってしまうのだそうで。
たしか、新しくRUNするとクリアされるのだったかなぁ。
もしかしたら、明示的にCLEARというコードを書かないとクリアされなかったかも
しれない。
この辺は処理系によって違うかもしれないし、当時のBASICのリストを見ると、DEFINT
と同様、ソースの先頭でおまじないのようにCLEARを入れているものが多かったので、
この辺で混同している部分もあるかもしれない。
で、結局どうするのがよいかというと

*LOOP2
FOR II!=1 TO CO!-1
    IF INT(I!/CO1%(II!))=I!/CO1%(II!) THEN NOFLG=1:II!=CO!-1
NEXT

こんな感じで無理やり強制的にループの制御変数の値を書き換えてしまう、という
ワザが使われていました。

> たとえば、#11097から始まるツリーの#11117とか#11126が、本来は「┗」でなければ
> いけないけれど「┣」になっているように見えます。

あうう、リンク先をそのまま見ていました。頭が他に行っていたみたいです。(>_<)
 msgview のツリーは「┣」になっていますね。失礼しました。m(__)m
 何が悪いのかはわかりません。m(__)m

> ソースリスト冒頭のコメントで
> '  IF DSP=1 THEN 	print			'画面出力
> '  IF DSP=1 THEN 	print out dat		'ファイル出力
> '  IF DSP=2 THEN 	no print		'カウントのみ
> となっているのですが、これはコメントが間違っているのかな。

コメントの間違いにコメントするなんて、鬼畜ですぅ。(;_;)
もちろん1行目は ゼロのつもりだったんですぅ。
日付や指定範囲などもおかしいような気がするけど気にしない。(^^;

> > LOCATE 縦位置,横位置,カーソル表示スイッチ,カーソル開始位置,カーソル終了位置

見直したらおかしなところに気が付きました。
  LOCATE 1, 26, ,1
とありますが、おしりの１はカーソル開始位置なので、終了位置が無い？
これも元は何かのサンプルソースで
  LOCATE 1, 26, ,1 '%CursorOff
多分これが元だと思います。
TBasicのマニュアルでは、終了位置を省略すると開始位置と同じ数値が入るらしいですが
このコメントでは、カーソルオフになっていますね？　わからん。
サンプルが間違えているかもですね。(^^;

> えと、LOCATEが縦、横の順というのは、Turbo Basic と TBasic の両方ですか？

両方です。TBasicはもろMS系だと思いますが、TurboBasicもMS系準拠ということですかね。

> カーソルの開始位置、終了位置ってなんだろう。

カーソルの高さ指定だと思います。TBasicでは、0が上で 15が下みたいです。


> FORのループを完了させずに途中で脱出すると、スタックにデータが詰みあがった
> ままになってしまうのだそうで。

うげ、これは知らなかったです。ヤバイかも・・・(>_<)
STIME でたまに問題が出るのはこれかもしれないですね。

> FOR II!=1 TO CO!-1
>     IF INT(I!/CO1%(II!))=I!/CO1%(II!) THEN NOFLG=1:II!=CO!-1
> NEXT
> こんな感じで無理やり強制的にループの制御変数の値を書き換えてしまう、という
> ワザが使われていました。

これも良くやっていますが、これからはループを抜ける時は気を付けます。

>  何が悪いのかはわかりません。m(__)m

私にも何が悪いのか、今のところは全くわかっていません。
一応、１月にkonnoさんにお送りしたコードを再び引っ張り出してみました。
そして、うちの板塀の現行ログを表示してみたのですが、全て正常な表示に見える
のですよ。かなり複雑そうなツリーであっても。
う〜ん、まさかデータというかログファイルのほうに原因があるのか？
それとも、私がkonnoさん的なコードに転記する際にどこかを誤ったとか。
いささか複雑というか統一性に欠けたコーディングスタイルでしたから。
あるいは、konnoさんがご自分でコードをきれいにしようとして失敗したとか。

一応、ざっくりみたところ。
msgviewの中で「┗」「┣」が表示されるルーチンは以下のような感じ。

if ($tx[$lx] == 0 && $lx != 0) { print "┗"; }
else {
    $jj=1;
    while ( $tlx[$j+$jj] > 0 ) {
        if ( $tlx[$j] == $tlx[$j+$jj] ) { $jj=0; last; }
        if ( $tlx[$j] > $tlx[$j+$jj] ) { $jj=1; last; }
    $jj++;
    }
    if ( $jj == 0 ) { print "┣"; }
    elsif ($lx != 0 ) { print "┗"; }
}

一方で、正しく表示される一括表示のツリー表示部分は以下のような感じ。

if ( $tx[$lx] == 0 ) { print "┗"; }
else {
    $jj=1;
    while ( $tlx[$j+$jj] > 0 ) {
        if ( $tlx[$j] == $tlx[$j+$jj] ) { $jj=0; last; }
        if ( $tlx[$j] > $tlx[$j+$jj] ) { $jj=1; last; }
        $jj++;
    }
    if ( $jj == 0 ) { print "┣"; }
    else { print "┗"; }
}

条件式が違うじゃない。
何でこんなところを見落としたんだろう。
テストデータというか板塀のデータで正常に表示されていたからだろうなぁ。

ということで、もしかしたらこれでうまくいくかも。
もうkonnoさんのところでも不要なコメントは全部落としているでしょうから、場所は
すぐに見つかることでしょう。
とりあえず試してみてください。

> これも元は何かのサンプルソースで
>   LOCATE 1, 26, ,1 '%CursorOff
> 多分これが元だと思います。
> TBasicのマニュアルでは、終了位置を省略すると開始位置と同じ数値が入るらしいですが
> このコメントでは、カーソルオフになっていますね？　わからん。

値を省略するとカーソルオフなんですかね。
N88だと、最後のパラメータなんでよく省略されていましたが、省略時は単にそれ以前
の値を引き継いでいました。

> カーソルの高さ指定だと思います。TBasicでは、0が上で 15が下みたいです。

あ、横方向ではなく、１つの文字の中の縦方向でしたか。
ということは、開始位置が0、終了位置を1と指定すると、アッパーラインのような感じ
になるということですね。これはVzのCiとCoみたいに変更できるということですから、
使い方によっては便利かもしれない。

> > FORのループを完了させずに途中で脱出すると、スタックにデータが詰みあがった
> > ままになってしまうのだそうで。
> うげ、これは知らなかったです。ヤバイかも・・・(>_<)

いや、昔のインタプリタの時代の話ですから。
コンパイル型言語なら大丈夫なんじゃないかなぁ。
ただ、ループをまわす回数が増えても問題がないのに、ループの回数そのものが少ない
にもかかわらず、そのループを呼び出す回数が増えると問題が出るという、謎の不具合
につながることがあって。
苦労させられた人はそれなりにいるはず。


ところで、それよりも、変なことに気がつきました。
#11097によると

> 最も素朴な方法は、2 から √n 以下の素数まで順番に割っていく

とあるのですが、コードの中にSQRT関係の関数がないようです。
これ、本当にこのアルゴリズムであっていますかね。
例えば、23が素数であるかを確認するためには√23以下の素数、つまり2と3で確認
すれば事足りるわけです。
コードを追いかけていませんが、まさか、5とか7でも割っているから余計に時間が
かかっている、ということはないでしょうか。

> あるいは、konnoさんがご自分でコードをきれいにしようとして失敗したとか。

私は頂いたソースをそのまま張り付けただけだったと思います。(^^;
今見たら私のバグバグなトンでもコードのコメントがそのまま大量に残っていますね。(^^;
よくこの状態で修正できたと感心します。いや、ありがたいです。

> msgviewの中で「┗」「┣」が表示されるルーチンは以下のような感じ。
> if ($tx[$lx] == 0 && $lx != 0) { print "┗"; }

ここは探してみたところ、以下のようになっていましたが修正しました。

#       if ($tx[$lx] == 0 && $lx != 0) { print "┗"; }
        if ( $tx[$lx] != 0 ) { print "┣"; }
    ↓
	if ( $tx[$lx] == 0 ) { print "┗"; }

     elsif ($lx != 0 ) { print "┗"; }
    ↓
     else { print "┗"; }

最初下の1行だけ修正しましたが変わりませんでした。
それで上側も修正したら、キチンとツリー表示出来ました。＼(^^)／ ﾔｯﾀ-

> もうkonnoさんのところでも不要なコメントは全部落としているでしょうから、場所は
> すぐに見つかることでしょう。

不要なコメントはまだそのままですが、これを機に削除しようと思います。(^^;
本当にありがとうございました。m(__)m

> 値を省略するとカーソルオフなんですかね。
> N88だと、最後のパラメータなんでよく省略されていましたが、省略時は単にそれ以前
> の値を引き継いでいました。

試しに
LOCATE 1, 26, ,10
にして実行してみたら、カーソル高さが半分くらいになっていました。
省略時はそれ以前の値を引き継ぐようですね。

> コンパイル型言語なら大丈夫なんじゃないかなぁ。
> ただ、ループをまわす回数が増えても問題がないのに、ループの回数そのものが少ない
> にもかかわらず、そのループを呼び出す回数が増えると問題が出るという、謎の不具合
> につながることがあって。
> 苦労させられた人はそれなりにいるはず。

やっぱりむやみにループを抜けるのは避けた方が良さそうですね。

> ところで、それよりも、変なことに気がつきました。
> #11097によると
> > 最も素朴な方法は、2 から √n 以下の素数まで順番に割っていく
> とあるのですが、コードの中にSQRT関係の関数がないようです。

気が付いてしまいましたか、そうです、私はWikiを見ないで自分で考えたのです。
素数を調べるには確定した素数で割ればいいんじゃないかと思ったのです。
それで配列に確定した素数を入れたのですが、数字が大きくなると割る回数が増えるので
時間が掛かったのでした。

> これ、本当にこのアルゴリズムであっていますかね。

PRIME2.EXE は、SQR関数を使っているので、これが本来のアルゴリズムなのでしょうね。
でも結果は一致していたので、考え方はあながち間違ってはいなかったかなと思います。

> 例えば、23が素数であるかを確認するためには√23以下の素数、つまり2と3で確認
> すれば事足りるわけです。
> コードを追いかけていませんが、まさか、5とか7でも割っているから余計に時間が
> かかっている、ということはないでしょうか。

その通りですね、ですから、SOSUシリーズは私の個人的仮説の実験だったのです。(^^;
PRIME.BAS のサンプルは学校でも使える模範的コードなのだと思います。

> それで上側も修正したら、キチンとツリー表示出来ました。＼(^^)／ ﾔｯﾀ-

無事に正常表示になりましたね。よかったよかった。

> 今見たら私のバグバグなトンでもコードのコメントがそのまま大量に残っていますね。(^^;
> よくこの状態で修正できたと感心します。いや、ありがたいです。

だから前にも言ったけど、ほとんど迷彩のような。
あたかも、プログラムからバグを除去することを拒むかのような。
このコードを書いた人は、プログラムの完成を見ることなく、永遠にデバッグのぬるま湯に
浸かっていたいのか。
と、誤解してしまいそうなわけですよ。誤解ですよね？
＃本心だったらいやすぎ


コメントが多いというのは、決して悪くはないんですよ。
問題は、それが何を意味しているかがわからないこと。
例えば、コードの右側のほうに
「この行のコメントをはずすと××になる」
とか
「※参考　○○氏のコード」
などときちんと記載されていればいいのですよ。
あるいは、ymfcstなんかでも採用されているような感じで
「★マークの５行のコメントをはずすとほにゃらら」
みたいなものとか。
要は、konnoさんのコードの場合、有効な情報が全くないのがイマイチ。

プログラムにおけるコメントって、コンピュータではなく人間に対して書くものですから、
人間に対して意味のない情報は少ないほうがいい。
私も、プロの書いたコードなんてあんまり見たことがありませんが、まずは目標として
コードだけで、つまりコメント全くなしで、ここは何をやっているかがわかるような
ものを目指すらしい。そうすれば、そもそもコメントを入れなくてすむから。
おおむね、人はみな横着ですからね。コメントを考える手間も省きたいわけですよ。
ただ、それはある種の理想。そんなものが実現することはまずない。
ということで、次善の策。コメントだけを追いかけることで、そのコードが何をやって
いるかがわかるようにする。
つまり、それなりにプログラムを読んできた経験のある人の場合、初めて触れる言語で
あっても、コメントのあるコードであれば、まずコメントを読む。
私も、Vzのマクロを勉強するとき、ikubohさんだったかな、もう忘れましたが、誰かの
マクロコードのコメントを見て勉強した記憶があります。

ということで、必要なコメントはバシバシ入れましょう、ということでした。

> コメントの間違いにコメントするなんて、鬼畜ですぅ。(;_;)

いや、なんとなく間違っていそうだとは思ったけど、確信がもてなかったのですよ。
だって、#11135で

> ・起動時オプション 1 で P000.DAT に素数を出力します。
> ・起動時オプション 2 で 表示もファイル出力もしません。カウントのみ

とはあったけど、起動時オプション 0 があるとは書いてなかったもので。

> 日付や指定範囲などもおかしいような気がするけど気にしない。(^^;

日付や範囲指定については、まだ見てもいない。
それより気になった部分がいくつかあって。
例えば、表示する素数の数の入力を求めるプロンプト、日本語の部分がコメント
になっていますが、これはなぜそうしているのか、とか。
メインというか j のループからは結構強引な脱出をしているな、とか。
そのループのコメントの「i;:c=c+1」っていったいなんだろう、とか。
outputのコメント、なんで素数が１個でも10000000個でも時間が同じなのかな、
とか。もしかしたら違うのかもしれないけど、この表現ではそれ以外の意図は
読み取れない。
タイマーのサブルーチンの冒頭、謎のif文がコメントアウトされているけど、
これはいったいなんだろう、とか。

一般にコードの概要をつかむにはコメント文が有効のはずなんだけど、全く有効に
見えない気がする。

> このコードを書いた人は、プログラムの完成を見ることなく、永遠にデバッグのぬるま湯に
> 浸かっていたいのか。
> と、誤解してしまいそうなわけですよ。誤解ですよね？
> ＃本心だったらいやすぎ

もちろん誤解ですよ。(^^;　ただ世の中変人が多いのでそういう人もいるかも。（いねえよ）

> コメントが多いというのは、決して悪くはないんですよ。
> 問題は、それが何を意味しているかがわからないこと。

超絶ハイテク技などはそういうコメントが欲しいものですね。

> 要は、konnoさんのコードの場合、有効な情報が全くないのがイマイチ。

うう、これは BASIC コードのことを言っているのですよね。
アセンブラやVZマクロにはかなりコメントを入れているつもりです。(^^;

> ということで、次善の策。コメントだけを追いかけることで、そのコードが何をやって
> いるかがわかるようにする。

これは上で書きましたが、BASICは自分で読めるものだからあまりコメントを入れないのですね。
でも後で読むと何をやっているのかわからなくなってしまっています。(>_<)
ということで、今はサブルーチンのタイトルや説明、各行のコメントを
なるべく入れるようにやっている最中です。(^^;
達人のコードにコメントが無いのは必要を感じないからなんでしょうね。

> 私も、Vzのマクロを勉強するとき、ikubohさんだったかな、もう忘れましたが、誰かの
> マクロコードのコメントを見て勉強した記憶があります。
> ということで、必要なコメントはバシバシ入れましょう、ということでした。

ikubohさんなど達人のマクロはコメントがないと何をやっているのか全く分からないレベルですからね。
私もこれからは他人が読むことを念頭に入れてコメントを入れるようにします。

＃　昨日の自分は他人と言いますからね。(ﾟ゜)☆＼(--#) それはおのれじゃ

> だって、#11135で
> > ・起動時オプション 1 で P000.DAT に素数を出力します。
> > ・起動時オプション 2 で 表示もファイル出力もしません。カウントのみ
> とはあったけど、起動時オプション 0 があるとは書いてなかったもので。

お察しの通りオプション 0 はありません。(^^;
あ、P000.DAT も S000.DAT の間違いですね。P000 は PRIME2 の方でした。(>_<)

> 例えば、表示する素数の数の入力を求めるプロンプト、日本語の部分がコメント
> になっていますが、これはなぜそうしているのか、とか。

最初日本語で書いたけどUSモードだと表示しないとか色々面倒なのでコメントにしてしまい
そのまま放置してました。(^^;

> メインというか j のループからは結構強引な脱出をしているな、とか。

これは良くない抜け方でしたね、気が向けば直します。(^^;

> そのループのコメントの「i;:c=c+1」っていったいなんだろう、とか。

これは元は PRINT文だったのを、PRINT1: というサブルーチンに変更したので

  IF j>SQR(i) THEN gosub PRINT1 i;:c=c+1	' 素数
             ↓
  IF j>SQR(i) THEN gosub PRINT1  'i;:c=c+1	' 素数

こういうように、コメントで手抜きをしてました。(^^;
まあ、飛び先でやってることをコメントに残したとも言えなくもないし。(^^;

> outputのコメント、なんで素数が１個でも10000000個でも時間が同じなのかな、
> とか。もしかしたら違うのかもしれないけど、この表現ではそれ以外の意図は
> 読み取れない。

'Number.1	    0: 0' 4 	Prime Number = 9592 
'Number.10000000	    0: 0' 4 	Prime Number = 9592 

これですね、Prime Number が同じということでお察しください。(^^;
手抜きの残骸だったのかなんなのか、今はもうわからないです。(^^;

> タイマーのサブルーチンの冒頭、謎のif文がコメントアウトされているけど、
> これはいったいなんだろう、とか。

これも借り物のルーチンの残骸ですね。他人に見せることは全く意識してないのです。

> 一般にコードの概要をつかむにはコメント文が有効のはずなんだけど、全く有効に
> 見えない気がする。

私のソースはこんなのばっかりなので、元々は公開する気も無かったんですがねぇ。(^^;
出来る範囲で改善するようにします。m(__)m

オリジナルの prime.bas のソースはこれだけです。

INPUT n
IF MOD(n,2)=0 THEN
  IF n=2 THEN PRINT "素数" ELSE PRINT "合成数"
ELSE
  FOR i=3 TO SQR(n) STEP 2
    IF MOD(n,i)=0 THEN EXIT FOR 
  NEXT i
  IF i<=SQR(n) THEN PRINT "合成数" ELSE PRINT "素数"
END IF
END


IF 〜 ELSE 〜 END IF をうまく使ってシンプルでエレガントですね。
TurboBasic で同じやり方はわからなかったので、自分なりに改造したのが以下

FOR i=2 TO n 
  IF i=2 THEN gosub PRINT i;:c=c+1		' 2 素数
  i2=i/2:i3=int(i/2):IF i2=i3 THEN goto EXIT2	' 合成数
  FOR j=3 TO SQR(i) STEP 2			' 偶数をスキップ
    i2=i/j:i3=int(i/j):IF i2=i3 THEN goto EXIT1 ' 合成数
  NEXT j
EXIT1:
  IF j>SQR(i) THEN gosub PRINT i;:c=c+1		' 素数
EXIT2:
NEXT i:i=i-1

としきさんにループの抜け方が強引と言われたけど、うーむ・・・

    IF MOD(n,i)=0 THEN EXIT FOR 
ここは
    i2=i/j:i3=int(i/j):IF i2=i3 THEN goto EXIT1 ' 合成数
             ↓
    i2=i/j:i3=int(i/j):IF i2=i3 THEN i=i+1	' 合成数
にすればよかったのかな。
つい、EXIT という構文に引っ張られたような・・・(^^;

> > 要は、konnoさんのコードの場合、有効な情報が全くないのがイマイチ。
> うう、これは BASIC コードのことを言っているのですよね。

BASICもそうですが、先日お送りいただいたperlのコードも含めて、です。

> ということで、今はサブルーチンのタイトルや説明、各行のコメントを
> なるべく入れるようにやっている最中です。(^^;

うん、まぁ、最終的な完成品を作るにあたってそういうことは必要ですけどね。
私のような横着な人間はどうするかというと、プログラムを作る前に、日本語で
設計します。そして、その設計をそのままコードの中にコメントとして残しておく。
例えば、今回のkonnoさんのprime2.basを作ろうとするなら、私の書きそうな設計
は以下のような感じ。

　初期設定
　求める素数上限入力
　メインルーチン（サンプルコードを最大限流用）
　終了処理（キー入力待ち必須）

　出力サブルーチン
　ファイル出力
　エラー終了ルーチン（自作の××からコピペ）
　タイマールーチン（自作の○○からコピペ）

こんな感じで設計ができたら、あとは切った貼った、コピペできないところは仕方
ない作るか。
という風にするわけです。
そうすれば、わざわざコメントを書くということはなくなります。
その上、設計をじっと見つめて、例えば、出力部分はもうちょっと整理できそうだ、
とか、エラーのルーチンはそのままコピペだとイマイチかも、みたいなことも考え
付いたりするわけですよ。
そういえば昔、どこかに似たようなことも書いた気が、と思って検索したら。
nifty:FGALDC/MES/15/#19030
に似たようなことを書いていた。
そうか、ikubohさんではなくてEmmettさんのマクロで勉強したのか。

いろいろなことを書きましたが。
結論は、楽をしましょうよ、ということに尽きるわけで。

> BASICもそうですが、先日お送りいただいたperlのコードも含めて、です。

そうでした、直してもらったばかりなのに perl のことを忘れていました。m(__)m

> 私のような横着な人間はどうするかというと、プログラムを作る前に、日本語で
> 設計します。そして、その設計をそのままコードの中にコメントとして残しておく。
> 例えば、今回のkonnoさんのprime2.basを作ろうとするなら、私の書きそうな設計
> は以下のような感じ。

なるほど、これをそのまま各ルーチンのタイトルに使うのですね。
私は手を付けてからどうするか考える癖があるみたいで、
今すぐこのスタイルに切り替えるのは難しそうです。(^^;
でも参考になりました。やってみたいと思います。

> そういえば昔、どこかに似たようなことも書いた気が、と思って検索したら。
> nifty:FGALDC/MES/15/#19030
> に似たようなことを書いていた。
> そうか、ikubohさんではなくてEmmettさんのマクロで勉強したのか。

そうでしたか、実は私も「コメントの多いマクロ」で Emmettさんを思い出してました。(^^;
その Emmettさんの発言を見ると

> 》　僕は、マクロを書く時はとりあえずグローバルマクロからとにかく書き始めます。
> 》  僕は、アルゴリズムを最初にどこかにメモしておいて、それに従ってプログラム
> 》  を組んで行くということはやったことがありません。いつでもいきなり、グロー
> 》  バルの１行目から、じかに書き始めます。

私とおんなじですね。(^^;
それに対してとしきさんも

> あぁ、なるほど、やっと Emmett さんのマクロ作法がわかったような気がします。
> 基本的な考え方としては、私も Emmett さんとほとんど変わりません。
> とっても安心しました。

このように同意していますが、その後に

> でも、大きく異なるところは、私の場合、仮想プログラム言語というかメタ言語
> というか、まぁ日本語のようなもので書いているのです。で、大体まとまったら
> マクロに翻訳する、と。

こう書いていますね。やっぱりスタイルが違うと感じます。(^^;
もちろん、としきさんの方が正統派だと思います。

> いろいろなことを書きましたが。
> 結論は、楽をしましょうよ、ということに尽きるわけで。

楽をする、という意味では、としきさんのような正統派のやりかたが良いと思います。
それが出来ない私は、やっぱり楽をしようと思っていないのかもですね。(^^;
それよりも早く頭の中のアイデアをコードにしたいという欲求が強いのでしょう。(^^;
＃　そうしないとアイデアが消えてしまいそうだから。(^^;;

多分、最大というか基本的な違いはここ。

> それよりも早く頭の中のアイデアをコードにしたいという欲求が強いのでしょう。(^^;
> ＃　そうしないとアイデアが消えてしまいそうだから。(^^;;

私はアイディアをコードではなく日本語で考えている、ということ。
だから、日本語でメモをしている。
逆に言うと、ナイスなコードを思いつく、ということはあんまりなさそうです。

あと、前述のEmmettさんとの対話の部分、読み直して、もしかしたら私に誤解が
あったかもしれないというのがkonnoさんの指摘で気がついた。

> > 》  僕は、アルゴリズムを最初にどこかにメモしておいて、それに従ってプログラム
> > 》  を組んで行くということはやったことがありません。いつでもいきなり、グロー
> > 》  バルの１行目から、じかに書き始めます。
> 
> > あぁ、なるほど、やっと Emmett さんのマクロ作法がわかったような気がします。
> > 基本的な考え方としては、私も Emmett さんとほとんど変わりません。
> > とっても安心しました。
> 
> このように同意していますが、その後に

このときの薄らぼんやりとした記憶では、私、サブルーチンから書き始めるのでは
なく、全体の大枠から書き始める、という意味でEmmettさんと同じだな、と感じた
ように覚えています。
確かにこの部分、解釈によってはいろいろと怪しいかもしれない。

> 私はアイディアをコードではなく日本語で考えている、ということ。
> だから、日本語でメモをしている。
> 逆に言うと、ナイスなコードを思いつく、ということはあんまりなさそうです。

うーむ、私もアイデアが浮かんだ時点では、コードではなく日本語な気もしますが
コード的な、パズルのピース的な漠然としたイメージなのかもしれませんね。

> このときの薄らぼんやりとした記憶では、私、サブルーチンから書き始めるのでは
> なく、全体の大枠から書き始める、という意味でEmmettさんと同じだな、と感じた
> ように覚えています。
> 確かにこの部分、解釈によってはいろいろと怪しいかもしれない。

普通、枝葉であるサブルーチンから書き始める人はいませんよね。(^^;
私も Emmettさんの書き込みを読み直したら、何か違う気がしてきました。

> 》  いつでもいきなり、グローバルの１行目から、じかに書き始めます。

ここ、私なら始めに類似したプログラムを探してそれを修正して使おうとします。
ゼロから書き始めるなんて面倒だと思うので私はほとんどやったことがないのですよ。
＃　それが改造人間の定めなのさ・・・・　ルルルー・・・

いいかげん、タイトルを変えるべきだということに遅まきながら気がつきました。
いまさら、という気も大いにしますが。
そして、たいそうな内容を書くわけでもない。

> ここ、私なら始めに類似したプログラムを探してそれを修正して使おうとします。
> ゼロから書き始めるなんて面倒だと思うので私はほとんどやったことがないのですよ。

類似したプログラムが見つからないとき、というのも私の場合はたまにある。
ん〜、最近はあんまりそういうこともありませんが。
例えば、野ざらし言#569 からのツリーで作ったマクロ。
こういう案件、konnoさんはあまり手を出さないということでしょうか。
私も最近はそういうことがなくなったということは、年をとったせいかも。
いかんなぁ。

> オリジナルの prime.bas のソースはこれだけです。

なるほど、MODって関数なんですね。
N88-BASICでは演算子なんですけどね。

> INPUT n
> IF MOD(n,2)=0 THEN
>   IF n=2 THEN PRINT "素数" ELSE PRINT "合成数"
> ELSE
>   FOR i=3 TO SQR(n) STEP 2
>     IF MOD(n,i)=0 THEN EXIT FOR 
>   NEXT i
>   IF i<=SQR(n) THEN PRINT "合成数" ELSE PRINT "素数"
> END IF
> END

これをそのままN88-BASICに移植すると、こんな感じかなぁ。
実行していないので、そのまま動くかどうかはわかりません。

100 INPUT N
110 IF N MOD 2=0 THEN 120 ELSE *ELSE1
120     IF N=2 THEN PRINT "素数" ELSE PRINT "合成数"
130     GOTO *ENDIF1
140 *ELSE1
150     I=3
160     WHILE (I<=SQR(N)) AND (N MOD I<>0)
170         I=I+2
180     WEND 
190     IF I<=SQR(N) THEN PRINT "合成数" ELSE PRINT "素数"
200 *ENDIF1
210 END

解説すると

・MODは演算子に変更した。
・110行目のTHENの行番号は省略できたかもしれない。
　つまり、NULLの行番号が許容されるのなら、その場合は単に次の行に制御が移る。
・ループの脱出条件が複数あるので、FORループからWHILEループに変更した。


> TurboBasic で同じやり方はわからなかったので、自分なりに改造したのが以下

TurboBasicって、MOD関数またはMOD演算子ってないんですか？
あと、NEXTの後ろの変数って省略できないんですか？
でもコンパイラ言語だからあんまり関係ないのか。
８ビットのBASICのころは、NEXTの後ろの変数を省略するとマイクロ秒の単位で速く
なると信じられていて、だから私も省略するのが癖になっているのですよ。
高速化といえば、最初のFORの直下のIF文。
これはループの中に入れておくのはもったいない。
だって、１回しか比較する必要がないものを何回も比較することになるわけだから。

> i=2:gosub PRINT i;:c=c+1		' 2 素数
> FOR i=3 TO n 

こんな感じで十分だと思う。

> いいかげん、タイトルを変えるべきだということに遅まきながら気がつきました。

私も途中で思ったのですが、まあいいかと。(^^;

> 類似したプログラムが見つからないとき、というのも私の場合はたまにある。
> ん〜、最近はあんまりそういうこともありませんが。
> 例えば、野ざらし言#569 からのツリーで作ったマクロ。
> こういう案件、konnoさんはあまり手を出さないということでしょうか。

そういう案件も多いと思います。その場合でも入出力など使えるルーチンは切り貼りで済まします。
そういえばテレビドラマ「ガリレオ」の教授は思いついたらいきなり数式を書きなぐっていましたね。
そういうやり方ができるのは、c.mosさんくらいではないかと。

> 私も最近はそういうことがなくなったということは、年をとったせいかも。

私も年を取って、昔のやり方でしか出来なくなったような気がします。
BASICのソースは普通大文字で書きますが、最近小文字の行を混在させてますよね。
そこは、自分で一から書いているよという自己主張なのかもしれません。(^^;

> なるほど、MODって関数なんですね。
> N88-BASICでは演算子なんですけどね。

あう、MOD は演算子でしたね、失礼しました。

> これをそのままN88-BASICに移植すると、こんな感じかなぁ。
> 実行していないので、そのまま動くかどうかはわかりません。

> TurboBasicって、MOD関数またはMOD演算子ってないんですか？

もちろんありますが、32767以上は駄目みたいです。

> あと、NEXTの後ろの変数って省略できないんですか？
> でもコンパイラ言語だからあんまり関係ないのか。

省略できると思います。指定した方がわかりやすいと思うので。

> ８ビットのBASICのころは、NEXTの後ろの変数を省略するとマイクロ秒の単位で速く
> なると信じられていて、だから私も省略するのが癖になっているのですよ。

コンパイラ言語ではあんまり関係ないのかもしれないなと思います。

> 高速化といえば、最初のFORの直下のIF文。
> これはループの中に入れておくのはもったいない。
> だって、１回しか比較する必要がないものを何回も比較することになるわけだから。

これはその通りですね、最初の FOR文はいらなかったですね。
うっかりしていました。(^^;
 SOSU のソースから切り貼りしたのをそのまま残してしまったのかなぁ。(^^;

> あう、MOD は演算子でしたね、失礼しました。

？？？
オリジナルの prime.bas では関数になっていますよね。
ということは、十進BASICでは関数である、ということだと思いますが？
もしかしたら演算子にもあるかもしれませんけどね。

> > TurboBasicって、MOD関数またはMOD演算子ってないんですか？
> もちろんありますが、32767以上は駄目みたいです。

N88-BASICのリファレンスでは、演算前に小数点以下は切り捨てられるとはあります
が、上限については記載がありません。試してみたいところではあります。

> これですね、Prime Number が同じということでお察しください。(^^;
> 手抜きの残骸だったのかなんなのか、今はもうわからないです。(^^;

いや、konnoさんがわからないくらいですから、私にも察することはできません。
それはさておき。
マジでN88-BASICに移植することを考えています。
で、まだ逐語的な変換には手をつけていないのですが。
気になったのがここ。

if dsp=1 then print#1,"":gosub 1010
if n>2000 then gosub 1000			'output

dsp=1 かつ n>2000 のときは２回出力されるようなんですが、これって仕様的に
なんとなく妙な気がします。これで正しいのですよね？
あと、変数 j2 と j3 も、何をやっているのかよくわからない。
この２つを足し算しているところもあるし。

> オリジナルの prime.bas では関数になっていますよね。
> ということは、十進BASICでは関数である、ということだと思いますが？
> もしかしたら演算子にもあるかもしれませんけどね。

あうう、キチンと読んでいませんでした。
てっきり私がまた間違った言い方をしてしまったのかと。(^^;

> > > TurboBasicって、MOD関数またはMOD演算子ってないんですか？
> > もちろんありますが、32767以上は駄目みたいです。
> N88-BASICのリファレンスでは、演算前に小数点以下は切り捨てられるとはあります
> が、上限については記載がありません。試してみたいところではあります。

十進BASICで関数を使っているのは、MOD に制限があるからかも。
思いついて TurboBasicでテストプログラムを作ってみました。

'tmod.bas
screen 0
print " input ";:input a					'
OPEN "mod.dat" FOR append AS#1			'ファイル出力
print "  a    MOD i ","2bytes "," Froat   "," a / i"
for i=2 to 5
  bb=int((a/i-int(a/i))*i+.5)			' MOD 代替式
  print a;"mod";i,a mod i,bb,a/i 
  print#1, a;"mod";i,a mod i,bb,a/i '
next
print "  a     \  i","2bytes "," Froat   "," a / i"
for i=2 to 5
  cc=int(a/i)					' \ 代替式
  print a;" \ ";i,a \ i,cc,a/i  '
  print#1,a;" \ ";i,a \ i,cc,a/i  '
next

PRINT#1,""
CLOSE#1
100 '入力待ち
print "  push eny key  ";
a$=input$(1)
if a$="" then 100
end

結果

　 a  MOD/\ i  2bytes        Froat         a / i"
 32767 mod 2   1             1             16383.5 
 32767 mod 3   1             1             10922.33333333333 
 32767 mod 4   3             3             8191.75 
 32767 mod 5   2             2             6553.4 
 32767  \  2   16383         16383         16383.5 
 32767  \  3   10922         10922         10922.33333333333 
 32767  \  4   8191          8191          8191.75 
 32767  \  5   6553          6553          6553.4 

 32768 mod 2   0             0             16384 
 32768 mod 3  -2             2             10922.66666666667 
 32768 mod 4   0             0             8192 
 32768 mod 5  -3             3             6553.6 
 32768  \  2  -16384         16384         16384 
 32768  \  3  -10922         10922         10922.66666666667 
 32768  \  4  -8192          8192          8192 
 32768  \  5  -6553          6553          6553.6 

 32769 mod 2   0             1             16384.5 
 32769 mod 3  -2             0             10923 
 32769 mod 4   0             1             8192.25 
 32769 mod 5  -3             4             6553.8 
 32769  \  2  -16384         16384         16384.5 
 32769  \  3  -10922         10923         10923 
 32769  \  4  -8192          8192          8192.25 
 32769  \  5  -6553          6553          6553.8 

これを見るとやはり 32768 以上では MOD も ￥ も使えないようですね。
実は今 STIME のタイマーで計算がバグって困ってたんですが、これが原因だったようです。
テストプログラム作成は無駄ではなかった。(~~;

> マジでN88-BASICに移植することを考えています。
> で、まだ逐語的な変換には手をつけていないのですが。

私も気になったので、NP2 でやってみました。(^^;
N88BASIC.EXE は画面がピンクになって動かないみたいです。(>_<)
BASIC.COM がコンパイラなんですね。無事コンパイルしたのを実行したら、
入力した数字が素数かどうかを表示するのですね。(^^;

> 気になったのがここ。
> if dsp=1 then print#1,"":gosub 1010
> if n>2000 then gosub 1000			'output
> dsp=1 かつ n>2000 のときは２回出力されるようなんですが、これって仕様的に
> なんとなく妙な気がします。これで正しいのですよね？

もちろんまずいです。(^^;　いい加減なだけでした。

> あと、変数 j2 と j3 も、何をやっているのかよくわからない。
> この２つを足し算しているところもあるし。

これですね。

810 if i<j2 then return 			'dsp2でカウント表示
j2=j2+j3  
820 LOCATE 5,1:PRINT i;	'

j2 は表示するまでのカウント数かな？
j3 はオプションの数字で、カウントがこの数字以上になったら次の数字ぶん表示しない
という感じですかね。ほとんど意味がないようですが。(^^;

お彼岸の墓参りの相談で実家に顔を出してきました。
その折に、３０分ほどですが、PC-98に触れて。

> これをそのままN88-BASICに移植すると、こんな感じかなぁ。
> 実行していないので、そのまま動くかどうかはわかりません。

動きました。
細かくはチェックしていませんが、概ね、一発完動。
一発完動教徒なら、このくらい当たり前、というかもしれませんけどね。

> ・110行目のTHENの行番号は省略できたかもしれない。
> 　つまり、NULLの行番号が許容されるのなら、その場合は単に次の行に制御が移る。

あ、ここが省略できるかは確認してこなかった。
次に行ったときには確認してこよう。といいつつ、忘れそうだけど。

次の週末、金曜日から土曜日にかけて実家に泊まることになったので、それまでには
prime2.basのN88-BASICへの移植を終わらせたいなぁ。

> マジでN88-BASICに移植することを考えています。
> で、まだ逐語的な変換には手をつけていないのですが。

ぼちぼち、移植を始めています。

・コマンドラインオプションは取得できないので、プログラム冒頭で入力するように
　した
・まず真っ先にやったのは、locateのxとyの総入れ替え
・N88-BASICでは、実数型も倍精度型も扱える上限は 1.7*10^38 で差がないため、
　変数は全て単精度実数に変更
　→実は覚えていなかったけど、FOR文のカウントに使うループ変数に倍精度型は
　　使えないのだとか。マニュアルに明記してあった
・私の趣味でファイル番号指定の「#1」の前には全て半角空白を入れた
　（たぶん、文法的には不要だと思うけど覚えていない）
・#11160で私が指摘した謎の２つのif文はdsp=1のほうだけ残した
・ファイル出力の際に、ループ内でいちいちOPEN/CLOSEするのは非効率的だと思う
　ので、最初で開いて最後に閉じるだけにした

今の所はそんな感じ。
とりあえず、机上デバッグでどこまでできるか。
忘れていることが多すぎるなぁ。

MOD と \ の有効範囲テストを NP2 でやってみました。
結果は 32767 を超えると オーバーフローエラーになりました。
また、N88BASICでは行番号が必要で、タブは使えなかったので
以下のようにプログラムを修正しました。

10 'N88mod.bas
14 print " input ";
20 input a                              '
30 OPEN "mod.dat" FOR append AS#1                       'ファイル出力
40 print "  a    MOD i ","2bytes "," Froat   "," a / i"
50 for i=2 to 5
60   bb=int((a/i-int(a/i))*i+.5)                        ' MOD 代替式
70   print a;"mod";i,
72   if a>32767 then print "over! ", else print a mod i, '32767 over
74   print bb,a/i 
80   print#1, a;"mod";i,
82   if a>32767 then print#1,"over! ", else print#1, a mod i, ' 32767 over
84   print#1, bb,a/i '
90 next i
100 print "  a     \  i","2bytes "," Froat   "," a / i"
110 for i=2 to 5
120   cc=int(a/i)                                       ' \ 代替式
130   print a;" \ ";i,
132   if a>32767 then print "over! ", else print a \ i, ' 32767 over
134   print cc,a/i  '
140   print#1,a;" \ ";i,
142   if a>32767 then print#1,"over! ", else print#1, a \ i, ' 32767 over
144   print#1,cc,a/i  '
150 next i
160 PRINT#1,""
170 CLOSE#1
180 '入力待ち
190 print "  push eny key  ";
200 a$=input$(1)
210 if a$="" then 180
220 end


エラーになるのと不正な結果になるのとどっちが良いかはともかく
MOD と \ の有効範囲は 普通は 32767 までのようですね。
だから素数のような桁数が多くなる計算は UBASIC などを使うのが良いのでしょうね。

> また、N88BASICでは行番号が必要で、タブは使えなかったので
> 以下のようにプログラムを修正しました。

うわぁ、ものすごく違和感がある見た目のプログラムになるんだな。
最大の理由は、おそらく、行番号のあるBASICにもかかわらず、コードが小文字だと
いうところからくるものだと思います。
行番号の不要なBASICなら小文字のコードでも全く違和感は感じないんですけどね。
どうやら、完全に、行番号のあるBASICは大文字、という感性に毒されている模様。
あと、もしかしたら些細かもしれないけど、行番号が等間隔ではないところにも、
まぁまぁ違和感を感じる。これは、同じN88であっても、インタプリタ型と違って
コンパイラ型の場合、テキストエディタでソースを書くことになるわけですから、
行番号の振り直しには手間がかかりますので、ある程度は仕方ないか。

ちょっとここで、行番号に関する昔話でも。
日本では、８ビットパソコンの草創期から、BASICのリストでは、行番号は10から
始まって10番ごと、というのがデファクト。なぜ10番ごとかというと、コードの追加
をする場合、その間の番号が使えるから、ということのようです。これは、日本に
BASICがやってくる前から、そういうのが普通だったらしい。
ただ、コードを追加すると当然、それは10番ごとにはならない。
そこで、BASICインタプリタにはRENUMというコマンドが用意されました。
renumberの略で、要するに行番号を振りなおしてくれるわけです。
これはNECのBASICにもシャープのBASICにもあったので、おそらく、東芝のBASICにも
あったのではないかなぁ。そしてたぶん、どこのものもほとんど同じだと思いますが、
NECの場合はデフォルトで、新しく付け直した行番号の開始番号は10からで、間隔も
10ごとに付け直してくれました。
コンパイラの場合は当然、こういう便利な機能があるわけではありませんから、番号
の振り直しは自前で人間がやらなければならないので、いろいろと面倒。

その後、BASICでもループなどをきちんとインデントするのが当たり前の時代になる
と、ここで問題になったのが、行番号の桁数。せっかくインデントを整えても、
90から100とか、990から1000といった行番号の桁数が変わるところでインデントが
崩れてしまう。そこでどうするかというと、例えば990行までに収まらないプログラム
なら1000行からはじめればよい、ということになりました。この部分、私ならなにも
10番間隔にこだわらず5番間隔でもいいじゃないか、それこそ最終的な完成形はもう
これ以上追加削除をしないということを強調する意味で1番間隔でいいのではないか、
と思うのですが、どうも世の中の大勢は10番間隔が好きみたい。
あと、間隔はいくつでもいいのですが、プログラムの最初から最後まで等間隔は
守るべき、というのも世間の多数派のようです。というか、RENUMコマンドを使えば
必然的に等間隔になるわけです。ここで例えば、いろいろとコードを追加した際に
その部分を追加したということを目立たせるためにあえて残すべき、という流派の
人もいたらしいですが、これはその後、少数派になりました。なぜかというと、
当時のBASICの編集画面だと、最近のテキストエディタと違い、それが何行目かと
いうことが表示されないわけです。ここで、例えば200行に GOTO 800 とあれば、
もし10番ごとの等間隔なら、ジャンプの飛び先はプログラムリスト上で60行先に
なるわけで、プリントアウトされた紙で追いかけやすい、という実利的な理由が
あったわけです。

と、いうことで。
もしBASICのプログラムをインタプリタに読み込ます機会があったら、RENUMコマンド
をかけた結果を保存しておくべきでしょう。

> うわぁ、ものすごく違和感がある見た目のプログラムになるんだな。
> 最大の理由は、おそらく、行番号のあるBASICにもかかわらず、コードが小文字だと
> いうところからくるものだと思います。

なるほど、そう言われればそんな感じもしますが、私はもう気にしてなかったので。(^^;

> 行番号の不要なBASICなら小文字のコードでも全く違和感は感じないんですけどね。
> どうやら、完全に、行番号のあるBASICは大文字、という感性に毒されている模様。

私はbasic歴が長いので、他の言語が小文字なのに違和感を感じました。今は無いですね。

> そこで、BASICインタプリタにはRENUMというコマンドが用意されました。
> renumberの略で、要するに行番号を振りなおしてくれるわけです。
> これはNECのBASICにもシャープのBASICにもあったので、おそらく、東芝のBASICにも
> あったのではないかなぁ。そしてたぶん、どこのものもほとんど同じだと思いますが、
> NECの場合はデフォルトで、新しく付け直した行番号の開始番号は10からで、間隔も
> 10ごとに付け直してくれました。

TBasicインタプリタは、RENUM 開始行番号,旧行番号,増分  となっています。
開始行番号は、新しくつける先頭の行番号の数値を指定します。
旧行番号は、付け替える初めの行を指定します。
でも私は使ったおぼえが無いですね。試したことはあるかもですが。

私の場合、行番号を振り直すと逆に頭の中のソースのイメージが壊れて混乱してしまう
気がしたので使わなかったのかもですね。再印刷もなかなか出来なかったし。(^^;

> と、ここで問題になったのが、行番号の桁数。せっかくインデントを整えても、
> 90から100とか、990から1000といった行番号の桁数が変わるところでインデントが
> 崩れてしまう。そこでどうするかというと、例えば990行までに収まらないプログラム
> なら1000行からはじめればよい、ということになりました。

これ、私はインデントなどしてなかったので、全く気になりませんでしたね。(^^;
だから今回のテストプログラムも １０番から付けてしまったのです。(^^;

> 必然的に等間隔になるわけです。ここで例えば、いろいろとコードを追加した際に
> その部分を追加したということを目立たせるためにあえて残すべき、という流派の
> 人もいたらしいですが、これはその後、少数派になりました。

どうやら私は少数派のようですね。(^^;

> 当時のBASICの編集画面だと、最近のテキストエディタと違い、それが何行目かと
> いうことが表示されないわけです。ここで、例えば200行に GOTO 800 とあれば、
> もし10番ごとの等間隔なら、ジャンプの飛び先はプログラムリスト上で60行先に
> なるわけで、プリントアウトされた紙で追いかけやすい、という実利的な理由が
> あったわけです。

私がNCプログラムを書いていた当時は、紙にプログラムを手書きしてからタイプライタに打ち込む形でした。
それが面倒に感じたのでパソコンに直接打ち込むスタイルを私が始めたのです。
紙テープに出力、印刷する時は行番号を N001 の形に自動変換していたので
もしかしたら行番号は RENUM していたかもしれません。もう忘れてしまいました。
私にとっては行番号は飾りでした。
＃　偉い人にはそれがわからんのですよ。

それで狭い画面で行番号を頼りに確認するのが煩わしくて、スクリーンエデイタを欲したのです。
当時スクリーンエデイタといえば、ワードマスターとか１０万以上もするようなのしか無かったと思います。
それで、結局自作のBASICインタプリタ用スクリーンエデイタもどきを作ったのでした。
そのために買ったのが、パソピア７だったという。(^^;
それが J3100SL に変わったころ、PSE や VZエデイタが出てきたのでした。

> もしBASICのプログラムをインタプリタに読み込ます機会があったら、RENUMコマンド
> をかけた結果を保存しておくべきでしょう。

その機会があればやってみたいと思います。
NP2 では、BASIC.COM は動かないみたいですが、これがインタプリタなのですよね。

> 私はbasic歴が長いので、他の言語が小文字なのに違和感を感じました。

私もBASIC歴はそれなりに長いのですがね。
複数言語に触れたというのが大きな違いでしょうか。

> TBasicインタプリタは、RENUM 開始行番号,旧行番号,増分  となっています。

これはN88-BASICでもN-BASICでも同じです。

> でも私は使ったおぼえが無いですね。試したことはあるかもですが。

ここは逆というか、私は使いまくりでした。
特に便利に使っていたのが、GOTOの飛び先の行番号が実在しないときにはエラーを
表示してくれる機能。行の追加・削除を頻繁に行う場合には、これは必須という
くらいに便利でした。

> 私の場合、行番号を振り直すと逆に頭の中のソースのイメージが壊れて混乱してしまう
> 気がしたので使わなかったのかもですね。再印刷もなかなか出来なかったし。(^^;

この辺はよく理解できない。ということは、私の場合はあまり行番号に依存しないで
ソースをイメージしていたのかな。つまり、私にとっては、行番号なんて単なる飾り
だった、とか。
＃私は偉くないから。

> これ、私はインデントなどしてなかったので、全く気になりませんでしたね。(^^;
> だから今回のテストプログラムも １０番から付けてしまったのです。(^^;

ここは私にとって大きな違い。
BASICでもバグの入りにくいコードを書こうと思っていたのでインデントしまくり。

> どうやら私は少数派のようですね。(^^;

別に少数派だからといって恥じる必要はさらさらありませんけどね。
ただ、多数派の言い分としては、そちらのほうがバグ取りがしやすい、というもの。
実際、私の経験からも、多数派のほうが正しそうな気がする。
ということで、バグ取りに悩まされたくないので、私も行番号をそろえていました。
あくまでも、実利優先、ということで。

宿直の際にものすごく多忙で。
１時間半ぐらいしか仮眠を取れなかったのですが、帰宅後すぐに実家から墓参り。
墓までの往路はいささか危なかったのですが、それでもおおむね安全運転。
墓掃除その他もろもろですっかり眠気は取れて、実家への復路はほぼ問題なし。

それはさておき、現在、実家です。

> > ・110行目のTHENの行番号は省略できたかもしれない。
> あ、ここが省略できるかは確認してこなかった。

省略できることを確認しました。
これでまた少しコードサイズが節減。

> ぼちぼち、移植を始めています。

ん〜、なんとなく動いているっぽい。
といいつつ、特にファイル書き込みの部分はろくに動作確認をしていないのだけど。

・N88-BASICだと、デフォルトは白黒モードなので、COLORでの色表示がうまくない。
　→おやくそくのCONSOLEでカラーモードにした。
・時間表示の部分、私の趣味で分と秒の間もコロンにした。
・エラー処理ルーチンの最後、CLSがあるとエラーで終わったことがわからなく
　なりそうだったので、これは除去した。

明示的にkonnoさんのコードに手を加えたのはこんなところかな。
あとは、各行にきちんと行番号をつけてやれば完成。
自宅に戻ったらアップロードしたいな。

> 別に少数派だからといって恥じる必要はさらさらありませんけどね。
> ただ、多数派の言い分としては、そちらのほうがバグ取りがしやすい、というもの。
> 実際、私の経験からも、多数派のほうが正しそうな気がする。
> ということで、バグ取りに悩まされたくないので、私も行番号をそろえていました。
> あくまでも、実利優先、ということで。

考えてみたら行番号必須のBASICインタプリタはプログラム言語全体では少数派なんですよね。
行番号付きのBASICインタプリタは作ったその場ですぐ実行できる初心者向きのお手軽な言語だと思います。
だから今でも教育用には使われているのでしょう。
本格的なプログラム言語には行番号は無いので、ラベルでジャンプしますよね。VZマクロも。

ということで、N88BASICなどと共用する場合を除いて行番号は無くす方向で行きたいと思います。
インデントは読みやすくなるのでなるべく心がけるようにします。

> 自宅に戻ったらアップロードしたいな。

アップロードしました。

tp://toshiki.la.coocan.jp/prime88.zip

期間限定。そのうちに削除します。

> といいつつ、特にファイル書き込みの部分はろくに動作確認をしていないのだけど。

こんな短いコードなのに、全ての条件分岐を網羅するホワイトボックステストは
行っていない。面倒になっちゃって。あぁ、横着。
とはいえ、画面表示とファイル出力の、最低限のチェックはしたので、少なくとも
一部はPC-98のDOS BASICで動作確認済み。
GOTOとGOSUBのジャンプはほとんどラベル化したので、行番号はなくても論理構造は
理解可能なはず。konnoさんのお持ちのTurboBasicなら、例えばcols.defのようなもの
を使って全ての行番号を削除しても、もしかしたらコンパイル可能かも。
ラベルの文法が違うからダメ、かな。

あと、もしかしたらほんのちょっとだけ高速化するかもしれない技術を一つ、導入
してみました。

1360     IF INT(I/2)*2 = I THEN *EXIT2
1380         WHILE (J<SQR(I)) AND (INT(I/J)*J<>I)

ここ、多くの処理系では割り算よりも掛け算のほうが速いと聞いたことがあるので、
割り算を２回するのではなく掛け算と割り算の組み合わせに変更してみました。
これでどのくらい早くなるかは測定していないからわからない。
処理系によっては、むしろ遅くなったりして。
konnoさんオリジナルのロジックよりは、使う変数も少なくなっている分だけ速く
なってるかもしれないけど、こんなもん、最近のコンパイラなら最適化してくれる
でしょ、という範囲かもしれない。
あとはまぁ、PC-88などの８ビットマシンならDMAを停めるとか、ナノピコ秒単位で
速度を稼ぐためにインデントを全て削除してマルチステートメント化するとか、
他にもいろいろと思いつく技はいくつかありますけどね。そこまではしていません。

> アップロードしました。
> tp://toshiki.la.coocan.jp/prime88.zip

早速落として NP2 で動かしてみました。
#11162 で
> BASIC.COM がコンパイラなんですね。
なんて書きましたが、正しくは BACICC.COM でした。
BASIC Compiler ということなのですね。(^^;

B.BAT
basicc %1.bas %1.exe %1.lib
%1.exe

これを見て間違いに気が付きました。(^^;

さて、実行してみてまず気が付いたのは、変数 MAX の表示が
1E+08
になっていました。浮動小数点の表示形式ですね。

1070 MAX=100000000#

えーと、定数の末尾に # を付けているのは倍精度指定なのですか？
変数 MAX は単精度のように思われます。

> > といいつつ、特にファイル書き込みの部分はろくに動作確認をしていないのだけど。

オプション指定 1 で ファイルがキチンと出来ました。
ただ、素数の個数が私のと違いますね。

p1000.DAT
Number.1000	  0: 0' 0   Prime Number = 168 

n1000.DAT　　N88
Number.1000	  0: 0: 1   Prime Number = 169 

どちらかがカウント数を間違っているかと思い、VZで比較したら

p1000.DAT
 167 
 173 

n1000.DAT　　N88
 167 
 169 		※ この行が多い
 173 

169 は、13*13=169 なので、素数では無いと思います。
今日は眠いのでこれ以上の調査は明日以降ということで。(^^;

> えーと、定数の末尾に # を付けているのは倍精度指定なのですか？
> 変数 MAX は単精度のように思われます。

おっしゃるとおりです。
変数を全て単精度指定に変更するときに修正をもらしたようです。
ただ、こちらは大勢に影響がありませんが

> 169 は、13*13=169 なので、素数では無いと思います。

こっちは大問題ですね。仕様どおりの挙動をしないのですから。
倍精度から単精度に精度を落としたことが悪いのか、それとも割り算と掛け算の
誤差の問題か。
いつ調査できるかわかりませんが、解決は図りたいと思います。

> > 169 は、13*13=169 なので、素数では無いと思います。
> 
> こっちは大問題ですね。仕様どおりの挙動をしないのですから。
> 倍精度から単精度に精度を落としたことが悪いのか、それとも割り算と掛け算の
> 誤差の問題か。

私は当初 NP2 のCPUエミュレーション等のバグを疑いました。
それで、anex86 でも試したのですが、結果は同じ。98NEXT では固まってしまいました。

次に疑ったのが、BASICコンパイラが壊れていないか。
1988/08/24  00:00            61,440 BASICC.COM
中身が壊れているることもありうるので、98実機での結果が知りたいところですね。

条件を色々変えて試しても結果は変わらなかったのですが、ひとつだけ

N88P.BAS
100 INPUT N
110 IF N MOD 2=0 THEN 120 ELSE *ELSE1
120     IF N=2 THEN PRINT "素数" ELSE PRINT "合成数"
130     GOTO *ENDIF1
140 *ELSE1
150     I=3
160     WHILE (I<=SQR(N)) AND (N MOD I<>0)
170         I=I+2
180     WEND 
190     IF I<=SQR(N) THEN PRINT "合成数" ELSE PRINT "素数"
200 *ENDIF1
202 input a
210 END

このプログラムでは、169 は「素数」と表示されます。
ところがオリジナルを若干修正した以下

PN88.BAS
100 'pn88.bas 
110  defdbl a-z                                 '倍精度指定
1000 INPUT n
1010 IF (n MOD 2)=0 THEN IF n=2 THEN PRINT "素数" ELSE PRINT "合成数"
1020 j!=sqr(n) 'ELSE
1030   FOR i!=3 TO SQR(n) STEP 2
1040     IF n MOD i!=0 THEN *EXIT1 
1050   NEXT i!
1052   *EXIT1
1060   IF i!<=SQR(n) THEN PRINT "合成数";i!;j! 
1062   IF i!>SQR(n) THEN PRINT "素数";i!;j!
1070 input a 'END IF
1080 END

このプログラムでは、169 は「合成数」と表示されます。
違いは、変数全体を倍精度にし、FOR 文の変数を単精度にしただけかな。
＃　うーん、これを反映させても改善しない。何故だー！　(;_;)

> ここ、多くの処理系では割り算よりも掛け算のほうが速いと聞いたことがあるので、
> 割り算を２回するのではなく掛け算と割り算の組み合わせに変更してみました。
> これでどのくらい早くなるかは測定していないからわからない。
> 処理系によっては、むしろ遅くなったりして。

なるほど、そういうやり方もあるのですね。
このプログラムで 10000 指定の実行結果は

Number.10000	  0: 0:30   Prime Number = 1233 

このソースを私の FOR 文のに置き換えてみた結果は

Number.10000	  0: 0: 8   Prime Number = 1233 

実行時間が短縮されました。
コンパイラでは最適化でインタプリタと違う結果になるようです。
どこがどう効いたかわからないので、変更ソースを上げます。

1320 *START
1330 TM$=TIME$
1340 I=2:GOSUB *PRINT1
1350 FOR I=3 TO N                                        '★
1360  ' IF INT(I/2)*2 = I THEN *EXIT2                    '☆
1362   i2=i/2:i3=int(i/2):IF i2=i3 THEN goto *EXIT2      ' 合成数
1370 '    J=3                                            '☆
1380 '    WHILE (J<SQR(I)) AND (INT(I/J)*J<>I)           '☆
1382      FOR J=3 TO int(SQR(I)) STEP 2                  '★ 偶数をスキップ
1390 '      J=J+1                                        '☆
1392        I2=I/J:I3=INT(I/J):IF I2=I3 THEN GOTO *EXIT1 '★ 合成数
1400 '      WEND                                         '☆
1402      NEXT J                                         '★
1404      *EXIT1                                         '★
1406 '     if i=169 then print "   13 =";i;sqr(i);j:goto *exit2
1408 '     IF i=169 then if J=SQR(I) THEN *EXIT2
1410      IF SQR(I)<J THEN GOSUB *PRINT1
1420   *EXIT2
1430 NEXT I
1440 I=I-1

ちなみに、VGA版の結果は

Number.10000	  0: 0' 1   Prime Number = 1229 

結果の素数の数が 4 違いますね。

---  N88  --- 
 169 	13*13
 5041 	71*71
 6241 	79*79
 9409 	97*97

10000 で 4 箇所 合成数が含まれています。
何が原因かわからないです。

不具合の原因がわかりました。
SQR() 関数の結果判定に問題が有ったようです。

PRIME98.BAS

1320 *START
1330 TM$=TIME$
1340 I=2:GOSUB *PRINT1
1350 FOR I=3 TO N                                   '
1360   i2=i/2:i3=int(i/2):IF i2=i3 THEN *EXIT2      ' 合成数
1370      j2=int(SQR(I))                            '
1380      FOR J=3 TO j2 STEP 2                      ' 偶数をスキップ
1390        I2=I/J:I3=INT(I/J):IF I2=I3 THEN *EXIT2 ' 合成数
1400      NEXT J                            
1410    IF J>SQR(I)+.0001 THEN GOSUB *PRINT1        '★
1420 *EXIT2
1430 NEXT I
1440 I=I-1

このように、SQR() に +0.0001 を足したら問題が解消されました。
計算精度の問題か、最小桁が切り捨てられているのでしょうか。
いくつ足せばいいのか桁を変えて試してみました。

1410    IF J>SQR(I)+.000001 THEN GOSUB *PRINT1		ng
Number.10000	  0: 0:29   Prime Number = 1233 
169  5041  6241  9409 	ng

1410    IF J>SQR(I)+.00001 THEN GOSUB *PRINT1		ng
Number.10000	  0: 0:30   Prime Number = 1232 
5041  6241  9409 	ng

1410    IF J>SQR(I)+.0001 THEN GOSUB *PRINT1		ok
Number.100000	  0: 2:29   Prime Number = 9592 

どうも N88BASIC の問題のような気がしますが、実機でどうなるか知りたいですね。

あ、これはまずい。

> このプログラムで 10000 指定の実行結果は
> Number.10000	  0: 0:30   Prime Number = 1233 
> このソースを私の FOR 文のに置き換えてみた結果は
> Number.10000	  0: 0: 8   Prime Number = 1233 
> 実行時間が短縮されました。

この差は大きすぎる。プログラムに間違いがあるから。

> 1382      FOR J=3 TO int(SQR(I)) STEP 2                  '★ 偶数をスキップ
> 1390 '      J=J+1                                        '☆

ここのところ、STEP 2 なんだから、J=J+2 でなければならない。
単純にループ回数が2倍になってしまう。
ということで、おそらく、30秒は15秒ぐらいまで短縮できるはずだけど、それでも
やっぱり8秒までは縮まらないと思う。

SQR関数の精度のほうは、どうしようかな。

SQRの計算を自前で出来ないか検索してみました。
「本の虫」のサイトの「平方根のアルゴリズム 」
https://cpplover.blogspot.com/2010/11/blog-post_20.html

ここがわかりやすかったのでここから引用します。
-----------------------------------------------------------

ここで使うのは、バビロニア人の方法（Babylonian method）と呼ばれている、歴史あるアルゴリズムである。
この方法は、手動でも、プログラミングでも、非常に簡単に計算できる、大変便利で汎用的なアルゴリズムである。
しかも、速度もそれほど遅くない。 

double sqrt( double s )
{
    double x = s / 2.0 ; // Is there any better way to determine initial value?
    double last_x = 0.0 ; // the value one before the last step

    while ( x != last_x ) // until the difference is not significant
    { // apply Babylonian method step
        last_x = x ;
        x = (x + s / x) / 2.0 ;
    }
    
    return x ;
}

-----------------------------------------------------------

これを TurboBasic に置き換えたテストが

3000 ' SQR1.BAS
3010 'defdbl a-z
3020 screen 0
3030 cls
3040 input s
3050 x = s / 2.0  '; // Is there any better way to determine initial value?
3060 lastx = 0.0 '; // the value one before the last step
3070 '    while ( x != lastx ) '// until the difference is not significant
3080 'loop1:
3090        lastx = x 
3100        x = (x + s / x) / 2.0 
3110   if   x <> lastx  then 3080 'loop1
3120   print "SQR(";s;")=";x,lastx
3130   input a
3140 end

3020行をコメントにすれば N88BASIC でも動作します。
これをサブルーチンにして PRIME88.BAS に貼り付けて

1320 *START
1330 TM$=TIME$
1340 I=2:GOSUB *PRINT1
1350 FOR I=3 TO N
1360     IF INT(I/2)*2 = I THEN *EXIT2
1370         J=3
1375         s=I:gosub 3050:s=xx                '★
1380         WHILE (J<s) AND (INT(I/J)*J<>I)    '★
1390             J=J+1                          '★★
1400         WEND
1410         IF J>s THEN GOSUB *PRINT1          '★
1420     *EXIT2
1430 NEXT I
1440 I=I-1

この結果は
Number.10000	  0: 0:14   Prime Number = 1229 

おお、素数が合ってるし、時間が半分になりました。
SQR()関数を2回実行していたのをサブルーチン1回にしたのが効いたみたいです。

さらに、★★ のところを
1390             J=J+2                          '★★
このように +2 に変更した結果
Number.10000	  0: 0: 9   Prime Number = 1229 

おお、時間がさらに短縮して、FOR文のループとほぼ同じになりました。
ちなみに FOR文のソースにこのサブルーチンを組み込んだら
Number.10000	  0: 0:11   Prime Number = 1229 

２〜３秒遅くなりましたね。これが関数とサブルーチンの速度差と思われます。
思ったよりも差が無いなぁ、というのが感想です。(^^;

素数のネタはこの辺でしまいにしたいところですね。

> これを TurboBasic に置き換えたテストが

えと、whileのループをifのジャンプに変更したのはなぜでしょうか。
こちらのほうが速いのですか？

> 素数のネタはこの辺でしまいにしたいところですね。

そうですね。
明日、３１日に実家へ行くので、時間が取れたら実機でいくつか試したいところ。
実は、父の命日が３１日なんですよ。
ただ、日が近いということで、多くの場合、墓参りはお彼岸に集約されています。
天候だとか諸事情でお彼岸に墓参りできないときだけ命日に墓参り、と言う感じ
なのですが、まぁいろいろと存在しない事情をでっち上げて実家に顔を出すところ
まではアポイント済み。ただ、時間が取れるかどうかは別問題なんで。
 

実家に来ています。
まず、先日アップしたあのプログラムをそのまま実行したのですが

> Number.1000	  0: 0' 0   Prime Number = 168 

うちのN88-BASICでは、素数の数が168になりました。
169は素数としてカウントされませんでした。
どうやらSQR関数、うちの環境のほうが精度が高いらしい。
ちなみに、ファイル出力ではなく画面表示で、所要時間は0秒〜1秒くらい。
あまり違いはないですね。

とりあえず時間切れ、続きは後ほど。

続いて、先日上げたプログラムのまま、すなわち、SQR関数の部分もいじらず、
変数Jのカウントアップも1ずつのままで10000までの結果。

> Number.10000	  0: 0' 1   Prime Number = 1229 

素数の数は1229と出ました。やっぱりうちの環境では誤差がないみたい。
ちなみに、所要時間は、画面表示だと12秒、ファイル出力だと13秒。
これはいささか直感と記憶に反している。
記憶だと、画面表示のほうがスクロールアップに時間がとられるので遅くなったはず
なのですがね。ま、でも、誤差の範囲。

次、変数 J のカウントアップを J=J+2 としたら所要時間は7秒まで短縮。
やっぱりループ回数が２倍というのは大きかった模様。
素数の数は1229なので、計算誤差の問題もないですね。

ところで、うちのBASICインタープリタは1987年製のVer5.0というやつです。
konnoさんのところの版数とかはわかりますか？

実家での検証、最後。

> ここ、多くの処理系では割り算よりも掛け算のほうが速いと聞いたことがあるので、
> 割り算を２回するのではなく掛け算と割り算の組み合わせに変更してみました。
> これでどのくらい早くなるかは測定していないからわからない。

メインのループを

1350 FOR I=3 TO N
1360     IF INT(I/2)*2 = I THEN *EXIT2
1370         J=3:I2=I/J:I3=INT(I/J)
1380         WHILE J<SQR(I) AND I2<>I3
1390             J=J+2:I2=I/J:I3=INT(I/J)
1400         WEND
1410         IF J>SQR(I) THEN GOSUB *PRINT1
1420     *EXIT2
1430 NEXT I

こうやって、割り算2回で20000までの素数を求めたら21秒で2262個。
元のままの、割り算と掛け算だと17秒、2262個。
うん、やっぱりうちでは、誤差というには差が大きいくらい、掛け算のほうが早い
模様。


以上、レス元が分散して申し訳ありませんが、実家での検証３連発でした。

> えと、whileのループをifのジャンプに変更したのはなぜでしょうか。
> こちらのほうが速いのですか？

私は while文をあまり使わないので、無意識に 慣れた IF文に変えてしまってました。(^^;
オリジナルのソースに wend を入れるだけでしたね。(^^;

#11179 で書きましたが
> ちなみに FOR文のソースにこのサブルーチンを組み込んだら
> Number.10000	  0: 0:11   Prime Number = 1229 
> ２〜３秒遅くなりましたね。これが関数とサブルーチンの速度差と思われます。

同じ条件では、while文の方が速いと思われます。
そこで、このサブルーチンの while と FOR で比較してみました。

FOR文     Number.100000   0: 2:51   Prime Number = 9592 
WHILE文   Number.100000   0: 2:47   Prime Number = 9592 

１０万で4秒の差でした。思ったよりも差が小さかったですね。
SQR １回あたり７〜１０回程度のループで済んでいるから差が小さいのでしょう。

> なのですが、まぁいろいろと存在しない事情をでっち上げて実家に顔を出すところ
> まではアポイント済み。ただ、時間が取れるかどうかは別問題なんで。

お手間を取らせて申し訳ないですが、よろしくお願いします。

ここにまとレスします。

> > Number.1000	  0: 0' 0   Prime Number = 168 
> うちのN88-BASICでは、素数の数が168になりました。
> 169は素数としてカウントされませんでした。
> どうやらSQR関数、うちの環境のほうが精度が高いらしい。

これは驚きです！　ということは、９８エミュの問題か、ファイルが壊れているかですね。

> ちなみに、所要時間は、画面表示だと12秒、ファイル出力だと13秒。
> これはいささか直感と記憶に反している。

TurboBasic でも同じような結果です。画面表示は遅いというのは思い込みなのでしょう。

> ところで、うちのBASICインタープリタは1987年製のVer5.0というやつです。
> konnoさんのところの版数とかはわかりますか？

88-BASIC(86) Compiler version 6.0 
1988/08/24  00:00            61,440 BASICC.COM

うちで使用したコンパイラ版はこれですね。

> こうやって、割り算2回で20000までの素数を求めたら21秒で2262個。
> 元のままの、割り算と掛け算だと17秒、2262個。
> うん、やっぱりうちでは、誤差というには差が大きいくらい、掛け算のほうが早い
> 模様。

なるほど。やはり掛け算が速いのですね。

> 以上、レス元が分散して申し訳ありませんが、実家での検証３連発でした。

お忙しい中色々検証していただき、ありがたいです。
N88BASICの精度疑惑も晴れたので、９８エミュの検証が必要そうですね。

以前N88BASICが動かなかったT98-NEXT で再挑戦しました。
コンパイラ版が動かなかったのはメモリ不足だったようです。
ATOK8がメインメモリに居座っていたので削除したら動きました。(^^;
ただし、BATのオプションが効かなくて、ソースファイル名を手打ちしました。(^^;
結果はほかのエミュと同じで駄目でした。

インタプリタも、実機ROMにチェックを入れたら動きました。
結果はやっぱり駄目でした。
98エミュは全滅です。

うーむ、このバージョンの N88BASIC に問題がある可能性があるのでしょうか。

> これは驚きです！　ということは、９８エミュの問題か、ファイルが壊れているか

エミュの問題、というのは考え易いところです。
が、ファイルの破壊となった場合、そんな精度に関係するところが絶妙に壊れる、
というのはなかなか考えにくい。
ただ、N88(86)では使っていない技術だとは思いますが、いくつかの処理系では、
関数の速度と精度向上のため、全てを計算で求めるのではなく、大きな定数表を
使う場合がある、と聞いたことはあります。とはいっても超巨大というほどの表
ではなく、引数のいくつかに分解して、それぞれの結果を足すとかかけるとかで
速度と精度を両立させます。
その場合は、その定数表の一部だけが間違っているとか精度が足りないことが発生
しうるわけです。でも、これって、三角関数とか対数関係の関数で使うワザだった
ような気がする。
平方根でも使うことがあるのかなぁ。

> 88-BASIC(86) Compiler version 6.0 
> 1988/08/24  00:00            61,440 BASICC.COM

これ、頭のNが欠けているのは転記ミスですよね。
実は、私の記憶でも、88年のVer6が最終版、ということになっているからです。
そして私の手元には87年のVer5しかないわけですが、バージョンアップするかどうか
という判断に際して、どこが変わったかという情報がなくてバージョンアップを
しなかった、というおぼろげな記憶があります。
ところでkonnoさんのところでは、TurboBasicではなく、N88BASICのコンパイラと
インタプリタで同じ結果になります？
あと、インタプリタとコンパイラでバージョンは同じですか？

こちらの掲示板での過去ログ表示で気がつきました。
[全部表示 会議室風]のリンクを押して表示される発言の中に、そのログのトップの
ツリーのルートの発言が含まれていないようです。
具体的には

過去ログ26では#10734
過去ログ25では#10632
過去ログ24では#10229
・・・
過去ログ2では#974
過去ログ1では#418

が表示されないようです。
ご確認をお願いします。

> その場合は、その定数表の一部だけが間違っているとか精度が足りないことが発生
> しうるわけです。でも、これって、三角関数とか対数関係の関数で使うワザだった
> ような気がする。
> 平方根でも使うことがあるのかなぁ。

原因が分かったような気がします。
N88BASIC(86) では、FOR文が倍精度では動かないので単精度でやって NG だったのですが
1030 defdbl A-Z　と変数を倍精度にし、FOR文の I だけ I! で単精度でやってみました。

1340 I=2:GOSUB *PRINT1
1342 i=3
1350 FOR I!=3 TO N
1360     IF INT(I/2)*2 = I THEN *EXIT2
1370         J=3
1380         WHILE (J<SQR(I)) AND (INT(I/J)*J<>I)
1390             J=J+1
1400         WEND
1410         IF J>SQR(I) THEN GOSUB *PRINT1
1420     *EXIT2
1422 i=i+1
1430 NEXT I!
1440 I=I-1

他は変えていませんが、このプログラムでは 169 が表示されず、正常になりました。
＃ 汚れていたのは SQR(I) だったんです。（By now shika）

変数 I が倍精度だと数値の比較が正常なのに、単精度だと 表示は整数でも内部の計算がズレる模様。
想像ですが、例えば比較計算は倍精度で、表示は単精度に丸められているとか。

> > 88-BASIC(86) Compiler version 6.0 
> > 1988/08/24  00:00            61,440 BASICC.COM
> これ、頭のNが欠けているのは転記ミスですよね。

はい、そうです。失礼しました。m(__)m

> ところでkonnoさんのところでは、TurboBasicではなく、N88BASICのコンパイラと
> インタプリタで同じ結果になります？

同じ結果になります。上の実験はインタプリタではしてないですが。

> あと、インタプリタとコンパイラでバージョンは同じですか？

同じだと思います。起動メッセージが同じなので。
日付は少し違いますね。

> こちらの掲示板での過去ログ表示で気がつきました。
> [全部表示 会議室風]のリンクを押して表示される発言の中に、そのログのトップの
> ツリーのルートの発言が含まれていないようです。

げげげ、・・・・・・

確認しました。しばしお待ちください。m(__)m

「妙だな」というのは、どこぞの小学生のよく言うせりふですが、それはさておき。
#11164にも書きましたが、N88だと単精度でも倍精度でも上限は同じです。
また、演算速度が単精度の方が速いという理由から私は全て単精度でやっているの
ですが、konnoさんが倍精度を選ばれている理由は何ですか？
他のBASICだと上限が違うとかあるのでしょうか。

さて、私のコードでは全て単精度でやっています。なので、精度変換の問題は出ない
はず。実際、うちでは問題が出ていません。
でも、#11173では、同じコードで問題が出ているということです。
なので、これは精度変換の問題ではないと思われます。


> 他は変えていませんが、このプログラムでは 169 が表示されず、正常になりました。

このプログラムだと、単精度の I! と倍精度の I の両方でカウント処理が発生します。
倍精度の I だけ使って WHILE のループにしたほうがいいような気がします。


> 想像ですが、例えば比較計算は倍精度で、表示は単精度に丸められているとか。

N88のマニュアルでは、異なる型同士での演算の場合は高い精度のほうに合わせて
行われるとのこと。これは比較演算でも同じはず。

で、私の疑っていた、konnoさんのところのコンパイラとインタプリタのバージョン
違いという疑いは晴れたので、するとあとは、私のところのバージョンとkonnoさん
のところのバージョンが異なる、という問題は残ります。
とりあえず、出発点は#11173。同じコードなのに結果が異なる、ということ。
あ、重要な問題がある。
私がもしかしたら、アップしたのとは異なるコードを実行していた可能性。
実はこの可能性が一番高いかも。

自分で実験できないのにあれこれ言って申し訳ありません。

> 条件を色々変えて試しても結果は変わらなかったのですが、ひとつだけ
> N88P.BAS
> ところがオリジナルを若干修正した以下
> PN88.BAS

N88P.BASとPN88.BAS、konnoさん的には「若干修正」かもしれませんが、内部的には
もしかしたら大幅な修正かもしれません。
そこで結果を教えていただきたいのが、

> PN88.BAS
> 110  defdbl a-z                                 '倍精度指定

ここを単精度指定にしたらどうなるか、ということ。
とても興味があります。

> > [全部表示 会議室風]のリンクを押して表示される発言の中に、そのログのトップの
> > ツリーのルートの発言が含まれていないようです。
> 確認しました。しばしお待ちください。m(__)m

ううう、3日間腐海暗闇の中で藻掻いていました。(;_;)

wforum.cgi を色々弄ってみましたがどうやってもルート発言が表示されません。(>_<)
仕方がないので過去ログの先頭に改行を追加してみたら表示されました。
うげぇ、今までの苦労は何だったんだ・・・・

唯の改行だとツリー表示にゴミが表示されるので、現行ログの形式でダミーを入れました。

0001<>00.00.00.00<>1097421569<>
番号　IPアドレス　書き込み時間（古ければスキップ？）

このように、書き込み時間が古ければ自動的にスキップしてくれるようです。
この処理をどこでやっているのかはわかりません。
色々弄った版はツリー表示がおかしくなったので、修正前のに戻したら直りました。

結局 cgi は弄らずに、過去ログ形式を変更することで解決しました。(-_-;) ﾔﾚﾔﾚﾀﾞｾﾞ
何かおかしなところに気が付いたら教えてください。m(__)m

> #11164にも書きましたが、N88だと単精度でも倍精度でも上限は同じです。
> また、演算速度が単精度の方が速いという理由から私は全て単精度でやっているの
> ですが、konnoさんが倍精度を選ばれている理由は何ですか？

N88 は FOR文のカウントに倍精度が使えない制限があるようです。
それで単精度でやったら問題が出たので、倍精度でやり直してみたという経緯です。

> さて、私のコードでは全て単精度でやっています。なので、精度変換の問題は出ない
> はず。実際、うちでは問題が出ていません。
> でも、#11173では、同じコードで問題が出ているということです。
> なので、これは精度変換の問題ではないと思われます。

私は N88BASIC の特定のバージョン（V6.0）の問題なのではないかと疑っています。
もちろん ９８エミュの問題の可能性も排除できないので実機で確認したいのです。

> > 他は変えていませんが、このプログラムでは 169 が表示されず、正常になりました。
> このプログラムだと、単精度の I! と倍精度の I の両方でカウント処理が発生します。
> 倍精度の I だけ使って WHILE のループにしたほうがいいような気がします。

私は while の入れ子は特に間違えやすいので、FOR文でやりました。
結果は同じになると思います。

> N88のマニュアルでは、異なる型同士での演算の場合は高い精度のほうに合わせて
> 行われるとのこと。これは比較演算でも同じはず。

なるほど、それで謎の挙動がわかったような気がします。
比較の実験結果をあげてみます。

> > PN88.BAS
> > 110  defdbl a-z                                 '倍精度指定
> 
> ここを単精度指定にしたらどうなるか、ということ。
> とても興味があります。

丁度良いテストプログラムを作ったので上げます。

3000 ' SQR88.BAS
3010 'defdbl a-z
3012 defsng a-z
3020 'screen 0
3030 cls
3040 input s
3042 OPEN "SQR.dat" FOR OUTPUT AS #1
3046 cc=0
3050 x = s / 2.0  '; // Is there any better way to determine initial value?
3060 lastx = 0.0 '; // the value one before the last step
3070 'while ( x != lastx ) '// until the difference is not significant
3090      lastx = x 
3100      x = (x + s / x) / 2.0 
3112      cc=cc+1
3114      print x;lastx,cc
3116      print#1, x;lastx,cc
3110  if   x < lastx  then 3070
3120  print "SQR(";s;")=";x,lastx,cc
3122  print#1, "SQR(";s;")=";x,lastx,cc
3124  close
3130  input a
3140 end

このプログラムで、TurboBasic の結果は

単精度
 43.25              84.5                   1 
 23.57875633239746  43.25                  2 
 15.37311267852783  23.57875633239746      3 
 13.18316555023193  15.37311267852783      4 
 13.00127220153808  13.18316555023193      5 
 13                 13.00127220153808      6 
 13                 13                     7 
SQR( 169 )= 13   13      7 回

倍精度
 43.25              84.5                   1 
 23.57875722543352  43.25                  2 
 15.37311286945074  23.57875722543352      3 
 13.18316604902914  15.37311286945074      4 
 13.00127244856782  13.18316604902914      5 
 13.00000006226796  13.00127244856782      6 
 13                 13.00000006226796      7 
 13                 13                     8 
SQR( 169 )= 13   13       8 回

倍精度の方が収束するのに１回多く掛かっています。
どちらでも計算は倍精度でやっているのがわかります。
一方、N88BASIC の結果は

単精度
 43.25            84.5             1 
 23.5788          43.25            2 
 15.3731          23.5788          3 
 13.1832          15.3731          4 
 13.0013          13.1832          5 
 13               13.0013          6 
 13               13               7 
SQR( 169 )= 13  13    7 回

倍精度
 43.25              84.5                   1 
 23.57875722543353  43.25                  2 
 15.37311286945074  23.57875722543353      3 
 13.18316604902914  15.37311286945074      4 
 13.00127244856782  13.18316604902914      5 
 13.00000006226796  13.00127244856782      6 
 13                 13.00000006226796      7 
 13                 13                     8 
 13                 13                     9 
SQR( 169 )= 13   13      9 回

おや、単精度の場合は SQR の計算も単精度なのか、それとも表示だけなのか？
倍精度では収束したのにさらにもう１回多く計算しています。？？？
この結果は、WHILE 文にしても同じでした。
そして、単精度の時だけ 169 が素数と誤判定しているのです。

このことから私は、「＞」や「＞＝」などの比較式で単精度の時だけ誤差が出ていると疑ったのです。
V6.0に問題が有るかどうかは、実機で確認する以外にわからないと思います。

> 仕方がないので過去ログの先頭に改行を追加してみたら表示されました。

この現象から見ると、過去ログと現行ログでの分岐に問題がありそうですね。
まさかと思いますが、そもそも分岐していない、とか。

> この処理をどこでやっているのかはわかりません。

もともとこのルーチン、作ったのはkonnoさんですから。
作った本人がわからないようではどうしようもありません。
もう大丈夫だとは思いますが、不要なコメント、とかいう目くらましにやられて
いる、ということはないでしょうか。

とりあえず、今のところは問題ないような感じです。

> N88 は FOR文のカウントに倍精度が使えない制限があるようです。

そです。
これはマニュアルにも明記されている仕様です。

> それで単精度でやったら問題が出たので、倍精度でやり直してみたという経緯です。

なるほど、いきさつが理解できました。

> 私は N88BASIC の特定のバージョン（V6.0）の問題なのではないかと疑っています。

現時点では、私もこの線が濃厚だと思っております。

> 私は while の入れ子は特に間違えやすいので、FOR文でやりました。

BASICを極めたいのならWHILEは避けて通れません。
私もかなり錆付いてはいますが、まだkonnoさんより私のほうが、BASICに関しては
一日の長がありそうな感じ。

> 結果は同じになると思います。

いや、結果の問題ではなく速度の問題。
加算するのはループカウンタだけでいいでしょう、ということです。

> 3000 ' SQR88.BAS

これ、あとで私も検証してみます。最短で今日の午後。

> このプログラムで、TurboBasic の結果は

> どちらでも計算は倍精度でやっているのがわかります。

ダウト。

> 単精度
>  43.25              84.5                   1 
>  23.57875633239746  43.25                  2 

> 倍精度
>  43.25              84.5                   1 
>  23.57875722543352  43.25                  2 

もうここですでに値が異なります。
すなわち、表示だけ倍精度、という可能性が濃厚。

> おや、単精度の場合は SQR の計算も単精度なのか、それとも表示だけなのか？

N88の場合、仕様では、引数の型が結果の型、ということになっています。
このプログラムでは、2.0 という単精度型で割り算をしています。
ここを 2# としてみたら、もしかしたら違いが出てくる可能性があります。

実家に来ています。
うちの母、風邪気味だというのに買い物に行きたいのだとか。
母と同居しているうちの弟、免許すら持っていないので、その手の案件は私が対応。
ということで、まもなく連れ出されてしまいますが、その前に。

まず、うちのN88BASIC、コンパイラはありません。
タイムスタンプは以下。

N88BASIC EXE       161,280 87-10-30    0:00
N88BASIC LIB       178,176 86-08-14   13:51

ん〜、ライブラリのほう、もしかしたらバージョンが古いかも。
そして、この環境で

> 丁度良いテストプログラムを作ったので上げます。
> 3000 ' SQR88.BAS

このプログラムを load して list をみたら、

3050 X = S / 2!  '; // Is there any better way to determine initial value?
3100      X = (X + S / X) / 2! 

と、自動で変換されてしまっていました。
もしかしたらkonnoさんのところでも、この手の意図せざる自動変換が発生している
かもしれません。当然、コンパイラのほうでも。
一度、インタプリタのほうで list をたたいて、自動変換の有無を確認されたほうが
いいでしょう。

そして、読み込ませてすぐに run させたら、あれ？
konnoさんのところと実行結果が異なる。
何が異なるって、途中経過が一切表示されない。妙だな。
よくリストを見たら、結果表示がループの外に出ている。
こういうトリックはやめて欲しいけど、でも私も良くやるので人のことは言えない。
とりあえず、3110行の if 文を3123行に持ってきて、ここで時間切れ。

続きは帰宅後。
何時ぐらいになるかなぁ。

> 続きは帰宅後。

続きです。

> よくリストを見たら、結果表示がループの外に出ている。
> こういうトリックはやめて欲しいけど、でも私も良くやるので人のことは言えない。

違う。
結果表示が改行されず、同一行に上書きされているような感じ。
つまり、トリックは私が仕掛けた、ということで。
大変失礼しました。
そして、私が悪かったにもかかわらず

> とりあえず、3110行の if 文を3123行に持ってきて、ここで時間切れ。

こんなことをやったから、出力書式がめちゃくちゃ。
とりあえず、konnoさんと同じような書式にVzでそろえた結果です。

単精度2.0
 43.25  84.5   1 
 23.5788  43.25              2 
 15.3731  23.5788            3 
 13.1832  15.3731            4 
 13.0013  13.1832            5 
 13  13.0013   6 
 13  13        7 
SQR( 169 )= 13               13            7 

倍精度2.0
 43.25  84.5   1 
 23.57875722543353  43.25    2 
 15.37311286945074  23.57875722543353      3 
 13.18316604902914  15.37311286945074      4 
 13.00127244856782  13.18316604902914      5 
 13.00000006226796  13.00127244856782      6 
 13  13.00000006226796       7 
 13  13        8 
 13  13        9 
SQR( 169 )= 13               13            9 

念のため、2! のところを全て 2# にしてみたけど、結果は同じでした。

どうも、見たところ、結果は全て同じ。
収束したのに１回多くループを回っているところも同じ。
にもかかわらず、うちの環境では、169は素数にならない。
まだアップしたままのprime88.zipを再度落としてみて、ファイル比較して同じもので
あることも確認済み。そして、名前を変えて、新しく落としたほうを実行してみて
169が素数にならないことも確認済み。

何じゃこりゃ。

> > 仕方がないので過去ログの先頭に改行を追加してみたら表示されました。
> 
> この現象から見ると、過去ログと現行ログでの分岐に問題がありそうですね。
> まさかと思いますが、そもそも分岐していない、とか。

うう、そのまさかでした。(>_<)

	open(IN,"$logfile") || &error("Open Error: $logfile");
	$top = <IN>;

こうなっていたところを
#	$top = <IN>;
	$top = <IN> if ($in{'act'} ne "past");

こう変更したら今までの過去ログファイルのままでも正常になりました。
うう、これも試していたのに弄りすぎておかしくなっていたようです。(>_<)
アドバイスありがとうございました。m(__)m

訂正、ではないような。
補足、かな。

> > よくリストを見たら、結果表示がループの外に出ている。
> > こういうトリックはやめて欲しいけど、でも私も良くやるので人のことは言えない。
> 
> 違う。
> 結果表示が改行されず、同一行に上書きされているような感じ。
> つまり、トリックは私が仕掛けた、ということで。

結果表示が上書きのよう、というのはそのとおりなんですが。
結果表示がループの外、というトリックは、やっぱりkonnoさんだった。

#11195より

> 3070 'while ( x != lastx ) '// until the difference is not significant
> 3090      lastx = x 
> 3100      x = (x + s / x) / 2.0 
> 3112      cc=cc+1
> 3114      print x;lastx,cc
> 3116      print#1, x;lastx,cc
> 3110  if   x < lastx  then 3070
> 3120  print "SQR(";s;")=";x,lastx,cc
> 3122  print#1, "SQR(";s;")=";x,lastx,cc

これ、行番号順に並んでいないじゃないのよさ。
BASICの場合、行番号順に実行されるわけですから、実行時には

> 3070 'while ( x != lastx ) '// until the difference is not significant
> 3090      lastx = x 
> 3100      x = (x + s / x) / 2.0 
> 3110  if   x < lastx  then 3070
> 3112      cc=cc+1
> 3114      print x;lastx,cc
> 3116      print#1, x;lastx,cc
> 3120  print "SQR(";s;")=";x,lastx,cc
> 3122  print#1, "SQR(";s;")=";x,lastx,cc

となるわけでして。
まったくもう。
前にも書いたと思いますが、もうちょっと行番号の並びとかインデントに気を配って
プログラムを書いていただけないでしょうか。
バグが混入し易くなりますよ、と、繰り返しお伝えしていますよね。
こうやって、残り少ない人生を無駄にしてしまうわけですから。

でも、このプログラムだと、N88なら、ループ内での途中表示は全くないはず。
つまり、#11195の結果は出ないはず。
すると、あの結果はどうやって出したのだろう。
結果の出たあと、プログラムを書き換えてからアップした？
違う処理系での結果をN88での結果と間違えて書いた？



それはさておき。
ゆっくり入浴していたときにつらつらと思い出したこと。
大学時代の情報処理初級の授業で、丸め誤差と打切り誤差、桁落ち、情報落ちの
違い、なんてことをやったわけですよ。もはやほとんど覚えていませんがね。
そして、そういった誤差をなくすための方法として多倍長精度演算というのがある、
ということも思い出しました。こいつをやるとてきめんに遅くなるのですが、誤差も
非常に少なくなる。多倍長用のuBASICというのを知ったのは、確か私が大学を卒業
した直後ぐらいだったか。
多倍長っていうのは、例えば、１バイトに数字一桁しか格納しない、という方法。
実際の実装では、そんなことやっていたらメモリ効率が悪いので、１バイトに０から
99までの２桁の数字を格納する、なんていうのが多いかな。８６のアセンブラにも
それようの命令があったんじゃないかな、BCD演算、というやつ。Z80にはあった
ような気がする。
そしてアセンブラにあるくらいだからBASICにもあるわけでして、もしかしたら上記
のuBASICがそうだったかもしれないけど、10進BASICという実装があったはず。

で、話を戻して、誤差。

> 3110  if   x < lastx  then 3070

こいつを

> 3110  if   x < lastx  then print "div=",lastx-x:goto 3070

とやってみたらどうでしょう。
１回多くループするところで、いったい何がおきているのか見えてくるかも。

まとレスで失礼します。

> ダウト。
> >  23.57875633239746  43.25                  2 
> >  23.57875722543352  43.25                  2 
> もうここですでに値が異なります。
> すなわち、表示だけ倍精度、という可能性が濃厚。

うう、眠くてよく見てませんでした。(>_<)
表示だけ倍精度、が正解のようですね。(^^;

> N88の場合、仕様では、引数の型が結果の型、ということになっています。
> このプログラムでは、2.0 という単精度型で割り算をしています。
> ここを 2# としてみたら、もしかしたら違いが出てくる可能性があります。


> このプログラムを load して list をみたら、
> 3050 X = S / 2!  '; // Is there any better way to determine initial value?
> 3100      X = (X + S / X) / 2! 
> と、自動で変換されてしまっていました。

なんと！　インタプリタでは精度指定の無い定数は自動的に単精度になるのですね。

> もしかしたらkonnoさんのところでも、この手の意図せざる自動変換が発生している
> かもしれません。当然、コンパイラのほうでも。
> 一度、インタプリタのほうで list をたたいて、自動変換の有無を確認されたほうが
> いいでしょう。

T-98NEXT で確認しました。やはり自動変換されます。

> よくリストを見たら、結果表示がループの外に出ている。
> 結果表示が上書きのよう、というのはそのとおりなんですが。
> 結果表示がループの外、というトリックは、やっぱりkonnoさんだった。

げげ、他のソースからコピペして行番号を変えるのを忘れてました。m(__)m
申し訳ないです。m(__)m

> 前にも書いたと思いますが、もうちょっと行番号の並びとかインデントに気を配って
> プログラムを書いていただけないでしょうか。
> バグが混入し易くなりますよ、と、繰り返しお伝えしていますよね。
> こうやって、残り少ない人生を無駄にしてしまうわけですから。

インタプリタを弄るのはもう何十年ぶりなもので、うっかりやらかしてしまいました。m(__)m
気を付けます。m(__)m

> でも、このプログラムだと、N88なら、ループ内での途中表示は全くないはず。
> つまり、#11195の結果は出ないはず。

3110番を 3118 に変更すれば正常に出力されると思うのですが
私が何か勘違いしている？

> > 3110  if   x < lastx  then print "div=",lastx-x:goto 3070
> とやってみたらどうでしょう。
> １回多くループするところで、いったい何がおきているのか見えてくるかも。

重複部分は以下のようになりました。

div 6.226795723485168D-08  13  13          8 
div 2.220446049250313D-16  13  13          9 
SQR( 169 )= 13               13            9 

比較はほぼ間違いなく単精度でしょうね。(^^;

> 重複部分は以下のようになりました。
> div 6.226795723485168D-08  13  13          8 
> div 2.220446049250313D-16  13  13          9 

これ間違っていました。m(__)m　　正しい数値を各社で比較します。

-----　単精度  -----
N88BASIC
div= 1.27316E-03             13                  13.0013            6 
TurboBasic
div= 1.272201538085938E-003  13                  13.00127220153808  6 
T-BASIC
div= 1.272201538085938E-003  13                  13.00127220153808  6 

N88BASICは精度もいまいちな感じですね。


-----  倍精度  -----
N88BASIC
div= 1.272386299866479D-03   13.00000006226796   13.00127244856782  6 
div= 6.226795723485168D-08   13                  13.00000006226796  7 
div= 2.220446049250313D-16   13                  13                 8 
div= 0                       13                  13                 9 

TurboBasic
div= 1.272386299866923E-003  13.00000006226796  13.00127244856782   6 
div= 6.226795790098552E-008  13                 13.00000006226796   7 
div= 0                       13                 13                  8 

T-BASIC
div= 1.272386299866479D-03   13.00000006226796  13.00127244856782   6 
div= 6.226795745689628D-08   13                 13.00000006226796   7 
div= 0                       13                 13                  8 

全部違うと思ったら、6回目の N88 と T が同じ数値ですね。
これでなにかわかるでしょうか。

いろいろと見えてきたようです。

> N88BASICは精度もいまいちな感じですね。

私が仕様を知っているのはN88だけですが、N88に関していえば、まさに仕様どおり。
N88の単精度は、６桁までしか表示されないのですよ。
そして、計算されるのは７桁目まで。
他の処理系の単精度は１６桁も表示されるのですね。


> -----  倍精度  -----
> これでなにかわかるでしょうか。

いくつかわかることがあります。
まず、N88から。
前回の単なる出力結果だと、x も lastx も13で等しいのに次のループに回っている
のが不思議に思えました。でも実際には 2.220446049250313D-16 だけの差があった
わけであり、次のループに回っているのが正当でした。一方で、あまりにも差が
少なすぎたのでしょう、表示は13で打ち切られてしまっている。
ここ、私が前に書いたように print using を使えば、もしかしたら表示されていた
可能性はあります。

つぎ、TurboBasic。
N88やT-BASICだと、単精度指数の表記はEですが、倍精度指数はDを使っています。
でも、TurboBasicは、倍精度でもEで表示されている。
なんか違和感。これが仕様なんだろうなぁ。
ちなみにEは指数（exponent）の略といわれています。Dは倍（double）の略らしい。
なお、表記は同じでも値は異なっているので、計算そのものはきちんと倍精度で
行われている模様。
ところで、Wikipediaによると、指数表示でEを使うのは国際規格らしい。
実際、Excelとかでもそうなっているし。
もしかしたら倍精度でDを使うって、日本のどこかが始めたことかも。
NECとかシャープとか。
昔のMS-BASICでそうだったのかもしれないけど。

そして、T-BASICを含めて、細かい桁数の計算ではいくらかの精度差が発生すること
がわかります。
今回の話題の出発点の169が素数になってしまうという問題も、konnoさんのところの
エミュ環境のN88で起こっている話ですから、うちの実機のPC98だと、konnoさんの
ところのN88とは結果が異なる可能性がありそう。
ということで、今回の結果を出した検証プログラム、#11195に載っているものと
大体同じものだと思いますが、念のため、もう一度示してください。重要なのは表示
でして、同じような表示にしたいので表示部は必須。
なにとぞよろしくお願いします。

> ということで、今回の結果を出した検証プログラム、#11195に載っているものと
> 大体同じものだと思いますが、念のため、もう一度示してください。重要なのは表示
> でして、同じような表示にしたいので表示部は必須。

DOSVAXJ3 の32ビット版をJ31モードにして TBasicインタプリタが起動できました。
結構互換性があるのね。
それで、ソースをリナンバーしてみました。
 RENUM 3000
これで、3000 から始まる行番号にキチンと並べ替えられました。＼(^^)／ ﾔｯﾀ-
ではそのソースを貼り付けます。

3000 ' SQR-3.BAS
3010   DEFDBL A-Z
3020  'defsng a-z
3030 'screen 0
3040 CLS
3050 INPUT S
3060 OPEN "SQR.dat" FOR OUTPUT AS #1
3070 CC=0
3080 X = S / 2!  '; // Is there any better way to determine initial value?
3090 LASTX = 0! '; // the value one before the last step
3100 'while ( x != lastx ) '// until the difference is not significant
3110      LASTX = X 
3120      X = (X + S / X) / 2! 
3130      CC=CC+1
3140      PRINT "div=";LASTX-X, X,LASTX,CC
3150      PRINT#1,"div=";LASTX-X, X,LASTX,CC
3160  IF   X < LASTX  THEN 3100
3170  PRINT "SQR(";S;")=";X,LASTX,CC
3180  PRINT#1, "SQR(";S;")=";X,LASTX,CC
3190  CLOSE
3200  INPUT A
3210 END

このままで J31 と PC-98 で動くと思います。

> このままで J31 と PC-98 で動くと思います。

ありがとうございます。
次に実家に行ったときに、このコードを走らせたいと思います。
これをこのまま、といいたいところですが、おそらく、ファイル出力のところ、
OUTPUTはAPPENDに変更させていただく予定。

あと、もともとの#11175に立ち返って。

> 条件を色々変えて試しても結果は変わらなかったのですが、ひとつだけ
> N88P.BAS
> ところがオリジナルを若干修正した以下
> PN88.BAS

#11192にも書きましたが、内部的には若干の修正ではない可能性があります。
なので、しつこくてもうしわけありませんが

> PN88.BAS
> 110  defdbl a-z                                 '倍精度指定
> ここを単精度指定にしたらどうなるか、

この結果を教えてください。
よろしくお願いいたします。

> > 110  defdbl a-z                                 '倍精度指定
> > ここを単精度指定にしたらどうなるか、
> この結果を教えてください。
> よろしくお願いいたします。

もちろん 169 が素数と表示されます。
元々単精度でそういう表示になるところから始まった話題ですから。
色々試していった結果結構ソースが変わってしまいましたが。(^^;

ところで、USING を使ってみたら違いが表示されました。

1000 'pn88.bas 
1010 ' defdbl a-z                                 '倍精度指定
1020  'defdbl n                                 '倍精度指定
1030  OPEN "SQR.dat" FOR OUTPUT AS #1
1040 INPUT N
1050 IF (N/2 <> INT(N/2))=0 THEN IF N=2 THEN PRINT "素数" ELSE PRINT "合成数"
1060 J!=SQR(N) 'ELSE
1070   FOR I!=3 TO SQR(N) STEP 2
1080     IF N/I! = INT(N/I!) THEN 1100 '*EXIT1 
1090   NEXT I!
1100 '  *EXIT1
1110    PRINT USING  " .##################";I!-SQR(N) '.14
1120    PRINT#1, USING  " .##################";I!-SQR(N) '.14
1130   IF I!<=SQR(N) THEN PRINT "合成数";I!;J! 
1140   IF I!<=SQR(N) THEN PRINT#1, "合成数";I!;J! 
1150   IF I!>SQR(N) THEN PRINT "素数";I!;J!
1160   IF I!>SQR(N) THEN PRINT#1, "素数";I!;J!
1170 INPUT A
1180 END


この結果は

 .000001907350000000
素数 13  13 

このように単精度の時
I!-SQR(N)
で誤差が表示されました。
倍精度ではゼロになりました。

98実機ではどうなるでしょうね。

> もちろん 169 が素数と表示されます。

ちょっと残念というか、当然と思えることがおきなければそれも手がかりになる
かな、と思っていたわけですよ。
それで、しつこくお尋ねしていた次第。

> ところで、USING を使ってみたら違いが表示されました。

やっぱりそうでしたか。

> 98実機ではどうなるでしょうね。

とりあえず、試したいことリスト。
すでに試し済みのものもあるかも。

#11208のpn88.bas、倍精度と単精度
#11175のPN88.BASでNを単精度にしただけのもの
そして、#11175のN88P.BASの改造版、以下。

N88P0410.BAS
100 INPUT N
110 IF N MOD 2=0 THEN ELSE *ELSE1
120     IF N=2 THEN PRINT "素数" ELSE PRINT "合成数"
130     GOTO *ENDIF1
140 *ELSE1
150     I=3
160     WHILE (I<=SQR(N)) AND (N MOD I<>0)
165         PRINT I,SQR(N)
170         I=I+2
180     WEND 
190     IF I<=SQR(N) THEN PRINT "合成数" ELSE PRINT "素数"
200 *ENDIF1
210 END

これも、Nを単精度と倍精度にしたものの２つ。
今のところ、思いつくのはこのくらい。
あ、そうだ、konnoさんのコードだとプログラム終了のところに必ずinputがあるの
ですが、これ、コンパイラだとあったほうがいいのですか？
それとも他の事情？
いえ、うちのインタプリタだと、必ず最後に入力プロンプトの「?」がはいるのが
うざいというかうっとうしくて。

> そして、#11175のN88P.BASの改造版、以下。
> N88P0410.BAS

これ、実行してみました。NP2 では、169 は素数と表示されました。

> あ、そうだ、konnoさんのコードだとプログラム終了のところに必ずinputがあるの
> ですが、これ、コンパイラだとあったほうがいいのですか？

コンパイラでは終了すると画面が消えてしまい、表示の確認が出来ないのですよ。
インタプリタでは消えないんですが、ソース共通化のために入れています。

> これ、実行してみました。NP2 では、169 は素数と表示されました。

あ〜、いやいや、そこではなくて。
いや、そこなのか？
＃どっちだよ

ループの最後というか、誤判定されるわけですよね。
その、最後とそのもうひとつ前というか、単精度型と倍精度型でどうなっているのか
見たいな、ということです。

プログラム最後のinputについては了解しました。
やはり、環境によって、こういう差異が発生するものなのですね。
想像はできても、実際にお話を聞けたことがありがたいというか。

DOSVAXJ3 が 240410版に更新されました。
以下更新内容です。

build JP240410　(2024/4/10)
・J-3100モードが動作していなかったのを修正しました。
・Linux, macOS でビルドできなくなっていたのを修正しました。

……ということなんで，われわれにはあまり関係ないかな(^^;

> ループの最後というか、誤判定されるわけですよね。
> その、最後とそのもうひとつ前というか、単精度型と倍精度型でどうなっているのか
> 見たいな、ということです。

実行結果（数値はVTDOSの結果を張り付けたが表示は同じ）
? 169
 3             13
 5             13
 7             13
 9             13
 11            13
 素数

NP2の結果は単精度型は「素数」、倍精度型は「合成数」と表示だけ違います。

110番の THEN ELSE はこれでいいんでしょうか。
まあ 2 の表示を省いたのだと思うけど。

> 110 IF N MOD 2=0 THEN ELSE *ELSE1

> DOSVAXJ3 が 240410版に更新されました。

更新されていたのですね、お知らせいただきありがとうございます。

> build JP240410　(2024/4/10)
> ・J-3100モードが動作していなかったのを修正しました。
> ・Linux, macOS でビルドできなくなっていたのを修正しました。

うげ、今ちょうど J31モードを使っている所なんですよね。
それで、3月15日に更新があったのは知っていたのですが、32ビット版は落としてなかった。OTL
ちなみに、3月15日の更新内容は

---------------------------------------------------------------
build JP240315　(2024/3/15)

    J-3100 ビデオモード 64h (640×400 2色 文字 80×20)に対応しました。
    MS-DOS/V 6.2 をイメージファイルからブートした場合に jkeyb.sys の /106 設定が有効にならず
    英語キーボード配列になっていたのを修正しました。
    [dosbox] kanjikey を追加しました。漢字キーを ALT+半角全角、半角全角、右 ALTに割り当てる事ができます。
    int 21h ah=5ch に対応しました。Windows 3.1 用の MS-Office が起動可能になります。
    内蔵 BIOS 割り込みのエントリアドレスを F000:C000 以降に変更しました。

---------------------------------------------------------------

> J-3100 ビデオモード 64h (640×400 2色 文字 80×20)に対応しました。

これは、20行表示モードが使えるということかと思って VZJ31の ^KL でやってみました。
が、白画面が真っ黒になって、縦400ドットが、480ドットに伸びました。
カーソルは動きますが、文字は全く表示されません。
もう一度 ^KL で元に戻りましたが、これは使えないようです。
CHEV 64 でも同じ結果です。
黒画面はどうも VGA ぽいですね。

うーん、私の設定か解釈が間違っているのでしょうか。軟式さんに聞いてみようかしら。

それはともかく、これがきっかけで J31 用のBASICコンパイラを試してみたら
なんと！　生成した実行ファイルが VTDOS で動くではないですか。＼(^^)／ ﾔｯﾀ-
MS-DOS Player と同じく テキスト表示だけなら問題なく動作します。
この実行ファイル一つで、VTDOS、MS-DOS Player、DOSVAXJ3のVGA,J31モード全部動きます！！

> ……ということなんで，われわれにはあまり関係ないかな(^^;

関係ないどころか、埋もれていたお宝が完全復活しました！！
それだけではなく、今までのエミュの壁を突破できる切り札として蘇ったのです！！

これはめざらさんのおかげですね。ありがとうございます。
としきさんとの素数プログラムのやりとりも助けになっています。
軟式さんの J31モードのまめな更新のおかげで、古代の遺産が復活出来ました！
みなさまに感謝です。m(__)m

＃　伝説巨神 出でよん 発動編（壮絶な戦いになりそうな悪寒）

> とりあえず、試したいことリスト。

試してきました。

> #11208のpn88.bas、倍精度と単精度

pn88単精度
 .000000000000000000
合成数 13  13 

pn88b倍精度
 .000000000000000000
合成数 13  13 

> #11175のPN88.BASでNを単精度にしただけのもの

合成数と出ました。

> そして、#11175のN88P.BASの改造版、以下。

単精度でも倍精度でも同じ、

 3             13 
 5             13 
 7             13 
 9             13 
 11            13 
合成数

と出ました。単精度でも倍精度でも同じです。
うむ、興味深いぞ。

> 190     IF I<=SQR(N) THEN PRINT "合成数" ELSE PRINT "素数"

Iも13、SQR(N)も13なのだから、合成数と表示されるのが正当。
そして実際、うちでは想定どおり動いています。
ところが、konnoさんのところでは、単精度型ではこの比較式が成り立たず、ELSEに
落ちてしまっている。そして、倍精度型ではきちんと動いている。
なんか、エミュの挙動がおかしいとしか思えない。
前にも書きましたが、N88BASICの仕様では、関数の結果は引数と同じ型になることに
なっています。つまり、Nが単精度ならSQR(N)の結果も単精度のはず。だから、小数点
以下の細かいところの値が出てくることがおかしい。
もしかしたら、次のような簡単なプログラムでも、実機とエミュで差が出たりして。

10 A#=1.23456789#
20 B!=A#
30 PRINT A#,B!

これ、実はN88のマニュアルに載っているサンプルです。
そして、仕様上のこの実行結果は

RUN
1.23456789  1.23457

となるべきなのだそうです。
もしエミュでこうならないとしたら、それはどこかがおかしい。
エミュの作者に調査を依頼してもいいかも。



追伸
#11213

> 110番の THEN ELSE はこれでいいんでしょうか。
> 110 IF N MOD 2=0 THEN ELSE *ELSE1

N88BASICでは、言語仕様として、THEN節に空文を許します。
つまり、THEN のときは、何もせずに、次の行に進むことになります。
これ、#11169で触れているとおりです。

> これ、実はN88のマニュアルに載っているサンプルです。
> そして、仕様上のこの実行結果は
> 
> 1.23456789  1.23457
> 
> となるべきなのだそうです。

NP2でやってみた結果です。

 1.23456789    1.23457

表示は全く同じですね。やっぱり表示と内部の数値がズレているのかなぁ。
他のエミュの結果は全て以下の数値でした。

 1.23456789    1.234568

98エミュの表示が上の数値で内部的には下の数値だとしたら、計算が合わないのも合点ですね。
でも何故こうなるのかがわからないので、とっても気になります。

> もしエミュでこうならないとしたら、それはどこかがおかしい。
> エミュの作者に調査を依頼してもいいかも。

表示は全く同じなので、おかしくないということですね。（違う！）

> N88BASICでは、言語仕様として、THEN節に空文を許します。
> つまり、THEN のときは、何もせずに、次の行に進むことになります。
> これ、#11169で触れているとおりです。

なるほど、つまり想定どうりということですね。

> それで、3月15日に更新があったのは知っていたのですが、32ビット版は落としてなかった。OTL

実は寝室のPCでダウンロードしていました。(^^;
ダウンロードだけして寝落ちしてそのまま忘れていたようです。(^^;;
ということで

> build JP240410　(2024/4/10)
> ・J-3100モードが動作していなかったのを修正しました。

これがどういうことかと疑問だったので確認してみました。
・・・J31モードにすると、起動中に固まってしまいました、(>_<)
そういうことでしたか・・・

> > J-3100 ビデオモード 64h (640×400 2色 文字 80×20)に対応しました。
> これは、20行表示モードが使えるということかと思って VZJ31の ^KL でやってみました。
> が、白画面が真っ黒になって、縦400ドットが、480ドットに伸びました。
> カーソルは動きますが、文字は全く表示されません。
> もう一度 ^KL で元に戻りましたが、これは使えないようです。
> CHEV 64 でも同じ結果です。

これ、CHEJ 64 だとモードが変わりました。
CHEV コマンドに反映されていないみたいです。デジャブのような。(^^;

D:\NC>chev 64

V - Video mode information    R1.0  (C)ChaN,1993

Current Video Mode = 74h
Screen Size        = 80x25
Character Height   = 16
VRAM Mode          = A/N
VRAM Address       = B800:0000 (Real VRAM)

それで、CHEJ コマンドを試したら

D:\NC>chej 64
CHEJ.EXE <MultiMode CHEV> ver 6.10 by Natrium.

J-3100(DCGA)、日本語環境に切り替えました。
現在のビデオモードは 64h です。

V - Video mode information    R1.0  (C)ChaN,1993

Current Video Mode = 64h
Screen Size        = 80x20
Character Height   = 20
VRAM Mode          = A/N
VRAM Address       = B800:0000 (Real VRAM)

おお、画面モードが 20行に変わりました。
それで、VZJ31 の編集画面を見ると
行数は 25行のまま、アンダーラインカーソルも追随します。
点滅カーソルは 20行になったようで、下に行くほどズレます。

うーむ、これは VZが対応できていないのかしら？
やっぱり軟式さんに聞いてみようかな。

> NP2でやってみた結果です。
> 他のエミュの結果は全て以下の数値でした。
> 表示は全く同じなので、おかしくないということですね。（違う！）

NP2と他のエミュで差が出る、というところは一つの突破口かも。
少なくともNP2以外のエミュは仕様どおりではないということで、バグ報告は可能
だと思います。おそらく、四捨五入するときの桁数を誤っていると想定されます。
仕様上は、有効桁７桁、出力のときは７桁目が四捨五入されて６桁で表示、という
ことになっているのですから。
なので、以後は、NP2と実機の差異をどうするか。
どうも、本来は７桁以上は格納してはいけないものを７桁以上格納している、その上
７桁以上で比較してはいけないものを７桁以上で比較している、というように見える
わけですよ。
print usingを使う以外に、何かいい方法はあるかなぁ。


実際、この程度の小数の誤差がどの程度影響するかはわかりませんがね。
でも、もしかしたら、昔からゲームなんかでも使われている可能性はあるわけで。
konnoさんは、例えばバルーンパンチなんてゲームを覚えておられませんかね。
シーソーに乗った人が交互にジャンプして上のほうで動いている風船を割っていく、
というゲームです。
このゲームで飛んでいる人間は、まるで重力で引かれるような感じで頂点に向かって
減速して、また落下するときは加速するわけです。このゲームに限らず、まるで重力
に引かれたような動きをする、だとか、慣性が働いているようになかなか加速しない
上に速度が乗ったらすぐには止まれない、といった動きをするようなゲームでは、
もしもそれなりに理論的なアルゴリズムを使うならば、物体の位置決定に二次関数を
使う必要があるわけです。実際に使っているアルゴリズムがどこまで理論的に正しい
ものになっているかはわかりませんけどね。
そして、二次関数を解くためにはSQR関数が必要。
あるいは、ゲームによっては三角関数を使っているものもあるかもしれない。
そして、画面のＸとＹの座標は当然整数。
ときどき、当たり判定がバグっているゲームというのが話題になることがありますが、
あれっていうのはもしかしたら、小数と整数の比較の際の誤差の問題かも。そして、
実機だと正常に動いていたのにエミュだとおかしい、というゲームなどがあった場合、
それこそこのような小数の誤差の可能性は高いかも。
もちろん、倍精度を使えば誤差は少なくなりますが、リアルタイムの計算の場合、
倍精度だとやっぱり重くなるので、たいていは単精度を使うでしょうし。

> NP2と他のエミュで差が出る、というところは一つの突破口かも。
> 少なくともNP2以外のエミュは仕様どおりではないということで、バグ報告は可能
> だと思います。おそらく、四捨五入するときの桁数を誤っていると想定されます。
> 仕様上は、有効桁７桁、出力のときは７桁目が四捨五入されて６桁で表示、という
> ことになっているのですから。

もしかしたら誤解させてしまったかもしれません。
他のエミュとは、98エミュ以外の、J31とかDOS/V系のエミュのことです。
今回 NP2以外の98エミュは確認していません。同じ結果になると思ったので。

ということで、ANEX86 や T98-NEXT のN88コンパイラ、インタプリタでも確認しました。
結果は NP2と 表示は全く同じでした。

> どうも、本来は７桁以上は格納してはいけないものを７桁以上格納している、その上
> ７桁以上で比較してはいけないものを７桁以上で比較している、というように見える
> わけですよ。

これが実際どうなのかはわかりませんが、BASICのルーツは MSのGW-BASICだと思います。
T-BASICなどは漢字処理を覗けば恐らくほとんどそのままの互換性だと思っているのですが
NECのN88BASICは、あちこち変えているようですが、単精度の精度もわざと落としているように見えます。
その辺がエミュでの誤動作の原因になっているのではないかと愚考します。

> konnoさんは、例えばバルーンパンチなんてゲームを覚えておられませんかね。
> シーソーに乗った人が交互にジャンプして上のほうで動いている風船を割っていく、
> というゲームです。

私はこの手のゲームはあまりやっていないので覚えていません。

> ときどき、当たり判定がバグっているゲームというのが話題になることがありますが、
> あれっていうのはもしかしたら、小数と整数の比較の際の誤差の問題かも。そして、
> 実機だと正常に動いていたのにエミュだとおかしい、というゲームなどがあった場合、
> それこそこのような小数の誤差の可能性は高いかも。

今回のことを踏まえるとそう考えられますね。

> もちろん、倍精度を使えば誤差は少なくなりますが、リアルタイムの計算の場合、
> 倍精度だとやっぱり重くなるので、たいていは単精度を使うでしょうし。

N88BASICは8ビット時代の互換性重視ではないかと思いますが、8ビットの貧弱なCPUで
ゲームの速度を上げるためにわざと単精度の桁を落としたのではないかと思います。
そして、16ビット版になっても互換性のためにそこを変えることが出来なかったのかも。

> もしかしたら誤解させてしまったかもしれません。
> 他のエミュとは、98エミュ以外の、J31とかDOS/V系のエミュのことです。

はい、誤解しました。
続報をいただいたことで、誤解は氷解しました。

> NECのN88BASICは、あちこち変えているようですが、

うん、まぁ、その前のN-BASICからの互換性というのがありますからね。
そちらのほうでいろいろと変えていたところはあるかもしれません。

> 単精度の精度もわざと落としているように見えます。

こちらについてはどうなんだろう。
そうではないというわけではなく、根拠不足というか、これまでのところでは、私
にはそう思えるだけの挙動はないような気がしています。
ということで、ちょっと調べてみました。
まず、単精度は４バイトであらわす実数、倍精度は８バイトであらわす実数。
これは、調べた範囲では、どこも同じみたい。８０年代の８ビットパソコンのBASIC
でも、２１世紀の６４ビットパソコンのＣコンパイラでもおおむね一緒。
ところが、倍精度のほうが、最近の国際規格とN88BASICで異なるみたい。
#11164に書いたように、N88BASICでは倍精度の扱える上限は 1.7*10^38 ですが、
最近の規格では 1.8*10^308 まで扱えるらしい。
一方で単精度の方は最近の規格でも 1.7*10^38 で同じ。
内部表現についても、仮数部２３ビット、指数部８ビット、符号１ビットという部分
に変化はない。
でも、だからN88の単精度では精度を落としていないかというといささか怪しいと
いうか断言はできない。
なにかというと、十進数との変換部分。
#11135にも書きましたが、仕様としては有効桁７桁、出力のときは７桁目が四捨五入
されて６桁で表示、となっているわけですよ。でも、他の処理系では例えば、有効桁
７桁で表示も７桁、となっているかもしれない。もしそうであれば少なくとも見かけ
の精度は落ちているわけです。あるいは、他の処理系では、７桁目で四捨五入では
なく切り捨て表示となっているかもしれないし。
ただ、あまりにも他のマシンと差があるようであれば、当時、大騒ぎになっている
のではないかなぁ。あの時代、ネットはなくてもパソコン雑誌はあったし、８ビット
のころはともかく１６ビットの時代はパソコン通信もあったし。
ということで、とりあえず現時点では根拠不足としてkonnoさんのご意見に賛同は
しないでおきます。
＃つまり、何かあればすぐに意見は変わる

ただ、エミュという意味では、よく言われる「バグまで再現した」というものが評価
が高いわけで、現状、実機と差異が出るエミュは、完成度としてはもう一歩、という
のが現実的な評価だと思われます。

> 続報をいただいたことで、誤解は氷解しました。

紛らわしい表現で誤解させてしまい申し訳ないです。
とりあえずホッとしました。

> > 単精度の精度もわざと落としているように見えます。

考えてみたら、これは表示だけなのかもしれませんね。
N88BASICは、インタプリタもコンパイラも中間コードの LIB を使用しているように見えます。
ということは、そのバイナリコードは BIOS.ROM の中なのではないですか。

私の手持ちのNP2の BIOS.ROMは、実機のものではなく、互換BIOS かもしれません。
その互換BIOSを作る時、N88BASICの仕様に忠実に作るために、#11215 の

> 10 A#=1.23456789#
> 20 B!=A#
> 30 PRINT A#,B!
> 
> これ、実はN88のマニュアルに載っているサンプルです。
> そして、仕様上のこの実行結果は
> 
> RUN
> 1.23456789  1.23457
> 
> となるべきなのだそうです。

この結果を忠実に再現するために、わざと内部数値まで桁落ちさせたのではないかと疑い始めました。
つまり、問題なのは、互換BIOS.ROM なのかもしれないと思うようになりました。

これは、実機を持たない人たちにとって無くてはならない非常にありがたい福音ですが
互換BIOS を作ったのは、著作権の問題回避の為なので、バイナリレベルで違うものでなければならないわけです。
もしかしたら、この部分がそのための直せない生贄だったりして。あくまで妄想ですが。

> ただ、エミュという意味では、よく言われる「バグまで再現した」というものが評価
> が高いわけで、現状、実機と差異が出るエミュは、完成度としてはもう一歩、という
> のが現実的な評価だと思われます。

NP2は、細部の再現性にこだわったエミュという評価があるようなのですが
先のサンプルプログラムの結果は忠実に再現していますね。(^^;

> ということは、そのバイナリコードは BIOS.ROM の中なのではないですか。

確かに .LIB のファイルのサイズが小さ目というところから、実際に LIB がやって
いることは ROM の中身の呼び出しのみ、という可能性は高そうです。

> この結果を忠実に再現するために、

ある意味、この結果「だけ」を忠実に再現している、という感じ。
もし「実機を忠実に再現」するのであれば、169は合成数と表示される必要がある。
この点がなされない限り、実機に対するエミュとしての完成度は今一歩、という
ところで終わってしまいそうです。
もっとも世の中には、既知のバグどころか未知のバグまで再現したエミュレータと
いうものもある模様。実機で新たなバグが発見されてから、エミュレータでも同じ
バグが発現した、なんて話もあるようで、とても不思議。こういうのが、いわゆる
「完璧なエミュレータ」というやつでしょう。なぜ作れるんだろう。

> 互換BIOS を作ったのは、著作権の問題回避の為なので、

これはそのとおりだと思いますが、その一方で、実数のバイナリ表現というものは
ある意味で規格化されているわけです。つまり、実数演算とかバイナリと十進数の
変換とかの部分は世の中にいくらでもサンプルコードとかライブラリとかのフリーで
使えるものが存在しているわけで、そしてそういうものを使えば少なくとも著作権の
問題は回避できるはず。さらに、その手のコードって世界中の人が見ているわけです
から、精度を落とす方向にいじることは少ないのではないかなぁ。というか、わざと
精度を落とす、なんてことに時間をかけるくらいならとっととリリースしてくれよ、
という気もする。
もちろん、そういうものを使わずに１からコードを書いていたら、十分な精度を確保
できていなくても不思議はないけど。
あ、でも、ありうるかな。
倍精度のほうが現在のありふれたものとは内部表現が異なっているようだから、そちら
のほうに合わせて、ということはあるかも。



実は私、実数演算についてはちょっとだけやかましい。
#2066とか#10367にも書いたけど、大昔、８ビットマシンの時代、実数演算のマシン語
ルーチンを書いてハンドアセンブルしていたもので。
といっても四則演算だけですけどね。

> もっとも世の中には、既知のバグどころか未知のバグまで再現したエミュレータと
> いうものもある模様。実機で新たなバグが発見されてから、エミュレータでも同じ
> バグが発現した、なんて話もあるようで、とても不思議。こういうのが、いわゆる
> 「完璧なエミュレータ」というやつでしょう。なぜ作れるんだろう。

それはきっと、リバーs^ ・・・　いや、なんでもないです。(^^;

> 実は私、実数演算についてはちょっとだけやかましい。
> #2066とか#10367にも書いたけど、大昔、８ビットマシンの時代、実数演算のマシン語
> ルーチンを書いてハンドアセンブルしていたもので。
> といっても四則演算だけですけどね。

鶴亀算みたいなものでしたっけ？　結構面倒くさいんですよね。
丁度 DANNYさんの浮動小数演算ライブラリを目にしていたので見てみました。
ASMは1531行ありましたね。
バイナリは恐らく２千バイトくらいになるのかなぁ。

J3100用BASICコンパイラの続報も書かなくてはいけないのでこの辺で。

konnoさん、なんか他のものを連想している。

> 鶴亀算みたいなものでしたっけ？　結構面倒くさいんですよね。

鶴亀算は整数演算です。
何だろう、何と勘違いしたんだろう。おいらにはわからない。

> 鶴亀算は整数演算です。
> 何だろう、何と勘違いしたんだろう。おいらにはわからない。

あう、多分整数演算の事だと思います。(>_<)
私は算数も数学も苦手というか、数字の計算や記憶が全くダメなんですね。
だからパソコンにやらせようと思うのです。(^^;

STIME のTurboBasic用のBASICソースを J31BASICに逆移植しました。
元々は J3100で開発、運用していたので、動くようになるまで1時間も掛かりませんでした。
ところが、その後の各エミュでの挙動が違いすぎてその対応は非常に困難なものでした。
まるで底なし沼に落ちたような、藻掻けば藻掻くほど深くなるその深淵は、地獄か。

ということで、地獄から生還した私の地獄巡り体験記(違う)改造遍歴を書いてみたいと思います。(^^;
始めに両コンパイラの違いの説明です。
ソースの冒頭

TurboBasic
1  'STIME5  Menu   1994-08-10 96-05-27 97-9-12 98-04-23 09- 24-04-21
10 'TB
50 REM $DYNAMIC
55 $INCLUDE "REGNAMES.INC"

J31BASIC
1  'STIME6  Menu   1994-08-10 96-05-27 97-9-12 98-04-23 09- 24-04-22
10 'J31
50 REM $DYNAMIC
55 rem '$INCLUDE "REGNAMES.INC"

1994年頃は J3100で運用していましたが、Windows95が出てPCもWinノートに変わりました。
DOSの画面モードは VGAになり、J31用のプログラムは動かない。(>_<)
仕方なく手持ちのTurboBasicに移植することに。それが恐らく 96年以降の日付。

50行は J31用の設定ですが、TurboBasicでも同じようです。REM も含めてメタコマンドか。
55行は、TurboBasic用で、J31コンパイラではエラーになります。

55 '$INCLUDE "REGNAMES.INC"
55 rem $INCLUDE "REGNAMES.INC"

実は上のどちらにしてもエラーになるので、REM ' としてやっとコメントになりました。

後はテキストカラー属性指定かな。
TurboBasicは、
COLOR 7,0	グラフィックモード
COLOR 7,0,0	テキストモード

J31
COLOR 7,0	グラフィック
COLOR @7,0,0	テキスト

"@" だけの違いのように見えますが、実は TurboBasicでは文字の反転はテキストモードだけ
つまり、SCREEN 0 の英語テキストモードでしか使えないようです。
J31は基本グラフィックモードだけなので、@でテキスト文字用に使い分けできます。

他にもあったかもですが、僅かの変更でコンパイラは通るようになり、動き始めました。
だが本当の地獄はこれから始まるのであった。


続く　・・・のか

ココログからの転載記事です。
http://tamaneko2.cocolog-nifty.com/vz2/2024/04/post-6e6da8.html
これは、TurboBasic の STIME です。
先にこちらを上げないといけないので。(^^;


STIMEでリアルタイムのタイマー機能を追加しました。
きっかけは白内障の手術です。
術後点眼薬を３種類１日に４回または２回挿すことになりました。
３種類を５分間隔で、４時間以上空けて１日に４回を毎日３カ月間続けるのです。

忘れっぽい私は、STIMEのタイマー機能を使えば点眼管理が楽になると思ったのですが
キーを押した時に経過時間を表示するだけの簡易タイマーなので、あまり便利に思えません。
経過時間をリアルタイムに表示出来れば便利だろうと思い、機能追加しました。

STIME41 画像参照
 
以前はこのように2系統のタイマーを2列表示していましたが
リアルタイマーは上下2系統にし、黄色で表示します。

STIME51 画像参照

これで５分間隔の点眼は便利になったのですが、４時間以上経過したかわかりにくいので
アナログ時計にマーキングすることを思いつきました。

STIME556 画像参照
 
黄色の丸が [F06] で、ピンクの丸が [F07] です。
時計の丸枠に掛かっている丸は短針の位置で時間を示します。
時計の丸枠の内側の丸は長針の位置で、分を示します。

やってみると、分の表示はごちゃごちゃしてわかりにくいですね。
そこで、５分とか指定時間が経過したらカラー表示で知らせるビジブルベルを追加。
 
STIME557 画像参照

指定所間を経過するとカラーバーを色を変化させて表示します。

[ESC] でカラー表示のビジブルベルを解除できます。
時間など各種設定のために、STIME.DAT で設定できるようにしました。
 
MS-DOS Playerではこのように表示します。

STIME558 画像参照
 
これだとPC画面の隅に1文字分でも表示させておけばほかの作業中でもわかります。

これはいい！

STIME のカレンダ表示などを弄っていて、LXCLND.DEF と表示を比べてみたら
２月２３日とか１２月２３日など違っている日がいくつかありました。
STIMEの HOLIDAY.DAT を見てみると

02/23 2020-2099 天皇誕生日  (令和天皇)
12/23 1989-2018 天皇誕生日  (平成天皇)

なるほど、最近変更された祝日に LXCLND.DEF が対応してないのですね。
STIME のバグでなくてほっとしました。(^^;

見たついでに、LXCLND.DEF の祝日テーブルを修正しました。
LXCLND.DEF には HOLIDAY.DAT のデータ形式で参考にさせてもらいましたからね。

LXCLND.DEF  431行目

72:	;---- holiday definition -----------------------------------------

;	hh..2  =  "1874>1948=11;1967>0=11",
	hh..2  =  "1874>1948=11;1967>0=11;2020>0=23",

;	hh..4  =  "1874>1948=3;1928>0=29",
	hh..4  =  "1874>1948=3;1928>1988=29;1989>2006=29;2007>0=29",

;	hh..5  =  "1949>0=3;1985>0=4;1949>0=5",
	hh..5  =  "1949>0=3;1985>2006=4;2007>0=4;1949>0=5",

	hh..8  =  "2016>0=11",

;	hh..10 =  "1874>1948=17;1966>1999=10;2000>0=BB",
	hh..10 =  "1874>1948=17;1966>1999=10;2000>2019=BB;2020>0=BB",

;	hh..12 =  "1989>0=23",
	hh..12 =  "1989>2018=23",


該当する HOLIDAY.DAT の祝日は

02/23 2020-2099 天皇誕生日  (令和天皇)

04/29 1948-1988 天皇誕生日 （昭和天皇）
04/29 1989-2006 みどりの日
04/29 2007-2099 昭和の日

05/04 1985-2006 国民の休日
05/04 2007-2099 みどりの日

08/11 2016-2099 山の日

10/10 1966-1999 体育の日
10/BB 2000-2019 体育の日
10/BB 2020-2099 スポーツの日

12/23 1989-2018 天皇誕生日  (平成天皇)

修正した LXCLND.DEF を VZマクロの部屋に置きました。
以下の直リンクでも見ることができます。

#txt:LXCLND.DEF

STIME.EXE Ver 240428 を「自作、改作アプリの放置部屋」に置きました。

STIME5.ZIP　サイズ 84098bytes　 24-04-28 new!

　 STIME.EXE Ver 240428

・DOSVAXJ3 の VGAで動くアナログ時計とカレンダとタイマーのアクセサリです。
・NCPATH= でデータファイルの置き場所を指定してください。末尾に "\" が無ければ追加します。

・DOSVAXJ3 を起動したら、chev jp でVGAモードにして、STIME.EXE を起動してください。
・MS-DOS Player では、chej jp でVGAモードにします。文字のデジタル時計とカレンダのみ表示。
・VTDOS では動作しません。
・タイマーモード(6)の時は[F03]や[←]キーで小窓のカレンダー当月を表示します。
・ビジブルベルは[F06]だけの機能です。STIME.DAT で動作設定します。[ESC]でカラー表示消去。

STIME5　24-04-28
　240428　タイマーモード(6)の時は[F03]や[←]キーで小窓のカレンダー当月を表示。
　240315　指定時間経過でビジブルベル タイマー画面復帰
　240306　アナログ時計にタイマーのマーキング 設定ファイル STIME.DAT で各種設定可能に
　240202　タイマーの時間表示文字を大きく・経過時間をリアル表示、スリープモードにも対応。
STIME4　23-12-12
　231212　NCPATH が通ってなくてデータファイル読めない場合エラー終了していたのを警告表示に。
　231208　環境変数 NCPATH でデータファイルの置き場所を指定。指定無しならカレント
　春分、秋分の日を自動計算
　デジタル時計とカレンダ大の文字を2バイト文字に。
　[↑↓]キーで前年・次年 [←→]キーで前月・次月のカレンダーを表示

　動作保証はでき無いので実行は自己責任で。　　


※今回は DOSVAXJ3 で TOUCH を使いファイルの日時を合わせました。
　使い慣れたDOSツールが使えるのは気持ちいいですね。
　今回の版は TurboBasic でコンパイルしています。
　VTDOSでは動かないので注意してください。

わたしもオリ・パラ関連特別措置法による移動は無視しました。
四月と五月は敢えて弄りませんでした。祝日名を表示するわけでもないので。

> わたしもオリ・パラ関連特別措置法による移動は無視しました。

これは Wikipedia でも参考程度になっていますね。

> 四月と五月は敢えて弄りませんでした。祝日名を表示するわけでもないので。

そうなんですよね、表示は同じなんですが、オリジナルでも分けているところがありましたので。

ところで、今回 LXCLND.DEF で気が付いたところがあります。
中央のカレンダに今日の日付が () に囲われてわかりやすくなっていますが
表示月を移動しても同じ日付に () が付いたままになっていますね。

これはバグという見方もできますが、仕様かもしれないと思いました。
このマクロはスケジュール管理のために月を変えてカレンダを参照しやすくなっています。
その時、今日は何日だっけ？と思うこともありそうなので、その確認になるかなと。
なので、この仕様はこのままにしておきます。

STIME でも現在の日付に色付けしていますが、改編時バグって毎月同じ日付に色がついて
修正に苦労したりして。いや、年取って頭が働かなくなっただけなんですけどね。(^^;

う、そういえば今日は祝日なのに今日の日付が赤になっていない。(>_<)
うーん、直せるかしら・・・(^^;

> 表示月を移動しても同じ日付に () が付いたままになっていますね。

日付出力のために疑似カーソルを表示しています。
これは当日であるとは限らないです。（当日は[TAB]入力直後の表示）

> > 表示月を移動しても同じ日付に () が付いたままになっていますね。
> 日付出力のために疑似カーソルを表示しています。
> これは当日であるとは限らないです。（当日は[TAB]入力直後の表示）

疑似カーソルって、Shift+カーソルキーで () の日を移動出来るんですね。
凄いテクニックです。ソースを見てみました。

LXCLND.DEF 189行目以降

10:	;---- make menu --------------------------------------------------

	pr..15 = "$$3($$7",		;right of today
	pr..16 = "$$3)$$7",		;left of today

ここが多分メニューの中で () を表示するところでしょうか。
実際のメニュー表示はその下のマシン語かな。

10:	;---- mklxclnd.asm ----

こうなると全く読めないので追及は諦めます。(^^;

新しい STIME では、TIMER.DAT にタイマー画面を退避させています。
J31用BASICコンパイラを動作させてみると、その画面がおかしい。
ぐちゃぐちゃになっているのです。

TurboBasic では、48桁 23行で以下のように表示されます。
1行目は、d-他の受け渡しに使っています。

 1             1 
>                                               
 1日 １７:１６:３１   0: 0: 0    0: 0: 9        
                                                
　　中略
                                                
     1日 １７:１６:３３   0: 0: 0   0: 0: 7     


J31BASIC では、各エミュごとに全部違っています。

VTDOS 4/13
13 把  ０Oマ: ４Sマ: ４Sツ   8:12'45    0: 0:19        
                                                
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

VTDOS 4/21
21日^@^@０２：３８：３１  0: 0: 0   0: 6:48 ^@^@^@^@^@^@
                                                
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

VTDOS 5/1
 1日  １７：２２：５４  0: 0: 0   0: 0: 8       
                                                

最初は2バイト文字が変に文字化けして、背景のスペースがヌルになっています。
現在は正常表示になっていますが、ここまでするのに一苦労でした。

DOSVAXJ3 VGAモード
12日���cc １PP６UU:２QQ９XX:１PP０OO   0  8:40:54 0: 0: 3
                                                
ﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛ
ﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛ

DOSVAXJ3 J31モード
13日日 ００１１:００７７:４４７７   0: 0'26    0: 0:13        
                                                
                                                
MS-DOS Player
13日�c ０O０O:５T３R:３R０O   0: 0' 0    0: 0:11        
                                                
                                                
このように、どのエミュでも2バイト文字が化けたり2重になったりしています。
その原因は、J31BASIC の CDBL$() という、1バイトの数字を2バイト文字に変換する関数でした。
元々は J3100 でこの関数を使って表示していたので元に戻してみたらこうなったということです。
しかたがないので、TurboBasic と同じやり方に戻しました。

背景の空白が ヌル文字になったり、DOSVAXJ3 VGAモード では、$DB で埋められています。
これは、VRAM領域のメモリの状況によると思われます。
C000h セグメントは VGAの領域で確保されていると思いますが、初期化の問題なのかな。
VTDOS では、TPAEXT などでメモリ拡張していると干渉すると思われるので要注意です。

ともかく、動くのが不思議な状態なので、このまま使うのがよろしいようです。
                                                

> 疑似カーソルって、Shift+カーソルキーで () の日を移動出来るんですね。

メニュー表示中のコマンドキーを受けるもののうち，以下の四つですね。

(#37)	{ r=7, &11 }
(#38)	{ r=7, &12 }
(#a)	{ r=1, &11 }
(#f)	{ r=1, &12 }

これらのキーを受け取ったときに「日付」を再設定します。
再設定する値は現在の値に1日（左右）か7日（上下）を増減して再表示します。

再表示のしかたについては，多くのカレンダーマクロで当日の背景色を変えたり
括弧でくくったりするのとまったく同じで，メニューアイテムへの埋込みです。
（括弧の場合は前後の空白に上書きすることになりますが）

メニューアイテムの書換えというのはトンでもなく面倒なわけで，
オリジナルのnomad版ではテキストに書き出すという手法をとっていたため
konnoさんのようにキーを押しっぱなしにしたりする人(^^;はとても使えなかった。

Yushiさんはメモリ（ラインバッファ）上に出力することと機械語化で高速化し，
Emmettさんは機械語化をさらに徹底的に行なって超高速化しています。

メニュー内でカーソルを動かすというのは確かに高度なテクニックですが，
（アセンブラに馴れ親しんでいるkonnoさんには釈迦に説法に違いないのですが）
とにかくひたすら面倒な「低級」テクニックとも言えると思います。

Yushiさんなんか，メニューで十字カーソルですぜ。
そんな面倒なコードをよく書くものだなぁとひたすら感心します。

あ，元に戻って，「日付」というのは保持している値なので，あまり意味はなく，
「当日」を指示されたときだけリセットするというイメージですね。

> > 疑似カーソルって、Shift+カーソルキーで () の日を移動出来るんですね。
> メニュー表示中のコマンドキーを受けるもののうち，以下の四つですね。
> (#37)	{ r=7, &11 }
> (#38)	{ r=7, &12 }
> (#a)	{ r=1, &11 }
> (#f)	{ r=1, &12 }

なるほど、詳細な解説ありがとうございます。
これなら改造も出来そうな気がしてきました。（やらないけど。(^^;）

> メニューアイテムの書換えというのはトンでもなく面倒なわけで，
> オリジナルのnomad版ではテキストに書き出すという手法をとっていたため
> konnoさんのようにキーを押しっぱなしにしたりする人(^^;はとても使えなかった。

い、いやぁ、、、そんなことは・・・ない、と思いますです。(^^;
実際のところ今カレンダ表示をモードによって分岐を変えるので四苦八苦してます。
とんでもないスパゲッティが出来上がりつつあり、ソースでごまかせるのかと。(^^;

> あ，元に戻って，「日付」というのは保持している値なので，あまり意味はなく，
> 「当日」を指示されたときだけリセットするというイメージですね。

これ、勘違いしていました。疑似カーソルの意味がやっとわかりました。
スケジュールとのリンクとか日付出力とかでこの機能が必要だったのですね。

DOSVAXJ3 が 240502版に更新されました。
以下更新内容です。

・J-3100 モードの場合、int 10h ah=02h のカーソル位置指定で bh のページ番号は使用せず常に 0 となるよう修正しました。
・J-3100 の int 10h ax=8200h でスクロールモードを変更した後に画面クリアするよう修正しました。
・macOS 上での SDL-IM+ の不具合を修正しました。

……てことで，あまり関係ないかしら(^^;)

> ……てことで，あまり関係ないかしら(^^;)

あうう、更新の記事を上げようとしたら先を越されてしまいました。(^^;

問題無く動作しますが、特に変化は感じないです、(^^;
この機会にJ31関連でちょっと要望などしてみようかしら。(^^;

> C000h セグメントは VGAの領域で確保されていると思いますが、初期化の問題なのかな。
> VTDOS では、TPAEXT などでメモリ拡張していると干渉すると思われるので要注意です。

C000h セグメントはパソピア16 でした。思い込みで間違えました。m(__)m
J3100用BASICコンパイラでは、画面モード 75 (SCREEN 4) でカラーモードが使えます。
J3100テクニカルブックによるとこのモードでは VRAM領域 A000h - AFFFh となっています。

確認のために STIME実行中に SHELL で画面情報を見てみました。

・DOSVAXJ3 J31
CHEJ.EXE <MultiMode CHEV> ver 6.10 by Natrium.

現在 DOS/V(Normal)、日本語環境です。
現在のビデオモードは 03h です。

V - Video mode information    R1.0  (C)ChaN,1993

Current Video Mode = 03h
Screen Size        = 80x25
Character Height   = 19
VRAM Mode          = APA
VRAM Address       = C741:0000 (Virturl VRAM)


・DOSVAXJ3 VGA
現在 DOS/V(Normal)、日本語環境です。
現在のビデオモードは 03h です。

Current Video Mode = 03h
Screen Size        = 80x25
Character Height   = 19
VRAM Mode          = APA
VRAM Address       = C679:0000 (Virturl VRAM)


・VTDOS
現在 DOS/V(V-Text)、日本語環境です。
現在のビデオモードは 70h です。

Current Video Mode = 70h
Screen Size        = 110x35
Character Height   = 12
VRAM Mode          = A/N
VRAM Address       = D000:0000 (Real VRAM)


・MS-DOS Player
現在 DOS/V(V-Text)、日本語環境です。
現在のビデオモードは 75h です。

Current Video Mode = 75h
Screen Size        = 80x25
Character Height   = 22
VRAM Mode          = A/N
VRAM Address       = B800:0000 (Real VRAM)


うーむ、どのエミュも A000h - AFFFh の領域は使用していないようですが
VRAMアドレスがバラバラですね。

ごめんなさい、ここのところがよくわからないので解説希望。

> その原因は、J31BASIC の CDBL$() という、1バイトの数字を2バイト文字に変換する関数でした。
> 元々は J3100 でこの関数を使って表示していたので元に戻してみたらこうなったということです。
> しかたがないので、TurboBasic と同じやり方に戻しました。

(1)J31BASICではCDBL$()を使っていた
(2)でも何らかの理由でJ3100ではCDBL$()を使わなくなった
(3)だけどやっぱりCDBL$()を使ったら文字化け
(4)TurboBasicと同じCDBL$()を使わない方法に戻した

という理解でよろしいのでしょうか。それとも

(1)J31BASICではCDBL$()を使っていた
(2')でもJ3100以外の機械で使うためにCDBL$()を使わなくなった
(3)だけどやっぱりCDBL$()を使ったら文字化け
(4)TurboBasicと同じCDBL$()を使わない方法に戻した

こっちの理由かな。
つまり、(2)なのか(2')なのかで違いがあるかも、というお話。


余談ですが、N88-BASICにはCDBL$()という関数はありません。
数値型のCDBL()という関数はあります。
引数を倍精度型に変換するという関数です。
文例として
A#=CDBL(256%)
なんていうのが載っていますが、仮に
A#=256%
とした場合と何が違うのか、あまり知られていません。違いはないのかも。
積極的には使われない関数であることは間違いありません。

> (2')でもJ3100以外の機械で使うためにCDBL$()を使わなくなった

こちらですね。
経緯は書いていますが、もう一度整理すると

・元々J3100 で使うために J31BASICでCDBL$()(２バイト数字文字）を使っていた。
・でも、PCがWin95ノートに変わってしまい、J3100のプログラムが動かなくなったので
　TurboBasicに移植して、CDBL$()が使えないので、１バイト数字文字で運用した。
・今回このプログラムを公開するために、２バイト数字文字表示を実現させた。
・その後 J31BASICで各種エミュで動くことが分かったので、CDBL$()(２バイト数字文字）を復活させた。
・だけど CDBL$()を使ったら文字化け。
・結局TurboBasicと同じCDBL$()を使わない方法に戻した

で、文字化け等の原因ですが、J3100と IBM-PCの VGAで同じBIOSコールを使っていても
機能が微妙に違ったり VRAMへの描画形式が違うためと思われます。
VRAM領域は、VGAと J31の画面モード 75 が同じ A000h セグメントなので動くみたいです。
実機では動かないと思っていましたが、エミュでは何故か動くのです。

> 余談ですが、N88-BASICにはCDBL$()という関数はありません。
> 数値型のCDBL()という関数はあります。
> 引数を倍精度型に変換するという関数です。

この関数は J31BASIC にもあります。機能的にも同じようです。

> 積極的には使われない関数であることは間違いありません。

私も使ったことが無いです。(^^;

> > (2')でもJ3100以外の機械で使うためにCDBL$()を使わなくなった
> こちらですね。

理解できました。ありがとうございます。
ところで、CDBL$()を使わない方法ってどんなものですか？
Vzでよくやる、$824fを足しこむ、みたいなものかな。

> ところで、CDBL$()を使わない方法ってどんなものですか？
> Vzでよくやる、$824fを足しこむ、みたいなものかな。

Vzでよくやる、$824fを足しこむ、みたいなやりかたはしてないです。
「0」のコード $30 を「０」のコード $824f に変換ですか、出来そうですね。

私は単純に配列を使ってみました。

 DIM BB$(10)
 BB$(1)="１"
 BB$(2)="２"
 BB$(3)="３"
 BB$(4)="４"
 BB$(5)="５"
 BB$(6)="６"
 BB$(7)="７"
 BB$(8)="８"
 BB$(9)="９"
 BB$(0)="０"
PRINT BB$(VAL(MID$(TIME$,1,1)));BB$(VAL(MID$(TIME$,2,1)));

これで２桁の２バイト数字表示になります。
VZ式だと配列を使わないで

k!=&h824f
PRINT chr$(k!)

こんな感じ？　結果はエラーになりました。(>_<)

配列方式は、わかり易くていいんですけどね。
やっぱり、初期設定がちょっと手間がかかる気がして。
単なる気のせいなんでしょうけど。

> こんな感じ？　結果はエラーになりました。(>_<)

あぁそうか。
chr$だと1バイト値しか取れませんからね。
N88-BASICだとAKCNV$かKNJ$を使う、ということになっているのですが、私、KNJ$って
使った記憶がない。これは純粋に文字コードの変換しかしてくれなくて、表示の際には
もう一手間かかるので。

> chr$だと1バイト値しか取れませんからね。
> N88-BASICだとAKCNV$かKNJ$を使う、ということになっているのですが、私、KNJ$って
> 使った記憶がない。これは純粋に文字コードの変換しかしてくれなくて、表示の際には
> もう一手間かかるので。

それらの関数は J31BASICには無いですね。調べてみたら、「０」は、KTN$("０") 
これで区点コードで &K0316 が得られました。この形式なら CHR$() で表わせるようです。
PRINT CHR$(&K0316)
０

&K は定数なので、これではちょっと使えないなぁ。
さらに調べてみたら、「０」は、内部連続コードなら CHR$() で表わせるようです。
その換算表が手元に無いのでさらに調べたら、ASC("０") で連続コードが得られるようです。
PRINT ASC("０")
459

PRINT CHR$(459)
０

おお、これなら使えるかもしれない。０〜９までの数値は

2バイト 区点コード	連続コード
０	&K0316		459
１	&K0317		460
２	&K0318		461
３	&K0319		462
４	&K0320		463
５	&K0321		464
６	&K0322		465
７	&K0323		466
８	&K0324		467
９	&K0325		468

こうなりました。この内部連続コードを使えば配列がいらなくなりますね。
早速 BB$(I) を CHR$(I+459) に入れ替えてみました。
おお、動いた。＼(^^)／ ﾔｯﾀ-

でも、考えてみたら、TurboBasic ではこの関数使えないですね。
ということで、互換性を考えてこの案は没にします。(;_;) 時間を返せ〜

各種DOS/V系エミュのテキストモードで J31BASIC が動作する仕組みは大体わかりました。
J31BASIC では文字の読み書きなどを BIOSコールで行っていると思われます。
なので、BIOSレベルではほぼ互換なのでテキストが正常に表示出来ていると。

ところが VTDOSの場合、2バイト文字の表示にいくつか問題がありました。

・文字列の中で2バイト文字だけ表示位置が1バイト後ろにズレる。
　その後ろが1バイト文字の場合2バイト文字が表示されなくなる。

・CHR$()で文字表示の場合改行しないと(カーソル点滅で?)最後の文字が消えることがある。
　1バイト罫線文字などでもこの現象は起こる。必ず起こるわけではないのは点滅のせい？

・"日 月 火 水 木 金" これらの文字が特に表示されにくい("土"はそうでもない)
　カレンダーでは必須の文字なのでCHR$()を使って苦労して体裁を整えた。

いずれも結構な難題補間形書くで、どうにかこうにか見た目だけは正常に出来ました。(^^;
VTDOSだけ何故こうなるのかは謎ですね。

ちなみに DOSVAXJ3のVGAモードならカラーグラフィックも表示されます。
640*400 の範囲だけどね。(^^;

なんか昔、１バイト幅の２バイト文字、というのが話題になったようなおぼろげな
記憶が。PC-98でしたっけ？

文字だとちょっと思い出せないんですが……，
確か罫線で半角の2バイト素片があったように思います。

大昔のPC8801のN88-BASIC のマニュアルなんか見たら，
1/4角文字コードなんて掲載があって凄く笑った。
実は，カセットテープの背ラベルとかに割と重宝してたの思い出して，
なんだか切ないような愛おしさまで感じた。（PC88専用ワープロで対応してた）
データベースが使えなくて印字で現物管理していた遠い昔の話です。

としきさん
> なんか昔、１バイト幅の２バイト文字、というのが話題になったようなおぼろげな
> 記憶が。PC-98でしたっけ？

PC98で 2バイト半角というのは聞いたことがあります。

めざらさん
> 大昔のPC8801のN88-BASIC のマニュアルなんか見たら，
> 1/4角文字コードなんて掲載があって凄く笑った。

そんなのもあるんですか、面白いですね。

> 実は，カセットテープの背ラベルとかに割と重宝してたの思い出して，
> なんだか切ないような愛おしさまで感じた。（PC88専用ワープロで対応してた）
> データベースが使えなくて印字で現物管理していた遠い昔の話です。

私も8ビットのパソピア７に漢字パック入れてドットプリンタで漢字印字とかやってたような。
5インチFDDも買っていたので凄い出費でしたが、全部捨ててしまったのは惜しいことしたかなぁ。

DOSVAXJ3 Build JP240514版　(2024/5/14)が更新されました

内容は

build JP240514　(2024/5/14)

    タイトルバーに表示する文字列を指定する [sdl] titlebar が有効になっていなかったのを修正しました。
    タイトルバーに表示する文字列を変更するコマンド title を追加しました。
    macOS Sonoma 上での SDL-IM+ の不具合を修正しました。


[sdl] セクションで

titlebar          =
　　　　　↓
titlebar          = DOS/V

このように変更すると、窓のタイトルバーに表示されて、DOS/V モードか J31 モードか判別しやすくなります。
私は常時複数窓を開けて使い分けているので、コマンドラインで

title J31

等とすればその窓のタイトルが変わります。
タスクバーの表示も変わるので使い分けに便利です。

わがままな要望に応えてくださった軟式さんに感謝です。

最近 Cドライブの空き容量が急激に減少してほとんど無くなってきました。
色々不要なファイルを削除したり移動させても追いつきません。

ふと、VTDOSのエラーログ、vtd_err.log を確認してみたら、、、げげぇ、なんと！！
ギガ越えの超巨大ファイルになっているではないですか！！　なんじゃこりゃぁ！！
その原因は、J31BASICコンパイラの実行ファイル、STIME.EXE でした。

2024-04-16 10:01:41 STIME(09BA) 1876:4778 'サポート外 VIDEO BIOS(Int10h) 機能: AX=8500'
2024-04-16 10:01:42 STIME(09BA) 1876:47F1 'サポート外 VIDEO BIOS(Int10h) 機能: AX=8582'
2024-05-08 07:47:20 STIMEJ(2797) 433A:5982 'サポート外 KEYBOARD BIOS(int16h) 機能 F6'
2024-04-16 10:02:00 STIME(09BA) 1876:4D68 'サポート外 Int6F'

このようなエラーログが延々と出続けていたのです。
特に、Int10h AX=8500 〜 AX=8582 は毎秒３０くらい出続けていました。
なんてこった、これでは VTDOSで使えないではないか。(>_<)

この割り込みは、ブラウンデータにも載っていない J31独自機能のようです。
J3100テクニカルブックを発掘したので見ると、カーソル位置のアトリビュート読み込みのよう。
int16h 機能 F6 は、キーバッファのチェックのようです。
Int6F は、ATOK5制御割り込みのようです。

VTDOSには エラーログ抑制オプションとかは無さそうだし、どうしたものか・・・・

> ふと、VTDOSのエラーログ、vtd_err.log を確認してみたら、、、げげぇ、なんと！！
> ギガ越えの超巨大ファイルになっているではないですか！！　なんじゃこりゃぁ！！
> その原因は、J31BASICコンパイラの実行ファイル、STIME.EXE でした。

このVTDOSのエラーログを削除しても Cドライブの空き容量の減少が止まりません。
そして、ついに Cドライブの空き容量がゼロになってしまいました。
その時ふと、DOSVAXJ3のフォルダを覗いてみたら、capture フォルダが出来ていて
こんな感じになっていました。げげぇ！！！

2024/04/26  05:15     5,866,799,616 stime_000.wav
2023/04/10  16:46             7,343 dosbox_000.png
2023/04/10  16:54         1,892,112 dosbox_000.wav
2023/04/10  16:54             7,202 dosbox_001.png
2024/03/06  14:10             5,300 stime510_000.png
2024/03/06  07:40         2,311,592 stime510_000.wav
2024/03/06  07:41         4,845,752 stime510_001.wav
2024/03/06  13:51         1,952,792 stime510_002.wav
2024/03/06  13:57        52,911,756 stime510_003.wav
2024/03/06  13:58         6,592,112 stime510_004.wav
2024/03/06  14:00        23,988,684 stime510_005.wav
2024/03/06  14:10        46,314,040 stime510_006.wav
2024/03/06  14:33       158,472,688 stime510_007.wav
2024/03/06  14:33         5,609,564 stime510_008.wav
2024/03/09  23:59     3,240,653,264 stime_000.wav
2024/03/09  23:59         1,792,092 stime_001.wav
2024/03/09  23:59            66,900 stime_002.wav
2024/03/09  23:59         1,114,112 stime_003.wav
2023/04/10  16:54         1,892,112 dosbox_000.wav

※ これはもう１台のPCの中身。件のデータはもっと巨大で、緊急事態につき速攻で削除しました。

どうやら DOSVAXJ3 の機能キーを不用意に押してしまったようです。

キー割当  機能名
Ctrl-F5   Screenshot
Ctrl-F6   Rec Wave

この辺のキー割り当てを弄ったので、その時に押してしまったと思われます。

＃　C部の空き丸ごと消滅だと！
　　良くわからないものを無理して使うからよ・・・

PCの警告が出て、Cドライブのクリーンアップが推奨されたので、しかたなく OK しました。
その結果、３分の１くらい空きができました。（大丈夫なのか）
その後は問題なく動作しているようなので、まあいいか。(^^;

> 2024-04-16 10:01:41 STIME(09BA) 1876:4778 'サポート外 VIDEO BIOS(Int10h) 機能: AX=8500'
> 2024-04-16 10:01:42 STIME(09BA) 1876:47F1 'サポート外 VIDEO BIOS(Int10h) 機能: AX=8582'
> 2024-05-08 07:47:20 STIMEJ(2797) 433A:5982 'サポート外 KEYBOARD BIOS(int16h) 機能 F6'
> 2024-04-16 10:02:00 STIME(09BA) 1876:4D68 'サポート外 Int6F'
> 
> このようなエラーログが延々と出続けていたのです。

これを何とかしないと J31BASICコンパイラは使い物にならないですね。
それで考えたのは、常駐プログラムでこれらの割り込みを横取りして無効化すること。

私がいつもお世話になっている、アセンブラ入門のサイトから
トップ-> アセンブラ 第2章-> 第2章.メモリー管理-> 2-7. 常駐プログラム(TSR)
https://programmer.main.jp/assembler2/assembler10.html

このページの、「HOOK21」完成版(?) のソースを元に、INT10h でやってみたら出来ました。
ところが常駐解除が出来ないのです。
色々やってみてわかったのは、ソースの解放チェックルーチンで

STAY_CHEK:
	mov	ax,3521h
	int	21h             	;割り込みベクター取得

	mov	ax,es           	;解放できるかのチェック
	dec	ax
	mov	es,ax
	mov	di,8
	cld
	mov	si,offset PRCNAME
;	mov	cl,7			;★ cl ではうまくいかない、
	mov	cx,7			;★ cx ならうまくいく

	repz	cmpsb            	;名前が一緒かのチェック
	or	cx,cx
	jz	_STAY
	stc                     	;解放できない
	ret
_STAY:                           	;解放できる
	clc
	ret

★印のところの cl を cx に変えたら常駐解除できました。

＃ 汚れていたのは ch だったのです。

これで調子に乗って、INT16h  INT6Fh  も一緒にしてしまいました。
でもまたもや常駐解除が出来ない。(>_<)
プログラムの仕組みがわかってないからでしょうね。(;_;)

どうも、新着情報のページの表示がおかしいですね。
すぐにプッシュアウトされてしまいそうなので具体的に言うと、野ざらし言の
新着情報の部分、野ざらし言#5602の発言のところ。
ざっくり見てみたところ、野ざらし言#5602の発言本文の中のリンク情報を
拾って、偽のリンク情報を無理やり構築している模様。

ご確認いただけると幸いです。

> 新着情報の部分、野ざらし言#5602の発言のところ。
> ざっくり見てみたところ、野ざらし言#5602の発言本文の中のリンク情報を
> 拾って、偽のリンク情報を無理やり構築している模様。

ああ、本当だ、おかしいですね。
掲示板の形式とか変わったのでしょうかね。
見てみます。

掲示板の形式が変わったわけないじゃないですか。(笑)
ただ，うちだけの問題なのかな。

例えば，こちらで似たようなリンクを書き込んでみると……(^^;

#5601：Re^14: 近況報告 めざら 2024/05/25(Sat)
http://mezala.la.coocan.jp/bbs/noz/wforum.cgi?mode=msgview&page=0&no=5601&reno=5600&oya=5561

あるいは，
http://mezala.la.coocan.jp/bbs/noz/wforum.cgi?mode=allread&no=5561#N5602
みたいにハッシュが付いているリンクの場合とか。

違うなぁ……

あれ？　今度は VTDOS BBS の新着へのリンクが消えちゃったな。
消えたと言うか，a要素リンク内の値を括るダブルコーテーションが閉じていない？
<tr><td><a href="http://tamaneko.world.coocan.jp/bbs/http://mezala.la.coocan.jp/bbs/noz/wforum.cgi?mode=allread&amp;no=5561#N5602' target='_blank' rel='noopener noreferrer' target='_blank' rel='noopener noreferrer'>???????e?[?}</a></td><td>11256</td></tr>
新着情報そのものは取得しているみたいだけれど，ダブルコーテーションの出力エラーで該当行以降が表示されないのと，他のBBSの不思議なリンクも中途半端に含まれていますね。
もしかして弄っている途中でしたか？

なるほど、めざらさんの実験で、なんとなく見えてきたようです。
konnoさんの使われているコードって、１つ分の発言全体から、ある特定の形式の
URLを手がかりにして、本文だのなんだの不要なところを消して、<tr>から</tr>に
はさまれた形に変換しているのでしょう。
ここで使ってるのは正規表現置換と見た。置換一発か複数発かはわかりませんが。
でも、今回、その特定の形式に該当してしまうURLが１つの発言に複数含まれて
しまった、ということかと。
今までは、仮にURLがあっても、その特定の形式に該当するものではなかったので
発病しなかった、のではないかなぁ。
なので、正規表現を駆使して、何番目に該当するものだけ残す、みたいにすれば
解決しそうな気がする。

ハズレかな。

> 掲示板の形式が変わったわけないじゃないですか。(笑)

すみません、適当なことを言ってしまって。m(__)m
色々見てみたのですが、わからないんですよね。(>_<)

> 例えば，こちらで似たようなリンクを書き込んでみると……(^^;
> あるいは，
> http://mezala.la.coocan.jp/bbs/noz/wforum.cgi?mode=allread&no=5561#N5602
> みたいにハッシュが付いているリンクの場合とか。
> 違うなぁ……

私もリンクを書き込んだりしているので疑ったんですが、よくわからないです。

> あれ？　今度は VTDOS BBS の新着へのリンクが消えちゃったな。
> 消えたと言うか，a要素リンク内の値を括るダブルコーテーションが閉じていない？
> <tr><td><a href="http://tamaneko.world.coocan.jp/bbs/http://mezala.la.coocan.jp/bbs/noz/wforum.cgi?mode=allread&amp;no=5561#N5602' target='_blank' rel='noopener noreferrer' target='_blank' rel='noopener noreferrer'>???????e?[?}</a></td><td>11256</td></tr>
> 新着情報そのものは取得しているみたいだけれど，ダブルコーテーションの出力エラーで該当行以降が表示されないのと，他のBBSの不思議なリンクも中途半端に含まれていますね。
> もしかして弄っている途中でしたか？

VTDOS BBS もおかしくなってますね。その下のリンクまで消えてるし。
弄っているのは別名のやつなので、初めからこうだったのかなぁ？
上のa要素リンク関係が怪しい気はするんですが。

> なるほど、めざらさんの実験で、なんとなく見えてきたようです。
> konnoさんの使われているコードって、１つ分の発言全体から、ある特定の形式の
> URLを手がかりにして、本文だのなんだの不要なところを消して、<tr>から</tr>に
> はさまれた形に変換しているのでしょう。

その通りです。今見ると何をやってるかチンプンカンプンで、誰がこんなの作ったの〜状態です。

> ここで使ってるのは正規表現置換と見た。置換一発か複数発かはわかりませんが。
> でも、今回、その特定の形式に該当してしまうURLが１つの発言に複数含まれて
> しまった、ということかと。
> 今までは、仮にURLがあっても、その特定の形式に該当するものではなかったので
> 発病しなかった、のではないかなぁ。

これが原因のような気がしますね。
色々試したのですが良くならなくて、泥縄の限界かな。

> なので、正規表現を駆使して、何番目に該当するものだけ残す、みたいにすれば
> 解決しそうな気がする。

これを試してみようと思いますが、正規表現がもうわからない。(>_<)

> > 今までは、仮にURLがあっても、その特定の形式に該当するものではなかったので
> > 発病しなかった、のではないかなぁ。
> これが原因のような気がしますね。

試しに野ざらし言の私の発言内のリンクを消してみたら正常になりました。
でも、VTDOS BBS 以降は消えたままです。(>_<)

この辺を色々弄ってみます。(^^;

なんとか泥縄を重ねて見た目は正常になりました。(^^;

> > > 今までは、仮にURLがあっても、その特定の形式に該当するものではなかったので
> > > 発病しなかった、のではないかなぁ。
> > これが原因のような気がしますね。

やはりこれが原因だったようです。
フラグ変数を一つ増やして、リンク処理ルーチン内でカウントさせました。

> 試しに野ざらし言の私の発言内のリンクを消してみたら正常になりました。
> でも、VTDOS BBS 以降は消えたままです。(>_<)

野ざらし言の私の発言内のリンクを元に戻しても正常になりました。＼(^^)／ ﾔｯﾀ-
でも、VTDOS BBS 以降が消えたままなのがわからなくて、古いルーチンで動いていたので
追加挿入してみたら、本来のルーチンも正常に表示されるようになりました。何で？
仕方がないので古いルーチンを一部残しておくことにしました。2重処理です。(^^;

＃　私が（プログラムを）織っている姿（ソース）は決して覗かないでください。

無事に治ったようですね。めでたい。

> なんとか泥縄を重ねて見た目は正常になりました。(^^;

うん、まぁ、いいんじゃないでしょうか。
ただ、これは異常ではないのでしょうが、いささか意味不明というか。
なにかというと、「今日のテーマ」の一覧の上、「Virtual Zone」の日付のうしろ、
なんか謎の「(0)」がいくつか並んでいる。
ついでに言うと、ここの部分、</FONT>の閉じタグが多い。

あと、ざっくり見ただけなので間違いもあるかもしれませんが。
「MS-DOS Player」の日付のあとの部分、なんか改行が過剰？
それと、全体的に<a></a>と<b></b>のネストが互い違いになっているような気がする。
これ、あとから改造しようとしたときにえらいことになりそうな気がするので、今の
うちにきれいにしておいたほうが良いかと。
それと、もしかしたらうちのブラウザのせいかもしれませんが。
リンクの中の実体参照「&」と「&amp;」がなんかうまくない気もする。
ただ、この混在、この「今日のテーマ」本体でもあちこちあるような。
どこまで気のせいか、というのがわからないのが現在の私の弱点。
konnoさんにおかれましては、複数のブラウザでチェックされることをお薦めします。

> ＃　私が（プログラムを）織っている姿（ソース）は決して覗かないでください。

どこからもケチがつかないような美しいものを織り上げられる人だけがこのせりふを
口にする資格があるような気がするのは、やっぱり私の気のせいか。

> なにかというと、「今日のテーマ」の一覧の上、「Virtual Zone」の日付のうしろ、
> なんか謎の「(0)」がいくつか並んでいる。
> ついでに言うと、ここの部分、</FONT>の閉じタグが多い。

この「(0)」は、コメントのチェックです。
 #9804：新着情報のメンテナンス、ココログのコメント数表示  konno 　 2020/10/02
この辺で話題にしていました。思ったより最近な感じですね。(^^;
動作確認のためにコメント入れてみました。(^^;

</FONT>の閉じタグ、多いですね。(^^;　なんとか修正しました。

> あと、ざっくり見ただけなので間違いもあるかもしれませんが。
> 「MS-DOS Player」の日付のあとの部分、なんか改行が過剰？
> それと、全体的に<a></a>と<b></b>のネストが互い違いになっているような気がする。

これらも大体修正しました。

> それと、もしかしたらうちのブラウザのせいかもしれませんが。
> リンクの中の実体参照「&」と「&amp;」がなんかうまくない気もする。
> ただ、この混在、この「今日のテーマ」本体でもあちこちあるような。

これはこれから見ていきたいと思います。
そういえば、板塀への番号ジャンプ、いつから出来なくなったんだろう。

> > ＃　私が（プログラムを）織っている姿（ソース）は決して覗かないでください。
> どこからもケチがつかないような美しいものを織り上げられる人だけがこのせりふを
> 口にする資格があるような気がするのは、やっぱり私の気のせいか。

真に美しいものは公開されても、誰もが称賛し、歴史に残るものですよね。
表が綺麗に見えても裏側はボロボロの継ぎはぎだらけ、と言う方が合っているかも。(^^;
というか、見てしまったのですね。知られたからには元に戻らなくてはなりません。

＃　ああ、飛ぶための羽が無い！ (;_;)

> この「(0)」は、コメントのチェックです。
>  #9804：新着情報のメンテナンス、ココログのコメント数表示  konno 　 2020/10/02
> この辺で話題にしていました。思ったより最近な感じですね。(^^;
> 動作確認のためにコメント入れてみました。(^^;

そんな話題もありましたか。もうすっかり忘れています。
なるほど、括弧の中の数字、今見たらゼロではなく１になっているのもある。
そういうことでしたか。

タグのネストの互い違い、まだひとつかふたつはありそうですが、大勢に影響は
ないでしょう。
ただ、末尾のほう、</m>という閉じタグがあるようなんですが、これはなんだろう。

> そういえば、板塀への番号ジャンプ、いつから出来なくなったんだろう。

ん？
何か挙動が変わりました？
私のほうはいじった記憶はありません。
だけど、変化してしまうことはままあるわけでして。
具体的に、どこがどう、ということを書いていただければ調べますよ。

> ただ、末尾のほう、</m>という閉じタグがあるようなんですが、これはなんだろう。

あう、試しに入れたものを削除するのを忘れてました。意味なしです。m(__)m

> > そういえば、板塀への番号ジャンプ、いつから出来なくなったんだろう。
> ん？
> 何か挙動が変わりました？
> 私のほうはいじった記憶はありません。
> だけど、変化してしまうことはままあるわけでして。
> 具体的に、どこがどう、ということを書いていただければ調べますよ。

えーと、いくつかあるんですが、まず新着情報の「新着」リンクが掲示板トップになってしまいます。

print "　<a href='http://toshiki.la.coocan.jp/bbs.html?mode=newsort' target='_blank' rel='noopener noreferrer'><b>やしきの\板\塀(新着)</b></a>　　
\n";
リンクのURLは
http://toshiki.la.coocan.jp/bbs.html?mode=newsort

あと、新着情報の「データ元」項目の発言番号リンクが掲示板トップになってしまいます。
リンクのURLは、番号が 4098 なら
http://toshiki.la.coocan.jp/bbs.html?mode=article&no=4098

あと、うちの掲示板からの番号リンクが掲示板トップになってしまいます。
>   やしきの板塀#00001	2003/03/31(Mon)〜
リンクのURLは
http://toshiki.la.coocan.jp/bbs.html?mode=article&no=00001

どうでしょうか。

> 新着情報の「新着」リンクが掲示板トップになってしまいます。

これは新着情報開設当初からの状況です。
板塀が個別のアーティクルへの直リンクを禁止しているのかと思っていました。
違うのですか？

> これは新着情報開設当初からの状況です。
> 板塀が個別のアーティクルへの直リンクを禁止しているのかと思っていました。
> 違うのですか？

記憶が朧気なので過去ログ検索したら

#9335：サイトのメンテナンス：新着情報の更新 Ver 0.73 　konno 　 2019/09/10
> > あ、確認ですが、URLは bbs.html?mode=newsort になっていますよね。
> やってみたら、板塀の新着記事に飛ぶことが出来ました。＼(^^)／ ﾔｯﾀ-

この時は出来ていたようです。

経緯としては……
板塀の個別のアーティクルや新着への直リンクができなかった
＞板塀は元々直リンク可能な仕様だがめざらの環境だけできないなら修正困難
＞＞『出来ました。＼(^^)／ ﾔｯﾀ-』とこんのがよろこんだ
＞＞＞めざらはあきらめた
＞＞＞＞さいはつした
♪たらら らったら〜♪

こんな感じ。(^_^;)

> > 新着情報の「新着」リンクが掲示板トップになってしまいます。
> これは新着情報開設当初からの状況です。
> 板塀が個別のアーティクルへの直リンクを禁止しているのかと思っていました。

板塀管理者としては、フレーム無しの表示は禁止したいと思っています。
が、フレーム内には個別アーティクルが表示されるようにしたい。
そのため、いささかどころではないトリッキーな手法を使っているわけです。
もし、フレーム内に個別アーティクルが表示されないとしたら、それは板塀管理者
の意図した挙動ではありません。
まずいなぁ。

ご指摘いただいた

> リンクのURLは
> http://toshiki.la.coocan.jp/bbs.html?mode=newsort

> リンクのURLは、番号が 4098 なら
> http://toshiki.la.coocan.jp/bbs.html?mode=article&no=4098

> リンクのURLは
> http://toshiki.la.coocan.jp/bbs.html?mode=article&no=00001

これらのURL、板塀管理人としては、そのようにリンクしてほしい、まさに希望通り
のものです。そして、フレーム内にそれぞれの発言が表示されることを意図している
のですが、現在、どうやらそのような挙動を示していない、ということですね。
とりあえず、現時点で、サーバを設置してある自宅内のサーバ以外のマシンから
チェックすると、なんとなくうまく動いている感じ。ただし、チェックはFirefox
だけでしか行われていません。
たとえば、Edgeとかだとセキュリティの関係で私の意図したとおりの挙動を示さない、
とか、自宅内だけはネットワーク構成の関係でうまくいく、とかがありうるので、
この辺を手がかりに追いかけて見ます。
ただ、例えば１時間後に「これが原因！」とか見つかるかもしれませんが、それの
確認は、早くて月曜日になる予定。

ということで、しばらくお待ちください。

> ただ、例えば１時間後に「これが原因！」とか見つかるかもしれませんが、それの

原因は見つかりました。解決は困難です。

現在、フレーム内に個別発言などを表示させるためにリファラを使っておりました。
ところが、Chromeだと2020年8月ごろのバージョンから、Edgeだと2021年9月ごろの
バージョンから、必要となるこの情報を与えてくれないようになってしまっていたの
でした。ちなみに、Firefoxも2021年3月ごろのバージョンでこの情報が与えられない
ようになっていたのですが、うちの試験環境はもっと古いバージョンだったので問題
が発生しなかった模様。あれ、でも、うちの実環境では、つい最近もFirefoxの更新
をしていたはず。もしかして、自宅内からはEdgeやChromeでもいけてしまうのかも。

ええっと、どうしようかな。
ちょっと模索してみますが、もしかしたらフレーム式を解除して直リンク可能にする
かもしれません。自宅サーバのIPアドレスが変わったときの処理が面倒なんですけど
ね。

あ、そうだ、もしも上記のバージョン以前のブラウザでもめざらさんのところでは
不具合が発生していたとすると、それは別の原因の可能性があります。たとえば、
ブラウザのセキュリティを厳しく設定していただとか、セキュリティが厳しめの
マイナーなブラウザを使っていたとか。
もし差し支えなければ、めざらさんの環境をお教えいただけると幸いです。

ということで、しばらくお待ちください。

こちらの環境は，メインが Firefox で，サブが Chrome です。
版は，概ねその時点の最新版です。ブラウザだけはさっさと更新するので。

で，「新着情報」の「やしきの板塀(新着)」リンクから新着表示ができたことは，
記憶する限り，たぶんおそらくたしかにかつて一度たりともありません。

各ブラウザのセキュリティ設定などは，それほど厳しくないと思います。
ごく標準的と言うか，ほとんどのクッキーは受け入れ，スクリプトの実行も許可，
ポップアップとかリダイレクトなんかもほぼ制限していなかったりします。

> ♪たらら らったら〜♪
> こんな感じ。(^_^;)
ああ、そんなことしたら妄想が暴走して・・・

その日、巨大な壁に鎧のとしきが穴を開けた。
我々はその穴を使って自由に壁の中に出入り出来るようになった。
だがその穴は始祖の巨人たちに塞がれてしまったのだ。
どうする？

　あきらめる
　助けを求める
> 勇者が現れる

♪た〜たらたったたた た〜♪

> 原因は見つかりました。解決は困難です。
> 現在、フレーム内に個別発言などを表示させるためにリファラを使っておりました。
> ところが、Chromeだと2020年8月ごろのバージョンから、Edgeだと2021年9月ごろの
> バージョンから、必要となるこの情報を与えてくれないようになってしまっていたの
> でした。ちなみに、Firefoxも2021年3月ごろのバージョンでこの情報が与えられない
> ようになっていたのですが、うちの試験環境はもっと古いバージョンだったので問題
> が発生しなかった模様。あれ、でも、うちの実環境では、つい最近もFirefoxの更新
> をしていたはず。もしかして、自宅内からはEdgeやChromeでもいけてしまうのかも。

なるほど、2019年9月には出来ていたけど2020年8月から出来なくなったのですね。
私は Firefox だったので、2021年9月から使えなくなったのでしょうが、覚えてない。(^^;

> ちょっと模索してみますが、もしかしたらフレーム式を解除して直リンク可能にする
> かもしれません。自宅サーバのIPアドレスが変わったときの処理が面倒なんですけど
> ね。

なんとかよろしくお願いいたします。m(__)m

> もしかして、自宅内からはEdgeやChromeでもいけてしまうのかも。

いけませんでした。
というか、そもそも新着情報に対するアクセス履歴が著しく少ない。
Chrome系のブラウザはアクセス履歴って３カ月程度で消えてしまうわけですが、Firefox
だと容量の許す限りアクセス履歴が残ります。それを見たところ、実環境の方では、
2019年10月以来でたった６回しかアクセスしていない。さっき、実験でアクセスした
のが７回目。
古い実験環境の方はもっとアクセスしていましたが、それでも2021年5月以来でたった
23回しかアクセスしていない。
なので、昔の、可能だった時代のおぼろげな記憶をいつまでも覚えていただけ、という
のが正解の模様。

それと、めざらさんのところでは昔から駄目だったとのことですが、Firefoxでいう
ところのプライベートブラウジングとかプライベートウィンドウという、セキュリティ
の厳しいモードを使っています、ということはないですよね。これ以外に新着情報が
始まった当初のブラウザでうまくいかない理由が思いつかない。
今となっては原因不明の迷宮入りになってしまうと思います。

履歴が辿れなかったり，いちいちID／パスを入れないと閲覧できないような
不便なことは，かつてやったことがありません。自分ながらセキュリティに
とことん甘い人間だなぁ……と思います。

とにかく，いろいろな仕掛けを施している開設者にわからないことが
自分にわかるはずもないので，早々にあきらめていたわけですから，
記憶も曖昧なはずです。できていたことがあったと言われても，
いよいよまったく一切実感はありません。

ところでフレームを採用している理由って何ですか？
単に掲示板タイトル他を常に表示させたいなんて単純な理由とも思えませんが。
そもそも，わたしみたいにいきなりフレームの区切り線をぎゅぎゅっと上端へ
移動してしまうような人間には，あまり意味がないわけですが。

> Chrome系のブラウザはアクセス履歴って３カ月程度で消えてしまうわけですが、Firefox
> だと容量の許す限りアクセス履歴が残ります。それを見たところ、実環境の方では、
> 2019年10月以来でたった６回しかアクセスしていない。さっき、実験でアクセスした
> のが７回目。

私は Firefoxですが、#11267 の書き込みで

> #9335：サイトのメンテナンス：新着情報の更新 Ver 0.73 　konno 　 2019/09/10
> > > あ、確認ですが、URLは bbs.html?mode=newsort になっていますよね。
> > やってみたら、板塀の新着記事に飛ぶことが出来ました。＼(^^)／ ﾔｯﾀ-

この時は間違いなく出来ていたと思います。
私は板塀の記事はほぼ毎回読んでいますが、必ず新着記事で読みます。
新着記事に飛ばなくなっても、ツリー画面で新着にして読んでいます。
なので、随分少ないなという印象ですね。
すぐに飛べなくなってしまったのかなぁ。

> 古い実験環境の方はもっとアクセスしていましたが、それでも2021年5月以来でたった
> 23回しかアクセスしていない。
> なので、昔の、可能だった時代のおぼろげな記憶をいつまでも覚えていただけ、という
> のが正解の模様。

昔って、もしかして 2009年のころでしょうかね。
#3814： 他の板への番号リンク 投稿者： konno 　 2009/06/04

> 現在、３サイトで過去ログを含めた発言番号リンクが実現できているので、どうせなら
> 他の板へも番号リンクをしたいと思い、テスト板#test41で試してみて、良さそうなので
> 公開します。(^_^)
> 
> 　　　2文字案　最終案
> -----+-------+-----------------------------
> #kyo　#k3008　#kyo3008へ(今日のテーマ板)
> #faq　#f0010　#faq10へ　(VzFAQ板)
> #link #l0008  #link8へ　(リンク板)
> #test #t0041　#test41へ (テスト板)
> #n　  #n3340  野ざらし言3340番へ
> #i　  #i1597  板塀1597番へ

このころは直リンクでやっていたのでしょうね。
直リンクであっても番号ジャンプ出来るのなら私はうれしいです。

> とにかく，いろいろな仕掛けを施している開設者にわからないことが
> 自分にわかるはずもないので，早々にあきらめていたわけですから，

当時のその段階で不具合報告をいただければ、いろいろと追及して、一時的ではある
かもしれませんが、それなりの解決には結びついたとは思うんですよ。いささか残念
ではあります。

> ところでフレームを採用している理由って何ですか？

これは、#7717にちょっとだけ書きましたが、自宅サーバのIPアドレスが変わって
しまっても、一意のURLでアクセスできるようにする、という目的でした。
cf. http://toshiki.la.coocan.jp/computer/itabei/frame.html

ただ、環境の変化というか時代の変化で、いろいろなものが使えなくなっていくと
いう現実があるわけで。仕方ない、こちらが対応するしかありませんね。

> 新着記事に飛ばなくなっても、ツリー画面で新着にして読んでいます。
> なので、随分少ないなという印象ですね。

私の場合、konnoさんが新着記事を作られるよりも前に、各掲示板のブックマークを
作っていましたからね。新着記事がリリースされた当時は何回もアクセスしました
が、通常は以前からの慣例で、そのままブックマークからのアクセスを継続していた
のですよ。


> 直リンクであっても番号ジャンプ出来るのなら私はうれしいです。

いろいろと考えたのですがね。
なにぶん、セキュリティが絡みますから、私の技術力では実装可能かどうかすら
わからないようなトリッキーな方法しか思いつかなくて。
ここはやはり素直に、フレーム方式廃止、直リンク可能という形に落ち着きそうです。
ただ、少なくとも向こう数日は多忙が見えている。
他人のHDDの復旧、なんていうタスクが割り込んできたもので。
おそらく、早くても６月中、ぐらいの速度感。
もちろん、それ以上かかるかも。

ごめんなさい，読んでいたはずなのに，まるで忘れてました。

> 当時のその段階で不具合報告をいただければ、いろいろと追及して、

まぁ，人んちの掲示板ですから，あんまり要求じみたことを言うのもナニかなと思って。

ふと思ったのですが、「としきのやしき」は現在 nifty の la.coocan.jp になっているのですよね。
板塀だけケーブルテレビのサーバーなのでしょうか。
掲示板を la.coocan.jp の中に入れてフレームを無くせば解決しそうな気が。
もちろん手間がかかるでしょうが、直リンクのURLが変わるたび修正するよりはましと思います。
外していたらごめんなさい。

ほら、めざらさんが困っているということは他の人も困る可能性があるということ
なんで。
というのは建前で。
自分のところのものはなるべく完成度を高くしたい、という思いもありまして。
いわば私利私欲というか。
ということで、もし次の機会がありましたら、その際にはぜひ。

> 板塀だけケーブルテレビのサーバーなのでしょうか。

そのとおりです。

> 掲示板を la.coocan.jp の中に入れてフレームを無くせば解決しそうな気が。

確かにその手はあって、将来、板塀サーバーマシンをどうにも確保できなくなった
場合には、その方向に行く可能性は高いです。
ただ、これはいわゆる「半土塀化」という感じ。
「完全土塀化」というのは、レンタルサーバーあたりを借りて、そちらで掲示板を
運用する形を意図しています。
「半土塀化」と「完全土塀化」は、取得できる情報がごくわずかに違う。
普通の人なら、まず気にしないような些細な部分なんですけどね。
例えば、平常時に取得できるログには、ほとんど差異はない。
でも、異常時のログは、ずいぶん違う。
例えば、

http://（略）.jp/bbs/wforum.cgi

という形でアクセスすれば、普通にアクセスログが取れます。
ところが、これのURLを誤って

http://（略）.jp/bbs/wforu.cgi

なんて形でアクセスがあった場合。
現在の板塀ではきちんとログが取れているし、レンタルサーバーなんかの場合でも
たいていはログが取れます。でも、la.coocanの場合、このログを確認できるのは
ニフティの中の人だけ。
ということで、実に些細な点で、konnoさんの推奨されている方法にはいささかの
抵抗感があるわけですよ。
ま、でも、将来的にはそういう抵抗感を打ち破ってその方向に行きそうな気がする。

> ということで、実に些細な点で、konnoさんの推奨されている方法にはいささかの
> 抵抗感があるわけですよ。

わかりました。個人の掲示板なので、自分がやりたい形でやるのが一番ですよね。

> ま、でも、将来的にはそういう抵抗感を打ち破ってその方向に行きそうな気がする。

ユーザーとしては便利であればトリッキーであろうが気になりません。(^^;
私もとしきさんのコンテンツを真似て新しいコンテンツをやろうと思っています。
喜ぶユーザーさんもいると思いますので。(^^;


＃　イタ・ベイエリア突破出来ません！
　　事案は机の上じゃなく机の下で起こっているんだ！

としきさんのコンテンツを真似て新しいコンテンツを始めました。
niftyのFGALDC会議室の自分の発言を掲示板のツリー形式で表示させます。

　FGALDC会議室の過去ログ　　VZ改造秘話など 
http://tamaneko.world.coocan.jp/bbs/bbs6/wforum.cgi


VZK誕生の改造秘話とか、ここの常連さんにはわかりきった話ですが、
少しは需要があるだろうと思います。
また、私の自伝的な意味合いもあります。
名前やＩＤなどの個人情報や引用符などは修正しています。

改造人間誕生秘話、とか
差異膨愚009誕生、とか
面白いタイトル募集！

私の発言が主体ですが、他の方の発言も引用というていで載せたいと考えています。
それはまずいよとか、載せないでなどの意見があれば削除など検討します。
ご意見、ご感想をお待ちしています。(^_^)

> niftyのFGALDC会議室の自分の発言を掲示板のツリー形式で表示させます。

おぉ、これは期待大ですね。
ところでこれ、Vzのマクロか何かでやっていますよね。
まさか手作業だったりして。
うちの場合はawkのスクリプトでやりました。

> 少しは需要があるだろうと思います。

そう頻繁に見るものではありませんけどね。
なんかの場合に必要になりそう。
あと、検索エンジンの検索に引っかかるようになる、というのが地味に大きな影響を
もたらしたりして。
それと、めざらさんも以前におっしゃったことがあったように思いますが、各改造
バージョンの仕様とか特徴がわかるようになるのもうれしいかも。

> それはまずいよとか、載せないでなどの意見があれば削除など検討します。

うちではもう何年もやっていますが、要望が来たのは１回だけ。
当時（今でも？）ご活躍の方でしたが、発言者名が実名だったもので、これを消して
ほしいというものでした。現在でも、その人の発言した部分が数ヶ所、空白表示と
なっています。幸い、問題となったのはツリーインデックスの部分だけでした。私の
発言本体の引用などには絡んでいなかったので、それ以上の対応はせずにすみました。

> ご意見、ご感想をお待ちしています。(^_^)

なんでもそうなんですが、データって大量に集まってこそ意味を持つもの。
例えば、日本のラジオドラマの過去一覧とか。
なので、物量は多ければ多いほどよい。
もちろん、フリートークとかは不要な可能性が高いですが、私の場合、そういうもの
を峻別するのが面倒だったので、ごく一部の危険なものをのぞき、全部アップして
しまいました。ということで、konnoさんにおかれましても、物量優先のスタンスで
どうかなにとぞ。

> ところでこれ、Vzのマクロか何かでやっていますよね。
> まさか手作業だったりして。

そのまさかの手作業です。(^^;
ツリー構造を見るために、あじゃさんの NIF_TREE.def を別窓で開いて参照しました。
素晴らしいマクロですね。あじゃさんに感謝です。

> うちの場合はawkのスクリプトでやりました。

さすがですね、私は今考える気力が無くて、VZなら手作業でもかなり効率的だし。
一昨日思いついてとりあえず形になったので公開しました。(^^;

でも今見たら新着記事とか会議室風の日付表示や並び順が合ってない。(>_<)
UNIX時間でソートしてるんですね。これの変換が面倒なのでスルーしてました。(^^;
仕方がないので発言番号を数字に取り込むマクロをでっちあげました。(^^;

うう、アイドルのツリーが大きすぎてまだ終わらない。(;_;)
これだけで147もあるんだもん、邪悪じゃぁ〜

> うちではもう何年もやっていますが、要望が来たのは１回だけ。
> 当時（今でも？）ご活躍の方でしたが、発言者名が実名だったもので、これを消して
> ほしいというものでした。現在でも、その人の発言した部分が数ヶ所、空白表示と
> なっています。幸い、問題となったのはツリーインデックスの部分だけでした。私の
> 発言本体の引用などには絡んでいなかったので、それ以上の対応はせずにすみました。

やはり実名は不味いですよね。(^^;
引用については今まで問題になっていないので、私の発言へのコメントは掲載したいですね。
その他は流れを読んで問題なさそうなら・・・

> なんでもそうなんですが、データって大量に集まってこそ意味を持つもの。
> 例えば、日本のラジオドラマの過去一覧とか。
> なので、物量は多ければ多いほどよい。
> もちろん、フリートークとかは不要な可能性が高いですが、私の場合、そういうもの
> を峻別するのが面倒だったので、ごく一部の危険なものをのぞき、全部アップして
> しまいました。ということで、konnoさんにおかれましても、物量優先のスタンスで
> どうかなにとぞ。

そうですね、情報としての価値もあると思うので、本当は丸ごとアップしたい気持ちです。
まあ、まずは私の発言だけでも纏めなくてはですね。

> ツリー構造を見るために、あじゃさんの NIF_TREE.def を別窓で開いて参照しました。
> 素晴らしいマクロですね。あじゃさんに感謝です。

私もこのマクロ、めざらさんに紹介していただいたのではなかったかな。
以前はかなり頻繁に利用していました。特にポケ３では。

> さすがですね、私は今考える気力が無くて、VZなら手作業でもかなり効率的だし。
> 一昨日思いついてとりあえず形になったので公開しました。(^^;

考える気力はないのに行動する気力はある、というのがkonnoさんの不思議なところ。

> UNIX時間でソートしてるんですね。これの変換が面倒なのでスルーしてました。(^^;

UNIX時間→日本時間に変換するマクロは、もう１０年以上前にめざらさんに作って
いただきました。逆方向のマクロは、konnoさんに作っていただく、ということで。

> やはり実名は不味いですよね。(^^;

でも、実名っぽいハンドル名、という人もいたわけだし。
私の場合、依頼をいただいたその人の場合は特に疑う理由もなかったのだけど、
実は全くの赤の他人が連絡してくる、という可能性もあるわけで、それを理由に
蹴っ飛ばす、というのもあってもいいかも。
さらに、発言者名とタイトルが組み合わさるとまずい、とかあるわけですが、その
人の場合も、発言者名とフォーラム名が組み合わさるとまずい、というパターンに
近くて。
ま、いろいろと出てくる可能性があるわけですよ。

> そうですね、情報としての価値もあると思うので、本当は丸ごとアップしたい気持ちです。

フォーラム末期に「自分の発言は他所に公開可」という表明をなされた方々もいらっしゃった
はずです。そういう人の分だけでも公開してもいいかも。そして、文句が来たら消す、と。

> 私もこのマクロ、めざらさんに紹介していただいたのではなかったかな。
> 以前はかなり頻繁に利用していました。特にポケ３では。

ポケ３でも使えるとはやっぱり凄いですね。
同一ツリーの発言を視覚的に追えるのは便利ですよね。
といっても私は今までほとんど使っていなかったです。
これを機会に使うようにしたいですね。

> 考える気力はないのに行動する気力はある、というのがkonnoさんの不思議なところ。

思いつくと直ぐにやってみたくなるのが性分みたいで。(^^;
おかげで簡単なマクロも思い出しながら作れました。(^^;

> UNIX時間→日本時間に変換するマクロは、もう１０年以上前にめざらさんに作って
> いただきました。逆方向のマクロは、konnoさんに作っていただく、ということで。

私には無理です。きっぱり

> でも、実名っぽいハンドル名、という人もいたわけだし。

うーん、そこは自己判断でいいんじゃないでしょうか。(^^;

> フォーラム末期に「自分の発言は他所に公開可」という表明をなされた方々もいらっしゃった
> はずです。そういう人の分だけでも公開してもいいかも。そして、文句が来たら消す、と。

おお、それがありましたね。ではそれを踏まえてなるべく掲載する方向で行きたいと思います。

> でも今見たら新着記事とか会議室風の日付表示や並び順が合ってない。(>_<)
これは修正に難儀しましたが、なんとか修正出来ました。

急かすわけでもなく，気が向いたらで構わないのですが，
「新着情報」を少し修正していただけると有り難いかなと思って。

ささやかに，3点だけです。(笑)

1　日時の表示
現在，野ざらしだけ日付と時刻の間にデリミタがありません。
ほかの掲示板はスペースが入っています。
スペース1個で構わないので分かち書きしていただけると嬉しいです。

2　新着記事へのリンク
現在，野ざらし言(新着) へのリンク文字列は「(新着)」部分を含めていません。
板塀はわかりやすいリンクになっています。（飛べる飛べないは別として）
板塀と同じようにしていただけると嬉しいです。

3　個々のアーティクルへのリンク
現在は掲示板名から各アーティクルを訪ねてくださるわけですが，
同じリンク文字列から別のリンク先に飛ぶのは個人的に違和感があり，
番号をリンク文字列にしていただけると嬉しいです。


新着情報だから掲示板トップへのリンクはないのか……

> 急かすわけでもなく，気が向いたらで構わないのですが，
> 「新着情報」を少し修正していただけると有り難いかなと思って。
> ささやかに，3点だけです。(笑)

時間が取れたら見てみます。

> 新着情報だから掲示板トップへのリンクはないのか……

これも検討してみます。お待ちください。

> ポケ３でも使えるとはやっぱり凄いですね。

とはいえ、私の記憶だと、ポケ３の場合、ECS常駐というか２５行モードにしないと
使い物にならなかったような。当時は今よりも目がよかったので細かい字でも見え
ましたし。
ただ、そうして記憶をたどっていくと、いくつか芋づる式に思い出して。
NIFPのＦＭ版というのが、確かポケ３でも動いたような。これも２５行モードだけ
だったかなぁ。
だけど、読むときはともかく、レス書きするときにはこういう細かい字のものは
使わなかったような記憶があって。また、ツリーインデックスとログ本体を上下分割
ではなく全画面の裏画面と表画面にして、[F2]で切り替えていたような記憶もあり。
うんうんうなっていたのですが、何か手がかりはないかとDCのログを「nif_tree」で
検索したら、あっさり出てきました。
nifty:FGALDC/MES/13/#7313
あ〜、このツリーも、なんか異様にでかいなぁ。
ということで、

> > 以前はかなり頻繁に利用していました。特にポケ３では。

「頻繁に」という部分はどうやら記憶違いのようです。
大変失礼しました。

> 私には無理です。きっぱり

ためしに、私が作ったらこうなりました。

= tmp
*m
89 ^\ "" #59 #E "mawk32 'BEGIN{print strftime($"%%Y/%%m/%%d %%H:%%M:%%S$","
         #I ")}'" #m

*

DOS窓で動作確認済み。
gawkとかjgawk、あるいはVTDOSやDOSVAXだと、クォートの処理とかが異なるかも。

> これも検討してみます。お待ちください。

やってみたら出来ました。

> > 新着情報だから掲示板トップへのリンクはないのか……
新着は、掲示板トップと別けて並べてみました。

> 1　日時の表示
これは余分な情報を削除するところでスペースまで消していたのが原因でした。

> 2　新着記事へのリンク
新着は、掲示板トップと別けて並べてみたので、慣れるまでは違和感あるかもです。(^^;

> 3　個々のアーティクルへのリンク
> 番号をリンク文字列にしていただけると嬉しいです。
やってみたら掲示板のタイトルの項目がいらなくなってしまったので繋げてみました。
Parlの書式文法をわかってないのでこれが一番苦労しました。(^^;

> うんうんうなっていたのですが、何か手がかりはないかとDCのログを「nif_tree」で
> 検索したら、あっさり出てきました。
> nifty:FGALDC/MES/13/#7313
> あ〜、このツリーも、なんか異様にでかいなぁ。

NIF_Tree.def で見たら 51レスありますね。(^^;
後で読ませていただきます。(^^;
NIF_Tree.def やっぱりすげぇ！

> > 私には無理です。きっぱり
> ためしに、私が作ったらこうなりました。
> DOS窓で動作確認済み。
> gawkとかjgawk、あるいはVTDOSやDOSVAXだと、クォートの処理とかが異なるかも。

うう、その手があったか。
私はその手のツールを持ってないのでまずどこかに落ちていないか探しに行かなくては。

＃　こうしてとある冒険者は新たな苦難の旅に出るのであった。

> ＃　こうしてとある冒険者は新たな苦難の旅に出るのであった。

ご愛読ありがとうございました。
konno先生の次回作にご期待ください。
＃いや、終わってないから

ご苦労ってほどではなかったと存じますが，お疲れ様でした。
早速の対応，有難うございました。（気になるなら言ってみるものですね）

> ご愛読ありがとうございました。
> konno先生の次回作にご期待ください。

こんなことを言われると何だかこそばゆいですね。（だから終わってないってば）
というか、すぐに戻ってきてはいけない雰囲気。(^^;

> gawkとかjgawk、あるいはVTDOSやDOSVAXだと、クォートの処理とかが異なるかも。

gawk.exe を落として試してみましたが、エラーになるようです。
それで、例題の mawk32 というのを落として

> 89 ^\ "" #59 #E "mawk32 'BEGIN{print strftime($"%%Y/%%m/%%d %%H:%%M:%%S$","
>          #I ")}'" #m

これを試したらキチンと結果が出ました。＼(^^)／ ﾔｯﾀ-
・・・私が欲しかったのはこの逆の変換でした。(;_;)

＃　無駄ではない・・・こうして木馬を追い込めたのだからな。（謎）

> ご苦労ってほどではなかったと存じますが，お疲れ様でした。

いやぁ、野ざらし言のリンクを修正するのに数時間試行錯誤してましたから。(;_;)

> 早速の対応，有難うございました。（気になるなら言ってみるものですね）

バグ報告などはどんどん言ってください。直せるかはわかりませんが。(^^;

それでは，お言葉に甘えまして。

現在，板塀へのリンクはふつうに開くわけですが，野ざらしへのリンクは別窓で開きます。
予告なく別窓で開くことは，アクセシビリティ上好ましくないとされています。
なので，野ざらしへのリンクも板塀と同様にふつうに開くようにしていただけるでしょうか。

少なくとも，いや，できれば，リンクの開き方は統一してくださるようお願いします。
……というふうに考えると，今日のテーマほかの開き方も同じ窓で……となりますが，
家主様は嫌ですか？　そこはどちらにするか konno さんの胸ひとつです。

> 現在，板塀へのリンクはふつうに開くわけですが，野ざらしへのリンクは別窓で開きます。
> 予告なく別窓で開くことは，アクセシビリティ上好ましくないとされています。
> なので，野ざらしへのリンクも板塀と同様にふつうに開くようにしていただけるでしょうか。

あう、そういえば板塀だけが違っていましたね。
修正中に気が付いてはいたんですが・・・

> 少なくとも，いや，できれば，リンクの開き方は統一してくださるようお願いします。
> ……というふうに考えると，今日のテーマほかの開き方も同じ窓で……となりますが，
> 家主様は嫌ですか？　そこはどちらにするか konno さんの胸ひとつです。

めざらさんの希望はわかりましたが、私はここでは別窓で開きたいのです。
ニュースサイトなどでも別窓で開くリンクは結構あるように思います。

なので、次の更新では板塀も別窓で開くようにするつもりです。
あしからず。

スマホだったら動作を変えるとか出来ればいいんですかね。

＃　どうすればいいんじゃ〜

了解です。
統一していただければ問題はありませんので。
有難うございました。

nif_tree.def を使っていたら、いくつか不具合に遭遇しました。
文太さんに頂いた 1メガ超のDC過去ログを見ていたら
特定のファイルで、ジャンプ先が該当発言番号より手前になるんです。
具体的には DC14階の
2008/08/08  14:02         1,007,705 DC14~003.LOG
2008/08/08  14:09         1,017,395 DC14~021.LOG
この2つで現象が起きました。

古い nif_tree.def でも同じです。
各種DOSエミュ、各種VZ で同じ症状が出ます。
特定のファイルで出るということは、作成されているデータがおかしいかも。
nif_tree.def を起動すると、ログフォルダの下に CT フォルダが作られて
ログファイルと同じ名前の番号ジャンプデータが作られます。

件のデータは、文太さんから頂いた当時からあったものです。
2004/10/23  18:27            66,757 DC14~003.LOG
2006/09/14  16:25            57,826 DC14~021.LOG

結構古いデータですね。
このデータをリネームして新規データを作成したら、正常にジャンプしました。
この新旧データを比較したら、かなり違いがありました。
ジャンプ先アドレスはもちろん、コメントなどのツリー構造も違ってました。
初期の nif_tree.def のバグのようです。
飛び先がおかしいと思ったら、このデータを削除して作り直すのが良さそうです。


さて、これで安心、と思ったら、今度は起動に失敗するケースが有りました。
やはり同じ 1メガ超のDC過去ログです。
色々実験してみてわかったこと。

通常にログファイルをオープンした場合は正常に起動します。
オープン窓の履歴から開くと起動失敗しておかしくなります。
色々試してみると、どうやらテンポラリエラーになっているようです。
これも各種DOSエミュ、各種VZ で同じ症状が出ます。

ということで、テンポラリエラー対策を入れてみました。

nif_tree.def 67行目から

	#W

	ky[, #M ((wa..64)[) ((wa..63)[)
	mp[=2,ps[, eu[-,

　　↓

	#W	;---  DATA LOG 
;	---- テンポラリエラー対策  ★
	#M				;カーソル位置マーク
	&00 p=r,                        ;自前バッファ pの先頭アドレスを取得   ★
        &Le(p,wa+126)                   ;mark0の値をp先頭に擬似プッシュ      ★
	ky[, ((wa..64)[) ((wa..63)[)	;カーソル位置マーク、ロング
	pn.7=pn.8-,			; pn.7=pn.8-,: プロファイル呪文 m.gann
	#] (mr==1)?{ &a(37) (r<=0)?. }	; &Im(pn+7,0) としてもよい
	#L (s==4)?'n' #P #m mr$80,	; クローズ･オープン 
        &Le(wa+126,p)                   ;mark0の値をポップ      ★
	#U				;現在位置に戻す

	mp[=2,ps[, eu[-,


207行目の 09:  の前に

00:      (3+$)."$[8]"

を追加しました。
うまく動いているようです。

ということで、改造版 nif_tree.def v8c を公開します。

#txt:NIF_TR8c.DEF

右クリックで保存できます。
ファイル名が違っているのでリネームしてお使いください。

> スマホだったら動作を変えるとか出来ればいいんですかね。
色々やってみたんですが、うまくいかないの。(;_;)

ということで、変数一個で分岐させる方式にして、二つの CGIに別けました。(^^;

「タマの猫ハウス」トップページの一番下に

[ BBS 新着情報 ]  [ BBS 新着情報 携帯版 ]

このようにリンクを並べて置きました。

「新着情報」は、基本的にリンクを別窓で開きますが
「新着情報 携帯版」は、リンクを同じ窓で開きます。

URLをお気に入りに入れてお使いください。

> 初期の nif_tree.def のバグのようです。

つまり，0.8b のバグではないんですよね？

テンポラリファイルエラーも nif_tree.def の問題ではないですし，
「nif_tree.def v8b にバグ？」というタイトルはどうなのでしょうか。

作者が見たらどんな気持ちになるのか，ちょっと考えてしまいます。
相応の配慮が必要ではないでしょうか。

> この表示タイトルはどうなのでしょうか。
> 作者が見たらどんな気持ちになるのか，ちょっと考えてしまいます。
> 相応の配慮が必要ではないでしょうか。

うう、確かに勘違いさせてしまいますね。m(__)m
タイトルを変更しました。

「新着情報 携帯版」 Ver 09.3 更新しました。

「新着情報 携帯版」 でうちの掲示板を開くと、縮ツリーになるようにしました。
ツリー表示は長くなると画面をはみ出してしまうために幅を縮めたツリー機能は
以前から仕込んでありましたが、今回携帯版のリンク先を縮ツリーに変更しました。

今はトップのツリーだけですが、これからぼちぼちと連携を広げていきたいと思います。
不具合など見つけましら教えてください。

> 今はトップのツリーだけですが、これからぼちぼちと連携を広げていきたいと思います。

ということで、縮ツリーの時は、一括表示や記事閲覧のツリーも縮ツリー(簡易版）にしました。
掲示板上部の [縮ﾂﾘｰ] をクリックすると、表示が [ﾂﾘｰ] に変わります。これと同じ状態です。
[ﾂﾘｰ] をクリックすれば、通常のツリーに戻ります。
変数の受け渡しに苦労しましたが、おかげでだいぶ CGI がわかってきたかもです。

長すぎる邪悪なツリーが多いとお嘆きの諸兄は、是非お試しください。(^^;

「新着情報 携帯版」 Ver 0.94 更新しました。

・「新着情報 携帯版」 でうちの掲示板の番号をクリックすると、一括表示になります。
　今までは、一括表示のツリーは通常でしたが、携帯版リンクでは縮ツリーになるようにしました。

・ ( 新着 ) リンクから新着記事に飛んでトップのツリーに戻ると縮ツリーになるようにしました。

・「新着情報 携帯版」の不要な項目やスペースを削除などして幅を縮小しました。

・「新着情報 携帯版」のタイトルの色を変更して通常版との違いをわかりやすくしました。

・テスト掲示板と VZwiki のリンクを VTDOS の行に置いて、はみ出しを少なくしました。


不具合などありましたら教えてください。

wforum.cgi の縮ツリー関連を色々更新しました。

・タイトルが固定だったのをセンターに配置

・FGALDC会議室の専用CGI を統合

・返信フォームの幅調整
 
・その他リンクやデザイン等微調整

今回ブラウザの幅を狭くして確認したのでだいぶまともになったと思います。(^^;


不具合などありましたら教えてください。

いろいろと励んでおられますね。

> 不具合などありましたら教えてください。

今の所は気がついた点はないのですがね。
昨夜、この#11309が書き込まれた直後ぐらいだったかなぁ、一瞬だけ、縮ではない
ほうのツリーが、左寄せではなくセンタリングで表示されて。あぁ、やっている最中
だな、と思いました。

あと、率直な感想として、このようにいろいろとやられているkonnoさん、これだけ
新酒の起床ではない進取の気性にあふれているように見えるわけですから、ここから
一気にレスポンシブデザイン対応に突っ走ってみる、なんてことを期待したりして。

それと、ついでにいくつか。
スレッド表示というか「スレ１覧」をみると、なんかえらくリンクになっている部分
が多いような気がする。これって正しい挙動なんですか？
「スレ２」のほうも、ツリー一覧を意味する三角の上というか下というか、謎の数字
が表示されていますが、これは一体何？
ツリー全体の発言数なのか省略された発言数なのか全く関係ないのか。
そもそもこれは、この数字の上のツリーのものなのか下のものなのか。
こういう、いささか利用者に不親切なところを改善していただけるとありがたい。
現状では、あまりにも不親切というか、私の主観では廃止していただきたいという
くらい。もちろん、管理人が有効に使っているとか、他のお客様には大好評、という
現状があるのであれば、私のたわごとに耳を傾ける必要はありませんが。

> 昨夜、この#11309が書き込まれた直後ぐらいだったかなぁ、一瞬だけ、縮ではない
c> ほうのツリーが、左寄せではなくセンタリングで表示されて。あぁ、やっている最中
> だな、と思いました。

あら見てたのね〜 (^^;
老化現象なのか、OKと思ってUPするとボロがボロボロ出てくるんですよねぇ。(;_;)

> あと、率直な感想として、このようにいろいろとやられているkonnoさん、これだけ
> 新酒の起床ではない進取の気性にあふれているように見えるわけですから、ここから
> 一気にレスポンシブデザイン対応に突っ走ってみる、なんてことを期待したりして。

丁度その手のサイトを見てるんですが、むずいですねぇ。(^^;

> スレッド表示というか「スレ１覧」をみると、なんかえらくリンクになっている部分
> が多いような気がする。これって正しい挙動なんですか？

げげ、思い切りバグってますねぇ。(>_<)

> 「スレ２」のほうも、ツリー一覧を意味する三角の上というか下というか、謎の数字
> が表示されていますが、これは一体何？

これはそのツリーのコメント数です。
バグ直しついでに表示を変えました。スレ１とスレ２で見栄えが違うのはご愛敬で。(^^;

> もちろん、管理人が有効に使っているとか、他のお客様には大好評、という
> 現状があるのであれば、私のたわごとに耳を傾ける必要はありませんが。

他の方の評判はわかりませんが、私が使うために設置したのでこれは存続させます。

> げげ、思い切りバグってますねぇ。(>_<)

あら、やっぱりバグでしたか。なんでも言ってみるもんですねぇ。

> これはそのツリーのコメント数です。

表示が変わって、その上のツリーに関係するものだとわかりやすくなりました。
これはいいですね。
といいつつ、スレ２のほうは私にはほとんどニーズはありませんが、でもスレ１の
ほうは見やすくなったこともあって、たまには使わせていただきたいと思います。

「新着情報 」 Ver 0.941 更新しました。


・「新着情報 」と「新着情報 携帯版」を一つに統合しました。

URLの引数に 「?mode1=1」があると、携帯版として表示が切替わります。
今までの「携帯版」ファイル sinn2.cgi は明後日に削除しますので、お手数ですが
改めてトップページの「新着情報 携帯版」からリンクしてください。
それをブックマークし直せば OK です。

今はまだ画面幅で自動切換え出来ませんが、需要あるかしら？

「新着情報 」 Ver 0.942 更新しました。

・「新着情報 」の引数で画面サイズを 大 中 小 と選択出来るようにしました。
　　標準画面サイズを大として、90% で表示しています。
　　URLの引数に 「?wsize=2」があると、画面サイズが中(85%)
　　「?wsize=3」があると、画面サイズが小(80%) になります。

・携帯版の時は、西暦2桁表示にしたり、色々詰めるようにしました。

・更新したときの時間を2行目に表示するようにしました。

・最下行に、ブラウザの縦横サイズを表示しました。
　ブラウザのサイズを変えると表示が変わります。
　http://www.shurey.com/js/samples/1_tips10.html
　「Labyrinthe Noir」さんのサイトの「JSすぐに使えるサンプル集」を
　そのまま使わせてもらいました。

＃　この数値を Parl の変数にしたいんだけどわからないの。(;_;)

画面サイズの選択を増やしたい方は言ってくれれば検討します。

「タマの猫ハウス」トップページを更新しました。

・「新着情報 」のリンクで画面サイズを 大 中 小(携帯版) に選択出来るようにしました。
　　標準画面サイズを大として、90% で表示しています。
　　画面サイズ中(85%)を選択すると URLの引数に 「?wsize=2」が付きます
　　画面サイズ小(80%) 携帯版では「?mode1=1&wsize=3」が付きます

・最下行に、ブラウザの縦横サイズを窓表示しました。
　ブラウザのサイズを変えると表示が変わります。
　http://www.shurey.com/js/samples/1_tips10.html
　「Labyrinthe Noir」さんのサイトの「JSすぐに使えるサンプル集」を
　そのまま使わせてもらいました。

＃　この数値を Parl の変数にしたいんだけどわからないの。(;_;)

画面サイズの選択を増やしたい方は言ってくれれば検討します。

> 「タマの猫ハウス」トップページを更新しました。

いろいろと励まれているようですね。
ただ、携帯対応というか小さい画面に対応しようとして、大きい画面に対する配慮
がおろそかになっているような気がします。なかなか大きい画面のシミュレーション
も難しいとは思いますが、とりあえずブラウザを最大化し、ブラウザでの文字設定を
最小化、さらに可能ならそこから[CTRL]+[-]を何回か連打する、というのをやって
みると、私のいいたいことが理解できるかもしれません。

> ＃　この数値を Parl の変数にしたいんだけどわからないの。(;_;)

普通には難しいでしょう。
だって、JavaScriptってクライアント側で動くもので、Perlはサーバ側で動くもの
ですから。
もちろん、普通ではない方法はあるわけで、クライアント側からサーバ側にデータを
送ってやればいいわけですが、サーバ側のほうがCGIならともかく、普通のWEBページ
だと、送られたデータの受け取りようがない気もする。
自前サーバならできるのかな？

どうもあれだ、konnoさん、いまひとつサーバ側とクライアント側の役割分担という
ものを理解されていないような感じに見受けられます。
以前にも書いたことがあるような気がしますが、文字のサイズなんてものは本来的に
クライアント側のお仕事。サーバ側でどうこうするようなものではありません。
というのは建前なので、できることはやってもいいじゃないか、というサイトが世の
中には多いのは現実。だけど、うちの板塀のように、ブラウザ側の対応が変わること
で可能だったことが不可能になることも多いですし、業界の多数派のご意見に変化の
兆しもありませんから、ここは日和っておいたほうが良いのではないかと。
すなわち、文字サイズ変更関係のルーチンは全て撤去、ということ。
いや、もちろん、反主流派を貫く、というのも一見格好良くはありますが。
＃いちご白書は何度目か

wforum.cgiの修正に、色々バグが有りました。m(__)m

> ・FGALDC会議室の専用CGI を統合

この修正ミスで、検索結果の記事の日付が今日になってました。(>_<)

> 今回ブラウザの幅を狭くして確認したのでだいぶまともになったと思います。(^^;

ツリーのはみ出し部分が折り返していて見苦しいのに今更気が付きました。(^^;
非推奨の <nobr> が折り返しを防いでいるんですね。修正しました。

 かなりゴチャゴチャしたので、この機会に、CSS に置き換えてみました。

print "<div style=\"white-space:nowrap;\">";
 
これでツリールーチンを囲うと同じ結果が得られました。
超今更ですが、これからぼちぼちと CSS化していこうと思います。
なんせ、CSSのことはほとんど知らないもので。(^^;

> ただ、携帯対応というか小さい画面に対応しようとして、大きい画面に対する配慮
> がおろそかになっているような気がします。なかなか大きい画面のシミュレーション
> も難しいとは思いますが、とりあえずブラウザを最大化し、ブラウザでの文字設定を
> 最小化、さらに可能ならそこから[CTRL]+[-]を何回か連打する、というのをやって
> みると、私のいいたいことが理解できるかもしれません。

やってみましたが、言わんとすることがよくわかりませんでした。(;_;)
目の手術をしたおかげで極小の文字も結構読めるなぁという感想です。(^^;
一番小さい文字は潰れて読めなかったけど、もしかしてこれのことかなぁ。

> もちろん、普通ではない方法はあるわけで、クライアント側からサーバ側にデータを
> 送ってやればいいわけですが、サーバ側のほうがCGIならともかく、普通のWEBページ
> だと、送られたデータの受け取りようがない気もする。

やっぱりそうなんですかねぇ。
JavaScript を使えば色々出来そうな気はしますが。

> どうもあれだ、konnoさん、いまひとつサーバ側とクライアント側の役割分担という
> ものを理解されていないような感じに見受けられます。

理解はしているつもりですが、もっと連携が取れたらいいのにと思うのです。

> 以前にも書いたことがあるような気がしますが、文字のサイズなんてものは本来的に
> クライアント側のお仕事。サーバ側でどうこうするようなものではありません。
> というのは建前なので、できることはやってもいいじゃないか、というサイトが世の
> 中には多いのは現実。

私も、出来るのならやってみたいと思う方だし、WEB世界はルール無用のジャングルかと。
思えば20年前も色々掲示板などを弄っていたのだなぁ・・・

> だけど、うちの板塀のように、ブラウザ側の対応が変わること
> で可能だったことが不可能になることも多いですし、業界の多数派のご意見に変化の
> 兆しもありませんから、ここは日和っておいたほうが良いのではないかと。

目出ぁ食えり、なんてぇ最近聞いた謎のはやり言葉にも日和たいのに日和れないひよわ男です。

> すなわち、文字サイズ変更関係のルーチンは全て撤去、ということ。

げげげっ、と思いましたが、もしかして全部 CSS でやれということでしょうか。

> いや、もちろん、反主流派を貫く、というのも一見格好良くはありますが。

私はそういうことはいっさい考えない人です。ただやりたいことをやるだけ。(^^;

> ＃いちご白書は何度目か

うーん、価値観の相違みたいな話なのかなぁ、、、わかりません。

こんにちは。私は現在学生で、研究のために多くのPDFデータをExcelに変換する必要があります。無料で使える良いツールはありますか？

そうたさん、こんにちは

> こんにちは。私は現在学生で、研究のために多くのPDFデータをExcelに変換する必要があります。無料で使える良いツールはありますか？

私は PDF を使わないので、その手のツールは知りません。
ネットで「無料でPDFをExcelに変換」で検索すれば色々出てきますね。
危険なサイトもあるかもしれないので自己責任で試してみるとかどうでしょう。

MSのcopilot で検索すると
----------------------------------------------------------

１．エクセルのPower Queryを使って取り込む方法:
エクセルのPower Queryを使用して、PDFをExcelに変換できます。この方法は重要なデータを変換したい場合に適しています。
手順:
新しいエクセルを開きます。
データタブを選択し、「データの取得」から「ファイルから」を選択します。
PDFファイルを選択して取り込みます。
表の1行目を項目として設定し、読み込みを実行します。

２．オンラインツール「iLovePDF」を使って変換する方法:
「iLovePDF」はオンラインでPDFをExcelに変換できる便利なツールです。
手順:
iLovePDFのホームページにアクセスします。
「PDFからExcel」をクリックしてPDFファイルを選択します。
「EXCELに変換」をクリックして変換が完了したらダウンロードします。

３．ワードでコピーペーストを利用して変換する方法:
ワードを使用してPDFのテキストをコピーし、Excelに貼り付ける方法です。
手順:
PDFファイルをワードに開きます。
テキストを選択してコピーします。
エクセルに新しいシートを作成し、コピーしたテキストを貼り付けます。

----------------------------------------------------------

こういう結果が出ました。
信頼性はわからないので試すなら自己責任で試すのがよろしいかと思います。

> やってみましたが、言わんとすることがよくわかりませんでした。(;_;)

うぅん、デザイン的な面での話なんですが、もしかしたらこれはkonnoさん的には
問題ない点なのかも。
うちの複数の環境で、ブラウザもFirefoxやedge、chromeな複数のバージョンで同じ
ような挙動になるので、ブラウザ間での差異はないと思うのですけど、もしかしたら
konnoさんのところでは違っているとかあるかもしれない。
以下はブラウザのウィンドウだと思ってください。

+------------------------------------------------------------------------+
|　　　　　　　　　　　　　　タイトル　カウンタ　　　　　　　　　　　　　|
|　　　　　　　　　　　　　　　　　　絵　　　　　　　　　　　　　　　　　|
|ごにょごにょ　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　|
|ごにょごにょ　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　|
|ごにょごにょ　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　|
|ごにょごにょ　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　|
|ごにょごにょ　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　|
|　　　　　　　　　　　　　　　　　検索窓　　　　　　　　　　　　　　　　|
+------------------------------------------------------------------------+

こんな感じになって、著しくバランスが悪いように見えるのですよ。なんというか、
このページのメインになってほしい部分が左寄せされているような感じ。
もちろん、トップなのだからメインはタイトルと絵であって、あとのリンクの部分は
ほんのつけたし、というのであればこの画面構成はとっても正しいものです。
そして、先に、大画面をエミュレーションするために[CTRL]+[-]を連打してみれば、
と申しましたが、うちではそれをすると、左側のリンクの部分がどんどん小さくなり
左側にこじんまりとしていく一方で、タイトルと絵のほうは小さくはなりますが位置
は変わらず、ますます間隔が開いていくばかり。
これは狙ってやっているのか、それともkonnoさんのところでは違う表示になるのか、
というところはわかりません。

> JavaScript を使えば色々出来そうな気はしますが。

ページの表示を全部JavaScriptで行う、という手法はあります。
この方法なら、サーバとの通信は全く行いませんから、可能なはず。
あと、うろ覚えな記憶だと、JavaScriptに通信させる、という手法もあったような気が
しますが、それこそこれはセキュリティの問題でブラウザ側が規制したような。

> 理解はしているつもりですが、もっと連携が取れたらいいのにと思うのです。

かつて、今よりブラウザが連携を許可していた時代、いわゆるセキュリティホール
とかで個人情報が抜かれまくったり遠隔操作されたり、ということで、ブラウザ側が
連携を取れる経路を絞りまくっているわけですよ。なので、konnoさんが希望する
ことはおそらく、JavaScriptだけで何とかできるようにこの方面を勉強する、という
のが正攻法のはず。これを正面突破ではなく裏口から搦め手でやろうとすると、あと
で手痛いしっぺ返しを食いそう。

> げげげっ、と思いましたが、もしかして全部 CSS でやれということでしょうか。

一応、それがベター。
少なくとも、私はそれよりよい方法は知らない。
ただ、私の知識もたかがしれていますから、もっと良い方法もありそうな気がする。

> > いや、もちろん、反主流派を貫く、というのも一見格好良くはありますが。
> 私はそういうことはいっさい考えない人です。ただやりたいことをやるだけ。(^^;

ところがですよ。
konnoさんの真にやりたい目的はともかくとして、やろうとしている手段は、いわゆる
ルール違反に近いようなことばかり。とはいえ、このルールというものも部外者から
したら曲者に見えるというか、いわゆる業界の自主基準というもので、当然、罰則
なんかありはしない。とはいえ、守っておけば、多くの閲覧者に正しく見てもらえる
可能性が著しく高まる、という程度の話。ブラウザでの対応、とかの話ね。
う〜ん、適切な比喩ができない、と文太さんにもよく怒られていますが、むりやり
比喩的な話で言うと、めざらさんのサイトの場合、４０キロ制限の道をときどき
４５キロくらいで走る程度、というくらいルールを守っている。うちのサイトだと
もう巡航速度が５０キロくらい、時々６０キロを越えます、と言ったような感じかな。
でもkonnoさんがやろうとしていることは、傍目にはターボをフルにして２００キロで
突っ走ってやる、みたいなもの。うまく行けばこれはすごいけど、下手をすれば周り、
つまり閲覧者にも迷惑をかけかねない。
＃「下り最速」というのは大抵「登り最速」ではない

ということで、私としては、何か違ったところを目指しているように見えて仕方ない。
もちろん、私の誤解の可能性も高いのですが。