四則演算で数を作るスクリプト

四則演算に「計算で数を作るやつ」がJavaScriptで書いてあります。便利です。

1 3 4 6 と四則演算で24を作れ！みたいなことです。

『樫』の栞の作品。

マスメ上の回転その後

マス上の回転の表し方を関係各位のお力を拝借して作りあげました。 １番下のtestみたいな感じで使います。コンパイラはエラーなしで通過もまだ実際に使ってないので、バグありかも要注意。
enum EnumPepi { /* 000 */ PXPY, /* ペピ */ /* 001 */ MYPX, /* ミペ */ /* 010 */ MXMY, /* メミ */ /* 011 */ PYMX, /* ピメ */ /* 100 */ PYPX, /* ピペ */ /* 101 */ PXMY, /* ピミ */ /* 110 */ MYMX, /* メミ */ /* 111 */ MXPY, /* メピ */ }; class CPepi { EnumPepi e; public: CPepi operator =(EnumPepi n); CPepi operator *(CPepi n); }; CPepi CPepi::operator =(EnumPepi n) { e=n; return(*this); } CPepi CPepi::operator *(CPepi n) { int as; int av; int bs; int bv; int cv; int cs; CPepi cpepi; as=e&4; av=e&3; bs=n.e&4; bv=n.e&3; cs=(as^bs); if(as){ cv=(bv-av)&3; }else{ cv=(bv+av)&3; } cpepi=(EnumPepi)(cs|cv); return(cpepi); } void test(void) { CPepi a,b,c; a=PXPY; b=MXPY; c=a*b; /////////////////// }

デバッグ嫌いとプラーク嫌い

　プログラマの性質として
　　バグ嫌いはＯＫ
　　デバッグ嫌いはＮＧ

　つまり、プログラマの性質としては「デバッグ好き」が向いているということをいってます。時に、「デバッグは嫌いなので、バグが出ないプログラムを作る」なんてこと言う人がいますが、それを口にした当人くらいはだいじょうぶかも知れません。でも、これを聞いて、「そうだよなぁ〜」とかボーッツと思ってる人はダメです。ここで言う、「だいじょうぶ」、「ダメ」はいいかえると、プログラマとして仕事がうまくできるかどうかです。

と以上のようなことを記事にしました。ちょっと前に。

＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

海上飛鳥さんからコメントをいただきました。

NOB芦ヶ原師がまだお元気だった頃の、
「取材旅行中、I8(I hate)プラーク、なる
　ナンバープレートを見つけた。
　歯医者さんの車らしいが、
　誰もプラークつまり歯石を取りに来なかったら
　商売にならないはずだから、
　嫌うのはおかしい」
と云う理窟を思い出しました。
・・・
歯石自体が好きか嫌いかはさておき、歯医者さんが
歯石取り嫌い、と読める看板をもし出したらアウト
・・・みたいなことですね。

最初は、そうだ多分、いわいの言ってることとＮＯＢさんの言ってることは同じようなことを言ってると思いました。

が、実際は違いました！訂正です。

プラークは歯垢のことです。違う点の根本は、

Ａ　歯垢は歯医者が作りだしたわけではない。
Ｂ　バグはプログラマが作りだしたものだってことです。

もし、デバッガーという商売があれば、（いや実際にあるんだけど）

Ｃ　バグはデバッガーが作りだしたわけではない。

＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

ＮＯＢさんのいってることは、「嫌なものなんだけど、おまえはそれで商売してるんだから、それがなくなったら困るだろう」です。

シロアリ駆除会社はシロアリがいなくなると困るだろうってことです。言えてます。

＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

ところが、プログラマはバグが無いと困るかというと、困るどころか楽になります。そこが違います。いわいの記事は、それを踏まえたうえで「デバッグ好き」か「デバッグ嫌い」かを論点にしてます。

＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

実はもうひとつ、裏理論があって、「バグがあった方が実はやっぱりプログラマも困らない」という部分もあります。「少しくらいヤブ医者の方がもてる」って理論です。この話はまた書くとしたら、別記事で書きます。

＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

別件ですが、いわいの記事がメモ程度であって、説明がバリ足りないところに、問題がありそうです。これからちゃんと書くようにしよっと。

以上

麻雀格闘倶楽部新人戦１パーセント

麻雀格闘倶楽部新人戦　成績で１パーセントの上位に入りました。
つまり、１００人中１人の割合のいい成績ってことで。
成績っていっても連続する４回の高上がり勝負で、どんどん金をつぎ込めば何度でも挑戦できる形なので、いっぱいやってるやつ有利ってことです。

ですが、まあまあ１００人中１人なら立派じゃないかってことで、記事にしました。

でも、まだ６段です。７段８段ぐらいが前も一番きつかった記憶があるが今回もいっしょできつい。

デバッグ嫌いはバグ好きってこと法

プログラミングにおいて

デバッグ嫌いっていうことは相対的にバグ好きってことです。
「デバッグは嫌いって言ってるプログラマ」はダウトがかかります。

バグ嫌いはＯＫですが、デバッグ嫌いはアウトです。

プログラミング：現場１００回捜査の基本法

　「現場１００回捜査の基本」は刑事ドラマでベテラン刑事などが口にするコトワザです。事件が起きた現場に何度も行っていると、それまで気づかなかった証拠や状況に気づくことがあり、それが事件の解決につながる。というものです。捜査が行き詰まったときなどにも有効に働きます。少なくとも刑事ドラマでは。

　ここで「現場１００回捜査の基本法」はプログラミングのデバッグについての方法です。バグが出たらデバッグして直していきます。通常のデバッグでは、手が出ない状況になったとき、バグが出てる状況も何度も見ていると、思わずヒラメキを起こし、バグの早期解決につながるという話です。バグはそういった意味ではいつかは直るものですが、この時間の短縮は重要です。

プログラミング：同じものに同じシンボルをつける法

関係する他の方法：
　別なものには別のシンボルをつける法
　多いものに着目する法

基本的に同じものには同じシンボルをつけると、言われて見れば、あたりまえですが。その後のソースの整理、理解、自己診断に役立ちます。同じものと言い方があやふやなところが鍵かもしれません。何を「同じもの」「違うもの」の判断に使うかは、まちまちです。「多いものに着目する法」「これだけはやっとこ法」などを参照にするといいと思います。

例えば、ここで関数がいくつかあったとします。
void sjis2googleadr(const char *sjis,char *google);
void kijihtm2tb(char *kiji,char *tb);
void rakuten2tb(char *kiji,char *tb);
void kakupage(CString &url,CString &page);
void soutai(const char *page,char *rss);
void hitokiji(const char *url,char *page,int size);

執筆中

プログラミング：なんでも方法にしてしまう法

　プログラミングに関しての「こういった方針でやるといい」「このやりかたが便利」「これはとりあえず、こうしとく」というものを自分では、一般の人より知っています。なんせプロプログラマなので。今までぼんやりして形なく思ってた部分もありましたが、なるべくこのブログで吐き出して（掃き出して？）いきたいと思ってます。で、自分でも、いままでなんとなく使って、ある局面を乗り越えてきた手法を再認識すると。

　自分の考えてることはソフトウェア工学などとはある意味、違った切り口を持っているものと思ってます。でも、世の中の他のソフトウェア工学の技法とはおよそ、衝突するようなものではありません。併用して使うといいのではと思います。「なんか、ちょっとでも足しになりゃいいじゃん」って感じです。

　で、ここで発明？発見？した方法がこの「なんでも方法にしてしまう法」です。なんかこのやり方が良かったなとぼんやり、思ったら分析してしまって方法にしてしまうと。このブログを書いていて思いついた方法論です。

　それらの方法は、自分の趣味、あるいは習性で、抽象化する方向に進みます。ある種、「どんなときにも役立つ」「心構え」「おまじない」「とりあえず、やっとく」「迷わず、選択」的になります。自分では抽象化がすすめばすすむほど、ラッキー運営です。なんせそれらの方法が使える場面がどんどん増えますので。

　このブログは自分のメモとして、役立つわけです。でも、人に説明するときは具体例がないとダメなのも知ってます。ヒトのために「具体的に説明」って部分がどれくらい行けるかわかりませんが、やってみます。「なんでも方法にしてしまう法」の具体例はこのブログのプログラミングカテゴリーの記事そのものってことになります。

プログラミング：頑強性に気をつける法

頑強であるかどうかに気をつけているとプログラム全体の頑強性が出て結果いいプログラムになって行きます。

頑強性に気を配らないで「できればいい」「できてるのでいい」と思っていると、ちょっとした変更や何かの環境が変わったときに、炸裂します。

「ちょっとした変更」

８ｘ８のパズルが解ける。
Ａは出来てる。
Ｂは出来てる。
ここでＡもＢも同じにできてる。

例えば、それを１０ｘ１０のパズルも解けるようにしようとしたとき、
Ａは素直に変更できた。
Ｂはできたように見えたけどバグだらけ。

Ａが頑強性が高いことになります。Ｂはダメです。

「ちょっとした例外」

８ｘ８のパズルが解ける。
Ａは出来てる。
Ｂは出来てる。
ここでＡもＢも同じにできてる。

８ｘ８なんだけど解くデータに予定にない文字列が入ってる。
Ａは停止することなく、予定にない文字列が入ってるのを教えてくれる。
Ｂは一見平気に動いてしまい。データの不備に気づかない。＜＝※

※はまずいです。Ｂよりもまだ変なデータを食わしたら停止してしまう方がよほど親切です。

＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

例え、その時点でのある条件での性能が同じでも、頑強性には気をつけなければなりません。

＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

何か、紙を抑えるのに、ペーパーウエイトで抑えて置くかティッシュペーパーの箱で抑えておくかみたいな違いです。その時点で紙が飛んでいかないことは同じでも、もう少し強い風が吹くと違いがでます。

プログラミング：例えばブログでカテゴリをわける作業

ブログのカテゴリわけるのって大変。

なので、自分で決め事

パズル問題：少なくとも「問題」になってる。
プログラミング記事：プログラミングに役立つもの
記事：って書いてあるものは、単独で読んでも成り立つもの

カテゴリが決まってるもの：カテゴリが決まったものはタイトルにそのカテゴリ名を入れて行く。

以上は守ろう。あとは適当かな。


＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

この記事さえ、プログラミングに役立つ考え。プログラムコードを整理して行くには、これと同じ考えを使っていくと、スタートダッシュに出遅れずにすみます。

ことプログラミング記事には、
タイトル「プログライング：＊＊＊」とする。
方法には名前をつける「気になるところだけ整理法」
その方法を短い行で説明する
「気になるところだけでもプログラムを整理する」
さらに、詳しく説明。
「全部を整理しようと思うと、やるまえから撃沈します、特にぐうたら」
さらに、例をあげて説明、
「これが面倒くさくてねぇ・・・」
方法「多少難があってもパタンに持ち込む法」
法にはグラフィックでマークでも入れるか。

・・・・かいてるうちに自己言及的なあぁぁぁぁぁ。

プログラミング：private protected public

class の　関数や変数の隠蔽・公開の度合いを決めるのが private protected publicです。どれを使うかは時としてわからなくなります。そこで、自分が使ってる一つの実効的な方法がありますのでご紹介。

それは、「private protected publicの順で試してみる」です。

流れは以下のような感じです。

とりあえずまず、クラス内の変数・関数を全部 privateに設定します。何も指定がないとprivate設定になりますので、「private protected public」の記述を全部とっぱらうのといっしょです。

で、コンパイルします。
たぶん、エラーが出ますので、エラーが出た変数・関数をprotectedかpublicにします。

ここでprotectedはprivate publicとは若干指定内容の”軸”がずれてます。クラスを実際に使って、オブジェクトになったときには、plivateとpublicの区別だけになりますので。protectedはその変数や関数を継承した子クラスに開示することを示しています。

class 犬クラス
{
protected:
int 毛の色;

};

class 柴犬クラス: (*) 犬クラス
{

};

犬クラス pesu;
柴犬クラス mame;

前提条件の薄い例で申しわけない。「毛の色」はpesuやmameにおいてはprivateになります。でも柴犬クラスの中からは毛の色を指定したときがある。

で、とりあえず、protectedに指定します。
まだ、エラーが出るようならpublicにします。

これで完了ですが、変数がpublicの場合やpublicの関数がが多い場合は作りが悪い可能性がありますので全体を見直します。＜＝ここが実は重要です。

プログラミング：Ｃ＋＋のクラスをゴミ箱のように使う。

Ｃ＋＋のクラスをどう使うかということの初歩的なところで、ゴミ箱、あるいは整理箱として使うって方法があります。できあがったコード自体は初歩的ですが、このゴミ箱、整理箱として把握するところが進歩的です。
// どこぞのabc.cのなか static int abc_cnt; void abc_reset(void) { abc_cnt=0; } void abc_countup(void) { abc_cnt++; }

一様、呼び出し側もかいておくと
void 呼び出し側() { // カウントを０にする abc_reset(); for(;;){ if(abcという文字が出てきたら){ abc_countup(); } } }

個数を数える関数群つったらこんな感じになります。Ｃとしては間違ってません。 ここで、自分の場合　static int abc_cnt;のところが、床の上に唐突においてあるフォークのように感じてます。危険です。なので箱にしまいます。箱としてＣ＋＋のクラスを使います。実際、Ｃにはこの箱の機能が弱く。あるソース.Cの中のstatic指定という手しかありませんでした。

class ABC_CNT { int abc_cnt; public: void abc_reset(void) { abc_cnt=0; } void abc_countup(void) { anc_cnt++; } };

うまく箱の中にしまうことができました。これで床の上のフォークを踏んでしまう心配がなくなりました。
　：
　：
つづく

グローバル変数は禁止

また急にプログラミングの話になりますが、

Ｃ＋＋においては
グローバル変数は使用禁止
ファイルの地べたにおいてある static 変数も禁止

理由はつけるとしたら、変数はすべてＣ＋＋のクラス内の変数でまかなえるだろって話です。
このルールを守れば、ソースが綺麗になる方向に向かいます。

非常に舌足らずな論理ですが、そうです。

うさぎとかめ ループ判定法

プログラミングのアルゴリズムの話です。この方法は自分で思いついたわけでなく、どこぞの本で学んだ形。どこぞの本が何かは忘れてしまった。「うさぎとかめ」ネーミングは元々でなく、いわいが名前をつけなおしたと記憶。「鮮やかなアルゴリズムだ」との印象。

a1=func(a0);
a2=func(a1);
a3=func(a2);
a4=func(a3);
a5=func(a4);
・・・・・

と状態が分岐のない一連になってるものに使います。
あるfuncは引数が同じなら返り値は同じ値をとります。

１連といっても例えば
(1) anとa0が同じだと環状になります。
(2)途中のanとamと同じならば、全体のグラフの形は「６」みたいな形になります。

(1)(2)はループになってますのでそれを判定するアルゴリズムがあってそれが「うさぎとかめ」です。
かめは道の上を１区間づつ進みます。
うさぎは道の上を２区間づつ進みます。

 kame=usagi=スタート地点;
 for(;;){
   kame=func(kame);
   usagi=func(func(usagi)));
   if(kame==usagi){
     おっとこれだとループってる。
   }
 }

本当は証明が要るが・・・
簡単にいうと、ループじゃないと「うさぎとかめ」の差は開くばかりで「うさぎとかめ」が同じ場所にくることはない。
でも道がループになってると周回遅れのかめにうさぎが追いつくことになり、うさぎが「かめやっぱり遅いな」と同じ場所にいることになります。

説明がだいぶ、はしょってありますがわかりますでしょうか？後で絵でも足すか？

さらにプログラミングの本当の実際にあてはめてみる。状態の記憶をusagiとkameの２個分だけもっていればよい。a0はいったか、a1はいったか、a2はいったか・・・・・と全部、覚えておく必要がないので、メモリー的にすっきり。

フラッシュ自分開発の状況

まさかのパズル: フラッシュ初期状態・・・

フラッシュでなんか作ろうってことで、やってます。停滞気味ではありますが、「お絵かき１９」の出題・解答プロセスを作りたいと思ってます。とりあえず、ボタン押すと

状態１→状態２→状態３→状態１→状態２→状態３→・・・

となるようにまでは、ずいぶん前にたどりつきました。フラッシュの「一覧性の悪さ」ＯＲ「自分パタンができてないところ」がプログラマの私には苦しい。自分のパタンにまで持ち込めればＯＫなのだが。

ルールはここ　まさかのパズル: 問題：お絵かき１９ ルール説明兼ねて　そういえば、ちゃんと例題を用意してなかったか。あとで補充。

パンの耳 プログラミングの話

プログラムで「番人」ってのがある。
軽くみつけてきた　http://www.geocities.jp/m_hiroi/puzzle/puzdoc04.html

それと同じような発想で「パンの耳」と名前をつけた手法をよく使ってます。

図１
□□□□□□□□□□
□□王□□□□□□□
□□□□■■□□□□
□□□□□■□□□□
□□□□□□□□□□

こんな盤面をコマ(図で王）が動く。コマは将棋の王の動きをする。横のサイズが１０、縦のサイズが５で表されているとして、コマはその中を動く。■は穴で王はそこには移動できない。また王はフィールドの外へは行くことはできない。

図１を正直にプログラミングしようとすると、data[10][5]を用意。
普通のマスには０を設定 data[?][?]=０；
■のマスには１を設定 data[?][?]=１；

移動できるか移動できないかの判定を考えてみる。

判定(座標)　// 移動した後の座標を入れる。
{
　if(フィールドの外か？）{
return(いけない）；
}
if(その座標の盤面は■か）{
return(いけない）；
}

　return(いける）；
}

パンの耳をつけると王が一歩一歩進むとすると

図２
■■■■■■■■■■■■
■□□□□□□□□□□■
■□□王□□□□□□□■
■□□□□■■□□□□■
■□□□□□■□□□□■
■□□□□□□□□□□■
■■■■■■■■■■■■

判定(座標)　// 移動した後の座標を入れる。
{
if(その座標の盤面は■か）{
return(いけない）；
}
　return(いける）；
}

全然、説明しきれてない。あとで書き足そう。

グルグルか２値か

http://masaka.seesaa.net/article/2531773.html#comment　でtiaokさんにコメントをもらいました。

例え、1 5 1 5・・・と値が変化するときにも、もしそれが４づつ移動で８のサイズの枠でクリッピングされてるとするとやはり、

 hensu=1;
 for(;;){
  hensu=(hensu+4)%8;
  なんか処理
 }

の書き方がふさわしいです。tiaokさんのコメントの前半やいわいの元々の記事の路線。グルグル動いてるわけで。



1 5 1 5・・・「２個の値を行き来するんだぁ〜〜」としたら、

 static int table[2]={1,5};＜＝※
 unsigned int cnt=0;
 for(;;){
  cnt++;
  hensu=table[cnt%2];
  なんか処理
 }

こんな感じが、オススメです。行き来したい値を例えば -23, 116, -23, 116 ・・・・としたいときも※のところを書き換えればいいので。

どうですか？

modで足すのと引くのと

パズルの問題は増すのかい？: この数列にピンときたら．とそのコメントを見て書いてます。プログラミングに関してのことです。こんなことってあったなっというネタ。

ある変数があったとき、
int hensu;
変数の中身をこんな感じで変化させたい。
0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,・・・

hensu=0;
for(;;){
hensu=(hensu+1)%10;
なんか処理
}

こんな感じにするとお手軽です。if文を使った10以上になったら0に戻す。あるいは10以上になったら10を引くなんて方法もあります。その方法はここでは話の外としておくと。

例えば、3増えるような感じでみたいなのも
hensu=0;
for(;;){
hensu=(hensu+3)%10;
なんか処理
}
とやると出来ます。hensuの中身は0,3,6,9,2,5,8,1,4,7,0,3,6,9,2,5,8,1,4,7,・・・とうまくまわります。麻雀のスジのように。

9,8,7,6,5,4,3,2,1,0,9,8,7,6,5,4,3,2,1,0,9,8,7,6,5,4,3,2,1,0,・・・とやりたいときはどうするでしょうか？
hensu=9;
for(;;){
hensu=(hensu-1)%10;
なんか処理
}
なんか、これでできてるようですが、実際にはhensuは
9,8,7,6,5,4,3,2,1,0,-1,-2,-3,-4,-5,-6,-8,-9,0,-1,-2,-3,-4,-5,-6,-8,-9,・・・となります。これはC,C++の%（パーセント）の定義に由来しています。

正しく動くための一つの例は
hensu=9;
for(;;){
hensu=(hensu+10-1)%10;
なんか処理
}
とすることです。-1の代わりに10-1を足してあげます。

以上は随分個々な例ですが。

ここで、自分が教訓として思っているのは「引く」「マイナス」なことは「足す」「プラス」のことより問題が難しくなるから気をつけよってことです。同じことですが、いいかえてみます。あることをなし得るあるいはシステム構成を考えるときに全部プラス系な感じでいくようにしてみるってことです。

プログラミングに関してのことですが、プログラムでない他のことにも活躍する考えです。作業的なことシステマチックなことには相性いい考えです。

書いてて前半の個々のパーセントの話はともかく。後半は全然説明できてないような気がしてきました。

プログラミングの話 シンボル

急にプログラミングの話ですが、シンボルって大切って話です。

■関数名や変数名には機能や扱い方にふさわしいものをつけることが重要です。
■ごちゃごちゃしたソースもふさわしい関数名や変数名をつけていくことにより自然に整理されることがあります。
■なんだかそんなもんなんだけど、名前をどうしようかと考えたら、特徴のある名前をつけるのがいいです。
■同じものには、同じシンボル、違うものには違うシンボルをつけます。
■特に似てるんだけど違うものには気をつけて違う名前を使います。
■違う名前を使うってことはおのずと構造やとりあつかいも変わります。
■重要なものには重要っぽい名前をそうでないものはそれなりの名前をつけます。
■「決まり字」も重要。
■文字の字数を揃えるなんてのもかなり有効です。

なんだか箇条書きで。１個づつを説明するのはまた気が向いたらやろ。例がないとわかんねぇだろ、こんなもん。

岩井

フラッシュ初期状態・・・

フラッシュに初期状態をいれてみました。フラッシュはPerlより手強いです。フラッシュは超超超超超超上級者用です。Ｃ＋＋なんて赤子の手をひねるようなもんです。開発の歩みののろい事といったら、亀Ｘ０．０１くらいです。