  |
はてなキーワード: 整数とは
あー…。つまり、六角形がゆとりにとっての円だとしたいのね。そうすると、六角形が円として定義出来るような円の定義を与えればいいのだと思う。で、考えてみた。
ノルム||が定義された空間Sで、あるc∈Sに対してある正の実数rがあり、図形{x | |x-c|=r}を、「空間S中の半径rの円」と定義する。
で、R^2上の六角格子がうまく座標表示できているか全く自信がないんだが、複素平面上の点の集合で定義すると、{k/2*(cos nπ/3 + i sin nπ/3) | k,n∈N}∪{k√3/2*(cos (nπ/3 + π/6) + i sin (nπ/3 + π/6)) | k,n∈Z}になった。Zは整数の集合。
http://anond.hatelabo.jp/20101118060341
みなさん分かってると思いますが上のは嘘ですよ。
これは豆知識の部類ですが、割り算の記号は国によってばらばらです。「÷」「／」「：」がほとんどだと思います。
ピーターフランクルが「：」を使ってたので、東欧のほうではこれなんでしょう。
左から割る記号に「＼」を使うのは数学で一度だけ出会ったことがあります。群論で剰余類で類別するところです。
参考: http://www.econ.hit-u.ac.jp/~yamada/algebra_pdf/2_2_subgroup.pdf 2ページ目の記号のところにありますね。
普通はこの意味で「＼」を使うことはありません。差集合の意味で使うのが普通です。
参考: http://ja.wikipedia.org/wiki/%E5%B7%AE%E9%9B%86%E5%90%88
整数どうしの割り算には大きく２種類の意味があります。等分除と包含除です。
上に書いたように５人で分けると１人分はいくつでしょうといった等分除と、３個ずつ分けると何人に分けられるでしょうといった包含除です。
参考: http://ja.wikipedia.org/wiki/%E9%99%A4%E6%B3%95
普通に算数を学んだ人は、この２つの違いを意識することはないと思います。
どちらも同じ割り算という計算をすれば答えが出ることをすぐに思いつけるレベルになっているでしょう。
即座に割り算だと分からないと、割り勘も出来ないし生活で困るはずです。
むしろ、この２つの違いを意識して式を立てるほうが異常だと思います。
3×5 の定義は3を5回足し合わせること。すなわち 3+3+3+3+3 である。もちろんこれは正しいことです。
よって、3×5 は3個のりんごを5組集めてきたときの総数という意味に解釈しなければならず、5個のりんごを3組としてはならない。これは完全に誤りです。
定義は掛け算の計算方法を定めているのであって、意味を定めているものではありません。
たとえば、掛け算には面積を計算するという重要な意味もあります。縦3m横5mの長方形の面積は何平方mでしょう？
3+3+3+3+3=15
により15平方mと解いたならこれは自信をもって×にできます。
3mを5回足すことに面積を求めるという意味はありえません。大体、左辺と右辺で次元が違っています。
3×5を定義で置き換えることで完全に意味が変わってしまいました。これは定義が意味を示してるわけではないということです。
割り算も同じです。等分除で定義した割り算も包含除で定義した割り算も計算の結果は同じです。意味が違うだけです。
意味が違うからと違う記法を導入してはいけません。数学は意味を捨て去って計算を抽象化する学問です。結果が同じならみんな割り算と呼んでやればいいのです。
意味の違いを捨て去ることで算数のレベルはひとつ上がりました。掛けられる数は常に左で必ず個数だと決めて覚えるのはもちろんレベルダウンですよ。
掛け算は何を意味するのか？それは定義ではなくて掛け算の性質（＝定理）から得るのが自然だ。
3×5は定義から「3個×5組」という意味にとれるし、交換法則と定義から「3組×5個」という意味にもなる。
「3m×5m」なら面積だし、「3m×5本」なら長さの合計でもいい。
大事なのは上のように式の意味をたくさん見つけてくる能力を強化することと、逆に意味から式を作る引き出しを充実させることだ。
みんなこのプロセスを辿ってきたから、等分除とか包含除とか意識せずに割り算できるし、掛け算の左と右を区別するという引き出しの容量の無駄遣いなんてしなくなったはずだ。
わざわざ理屈で考えて式をひねり出させるような問題ではない。そんなことができるのは算数が得意な利口なのだけだろ。
整数同士の掛け算は「複数回足す」でよいだろう。
有理数同士の掛け算は既約分数の分子同士、分母同士を掛けるとできる。（その妥当性は簡単に検証できる）
「100円のりんごを3個買うのと、100円のナシを3個買うのとでは、合計金額を計算するのは同じ式でよい」という程度の抽象化はするけど、
頭悪いな。
りんごだとか皿だとか、物理的な実体が出てきた時点で数学じゃなくて物理の領域なんだよ。
（※ 追記しました。）
なわけありません。元ネタは
http://alfalfalfa.com/archives/1374811.html
で、
http://kidsnote.com/2010/11/15/35or53/
とかで議論されている。この問題は
の話が混じりあい、おかしな事になっている。
だがそんな中で、「これは数学では全く同じものだから、くだらない、国語の問題だ」とか言って思考放棄してる連中が多すぎて反吐が出そう。おまえら、どうやって掛け算計算しているんだ？3×5=5×3は、定理より導かれる帰結なんであって3×5と5×3が同じ意味なわけがない。
ここでは、「高等教育を習った人向け」に、数学的に5×3と3×5を区別するべきことを説明する。
suzusuke氏も算数科学習指導要領解説から引用していることであるが、数式とは思考過程を表現する言葉（ツール）である。
Aさんがりんごを1個、Bさんがりんごを3個、Cさんがりんごを2個持っていました。合計は？
これに対して、
4+2=6、よって6個
と書いたら、だれにも伝わらない。4って数字がどっから来たのかわからないからだ。
いくら「1+3=4なのは数学的に等価だ！」といっても、それはお前の頭の中であって別の話である。
6であるということを証明するには合計を計算するにはすべてを足せばOKという共通認識を持った上で
1+3+2=4+2=6
と示さなければいけないのである。無論、バックグラウンドで了解が取れるなら
1+3+2=6
といきなり書くことは何ら問題がない。大事なのは「1+3+2」と「1+3+2=6」は言葉として意味が違う、ということだ。どう考えたか、をできるだけハッキリした形で表現できるツールが、数式なのである。
お前らは「3×5も5×3も同じじゃないか」とか言うかもしれない。じゃあ聞きたい、「その同じと言ってる3×5とはなんなのか」を。まさか九九を信用して「3×5=15」のことだ、とは言わないだろう。
ここで、「定義」の必要性が出てくるのだ。掛け算はあまりに普遍的すぎて、そこを忘れやすい。そこで我々は×という記号を
3×5 = 3+3+3+3+3
のような略記である、と「定義」するのである。
ここで、お前らは英語圏では
3×5 = 5+5+5
と定義しているぞ、バカが。と言うかもしれない。そのとおりである。それで一向にかまわない。だが大事なのは「数学は可能な限り簡潔な定義でなくてはならない」ということだ。つまり、
3×5 = 3+3+3+3+3 または 3×5 = 5+5+5
なんて自由度を与える定義はあってはならないのだ。そもそも、計算してみないとほんとに等しいかわからない3+3+3+3+3 と 5+5+5 のどっちでもいいよ、ていうのはwell-definedにならない危険性さえある。とにかく、定義は一つで済むなら一つにするべきなのである。
あくまで定義の仕方が２通りある、ということだ。定義の仕方自体に絶対性はない。そして、日本では前者のほうがしっくりくるから、とりあえず前者で定義している。定義なんだから、ローカルルールも小学生限定もない。そこを履き違えてはいけない。
ちなみにそんなこと数学で習ったことない、という奴もいるだろうが、当たり前である。高等数学では上記のような略記であるとは定義しない。それは0とか負の数とか、小数とかが入ってくると上記の定義では不足するからである。だが、はじめは自然数だけの世界で議論するなら上の定義が一番素直なのである。
では、上記の定義を教えた、という文脈で数学的に「5皿でそれぞれ3つのりんごが乗っている、りんごは合計で？」の解答を考えよう。
15個。
誤答。これは回答になってない。文章中に15という数が書いていないので、どこから15が出現したかわからない。
3+3+3+3+3 = 15、よって15個
正答。3個のものを5皿あるんだから足し合わせるのは自然。式変形は当たり前なので省略したのであろう、当然
3+3+3+3+3 = 6+3+3+3 = ...
としてもOK。
6+3+3+3+3 = 15、よって15個
誤答。たしかに3+3=6だが、それを計算したかどうかが伝わらない。数学的に等価だ、なんて理由にならない。
5+5+5 = 15、よって15個
誤答。文章中に「5個」という言葉が出てない以上、はじめの式の5は「5個」と解釈できない。だから足しあわせた結果はりんごの数を表現しない。
同じ数ずつ乗っているなら1個ずつ配っていくことで数えられる。一周で配れる量は5個で、3こずつ配るから三周する。よって
5+5+5 = 15、よって15個
正答。数式中に現れる5をリンゴの数だと説明しているからである。
3×5 = 15、よって15個
正答。我々の定義に従えば、その2の略記でしかない。
5×3 = 15、よって15個
誤答。我々の定義に従えば、その4の略記でしかない。すると同じ理由で間違い。
3×5と5×3は数学的に等価だ、なんてもう言わないよな？それを認めるとその3でさえ正しい。
数式とは「定義」という共通認識のうえで言葉を話すものであって、別の記述をしたら「偶然正しい」のか「根拠があって正しい」のかわからんのである。
結論は
数の概念を整数一般に拡張させると、掛け算の定義は上記では不十分で、分配結合則など環の性質にその本質があることに気がつき、そこに定義を移すことになるがまた別の話。そこまで行くと公理とは何か、整数とはなにかを考え直す必要が出てくる。そこで可換性自体は代数構造には不要であることにも気づくはずだ。
大事なのは定義を尊重する姿勢と、定義そのものに着目する（そして、定義そのものを疑う）姿勢を合わせ持つこと。ローカルルールだ、とか押し付けだ、とか言っているやつらが、実は一番思考停止してる。
まぁ小学生にここまで考えさせるのは、正直厳しいが上記正答例、誤答例を示してみるくらいはいいんじゃないか、と思う。
トラバが付きまくってるｗみんな好きだね。
言いたいことが伝わらなくて、もどかしい。
ここまできて、根拠が「それが普通」だからてお前・・・。
今度はそれが普通であるという根拠を主張しなきゃイカんでしょ。
「普通」には根拠はないだろう。「慣習」と言い換えてもいい。だから、この定義を疑うことが大事。ただ、一番最初に習う定義として、これを使うことが多いということである。
「それが普通だから正しい、それ以外は間違い」に集約される、と。
バカみたいだな。
「普通だから」ではなく、今の文脈では「3×5 = 3+3+3+3+3 を定義として採用するから」である。まずは定義を信用し、それ以外は知らないものとして扱わなければ数学じゃない。
m×0＝0
m×(n+1)＝ m×n+m
まー俺なんぞが独力で導入できるような概念じゃないけど
それで定義すると、m × n = m + m + ... + m (n times) = n + n + ... + n (m times) = n × m が定理になるんだろう。
ようするに、どれが定義かって話じゃん。
そう、上記の「普通」は普通じゃないだろと気がついたときに定義に変更が加わる。そしてこちらの定義のほうが美しい。だから「これが掛け算の定義だ、そしてこれを定義にすればこの定理は明らかだ」という「文脈」では、5×3と書いても3×5と書いてもいい。
文脈についても議論がされているようだが、文脈こそ数式を語る上で重要なものだ。何を定義にするのかというのも文脈だし、どの定理を認めるかも文脈だからだ。
たぶん、5×3も3×5も同じ物と主張する人は可換性を自明としている。それこそが文脈である。しかし数学で何が文脈なのかは、状況によるし、今回は掛け算を定義したばかりなのだから可換性を自明とするのはおかしい。
「１皿につきりんご３個」と表現した時点でそれは３個/皿という比率しか現していない。３個＋３個＋３個＋３個＋３個＝１５個と言いたいらしいが、前処理を済ませない限りその３につけるべき単位は個ではなく個/皿でしかない。３(個/皿)＋３(個/皿)＋…、おいおい、比率って足せるのかよ？
単位の話をすると少し難しくなる、というか物理がわかんないのでそこを正確に語れない。だが、あなたの主張を通すと 3+3+3+3+3=15 は間違いだ、ということにならないか？これを否定されるとどうしようも無い。
オブジェクトのシリアライズツールであるプロトコルバッファについて書きます。
Protocol Buffers 本家
http://code.google.com/apis/protocolbuffers/
XMLはもう不要!? Google製シリアライズツール「Protocol Buffer」
http://journal.mycom.co.jp/articles/2008/07/18/protocolbuffer/index.html
Protocol Buffers (Protocol Buffers の内部解説記事。とても参考になります)
http://dodgson.org/omo/t/?date=20080712
プロトコルバッファは異種言語間でオブジェクトのやりとりをするための規格です。
独自の言語によりオブジェクトのインターフェースを規定することで、多言語対応を行っています。
例えばこんな感じ。
package tutorial; message Person { required string name = 1; required int32 id = 2; // Unique ID number for this person. optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phone = 4; } // Our address book file is just one of these. message AddressBook { repeated Person person = 1; }
以上のようなprotoファイルから各言語のソースコード、または何らかのデータ操作ライブラリを使いオブジェクトの処理を行います。
googleによってC++, Java, Python用のライブラリが作成されましたが、他の言語に対応したサードパーティー製のライブラリがいくらでもあるので、実質的にほぼすべての言語で使えると言っても過言ではありません。
数字が多きければ大きいほど、長いバイト長で保存されます。ただし、負数の場合は符号ビットが立つ関係で、ほとんど常に変換後のバイト数が最長バイト数(10)になってしまいます。フィールドの型をsint32, sint64で宣言しると、各数値にzig-zags変換が行われるため、負数であってもその値の絶対値で使用バイト数が決まるようになります。
バイナリに保存されるデータは各メッセージのID/型/値のみです。なので、同じ定義の二つのメッセージ型は、プロトコルバッファ上では全く同じように扱うことが出来ます。例えば、片方からシリアライズしたデータを、もう片方の型でデシリアライズすることが可能です。
またオブジェクトを連続でシリアライズ/デシリアライズすることもできます。
すでに存在する継承関係のあるクラスを、Protocol Buffersでシリアライズ/デシリアライズしたい場合は次のようにします。
(ソースコード中になぜか日本語が書けないので、コメントはすべて英語になっています)
message PbBase { require int32 id = 1; require int32 value = 2; require Derived derived = 10; // - Point !!! } message PbDerived { require string string_value = 1; }
継承元のメッセージの定義に、継承先のメッセージを持たせます。Baseを継承するクラスをシリアライズ/デシリアライズしたい場合は、PbBaseメッセージを中心に処理を行うことで、比較的簡単に処理を実装することが出来ます。
例えばこんな感じ
Base *Base_DeserializeFrom(PbBase &pbobj) { // Arrange the classes which inherits from Base. if (pbobj.has_derived()) { return new Derived(pbobj); } else ... } class Base { ... virtual void Base::SerializeTo(PbBase &pbobj) { // Set the fields of 'pbobj', } ... }; class Derived { ... virtual void Base::SerializeTo(PbBase &pbobj) { PbDerived *derived = pbobj.mutable_derived(); Base::SerializeTo(pbobj); // Set the fields of 'derived', ... } ... };
protoファイルを以下のように書くと、メッセージの扱いが非常に難しくなります。
message PbBase { require int32 id = 1; require int32 value = 2; } message PbDerived { required PbBase base = 1; // - Here is the point !!! require string string_value = 2; }
最近、増田でも、夫婦別姓や戸籍廃止についての話題が多い。例えば下記とか。
夫婦別姓の賛成派は親子別姓に耐えれるのか
私も、戸籍廃止、夫婦別姓賛成派である。しかし、戸籍廃止、夫婦別姓廃止派は、相容れない二派に分かれている。
一つは、国が個人情報を管理すべきでないとおもっている派閥だ。
もう一つは、国にが個人情報を、適切に管理すべきだと思っている派閥だ。
私は、後者である。戸籍や姓というあやふやなものは廃止して、整数で個人を識別すべきだと思っている。例えば、生年の西暦４桁＋届け順８桁の１２桁の整数を、個人に割り振ることで、現状の戸籍や姓という制度より、厳密な管理ができる。そして、効率的でもある。
一方、国が個人情報を管理すべきでないから、戸籍廃止、夫婦別姓賛成派の人もいる。
ぼく「えっ」
PHP「$a="0x0A";++$aは11になりますが」
ぼく「いえ"0x0B"です」
PHP「えっ」
ぼく「えっ」
PHP「まだインクリメントしたことがないということでしょうか」
ぼく「えっ」
PHP「えっ」
ぼく「変化するってことですか」
PHP「なにがですか」
ぼく「型が」
PHP「ああ文字列でも整数っぽい文字列なら自動で型変換されますよ」
ぼく「そうなんだすごい」
PHP「ではインクリメントいたしましょうか11ですよ」
ぼく「でも"0x0A"は明示的にキャストしたら0になりますよね」
PHP「えっ」
ぼく「えっ」
PHP「ああ16進数のことなら10進数に自動で変換してから演算するんですよ」
ぼく「なにそれこわい」
PHP「for($i="0w9Z";$i<12;$i++){echo $i;}と書くと $i="0w9Z", "0x0A", 11と変化します」
ぼく「なにそれきもちわるい」
PHP「えっ」
ぼく「えっ」
if ("0x0A" == "10") {
print '(´ε｀ )ﾁｭｯ';
}
チュッ。されちゃいます。
文字列であっても整数と解釈できる文字列の場合は勝手に型変換しやがる今世紀最大の愚行を犯してしまうってのは有名な話だよね。
文字列であっても整数と解釈できる文字列の場合は自動的に整数に型変換してくれる超便利機能があるってのは有名な話だよね。
だけどなんでコレが一致するかわけがわからんかった。
0x0Aは10進数で10になるので一致する。と、言いたいところなんですがそう単純な話じゃないんだ。
以下の例を目ん玉見開いて見て欲しい。
var_dump(0x0A);
var_dump("0x0A");
var_dump((int)"0x0A");
var_dump((float)"0x0A");
var_dump(intval("0x0A"));
実行結果
int(10)
string(4) "0x0A"
int(0)
float(0)
int(0)
つまり文字列の"0x0A"ってやつはどう考えても0と解釈されるはずなんだ。だから上記if文が本来一致するはずがいない。
でも実際は何故か10と解釈されて一致してしまう。
そう、つまり演算子で比較した場合、やらんでもいいのにわざわざ16進表記かどうかまでチェックして余計なお世話的うんこ変換しやがるということになる。
そう、つまり演算子で比較した場合は、16進表記かどうかまでチェックして10進数に変換してくれているということになる。
明示的に書くならこんな感じだ。
if (intval("0x0A",16) == "10") {
print '(´ε｀ )ﾁｭｯ';
}
クソが。
なるほどねー。
ただでさえ文字列同士の比較なのにintに変換されるだけでもミソ糞うぜぇのに、わざわざ16進数の場合は10進数に変換してくれる超糞尿仕様。
文字列同士の比較であってもintに自動変換してくれるだけでも素晴らしいのに、それに加えて16進数の場合は10進数に変換してくれる超便利仕様。
ってこたぁ、8進数表記の場合も糞糞マジ死ぬほど余計なお世話するんだろうなぁと思ってしぶしぶ試してみた。
ということは8進数表記の場合もこの素晴らしい自動変換しれくるのかなと思って試してみた。
if ("0x0A" == "012") {
print '(´ε｀ )ﾁｭｯ';
}
else {
print '＼(^o^)／';
}
実行結果
＼(^o^)／
おー、さすがPHP！、やっぱ8進数の場合は10進数と似てるから8進数と見なすよりも10進数と見なしたほうが効率いいですもんね。いやーわかってるなー。ますますPHPが好きになりました。I Love PHP. We Love Ｐ☆Ｈ☆Ｐ！
はは、はははっ、ははははっ。やるならやる！やらないならやらない！どっちかに統一せーやこのプリンシパル校長ヘッドハンティンピープルぺーぺーぽりんき味噌マッチョ変態改造エアガン陵辱－２くらいのスカンク殺ろうがぁああああああ★ああああああああああああああああああああああああああああああああああああああｆじょ★えいｊｆｓきじぇいつつしまじいのそるいつのだ★ひろけがきちもするけけけそあいんぼろうれあああぁあああああaaaaaa
音の高さは周波数で表現される。周波数が2倍になったとき，われわれは音色が保たれたまま1段「高く」なったと感じる。4倍で2段。2^n倍でn段となる。これに必然性はなく生物的所与条件にすぎない（たとえば，3倍を1段と感じたり，100Hzごとに1段と感じる生物がいてもよい）。人間の耳は20Hz～20000Hzまでの音を知覚できるので，最大10段程度（2^10=1024倍）の音色を聞き分けられることになる。
1段を細分化する制度が音階である。分割の仕方には2つの論点がある。まず，いくつに分割するか。一般によく知られているのは12階に分割する方法（12音階）だが，これが「正しい」わけではない。5音階や3音階を採用した音楽文化も存在する。次に，どのように分割するか。先述のとおり音色は比で決定されるので，差で分割するのは普遍性に欠ける（1段内のみなら可能だが，2段目以降に適用したときに破綻する）。人間の耳は最小で周波数の0.3%が変化したときにその変化を感知できることが知られている。よって1.003以上の比で分割することになる。各音の比を可変にして，常に整数値になるようにしたものを純正律，また各音の比が一定になるようにしたものを平均律という。平均律12音階制を採用した場合，各音の比は12√2になる。これは無理数であるので，これをもとに音楽を奏でるときには近似値を用いなければならない。
F = f * 2^(x/12)
と表すことができる。なおfは基準音，xは基準音からの隔たりを示す整数（音程）である。前提から自明であるが，これは離散的な値をとる。
音階に基づく音を時系列に沿って表示する記号体系として五線譜が広く用いられている。周波数の高低を視覚的な上下に置き換えて示すため直観的にわかりやすい。この五線譜を周波数のグラフとして考えることができる。各々の線は等比的な増大を示すため，対数グラフである。ただし一般的な五線譜の記法は7音階＋5半音という古典的な考え方に基づいているため完全な対数グラフではない。
「f(x,y)を最大にする整数x,yを求めよ」
これを遺伝アルゴリズムでやるとこうなる。
うーん、これはイプシロンーデルタ論法の一変形のような気がする。
うん、ごめん。タイトルは釣り。っていうか今から書くことも間違ってるかもしれない。
識者のフォローを待ちたい。
http://b.hatena.ne.jp/entry/http://wiredvision.jp/news/200904/2009041523.html
これの話なんだけど
「遺伝的アルゴリズム」って出たときに、もうこれは人工知能ではないと一応考えていい。それはソートプログラムが人工知能ではないのと同じみたいな。
「f(x,y)を最大にする整数x,yを求めよ」
これを遺伝アルゴリズムでやるとこうなる。
これを上昇しなくなるまで繰り返したら終り。これだけ。
単純化の為にxyとしたけど、x,yを「素数の和」と考えて素数の列abcdefghを遺伝子なんてするとよりそれっぽくなる。要は遺伝的アルゴリズムとはランダムサーチをちょっと改良した奴ってことだ。
記事中のプログラムは現象をモデル化しては考えてない。文字列のなかから現象に近い値を示す数式とおなじ文字列を選び出すだけだ。
あと、どれくらいの率で子孫を残すか、交換が起こるか、突然変異が起こるか等は計算の収束に影響を与える遺伝子とは独立したパラメータで、それをプログラムがいじるのであれば、まあ一応人工知能と呼んでも怒られないかもしれない。
１÷３＝１／３
から
「三分の二個のリンゴを四分の一個で割るってどういうこと？」
に行くのが急なのかも。
１÷３＝１／３
が出来たら
１÷１／３＝３
をやってみると１より小さい分数で割ると答えが大きくなるのが実感しやすいか。
整数の割り算なら
６÷２＝３
と
６÷３＝２
みたいに、割る数と答えを入れ替えても式は成り立つ。
これは、
６個のリンゴを２人に分けたら何個づつになるのか
と
６個のリンゴを３個づつ配ったら何人に配れるのか
という２つの考え方のどちらも成り立つということ。
このことが理解できていなかったのなら、これも復習する。
リンゴと人の場合は、リンゴは分数にできても人は分数にできないので別の例を考える。
１分間でリンゴを１／４個食べられる人が、２／３個のリンゴを食べるのにかかる時間は？
とか。
これで難しかったらまず
１分間でリンゴを１／４個食べられる人が、１個のリンゴを食べるのにかかる時間は？
でやってみるとか。
わからないことがあったら、わかるところまでもどってからやり直したほうが結局のところ早いのかも。
今年の情報オリンピック予選のこの問題、
冬の寒いある日，JOI太郎君は広場にはった薄氷を割って遊ぶことにした．広場は長方形で，東西方向に m 個，南北方向に n 個，つまり， m × n の区画に区切られている．また，薄氷が有る区画と無い区画がある． JOI太郎君は，次のルールにしたがって，薄氷を割りながら区画を移動することにした．
東西南北のいずれかの方向に隣接し， まだ割られていない薄氷のある区画に移動できる．
移動した先の区画の薄氷をかならず割る．
JOI太郎君が薄氷を割りながら移動できる区画数の最大値を求めるプログラムを作成せよ．ただし， 1 ≦ m ≦ 90，1 ≦ n ≦ 90 である．与えられる入力データでは，移動方法は20万通りを超えない．
入力はn+2行ある． 1 行目には整数 m が書かれている． 2 行目には整数 n が書かれている． 3 行目から n+2 行目までの各行には、0 もしくは 1 が， 空白で区切られて m 個書かれており，各区画に薄氷があるか否かを表している．北から i 番目，西からj番目の区画を (i,j) と記述することにすると (1 ≦ i ≦ n, 1 ≦ j ≦ m)，第 i+2 行目の j 番目の値は，区画 (i,j) に薄氷が存在する場合は 1 となり，区画 (i,j) に薄氷が存在しない場合は 0 となる．
のいい最適化の方法が思いつかない。
一応プログラムは書けたけど90*90の時にまともに動く気がしない。
単なる深さ優先検索。
array = [ [1, 1, 1, 0, 1], [1, 1, 0, 0, 0], [1, 0, 0, 0, 1] ] result = [] def get(x, y): if (0 <= x < len(array)) and (0 <= y < len(array[0])): return array[x][y] else: return -1 def func(x, y, route): route = route[:] # print x, y, get(x, y) if get(x, y) == 0: result.append(route) return if (x, y) in route: return route.append((x, y)) if get(x - 1, y ) >= 0: func(x - 1, y , route) if get(x , y + 1) >= 0: func(x , y + 1, route) if get(x + 1, y ) >= 0: func(x + 1, y , route) if get(x , y - 1) >= 0: func(x , y - 1, route) func(0, 0, []) for i in result: print i
いまさらだがFizzBuzz。
1から100まで、3の倍数5の倍数云々って、全部定数の計算じゃね？
というところに気付き、自称メタプログラマー（略してメタグラマー）俺の血が騒いだ。
定数計算なら、それは実行時ではなくコンパイル時に行なわれるべきだ……。
#include <iostream> const int FIZZ_NUM = 3; const int BUZZ_NUM = 5; const int BEGIN_NUM = 1; const int END_NUM = 101; template<int N> struct Fizz { enum {PRINT = 0, NEXT = N + 1}; static void print() {} }; template<int N> struct Buzz { enum {PRINT = 0, NEXT = N + 1}; static void print() {} }; template<int N, bool ForB> struct Number {static void print() {std::cout << N;}}; template<> struct Fizz<FIZZ_NUM> { enum {PRINT = 1, NEXT = 1}; static void print() {std::cout << "Fizz";} }; template<> struct Buzz<BUZZ_NUM> { enum {PRINT = 1, NEXT = 1}; static void print() {std::cout << "Buzz";} }; template<int N> struct Number<N, true> {static void print() {}}; template<int N, int F, int B> struct FizzBuzz { static void print() { typedef ::Fizz<F> Fizz; typedef ::Buzz<B> Buzz; Fizz::print(); Buzz::print(); Number<N, Fizz::PRINT || Buzz::PRINT>::print(); std::cout << std::endl; FizzBuzz<N + 1, Fizz::NEXT, Buzz::NEXT>::print(); } }; template<int F, int B> struct FizzBuzz<END_NUM, F, B> {static void print() {}}; int main(int argc, char **argv) { FizzBuzz<BEGIN_NUM, 1, 1>::print(); return 0; }
ifなし%なしループ系なし、しかも実行時オーバーヘッドなし！（多分）
ああ、久しぶりにC++を触ったけど、やっぱC++のテンプレートってダメダメだな。20世紀の遺物といわざるを得ない。
君がもし21世紀のモテ系イケメンメタグラマーなら、21世紀のプログラミング言語、D言語を使うべきだ！
驚くべきことに、D言語はコンパイル時に関数が実行でき、その結果をソースコードとして取り込める！
ただし実行できるのは簡単な関数だけだけど……。
import std.stdio; // これでFizzBuzzを全部出力するコードを作るぜ！ string makeFizzBuzzCode() { string code; for(int i = 1; i <= 100; ++i) { // 効率？ コンパイル時にそんな配慮は要らん！ if(i % 3 == 0 && i % 5 == 0) { code ~= "writefln(\"FizzBuzz\");\n"; } else if(i % 3 == 0) { code ~= "writefln(\"Fizz\");\n"; } else if(i % 5 == 0) { code ~= "writefln(\"Buzz\");\n"; } else { code ~= "writefln(" ~ static_itoa(i) ~ ");\n"; } } return code; } int main(string[] args) { // おまけで生成されたコードも見せるよ。 pragma(msg, makeFizzBuzzCode()); // 生成したコードを埋め込む。コピペみたいな感覚。 mixin(makeFizzBuzzCode); return 0; } // 以下ユーティリティ。このぐらい標準で欲しいな……。 /// 整数→文字列変換（コンパイル時） string static_itoa(int n) { if(n == 0) { return "0"; } // 10で割りながら余りを文字にして追加。桁が逆転した文字列になる。 string s; for(; n; n /= 10) { s ~= ("0123456789")[n % 10]; } // 桁位置を正常にする。相変わらず効率無視。 return static_reverse(s); } /// 配列リバース（コンパイル時） /// 実行時ならarray.reverseが使えるんだけどね……。 T[] static_reverse(T)(T[] s) { T[] result; foreach_reverse(c; s) { result ~= c; } return result; } // 心配なので静的ユニットテスト（笑） unittest { static assert(static_itoa(0) == "0"); static assert(static_itoa(10) == "10"); static assert(static_itoa(999) == "999"); static assert(static_itoa(9999) == "9999"); static assert(static_itoa(12345) == "12345"); static assert(static_itoa(314159265) == "314159265"); }
コンパイル結果
$ dmd -unittest fizz_buzz.d writefln(1); writefln(2); writefln("Fizz"); writefln(4); writefln("Buzz"); writefln("Fizz"); writefln(7); writefln(8); writefln("Fizz"); writefln("Buzz"); writefln(11); writefln("Fizz"); writefln(13); writefln(14); writefln("FizzBu(ry
出力結果は略。
さすがD言語！C++やJavaやC#にできない事を平然とやってのけるッ
そこにシビれる！あこがれるゥ！
というか、
writefln(1);
writefln(2);
writefln("Fizz");
writefln(4);
もうwritefln（出力関数）要らなくね？
修正。
// これでFizzBuzzを全部出力するぜ！ string makeFizzBuzzCode() { string code; for(int i = 1; i <= 100; ++i) { // 効率？ コンパイル時にそんな配慮は要らん！ if(i % 3 == 0 && i % 5 == 0) { code ~= "FizzBuzz\n"; } else if(i % 3 == 0) { code ~= "Fizz\n"; } else if(i % 5 == 0) { code ~= "Buzz\n"; } else { code ~= static_itoa(i) ~ "\n"; } } return code; } int main(string[] args) { // もうコンパイル時のメッセージしか出さない。（笑） pragma(msg, makeFizzBuzzCode()); return 0; }
コンパイル結果。
$ dmd -unittest fizz_buzz.d 1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBu(ry
実行するまでもなく結果が出力された。つまり実行時間ゼロ、ということは……
世 界 最 速
みんな使おうD言語！
http://www.kmonos.net/alang/d/1.0/index.html(1.0。こっちの方が安定してる？)
http://www.kmonos.net/alang/d/2.0/index.html(もっと凄い2.0)