れいさん いや～将来有望な若手ですから、ぜひじっくりと育ててください。abs かましたのは反省している。 親切な人多いのはいいんだけど、時として船頭が多すぎるきらいもありますね。 >Andでも&&でもどっちでもいい むー、これほど力説しても * は候補にすら上らないのか・・・

プログラム書いた経験はありますか? プチコンが全くの初めて??

使い方 var n=256 '実データ数、2のべき乗にすること var x[n*2] 'fftに渡す複素数の配列、変換結果もここに入る 偶数インデックスが real part, 奇数インデックスが imaginary part です。 fft n, x 'xをフーリエ変換する。結果もxに返る ifft n, x 'xをフーリエ逆変換する。 @l:data 1,0, 0,0, 0,0, 0,0 copy x,@l fft 4,x これで x は {1,0, 1,0, 1,0, 1,0} になります。

あの！大浦FFTを移植しました。key=QKA51X3D 見える…見えるぞ！私にもスペクトルが見える！ 再びテスター募集します。 使い方はコメントで。

いいですよ～

綺麗ですね。45度から数ドットずらすことでモアレを生んでいるように見えます。

おかえりなさい～～ あじさいに望月癒されますねえ

dim v[4] という整数の配列から x という値を探すとして i = 0 while i < 4 && v%[i] != x i = i + 1 wend と書けば期待通りに動くんですけど、これを and にしちゃうとバグるのね。こういういちいちプログラマ好みな仕様が C 言語やめられまへんな～な理由です。 >みき氏は妙齢の素敵な女性だし 違いますね。そういやめぐりー先生には「動けばいい」と言ってたれいさんが、Newあっきーさんには方法論を語ってるあたりも、なるほどと思いましたね。 イカさん、 if P then if Q then ～ if P && Q then ～ は完全に一致します。

おちゃめさん BUTTON(2) AND 16」の値が16、かつ、「変数SG」の値が0 その「かつ」はおちゃめさんの脳内で and ですか? && ですか? * ですか? spchk も button 同様単なる特例でしょうね。一般的な「かつ」に比べたら。

ん? 最初から && を教えて and はボタン判定専用の特例と教えれば、余計な苦労を背負い込まずに済むと思いますが??

そういう文化を含めて愛していますね。 (MSからRFC出してきた時は心底びっくりした) まあデファクトスタンダードって言葉もあるように、The Internetの世界では RFC が聖典そのものですから。 あと RFC には status というランクシステムもありますよ。

とりゅふさん、置き去りにしてごめんね。 うえこうさん、孤立無援四面楚歌絶体絶命の中救援ありがとう。 実は && || には and or よりも平均的に速いという特性もあるんですよ。 この仕様は C 言語からの借用なんですけど、そもそも C 言語は筋金入りのハッカーが自分達が使うために設計して実装した言語なんで、とびきり使いやすくできてるんです。

ん? 上記の通り私は AND OR どころか * + でも容認しますし、&& || 原理主義でもありませんよ? Robustness principle = 堅牢性の原理 MAY = してもよい SHOULD = すべきである MUST = しなければならない ああ、私は RFC 原理主義者かもしれませんね。

RFC 1122 によれば Robustness principle とは "Be liberal in what you accept, and conservative in what you send" です。 日本語に訳しますと「送る側は慎重に、受け取る側は寛大に」 この場合sendされるはソースコードでacceptするのは SmileBASICです。その出力が実行結果。 工夫が必要な、ともすれば綱渡りのようなコードをsendするよりもSmileBASICの意図どおりに && || を使うのがより Robustness principle にかなっていませんか? and or * + を「かつ」「または」の意味で使うのはRFCで言えばMAY相当でしょう。 && || を使うことがSHOULD相当ですね。無論MUSTではない。

いえ、say さんのコードでも完全に意図どおりに動くでしょう。決してウソではないのでご安心を。 say さんのコードは工夫によって and を「かつ」の意味で使うことに成功してます。同じ工夫によって * を「かつ」の意味で使うことも可能です。 その工夫を定型句化して常に and と * を「かつ」の意味で使い続けるというアプローチもあるでしょう。 私のアプローチは、&& を使えばその工夫自体不要になるから、そっちの方がよくね? ってことです。

SPANIM の文法はよくわかりませんが、"XY"-60 はありえないです。文字列と数値の演算なんで、エラーになるよね。

「&&の方がいい」ってレベルじゃなくて、「&&じゃなきゃダメ」ってレベル。 なんとなれば、P かつ Q の意味で P * Q を使うことができます。P または Q の意味で P + Q を使うこともできます。 でも * とか + とかそういう演算子じゃないよね。 それと全く同じことで、 and や or は「かつ」「または」に使うべきではないってことです。 かつ、またはの意味で and or 使う人が多いのは、プチコン以外の basic ではそうなってるからですね。でもそれはプチコンの流儀ではない。

「P かつ Q」の意味で「P and Q」使うとバグるよ。 必ず P && Q を使いましょう。 64行目もね。 P または Q の場合も必ず P || Q を使いましょう。 普通のプログラムではまず and とか or とか使いません。 プチコンでほぼ唯一の使い道がボタンの判定。

なんだろう? グランドピアノとか想像したのかな??? ピアノと言っても安いエレピです。誤解なきよう。

C++じゃなくてC? それだったらわかる。 C++だったらまあどっちもどっちかな～～～(談話は個人的な体験に基づくものです)