つ修理

プログラム作成の苦労とか「俺はお前の知らない事を知っている」症候群ぽいですね。 苦労したから偉いわけでもないし、先に始めてたから偉いわけでもない。

でんぺんさん 上下限不明の場合は、最初の推定 x (x>0とする) で上下限のどちらかがわかります。(x より大きいなら下限が x, x より小さいなら x が上限)。 次に逆二分法(?)を使い、もし上限が不明なら 2x, 4x, 8x, .. で上限を確定します。下限が不明なら -2x, -4x, -8x, ... で下限確定。 そしたらあとは通常の二分法でいけます。(nx と 2nx の間 (n=0でない整数))

xscreen を外に出すのはボルガはかせさんの言うとおり。 186行目 while の中から goto でどこか飛ぶのは異常です。 そもそもここが while ループである必要があるのか???

こういちさん すごい!! 全盲の男性が普通にバスケットボールゲームをプレイしてたのは見たことあります。自らの口で「チッチッ」とパルス的な音を発し、エコーロケーションで周囲の状況を調べるアクティブソナー方式でした。 あんな感じなのかな???

(1) そのグラフと原点に対称なグラフ(y=-x^2)を脳内に描いてください。 (2) その逆U字のグラフを、y軸を軸に 90 度回転してください。結果は三次元のグラフになります。 逆U字の半分は画面から飛び出して、残り半分は画面の奥に引っ込む感じになります。(わかりますかね?) (3) (2)のグラフを元の y=x^2 のグラフと合体させてください。 (U字のグラフの頂点同士がくっついたグラフになります。ただし下半分は90度ねじれてくっついている) これが x が複素数の時の y=x^2 のグラフ(がこの世に交わったグラフ)になります。 U字がx軸より上に行くと実数の範囲では「解なし」になりますよね。 複素数まで解に含めると、下半分の逆U字はx軸ではないけれど、y=0という平面と二つの交点を持ちます。この交点が虚数解になるというわけです。(イメージできるかな?)

あれ?? 引き分けって drawn game じゃないのかな???

二頭身キャラだけじゃなく、こんなかわいいイラストも描けるとは!!

体育の日なのでプチコンしないでスケートしてきました。 シーズンじゃないので空いててよかったです。 6人とすれちがえてラッキー!

な、なんかかわいいな・・・

確かに dat/grp が分かれているのは意味不明ですね。 open/close は、まあその方がいいんだけど、プチコンの利用形態からするとそぐわないかなあ。close しないで終わったらどうするの? とか。 ただ巨大なファイルをアクセスするのに一度全部メモリ上に置かなければならないってのが困りものですね。

確か list err で飛んだ先が一番下の行のとき消えますよ。 そこでおもむろに direct -> edit でカーソル復帰します。 ・・・というのは関係無い???

空に昇って鳥になった

技術的な問題だったら最悪でも妥協すればなんとかなる!! がんばってね!! (これが法的な問題とか政治的な問題だとどうにもならない)

わんやしゃさんのイラストは、空気の動きを感じさせるものが多いですね。 背景ないけど外にいるんだなーって思います。 焼き菓子?? クッキー? おせんべい? ケーキかな??

いや、プチコン(smilebasic)を他の言語で実装しようとするとそういうのの塊になるし、プチコンをプチコンで実装しようとしたらまあめろんさんのコードみたいになりますね。 可変数引数がめんどくさいのよね。 文法もめちゃくちゃなので、やるとしたプチコンのサブセットになるのかな～～

AFTER BURNER II ですね わかります (画像使用許諾: http://faq.sega.jp/faq/show/4605)

一般に、再帰を使ったコードは、再帰を使わないで書くことができます。 やろうとすると非常に大変なんですけどね。 もしやるのであれば、まず再帰版を作ってアルゴリズムの妥当性を確認してから、非再帰版を起こすってのがいいかなあ?? いずれにせよ後ろ向きの解決なんですよね。 プチコンが再帰呼び出しの深度を深くすれば済むところを、 こっちサイドで処理系の穴を回避して面倒なことしなければならないという・・・ (お仕事ではよくある話ですww) 目標が「9x9解けるソルバーを作る」であればそういう努力が必要になりますし、 「バックトラックソルバーを書いてみる」であれば、4x4まででいいんじゃないかな?

あ、そうなんです。 プチコンでないと書けないもの(スプライト使ったもの等)以外は、まず PC で十分デバッグしてからプチコンに移植するという方法をとる事が多いです。 プチコンに比べると、エディタとデバッグ環境込みで、PC の方が 10 倍くらい開発が捗る感じです。 特にプチコンはデバッグが大変ですよね。PCでの開発(主に C 言語)だと「ステップ実行」といって、プログラムを一行ずつ確認しながら実行できる機能があり、これが大変便利なんです。

solve の引数に整数をを使う理由は、 - 実行時間が速い - プログラムが簡単 の二点に尽きるのですが、反面 32 bit しかないので 5x5=25 は解けるが、6x6=36 は解けません。 なので、上を目指すなら最初から"0""1"の文字列を与えるようにしておけばいいんだけど、例のスタックの問題があるために、どのみち 6x6 は解けないという・・・ 悩ましいですね。