実質的に人の認知すべき状態と内部処理で一致しな
ければならない処理は存在しますが、その状態の処理
は人の認知と同じかと言うとそうでもない場合があり
ます。
基本的に、処理には
【 変数として存在し、人が見てそれと一致してなく
てはならない物 】
と【 そうではない処理 】が存在します。例えば、LED
が7つ揃った文字盤で数字を表示する場合、
■ LEDの表示処理
ブーリアン型（0と1）
■ 処理する対象物の数
7つ
となります。とりあえず、その場合ですが、人の目から見た
場合に
【 10新数表記に見える事 】
と言う条件が付くと
■ 入力値
０~9
■ メモリーに格納する数値
０~9
となります。つまり、この時
■ 入力とメモリーに格納する数値は同じ
■ 入力と表示される数値は同じ
と言う条件が付きます。この条件から、命題によって
■ メモリーに格納される数値と表示は同じ
とも言える訳ですが、この三者の関係性は担保される必
要があります。
しかし、処理を考える場合にその店頭をどう考えたら
いいだろうか？というので複数の思考方法が出てきます。
とりあえず、
な感じのものがあったとして、
との表示が可能な訳ですが、この状態で考えると構造的には
【 その値がメモリーに格納された場合、その対象の
LEGを発光させる 】
と言う条件で片付くので、それぞれの数値に、パターンを記録
させておき、処理する方法をとれば大丈夫という事になります。
配線がつながってる場合だと考え方が少し違うので、プログ
ラムとして考えた場合、
■ 入力用の数値を格納する変数
を用意して、0-9までの数値を入力できるようにします。
ただ、これだけだと数値を入力した処理だけなので、これに
対して
【 各LEDに番号をつけ、それに対しての信号を制御する 】
と考えると、処理の方法が見えてきます。とりあえず、
【 ２ 】
【 １ 】 【 ３ 】
【 ４ 】
【 ５ 】 【 ６ 】
【 ７ 】
と言う風に考えた場合、
１：3,6
２：2,3,4,5,7
３：2,3,4,6,7
４：1,3,4,6
５：1,2,4,6,7
６：1,2,4,5,6,7
７：2,3,6
８：1,2,3,4,5,6,7
９：1,2,3,4,6,7
０：1,2,3,4,6,7
と言う条件になります。つまり。この条件に真のパルス
を送信し、送信しない場合には、反応なしにしておけば、
上記の条件が成立します。
では、もう少し考え方を変えてみて、発行体側で判断
してみると
１：456890
（1,2,3以外）
２：23567890
（1,4以外）
３：12347890
（5以外）
４：23456890
（2,7以外）
５：268
（上記の条件）
６：134567890
（2以外）
７：2356890
（1,4以外）
となります。つまり、メモリー格納の数値基準である
場合、
【 入力された変数に対して、8つのセンサーの
複数に対し処理を行うプログラム 】
になるので、処理系が複数発生します。
つまり、変数をi、LEDをa1～a7と仮定すると、
IF i=8
a1=True
a2=True
a3=True
a4=True
a5=True
a6=True
a7=True
のような処理です。それを1~8まで書く感じです。これだと
フツーに誰でも思いつく方法ですよね。
では、LED側を主体に考えてみると、
if i<>5
a3=True
if i<>2
a6=True
のような条件です。複数ある場合は、
if i<>1 or i<>4
a2=True
のような感じです。上記の変数基準のもので考えると、
■ 処理の対比
【 変数を基準にした場合 】
（８～０まで）
IF i=8
a1=True
a2=True
IF i=9
a1=True
a2=True
IF i=0
a1=True
a2=True
【 LEDを基準にした場合、 】
if i<>1 or i<>2 or i<>3
a1=Ture
if i<>1 or i<>4
a2=Ture
if i<>5
a3=Ture
if i<>2 or i<>7
a4=Ture
if i=2 or i=6 or i=8
a5=Ture
if i<>1 or i<>4
a7=Ture
のように圧倒的に簡素になります。 仮に
var i=0;
var a1=Fauls;
var a2=Fauls;
：
と言う感じで、宣言して、同じように処理をするとしても、
ソースコードが入力した数値を主体としたものなのか、そ
れとも処理の対象側から見たもので考えるのかでソースコー
ドの状態が変わってきます。
同じ処理をしてるのに、ソースコードが全く違う事があ
るというのは、視点の違いだったり考え方の違いなんです
が、変数を前提としてパターンを割り当てると、その状態
に合わせたパターンを用意してそれを随時処理する状態に
なる訳ですが、0-7までのモノがパターンで発光すると言う
条件で、その発行パターンが存在する場合、そこに法則性
があれば、発行の有無において、少なくなる条件が必ず
出てきます。つまり、その真逆の条件がそれが実行される
内容なので、少ないほうの戻り値を参照して、その逆の
条件で機能するようにすれば、短いソースコードで処理が
できるわけです。
無駄に複雑にしようと思うと、これを３列で考え
右 00/01/10/11の配列
（16進数0-3）
中 000/001/010/011/100/101/110/111の配列
（16進数0-7）
左 00/01/10/11の配列
（16進数0-3）
で、000-373で制御するとかもありますが、これを縦で
00000-13131で管理する事もできます。（というか、
そこまでくると既に暗号ですが...。ｗ）
ただ、処理系で考えると非効率なので、この場合、パ
ターンで非表示を基準にしたほうが条件式が簡素になり
処理も複雑にならないので処理をする上でもソースコー
ドを簡素にできるわけです。
通常の考え方だと、人の意認知の場合、こうした配列
は経験則から、積み木・ブロック・パズルなどのように
【 形状をそれに合わせる 】
と言う【 図画工作的な発想 】が先に来るので、最初
の答えに行き着く人は多いのですが、少し視点を変えると
【 パターンからもっと簡素な処理が可能場合がある 】
と言う事が見つかる事もあります。
プログラミングをする場合、無駄な処理を省く作業は
発生しますが、手抜きでは物は動きませんから、モノの
見方考え方で、どうすればそれが効率的に動くだろうか？
や、【 無駄な処理をしていないだろうか？ 】を考え
る事になるのですが、こうした考え方もプログラミング
をする場合、おのずと必要になってくるような気がしま
す。
とりあえず、ソースコード度が短くなっていますが、手
抜きではなく同じ処理をする場合における着眼点御違い
であり、パターン解析をすれば、そうした傾向がある為、
その条件から、処理を少なくしても条件が満たされる内
容を判断すれば上記のような条件式でLEDの発光を実現
出来る訳です。
こうした処理がもう少し複雑な事をしてるので、この
辺りの処理が複合的に鳴っただけで無理が来る場合、効
率化というものが解らない場合があるわけですが、基本
的にどういう条件で何が動くのかを考えるのがプログラ
ミングで身につく能力なので、そうした思考も養われて
いくように思います。
ちなみに、BGEだとこの処理はロジックエディタで処
理する事になるのですが、前者の変数の値を基準にした
場合、一つのセンサー（0-9までの９つのセンサーが存
在する）でANDにつないで、1-7のオブジェクトの色を
変える処理を入れる事になるのですが、後者の場合、
【 それぞれのオブジェクトで、変数参照を行い
数値の条件以外だと色を変える処理をする 】
と言うものになります。つまり、センサー入力が複数
でアクチュエイターは一つのみになります。
つまり、先ほどのa1=Trueのような処理と言うの
は、アクチュエイターの処理ですから、条件式の数
値の種類が、センサーの数になります。そうなると、
【 複数のセンサーをorで繋いで、一つのアクチュ
エイターで処理する構造 】
になります。つまり、一つのセンサーで７つのアク
チュエイターを処理するのと比較すれば簡素な仕組み
にできます。
処理をする場合に、【 何がどう動くのか？ 】
というのを判断して物を考える事になるのですが、今
回の事例のように
【 確実に決まった法則性（今回のは、異なる条件に
なりようがないですが。）がある場合だと法則性
を利用して、処理方法を考える 】
と言う手法もあります。まぁ、打算的に法則性を口にす
る人間と言う尾は、複雑系辺りに法則性があると言う野
生に返る準備をしてるような固有種ですから相手にする
とロクなことにならないのですが、簡素なモノで見ると、
パターン解析と、そこから考えられる処理方法の最適化
は効果があるのが解ると思います。ｗ
これが8x8のLEDのグリッドになると、表示できるも
のが増えてきますが、これも法則性がある場合、8x8の
64のドットのそれで処理をする方法も扱えますが、
【 16進数で1行ずつその01の数値を指定した
モノを用意してそれを、個別のLEDの値と
して読ませたほうが効率的 】
なので、処理が複雑になると前述の方法だと無理が来る
ので、異なるアプローチを用いる事になります。当然、
これがピクセル数の多い画像とかになると、全く異な
る処理をすることになります。
