Deep Learning
Deep Mind 社(Google)が開発した AlphaGo がトップクラスの囲碁棋士(韓国)に4勝1敗で勝利したことは記憶に新しい。この AphaGo は囲碁の定石などのロジックを組み込んだものではなく、Deep Learing という汎用のメカニズムを利用しているとのことだ。
上の画像は Deep Learning によってブロック崩しをやらせた例で、最初に得点を増やすという目的のみを与える。すると最初はボールを弾くことさえできず放置状態。それが偶然にボールを弾き得点が得られると、弾くことを覚える。
そして4時間後には、崩した一角からボールを裏側に回し、高得点を得るテクニックまでを覚えた。これはゲームとのインターフェースを別にするとそのメカニズムは汎用的なものだ。
AlphaGo では過去行われた15万局の棋譜を画像として与えたそうだ。そして勝つときのパターンを学習させた。つぎにある程度強くなった段階からは、AlphaGo 同士を対局させて勝つ方法を学ばせたのである。その数たるや驚きの 3000万局とのことだ。
Deep Learning 自体、とても興味深い話題だが、さて、ここからが本題。
Deep Learning 能力を持った FX の AI トレーダーに過去の大量データから勝ちパターンを学ばせ最強のトレーダーに育ててからトレーディングをさせたらどうなるだろう。まぁ、これは誰もが考えつくことだ。
今後、多くの AI(プログラム)の FX 市場への参入によって相場の状況が変わったとしても Deep Learning はそれにどう対処すべきかを学んでいくだろう。その場合、多くの FX ロボット(MQL 4/5 プログラムなど)はプログラム自体の変更を余儀なくされるはずだ。
まぁ、ぼくが言いたいことは、われわれの幾分古くさい FXロボット開発においても、固定的なロジックばかりではなく、最新の相場データを(リアルタイムでなくとも)常に分析させる方法論が必要になるのだろうということだ。
Deep Learning という汎用のメカニズムは Google が持ってる。さりとて我々だって、対象を FX に限定すれば似たようなアプローチは可能ではないだろうか。
チェス用語のカタカナ表記の件
ルックってなんだよぉ。
昨年の11月にチェスの勉強を始めてから、あれこれチェス本(チェスの教本や問題集のこと)を読んでいる。すると Rook のことを「ルック」と表記する本があった。あれっ、Rook は「ルーク」じゃなかったのか。ぼくはそれがとても気になった。
もちろんルックと書く趣旨はわからなくはない。発音がルックのほうがましと考えたのだろう。でもそれなら Queen をなぜ「クイン」としないのか。「クイーン」だよね。発音としてはクインのほうがかなりましだと思うけどね。でもクイーンは日本語だからクインなんて勝手に変えちゃいけないよね。
これはぼくの場合だが、たとえば Bxc4 という棋譜を読む場合、Bishop takes c four と読んでいる。できる限り英語の発音に近い音にしているつもりだ。ビショップ・テイク・シー・ヨン(フォーでもフォアでもなく四)と日本語として読むことにしている人もいるそうだ。ただ、これは用語問題とは無関係なこと。好みでよいと思う。
えっと、ところで、ぼくは日本語のチェス本をほとんどすべて持っている(えっ、誰がバカだって・笑)。そのほとんどがルークでルックは少数派なのだ。ぼくは、ルークは Rook を示す日本語(カタカナ語)だと思っている。どうして急にルックが出てくるのだろう。英語かぶれなのか?外人と話すのなら【rˈʊk】と発音すればよい。カタカナならルックよりもゥロークのほうが近いだろう。じゃ、ロークか。
つまり日本語「ルーク」をそう簡単に壊さないでほしいと言いたいのだ。チェスがいくら日本でマイナーであるとしても、むしろそれだからこそ、チェス用語の日本語化が大切だと思うし、固定化・安定化が求められるところだ。ルックと書く著者はチェスは所詮英語の世界だと考えているのだろうか。
ところで、マルチプランという表計算ソフトウェアを知っているだろうか。これは日本語として固定されており、誰もがマルチプランと書く。だけど、米国人に口頭で伝えたければ「モーティプラン」(無理にカタカナで書けば)と言うだろう。書くなら、Multiplan だ。
チェスの日本国内での普及を考えるのなら、少なくとも初級・中級くらいまでは日本語だけでチェスが完結する世界が必要であり、重要だと思うのだ。
もうルックとなんて書かないでぇ。英語かぶれ屋さんのイケずぅ。
盤上のポラリス
じつに久しぶりにコミック本を買った。「盤上のポラリス」というチェスを題材にしたコミックだ。これを読んでいてふと思ったことがある。
日本でチェスをやる人って..どんな人なんだって。
なぜ、将棋じゃないんだ。日本はチェス弱小国。そりゃ、なんてたって将棋があるからね。
日本におけるチェスとは日本におけるキリスト教のような立ち位置じゃないだろうか。
日本におけるキリスト教徒の割合は僅か1.5%程度と聞く。戦争に負けた日本がよくもキリスト教に浸食されなかったものだと思う。
そこから、こんごも将棋がチェスに侵食されることはないだろうというアナロジーが浮かぶ。
ところで、日本国内でチェスに取り組む日本人に、ぼくはなにやら嫌らしいものを感じていたのだ。偏見だと非難されようが仕方がない。
頭脳ゲームに興味を持つような人ならチェスよりも将棋を先に知るはずだし、チェスに目を向けるような人なら、その前に将棋を知っていたはずだ。
なにが言いたいのだね、まじんくん。チェスを嫌っているのか? いやね、じつはぼくは今年の11月からチェスを学び始めたのだ。チェスは嫌いじゃないよ。むしろね、大好きになりそうなのだ。
今回の記事では、将棋をパスしてチェスに取り組むひとたちの人間像をあれこれ書きたく思っていたのだけど、やはりそれはやめておこう。趣味が悪そうだ。
さて、日本はチェス弱小国だけど、そんな日本国内でチェスのトップクラスになりたければ、英語によるチェス本を読む必要があると思う。
近年は、日本語によるチェス本も充実してきているようではあるが、英語本にはまる一冊キングズギャンビット(チェスの定跡の一つ。将棋でいえばまる一冊「横歩取り」だろうか)という分厚い本(全680ページ)もある。
向こうのやつらはこんなの読んでるんだぜ。
ちなみに、近年はキングズギャンビットはあまり指されないそうだ。ギャンビット(ポーンを捨てる手)なら現代はクイーンズギャンビットなのだそうな。
というわけで、日本国内の初期の強豪には英語屋が多いようだが、それも頷けるというものだ。
そう、話は盤上のポラリスだった。
主人公の少年(小学5年生)は自発的にチェスに興味を持ち、チェス教室に通う。あり得ねぇー、無理があるぅー。いや、別に非難しているわけじゃない。
欧米においてはごく当たり前にあることかもしれない。というか、極々自然に父親が教えるだろう。そして父親に勝ちたくて強くなる。
話は戻ってポラリス。1巻目にして主人公の少年は、グランドマスター(世界クラスの強豪)になると宣言する。..が、そりゃ、無理だよ。日本にはよい指導者もいなければ、子供向けのよい本もない。それにライバルもいないはずだ。
まぁ、そう言っちゃおしまいだし、夢がない。
コミック「盤上のポラリス」には夢がある。ぼくは今後出る巻まで含め全巻読むつもりだよ。(現在は3巻まで発行済み)
このコミックを見た若い人が、よーし、おれもグランドマスターになるぞーとなれば、外野としても楽しいね。ぼくも若ければね..。じゃ、若いころに逆戻りできたら、チェスのグランドマスターに挑戦するかい? あっ、ごめん、そのころにはもっと楽しいことやってたよ(笑)。
というわけで、楽しいことも終わったぼくは、いまからマスター(FM)に挑戦しようか。
あり得ねぇー。
オセロ始めました
チェスに続いてオセロを始めた。
この歳まで、オセロを真面目にやろうと思ったことは一度もなかった。オセロなんて底が浅い、大人が真剣にやるようなもんじゃないと思っていた。オセロ九段がいると聞いて吹き出してしまったぼくだ。オセロが趣味の人から見たら敵以外の何者でもないようなぼくなのだ。
それがふとオセロをやってみようと思った。
http://wars.fm/reversi?lang=ja
↑こいつのせいだ。
で、ぼくはこれに参戦したい。ぼくはまずは入門書を読み始めた。現在、まだ 1/3 ほどしか読み進んでいない。よくそれでこんな記事を書く気になったもんだね。うー、それだけじゃないのだ。
オセロのソフトを購入して対局を始めたのだ。そのソフトは、OthelloⅢといいアマゾンで税込1,291円で買えるんだ。上の画像は、OthelloⅢのレベル10に勝ったときのものだ。ちぇ、自慢かよ。悪いね。でもね、言いたくはないけど、レベル10にはたぶん誰だって勝てると思うよ。
現在、レベル10とまで対戦したのだ。入門書を読む前の挑戦だった。ようするに、OthelloⅢは完全な素人にも勝たせてくれる思い遣りのあるソフトなのだ。決してぼくが強いなどという自慢ではないぞ。レベル11以降は、入門書を読んでからやろうと思っている。計画的なぼくなのだ。
OthelloⅢによってぼくはオセロソフトに興味を持った。で、世界でもトップクラスと言われる2つのソフトを戦わせてみたのだ。Thell3 vs WZebra の一戦だ。
Thell3 : http://sealsoft.jp/thell/ (セル)
WZebra : http://radagast.se/othello/ (ゼブラ)
結果は、石が同数で引き分けとなった。
ゼブラは外国製のソフトだが、メニューには日本語が表示できる。これは、オセロが日本で発明されたものであり、歴代の世界チャンピオンも日本人が圧倒的で、ソフトの開発者も日本を尊重すると言うことなのだろうとぼくは思った。
セルとゼブラ、どちらのソフトも素晴らしい。これからぼくのオセロ研究の心強いパートナーとなってくれることだろう。オセロに関心のある人なら、ぜひダウンロードして使ってみるとよいと思う。
【 勝てたよ 】
ゼブラは便利な機能も多く、ぼくのお気に入りとなった。ゼブラは対局用と言うよりは研究用と考えているが、とりあえず、ゼブラの一番弱いの(一手読み)には勝つことができた。(黒 38 対 白 26)
【 世界最強?】
もう一つ世界最強と言われるオセロソフトがあるそうな。上の画像のソフトがそれだ。NTest という。もちろんダウンロードしようとしたが、作者のサイトが無効となってしまっている。残念。
その後、世界のサイトを彷徨って、NTest を見つけたのだ。ただ、まだ動かしていない。ファイルの素性に信頼が置けないからだ。だから、ここでも紹介はしない。
NTest は、IBMの研究員によって開発されたソフトらしい。もし、動かして安全性に問題がなく評判通りの強さであったなら、改めてこのブログで紹介するかもしれない。
とにかく、ぼく自身、早くちょっとは強くなりたいな。
チェス始めました
始めたというのは正確には違うのだが、ぼくの中では始めたが正しい。最初にチェスに興味を持ったのは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 とはそういう存在。