チェス始めました

始めたというのは正確には違うのだが、ぼくの中では始めたが正しい。最初にチェスに興味を持ったのは20代のころなんだ。確か「ボビー・フィッシャーのチェス入門」を読んだ記憶がある。その本はもうどこを探してもない。

こんにちまでチェスは将棋の力（アマ四段）だけで指してきた。そして先日、チェスのことをボーッと考えていたら、あれっ、クイーンってどっち側だっけ．．ぼくのレベルはその程度だったのだ。

それで、いま、入門書（「ここから始めるチェス」という本）を買って読んでいる最中なのだ。この本はよい本なのだろうね。チェスへの興味が強くなったんだ。

読んで気づいたんだけど、ステイルメイトやアンパッサンなどもよく分からなかった。また、それらは読んで理解したつもりだったけど、つい最近買ったチェスソフトと対戦してステイルメイトを2度もやってしまった。圧倒的優勢であとは詰ますだけという状況でだ。「あーーーーー！」そのときのぼくの声だ。これはステイルメイトを理解したという声だ。

とりあえず今回は「チェス始めました」という宣言だけ。今後、ぼくのチェスが果たして進歩するのかどうか、ありのまま、少しずつ書いていこうと思う。

FX 成功の秘訣（2015年版）

FX 成功の秘訣。それは人生成功の秘訣でもある。

じゃ、そんなことを知っているまじんくんはよっぽどの成功者なのだろうね。うーん、そうだねー、ぼくは過去、単年度で1億5千万円の税金を払ったことがある。これを持って成功とするならば、成功者と言えなくもない。ちなみにいまのぼくは貧乏だ。

最初に言っておくが、実は個人の成功とか満足とかいうことは、その人本人が決めることで他者による客観的評価とは無関係なのだ。余り多くを求めずのんびり人生を味わいたいという人もいれば、死ぬ寸前まで、会社経営と利益追求に奔走する人もいる。

さて、もったいぶらずに結論から言おうじゃないか。それは「運・鈍・根・足」である。これは人生全体にも、もちろん FX にも有効な知恵なのだ。しかし、これを知識として得たからといって、実践して成功できるかどうかは別のことなのだ。

えっ、つまり、この記事を読んで理解しても無駄ってことか。まぁ、そういうことは置いておくとして、まずは「運・鈍・根・足」を説明しよう。

まずは「運」だ。何事にも「運」が必要で、わたしは「運」に頼らない、地道確実に努力して成功をつかむのだ、と言っても、「運」なくして確実に成功を収めることはできない。そんなの当たり前だよ。誰だって知っている。

そうだろうか、じゃ、まぁ、次に行こう。
次は「根」だ。次は「鈍」でしょ。分かりやすいものが先。

継続は力なりとか、何事にも根性が必要という、それのこと。そんなの、だけでも知っていることだよ。金返せ！いや、お金はもらってないだろ。まぁまぁ、まずは一通り説明させてほしい。

「鈍」は難しいだろうなぁ。「鈍」とは感じにくい、気づきにくいと言うことだ。えっ、それじゃダメだろ。「鈍」って何事にとってもダメじゃないのか。「鈍」とは何事をも疑い過ぎないということで勘違い野郎と言うことでもある。

「鈍」は成功のために最も必要な素質だと思う。ぼくにはこの才能がない。センシティブすぎるのだ。何事をも疑うし何者をも疑う。自分さえもね。

「鈍」が必要なのは FX も然り。FX で数億円の利益。その秘訣を伝授。などという書籍がよく出ている。FX で数億稼げるのなら、書籍の執筆などというセコイ仕事になぜ取り組んでいるのか。そりゃ、自分が儲かった方法を世間に教えてあげようという心からだろうよ。心優しい人なのだよ。

ぼくはそうは思わない。FX は優れたロジックを見つさえすれば、そしてそれを冷静に用いれば必ず大成功できるというものではない。しかし、ぼくは FX は「運・鈍・根」によって大成功できる可能性がけっこうあるものと思っている。

その際は「鈍」が特に重要。

自分が信じた方法を疑ってはならない。改良ばかりに気を取られてはいけない。ときに勘違いが大きな利益を生むのだ。ただし FX で大成功するには「運」が不可欠。「運」なんて関係ない。俺の方法は無敵なのだ！という人もいるだろう。

「鈍」な人は失敗のリスクに気づかない。その心意気が大成功には必須なのだ。

次に「足」について述べたい。

「足」とは、小欲知足。足るを知る。まるで FX 精神には真っ向から反するものに思える。FX ではリスクに目を背け「鈍」となって大成功の可能性にかけるのか、「鈍」ではあるもバカじゃないと、大成功ではなく小さな成功、あるいは極小成功を目指すのか。

ところで、FX には法則性がないという人がいる。ランダムウォークなのだと主張する。ぼくはそうは考えていない。しかし、法則を見つけさえすれば大成功！などとも思っていない。

ぼくのロボット開発は、小さな小さな有意性を見つけ出して、それを極小の塵を集めるのように集めようと考えている。これは人間は無理な仕事だ。FX には有意が存在する。しかし、その有意は極めて小さなもので、まともな人間はその極小の塵集めの仕事には耐えられない。だからロボットなのだ。

そして、これは「足」の精神でもある。もし、そんなロボットが完成したとしても、それは永遠のものではない。それを勘違いしている人が多いように思う。

ぼくは過去、あらゆるインジケーターを試した。そして、これなら絶対うまくいくと思えるインジケーターを見つけた。シンプルなものだ。しかし、実践をしていない。もし、それを続けていれば、つまり「鈍」を継続し、「運」に恵まれれば成功したかもしれない。

なぜ実践しなかったのか。楽しくなくなってしまったのだ。ぼくにはよくあることで実に無駄と言える。「鈍」と「根」が足らないよ。「欲」も足らない。

これ「年金ロボットをめざして」というタイトルのブログだけれど、それ以来、FX には取り組んでいないのだ。申し訳ない。

ぼくには楽しいかどうかが最も重要で、楽しくなければ、お金になろうとも我慢できないのだ。どうしようもないガキなのだ。いい歳してんだけどね。

率直に言って FX はぼくに向いていると思う。だけどもね、．．。

ロボット開発は、また気が向いて、楽しいと思えたら再開すると思う。

【追伸】

