Aボタンが押されているかどうかを判定するのに B=BUTTON() IF B AND 16 THEN ～ というような書き方をしている人は非常に多いと思いますが、これはあくまで省略形であり省略せずに書こうとすると IF (B AND 16)==16 THEN ～ となります。（IF (B AND 16)>0 THEN ～ も特定条件下でしか使えない） どういう場合に省略できるのかを理解して使うのであれば問題ありませんが、そうでない場合は省略形はあまりオススメできません。

はい、私は、 IF (B AND 16)!=0 THEN と言う意味で使っています。

オススメできないのはなんでですか？ となると自分は知らずに省略してたのか (・ω・:)

コータさんへ Aボタンのように単独のボタンが押されているかを判定するのならばその考えで間違いないですが複数ボタンが押されているかを判定したい場合はそれだとまた問題が発生する場合があるんですよね。

うくじーさんへ なぜオススメできないかというとプログラムがちゃんと動かないという原因を招いてしまうからです。 例えばAボタンとBボタンの両方が押されたかどうかは IF (B AND 16) AND (B AND 32) THEN ～ という感じの記述になってしまいがちです。（ANDを&&で記述するというのもビット演算と論理演算の区別がつく人以外はオススメできない） これが、基本通りに書けば IF (B AND 16)==16 AND (B AND 32)==32 THEN ～ で正しく動作します。 また、この基本形の意味をちゃんと理解していれば IF (B AND 48)==48 THEN ～ とすることでABボタンの同時押しの判定も簡単に可能になります。

私は、同時押しに、特別な意味を持たせたプログラムをつくったことがないので･･･すみません。

成る程。勉強になります。 同時押しに割と興味があったので覚えられて良かったです。

コータさん、うくじーさんへ IF (B AND 16)==16 THEN ～ という基本形さえ覚えておけば同時押しだろうとどんなボタン判定だろうといとも簡単に記述できるので超オススメです。

ボタンの状態判定については、２進数の仕組みと、ビット演算子と論理演算子の違いを平易に説明していただけるとありがたいです。たぶん、それが、わからないと話についていけなくなるおそれがあるような気がします。

僕は B=BUTTON() IF B==16 THEN… ってやってます。

同時押しの場合、足し算した上でビットの論理ORと同じことを利用した式よりは、分けて IF (B AND 32)!=0 AND (B AND 16)!=0 THEN か、論理演算子を正しく使って IF (B AND 32) && (B AND 16) THEN の方が初めての人には分かりやすいと思っていますが、どうでしょうか？ (論理演算子自体も正しく覚えた方が無難なので、&&の方で教えてます) もちろん、ビット演算子を理解した後なら、合わせて使った方がすっきりしますね。

同時押しの判定だったら、 IF (B AND (16 OR 32)) THEN という書き方もありますね！

