Windows だって、要するに cygwin とか擬似UNIX環境で仕事をするわけですから、 (g)awk って確実に存在しています（勿論 UNIXは言うに及ばずね）。で今回、

csv で出力されたデータのチェック

をしなければならないことになりました。２つの csv 出力が対応しているかどうか...のチェックです。勿論、

一方が他方に対して、その（複数フィールド・複数列の）合計とか

自明でない関係を持っていますから、それをチェックしないといけません。

以前、

コードジェネレータに bash を使うと、バッチリ使える

という話を書いたことがありますが、さすがにこっちは

フィールドで分解し、数値を扱う

ものなので、bash では力不足です。で...ですが、勿論 perl を入れて、Perl でチェックスクリプトを書くというのでもイイのですが、

そういう用途の「ドメイン固有言語」として、ちゃんと AWK があるじゃん。

ということを強調したいな...と思います。だって、

適当なセパレータ（この場合はcsvですからカンマ）でフィールドを切り分けて、それぞれの列で合算したり、行ごとに集計したり、切り上げ・切捨て・四捨五入...とか倍率を掛けたり割ったり....

という仕事のまさにそのために、昔から awk がUNIXには付いてきていたわけです。これ栄えあるベル研開発スクリプト言語ですしね（苦笑）。

A は Alfred Aho の「Ａ」
Wは Peter Weinberger （今Googleに居るそうです）の「Ｗ」
Ｋは Brian Kernighan の「Ｋ」

と、歴史....に思いを馳せるのもいいのでは？

実際入力をフィールドにバラして、合計したり...という仕事をさせるスクリプトは、AWK だと極めて簡潔です。

awk は汎用的なツールであって、汎用的な言語ではない

というあたりが一番のポイントではないか、と思います。あ、勿論 AWK は形式的な定義としてはチューリング完全な言語であることは承知の上ですが、

これだけCSVファイルのチェックのような特定分野で使いやすいのは、そりゃ特定用途に特化した「ドメイン固有言語」なんだからでね！

というあたりを強調したいわけです。ハッカーとそれ以外のプログラマの最大の差....って何かというと、私が一番しっくりする違いは、

新しい言語を憶えるコストが極めて低く、心理的な障壁がほとんどないのがハッカー

という違いを感じます。要するに「プログラミング言語上のマルチリンガル」であること、に馬鹿にならない大きなメリットがあるのです。つまり、「使っている言語を相対化して捉えることができるかどうか？」という能力なのではないのでしょうか。AWK には AWK の「良さ」があり、その「良さ」が最大に発揮できるタスクならば、ぜひとも awk を使おうよ...と、思いませんか？フツーにそこにあるんですしね！

あ、「音楽の著作権」じゃないですよ。「音」そのものの話です。

サウンドフォントについて少し調べていて、見つけたサイト（A-9氏）で、

以前、サウンドフォントは使うな！みたいな話をしたことがあって、
http://frontier.diarynote.jp/200707040806350000/

実際うちにもおそらくアレであろうフォントがいくつかあり、個人的に使う以外に使用を控えていたのだが、その後調べていたところ、

http://www.askaccs.ne.jp/xoops/modules/weblinks/viewcat.php?cid=18&sortid=5&page=2

著作権に関しては問題は無いと言うことだろうか

実際には外国でサンプリング音源がどうのこうのみたいな裁判もあったような気がするので、グレーと言えばグレーには違いないし、ちょっとサウンドフォントや音楽文化について疎いのかな？と思われる回答も怖いんですが、（他の質問を読んでいても、法解釈では正しくても裁判になったらどうだかわからんようなのが多い）とりあえずこの手の問題を扱うエライ団体さんの言うことなので、使うこと自体は問題ないと言うことでしょう。
もし訴えられたらこの人達に保護してもらおう

という話を見つけました。で、実際リンク先は、「社団法人　コンピュータソフトウェア著作権協会(ACCS)」という公益法人

