週に一回は書きますよ 月に4つ記事を書けばノルマは満たされます。
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
lnternational
lnternationalization
何語ですかこれは。

極めつけはこれ。
L18N


解説:
internationalizationをi18nと略すことがあります.
その誤用.
ほかにはl10n(localization)やm17n(multilingualization)とか書きます。
スポンサーサイト
レキシカルスコープを持ち、さらに名前空間やモジュールシステムのような機構を持っているプログラミング言語なら、外部の名前をブロック内で隠蔽する必要はあまりないと思う。逆に、うっかり同じ名前をつけてしまうことのほうがあるような気がする。このような言語については、名前の隠蔽に警告くらい出してもいいのではないだろうか。
夕食で私が言ったこと。これに対する反論。
クラスのメソッドを考える。
  1. コンストラクタとsetterでは、セットする変数と同じ型の引数を受け取り、引数の名前はフィールドの名前と同じになることがある。同じであってもよい。
  2. フィールドを参照する際にいちいち読みにいってほしくないとき、ローカルにキャッシュとしてフィールドの値をおいておくことがある。この名前は同じになる。
  3. マルチスレッドプログラミングで競合を避ける際にも使える。(詳しくは覚えてないです)
このように名前を意図的に隠蔽することは多いので、それに対して警告が大量に出るとうっとうしい。
http://d.hatena.ne.jp/mowamowa/20070215/1171507215
http://d.hatena.ne.jp/mowamowa/20070215/1171526531
あたりから。
ながくなりましたのでTBでコメントします。

まず私のいつもの考え。ブログ記事って完成した記事、特定の事柄について、その先行研究やら関連研究やらを含めてすべてのことを調べた記事を載せる必要はないと考えています。確かに調査の行き届いた記事のほうが役に立ちます。しかし(少なくとも私の)ブログは、そこまでしなくても、むしろ調査が中途半端で突っ込みを入れてもらって考えが深まるくらいでよいと考えています。ブログは書いたものがすべてではなく、書いた結果書き手が進歩できればよい、位の立場です。

まあ気楽に行きましょうやということです。

で、もわさんのはじめの記事についてです。
この記事は"再生産"、よそにあることと同じことを書くことを一部肯定しています。しかし記事の話の進め方として、
「再生産は有害に見えるものの、必ずしも悪ではない」
の「有害に見える」の部分に疑問を持ちました。一般的には人と同じことしか書いていないということは有益ではないです。しかしブログにおいては違うと考えています。そして、このもわさんの文章はブログをターゲットにしているように読めたので、ブログだったら同じことを書いてもいいんじゃないのかと気になりました。

