プチコン3号のRND関数に限らず、コンピュータ上で作られる乱数はすべて擬似乱数です。 他の優れた擬似乱数と比べても単に偏りの大きさや周期の長さが異なる程度です。 したがって、「ランダムに出力する」というのを擬似乱数だから不可というのは事実上プログラミング不可能になってしまうためRND関数で問題無しと個人的には思います。 ただし、再現性があるか否かは出題時はきちんと言っておく必要があったかもしれないですね。（第1回のときはその点はきちんとしていたので「第2回もそれを継続としている」と考えるか「第2回は第1回とは異なる」と考えるかでねこはちさんの回答の判断は分かれるところでしょう。 次回の出題も乱数がテーマならばその辺を最初に書いておいた方が良いと思います。

本来は内部で丸められて表示されている0.1みたいな数も正確に0.10000000000000001と表示されるためです。（10進数で0.10000000000000001と記録されているわけではなく0.1は2進数では循環小数となってしまうため52桁で丸められた2進数を10進数に変換した結果がそうなるというだけ） これが示すようにプチコン3号の「0.1」は「0.1より少し大きな数」であるため0.1を100回足しても10ちょうどにはならないけどPSTR$ならばそれも目視確認が可能であるということです。 PSTR$は正確すぎるため感覚とずれる部分があるため電卓として使用するのであれば「STR$ほど極端には丸められないけどPSTR$ほど極端に正確ではない文字列化を行える自作関数」を作るというのがベターかもしれませんね。

ちなみにSV=TRUEとしたときの25桁というのは通常表示であれば横に2つ分、WIDTH 16時でちょうと1つ分ということで表示するにも都合が良い値です。 PSTR$ ver.2.0においてver.1.0から仕様変更したのはこのような意味があるためです。 では、電卓を作るのにPSTR$を使えば万全かというと実はそうとは言えないのです。 というのもあまりに正確すぎるためです。

「絶対値が1e-5未満の値」が指数表記になるのは人間が瞬時に認識できるのは4桁までだからです。0.00001234のように小数点の横に0が4つ並んでいれば「4つ」と瞬時に認識できますが、0.0000001234と6つ並んでいる場合には「6つ」と瞬時に認識するのは難しいです。 それに加えて文字列化したときに無駄に桁数が増えるのを避けるためです。 1e-5に抑えることで最大時でも24桁に止まります。 PSTR$はセーブデータとして利用できる（SV=TRUEで使用可能）のですが、スペースを入れて25桁ちょうどとなるためまとめて1つにして保存しても25桁ごと区切ってVALで変換すれば元に戻せる（丸められず文字列化できるため）というメリットがあります。

PSTR$は仕様上「絶対値が1e+16以上の値」または「絶対値が1e-5未満の値」は指数表記にするようにしています。 これは分かりやすさを最優先しているためです。 FORMAT$ではPOW(2,256)などの大きな数を表示した場合には末尾に無駄な0が羅列することになりますが、PSTR$ではそれを避けるために「絶対値が1e+16以上の値」は指数表記にしています。 なぜ1e+16かというとプチコン3号の実数型の有効桁数が上記のように16桁弱しかないためです。 つまり、整数部が16桁を超えたら末尾に羅列する0は無駄になっていくため指数に切り替えて0を省略しているわけです。

そこで登場するのが私の自作関数PSTR$です。 https://miiverse.nintendo.net/posts/AYIHAAAEAABEVRTp-ZVMIg このPSTR$は上記のSTR$とFORMAT$の欠点を埋めるために考え出したものです。 つまり、STR$の「丸められて値が変わってしまう」という欠点、FORMAT$の「桁数指定を調整するのが難しい、（絶対値が大きな数や小さい数は）無駄に0が羅列してしまう」という欠点を無くしたものです。 そして、何も考えなくてもA$=PSTR$(PI())でA$にはPI()を文字列化した値が入り、その状態でA=VAL(A$)とすればAにはPI()と全く同じ値が入るため扱いも非常に楽ということです。 FORMAT$でこれと同じことをするのは非常に大変でVALで正しく数値化できるのは絶対値が1e-81以上1e+99未満の数に限ります。

