おちゃめくらぶ掲示板 - 1659321896

2401：御茶目菜子：2015/05/04(月) 23:55:44: プチコン3号の処理を1ナノ秒単位で計測する
プチコン3号で変数の型や演算子によってどれくらいの速度差があるのかを調べてみたにょ。
http://ochameclub.web.fc2.com/petitcom3/lecture/speedup_nano.htm

これは先日（4月10日）にtwitterやMiiverseで書いた投稿を正式にまとめたものにょ。
私はtwitterやMiiverseはとりあえず「こんなのを作ってみた」とか「こんなのをやって
みた」というのを書くのに利用しているけど自サイトに書く場合にはちゃんとコンテンツと
して公開する限りは（自己基準で）一定ライン以上のものにしたいと思っているにょ。
そのtwitter上で書いた「A=A+1が345ナノ秒程度になる」といってもこの信頼性というのは
極めて低いにょ。
それは自作TIMER()関数はMICPOS命令を使って実現しているけどこのMICPOSのカウントの
進み方は一定ではなくバラツキがあるためにょ。
そのため1フレームより短い時間の計測に活用できそうなTIMER()関数は1フレーム程度の
短い時間だとバラツキで計測時間が大きく左右される（私が少し調べてみただけだと
1フレームであっても常に15～17m秒といった範囲で値がばらついていてワーストケース
では1フレームが18m秒と計測され誤差は10％に達してしまう）という問題があるにょ。
したがって、この問題を何とか改善する必要があるにょ。

ただし、TIMER関数は1秒だと3DS本体の内蔵時計と比較してほぼ1％以内の誤差に収まって
いるし長い時間ならばMAINCNTよりも正確な時間を指し示すためMICPOSが大きな値で進む
頻度にそこまで大きなバラツキはないと言えるにょ。
ちなみにMAINCNTも計測結果にはある程度のバラつきが出てしまうためより細かい時間が
計測が可能なTIMER()関数のアドバンテージは十分にあるにょ。
「1ナノ秒単位で計測を行う」となると1000分の1秒単位で計測可能なTIMER()関数でも最低で
100万回ループが必要になるにょ。
100万回ループといってもNew3DSで動作しているプチコン3号ならば1秒もかからないにょ。
ただし、100万回ループでも安定した計測結果が得られるかというとそうでもなく±数％の
バラツキが発生していまっているにょ。（これはTIMER()関数の仕様に加えてプチコン3号では
バックグラウンドで様々な処理を行っている関係でプチコンmkIIと比べて処理速度が安定
しないせい）

今回の結果からA=A+1は345ナノ秒程度かかることが分かっているのだけど100万回ループだと
±5ナノ秒くらいの誤差は普通に発生し、希に+10ナノ秒くらいの誤差まで発生してしまって
いるにょ。
そのため例えば100万回を3回計測して355ナノ秒、340ナノ秒、343ナノ秒という値が得られた
時にこれからどう判断するのかという手腕が問われるにょ。
単純に平均を取ると346ナノ秒となるけどこの結果から「346ナノ秒」と言い切るのは極めて
微妙にょ。
したがって、4月10日にtwitter上で書いた時には結果を5ナノ秒単位で丸めて5ナノ秒単位の
誤差はあるということを伝えたにょ。
つまり、計測結果は1ナノ秒単位で表示されているけど実際は5ナノ秒単位でしか判断が
できないということにょ。（確実に5ナノ秒以内に誤差が収まっているというわけではない）
サイト上で正式コンテンツとして残すならばこの辺を何とか改善したいにょ。

それを改善するにはどうすれば良いのかというと最も単純な改善策はループ回数を増やす
というものにょ。
例えば100万回ループではなく500万回ループにすればで内部（ここでの内部というのは
計測結果を返す前の段階のことでありプチコン3号の内部処理を意味するものではない）では
0.2ナノ秒単位になるため誤差が減るというわけにょ。
しかし、100万回ループを500万回ループにすれば確かにばらつく範囲は狭まるもののばらつく
範囲が1/5になるというという単純なものではないにょ。

ここで問題となるのはどのような値を測りたいのかということにょ。
今回は普通に実行して得られる値が欲しいので平均的な速度はどれくらいなのかという
ものにょ。
それならば素直に平均値を求めれば良さそうだけど上記のように「355、340、343」を
足して3で割るというのは得られた数字の信頼性は極めて低いにょ。
それならば計測回数を増やしてやればいいにょ。
3回ではなく10回とか20回とかにすれば平均的な値から大きく外れた値が出てもその値に
大きく左右されることが無くなるにょ。

