肝心のひし形を求める式 「J = H*I/2」がスクショ画像では無いので予想の範囲でしか答えられないが、台形の式では「割る2」のところを「/L」としていることから、ひし形も同じくLで割っているのではないだろうか。 そうだと仮定した場合、Lの代入忘れ、つまりL=2してないのでL=0の状態だから「0では割れませんよ」というエラーが出たと推測してみたけどどうだろう？

63%

ガチャとリアルガチャ

乱数は100回やるときれいに50:50になるものではないですよ。 何故かというと、そろうように作ると次に何が出るかを予測できてしまうのでランダムとして使えないんです。 例えば99回までで0と1が49:50だとしたら、数がそろう場合、次の100回目に出る値は「0」だと簡単に予測できてしまいますよね。 0と1が50:50で出るようなクジを作りたいのならば、配列に0と1を50個ずつ入れてシャッフルし取り出すようなプログラムを作る必要があります。

"," is missing. DEF TYPE A$,A

ちなみに、H1のBEEPやWAITも実行されないのは、実際にプログラムを実行する前にまず変数や命令に間違いがないかをチェックしているからです。その事前のチェック段階でエラーとなり止まるから、BEEPも鳴らないわけです。 異なるスロットの変数や命令を呼び出すときに、全部「VAR("1:H")」なんて書くのは面倒だったりするでしょう？ なので、こういう呼び出し方は、どうしてもという特殊な場合にしか使わないのが良いです。そのためにCOMMON DEFがDEFとは別に用意されていて、別のスロットから値が欲しい場合には、COMMON DEFの返り値を経由して受け取るのが標準的な方法になると思います。

H0の H[I] を全て VAR("1:H")[I] にすれば、とりあえず動くようになります。 （LOCATEの設定できる範囲を超えてしまうので、そこでエラーが出ますよ。 プチコン３号の仕様上、変数や命令を入れる箱はSLOTごとに別ものとして作られるようです。 なので、名前が同じHでも、厳密にはスロットに応じて0:Hや1:Hなんです。 同じスロットでは番号を省略しても問題がないのは、「同じスロットから呼び出す場合は同じスロット番号の変数や命令だと見なす」という暗黙のルールがあるとでも言いましょうか。だから、今回の場合コンピュータはHを0:Hだと勘違いして、配列変数Hが宣言されてないよ（DIM H[512]がないよ）とエラーを吐いています。

ギャルズパニックかなと思ったら、がんばれゴエモンだった エロは安村ライン（履いてますよまで）を越えるとアウトじゃないかなｗ

定数リテラルのユーザー定義対応お願いします。 挙動としては、SLOT間で共有の定数値として認識されるものが欲しいです。

プチコン式追悼　43EN4EAX

> イカさん もしかして元ネタ知ってる感じかな？ｗ ゲームの題材自体はありふれたものかと思いますが、一応参考元はあります。クリアするとご褒美画像が見られる系のアレなやつなので名前は出せませんが、任天堂ハードであのメーカーの作品の再現ネタやるのは、ロマンですなｗ まぁ、QSPとか流行ってるから私もショートプログラム書いてみようという事で、単純なゲームでそれに適していたという以上の題材選出の理由は無いです。

カエルがハシゴをのぼるだけ　 2A5QF3K4

丁度、ほしけんさんの漢字ライブラリが良い感じになっていて、色々参考になりそうだと思った。 組み込みやすいようにサブセット化ツールまで付いていて、皆がここまでしなくてはいけないかとなるとハードル高いけれどｗ

> コータさん 3号のスロットという4か所だけに限定されるような仕組みは過渡的なものだと考えているので、プチコンの次期verで順当に進化すればもっと一般的なインポートの形になるのではと思っています。なので、スロットが足りなくなって自動で調整してという規模にもなると、もう3号でやる範疇じゃないかなと。 あぁ、でも、私も機能で見たら別々にしたいところを、使う時にこれ一つのためにスロット埋めるの勿体ないからってやってますねｗ 自動コピペのアイデア自体も便利そうですね。作る時は別スロットにガンガン分けて書いておいて、後から自動で一つにまとめてくれるみたいなこともできそう。

> けいさん 何でもかんでもモジュール分割（ライブラリに分ける）すべきでもないですから、コピペでも管理できる範囲ならば問題ないと思います。 どの段階で分けるのかは色々と流派があって確定的なことは言えないですが、ライブラリにまとめることに限定すると、プログラムの構成やデータ整理が固まった段階になるので、頻繁に改変が必要な時はまだライブラリ化する段階にないですし、また多少の中身の変更があっても、呼び出すインターフェース部分がコロコロ変わらないよう整えることを含めてライブラリ設計だと思います。

> おかっぺBEERさん 初期化関数は配列初期化の問題がクリアになればまだ安心して使えるんですけどね。 おかっぺさん含め、ライブラリの単独実行でサンプル起動という声が結構あるのは意外でした。ライブラリは単独で使うものではないし、他のプログラムに組み込むことを考えると中に余計なコードを含んでいるのは邪魔なので、サンプルは別にしてほしいというのが私の考えだったからです。 > ヨッシーさん BACKTRACEはDirect専用命令でもありますし（何故かDirectでなくても動くけれどｗ）、使うとしたら個人的にこれしかないって時に限りますね。サンプル実行のためだけに一般的な方法として人に勧められるものではないですよね。 スロット番号ぐらい簡単に取得できて問題ないと思いますし、次のアップデートで取得できるようにしてくださいと要望しとくかな。

> れいさん ライブラリの中身のことは具体的に考えていなかったけれど、モノによって手段を変えることになるのは、その通りですね。 スロットまわりは実装優先で作ったとの話もあり、現状のプチコンできちんとしたライブラリを構成するには改善されるべきところも多いです。私も、これでガチなやつを作ろうとは思えないかなｗ。そういう改善の要望について、こういった議論を通じて具体的に現状皆がどう使っていてどこに問題があるのかフィードバックをあげられると良いです。 > ナツキさん 私もEXECを使うことは考えてなかったですね。 でも、公式がEXECをライブラリの呼出に使うとしているのならば、それを汲んで作るべきとも思い悩みどころです。 スロット跨ぎのサブルーチンは、限定的に使わないとスパゲッティ化のもとですが、初期化の解決法としてはベターな折衷策だと考えています。

どの方式でも通る複合例。 実態としては、定義自体はサブルーチン方式で、関数やEXECではそのサブルーチンを呼び出すことで定義する仕組み。 関数内からサブルーチンを呼ぶのが特殊なのと、サンプル実行で定義した変数を使うには、初期化サブルーチンを上に配置しなくてはいけないところが注意点。

> Godot さん EXECは単体実行とライブラリとしての使用とが一緒になっちゃうのが欠点ですよね > れい さん、けい さん、でんぺん さん コピペも自分用や短くて単純な関数だとアリですよね。 コピペだと変数の衝突が起こり、それを毎回修正する必要があるので、条件としてはそれが出来る規模のものに限られます。質問では、中身の複雑な計算を知らない他の人が使うことを想定していましたので、コピペは除外しました。 >ヨッシー さん 私も、今回の質問に際してどのパターンでも通る形で書いてみましたが、結局そこに落ち着くのかも。いくつか知らないとハマる注意点はありますが、どれを採用するかに悩むくらいなら全然いい。 EXECで読み込むだけの時とサンプルが動く時の分岐法が分からないので、そこを教えてほしいです。

理由も付けていただけると助かります