ACCSは、コンピュータソフトウェアをはじめとしたデジタル著作物の著作権者の権利を保護すると共に、著作権の普及活動を行い、コンピュータ社会における文化の発展に寄与することを目的としています。

が運営している質問サイトです。その回答「c714 サウンドフォントの著作権について」によると、

音を曲にすれば、音楽の著作物の創作者として著作権法の保護を受けますが、最初にその曲をレコード盤や磁気テープ、CD-ROMなどの物に固定した人は、レコード製作者として著作隣接権により保護されます。この場合、音も一緒に隣接権で保護されますが、ドレミなどの音自体は、著作物ではないので、どんな楽器から抽出されたものでも、その音をもとに作曲するのは自由です。

...質問者は、売り物のサンプリングＣＤの音のフォーマットを変換してるモノとか、あるいは商品のハード音源・ソフト音源の音をそのままサンプルしてサウンドフォントにして配布しちゃう...というのは、感覚的には

限りなく、グレーゾーン（というか、すでに塀のあっち側？）

という雰囲気なんですけどね.....けど、

音自体は著作物ではない

んだそうです.....これ「音楽制作用に、さまざまなサンプリングＣＤ・音源が（かなり高い値段で）売られている」という現実から考えると、かなり理解に苦しみますね（業界が別なのかしら？）。サウンドフォントじゃない、字のフォントの方はちゃんと著作権で保護されているのは皆さんもご承知のことと思います（Linuxはこれで一時トラブりましたね...）。フォントに著作権があるのは感覚的に納得がいかないわけではないですが、しかし、同じ視覚的表現でも、「色」自体に著作権があるか...というとムリがあるでしょうが....

実際、著作権では「著作物の定義」を、

思想又は感情の創作的表現

とかなり狭く表現しています。音の本質は自然現象ですから、思想・感情をまったく表現しない「音」というのも現実的に存在しえます。そこらへん純粋に人間が作る記号表現である字体のフォントとは違う...といえば違うわけですし.....

まあ、著作権、という問題はかなりややこしい上に、ギョーカイからの圧力もあって政治ドロドロのあまり係わり合いになりたくない世界でもあるわけです。ふう、

法律家がすべての社会現象についての正確な理解ができる、というわけでもまったくない

のはまぎれもない事実ですし、イマという時代は、

事実が制度に完全に先行しちゃってる....

という意味では、正常な状態である、と言えるかもしれませんけどね（言い方イヂワルですみません....）。

カール・ケレーニイによれば、彼ら（プロテウスを含む）「海の老人」はポセイドン以前のギリシアの海の支配者であった。予言の能力を持つが、その力を使う事を好まないため、プロテウスの予言を聞くためには、捕まえて無理矢理聞き出さねばならない。しかし、他の物に変身する能力をも有するため、捕まえること自体が至難の技である(Wikipedia)。

というのがプロテウス、というギリシャの神なのですが、その名にちなんだ「Proteus VX」というソフトシンセが、無償で公開（去年８月）されました。SONAR を買った話は以前したわけですが、

う～ん、どうもプリセット音が気に入らない....音が薄く存在感がないし、使える音域が狭すぎる....

で、手持ちMIDIハード機材を動かしてハードディスク録音する始末です。ピアノでも sfz で使うサウンドフォントがまあまあだけど、アク強い音キャラで使いづらいタイプだし.....で、これじゃあ、

フルデスクトップ化するメリット、ないなぁ...

と落ち込んで、音源を買うことを検討しだしたわけですけども、そういえば...と思いついてコレを入れてみました。少しイジれば、SONAR の上からも VST 経由で立派なマルチティンバー音源として使えます。で、ですけど、

使える...

というのが好印象。音に個性が立っていて、イライラせずに済みそうです。あと、SONAR6 のオマケで付いていたソフト音源だと、