ビット演算を正しく理解するよりは、けいさんの例のような論理演算について覚える方が簡単そうな気がします(´ω｀) 最初のうちは、「かつ」は&&で、「または」は||で、ANDとORは何かの計算用だから「かつ」とか「または」じゃない、って覚えておくだけでも十分かもしれませんし。私は最初そう覚えていました( ´ ▽ ` )ﾉ

んー皆さんのコメントを見てたらわからなくなってきました。「OR」の考え方とか。 あと、「ll」←これってどこにあるんですか？

>うくじーさん キーボードではAの左に、説明書では「30 BASIC基本仕様」の「論理演算子」のところに説明があります。

ANDと&&って違う意味だったんですね。省略してうつための記号なのかと思っていました

よっぱらいさん それだと、「AとBが同時に押されたら」ではなく「AとBのどちらかが押されたら」という意味になってしまいます。

`(B AND 48)!=0`(AまたはBのどちらかが押された)と `(B AND 48)==48`(AとBの両方が押された)では 結果が変わってしまいますから、複数ボタンの判定には注意が必要ですよね。 その辺がややこしいと感じる場合は、けいさんの言われるように各ボタン個々の判定結果を&&,||で連結するようにした方が無難かなと思います。 ビット演算子(AND, OR)と論理演算子(&&, ||)の使い分けについては 「条件式中には比較演算をおく(ゼロとの比較を省略しない)」ことを徹底した上で - ビット演算子:数値どうしの計算を行うもの - 論理演算子:比較演算による結果どうしを組み合わせるもの という認識でいると間違えにくいかなと思っています。

nyannziさんへ ANDはビット毎にANDをする演算子なので、２進数をイメージして、１になっているビットはそのままで、０になっているビットは０になります。その特徴を利用してマスク計算に使っている例が、ボタン状態読み取り時によく見られるANDだと思います。ビット演算子は、３２個（プチコンの場合）の１桁２進数を同時に論理演算する機能と考えることも出来ます。

他の言語でも必須知識だと思うので、慣れてきたらバグ覚悟で色々な表現にチャレンジすると良いかもしれませんね。 XOR AX,AXなどトリッキーな使い方あってこその2進数ですし。

コータさんへ その辺はここで書くと長くなるので私のサイトの入門講座で書いていく予定です。 もっとも今回入門講座で書いた基本的な使い方だけでもほぼすべての状況には対応できると思います。 かっちんさんへ ビット演算子ANDを使うのは他のボタンを押した状態でAボタンが押されているかを判定可能にするだけなのでAボタン以外を押さないことが前提ならばそれで問題はないです。

けいさんへ 初心者にとって分かりやすいかどうかはどのようなステップアップをとるかで決まると思います。 適切なステップアップとそれに至ることが可能な情報の有無が重要となるでしょう。 私のサイトのプチコン3号入門講座ではIF (B AND 48)==48 THEN ～ でABボタン同時押しの判定が可能になるまでが分かりやすく説明しています この方法ならばビット演算の仕組みも2進数も知らなくても10進数だけで対応が可能です。 しかも、基本形を覚えるだけですべてに対応できるため覚えることが少ないのもメリットです。

けいさんへ（続き） Aボタンを押している場合はB AND 16の値は16になるため「!=0」よりは「==16」の方が自然だと私は思います。 比較演算を省略して誤動作する原因は無意識のうちに「!=0」を行っているためなのでそれを防止する役割もあります。 また公開されているプログラムの多くはIF 条件式 AND 条件式 THEN ～で記述されているため結局「&&」だけの説明ではなく条件式の結合としてANDの説明も必要になってしまいます。

よっぱらいさんへ それはIF B AND 48 THEN ～と同等になりますが、それだとABボタンの同時押しの判定はできてないんですよね。 スーさんへ 自分で覚えるならば自分で分かりやすい覚え方をするのが一番ですが、講座などを書いたり他の初心者に教える場合はなかなかそういうわけにもいきません。 初心者が例えばIF A==1 AND B==2 THEN ～ みたいなIF文を見たときにANDが「かつ」ではないと認識したらどのように理解させるかが問題になってしまうのが難点ですね。

うくじーさんへ ビット演算と論理演算の違いは最初のうちは難しいかもしれませんが、それが分からなくてもIF文においては比較演算（「!=」や「==」など）を省略せずに書けば気にする必要は全くありません。 もやしもどきさんへ 「分からないうちは比較演算を省略しない」というのが初心者にとっては最も分かりやすいと思います。 「比較演算を省略しない場合の書き方」が今回の焦点となっている部分でBUTTON関数においては「(B AND 16)!=0」や「(B AND 16)>0」ではなく「(B AND 16)==16」が最も適切だと私は考えています。 初心者のうちからそうやって覚えておけば「このプログラムがなぜ正常に動作しないのか分からない」という心配は皆無になります。

ヒロフミさんへ 私もトリッキーな書き方を多用していますが、それは初心者にはあまりオススメしません。 いろいろ試して仕組みを理解した上で使用するならば全く問題ないんですけどね。

>おちゃめさん 丁寧にありがとうございます。初心者講座のボタン判定のページも拝見致しました。とても分かりやすかったです。 ビット演算の仕組みを避けるのでなく、10進数の足し算と「足しても被らない組み合わせ」であることを使って、ビット演算のANDの本質を分かりやすく説明されていましたね。 確かに、AND演算子が値から値を取り出すものだと理解していれば、IF (B AND 48) == 48 THEN の意味もすっきり理解できますし、(B AND 16)が16になるのも違和感なく扱えると思います。 私は、IF文の「かつ」に「&&」以外のものを使うのがそもそも正しくなく、ボタン同時判定のバグなどの原因になっていると考えていますが、歴史的な理由から公式含めてANDで代用しているプログラムが多いと知り、教える時にその辺りは悩みどころです……

は、私としたことが...

けいさんへ プログラミングをゼロから始めた初心者や今後他の言語を習得する場合を考えると「かつ」は「&&」で覚えるのがベターですが、BASICでは古くからビット演算子「AND」を「かつ」の代わりに用いていてプチコンにおいてもmkIIまではそうでした。 それを考えると「&&」よりも「AND」を先に教えるのが初心者にとっては有用と私は考えています。 それに「AND」で正常に動作しているプログラムを「&&」に置き換えても正常に動作するのに対して「&&」で正常に動作しているプログラムを「AND」に置き換えたら正常に動作しない場合があるため初心者に教える場合は最初は比較演算を省略せずにANDを使用するというのを徹底させておいて後から「&&」を使うのがベターであるというのを教えたいと私は考えています。

>おちゃめさん なるほど。やはりBASICやプチコンの歴史から、はじめは「AND」を使わせるのが自然と考えられているのですね。 私がプチコンもBASICもこれが初めてで、そのあたりの経緯も恥ずかしながら最近知ったので、論理演算にビット演算子を使う事に抵抗を感じているのだと思います。(多少話がそれますが、同様にビット演算の結果を何かと比較しないままIFで使うことも、繋ぐのは論理演算子が前提なので私は省略ではないと捉えています) はじめはアプローチの狙いが分からず色々疑問がありましたが、考えを伺えて色々勉強になりました。 ありがとうございます。

そんな深い意味があったのですね。 わたしは、せっかく論理演算子＆＆と｜｜が導入されたので、条件判定は、基本的に論理演算子を使い、ビット演算が必要なときだけビット演算子を使えば良いぐらいしか考えていませんでした。 失礼しました。

けいさんへ 結局は古くからBASICを使ってきた私と他の言語を使ってきてプチコンではじめてBASICに触れたけいさんとの差ということになるのでしょうね。 ANDを「かつ」として見なすか見なさないかの差も比較演算子が無いのを「省略」と見なすか見なさないかの差もそのためです。 コータさんへ ビット演算子ANDを「かつ」の代わりとして用いる場合には比較演算子さえ省略していなければ何ら問題はないため初心者には「省略しないで書く」というのを強く推していきたいと思った所存です。 そうすれば少なくとも誤動作が起きる心配はなくなります。

そうですね。私も全く同じように思います。 おちゃめさんのアプローチの狙いや背景も一応理解した上で、自分が今のところ「これがベストかな」と考える方法は基本的に変わってはいないのですが、かといってもちろん、おちゃめさんの方法が良くないと思っている訳でもないです。 プログラムって機械的で厳密なはずなのに、その人の個性や背景が意外と如実に反映されて面白いなと思います。