逃げしか出来ない集団の凄い悪あがき

また凄い悪あがきをしてきましたので、予告通りさらしUP。
http://d.hatena.ne.jp/ange1/20100730
やはり読解能力がない。
情報が喪失している事を記事でもはっきりかいているのですが、彼らは日本語を読めないのでしょうか？

引用
第三に、初期化もしくは変数に値を設定する部分で、意図せず正しくない結果を出してしまう危険性があります。使用する際には注意が必要です。

分かっていないようだからいいますが、0～4の情報が喪失しております。
さらに、自分で名前を変えている事を発表しているし（笑）

引用：Sodaさんの記事 ( id:Deppi:20100726 )

違う名前を使うなとあれほど騒いで置いて、自分たちは違う名前を使うわけですか・・・
まぁ、論理が破たんしているのは前からですがね。
見てくれたら分かりますが、他の部分も痛々しいばかりです。
筆者が記事を訂正したら卑怯などと言って、陰で女々しく数人で誹謗中傷に徹している自分たちは、卑怯とは考えないらしい。
それに、彼らが発見した実績とは、まれに起こる誤字脱字のみだという事にまだ気づいていないのかな？
しかも、趣味のブログを初めて間もない期間に起こった事ばかりだしね。
ひっそり記事を訂正しているなどと言っておりますが、記事の訂正記録が表示されるのは当然知っております。
だから、特に何も言う事はないと考えて、何も書いていないのですが、また妄想力を爆発しているようです。
会話にならないという部分も未だに理解していないようですが、陰で女々しく誹謗中傷する事に徹している人と、どうやったら会話になるというのでしょうか？
相手が居ないので会話が成立しません。
おかしなことに彼らの言う会話とは、陰口を叩く事らしいです。
最後に、彼らに技術者失格と言われて嬉しいです。
というのも、彼らの言う技術者orプロとは、前に書いたように「自分より知識が下回る人間」の事ですから、彼らにプロと認められたらお終いです。
例えば、「ボトムアップアプローチを知っていればプロではない」、「自分はC言語を知らないけども、C言語の知識を前提としている記事は間違っていると思う」・・・等と本気で言っている人たちです。
※これを書いたら技術者orプロ認定と書いてくるかな（笑）
こういう風に、自身の読解能力のなさをアピールしてくる人間は初めてです。
言えば言うほど、自分たちの能力のなさをアピールする結果になるという事を把握していない。
彼らは本気で技術論をしているつもりらしいですが、日本語が読めない人相手に技術論をしたい人はいませんし、誤読・誤信を妄想で広げる行為は技術論と呼べません。
日本語が読めるようになってから、技術論はするべきだと思います。
それから、情報処理技術の基礎をちゃんと学んで下さい。
そうやって、誹謗中傷をしているだけでは成長しません。
いや、そうやって、今までも人生を送ってきたから、私よりも年上なのにもかかわらず、知識が少ないというべきですね。
それどころか、そもそもこの人たちは、IT業界の人間ではないでしょう。
e氏も自分だけはプロだと言っておりましたしね。
素人がどれだけ喚こうが、滑稽なだけです。

それにしても、面白い人たちです。
とはいえ、こんな馬鹿集団の記事ばかり書いていては、このブログの品位が問われるので、時々にしておきます。

追記
分かっていないようだから書きますが、マニュアルをただ読むだけでは習得したとは言えません。
マニュアルは最低限の事しか書いておりません。
その技術的背景や理論を理解して、初めて習得したと言えます。
マニュアルを見て、それを模倣するだけならば、素人でも出来ます。
この人たちは、そこが分かっていないんですよね・・・
インテルTBBのマニュアルを読んで、理解したつもりになって「並列処理でcoutを使え」、「並列処理でグローバル変数を避ける理由がない」、「sleep(200)の処理時間は200ミリ秒だ！」・・・などと壮大な間違いを犯しています。
インテルTBBのマニュアルは、基礎レベルの並列処理の知識がある事を前提としていると思うな。
おっと、また分からないと思うから書いておくけど、OpenMPの仕様書も同じですよ。
あの手のマニュアルは、基礎知識があるのを前提としています。