ピアノ系音色が少ない....しかも、低音だと歪んだヘンな音になる

という苦しさがありました。直接にはコレで困っていたのですが、Proteus VX だとかなり豊富なピアノ音色（２１音色）があり、低音が歪みも比較的マシな方です。とりあえず Proteus VX の音でとりあえずの実用は何とかなりそうなので、これで一安心、というところでしょうか。

まあ、問題は

あまりいろいろとイジれる余地はない（神話のプロテウスは変身の名人だそうですが、これは違う...）

というあたりと、リアル音系はそれでも弱いわけで、それは音源を買うことになりそうです....

ちなみに 2ch だとスレタイが

【神】「Proteus VX」がフリー化！【光臨】

だったりします.....(すごいスレタイだなぁ)。まあ賛否両論（あと不安定、特にVistaで問題）ではありますが、この手のスレでは

やたら辛い方がカッコイイ

というのを割り引いて考えれば、フリーでこの音質は革命的かもしれませんね。

ハマりました。けどこれ面白い話なのでご報告しましょう。ライブラリの使い方に関する意外な結果なんですよ。

Apache-Commons の PropertyUtils なんですけども、これ結構皆使うライブラリで有名ですよね。もともと Struts が出来たときに、Struts がガンガン reflection を使っていて、そこで作ったライブラリを Commons に別立てで寄付した...というのがこのライブラリの発祥ですから、実績も豊富で歴史も（相対的に）長いものの一つ、ということになります。（ここらへんの臭い話は、別な件でハマったことがあります...「一日２回 Strurs でハマった日」でもどうぞ）

この PropertyUtils に、copyProperties() というユーティリティメソッドがあります。要するに、

PropertyUtils.copyProperties(dest, src);

とやると、dest, src がどういうクラスか、は不問で、とにかく src のプロパティが dest のプロパティにコピーされちゃう...という便利なユーティリティです。

勿論これ、リフレクションを活用して、JavaBeans をコピーする、というのが仕事のユーティリティです。勿論これはこれで非常に有用なのですが、大人数で開発する場合にはちょっと問題がないわけではないのです。

それはですね、このメソッドが

JavaBeans の規約に基づいて、getter/setter を自動で探して、見つかった（利用可能な）setter/getter を使ってプロパティをコピーする

というのが正確な動作、だということです.....逆に言えば、

デフォルトのプロパティを「より便利に」するために、同じメンバにアクセスする「便利なバージョンの setter/getter」を誰かが作っちゃうと、copyProperties でコピーするときに、内部的には同じメンバーに複数回 setter が作用する可能性がある....

ということになるわけです。ですから、

setterが賢いことをしようとして、副作用を起こしてる！

とか、

setter がべき等に動作しない（add動作するとかね）

というケースで、copyProperties() は見つけづらいバグを作ることになります...

これが見つけづらいのはですね、バグ自体が「宣言的」だからかもしれません。手続き的にヘンなことが起きる...というよりも、

二重に宣言されているメソッドがあること

が原因だからです。まあ、これは

copyProperties() を使うよりも、愚直にコピー対象を copy() するメソッドを作る

というのがベストの解法でしょう。便利だから、とついつい使うユーティリティですが、落とし穴はあるものです。

あるいは、第３引数追加で、

copyPropeties(Object dst, Object src, Class baseClass);

なんてあったら便利かも....一応Javaリフレクションの規約では、「このクラスで定義されているメソッド」を取得するのが本筋なので、こっちの「baseClassで定義されたメソッド限定でコピーする」というのがあれば、特に O/R マッピングを使うケースでより使いやすいかもしれません、O/Rマッピングで一般的な GenerationGap パターンとの合せ技になりますね....

というのはですね、私が使ってるサーバで事故があって、いろいろとサイトを再構築していたのですが、私のことですから、

自分が Perl で書いた古い CGI が大量にあって....