それならば「平均的な値から大きく外れた値は最初から除外して平均を求める」というのも
1つの改善策にょ。
ただし、平均的な値がどれくらいなのか事前に分かってないと除外対象が分からないし
除外する値の閾値をどれくらいに設定するのかという問題が発生するにょ。
そもそも、今回私が欲していたのは平均値ではなく平均的な値（普通に実行してよく起こり
うる値）なので、平均値よりもむしろ最頻値の方がこの場合は相応しいにょ。
ただし、最頻値を求めるならば10回程度の計測ではたまたま同じ値が出たらそれに決まってし
まうという結果を招いてしまうためバラツキを考えると最低でも100回、できれば1000回以上
の計測を行う必要があるにょ。（どれがどの程度の確率で発生するのか、どんな確率分布に
したがって分布するのかが分からないため検定はしてないけど1000回ならば最頻値を得るのに
ほぼ問題ない回数だと思われる）

では、実際に1000回計測したらどのようになるのを示したのがこれにょ。
（New3DS、ver.3.1.0での結果なので旧3DSで実行した場合だと同じループ回数であっても
処理速度が遅い分だけ分布する範囲が広くなる）

◎100万回ループ　1000回計測
平均　345.532ナノ秒
335ナノ秒　　5回
340ナノ秒　 13回
341ナノ秒　 39回
342ナノ秒　 68回
343ナノ秒　113回
344ナノ秒　133回
345ナノ秒　162回　最頻値　←　平均付近
346ナノ秒　141回
347ナノ秒　115回
348ナノ秒　 78回
349ナノ秒　 46回
350ナノ秒　 37回
351ナノ秒　 16回
352ナノ秒　 16回
353ナノ秒　 10回
354ナノ秒　　2回
355ナノ秒　　3回
356ナノ秒　　1回
357ナノ秒　　1回
358ナノ秒　　1回

◎500万回ループ　1000回計測
平均　345.041ナノ秒
342ナノ秒　　9回
343ナノ秒　 93回
344ナノ秒　248回
345ナノ秒　297回　最頻値　←　平均付近
346ナノ秒　230回
347ナノ秒　98回
348ナノ秒　24回
349ナノ秒　　1回

100万回ループを見ると平均を基準に小さい値はバラツキ幅が小さく、大きい値はバラツキが
大きなべき分布気味の形になっているにょ。（A=A+1は比較的安定した結果が得られているの
だけど他の処理でもそこまで大きな差はない）
100万回ならばそこまでではないけどこの傾向はループ回数を減らせばさらにはっきり出て
くるにょ。（10万回ループまで減らすと320～380くらいの値に分布して最頻値から大幅に
外れた大きな値が出やすくなる）
しかし、これが500万回ループになると傾向が変わり大きい値のバラツキがかなり抑えられる
ため正規分布、ガウス分布に近い形になるにょ。
べき分布であれば「平均を取る」ということに意味はないけど500万回ループならばガウス
分布にかなり近くなるため平均とのずれは気になるレベルではないにょ。（正確なべき
分布であれば対数を取ることで直線的なグラフになるけど今回の結果だけだと正確なべき分布
とは言い難いし、ループ回数を増やせば対数を取る必要性はなくなる）
そして、最頻値も平均とほぼ同じ値を示すにょ。（これと同じ1000回計測を他にもいくつか
試してみたけど誤差は0～1ナノ秒だった）
A=A+1の1000回計測においては500万回ループに限らず100万回ループでも1ナノ秒単位で見た
場合には平均値と最頻値は一致しているにょ。
「最頻値＝平均値」ではないけど100万回以上のループを行えば両者に大きな差異はないため
正確な平均を求めればほぼ正確な最頻値が求まるというわけにょ。（この辺は実際に多数の
ものを計測してヒストグラムを出さないと分からない）