ブログへのコメントで、ぼくに ZigZag についての質問をしてくれた方がおられました。ソースを見て回答しようとも考えましたが、ソースも見つからなく（前のパソコンの外付けディスクのどれかのどこかにはあります）、また興味が向かなくて返事をしていません。申し訳ありません。

ブルゲ的脱衣将棋

市販の将棋ソフトといえば、激指が有名所だけど、それって娯楽用としてはどうなんだ。もちろん、激指は優れたソフトだとぼくも思っている。実際、ぼくは激指の バージョン 5、7、10 を持っている。

しかし、強いソフトがお望みなら GPS や Apery が無料で使えるよ。検討用のソフトがほしいのなら ShogiGUI が優れものだ。なお、ShogiGUI には GPS が標準で組み込まれている。

さて、娯楽用ならば、これはその人の棋力に依存する話だけど「ブルゲ的脱衣将棋」なんてどうだろう。棋力は 2級とどこかで見たけど、ぼくの見立てではもう少し弱い。

このソフトはエロゲーに分類されるらしいが、品が悪いとは感じない程度だよ。ぼくはこれをアマゾンで購入した。3,780円だった。Windows 8.1（64bit）のぼくのパソコンでは問題なく動いている。けっこう楽しめる将棋ソフトだったので、ここでみんなに紹介したい。

 上がブルゲ的脱衣将棋のスタート画面。下はフリー対局の画面。

対局では、画面上のキャラが話しかけてくる。吹き出しもあるし、駒音や BGM もある。これらは、設定によって細かくオン・オフできる。

 下はストーリーモードの画面。お話が終わったところでセーブできるので、これを毎回見る必要はない。

 ストーリーモードをクリアすると、対戦相手が増える。星の数が多いほど強いキャラなのだろうと思ったけど、それを確信できるほどの違いは感じなかった。

 その増える対戦相手の一人がこのワルーシー。口が悪い。

 動画を見ながらブルゲと一局。動画を見ながらなので、このときは音はすべてオフにしている。ちなみにこのとき見ていた動画は、Lolita という映画。なお、この映画はロリコン向けのエロ映画ではない。映画好きが見て楽しめる映画だと思う。

https://www.youtube.com/watch?v=GRIPOq77aHw

 説明はかなり端折ったけど、ぼくの感想は優良な将棋ソフトということだ。

ぼくはアマ四段だけど、このソフトで遊んでいるときはかなり楽しめたよ。このソフトに対しては、強すぎて勝てないというコメントもあったけど、目安としては 2～3級ということで、多くの将棋ファン層にとって適当に楽しめるお相手ではないだろうか。

そうそう、大事なことを言っていなかった。このソフトは瞬時指しだということ。待たされることはない。一手に30秒とか掛けられたら遊ぶ気にならないよね。

フリーの将棋ソフトでは、磯部将棋（棋力初段）が瞬時指しでお勧めだよ。

最後の最後に一つ。ぼくはこれをエロゲーととらえてはいないけど、18禁のエロゲー分類であることをお断りしておきたい。

ついたて将棋

いまぼくは｢ついたて将棋｣なるものにハマっている。

最初これを知ったときは、まぁ、将棋色物の一つであって、おふざけに過ぎず、一時的には楽しいのかもしれないが、真剣に取り組むようなものではないだろうと決めつけていたように思う。しかし、実際にやってみると、これが奥が深いことに気づいた。

【ついたて将棋オンライン】http://wars.fm/tsuitate?lang=ja

実際に試すのは簡単。「ついたて将棋オンライン」というサイトがあって、そこで無料で楽しむことができる。登録は自分で決める ID だけで、本名・住所はもちろんメールアドレスの登録も不要である。初めての人も思い立ったら今すぐ始めることができる。

ぼくは Windows のブラウザでプレイしているが、ブラウザ版は低機能とのこと。Android、iPhone、iPad 等のほうが快適との話だ。ぼくの初対局では、駒が敵陣に進めなくなって負けてしまった。第2局目は問題なかった。こういうこともあるが気にしない気にしな い。

最初に 30級が与えられる。いまぼくは 19級だ。全部で 42番戦った（17勝-20敗-5引き分け）。いっぱい負けているよ。ぼくの将棋の実力はアマ四段だけど、通常の将棋とは別のゲームだと考えた方が良いと 思う。負けてもまったく気にならない。だってぼくは、ついたて将棋の初心者なのだから。

さてさて、上の画像は対局スタート時の画面。相手の駒が見えないだけで、ルールは将棋とほぼ同じ。当たり前だが相手からもこっちの駒は見えない。持ち時間については、ついたて将棋オンラインでは 10分切れ負け。ちょうど良いと思う。

「9」という数字が表示されているが、反則をしたら数字が 1つ減る。これが「0」になりさらに「-1」になったら負け。で、反則とは、相手の駒の上に動こうとしたり、たとえば、先手で角道を開けて直ぐに2二角成りとすれば 3三に相手の歩がいるから反則。また、相手の駒の利き筋に玉が逃げようとしたら反則。これは普通に考えれば分かること。

あと、150手で決着が着かない場合は引き分けとなる。ぼくの引き分けの 5 は勝負が 150手以上になったときのもの。引き分けだと点数が減らないようなので？、「反則」と「引き分け」をうまく利用するというのもポイントだろうか。

以上の知識で問題なく対局できるはずだ。

上は、8級氏と戦ったときの終局図。成銀を玉で取ればまだ詰んでいないが、相手が 9回の反則のあと、もう一回反則をして -1 になったので、ぼくの勝利となった。10回の反則で負けとなる。

ある 2級氏と戦ったとき、相手の強さに、こりゃ、適わんとなった。つまり、勝つには技術が必要なのだ。また、運もある。そこが将棋とは異なる。

ある対局では、早々に飛車・角・金・銀を取られ、あー、こりゃ負けだと思ったが、逆転することができた。将棋ではあり得ないことだろう。

こんなに面白いゲームがいままで余り注目されることがなかったのが不思議に思える。将棋が弱くても「ついたて将棋」では直ぐに強豪になれる可能性もあると思う。

将棋のルールが分かる人は、ぜひ一度試してもらいたい。

どお的ウェブ

このところ、ウェブの比較的珍しくて新しい表現方法の研究に取り組んでいる。その方法論について最初にぼくの頭に浮かんだのは「動的ウェブ」という言葉だった。