というわけで、完全復旧なんてできないかも？ともなってます。で、古いＣＧＩを復旧するためには、当然、

CPAN からライブラリを取ってきて、入れなおす

ことが必要になります。結構盛んにCPANライブラリを使って書いてましたからね....で、です。そこで気がつくのですが、

あれ....CPAN ライブラリのバージョン更新があまり進んでない.....

ということなんですね。たとえば、用途から考えて、現役でちゃんとメンテされているに決まっている XML::RSS あたりを基準に考えると、

 2009年：２、2008年：８、2007年：１、2006年：４

というくらいの更新があります（要するについさっきも更新があった、くらいの頻度）。それに対して、XML:RSS が要求する XMLパッケージの基盤ライブラリである XML::Parser で、最終更新が 2007年１１月ですし、SHA アルゴリズムを使うメッセージダイジェスタ実装の Digest::SHA だと、

2008年：２、2007年：１、2006年：８、2005年：４

と、2006年くらいにピークがある、という格好になっています。

一番盛んに私がいろいろPerlで書いていたのは、世紀末から３年くらい前（1998年くらい～2005年くらいまで）で、当時 Perl も CPAN で盛んにいろいろなライブラリが開発されていました。しかし、その頃から比較して、あまり CPAN ライブラリの「状態」が変わってないのです。まあ、勿論全部調べたわけではない（デフォルトでパッケージに入るLWPなんかは勿論今でも盛んに更新されてます）ですし、印象に過ぎない、といえばその通りですが、

Perl(CPAN)に対する注目が、このところ相対的に低下している

のが数字で出てきているように感じます。まあ、それもそうかもしれませんね。さすがにもう Perl という言語は古くなってきています。「簡単に動的コンテンツを実現したい！」という初心者が Perl を勉強する...ということなんて、あまり考えられない時代ですし（PHPかRubyあたりでしょうね）。

まあ、考えてみれば、Perl はそもそもちょっとしたニッチ言語として、強力な (g)awk くらいのノリから出発して、Webアプリ言語という新興市場で強烈なシェアを獲得した言語だった...という印象がありますが、それにはそれなりの訳があって、いろいろと先進的な働きをしたインタプリタ言語環境でした。

1. 1. webアプリ言語に不可欠な、正規表現を扱う機能を十分に装備。これで正規表現を憶えたプログラマは多いのでは？と推測されるくらいに、「正規表現による照合・置換」を主の操作とするタイプのプログラムに向いていた言語だった。→イマドキ正規表現の使えない言語なんて....
2. 2. インタプリタであるにも関わらず、まず内部的にバイトコンパイルを行って、できたバイトコードを実行する、という２段構えの動作をするために、コンパイラとインタプリタのいいとこどりができた。→これは後続のインタプリタが皆採用しましたね。
3. 3. ユーザライブラリを交換し合うための検索・保管場所として、CPAN が作られた。→PHP(PEAR/PECL)、Python(PyPI)、Ruby(RAA)といった具合にこれも真似られましたね。

とはいえ、

1. 1. 言語仕様が汚い。厳格にはサブルーチンの「引数」という概念がないし、変数はすべてグローバルで特に宣言した場合だけローカルになる...というあたりの仕様は、そりゃインタプリタの実装は楽チンだろうけども、美意識（とミスしにくさ）には欠けるよね。
2. 2. 後付けのオブジェクト指向。何かヘンテコなやり方です...神の祝福が要る（bless）わけですが、「神の祝福」って何だろ？
3. 3. 5.8（2002年） でマルチエンコーディングに（実質上Unicodeに）ようやく対応。これはタイミング的にはちょっと遅れを取った感が否定できなかったです....

という負の資産もてんこ盛り（だって出発が超古いんだもん。1987年だよ...Javaよりかなり年上だ、ということをお忘れなく）なことは、もうどうしようもないわけですしね....