ここで問題は先ほども書いたように正確な平均を求めるのが難しいということにょ。
100万回ループだと1000回計測で実際に335～358の値が出ているにょ。
A=A+1は何度も計測しているため345がほぼ平均値（≒最頻値）であることが分かっている
けど358というのはそれよりも13も大きい数字であり、それが実際の計測に出た場合には
それ1つで結果が大きく左右されるにょ。
ならば、簡単な方法は1つでループ回数を増やせばいいにょ。
500万回ならば上記のように最大でも349（最悪のケースで4ナノ秒の誤差）で収まるため
その値1つで平均が大きく変わるようなことにもなりにくいにょ。
それでも、TIMER()関数を使う以上はくらループ回数を増やしてもバラツキを1ナノ秒以下に
抑えるのは難しいし8秒以内という制限を考えるとNew3DSでも500万回が限界にょ。（ループ
だけならば700万でも対応できるけど実際に計測したい処理（ほとんどのものが200～600ナノ
秒程度）を考えると500万が限界ということ）

したがって、一発計測ではなくある程度の計測回数を行いそれを平均することになるにょ。
何回計測すれば90％程度の信頼性を得られるかとかは正規分布ならば計算は可能だけど今回の
分布ではそれが面倒なので実際に数をこなしすでに分かっている値に近い値を出すには何回
くらい必要かを計測回数を変えながらいろいろと試してみたにょ。
その結果がこの10回という数字にょ。
確かにこれを50回とか100回に増やせばさらに信頼性はアップするけど計測にかかる時間を
考えると微妙だし、計測する処理によって値がばらつく範囲が変わるため一概には言えない
ものの「1～2ナノ秒程度の誤差はある」と最初から言っておけば問題ないと感じたにょ。
（私の感覚では500万回ループで実行したものに関しては±2ナノ秒の範囲で90％以上の
信頼性があると思うけど後者のように些細な環境による計測値の変化の影響があるため
2ナノ秒以下の誤差で90％以上の信頼性というのは計測結果の信頼性であって掲載している
表の信頼性はそこまでないかもしれない）

それに10回ならば全結果が表示可能なのでそこから判断も可能だしね。
後からみてあまりにバラツキが大きい場合は再計測を行うことも可能だし、空ループを
計測してプラスの値やマイナスの値ばかり出ているならば補正値の変更を検討する必要が
あるにょ。（変数宣言や代入の順番やそれが整数型か実数型かでも結果が数％変わるため
実は同じ条件で計測するというのは思っている以上に困難で空ループを計測して補正値を
変えて対応するしかない）
TIMER()関数の精度の問題よりも計測プログラムに使われている変数処理の順番で変わる
ことの影響が大きいくらいにょ。
このことに気づいたのは今回の結果を粗方計測し終わった後だったのでまた再計測し直した
けれど再計測されてないものもいくつかありそうなので補正値の誤差がほぼゼロ、500万回
ループで実行時でこの表から5ナノ秒以上ずれている結果が表示された場合にはぜひ報告
して欲しいにょ。（100万回ループでもほとんどの場合は5ナノ秒以内の誤差に収まって
いると思うけどそこまで確信は持てない）
その際は環境による違いか、私の記載ミス（要は誤植）かをこちらで判断するけど記載ミス
というのもそれなりにありそうなのでこちら側で記載ミスを発見した場合はこっそり修正
させてもらうにょ（笑）

注意すべき点としてはこれは、リンク先のページ内でも何度も書いていることだけど
各演算処理に「○○ナノ秒かかる」というのは絶対的な数字ではなく覚えてもあまり意味が
ない数字にょ。
というのもこの数字は環境によって変化する値だからにょ。
しかし、「乗算は加算の○○倍遅い」というのは知っておけば高速化をする時に役に
立つにょ。
そのためできるだけ環境を揃えて相対比較が十分に行える精度で計測しているにょ。（この
「環境を揃える」というのが後述のように思っている以上に難しい）
それでも、下記にあるようなTIMER()関数の仕様や計測回数が10回という仕様によって
500万回ループであっても1～2ナノ秒程度の誤差が出る可能性があるにょ。

絶対的な数字ではないというのは単に「誤差がある」という意味ではなく実際にはTIMER()
関数に使われているMICPOSが正確に32/32730秒周期で増加しているのではない（これは
ループ数を増やすことで許容誤差の範囲になるようにしている）のに加えて各種割り込み
処理が加わる関係上、実際の処理速度（プログラム実行速度）というのは確定している値
ではないためにょ。
例えば私が使っているポケコン（PC-E650）においては、INKEY$による割り込み処理の
関係上、キーを押している時はすべての処理速度が15％くらい遅くなるにょ。（キー割り込み
無効化はBASIC上からもPOKE命令で可能なのでINKEY$を使わず直接キーポートを読み取る
ことで約15％の高速化が可能になる）