しかし、動的ウェブという言葉は本来、クライアントからのリクエストでサーバーからデータが送られクライアントのページが更新される形態のウェブページのことを言うのであって、動的ウェブという言葉を使うと誤用だと叱られそうだ。

で、まぁ、その動的ウェブの意味を少し残しながら、こんなの、どお？的なテーストのウェブとして世に問おうじゃないかと。でも？付いてると、ちょっとごちゃごちゃしてるので、「どお的ウェブ」ってことにしておこうかな、ということなんだ。なんだよぉ、ふざけてんのか。いや、まぁ、まじめなんだけど。

世に問うなんて言うと画期的なアイデアに聞こえ、なんだか大げさだけど、まぁ、それほどのことじゃない。従来から他分野では目にする程度のものだけど、情報提供用のウェブページとして用いた人はいない（少ない？）かもしれない。

具体的に見せてくれよ！ そうだろうねぇ。しかし、まだ研究中で具体的に見せられるほどのものはないんだ。しかし、どんな考えのものかは説明したい。

① Visual
② Interactive
③ Personalized

本当はこれに Dynamic も加えたいけど、誤用と言われそうなのでやめておこう。で、結局、HTML5 なんだよね。なーんだ、じゃ、最初からそう言えよ。でもね、たとえば次のサイトはぼくがテスト的に jQuery を使って作ったもので、①の Visual とは言えるけど、②③とは言えないと思う。

【 Photo Zoom 】http://zoom.yagoo.org/

ところで、Flash 全盛のころ、ぼくは知人とよく議論したんだ。知人はウェブにおける Flash の利用がお好みのようだった。これに対しぼくは反対の意見だった。

Flash はウェブのインターフェースとしては消滅するだろう。そう断言していたんだ。アニメーション作品用には優秀なツールだし、それならばウェブで使うのも有用だと思うとも付け加えていた。

つまり、ウェブにおいては情報にアクセスしたいのであって、毎回毎回、アニメーションが見たいわけじゃない。そんなのウンザリするだろう、と主張した。

で、ぼくは、このウンザリ型とビジネスライクな従来型の狭間を目指してみようと思い始めたのだ。つまりこうだ。

『 ビジネスライク従来型 ＜ どう的型 ＜ ウンザリ型 』

もちろん Flash は用いない。繰り返すが、Flash はウェブ用アニメーション制作には有用だと思う。つまり、HTML5 を使った「どう的型」が「どう的ウェブ」ということなんだ。

HTML5 の発表時から、ぼくは HTML5 の機能には注目していた。ちょっと意外なポイントだろうが、とくにぼくは、クッキーを越えたストレージ機能に注目した。 まぁ、それが ③の Personalized に繋がるというわけなんだ。

しかし、ウェブというものは情報提供が第一義であり、一々 HTML5 を使ってどう的なアイデアに取り組むというのも面倒なので、主にはその上位ツールを用いるという方法を考えている。

また、どう的ウェブは従来型の補助として用いるべきと考えているんだ。
つまり、『 従来型ページ ＋ どう的ページ 』という使い方が良いだろうと言うことだ。

まっ、今回はこの辺で終わりにするが、「どう的ウェブ」に興味のある人はコメントをください。要望があれば、また、どう的ウェブの記事を書きたいと思います。では。

Python でシーザー暗号

ちょっとしたわけがあって Python でシーザー暗号のプログラムを書くことになった。

Python には codecs というモジュールが標準で用意されているので、それを使って楽をしようということに。

でも、誰かが完全に動作するプログラムを書いてるんじゃないかと期待してネットを検索してみたが、日本語が扱える完全なプログラムを見つけることはできなかった。

で、まぁ、ぼくが期待した役割をぼく自身が果たしたので、ここに書いておけば誰かの役に立つかもしれない。ということで、ここに書いておくことにした。

簡単な機能だから解説はしないよ。まずは、このソースをそのままコピペして、動かしてみるとよいと思う。あとは、Python のドキュメントと適当に他のサイトを参考にすれば、お役に立つことだと思う。

最初にこのプログラムの動作例を、それに続いてプログラムの完全なソースコードを掲載した。どなたかの役に立てば幸いです。

1:encode 2:decode 0:exit = 1

to encode (enter:goback) = 魔神の内緒話

encoding  =  6n2H56Jr44Th5LnS57rF6Xzk

1:encode 2:decode 0:exit = 2

to decode (enter:goback) = 6n2H56Jr44Th5LnS57rF6Xzk

decodeing =  魔神の内緒話

#----------------------------------------------------
import codecs
import base64

def cenc(s):
    encutf8=s.encode('utf-8')
    encb64=base64.b64encode(encutf8)
    decascii=encb64.decode("ascii")
    rot13=codecs.encode(decascii, "rot13")
    return rot13

def cdec(s):
    decrot13=codecs.decode(s, 'rot13')
    decb64=base64.b64decode(decrot13)
    decutf8=decb64.decode('utf-8')
    return decutf8

if __name__ == '__main__':
    while True:
        s=input('1:encode 2:decode 0:exit = ')
        if s=='0': break
        elif s=='1':
            print()
            s=input('to encode (enter:goback) = ')
            if s=='': print(); continue
            ss=cenc(s)
            print(); print('encoding  =  {}'.format(ss)); print()
        elif s=='2':
            print()
            while True:
                s=input('to decode (enter:goback) = ')
                if s=='': print(); break
                try:
                    ss=cdec(s)
                    print()
                    print('decodeing =  {}'.format(ss))
                    print()
                except:
                    print()
                    continue
        else: print()
#----------------------------------------------------

Java vs C#

興味深いテーマだが、機能比較をしてどちらが優れているなんていう主張をするつもりはない。それに C# の機能の詳細をぼくは理解していないのだ。えっ、それなのに Java vs C# なんて記事を書くつもり？ そうだね、Java と C# を肴にプログラミング言語というものの「ある種の本質部分」を考察してみたい。

この「ある種の本質部分」というのは、Python vs Ruby で考えてもそれほど違いはないだろう。

機能の細部を比較したり、処理種類ごとの速度を比較したり、それはそれでつまらないとはいわないが、それをもって、こっちのほうがいいのだと胸を張ってもらっても困るのである。将来ある若者を混乱させるのではないか。