そのため ?FORMAT$("%.6f",POW(2,-20)) は「0」と表示されます。 これが0にならないように必要な桁数だけ求めるためには対数などを使って表示桁数を調整するしかありません。 FORMAT$は「あらかじめ整数部○桁、小数部○桁で表示」と決めておくならば便利な関数ですが、小数部がその範囲で収まらない場合にうまく表示させるのは難しいということです。

整数部は超えた分が自動的に拡張されるため桁揃えが必要でなければ FORMAT$("%.6f",A) として小数部の桁数のみ記述しても問題ありません。 ただし、FORMAT$は指数での表記ができないため ?FORMAT$("%.6f",POW(2,256)) などの絶対値が大きな数を表示したい場合は末尾に無駄にゼロが並ぶという点は注意する必要があります。 FORMAT$において整数部に関しては必要な場合に上記のように自動的に拡張されるのですが小数部に関しては指定した桁数の分だけしか表示できません。 ?FORMAT$("%.6f",1) では、1.000000と表示されるということです。 さらにあらかじめ指定した分しか表示ができないため?FORMAT$("%.6f",A)では小数第6位までしか表示できないということになります。

では、小数を含む実数型では文字列化をする際に6桁の壁は突破できないかというとそんなことはありません。 そういうときの心強い見方がFORMAT$です。 FORMAT$を使えば整数部、小数部ともに自由に設定した桁数で文字列化が可能です。 整数部に関しては指定していてもそれを超える桁数の場合は自動的に拡張されるため FORMAT$("%17.6f",A) として変数Aの値を整数10桁、小数6桁（小数点込みで17文字分確保）で表示するようにしてもAの値が1e10（100億）ならば11桁の数であるため自動的に整数部は11桁分に広がるというわけです。

STR$を使えば有効数字が6桁になるということで6桁までの整数ならば何ら心配は要りません。 しかし、最大6桁の電卓というのも心もとないものです。 実はA%=123456789のように値を整数型の変数に入れている場合はSTR$(A%)で「123456789」という文字列にすることができます。 つまり、6桁を超えても変化しないということです。 整数専用の電卓であればこのように整数型変数を使うことで整数型の範囲内（-2147483648～2147483647）はSTR$で正しく文字列にすることができるということです。 「文字列化せずに普通に数値のまま表示すればいいのでは？」と思うかもしれないですが、その場合は最大でも小数第8位までしか表示できないという問題があるし、表示の整形をしにくいという問題があります。

知っての通りSTR$は数値を文字列に変換する関数です。 ただし、実数型（普通の数値変数）の数値をSTR$を使って変換すると有効桁数が6桁に丸められるというのを知っておく必要があります。 プチコン3号の実数型は2進数で52桁分、10進数だと16桁弱の有効桁数がありますが、STR$を使えばそれが6桁になるというわけです。 例えばA=123456789という9桁の整数はSTR$(A)とすると「1.23457e+08」になります。 これはどういう意味かというと「1.23457×10の8乗」という意味です。 1.23457に10の8乗（＝1億）を掛けた123457000のことを示します。 これをVALを使いVAL("1.23457e+08")としても元の123456789という数値には戻りません。 123456789という数値がSTR$を使うことで123457000という値に変化するわけです。

最近電卓を作る人が多く見かけますが、電卓を制作のときによく使われるであろうSTR$を使用していていきなり「1.23457e+08」とか表示されて「変な表示になった」とか思ったことがある初心者も多いと思います。 そこでSTR$使用時の注意点や対処方法などを書いておきます。初心者だけではなく中上級者も参考になると思います。

