一括表示

− 野ざらし言 −

[5876] 続・N88-BASICのRENUMのようなマクロ

としき 2025/05/26(Mon) 00:41
http://toshiki.la.coocan.jp/
巨大なツリーは全く問題とは思わない私ですが、錯綜したツリーはなぜか問題と感じるものですから、新しいツリーにします。というか、マトレス的な発言だから新しいツリーにした、というのが正解かも。
とりあえず、乱れたログは回復したようで、祝着至極。

さて、#5687では

> ver.0.21として、

> 終了時のメッセージを出すことと、
> > #55 " " &?("%d",o) #m"
> > ……これを少しだけまとめて……"
> > #55 &?(" %d",o) #m"
> この変更を加えてみました。

#55 だけではなく、#5866でめざらさんからアドバイスされていた #56 の変更も加えたものをver.0.21としました。

ついで、ver.0.22aとして、ファイル先頭にジャンプして末尾まで検索するロジックにした版を作りました。これは行番号ジャンプを使用しています。
これはなんとなく動いているようです。
そして、ver.0.22bとして、マークジャンプを使用して、旧番存在確認は従前のまま上下検索を実施する版を作ってみました。が、これがなぜかうまく動かない。トレースしてみたところ、なんかおかしい。#56 の置換文字列の入力部分で&?("\1FTHEN\2%d\3",n)とかやっているのですが、ここの「%d\3」の部分が数字の連続になってしまった結果、解釈がこけている、というような感じ。ただ、これ、ver.0.21もver.0.22aも同じルーチンなんですよ。ローカル10番にテキストの比較をかましても、３つとも同じ。にもかかわらず、マークジャンプ版だけ正常に動作しない。なので、実は違うところでバグっているはず。

ちょっと頭を冷やして、もう一度トレースを追いかけてみます。
きっとどこか、私が見落としているところがあるのでしょう。
特に、マークジャンプの部分で。

[5877] Re: 続・N88-BASICのRENUMのようなマクロ

としき 2025/05/26(Mon) 02:00
[5876]へのコメント http://toshiki.la.coocan.jp/
うあ、こんな時間。
朝になったら普通に出社しなくてはならないのに。
時間を忘れてマクロをトレースしていました。
結果。

> そして、ver.0.22bとして、マークジャンプを使用
> が、これがなぜかうまく動かない。

原因がわかりました。
単に私が素直すぎただけ、というか。
#5870でいただいたアドバイスですが

> h=ln, の代わりに &#M(1) を，&#J(h) の代わりに &#U(1) を使うだけ

このとおりのコードを書いてしまっていました。
が、実は変数 h って、他でも使っていたんですね。
つまり、設定していない変数を参照していたのでした。
何やってんだか。

これで何とか動くコードができたので、各バージョンに#5872で教えていただいた時間計測ルーチンを仕込んで測定してみたいと思います。

[5878] Re^2: 続・N88-BASICのRENUMのようなマクロ

めざら 2025/05/26(Mon) 16:09
[5877]へのコメント http://mezala.la.coocan.jp/
> が、実は変数 h って、他でも使っていたんですね。

あーらら。よくコードを見ていなくて申し訳ないです。
よろしくない書き方で，としき兄の睡眠時間を削ってしまったのか。
本当にすみません。
○○の代わりに，なんて書かなきゃよかったですね。


ログの破損の方は，だいたい直しました。
またヌルの混入など変な症状がでなければよいですが……。
ネットワークのせいみたいなので，原因は分からず。
なにしろ，ふたつのアーティクルが接続しちゃってたりすることもあったので，単にヌル混入よりひどい。ヌルなら検索すれば見つかりますからね。混入っていうか，通常の文字がヌルに置き換わってバイト数は変わらないとか，紛らわしいことこの上ない。○-com のせいかなぁ……

[5916] Re^2: 続・N88-BASICのRENUMのようなマクロ

としき 2025/06/30(Mon) 00:39
[5877]へのコメント http://toshiki.la.coocan.jp/ 
ハードウェア関係というか、庭関係含め物理的に体を動かすことが多かったもので、
ソフトウェア関係が滞っていました。体を動かすといっても、もっぱら軽作業でした
が。肉体的な運動量としては、アイロンがけとか半田付けとかその程度なので、
体重は減らないなぁ。

それはさておき。
めざらさんに教えていただいた時間計測ルーチンを仕込んで、同一のBASICのソース
をリナンバーしたときの、各バージョンの所要時間を計ってみました。

開始           めざ    0.20    0.20    
番号   増分    ら版    &s無    &s有    0.21    0.22a    0.22b
    1     1     15s             11s     10s      9s     10s
   10    10     15s             11s     10s     11s     11s
  990    10     15s     25s     11s     11s     10s     11s
 1010    10     15s             16s     17s     17s     17s
 1020    10     15s             19s     19s     18s     19s
 1030    10     15s     38s     19s     18s     19s     19s
 1040    10     15s             17s     18s     17s     18s
10000    10     16s     25s     10s     11s     11s     11s

0.21  0.22a  0.22b がそれぞれどんなものかは#5876参照。
一応、0.21  0.22a  0.22bのいずれも、全て&sありです。
あ、#5867で&sの有り無しが逆転している。
&sの前のセミコロンの有り無し、つまりコメントアウトして抑止していたか否か、
ということに引っ張られていました。
うむ、誤差程度に0.22aが速いかな。
あと、開始番号が1020と1030のときが、微妙に所要時間が長い。
オリジナルは1000から始まっているので、行番号の重なりの関係が悪さをしている
と考えたのだけど、そうであれば990始まりの時だって大差ないはずなわけで、
この辺は非常に謎。

あと、どうでもいいかもしれない参考情報をいくつか。
めざら版は&s無しの所要時間だけど、&sつけて画面表示を抑止したら、なんと
たった４秒で変換が終わった。速い。これで既知のバグがなければ、ずっとこれを
使うのだけどなぁ。
もうひとつ、#5876で書いた、#55だけを変更した旧0.21。
会社のWin10のマシンだと、同じ変換を実行しているのに、3秒ぐらいだったり7秒
ぐらいだったりと不安定。きっといろいろと裏で動いているからだと思う。

以上、報告でした。
もっと良いアルゴリズムが思いつければ、乗り換えたいところではあります。
あと、上記の謎が解ければ、今のアルゴリズムで高速化できるかもしれないし。

[5917] Re^3: 続・N88-BASICのRENUMのようなマクロ

めざら 2025/06/30(Mon) 07:43
[5916]へのコメント http://mezala.la.coocan.jp/
10秒でも11秒でも，ちょっとお茶の一口でもすする間に終了するのだから，まったく御の字だと思います。

> たった４秒で変換が終わった。速い。これで既知のバグがなければ、

式の中の数値まで行番号といっしょに変換対象にしてしまう致命的なバグなんて，恥ずかしいのでお忘れください……(^_^;

「本物」のアルゴリズムって，どうなってるのかなぁ……

↑ このページの先頭