そりゃ Perl6、という話もないわけではないのですが、これだけＣＧＩ（そりゃMovableTypeだって...）が書かれちゃうと、下手すれば

Perl6 は登場（そりゃ現在でも Haskell で実装された Pugs はありますが...）しても全然普及せずに、Perl5 だけ「レガシー資産」扱いで細々とメンテされる

状態になる可能性も否定しきれないようにも感じます（そりゃCOBOLやFORTRANだってまだ現役言語には違いない！）。

仕方ない、とはいえ私は少しだけおセンチ状態、かもしれません....

は、大嘘です。昨日社内で、そんな話題（勿論正解の「大嘘」の方）で話していた方がいました...

昔話ですが、Linux がようやく普及しだした頃、

検証のため、強引に Linux で感染・繁殖するウィルスを書いた！

人がいる....という話を確か「Linux Japan」で読んだ記憶があります（1996年くらいだっけ？）から、世の中には、

ウィルスを書く、そこにＯＳがあるからだ！

という人のタネは尽きないようです（苦笑。被害目的である・なしは問いませんけどね）....当然マイナーなだけで、今もいろいろ存在しています。まあ、ここでは狭義のウィルスについて考えてみましょう。セキュリティホールをいじって感染するものではなくて、一番オーソドックスで防ぎようのない、実行ファイル感染型ですね。原理的に考えてみれば、

ウィルス（自己複製プログラム）が書けること ＝ チューリング機械と同等（万能機械を作れる）

ということでもあるわけですから、「原理的にウィルスが書けないコンピュータは、コンピュータではない！」という逆説もまた、成立するわけです（ま、コンパイラがプログラム出力を受け取れない太古の昔のＯＳ・言語ペアはともかくね）。

とはいえ、勿論

ウィルスが被害を及ぼしやすいＯＳかそうでないか

という問題はまったく別です。Linux など UNIX 環境は、「被害を及ぼしにくいタイプのＯＳ」であることは言うまでもありません。要するに、

1. 1. ユーザのウィルスプログラムの実行時の特権で、実行ファイル・システム設定ファイルを書きかえることがフツーはできない。勿論 root でプログラムを実行する趣味がある管理者は、このメリットが受けれないですよ！
   
   
2. 2. 明示的に実行パーミッションを立てるか、明示的にインタプリタに引数で渡さない限り、スクリプトの実行さえできない。だからメールウィルスが実行される可能性が低いし、また、文化的に「開いただけ、あるいはクリックしただけで非明示に実行する」ことに抵抗感がある傾向も強い。
   
   
3. 3. 基本的にソフトのバイナリディストリビューションよりも、ソースによるディストリビューションが正道（少なくとも私は今でもそう思ってますよ）と捉えられている。だから、ウィルスを含ませるためにソースに一目で判る不審なコードを書き込まなければ、まともに作成・配布できない。だから、「人目の多いオープンソース開発＋ソースから自分でコンパイル・インストール」という組み合わせはかなり安全。
   

というあたりが原因で、「Linux のウィルス」は珍しい...ということにもなるわけです。

しかし、Linux のサーバを運用するときには、やはり

そのサーバが提供するコンテンツに、Windows で感染する Windows ウィルスが含まれる...

というのは避けたいです（信用問題...です）。そのために、

Linux で実行される、その他ＯＳ用のウィルスチェッカー

というソフトも今いろいろあります。ですから、

Linux、だってウィルス問題とは、決して無縁じゃない

というのが、正しい立場なんですよね。

三題話です。Arduino や Gainer がオープンソース・ハードウェアだということから、以前も少し触れましたが、

モノとオープンソース

という微妙な関係についてちょっと考えてみましょう。オープンソース・ハードウエアとは、

情報ではなくて、ちゃんと現実世界のモノとして存在するモノで、それがオープンソースに基づいている

という状態にあるモノの話ですね。現実世界のモノには所有権という権利があるわけで、所有権が比較的あいまいな情報の領域とは