プチコン3号ではバックグラウンド上では多数の処理が行われているため純粋な命令の
実行速度というのはこのプログラムでは計測ができないにょ。
しかし、これも環境を可能な限り統一することで割り込み等を含んだ実行速度を計測
しているにょ。
もちろん、これは「この計測プログラム上における実行速度」だけどプチコン3号でそこ
まで遅くなる（計測値が数10％変わる）ことはあり得ないにょ。（A=A+1が345ナノ秒と
いうのもあくまでこの計測プログラムにおける値にすぎないけどほよどのことがない
限りはここから大きく変わる値が計測されることもない）
もちろん、処理に影響を与えるプログラムであれば私の計測値より数％変化する可能性は
十分にあるためこの数字は絶対的なものではなく相対比較用のものでしかないにょ。
しかし、プログラムを公開することで統一環境の元、各自で相対比較を行えるので問題は
ないにょ。

といっても、このプログラム自体は決して特殊なものではないにょ。
自作TIMER()関数を使わなくてもMAINCNTでも簡単に作れるためにょ。

　M=MAINCNT
　FOR I=1 TO 16710000
　NEXT
　?MAINCNT-M;"ナノ秒"

たったこれだけで私が作ったものとほぼ同等の1ナノ秒単位の値を計測が可能になるにょ。
空ループの時間を計測して、FOR～NEXTの間に計測したい処理を入れてその実行時間を計測して
差分を取ればOKにょ。
1フレーム（1/60秒≒16.666666ミリ秒）のループ回数が16666666回でないのは私の計測に
おいてプチコン3号での1フレームは平均で1/59.835秒（≒16.712626ミリ秒）程度であるためで
それならば厳密には16712626回ループにすべきだけどそこまでの精度で計測できない（計測
精度はせいぜい3桁しかない）ためこれでほとんど問題はないにょ。
どうしても、これでは精度が足りないと思う人は下4桁を「2626」にすればいいけど各自の
手元のプチコン3号を使って計測してもらうのが一番にょ。（とりあえず、私のNew3DSと
旧3DSでは複数回計測して1/59.835秒になったけど他のものでも同じになることが保証でき
ないため）

これだけのプログラムで「A=A+1が345ナノ秒前後」というのが計測できるにょ。
つまり、これは特殊なことをせずに誰もが確認できる値といえるにょ。
ならば、「私が作ったものっていったい何なのか？」
自作TIMER()関数を使いたかった・・・というのもあるけど「1ナノ秒単位で計測」というのを
アピールするためにはMAINCNTだと最低1671万回のループが必要だけどTIMER()関数ならば
100万回のループで済むというメリットがあるにょ。
もっとも、1671万回ループのMAINCNTの方がTIMER()関数の100万回ループのTIMER()関数よりも
誤差が少なく計測が可能にょ。（MAINCNTも1/59.835秒を正確に刻んでいるかというとそう
ではなく3DS内蔵時計が最も正確に時間を刻んでくれるので時間に余裕があるならば内蔵
時計で計測するのが最も誤差の少ない実行速度計測が可能になる）

では、私が作った処理速度計測プログラムはTIMER()関数を使い100万回という少ない（？）
ループ回数でも「1ナノ秒単位で計測」をアピールしているというだけでそれ以外は
何も考えてないというわけではないにょ。
プチコン3号においてはFOR～NEXTのループは常に終了値と刻み値を評価しているけど
終了値は定数で置くよりも変数で置いた方がループの速度が安定するため変数で置いて
いるにょ。
その変数はOPTION DEFINTでの実行を考慮して実数型を示す「#」を付けているにょ。
ループ回数が2の31乗回を超えることはこのプログラム上ではあり得ないので整数型でも
いいのだけど実際によく使われるのが実数型なのでそれに合わせているにょ。（それを
考えるとループの終了値にも変数が使われることが多いし）
整数型だろうと実数型だろうとループにかかった時間を引くわけだから関係ない（むしろ
整数型ならばループが速く終わるというメリットさえある）と思うかもしれないけど
実際はループ内処理を含んだループ全体の時間をからループにかかる時間を単純に
マイナスしてもループに使われている変数が整数型か実数型かでループ内の処理にも
影響を与えるため一般的に使われている実数型を選択しているにょ。

