 
|
はてなキーワード: 整数とは
教職員の採用については、俗に「定数法」と呼ばれる法律があり、それに基づく各都道府県の条例に基づいて、正採用の教職員の数は明確に決まってる。具体的には、現行の定数法は１クラスを40人としているので、仮にとある都道府県に40000人の生徒がいたら、クラスの数は1000。そうなると、各クラスには担任副担任２名を置くので、正採用できる教職員の数は2000人ということになる。基準の適用の仕方は色々あるし、小学校の定数は最近若干変わってきているし、他にも自治体独自で作る枠もあるし、一方実際のクラス数はもっと多い（全ての学級の「上限」が40人なのだから、それより数の少ないクラスもある＝実際のクラス数は40で割ったより多くなる）が、とにかく、大体そんな感じに「正採用の人数」は決まっている。
で、統廃合のときどうするかだけど、当然「いつ」統廃合するかは決まっているから、計画が決まるあたりから採用調整を行う。子どもの数は出生数から分かるわけだから、将来的にどのくらい学校が必要か不要かはある程度分かっているわけで、それを見越して採用調整を行う。特に、この20年間くらいは、子どもの数の急激な減少期だったりしたから、学校の統廃合も激しく進み、相当の採用調整を行う必要があった。
かといって、雇っている教員のクビをぽんぽん切れるわけではないので、教員の数を減らすには、原則「早期退職」とか「定年による自然減」に拠るしかない。統廃合前にそれをある程度進めないといけないので、たとえばある学校を一つ統廃合する前の年には、その一校分くらいの教員数を減らし終わってる必要がある。だから、大体その前年まで採用数を減らして教員の数を減るに任せる必要がある。だから、前年くらいにはその都道府県の中に（足りない分を補う）期限付き講師があふれるという減少が起こるというわけ。まあ、学校を廃校にすると言っても、いきなり全学年が消えるというつぶし方をしなくてもよい。新１年生が入ってこない状況にすれば、教員数は１学年ずつ減らしていくという手もあるから、講師による調整数も、せいぜい１学年分ずつということにもできる。それでも、この10年くらいは、複数の学校を一気に統廃合する関係上、さすがに調整きかない分もあるためか、定年後の再雇用枠とか、教育委員会内への出向とか、研修センターで研修とか、まあいろいろ無理矢理な調整をする必要があることもあった。
上の増田が書いてる「２クラスに教師が３人」というのは、色々勘違いがあって、そもそも「１クラスに２人」が標準だから、２クラス３人ならむしろ教師が足りないことになる。多分（主たる）担任のことを言ってるのだと思うが、３人の教師が付くのは、学級担任とは別枠の何かとして配当されているという事情によるのであって、「教員が余ってるからぶちこむ」とかそういう事情とは違うと思う（そんな余裕はない）。多分、片方の担任の指導力に不安があるとか体調不安があるとかクラスに発達障害の子どもがいるとか、まあそんな事情だろう。
それにしても、期限付き講師は、昔は採用に際し有利になることもあったようだが（逆に、前評判が出回って不利になる人もいたと噂に聞くが）、今は特にそういうことも原則ないと思うので、そうなると本当に、採用試験に受からない限り、使い捨てである。色々と問題は多いと思う。
PCでの複数コアの主な使い方というのは、まるで違う用途のタスクをそれぞれのコアに割り振って、一番負荷のかかるメインのタスクを停止させないことでキャッシュメモリのフラッシュ回数を激減させることにより、システム全体のスループットを若干上げるためにあるのだと考えてた。
たとえばにAコアでメイングラフィック、Bコアで音声処理/ネットワークでOS(ディスクや入力I/O)みたいな。
セマフォだの同期処理だのまったく考えずにマルチコアの恩恵をそれなりに受けることができる手法って、ほかにないですよね。
ちょっと前に話題になったヘテロジニアスマルチコアなんて、モロ的にそういう発想ですよね。
動画デコードに特化したコアとか、アフィン変換に特化した不動少数SIMDコアとか、AESなど暗号専用のコアとか、それらをまとめる一般整数コアなどまとめて、今までより速いのを安く低消費電力で作って、車載ナビで地デジもネットもゲームもokにしちまおうぜみたいな。
最近のPCは、それとはまた違うアプローチで、CPUコア同様のGPUコアももうすこし自由に使えるような仕組みを増やして、性能稼ごうって方向みたいですが。
facebookにはイイネ！ボタンなるものが付いていて、これはその内容に賛同できるもしくは気に入ったものに対しての意思表示をして、自分以外の友達にもそれを知ってもらうものである。
ある記事等に対してはそれまでにいいね！ボタンが押された人数が常にカウントされていて、その範囲は0～∞（多数の正の整数）となる。
しかし、実際の人間の心理としては、全く感心のない0からとても賛同できる多数の+以外にも、全く賛同できない否定的な-方向の意見が存在するはずである。ところが、facebookにはよくないね！ボタンなどはないのだから、いいね！ボタンの押された回数と実際に見た人の意見は一致しないのである。
あー…。つまり、六角形がゆとりにとっての円だとしたいのね。そうすると、六角形が円として定義出来るような円の定義を与えればいいのだと思う。で、考えてみた。
ノルム||が定義された空間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; }
最近、増田でも、夫婦別姓や戸籍廃止についての話題が多い。例えば下記とか。
夫婦別姓の賛成派は親子別姓に耐えれるのか
私も、戸籍廃止、夫婦別姓賛成派である。しかし、戸籍廃止、夫婦別姓廃止派は、相容れない二派に分かれている。
一つは、国が個人情報を管理すべきでないとおもっている派閥だ。
もう一つは、国にが個人情報を、適切に管理すべきだと思っている派閥だ。
私は、後者である。戸籍や姓というあやふやなものは廃止して、整数で個人を識別すべきだと思っている。例えば、生年の西暦４桁＋届け順８桁の１２桁の整数を、個人に割り振ることで、現状の戸籍や姓という制度より、厳密な管理ができる。そして、効率的でもある。
お風呂でゆっくりしながら、昨夜に勉強した「整数計画法」の問題を考える。
整数計画法のLP緩和と近似について……離散構造と連続構造をいきつもどりつ。
こんなときは、紙に手計算。
朝の問題の続きを考えながら、仕上げを急ぐ。
仮配属の研究室で4年生3人がそれぞれ発表。
この1週間で読んだ論文と考えた解法を話し、教授と先輩からコメントをいただく。
午後にもらったコメントを思い起こしながら、次の発表のことを考える。
「あっ！」と思いつたので、部室に着いてすぐ計算。
無心にクラリネットを吹く。
うまくステップを踏めない後輩をイジる。
みんなで笑ってばかりいた。
仲間と話をしながら夕食（コンビニで買ってきたパスタ弁当とサラダ）。
新しい解法をがんばる。
いくつかの文献に目を通していくうち、気になる論文を見つけた。
「情熱大陸」は最高に気分がいい。
見つけた論文（30ページもある！ おまけに英語だ……）を読む。
読み慣れない英語論文を必死に読んでいたら、いつの間にか机で眠ってた。
http://www.is.s.u-tokyo.ac.jp/pamph/pdf/utokyo_ISguide2009_05.pdf
ぼく「えっ」
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