さて、話はちょっと逸れるが、現在、表計算といえば即ち Excel といって問題ないだろうと思うが、その昔においては、Multiplan（マルチプラン。BillG が、モーティプランと発音していたのが懐かしい）というソフトが人気だった。その後、Lotus 1-2-3 という表計算ソフトに市場を制覇された。

Quattro Pro という表計算ソフトもあった。「Twice The Power Half The Price」が広告文句だった。実際、機能比較表を示して、ほらね、で、値段は半額さ！

ぼくはここで、Java vs C# を思い起こす。しかし、Quattro Pro は消え去ったのだ。

Lotus 1-2-3 や Quattro Pro はなぜ消え去ったのか、Excel はなぜ市場を制覇できたのか？ えっ、Windows を持っていたから？ まぁ、それは間接的には Yes だろう。Excel は新しい方法によってライバルを打ち負かした。

それは GUI。

Microsoft 社が Windows に勝負をかけることにしたことを一番早く一番よく知っていたからね。競合他社は、Excel の方法（GUI）に追いつくことができなかった。市場を握った Excel は、その後、ますます差を広げ、もう誰にも二度と追いつかれることはなかったのだ。

それはなぜか。この方法（GUI）はある程度十分複雑な内容を持っていたため、引き離した距離を維持できたのだと思う。

Java も同様、新しい方法（シンプルなオブジェクト指向、JVM、write once run anywhere）を打ち出した。その当初は、Microsoft 社もアタフタしていたよね。J# なんていう言語もあったね。

そして、先行し、Java は距離を確保できたようだ。そして今、Microsoft 社は、C# をもって Java を追いかけている。今、多くの人たちが Java と C# を比べ、C# のほうがよい機能を持っていると主張している。

そりゃそうだ。追いかけるほうが機能が低くてどうする。一度先行したプログラミング言語を追い抜くのは至難の業ではないか。 プログラミング言語というものは、文化的・習慣的側面が大きい。

機能を比較して勝るとしても、それが何なのだ！ということがあるよね。エスペラント語がいかに合理的であるといったところで、フランス語を置き換えることはできないだろう。

そういうわけで、何もわからないバカなぼくも Java を支持することになる。同じく、Python を支持している。Ruby のここが Python よりもいいんだよといわれても、じゃ、どうして世界中のみんなは Python を使うの？ C# のほうがよければ、なぜ、世界中の人たちはみんな Java をやめて C# にしないの？

ぼくは全く自然に Python を選んだし、Java を選んだ。

でも、Haskell を選んだのはなぜだろう。それは皆さんが Ruby を選んだり、C# を選んだりするのと同じかも。

それのどこが悪いっていうんだ！（笑）

Haskell の入り口の小さなこと

使うつもりのなかった Haskell を今年になってから使おうと思い始めた。

 そして Haskell の手始めに詰将棋の解図プログラムを書いてみようと思いついた。

しかし、その前にいつもやっている、メッセージを出して、入力を受け付け、計算を行い、出力す る、という、ぼくにとっての Hello World ともいえる処理を書いてみることにした。

日本国内にも Haskell を使っている人はたくさんいるはずと思うのだが、今回ぼくが書く、Haskell の入り口の小さなことを知っているのだろうか？

まずは、在り来たりだけど、こんなプログラムを書いてみた。

------------------------------------------------------------------------
import Data.Char

fib :: Int -> Integer
fib = (!!) $ fib 0 1 where fib a b = a : fib b (a + b)

fibds :: Int -> Int
fibds = length . map digitToInt . show . fib

main = do
    putStr "computing fib(N), input N (only enter to quit) : "
    n <- getLine
    if null n
        then return ()
        else do
            putStr $ "\nfib(" ++  n ++ ") = "
            putStrLn $ show $ fib $ read n
            putStr $ "digits length of fib(" ++  n ++ ") = "
            putStrLn $ (show $ fibds $ read n) ++ "\n"
            main
------------------------------------------------------------------------

そして、GHCi で動かしてみると、以下のように思った通りの結果だ。

------------------------------------------------------------------------
ghci> :main
computing fib(N), input N (only enter to quit) : 100

fib(100) = 354224848179261915075
digits length of fib(100) = 21
------------------------------------------------------------------------

うん、楽勝、楽勝と今度はコンパイルして動かしてみる。

------------------------------------------------------------------------
C:\hs>ghc fibds0.hs
[1 of 1] Compiling Main     ( fibds0.hs, fibds0.o )
Linking fibds0.exe ...

C:\hs>fibds0
100
computing fib(N), input N (only enter to quit) :
fib(100) = 354224848179261915075
digits length of fib(100) = 21
------------------------------------------------------------------------

あれっ、最初の putStr "computing fib(N), input N (only enter to quit) : " が表示されないで、入力待ちになっているぞ！ 仕方がないので、100 を入力。

そう、GHCi 上とコンパイル後のプログラムでは挙動が異なるのだ。

ぼくはまずコンパイラのスイッチを調べたが、そこじゃない。その後もあれこれ悩んだあげくやっとわかった！

GHCi のデフォルトは、行バッファリングがオフなのだ。それに対し、コンパイラが吐きだした実行プログラムでは、行バッファリングがオンになっている。

    putStrLn "message"
    s <- getLine

↑のように putStrLn にすれば問題はないが、ぼくはそれでは不満なのだ。Python でできることが Haskell にはできないというのか。

System.IO のなかに、hGetBuffering stdout（現在のバッファリングを知る）、hSetBuffering stdout NoBuffering（行バッファリングをオフにする）、hSetBuffering stdout LineBuffering（行バッファリングをオンにする）などを行うことができるモジュールが入っている。

------------------------------------------------------------------------
import System.IO
main = print =<< hGetBuffering stdout
------------------------------------------------------------------------

↑これを GHCi で実行してみると、以下のとおり、行バッファリングがオフであることがわかる。

------------------------------------------------------------------------
ghci> :load "letmeknow_linebuffering.hs"
[1 of 1] Compiling Main     ( letmeknow_linebuffering.hs, interpreted )
Ok, modules loaded: Main.
ghci> :main
NoBuffering
------------------------------------------------------------------------