これは命令の順番や直前に処理しているのが実数型か整数型かで処理速度が変わるためで
実際にどれくらいの影響があるかというとこの計測プログラムにおいてループの終了値の
変数（K）を実数型から整数型に変えるだけでA=A+1の速度が345ナノ秒から344ナノ秒へと
速くなり（ただし、これはこのプログラム上は誤差の範疇）、ループのカウンタ変数（I)を
実数型から整数型へと変えると380ナノ秒へと約10％も遅くなるにょ。（ちなみにK#を定数
5000000で計測したら341ナノ秒へと高速化される）
ループ外の代入処理でさえループ内に影響を与えるにょ。
というわけで、一般的に使われている環境（と想定されるもの）に合わせることで誤差を
極力少なくしているのがこのプログラムというわけにょ。
やっていることは大したことはない誰でも考えつくような内容のプログラムだけど「誤差を
少なくする」というのはここまで考える必要があるというのが分かってもらえたらいいにょ。
（1ナノ秒単位での計測だと非常に些細なことでも影響を与えてしまう）

　《　プチコン3号で処理時間計測をする場合の最大の問題点　》

　　　FOR I=1 TO 1000000
　　　　A=A+1
　　　NEXT

　　の実行時間から

　　　FOR I=1 TO 1000000
　　　NEXT

　　の実行時間を差し引いても

　　　A=A+1

　　の正しい実行時間が出るというわけではない！
　　どのような処理を行おうと得られるのは絶対的な値ではなく
　　その実行時の環境に依存した実行時間でしかない。
　　　　↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

　　この場合だとFORの前に何も処理がなく、カウンタ変数は実数型、終了値は1000000の
　　場合という特定環境下の「A=A+1」の実行速度が分かるだけ。

　　ならば、実行時の理想環境を想定して得られた数字は相対比較用の数字とすればよい。
　　これが今回のプログラムとなっている。
　　したがって、この理想環境内では誤差の少ない「正しい値」が出ている。
　　その代わり理想環境は一般的によく使われるであろうものにする必要がある。
　　つまり、それを計測したプログラムも一緒に公開しないとその値はほとんど意味を
　　持たない数字になってしまう。

あと、TIMER()関数の仕様で最大8秒までしか計測できないならば一定回数ではなく8秒間に
実行できる回数を計測した方が良いという指摘も戴いたけどこれは上記のようにループを
単純化させることで安定した誤差の少ない結果を得ることができるというのを優先した
結果にょ。（ちなみにMAINCNTで600フレームを計測するよりTIMER()関数で10000ミリ秒を
計測する方が10秒に近い値が出やすいけどMAINCNTの方が値は安定している）
ちなみにTIMER()関数そのものは「275197044141185ミリ秒（≒8726年）」までカウント
可能だけど8秒間に1回は呼び出さないと8秒を超える時間はカウントできないという仕様に
なっているだけにょ。
約8秒を計測するだけならば本プログラムでやっているようにMAINCNTが480以上増加したか
どうかを判断すればいいので簡単にょ。（MAINCNTも上記のように正確に1/60秒を刻んでいる
わけではないので480で8秒というのは本当は正しくはないけど）
もっとも、TIMER()関数を使用しないのならば8秒の制限はないので10秒でも20秒でも好きな
時間に設定できるし、その改造も簡単なので「一定時間の方が良い」と思う人は自由に
改造して使って欲しいにょ。
ただし、その場合にはこの理想環境から外れる上に誤差が出やすくなり、上記ページで
記載されている時間と単純比較ができなくなる恐れがあるにょ。（5ナノ秒以上のずれが
あっても環境による違いかプログラムの処理方法による違いかの特定ができないということ）

私はNew3DSで動作するプチコン3号と比べて数千、数万倍遅いポケコンで0.1ミリ秒、0.01
ミリ秒単位の高速化（ベーマガなどの雑誌に掲載のゲームで平均3倍、最高で9倍の高速化を
実際に行った）をしてきたけどこれは言うならばプチコン3号で1ナノ秒単位での高速化に
匹敵するレベルにょ。（これは改造というよりまったく同じ動作をするプログラムを1から
作り直した上でさらに演算子の実行速度を加味して限界まで高速化している）
高速化の効果をリニアに体感できるポケコンとは異なり、プチコン3号でそこまで高速化
しなくてはならないという機会はないし、あってもポケコンほどは体感するのが難しく
苦労の割りにはメリットは少ないにょ。（リニアに体感できる高速化を得ようとするならば
このような1ナノ秒単位の変数の演算子の速度の違いに拘るのではなくアルゴリズム等の
改善をするべき）
限界までの高速化を行うならば先ほども書いたように演算子や変数使用の順番やそれらが
実行される確率などで変わってくるため最速プログラムを作りたいならば単命令の速度では
なくその命令を含む実測値が重要になってくるにょ。（速い命令を並べたらそれが最速に
なるというわけではない）