ちなみにPSTR$はPOW(2,100)等の大きな数を表記する際に末尾に無駄な0の羅列が付くのを防ぐため1e+16以上の値に関してのみ指数表記になっています。（あと絶対値が1e-6より小さい値も指数表記にするようにしている）

使用しているRVAL関数のバージョンが2.0から2.1に差し替えてあるのですが、その差し替えが完全ではなく中途半端に2.0と2.1のコードが混じった状態になっているため正常に動作しません。 176行のPRGSET "@R R="+E$+"RETURN　は　PRGSET "R="+E$　に変更する必要があります。

WiiUは近日生産終了が決定しているためすでに生産調整をしていると思うので、年末のクリスマス需要で流通在庫の大半が無くなると予想されます。 ネット通販でも何でも活用すれば来年以降であってもいくらでも手に入ると思いますが、近所の馴染みのショップで買いたいのであればなるべく早く購入しないと生産終了後は店頭在庫が無くなった時点で「取り寄せ不可」になるかもしれません。 ちなみに私は昨日WiiU本体（スプラトゥーンセット）を「プチコンBIGのためだけ」に買いました。

指数表記無しで文字列に変換たいというのであればFORMAT$を使うのがベターですが、「お手軽、かつ、正確に文字列に変換したい」というのであれば私の自作関数PSTR$がオススメです。 https://miiverse.nintendo.net/posts/AYIHAAAEAABEVRTp-ZVMIg

ちなみにИあっキー#ジャロさんの最初の画像（5つ上のコメント）は(2)、次の画像（3つ上のコメント）は(3)の方式が採られていると思います。 計算式等はいろいろありますが、3Dだとカメラ位置を決めておくと計算がしやすいです。 あくまで「擬似」なんだからカメラ位置はアバウトでもそれっぽく見せることは可能ですが。（実際、そのように作られたゲームも少なくない） あと直角カーブはよく使われる擬似3Dの表示方式である「横ずらし」では対応できません。 したがって、これを行うならばコース全体図を用意してそこからスキャンしたものをパースをつけて表示という形を採るのがベターだと思います。 この場合は直線の表示方式そのものは(1)～(3)のどれでも対応が可能なのでまずは、カーブがない直線コースから確実に表示できるようにするというのもありだと思います。

表示された道路に隙間が開く理由は簡単です。 かいしゅうさんが作られたプログラムはほぼ同じ比率で縮小した横長の道路のスプライトを縦方向に等間隔（6ドットごと）に表示していますが、パースがついているためこの道路を真上から見ると(1)のように奥の方が長くなっているのです。 こうやってみると隙間だらけなのが一目瞭然ですね。 では、どうするかというと(2)のように奥に行くほど道路の縦方向の比率を大きくする（画面上では同じドット数にする）か、(3)のように均一な幅で統一（画面上では奥に行くほど縦方向に小さくなる）かという方法を採る必要があります。 擬似3Dにおいてはどちらが正解というわけではなく好きなほうを選択して構いません。 ただし、(2)と(3)では距離感が変わるためそれに関しては注意をする必要があります。

プログラミング未経験者がゼロから覚えるならばどれでも変わらないかと言われたら微妙で少しでもハードルが低い開発環境の方が良いのだけどプチコン3号は言語仕様はともかくハードルの低さは超オススメできますね。 ある程度経験している人が手を出すならば現時点で覚えているものとの比較で覚えることになるため違いが小さい方が楽かもしれません。 かつて、BASICを経験したおっさん連中ならば問題ないし、学校の授業とかでBASICを触ったことがある学生ならば簡単に受け入れられるでしょう。 私は覚えが早い方ではないのですが、それでもさすがに四半世紀以上BASICを使ってきたためプチコンはあっさり受け入れることができました。

nobuさんへ 祝って頂きありがとうございます。 これで16歳になりました。 昨年も16歳だったけど細かいことを気にしてはダメです。