今度は同じプログラムをコンパイルして実行してみよう。以下のとおり、行バッファリングがオンになっていることが確認できる。
------------------------------------------------------------------------
C:\hs>ghc letmeknow_linebuffering.hs
[1 of 1] Compiling Main     ( letmeknow_linebuffering.hs, letmeknow_linebuffering.o )
Linking letmeknow_linebuffering.exe ...

C:\hs>letmeknow_linebuffering
LineBuffering
------------------------------------------------------------------------

では、hSetBuffering stdout NoBuffering を使って行バッファリングをオフにすればよいのか。多分部分的にはうまくいきそうだが、これはやるべきではないように思う。

そこで、行バッファリングをフラッシュする hFlush stdout を使うことにした。これだと1行だけの問題として解決できるはずだ。

------------------------------------------------------------------------
import System.IO
import Data.Char

fib :: Int -> Integer
fib = (!!) $ fib 0 1 where fib a b = a : fib b (a + b)

fibds :: Int -> Int
fibds = length . map digitToInt . show . fib

main = do
    putStr "computing fib(N), input N (only enter to quit) : "
    hFlush stdout  -- ここに注目！（import System.IO が必要）
    n <- getLine
    if null n
        then return ()
        else do
            putStr $ "\nfib(" ++  n ++ ") = "
            putStrLn $ show $ fib $ read n
            putStr $ "digits length of fib(" ++  n ++ ") = "
            putStrLn $ (show $ fibds $ read n) ++ "\n"
            main
------------------------------------------------------------------------

やれやれ、やっと解決だね。

このような問題に関する記事を書籍やネットで見たことがないが、他のみんなは解決策を既に知っているということなのだろうか。

小さいように思えてぼくにとっては大きな問題だった。
いずれにせよ Haskell の入り口の小さなことでした。

Most Popular Coding Languages of 2015

世のなかには数多くのプログラミング言語に関するランキングが存在する。この Code Eval もそのひとつ。このランキングがどういう視点で捉えたものかは、Code Eval のサイトを見てもらいたい。

                        Source：【 Code Eval / http://blog.codeeval.com/ 】

これが当然に思えるか、意外に思えるかは、その人の立場や趣向あるいはなんらかの想いによることだろう。ぼくには比較的当然に思える結果だ。

Python と Ruby がクアドラプル・スコア以上の開きがあるところがひとつの見所だね。この関係は今後益々拡大することだろう。

あと、ぼくには F# の姿がないのは意外だった。C# 自体が 7.4% と捉えられているので仕方がないのか。Perl が 1.5% とか多少極端な気がするが、最新の動向であるとなれば、納得できなくもない。

もし、あなたが、計算機学科に進もうとしている若者ならば、まずは C を学ぶべきだと思う。選択の余地はない。もし、職業プログラマ1年生ならば、このデータを見せながら職場の先輩に相談するのがよいだろう。

そしてもし、プログラミングが職業ではないが、なんらかの目的のために言語を探しているならば、まずは Python でできないかを調べるべきだと思う。

人気のあるプログラミング言語というものはダテに多くの人々に指示されてはいないのだ。たとえば、Python には必ず解決策がある。数多くの優れたパッケージが存在するのだ。

しかし、皆と同じものなんか嫌だ！ という人もいるだろう。そんな人は、Ruby や Clojure に取り組んでみるのもよいと思う。

プログラミングの経験があまりなく、自分の能力に自信がある人は、Haskell に挑戦してみるのがよいかも知れない。Haskell はその昔は、情報も少なく、研究所で働く IQ の高い人たち専用の言語だったが、現在では普通にプログラミング言語のひとつと認識されるようになり、よい書籍もあるので、努力さえすれば誰でもあるレベルまでは理解可能な言語になったと思う。

ところで、もし、きみが中学生だったら、運がいい。現代は Python がある。現代に生まれた恩恵を得たいなら、Python を学ぶべきだと思うよ。

そういえば、Lisp や Scheme の姿もないね。個人的には優れたプログラミング言語と思うが、一般ウケはしないということか。もし、この世界に Python がなかったとしたら、学生諸君には、Scheme を勧めることだろう。

でも、Python があるからね。

Python って Scheme なの？

プロジェクト・オイラー問題 1 の解答が Scheme で書かれているのを眺めていたら、ふと、これって Python でもまったくおなじように書けるんじゃないか！？ と気がついた。

その前にまず、プロジェクト・オイラーとはなにか。以下のサイトを見てもらえばわかるだろう。プログラミングのお題。ぼくも取り組んでいるよ。

本家サイト       ： https://projecteuler.net/
日本語訳サイト： http://odz.sakura.ne.jp/projecteuler/

プロジェクト・オイラー問題 1。

『10未満の自然数のうち, 3 もしくは 5 の倍数になっているものは 3, 5, 6, 9 の4つがあり, これらの合計は 23 になる. 同じようにして, 1000 未満の 3 か 5 の倍数になっている数字の合計を求めよ.』

で、まずは Scheme だとどう解けるのか。

; in scheme
(display
    (reduce + 0
        (filter
            (lambda (x)
                (or (= (remainder x 3) 0) (= (remainder x 5) 0)))
                (iota 1000))))
(newline)

いかがだろう。
これを Python で書いてみると以下のようにる。

from functools import reduce
print(
    reduce(
        lambda a, b: a+b,
            filter(
                lambda x: x%3==0 or x%5==0,
                    range(1000))))
print()

Scheme と Python の 2つの構造はまったくおなじ。display → print、reduce → reduce、filter → filter、lambda → lambda、iota → range と対応している。最初の import が必要なのは Guido（Python の発明者）が reduce は醜いと functools のなかに追いやったためとどこかに書いてあったような。

初心者の人向けに少し説明しよう。まずは、Python の lambda に注目。lambda ってなにか？ Python では関数は def で作ってから使うが、lambda を使えば、使いたいその場で名前を定めることなく使うことができる。たとえば、def nantoka(x, y): return x*y+2y という関数は lambda x, y: x*y+2y などと書いて関数名は無名のまま使える。