爆笑！世にも奇妙な誹謗中傷集団の観察日記

おはぴよ♪昨日紹介した哀れな集団について書きます。
彼らの理解力はやはり0なようです・・・

SeroSero 2010/07/27 12:24 >http://indori.blog32.fc2.com/blog-entry-1056.html 金種が可変であるとはいえ、ある条件において「最小となる枚数」にならないなら貪欲法を使うのは間違ってる気がす。

絶望的な理解力ですね。
「処理結果は何も出力されなかった。という事は、金額による変化はなしという事だね。念のために１万まで実行させたけど、両アルゴリズムの結果は同じだった。」
とかいているのに・・・
理解力がないようだから解説しておくと、両アルゴリズムの結果が同じと言っているのだから、今回の実験内では貪欲法と動的計画法の解は同じです。
さらに実験してみないと分かりませんが、解が同じならばスピードが早い方を採用するのが普通。
其の流れで、次にスピードを測っている。やはり文章が分かっていない。
それから、まだ営業妨害をしているようです。

ange1   2010/07/29 21:23  > こっそり修正されている件について。
> 何か悔しいことでもあったのか
アレかも。私が編集部にクレームを入れたからかも。
にしても、えらく舐めた仕事をしてくれるもんだ。まあ、要確認ですな。

まともに会話出来ないから、卑怯な手段に徹しているようですね。
何時もスタート地点から間違っているクレームを入れているようだけど、あさっての方向の誹謗中傷しかしないから、どうしようもありません。
間違っているのであれば訂正できますが、指摘そのものがあさっての方向を向かれては何も出来ないのです。
自分が理解していないという事を何時になったら気付くのでしょうか？
まぁ、読解力がなく、その理解できていない部分を妄想力でカバーしている集団だから、一生気付かないと思います。
e氏を筆頭に、並列処理でcoutを使っても平気だと、堂々と間違った発言をしていましたからね（笑）
coutを使ったら駄目なのは、入門者用の本に書いてある、並列処理の基礎中の基礎です。
全く並列処理を知らないのに、知ったかぶりして指摘しているつもりなのが透けて見えます。
自分が並列処理について知らないのを知らないとは、救いようがありませんね。
あと、自分の記事を点検して改善するのは普通の事だと思いますが・・・どうやら、 自意識も過剰なようです。
さらに、この記事をまた理解していないし（笑）
他にも馬鹿げた記述があります。

 eileaneilean   2010/07/29 18:49  何か悔しいことでもあったのか中傷記事をアップ。
自分のやっていることが中傷であるとは考えられないらしい。
http://indori.blog32.fc2.com/blog-entry-1059.html

自分たちがしている事は、明らかな誹謗中傷だという事を把握していないようです。
1年以上誹謗中傷し続けていた人に言われたくありません。
それに、私は事実を書いているだけです。
読解力がないのは、彼ら自身が1年以上も証明し続けています。
この人たちは何を考えて、自分の読解力のなさ等をアピールしているのでしょうか・・・
AlexAndRiteさんの記事（ 結局、id:busaikuroは誹謗中傷したんだろ？CommentsAdd Star）を読めば、その稚拙な行動が分かります。
彼らは、少しは調べてからものをいった方がよろしいかと思います。
彼らは自分が論理的だとおかしな発言をしておりますが、知らない専門用語を妄想力でカバーしたり、単語から妄想を広げるのは論理的とは正反対の行為です。
論理的という言葉を辞書で調べる事をお勧めします。
彼らは＠ITの質問者を散々馬鹿にしていましたが、自分達が一番変な事をしていると把握する方が重要です。
彼らが、自分たちの愚かさを把握するまで、さらす事にします。

中の人の徒然草369