世界が違う

わけです。ですから、オープンソース・ハードウェアの場合は、

設計がオープンソースだけど、材料を用意して作る人は、当然材料の所有権を保持するわけで、出来たものは作った人のモノ

ということになります。ＯＫ？

ですから、「設計という情報」がオープンかそうでないか、がポイントです。逆に言えば、設計という情報を囲い込むことで利益を上げる...という企業は、

現実的に、情報のコントロールで利益を上げるわけだから、一種の「情報」産業？

という見方もできないわけではないでしょう。そういう意味で見ると、

ＡＲＭは

ＣＰＵの設計を著作権として囲い込んで、その製造パテントを売って、利益を上げ

ディズニーは

キャラクターのデザインを著作権で囲い込むことで、そのデザインの利用について課金して利益を上げ、

コカコーラは

そのレシピを秘密にすることで、コーラの重量としては、ごくわずかの原液を供給することで、利益を上げ、

というように、ＣＰＵメーカーであるＡＲＭはともかくとして、一般に「情報産業」とは呼ばれない企業も、

オープンソース・ハードウェアがあったら、ビジネスモデル的に競合するかも

という逆照射された見方で、「情報産業」と見ることができるのでは...とも思います。ですから、逆に

オープンソースのＣＰＵ

として、OpenSPARC とか

オープンソースのコーラ

として、オープンコーラとか（若干これ皮肉ですけどね）

オープンソースのキャラクター

というと、Linux のマスコット Tux とか Java のマスコット Duke とか。Tux はぬいぐるみを作るのならば型紙をＧＰＬで提供してくれるそうです。Tux や Duke がミッキーの代用になる...かどうかは別、ですけどね（苦笑）

というように、オープンソースなハードウェアのための基盤がいろいろと実験されている...ということにもなっているわけです。ソフトウェアの世界をオープンソースが変えたように、

ハードウェアの世界も、オープンソースが到来？

なのかもしれませんよ？

 

ってご存知でしょうか？　コトバのニュアンスで言うと、

Java の規格や仕様について、あーだこーだと小うるさいことを囀る人々

みたい（マジに苦笑、私か？）ですが.....偶然知ったのですが、実は Java Sparrow というのは、

文鳥さん

のことでした。要するに、

Java 島原産の、スズメの仲間の鳥（英名）

が偶然、江戸時代から愛玩鳥として飼われている、ペットとしておなじみの鳥なんですね。ちょっとしたJava ハッカーの（自虐or）皮肉のネタに使えそうな気も...

（偶然、は実は私今市子ファンでして....でも文鳥ネタは今まで敬遠＆出版社倒産で手に入りにくい、で読んでなかったのですが、ついに新刊「文鳥様と私９」を購入してそのついでのザツガクです。今市子がプログラミング関連のネタになる、とは思いもよりませんでした）

新聞を見ていたら、こんな記事がありました。

 衆院選：候補者の政策指向、自・民が混在　アンケート分析

 別に内容はどうでもいいです。ここで使われた統計手法なのですが、クラスター分析なのですね。クラスター分析とは、この記事の【ことば】の解説ですと、

【ことば】▽クラスター分析▽　複数の個体間の類似度を数値化、近いものを集めてクラスター（集団）を作る統計的分析手法。消費者が品物を選ぶ際に何を重視するかを調査し、分類した集団の特徴に応じて商品開発や販売に役立てるマーケティングに有効なほか、検査値に基づく疾患分類などさまざまな分野で活用されている。今回は立候補予定者について、２１問を均等にとらえたうえで、所属政党を超えて考え方の近い集団の形成を試みた。類似度の制約をゆるめることで集団は順次減らすことができるが、集団数が減るほどそれぞれの特徴は薄れる。