さて、Pythonコードの下から説明してみよう。まずは、お馴染み range で、0 から 999 までの数列を作る。「filter(lambda x: x%3==0 or x%5==0,」によって 0 から 999 の数列にまさにフィルターを掛け、これで 3 または 5 で割り切れる数だけの数列になる。

つぎに「reduce(lambda a, b: a+b,」によってその数列の数すべてを足し併せる。そして結果を print 。Scheme とおなじだね。上の Python のコードはそのまま動いて正しい答えを出力してくれるが、もっと簡単に print(sum(x for x in range(1000) if x%3==0 or x%5==0)) こう書いてもおなじように動く。

ちなみに Ruby だとこんな感じ。

sum=0
1000.times do |i|
    if i%3==0 or i%5==0
        sum+=i
    end
end
puts sum

えっ、こっちがいい？ ならば Python だって。

sum=0
for i in range(1000):
    if i%3==0 or i%5==0:
        sum+=i
print(sum)

さらに、ぼくならいつもこう書くんだ。賛否はあると思うが、とくに単純な1行 if ならこう書いたほうが読みやすいと思う。

sum=0
for i in range(1000):
    if i%3==0 or i%5==0: sum+=i
print(sum)

こうやって見てみると、これが素朴で一番わかりやすい。

で、ことはついでに、プロジェクト・オイラー問題 2。

『フィボナッチ数列の項は前の2つの項の和である. 最初の2項を 1, 2 とすれば, 最初の10項は以下の通りである.
                    1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...
数列の項の値が400万以下の, 偶数値の項の総和を求めよ.』

ぼくの解答はこう。

折り曲がっているだろうけど、これ 1行。 で、ただしこれ、 機械伯爵さん（http://blog.livedoor.jp/kikwai/）から基本的なアイデアをいただいた。

ちょっと、裏技的過ぎて読みにくいかも知れない。

ハスケルハスケルるーるるる

Haskell は、果たしてぼくが第一言語として使うべき言語なのだろうかと天に問う。そのときの呪文が「ハスケルハスケルるーるるる」なのだ。きょうもトイレで唱えてしまった。

ぼくは昨年12月から、数論研究とぼくのもつ幾つかのアイデアを実現するためのプログラミング言語を決めようとしていた。J、Python、Scheme、Haskell 、Pure（1月になり加わった）の5つがその候補だ。

J は使い続けている好きなツールだけどアプリケーション開発には向かないので除外した。また、長年に渡りずっと関心を持つ続けてきた Scheme なんだけど、どういうわけだか使いたいと思わなくなってしまったのだ。一時的な病かも。

で、現在は、Python、Haskell、Pure の3つが最終候補となっている。

プログラミング言語としてなにを選ぶかということは、その目的と使う者の事情（職業プログラマならプロジェクトの事情）によって決まるものだと思う。ぼくの場合は科学者のニーズと似ているだろう。

また、OS やミドルウェアを開発するわけではないので、C、C++、D、Go、Rust  などは本当の必要が生じない限り手を出す気はない。そう、気づきましたか。ぼくにとっては動的言語が好ましいのだ。

だったら Haskell ってその点どうなの？ うん、だから後から Pure が顔を出したんだ。

ズボラなぼくには動的言語が好ましい。だって、やりたいことの本質とは関係ないことに煩わされたくないよ。Haskell は、カタ（型）カタ、カタカタうるさすぎる。でも、そのカタカタは長所でもあるけどね。

さてさて、この頃では、関数型言語が脚光を浴びており、職業プログラマの人たちもなにを学ぶべきかと悩んだりすると聞くが、.NET の人なら F#、Java の人なら Scala で決まりだろう。悩む必要なんてないと思うよ。

職業プログラマは道楽100％とはいかないから、趣味（向上心）と実用（仕事）を考え、F# か Scala が好ましいと思う。実際、この2つの人気が上昇中だ。当然だと思う。

間違っても Pure などやろうと思わないほうがいいよ。だってまだ信用できないよ。バージョンは 0.64 だし、実際たまに落ちる。

ところで、1月になって、ある仲間から Project Euler（https://projecteuler.net/）を教えられた。（和訳サイト：http://odz.sakura.ne.jp/projecteuler/）

最初の数問をやってみたら、驚くことに、自然にぼくは関数プログラミングで解こうとしていた。どうしてもループを書く気にならない。

それでまた呪文の声が高くなった。
「ハスケルハスケルるーるるる」。こんどは、風呂場に響き渡る。

けっきょく、過去一度は切り捨てた Haskell がぼくのなかで復活しようとしている。

① 第一言語： Haskell（Pure）
② 第二言語： Python

かな．．。Python は必要？ うん、けっきょく最後は Python が助けてくれる。
ぼくにとって Python とはそういう存在。

(factorial 300000)

ぜんかいの「Scheme スピードテスト」の続きの話ではあるが、こんかいはぜんかい以上にいい加減なテストなんだ。こんかいは時間さえも計っちゃいない。目覚まし時計はお休みちゃん。

とにかく時間がかかってもいいから、計かんないから、やってみろい！ しかし、ちょっときついぞ (factorial 300000) だ！ どういうわけだか、また 30万なのだ。

まずは最初に訃報だ。ぜんかい優勝の Ypsilon が (factorial 300000) の暴力に吹っ飛んだ。

10万までは高速順調であったが、さすがに 30万となると Ypsilon の想定外なのか黙って落ちた。

そのほかの Scheme メンバーもダウンに次ぐダウン。多倍長ハンターの Lisp 族としての誇りはどうなったのだ。

(define (factorial n) (if (zero? n) 1 (* n (factorial (- n 1)))))
(factorial 300000)

で、プログラムはこんな感じね。

まずは見てくれ。ぼくが信頼し愛用する GP はちゃんとやり終えてくれたぞ。数字はちょっとしか見えていないが実際はすごい量なのだ。30万どころか 300万をやらせてみたがこの通りだ。

いっぽう、こりゃなんじゃ。

こんなの Scheme といえるのか。Infinity って．．。あっ、すまない。前回のデータだった。ほんと、いま気づいた。でも、Factorial をやったところで Infinity に決まってるさ。まぁ、いろんな処理系があっていいんだけど、Lisp 族は Fortran が簡単にはできないことができてほしい。

で、肝腎の Scheme は？

みんなが信頼する Gauche はさすがなもので時間はたっぷり掛かったが最後までやってくれた。また、Schluessl は前回どうようの高スピードでこんかいもぼくの期待に応えてくれたのだ。ありがとう。

MIT/GNU-Schme からは、Aborting!: maximum resursion depth exceeded のメッセージをもらった。外国勢も黙ってサラッとやり終えてくれるものはなかなかなかった。そんななか、SISC は Gauche よりも Schluessl よりも速く黙ってやり終えてくれる数少ないひとつだった。

こんかいの結論は、なんとなくこんな感じか。じつは、お気づきのとおり、ぜんかいも Ypsilon よりも SISC のほうが上だった。ただ、あとになってのエントリーだったので、表彰台に登ることはなかったということなのだ。

さて、最後に (factorial 300000) という数字がどれほどのものか伝えておきたいと思う。

この数字がどれほど続くのか。うーん、GAP の力を借りることにしよう。

1512852 桁。151万桁の数字というわけだ。

あっ、これでもわからない？ もし、ここにその数字全部を貼り付けたら、記事10回分くらいが数字で溢れかえってしまうだろう。そういう数字を計算して吐き出すことができる言語。それこそが Lisp（Scheme）ではないだろうか。

【追伸】
とはいたってわかっちゃいるよ。

Gauche は Linux において（Windowsのほうはあまり見ちゃいないだろう）、あらゆる使用に耐え、あらゆる場面で高パフォーマンスを出せるようなバランスを取った設計になっているのだろう。Fortran 的に使ったってそこそこいくぜってことだね。

これは想像だけど、Gauche は事務処理、数値計算、記号処理の総合においては最強なのかも知れないよね（ぼく的には根拠はないけど）。

でもね、Fortran の土俵では Fortran にはまったく敵わないだろう。また Fortran だって 30万の階乗の計算だってそりゃもちろんできるだろう。そして、やればどの Scheme にだってスピードじゃ負けないはずだ。

だけど怠け者のぼくはそんな大変なことをやろうとは思わないさ。

言語哲学的にいえば、Scheme はまずは Sceme の得意分野で最高を目指すべきじゃないだろうか。ぼくはけっきょくそれがいいたくて、2回にわたって Gauche の名前がでる記事を書いたのかも知れない。

Scheme スピードテスト

きょうはちょっとした思いつきで Scheme のスピードテストをやってみた。

内容は 123^300000（30万乗）の計算をさせるという単純なもの。テストしたのは7つの Scheme で答を出力できたのは3つだけだった。設定を変えればよいのかもしれないが面倒なので正常に終了したものだけを挙げると以下のとおり。

① Ypsilon（イプシロン）                 52秒
② Schluessl（シュリュッセル）   1分40秒
③ Gauche（ゴーシュ）               5分23秒

 なお、計測中は DVDで映画を観ていた。実行中は静止させていたよ。

でも、そういういい加減な環境で、目覚まし時計の秒針で計ったということだけど、どれもおなじ条件だからね。

それでこの結果。ちなみのぼくの PC は Windows7 64bit版 メモリ 12GB だ。

ついでにそのほかの言語もやってみた。
結果は以下のとおり。

① SWI-Prolog                                  1秒 強（2秒掛かっていないが計れなかった）
② Haskell                                        6秒
③ Python 3.4.2                                9秒
④ PyPy 2.4.0                                  20秒
⑤ Frink                                          52秒
⑥ J                                             2分3秒

まぁ、これは、ディスプレイに数字を打ち終わった時点までの時間で本質的でない部分が含まれていると思う。それにしても工夫なしで計算してくれて出力し終わってくれる、これがすごくないかい。すごいと思うし、ありがとうって感じ。

なお、GAP でも試した。表示は瞬時だったが、

gap> 123^300000;
<integer 341...001 (626972 digits)>

こんな感じの表示だったので、こんかいは対象外とした。でも、たしかに計算は終わっているようだよね。このドイツ製の GAP に注目か！？

なお、Factor でも試そうと思ったが落ちるのが目に見えているのでやらなかった。Factor はじつに魅力的な言語だけど、現時点では、大きな計算負荷を掛けると落ちてしまう。【追伸】とはいえあになって気になったので試したが、123^300000（30万乗）どころか 123^3000 でダウン。

Factor はぼくが大好きになりつつある言語なので、こんごの改善を期待したい。

さて、スピードテストといってもこんかいのような単純な計算ひとつだけのテストで順位を付けられては言語の開発側もたまったもんじゃないだろう。もっと総合的に評価しなければならないことは承知している。だから、あくまでもこの計算ではこうだったというひとつの参考程度に考えてほしい。

Ypsilon のサイト（http://www.littlewingpinball.net/mediawiki-ja/index.php/Ypsilon）には、以下のように書かれている。

『Ypsilon Scheme System（イプシロン・スキーム・システム）はプログラミング言語Schemeの最新規格R6RS*に準拠する実装です。インタープリタの特性を活かしてスピーディーでインタラクティブなアプリケーション／ユーザーライブラリーの開発を可能にします。またマルチコアCPU用に最適化した Mostly Concurrent Garbage Collection を実装することにより、極めて短いGC停止時間と並列実行によるパフォーマンスの向上を達成しています。』

Ypsilon にはその他、Factrial や 素数関係の計算もさせてみたが、いずれも高速だったよ。

【追伸】
この記事の投稿のあと、CLISP と MIT/GNU-Schme、SISC、Kawa でもテストをおこなった。CLISP はスタック不足で停止。スタックを増やそうとはしなかった。MIT/GNU-Scheme は 44秒、SISC は 45秒、Kawa は 1分40秒とともに高速だった（ただし、テスト中に DVD ソフトは起動していなかった）。

あたらしい7つの言語

言語好きの人なら「7つの言語 7つの世界」（原題：Seven Languages in Seven Weeks）を読んだことだろう。ここで出てきた7つの言語とは、Ruby、Io、Prolog、Scala、Erlang、Clojure、Haskell の7つで、Io 以外はどれもすでに有名な言語だった。Io はこの本によって認知度が上がったように思う。
つぎに出た本がこれ「Seven More Languages in Seven Weeks」。第2弾ってことだろう。まずは、ここで取りあげられている言語に注目だね。それはズバリこの7つだ。

Lua              http://www.lua.org/
Factor          http://factorcode.org/
Elixir            http://elixir-lang.org/
Elm              http://elm-lang.org/
Julia             http://julialang.org/
MiniKanren   http://minikanren.org/
Idris             http://www.idris-lang.org/

知ってる言語はあるかな。見慣れない言語が多そうだね。

Lua はお馴染みだろう。軽量の LL だ。シンプルな言語仕様とデータ構造で、ぼくの好みの言語だね。おっと、巨乳のジュリア（Julia）が居るじゃないか。Julia は数学のほうを向いた、オブジェクト指向で、関数型で、並列プログラミングを指向した豊満な言語だ。それが巨乳の所以でもある。

いや、ホント言うとね、Julia を Googleで検索したら「巨乳動画サイト」が出てきたのがその所以なんだ。検索するなら「Julia言語」でね。

さて、Factor というのは、スタック指向言語として有名な Forth を現代化したような言語のようだ。まだ詳細はわからない。

Elixir、Elm、Idris  はどれも関数型言語のようだ。いまどきを反映しているようだね。Elm はおもしろいよ。ウェブページでマリオを動かすデモをやってる。

ゲームだけではなく、Elm のプログラムでウェブページを作るということを考えているようなのだ。ぼくとしても興味深いところだ。

えっ、まだ残ってる MiniKanren ってなんだって。うーん、コンパクトな論理プログラミング言語といったところか。ぼく的には興味深くはあるがまだよくわかってはいないんだ。

こんかいの新たな7つの言語のうち、Julia と Factor には、とうぶんのあいだ取り組んでみようと思っている。Factor は、数論アルゴリズムの研究に使えないかとの期待からだ。

10 sq 5 - .

簡単なこれ説明してみようか。まず最初の 10 を箱に入れる。つぎにまた箱に上から sq（2乗する関数）を乗せる。すると箱のなかの 10 が2乗されて箱のなかの 10 と sq は 100 に変化する。つぎに箱のなかの 100 の上に 5 を乗せる。さらにその上に - を乗せると、100 と 5 と - が 95 に変わり、箱のなかには 95 だけが残る。つぎに箱のなかに . を入れて乗せると、箱のなかの 95 が取り出され出力エリアに表示される。このとき箱のなかは空っぽ。

さてさて、Julia はすでに前回登場したね。詳しくなったらまた記事を書きたいと思う。Factor についてもね。

じゃ。

パイパイと巨乳のジュリア

もし、きみがだね、マニアックな人間じゃないとして、生涯使えるプログラミング言語をひとつだけ教えてほしいというならば、ぼくは Python を勧めるだろう。

ところで、ぼくはあるプログラミング入門者に十進BASICを勧めたのだ。文系の人でプログラミング経験ゼロだと推測してのことだったが、ポケコンのプログラミング経験者だったことをあとになってわかった。

その彼はあれよあれよという間に十進BASIC（Full BASIC）に馴れていった。そして彼にはあるニーズが生まれた。それは、多倍長演算ができるコンパイラ言語だ。つまりスピードがほしい。それでまずぼくは Full BASIC と親和性のある FreeBasic を調べた。うん、できるできる。GMP が使えるじゃないか。

しかしなぁ、これじゃ C言語やってるのと同じじゃないか。だったら C のほうがいいよ。まさか彼もこんなプログラミングはしたくないだろう。

（↑ 説明略だがいろいろすごいぞ巨乳のジュリア ↑）

またところでだけど、ぼくはつい先日、Julia というプログラミング言語を見つけた。うん、こいつはまだ日本のみんなは知らないんじゃないかと、ぐるぐる in Japanese（Googleで日本語サイトを検索 ← 最初からそう言えよ）してみると、出てきたのは、アダルトビデオ、AV女優、巨乳動画などのサイト。

あっ、そっかと、Julia言語で再検索。そうしたら出てくる出てくる。ぼくは遅れたやつだったのだ。で、まぁ、気にせず、ぼくは Julia のドキュメント（英文）を読んだ。

そしたら、まぁ、欲張りな言語だこと。

小さな処理系を好むぼくには、このジュリアは巨乳過ぎるぞ。しかしそれでも数学のお供にジュリアの巨乳を弄くり回してやろうじゃないか。と、欲求不満気味のぼくは決めたのだった。

 で、話は戻って、彼のニーズにはどう応えたらいいだろう。

ぼくは Lua を思いついた。Lua は速いと聞いていたぞ。ぼくは Lua に素数を吐き出させてみた。その結果は、上限数100万までの素数全出力が、8秒。上限数1千万だと、1分33秒だった。十分速いじゃないか。

Lua は難しいことさえしなければ、非常にシンプルで美しい。Full BASIC からの移行も抵抗がないだろう。しかし、コンパイラと比べると見劣りがする。LuaJIT でもその不満は解消できないようだ。

なにかないか。で、ぼくは PyPy という高速版 Python を見つけた。ぼくは遅れたやつなのだ。ぜんぜん知らなかったよ。早速ダウンロードして試した。

http://pypy.org/ こんかいは Python 2.7 互換の PyPy 2.4.0 を選んだが、Python 3.2.5 互換の PyPy もあるので、好きなほうを選べばよい。

で、Lua とおなじように PyPy でも素数を吐き出させてみたよ。つぎのような結果だった。

上限数100万までの素数全部     →     2秒
上限数1000万までの素数全部   →    19秒
上限数1億までの素数全部         → 3分8秒

速いね。ぼくは満足したよ。ぼくはこんかいはじめて、パイパイを弄ったのだけど、気持ちよかったというか気分がよかった。下ネタはやめて。

で、Julia にも吐き出させてみた。PyPy には及ばなかったがこの速さはそうとうなものだね。

上限数100万までの素数全部     →       4秒
上限数1000万までの素数全部   →      32秒
上限数1億までの素数全部         → 4分24秒

さて、ぼくは彼に巨乳（Julia）を勧めてみたいとも思ったが、まだなんだかよくわからないものを勧めるわけにもいかず、そもそも彼は、やれ Ruby だ、やれパイパイだ巨乳だとあれこれ弄くるような不真面目な男ではないのである。

うん、そうだ。PyPy を勧めよう。Python ならば一生涯使える言語だからね。まじめな彼にはもってこいだと思う。

これも一種のコンパイラだしね。JIT（実行時コンパイラ）だけど。

【おまけ】
「Python 3.3.2 で 3347670493571081 を素因数分解」

「PyPy 2.4.0 で 3347670493571081 を素因数分解」

こんなにちがうんだね。

うちの巨乳の Julia は、0.234438088 秒だったので素因数分解は PyPy よりも速かったね（黒い画面の画像に注目）。っていいたいけど、それは実装の問題だね。Julia のほうは組み込み関数だから。