うっかりの記録――OR関数とAND関数
はじめに
この記事は、下記の記事内容を踏まえています。
条件判定の総合
FILTER関数の挙動の解説
上記の記事における話の流れは、次のようです。
FILTER関数は、ある範囲を行方向または列方向でフィルターする関数である
FILTER関数の第2引数は、条件と説明される事が多いが、その実態は、行または列の可視状態を定義する配列引数である
第2引数には直接OR関数やAND関数は入れられないので、配列を返すような比較演算数式を入れる
複数条件になれば、上記比較演算数式の和や積を取る必要がある
条件が複数になると途端に複雑になるので、表に作業列を追加して、1セルに1条件の判定を入れる
各条件を総合させるために、条件判定のセルをSUM関数やPRODUCT関数で加算もしくは乗算する
SUMやPRODUCTでの条件の総合
流れはこうなのですが、ついうっかりしていました。と言うのは、上で強調した、
各条件を総合させるために、条件判定のセルをSUM関数やPRODUCT関数で加算もしくは乗算する
この部分について、
そもそもSUM関数やPRODUCT関数を条件の総合に使う必要は無い
所に気付かずに説明してしまったからです。
流れを振り返ってみると、FILTER関数の引数としてOR関数やAND関数を直接入れられないので、そこでは
=sushi_tabeta[ネタ]="サーモン"このような数式にして、配列を返すようにしたのでした。なぜそうするかと言うと、
OR関数やAND関数は配列を返さない
からです。それらが配列を返さないので当然、可視状態を定義する配列を作れません。だから、範囲と何らかの値を比較演算して配列を返すようにしたわけです。
で、その流れで私は、数式が複雑になるので、条件判定を作業列にまかせて、FILTER関数では条件を総合した作業列を参照させるようにする、という手法を紹介したのですが、その際、
FILTER関数では通常、引数にOR関数やAND関数を入れない
事を引きずって、作業列での条件判定の総合をも、OR関数とAND関数を使わないようにし、代わりにSUM関数やPRODUCT関数を使ったのでした。
しかるによく考えてみれば、条件判定を作業列に出してあって、複数の条件を総合してセルに入れるのですから、そこで返るのは
1つの値
で構わないのです。0かFALSEなら非可視ですし、0以外の数値かTRUEなら可視です。そして、FILTER関数では、その
条件を総合したセルを複数参照させる
のでした。であれば、です。
各行での条件の総合は、OR関数やAND関数が使える
のです。ここが、私がうっかりしていた所です。先述したように、FILTER関数にORやANDを入れないのを引きずったのですね。だから、わざわざSUMやPRODUCTを使ったという次第。
OR関数やAND関数での条件の総合
SUM関数やPRODUCT関数を使った数式はこうです。
いっぽう、OR関数とAND関数を使った総合はこうです。
FILTER関数の結果は同じです。違うのは、SUMやPRODUCTは数値を返すのに対し、ORやANDは、TRUEもしくはFALSEを返す所です。FILTER関数の第2引数は、数値の配列でも真偽値の配列でも良いので、結果は同じとなります。そして、ORとANDは
OR関数：引数で与えられた1つ以上の論理式の内、1つでもTRUEならTRUEを返す
AND関数：引数で与えられた1つ以上の論理式の内、すべてTRUEならTRUEを返す
このような機能を持っており、0と1（0以外の値）はそのままFALSEとTRUEとして評価される便利な性質があるので、COUNTIF関数で返される0か1をそのまま、OR関数やAND関数に投入しても上手く動くという寸法です。
動きと名前
SUMやPRODUCTを使った数式でも、ORやANDを使った数式でも、同じように動きます。そのように作ったので当然ではありますが、機能的には差はありません。しかるに、
返ってくる値が、ただの数値では無く真偽値
ORとANDがどのような機能を担っているか明瞭
これらを考慮すれば、やはりOR関数とAND関数を使用するほうが適切であり、SUM関数とPRODUCT関数を使用するのはスマートさに欠ける、と言えるでしょう。
教訓
思い込んだまま物事を進めると、より好ましいやりかたを見過ごす場合がある。