というものです。これは結構大昔からある統計手法で、私も卒論で使ったりした懐かしい思い出がありますし、この間知り合いの卒論での調査に協力したときにも使われてて、ついつい懐かしくて

中身、だけではなくて手法で話がはずんじゃう

なんてことになりました（苦笑）。心理学とか専門の分野ではよく使われますが、s新聞のような一般向けの記事で「クラスター分析とは」なんて出ていて少し「へえ」となっちゃったのですね。

とはいえ、これ結構使いでのある技法です。統計手法とはいえ、

差が有意かどうか

を検定するものではなくて、

与えられたデータから、何かの知見を得る

という因子分析と同じような発見的な統計技法のひとつです。ですから、新聞の調査では、

各立候補者の主張する政策の類似性によって、立候補者のグループ分けをする

というかたちで、「新しい知見」を得ているわけです（ホントはクラスター分析だと融合水準のデンドログラム（樹状図）を見せてくれた方が判りやすいのですが...）。

実は去年の話題の書である、「集合知プログラミング」でも、このクラスター分析が紹介されていて、やはりこの本だと話題は

ブログを単語ごとに分解して、いろいろなブログの間での類似性を評価する

のに使われていたりしたわけです。まあ、こういう「使い方」があの本らしいところですが、それだけではなくて、結構クラスター分析っていろいろな応用があるようにも思います。ここらへん、

プログラマの教養、かつ隠し技としてイケてるテクニック

だと思いますからオススメです。勉強してみたらいかが？

 

明けましておめでとうございます。本年もよろしくお願いします。

さてお正月企画です。初夢話ですね。

世の中には「スーパーコンピュータ」というモノがあったりしますが、「スーパー」よりも凄い（スゴそうな）

ハイパーコンピュータ

という概念があったりします。残念ながらハイパーコンピュータは現実に存在するコンピュータではなく、

計算理論の上で、存在するコンピュータが基礎とするチューリング機械のモデルで計算できない「計算」さえ計算できてしまうコンピュータ

で、理論上の存在です。たとえば、チューリングの停止問題に答えれてしまう「神託機械」はこういうハイパーコンピュータの１つです。ですから、これチューリング自身が「もし、自分が計算不能とした停止問題を、超越的に解決できたら？」という問うたことから、「計算理論上はある」ことになっているコンピュータなので、

絶対作ったりできない....

仮想の上での話です。以前「空にカードを放り投げて..」というエントリで考察したような、

ノンコストで実質上無限の数が平行で動く、完璧な非決定性チューリング機械

は作れる可能性は今のところかなり低い（まあ、量子コンピュータがそれに近いですけど）ですが、これだと

Ｐ≠ＮＰ　である

が証明できれば、ハイパーコンピュータになるかもしませんね（まだ未証明です。量子コンピュータはどうもチューリング機械に還元できそう...なので残念です）。

 固い概念の「ハイパーコンピュータ」は現実には存在しそうにもないのですが、こういう「ハイパーコンピュータ」なら現実に世の中に存在するみたいです。

フツーのスーパーコンピュータの、上位機種

まあ、宣伝文句によるインフレーションみたいなものですね。スパコン自体今はあまり魅力的ではないですから、どうでしょ。そういう用例

ＥＣＵの商品名

これ見つけたときには笑ってしまいました.....要するに、車のポルシェのエンジンコントロールユニットの、純正外のチューンアップ機材として、アイメックという会社が「ハイパーコンピュータ」というユニット（の俗称、みたいですが...）を出しているらしいです（苦笑）。要するに、エンジンを効率的に動かすために、ガソリンの混合比の調整とかタイミングの調整とか、

やはり今時の話で、マイクロコントローラで行う（まあ、イマドキの車はマイクロコントローラのカタマリだったりするわけで）

わけで、これだって立派なコンピュータだったりするわけです。「ハイパー」はいかにも吹っかけすぎですが、コンピュータであることだけは、間違いないですね。初笑いいかがでしょう？