トップページ > ソフトウェア > 2011年12月03日 > mXU25fWD0

書き込み順位&時間帯一覧

7 位/958 ID中時間01234567891011121314151617181920212223Total
書き込み数0000000000113300100000009



使用した名前一覧書き込んだスレッド一覧
名無しさん@お腹いっぱい。
自動化ツールuwsc使いよ集まれ7

書き込みレス一覧

自動化ツールuwsc使いよ集まれ7
407 :名無しさん@お腹いっぱい。[sage]:2011/12/03(土) 10:57:34.98 ID:mXU25fWD0
IF (test_flag xor PEEKCOLOR(446,182))=($FFFE or (test_flag xor 1)) then その後の処理
って感じでtest_flagの状態によって切り替えて判定してるんだけどもっとシンプルに書きたい
norが有ればもう少しましに
IF (test_flag xor PEEKCOLOR(446,182))=($FFFE nor test_flag) then その後の処理
って感じで書けるんだろうけどnotすらないようなので・・・
○PEEKCOLORの取りうる値は$FFFFかそれ以外
○test_flagは0か1の値を取る
○検出したいのは$FFFF

やりたいことは
○test_flagが0の時、$FFFF=PEEKCOLOR(446,182)を検出するとthenを実行
○test_flagが1の時、$FFFF=PEEKCOLOR(446,182)を検出出来なければthenを実行
頑張って一回で両方を判定しようとして2,3時間悩んだ結果がこれなんだ
実際にはthread処理してて別のルーチンでtest_flagの状態を変えてるからタイミングが悪い時に
2回判定するとタイミングずれて結果が変わる
両方を同時に判定しないといけないんだけどもっといい方法無いかな
自動化ツールuwsc使いよ集まれ7
408 :名無しさん@お腹いっぱい。[sage]:2011/12/03(土) 11:25:51.48 ID:mXU25fWD0
○test_flagが1の時、$FFFF=PEEKCOLOR(446,182)を検出出来なければthenを実行
↑間違えた
○test_flagが1の時、$FFFF=PEEKCOLOR(446,182)を検出するとthenを実行

普通は判定で処理が変わるけど、処理が同じで判定の方が変わる
自動化ツールuwsc使いよ集まれ7
411 :名無しさん@お腹いっぱい。[sage]:2011/12/03(土) 12:08:59.69 ID:mXU25fWD0
>>409
test_flagは別ルーチン(thread処理で別のが切り替えてる)
ダメな理由は
if peekcolor(446,182)=$FFFF and test_flag=0 then 〜
if peekcolor(446,182)<>$FFFF and test_flag=1 then 〜
って書くとifとifの間の実行中に別スレッドがtest_flagの値を切り替える可能性があるから

>>410
これも同じ理由です。そもそも状態を記憶するためにフラグを使ってるのですから
直接参照した上でないと代入や判定の際にタイミングずれて誤作動しました
自動化ツールuwsc使いよ集まれ7
415 :名無しさん@お腹いっぱい。[sage]:2011/12/03(土) 12:26:58.10 ID:mXU25fWD0
>>408が間違いです。ほんとすみません
test_flagが1の時、$FFFF=PEEKCOLOR(446,182)を検出出来なければthenを実行であってました
どうも混乱しててごめんなさい
自動化ツールuwsc使いよ集まれ7
416 :名無しさん@お腹いっぱい。[sage]:2011/12/03(土) 12:34:58.12 ID:mXU25fWD0
>>413
ほんとうにごめん。>>415です。>>408が間違ってました
気分を害したのならあやまります。ただ、こう言ったロジックの話は
チェスとかパズルとか将棋みたいで知的遊戯な気がするので聞いてみました
詰め将棋やってて解けたと思ったら実は他に逃げ道が有って・・・みたいな感じですね
>>412なんですがその通りなんですよね
完全に回避しようと思ったらuwsc自体にthread処理を一旦止める実装がないと無理だと思います
ただ、
if peekcolor(446,182)=$FFFF and test_flag=0 then 〜
if peekcolor(446,182)<>$FFFF and test_flag=1 then 〜
と書くよりは誤作動する確立が減るので、一回でなるべく高速に判定したいと思った結果なんですよ
自動化ツールuwsc使いよ集まれ7
421 :名無しさん@お腹いっぱい。[sage]:2011/12/03(土) 13:29:11.91 ID:mXU25fWD0
>>417
わざわざ試して頂いてありがとうございます
ちょっと自分なりに条件を考えてみたのですが
IF (test_flag xor PEEKCOLOR(446,182))=($FFFE or (test_flag xor 1))
のフラグが最初と最後で書き換えられていない場合でPEEKCOLOR(446,182)が$FFFFを返す場合

フラグ1の時
1 xor $FFFF=$FFFE or (1 xor 1)これが判定式に入るので
if $FFFE=$FFFE then〜 の式になる

フラグ0の時
0 xor $FFFF=$FFFE or (0 xor 1)
if $FFFF=$FFFF then〜 の式になる

これは思った通りの動作です

改行が多いと怒られたので
自動化ツールuwsc使いよ集まれ7
422 :名無しさん@お腹いっぱい。[sage]:2011/12/03(土) 13:29:31.63 ID:mXU25fWD0
途中で切り替わってしまった場合は
フラグ1の時
1 xor $FFFF=$FFFE or (0 xor 1)これが判定式に入るので(もしくはその逆で0 xor $FFFF=$FFFE or (1 xor 1)かもしれない)
if $FFFE=$FFFF then〜 の式になる

フラグ0の時
0 xor $FFFF=$FFFE or (1 xor 1)同上
if $FFFF=$FFFE then〜 の式になる
IFの判定の瞬間に切り替わっちゃうとどうしようもないけど、頑張って考えたて
安全性を求めるなら、この条件を数回実行するって言うのしか方法はなさそうなんですよね

>>418
はい、ほんとうにごめんなさい。反省してます
自分でも必死に考えて試行錯誤の結果なのできっちり理解できてませんでした
if peekcolor(446,182)=$FFFF xor test_flag then 〜
なんですけど試したらちゃんと動きました。ありがとうございます
ビット演算が実は逆に時間がかかる場合もあると聞いてビックリです
>>420
いえ、ありがとうございます。勉強になりました
>>418で答えていただいたのを理解してました。遅レスですが皆さん本当にありがとうございます
自動化ツールuwsc使いよ集まれ7
423 :名無しさん@お腹いっぱい。[sage]:2011/12/03(土) 13:33:29.83 ID:mXU25fWD0
あと、事後報告なんですが、>>418で回答頂いたのをコードに組み込んで
printで確認したら、やっぱり何回かに1回の割合で誤判定してるみたいです
3、4回走らせると、誤作動はしてないみたいなので、本当にthen以降を実行するかはループを回してチェックする事にしました
ありがとうございました
自動化ツールuwsc使いよ集まれ7
425 :名無しさん@お腹いっぱい。[sage]:2011/12/03(土) 16:28:49.35 ID:mXU25fWD0
>>424
そうなんですか
最終的にはif ビットが立ってるか? thenって言う判断なんですね
凄く参考になったので今if文全部見直してます


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。