つまり、BASICというブラックボックス上で動いている以上は自分が書いたプログラムが
プチコン3号にどのように解釈されるのかというレベルまで考えてはじめて最速の
プログラムが書けるということにょ。（これがコンパイラならばよりコンパイルされた後に
どのようになるのかを考えた上でソースを書く必要がある））
したがって、命令や演算子の速度はどれがどの程度速いのかという相対値を知っておけば
十分ということにょ。（そのためその相対値として使える数字の誤差が出にくいプログラム
というのが私の作ったプログラム）
しかし、ポケコンなどのROM BASICとは異なり、プチコン3号で1ナノ秒単位の処理の最適化は
バージョンが変われば無に帰すためver.3.1.0でのみ最速を目指すので無ければほとんど
意味がないにょ。

さて、今回上記の1000回計測の結果をヒストグラム表示してこの計測値がどのような分布に
なるのかを視覚的に確認できるようにしてみたのだけどこの傾向というのは10回程度では
分からないにょ。
かといって、分布の確認表示をするため計測回数を増やしループ回数を減らしてしまう
（New3DSでさえ500万回ループを1000回実行するならばそれこそ2時間近い作業になるため
厳しい）というのは本末転倒となってしまうにょ。
ヒストグラム表示に意味を持たせるならば計測回数を最低でも100回できれば1000回以上に
する必要がありこの機能が欲しい人は各自で対応して欲しいにょ。（ヒストグラム表示
そのものは単純だけど100回計測、1000回計測なんて滅多に使わない用途でリストの長さが
倍増してしまうのも個人的にはあまり気に入らないため）

ちょっとやってみようと気軽に始めた今回の計測だけど実際にやってみると単に「平均を
出す」というだけでも様々な条件が絡んでくるため思った以上に困難だったにょ。
そして、誤差をいかに減らすのかが難題になったにょ。
そのため、たったこれだけのことをまとめるのに3週間かかったにょ。
まぁ計測中は放置で済むとはいえ、書きたいことが最初から分かっている講座と異なり
測定しながら新たな問題点が見つかりその改善策を考える必要があるため予想以上に時間が
かかってしまうにょ。
ちなみに500万回ループ、1000回計測をデフォにすれば正確な平均値や最頻値が求まるの
だけどすでに書いているように実行速度は様々なものが影響を与えるにょ。
しかし、値を左右する様々な要因について今回分かり私自身多くのことが勉強できたにょ。

これくらいならば数日で終わるだろうと思っていたものが3週間もかかってしまったため
私のサイトのプチコン3号コーナー制作の予定もかなり遅れているにょ。（遅れたのは他にも
twitterやMiiverseで公開しているような自作関数を作っていた影響も多少はあるけど）
次はその自作関数をまとめたページを作る予定にょ。
今まではほぼリストのみの公開だったけど1つのプロジェクトフォルダにまとめるので
入力するのが面倒だから使ってなかったという人もこれを機会にぜひ使ってみて欲しいにょ。
どれだけの需要があるか分からないコーナーだけど今まではtwitterやMiiverseで単発発表
してきたものをまとめるだけなのでそれほど難しい作業ではないにょ。（今回の計測結果を
まとめる作業と比べたら格段に簡単）
とはいえ、実際やってみると今回のように「思っている以上に面倒な部分」も見つかると
思うのでとりあえず連休中（5/6まで）には何とかしたいにょ。
それが、終われば入門講座の再開にょ。
スプライト関係は書くことがあまりに多くて後回しにしている状態なので次はWHILE～WEND、
REPEAT～UNTILあたりを書く予定にょ。
他にもやりたいことが溜まっているので連休中はこれくらいで終わりそうにょ。
まぁ作りたいものが見つかったらそちらを優先してしまうのでこの予定はあくまで未定
と思って欲しいにょ。
まぁ仕事でやっているわけではなく趣味として自己満足でやっていることだから自分が
やりたいようにやらせてもらうにょ（笑）