こんにちは。今日も元気なインドリです。
何時も情報処理技術の事ばかり書いているから、今日は情報処理技術と関係のない雑談を書きます。
このブログの常連の方は知っていると思いますが、誹謗中傷を目的とする変なグループが存在します。
その習性がかなり面白いです。
其のグループは基本的に、自分が知らない事は間違いだと判断します。
しかも、知識量が非常に少ないので、何でも間違いに見えるようです。
普通の人は、分からない用語があれば、調べるか本人に聞くと思うのですが、彼らは知らない＝間違いだと決めつけて、妄想を膨らませます。
なおかつ、間違いだと決めつけて妄想を膨らませるので、時間がたつごとに真実から遠のいていきます。
例えば、彼らの仲間であるJ氏は、自分がボトムアップアプローチと言う用語を知らないから、ボトムアップアプローチという用語を知っている奴はプロじゃないと、このブログで仲間と共に暴れました。
本当に理解できません。ボトムアップアプローチという情報処理技術の用語を知っていると、プロじゃないそうです。という事は、大半のSEは彼の定義ではプロではないのでしょう。
そうした理解できない思考に基づき、人を誹謗中傷するのですから、非常にたちが悪い奇妙な集団です。
知識が少なく、その知識に収まらない範囲の事は、全て間違いだと判断して誹謗中傷をするのですから、お話しになりません。
きっと、そうやって自分が知らない事を今まで放置していたから、一向に知識が増えないのでしょう。
また、そういった考えだから、会話になりません。
会話を試みても、知っている事が少なく、知らない事は全て間違いだと判断する人とは会話になりません。
さらに、文章の読解能力が低く、単語だけ読み妄想を膨らませますので、文章では意思疎通が出来ません。
従って、インターネット上では、彼らとコミュニケーションをする事が不可能です。
知識が少ない理由の一つは、文章を読めないから専門書が理解できないのでしょう。
そんな彼らも誹謗中傷をするべく、たまにインターネットで調べるようですが、残念ながらインターネットにはごく一部の情報しか存在しません。
全ての情報がインターネット上にあれば、専門書なんていらないのですから、それも当然のことでしょう。
それにも関わらず、彼らはインターネット上にない情報＝存在しないと考えるので、本当にどうしようもありません。
この奇妙なグループから得られる教訓は、人の話しは良く聞こうと、知らない事はちゃんと調べようです。
それにしても、彼らはどのような生活を送っているのでしょうか？
特にリーダー格であるe氏は、一日中ネットに居て、誹謗中傷にいそしんでいますが、仕事はしていないのでしょうか？ 非常に不思議です。
独りで意見を言えず、人と会話もできず、一日中妄想にもとづき誹謗中傷を行う・・・
きっと、自分で恥ずかしい事をしているという自覚がないのでしょうが、恥ずかしくみじめな生き方です。
人生を考えさせられる、良い反面教師と言えるかもしれません。
やはり、コミュニケーションは大事ですね。

中の人の徒然草368

こんにちは。暑さにまいっているインドリです。
今日は何を書こうかな・・・・・・
最近アルゴリズムについて書いたので、ソフトウェア開発におけるアルゴリズムの選択について書きます。
実務でアルゴリズムを選択える際には、色々な事を考えなくてはなりません。
1つ目は正確さです。正しくなければ駄目なので、説明の必要はないでしょう。
2つ目は重要さです。お仕事には納期が設定されています。その限られた時間を有効に使う事は大変重要です。ですから、そのロジックにどこまで時間を充てられるのかを考えなくてはなりません。
残念ながら実務では、アルゴリズムの選択や、プログラムの洗練を思う存分考えられません。物事に優先順位をつけて、素早く行動せねばなりません。
3つ目は、リソースの配分です。重要でない処理には、それなりのリソースを充て、重要な部分に十分なリソースを充てなくてはなりません。
例えば、動的計画法を使用したロジックを並列化する事を考えます。並列化するには、並列アルゴリズムを考える時間、実装する時間、テストする時間などが必要です。また、並列処理を実行するには、PCのリソースも使わなければなりません。
すなわち、そのロジックはシステム全体に於いて、そこまで重要なのでしょうか？ 貪欲法でもよいのでは？そのロジックでスレッドを使用すると、重要なロジックに充てるスレッドが十分なものではなくなるのでは？・・・等と言った事を検討するという事です。
システムに於いて、実行されるコードは偏っていますので、全てのロジックを最高にする必要はありません。
これは手抜きをしろと言っているのではありません。最高に保とうとすると様々な問題が発生し、お客様に満足してもらえるシステムが提供できなくなります。
手抜きではなく、全力で限られた時間と予算内で、お客さまにとって最高のシステムを提供するべきだという事です。