ここでさらに、私は
「おそらくもわさんはそこまでブログに厳しいわけではないだろう。で、それでもこういうことを書くということは、予想するにどこかでこういう"再生産"が非難されていて、再生産を擁護するために書いたのではないか。」
と推測しました。立場としては
「何か問題がありそうなら、何が問題か考えよう」
という感じです。
そして、その事件のようなものがあるのかな、とコメントを書いたわけです。
「なんか火元を指してもらうのも野暮/延焼の危険があるかも」
とか思って、適当に濁しましたが。
> 逆説的に考えれば、普段の話は全部バックグラウンドがあるもんだと理解されているわけですね。いや正しいんですが(^^;

そんな感じです。正確にはちょっと違うかもしれませんが、安全な側に倒したとでもいいましょうか。バックグラウンドがないならば別に何も問題はない。しかしもしバックグラウンドがあるなら、そこには私にとっても危険があるかもしれない。

結果的に深読みしすぎです。

そうそう、こういう話に対しては誰かが言ったうまい言葉があります。

「車輪の再発明」は骨折り損のくたびれもうけだが、「車輪の再生産」はしないと車が作れない。


まとめると、理由なく書かれた記事に理由なくコメントするのも快適だなぁ、と。


ここまでだとはじめの方だけについてしかコメントしてないので後のほうについてもちょっと独り言。ひとりごとですよ。
ソフトウェアだとJoelが助けてくれます。
"Listen to your customers, not your competitors."
研究だと話はだいぶ違います。これは文字通り車輪の再発明m9(^д^) となります。
ブログだと、「その話はもうすでに40年前にありますよ」という書き込み自体がありがたい、と私は思います。だって読者が私の代わりに先行研究を調べてくれるんですよ。
この手法を推し進めると、ポールグレアムになりますね。正直やりすぎだとおもいますが。
まずここで最初に発表したいのは、研究論文の遅延評価アルゴリズムの発見だ。書きたいことをただ書いて、既存の研究を一切引用しないでおく。すると、熱心な読者が全ての引用すべき文献への参照を送ってくれるんだ。「スパムへの対策」がSlashdotに取り上げられた後に、私はこのアルゴリズムを発見した。

どこかで議論していたので、ついWikipediaのラノベ項目とか見てしまいました。

個人的に面白かったのは某巨大掲示板の記述。
●トラブル防止のため、以下の話題はご遠慮ください。
 ★「ライトノベルの定義」。あなたがそうだと思うものがライトノベルです。
  ただし、他人の同意を得られるとは限りません。

素敵です。もう私は年なのでこの長さで十分遊べます。

ダンジョンは6つで少なめです。しかしダンジョンに入るまでの謎解きが結構あり、 村を駆け回って謎を解く必要があるので、個人的には短いとはあまり感じませんでした。 現在、ヒントなし(説明書すら(それはだめよね))で、たぶんラスト直前まで。ひとつずつ詰まりますがヒントなしで進めています。この辺は私の知能水準にあった感じです。感動。

次の場所で詰まりました。

  1. 山のふもと、緑の水を取るところの爆弾箇所に気づかない。
  2. モグラグローブで入れる入り口であることに気づかない。
  3. 秘境から風の遺跡に入れない。ここは難しいですよ。 周囲に小人用の穴がたくさんあったので、 てっきり小人用のアイテムが必要なのかと思って町をぐるぐる探し回ってしまいました。
  4. ボスとか強いです。風の遺跡と氷の遺跡で苦戦。 巨大オクタロック戦では、尻尾を切ろうと周囲をぐるぐるしていました。 あと現在ラスボス?聖域での戦いで一つもダメージが入りません。

あとひとつ文句をつけるとすると、倉庫番が多いことです。むしろこれは昔からかな。氷のダンジョンですべる倉庫番(というかxhl倉庫番<<50th周辺の技術室出身ISerにしか通じないネタ)が出たときには思わず笑ってしまいました。ちょっと倉庫番に頼りすぎではないでしょうか。

名前を"ld"にしました。これではリンクではなくリンカです。


タイトル修正@2/13/2007.
  1. リヴィエラ ~約束の地リヴィエラ~
  2. ファミコンミニ ゼルダの伝説1
  3. EA Best Selections アリス・イン・ナイトメア
  4. ゼルダの伝説 ふしぎのぼうし
  5. だんデらいよん

Wizもやったことないんで手を出そうかと思ったんですが、ビックカメラにあったのは「五つの試練」と「戦闘の監獄」ってやつで、どのバージョンかよくわからなかったんでパスしました。

ところでまだ「イース フェルガナの誓い」をあけてすらいないんですがどうしましょうか。

シューティング脳の恐怖

Lispと通じるものがある気がします。
使ってみれば、これ以上の言語はないとわかるかも?!
人のうちのゴルフ場で遊びすぎるのは良くないですね。
shinhさんがやばいやばい書いていたのが良くわかります。
時間を思いっきりつかってしまいました。
あとHaskellのPrelude.hsをBoolで検索したりとか。おかげで助かりました。

以下ネタばれ。
サイエンスカフェ

ごめんなさい激しく笑ってしまいました。
それにしてもこのキモイはある意味いい表現なのかもしれないと思いました。

あとタイトルは冗談です、というかこぴぺです。気にしないでください。無理なお願いですがどうか気にしないでねと。

革命の日々より

試してみます。

% cat i64conv.cpp
#include <iostream>
using namespace std;
int main(void)
{
    long long x;
    cin>>x;
    int i=x;
    cout<<x<<"="<<i<<endl;
}
% g++ -Wall -W -o i64conv -mno-cygwin i64conv.cpp
% ./i64conv.exe
10
10=10
% ./i64conv.exe
4294967296
4294967296=0
% ./i64conv.exe
10000000000
10000000000=1410065408
% g++ --version
g++ (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
%
あるえ。本当に-Wall -Wではだめですね。以前の経験で-Wall -Wとかすると大体の警告は出たような気がしたんですが。ちゃんと調べないとだめですね。

ほかに適切なオプションがあるのでしょうか。 gcc option summaryのWarning optionsとか見たんですが見つかりません。

たぶんM論終えてからずっと持ち歩いていたと思いますので何人にも話したような気がしますが、一応論文紹介。
3 States & a Plan: The AI of F.E.A.R

via Radium Software Development
FPS(First Persion Shooting)であるF.E.A.Rの敵A.I.についての話です。詳しくはリンク元を見てください。普通NPCの制御に有限状態マシンを使うところを、代わりにプランニングシステムを用いてうまくいったという話です。
記述は本当にわかりやすいです。専門外なのにほとんどわかったつもりになれます。

以下感想。間違ってたらぜひ教えてください。

 このシステムはゴールを動的に切り替えられることが本質的だと思います。最初、p.6 にPatrolとKillEnemyの例が出てきますが、これだけだとおそらく、特に任務を帯びていないNPCはすべてPatrolとKillEnemyをゴールに設定しているはずなので、それが固定ならばFSMで何とかなりそうな気がします。一方後半 p.13 からのチームワークの例では、与えられる指示が切り替わります。時々刻々と切り替わる指示に対応するのにプランニングシステムが有効なのではないかと。あるいはp.8の仕事中に銃で狙撃される例でもよいですが。
 ルールとゴールの分け方もちょっと気になりました。はじめは「ジャンプ」や「歩行」など具体的な動作がルールに入り、「敵を探す」などの抽象的な動作がゴールになっているかと思っていました。しかし p.8 でDeathやStunnedがゴールに分けられていたので、この理解ではちょっとおかしいことに気づきました。おそらく分割不可能な動作がゴールに、途中でほかのことに移れる分割可能な動作がルールに入るのでしょう。とするとドアを開けるという動作も長くかかるならルールからゴールに移る可能性があります。一方でドアを開けるのはもっと抽象的な「敵を探す」「巡回する」などのゴールの手順となるので、その場合はこのシステムを二段重ねで作る必要があるのでしょうか。しかしそうするとどうなるんでしょう。ちょっとよくわからなくなりました。
 関連研究も見てみます。暇があれば。
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。