マルチコア時代に突入し、CPUのコア配分まで考えなくてはならない時代になりました。
これからの時代は、アルゴリズムの選択肢が増えまずので、大変だけど楽しいですね。
選択肢が増える事は、お客さまにとって良い事だと私は考えています。
どれだけの選択肢をお客様に提示できるのか？
それがIT会社の実力をはかる、一つの基準になるでしょう。

ネタつつき84－動的計画法と貪欲法をつつく♪ 其の二

前回に引き続き、動的計画法と貪欲法をつつくピヨ♪
前回は金種を変化させる事により、その差を確かめたので、次はお釣りの金額を変えてみる。
前回のプログラムを使用したら、一々お釣りを変えて実行するのは面倒だから、mainプログラムを変えて、コンピュータに処理をさせてみた。

int main() { //金種を設定 vector<int> denomination; denomination.push_back( 1 ); denomination.push_back( 5 ); denomination.push_back( 10 ); denomination.push_back( 25 ); Dynamic dina( denomination ); Greedy gree( denomination ); for ( int i = 0; i < 2500; i++ ) { //金額を設定 int amount = i; //動的計画法で釣り銭問題の答えを出す vector<int> result = dina.Calculation( amount ); //貪欲法で釣り銭問題の答えを出す vector<int> result1 = gree.Calculation( amount ); //結果に差があったら出力 if ( result.size() != result1.size() ) { cout << "動的計画法で算出" << endl; PrintResult( amount, result); cout << "貪欲法で算出" << endl; PrintResult( amount, result1); } } return 0; }
処理結果は何も出力されなかった。という事は、金額による変化はなしという事だね。念のために１万まで実行させたけど、両アルゴリズムの結果は同じだった。
次に気になるのは、スピード。貪欲法の早いと思うけど、念のために確かめてみた。

int main() { //金種を設定 vector<int> denomination; denomination.push_back( 1 ); denomination.push_back( 5 ); denomination.push_back( 10 ); denomination.push_back( 25 ); //変数を設定 time_t start, end; int max = 25000; //動的計画法の処理時間 time( &start ); for ( int i = 0; i < max; i++ ) { int amount = i; Dynamic dina( denomination ); vector<int> result = dina.Calculation( amount ); } time( &end ); cout << "動的計画法の処理時間は" << difftime( end, start ) << "秒です。" << endl; //貪欲法の処理時間 time( &start ); for ( int i = 0; i < max; i++ ) { int amount = i; Greedy gree( denomination ); vector<int> result1 = gree.Calculation( amount ); } time( &end ); cout << "貪欲の処理時間は" << difftime( end, start ) << "秒です。" << endl; return 0; }
最大限の最適化をしてから、このプログラムをコンパイル＆実行すると、動的計画法は6秒、貪欲法は0秒という結果が出た。
なるべくOSに依存しないプログラムを書きたかったから、標準ライブラリだけを使ったけど、精度が足りていないな。まぁ、早い方を判別するだからいいや。
この2つの結果から考えるに、十分な情報を持つ時、貪欲法を使用するとよいと言える。基本的には貪欲法の方が早いから、正しい答が出る時は、貪欲法を使うべきだと思う。
貪欲法に与える情報が足りているかどうかは、少ない範囲で試してみるといい。
例えば、今回の場合は釣り銭、ナップ・サック問題では重量制限を、少ない範囲の値で実行して、結果が正しいかどうかを確認すると、どちらのアルゴリズムを使うべきかの判断基準となる。
アルゴリズムを比較するのって楽しいな♪
これは余談だけど、今日はキャラが定まらなかったなー♪
今度からは、文章のキャラを決めてから書こうかな。

ネタつつき83－動的計画法と貪欲法をつつく♪ 其の一

今日は休日なので、マッタリとプログラミングで遊びます。

定められた金種を用いて、指定された金額の釣り銭を作る場合、最小となる枚数の組み合わせを求める。ただし、同じ金種のお金を何度も使ってもよい。

この問題を解くにあたって、私が直ぐに思いつくアルゴリズムが動的計画法と貪欲法です。この2つのアルゴリズムの違いを知りたくて、サクッとプログラミングしてみました。

#include <iostream> #include <vector> #include <algorithm> #include <iterator> using namespace std; class Dynamic { private: vector<int>& denomination; //金種 public: Dynamic( vector<int>& denomi ) : denomination( denomi ) //釣り銭問題を計算 vector<int> Calculation( int amount ) { //枚数を初期化 vector<int> count; for ( int i = 0; i <= amount; i++ ) { count.push_back( i ); } //動的計画法で釣り銭を算出 vector<int> use( amount + 1 , 0 ); for( int i = 0; i < denomination.size(); i++ ) { for ( int s = denomination[ i ]; s <= amount; s++ ) { int p = s - denomination[ i ]; int newCount = count[ p ] + 1; if ( newCount <= count[ s ] ) { count[ s ] = newCount; use[ s ] = i; } } } //計算結果を格納 vector<int> result; for ( int i = amount; i > 0; i = i - denomination[ use[ i ] ] ) result.push_back( denomination[ use[ i ] ] ); return result; } }; class Greedy { private: vector<int>& denomination; //金種 public: Greedy( vector<int>& denomi ) : denomination( denomi ) {} //釣り銭問題を計算 vector<int> Calculation( int amount ) { int remainder = amount; vector<int> result; for ( int i = this->denomination.size() - 1; i >= 0; i-- ) { while( denomination[i] <= remainder ) { remainder -= denomination[ i ]; result.push_back( denomination[ i ] ); } } return result; } }; //結果を表示 void PrintResult( int amount, vector<int>& result ) { cout << "金額：" << amount << endl; cout << "枚数：" << result.size() << "枚" << endl; cout << "使用した金種："; copy( result.begin(), result.end(), ostream_iterator<int>(cout, " ") ); cout << endl << endl; } int main() { //金額を設定 int amount = 44; //金種を設定 vector<int> denomination; denomination.push_back( 1 ); denomination.push_back( 5 ); denomination.push_back( 10 ); denomination.push_back( 25 ); //動的計画法で釣り銭問題の答えを出す Dynamic dina( denomination ); vector<int> result = dina.Calculation( amount ); cout << "動的計画法で算出" << endl; PrintResult( amount, result ); //貪欲法で釣り銭問題の答えを出す Greedy gree( denomination ); cout << "貪欲法で算出" << endl; vector<int> result1 = gree.Calculation( amount ); PrintResult( amount, result1 ); return 0; } サクッとプログラミングしたから、改良の余地はあると思うけど、目的はアルゴリズムの違いを考える事だから、よしとしよう。
釣り銭を44、使用金種を25・10・1に設定すると、次の結果になる。

動的計画法で算出
金額：44
枚数：8枚
使用した金種：10 10 10 10 1 1 1 1 

貪欲法で算出
金額：44
枚数：11枚
使用した金種：25 10 1 1 1 1 1 1 1 1 1

あれ？貪欲法は11枚も釣り銭を出しているぞ！
ポケットが小銭でいっぱいになりそうですｗ
じゃあ、次は釣り銭を44、使用金種を25・10・5・1に設定してみよう。
今度は次の通りになったよ。

動的計画法で算出
金額：44
枚数：7枚
使用した金種：25 10 5 1 1 1 1 

貪欲法で算出
金額：44
枚数：7枚
使用した金種：25 10 5 1 1 1 1

与えられた金種によっては、両アルゴリズムの結果は同じになる。
じゃあ、その違いは何かな？
長くなったから、次回へ続く♪

エピステーメー軍団が迷惑すぎる

余りにも迷惑なので書きます。
知っている人は既にいると思いますが、エピステーメー軍団の行為が迷惑すぎます。
1年以上も間違った知識に基づいて、子供じみた迷惑行為を繰り返します。
エピステーメー氏を筆頭に、彼らはCodeZineのコメント欄を占拠し、コメント欄がなくなった今でも、色々な手段を使って迷惑行為を繰り返しています。
具体的に言いますと、最近公開されたインテルTBBのスレッドクラスについても、エピステーメーは編集部に迷惑なメールを送りつけています。

Subject: これはひどい: 「インテル TBB のスレッドクラス」

επιστημηです。

http://codezine.jp/article/detail/5259
# コメント欄が閉じているので本メールで。

この記事は正視に耐えません。

- そもそも class tbb_thread は"deprecated"だとマニュアル(Reference)に明記さ
れています。
  重要な注意が記事中のどこにもありません。

- 「tbb_threadはheavyであり、たくさん起こすと著しいパフォーマンスの低下を引
き起こしかねない
　からできるかぎりtaskで解決すべし」とマニュアル(Reference)に明記されていま
す。
　重要な注意が記事中のどこにもありません。

いつもながら、酷い代物です。この方は、読解能力がないとしか思えません。
私の記事はどこにもスレッドクラスの使用を推奨していません。前提を読んでいないようです。


インテルTBBには豊富な機能があり、大概の並行処理はそれを使用すれば解決できるでしょう。しかし、あらかじめインテルTBBに用意されている並列アルゴリズムを適用できない状況で、並列処理をする必要があるかもしれません。この場合は、インテルTBBに用意されているthreadクラスの使用を検討する必要があります。


ですから、極力使用するなと言っているのですが・・・
さらに、まとめで念押ししています。


　しかしながら、並列処理の初心者が、実務レベルで使いこなすのは大変難しいでしょう。この連載は基礎の解説を目的としているので、詳しいことは今回述べませんでしたが、スレッドクラスを使用して自分で独自の並列アルゴリズムや、スレッドセーフなクラスを実装するのは多くの知識が必要となります。


推奨しないとだけ書いても、説明不足ですし、インテルTBBが対処できない処理を並列化する時どうするのかを説明しているわけです。
技術解説記事はマニュアルを写せばいいというものではありません。
日頃の言動や文章を見るに、どうやらエピステーメー氏は、マニュアルをそのまま書くのを推奨しているようですが、それは著作権上よろしくない事ですし、それでは記事の存在意義自体がなくなります。
どうやら、全く内容を理解していない上に、マニュアルも理解していないようです。
あと、彼らは必死で誤魔化していますが、過去からずっと間違った知識に基づいて騒いでいます。
数が多すぎて、全てを挙げられないので、最近の出来事をピックアップします。
スレッドセーフとインテルTBBのコンテナにてcoutを並列処理で使って平気だと騒いでおります。
しかし、私の記事で証明しているように、この様な事をすれば、メッセージが乱れる場合もある上に、メッセージの出力順序が不定なので、問題があると言えます。この様な特性を持つcoutを並列処理で使用する事を大丈夫だと言い切るのは非常に問題です。
これは、入門者レベルの事なのですが、あれだけ堂々と言っているところをみると本気で知らなかったようです。
さらに、この軍団のメンバーであるはなおかじった氏は、coutはスレッドセーフで使用しても大丈夫だと、自分のブログで言い切った上に、マルチスレッドを安全に実行する という、誤り記事を書いています。
他には、OpenMPの実行時ライブラリと並列ループ 内にて、間違った知識をもとに読者に絡んでいます。


page4、最後の実験結果/実験一回目： 処理回数[200] 一処理あたり[1]ミリ秒ならどんなに 速くても200ミリ秒(2-coreなら100ミリ秒)かかるはずなのに 実測では 3ミリ秒あまり。速すぎます/あり得ません。なぜですか? επιστημη （2010/01/29 17:00）


逆にこちらが聞きたいです。200ミリ秒だと思った理由は何ですか？
マニュアルを読めば、200ミリ秒にならないぐらい分かると思いますし、sleepで正確な時間を指定できないのは、Windowsプログラマにとって常識です。マニュアルを読みましょう。
枚挙にいとまがないので、そろそろ纏めます。
彼らは自分の間違った知識に基づき、誹謗中傷を目的として、1年以上この調子で迷惑行為を繰り返しています。
他のライターに迷惑な行為をしているのは、エピステーメー氏です。
独りで自分の意見を言えず、仲間を募って、間違った知識をもとに人を誹謗中傷するのは止めましょう。
それに加えて、ペンネームを変えて嫌がらせするのも止めましょう。


# ごめんなさい。直前の"Cお兄さん"は実は僕です。つまりそゆこと。
επιστημη （2010/02/10 08:09）


他にも、プロバイダを複数契約してやったりしていますが、残念ながらTCP/IPを知っている私には通用しません。 名前は大事ですよ。
自分が知らない事には、口を出さない方がよろしいかと思います。
それよりも、自分の記事をちゃんと書いてください。
これは、この軍団全員に言える事ですが、自分の知らない事で他人を攻撃するのは止めましょう。
並列処理の基礎中の基礎でこの状態なのですから、何も知らないのは明白です。
それに加えて、誤読・誤信が多すぎますので、誹謗中傷する暇があったら、先ずは勉強して下さい。


【追記】
ちなみに、彼らの目的が誹謗中傷である事と、本気で間違っている事は次の台詞を見ると分かります。

επιστημη 2010/02/27 17:09
ぃぇぃぇー
さてさて、次の一手はどうなりますやら。
チェッ クメイトだと思うんだが...起死回生の手があるに違いないｗｗｗ

起死回生も何も、基礎から間違っているんだけど・・・
基礎から間違って居るにもかかわらず、営業妨害が達成できると、自慢しつつ話しあっている彼らは、本当にどうしようもありません。
彼らは1年以上この調子ですが、彼らの意見は誤読・誤信で構成されていますので、目も当てられないありさまです。
いい年して、1年以上も何をしているのでしょうか？
本当に迷惑以外のなにものでもありません。
この様な愚かな活動しても、自分の名誉が傷つくだけと思うな。

中の人の徒然草367

こんばんは♪インドリです♪
ここ2・3日気になっている本があります。
この本の作者は、なんとErlang歴15年らしいです（驚）
私なんて、プロ歴11年ぐらいなのにな・・・
それよりも長い期間をErlangにかけているなんて、凄過ぎる！
そんな作者が書いたというのだから、凄く興味が湧きます。



でもErlangのバイブルをまだちゃんと読んでいないんですよね・・・



一応目は通したのですが、色々忙しくて触り足りない。
Erlangは非常に興味深い言語です。論理型言語ってところが魅力的。
おまけに、私が好きな並列処理に強いし、本格的に学ばないと駄目ですね。
論理型言語といえば、P#とかProlog.NETなんて言語もありました。
マイクロソフトもErlangの様な言語を作ってほしいな♪

中の人の徒然草366

おはピヨ♪今日も情報処理技術を啄ばんでいるインドリです♪
今朝ふと思ったのですが、なんだか書き足りないです。
このブログも、基礎中の基礎しか書いていません。
CodeZineでもそれは同じです。
書きたい事は山ほどあるのですが、基礎を飛ばすわけにはいきません。
かといって、もっとディープな内容を書きたいのですが、ディープなものは読者も少なそうだし、ブログに書くにしても時間がない。
並列処理一つにしても、基礎中の基礎しか書いていませんので、非常に物足りない。
さて、どうしたものか・・・
悩んだ末に出した答えが、一歩々書くしかないという事です。
今のところ、このブログも情報量が圧倒的に少ないですが、書くしかないですね。
色々あって、やる気が失せていましたが、気を取り直して書いていきます。

基礎といえば、書くのが難しいです。
意外だと思う人もいるでしょうが、情報を絞るのが困難なのです。
情報処理技術は膨大で、おまけに全てがつながっています。
無制限に書くと、文章としては最悪の結果になります。
何も考えずに、自分の知っている事を書き連ねるのは、文章ではなく散文です。
ですから、対象を考えて情報を絞らなくてはなりません。
書き手としては、この対象がある程度多くなければなりません。
しかし、無制限にしてしまうと文章になりません。
このバランスが非常に難しい。
書き手が常識だと考えることでも、知らないという人が居たりします。
かといって、事前条件を少なくし過ぎると、それこそ「プログラミングとは何か」から書かないとならなくなります。
それに加えて、曲解や誤解をする人々もいます。
万人が曲解もしくは誤解出来ない文章を書ければいいのですが、私はその様な神がかり的な文章を見た事がありません。
特に専門的な文章では、読者対象を考え、省略するべき情報が必ずあります。
その省略した情報を分からないとか、理解しておらず曲解／誤解する人が居ますので、不可能といってもよいでしょう。
例えば、コンピュータプログラミングの概念・技法・モデルを万人が理解する事が出来るでしょうか？
必ず、分からないだとか、この本が嫌いだという人が居ると思います。
それは、情報の性質から考えて当たりまえの事です。
分からない人が悪いわけでも、著者が悪いのでもありません。
こういった技術的な文章には必ず、前提知識が要ります。
その部分で、著者が考える前提と、読者が考える前提にズレが生じるのは仕方がない事です。
これは永遠のテーマだと思います。
情報の伝達は奥が深いですね。

中の人の徒然草365

みんな、おはよう♪超実装主義のインドリです♪
たまに他人から、何故そこまで実装主義なのかと問われる事があります。
その答えは、ソースを読まないと分からない事が多々あるからです。
最近はなんだか、書類主義が横行して、マニュアルや専門書だけを読めばいいという考えが蔓延していると感じます。
しかし、マニュアルや専門書は、プログラムをそのまま書き写すものではないので、情報に抜けが必ず存在します。
その理由は、自分で文章を書いてみると分かると思いますが、プログラムの全てを文章で表現するのは、混乱を生むからです。それに、そのまま書き写すのであれば、書く意味がありません。
情報は多ければいいというものではありません。伝えたい相手によって、情報量をコントロールする必要があります。
ですから、オープンソースの場合、ソースを読めという事を意味しています。そして、製品では「実行して確かめよう」という事を意味しています。
また、実装しないと分からない事が沢山あります。世の中には、体験しないと分からない事があるのです。旅行雑誌を読んでも、旅行した事にはならないのと同じです。

車輪の再発明という言葉が有名です。その言葉から、実装を深く知る必要がないという人もいます。しかし、車輪の再発明は、車輪を知る必要がない事という事を意味していません。
オープンソースが提唱されている理由の一つとして、知識を伝える事が挙げられます。オープンソースにしているという事は、実装を知る必要性がある事を示していると考えるのが妥当でしょう。
そういった事から私は実装する事に拘ります。ただし、ソールだけを読むというのも、また間違いです。その作者の意図や、背景知識の理解が必要となります。
理論と実践ともに大切なのです。
良く学び、良く実装しよう！