スーパーマリオワンダーのリスポーンの特許と、ゼルダの伝説ToTKのスクラビルド(じゃなかったウルトラハンド)の特許

仕事がしんどすぎて久しぶりに任天堂の特許を検索したところスーパーマリオワンダーらしき特許が大量に出願されていたことに気づいた。

この2023年11月から12月にかけて出願された18件の特許は図面とかを見た感じスーパーマリオワンダーに関連する特許のようだった。一番上の2つはレンダリングに関係するものなので読みたいと思っている。ちょっと時間と気力がなくて全部チェックするのはすぐには無理。なので一番最初に見た特許について紹介しようと思う。他の特許もマルチプレイ関連が多いような気がする。

 

特開2023-169896(P2023-169896A) - 死んだあとのリスポーン位置を決める特許

https://www.j-platpat.inpit.go.jp/c1800/PU/JP-2023-169896/A3A009FAA3611A376237881353491653546A12F903EB012F0094BD5E17CB8B33/11/ja

【公開番号】特開2023-169896(P2023-169896A)
【公開日】令和5年11月30日(2023.11.30)
【発明の名称】ゲームプログラム、ゲームシステム、およびゲーム処理方法
【出願番号】特願2023-132926(P2023-132926)
【出願日】令和5年8月17日(2023.8.17)

【要約】
【課題】適切な位置にキャラクタを出現させることができるゲームプログラム、ゲームシステム、およびゲーム処理方法を提供すること。
【解決手段】ゲーム空間内の所定の位置を所定のキャラクタの出現予定位置として設定する。出現予定位置が、所定のキャラクタが出現可能な位置の場合は、当該位置にキャラクタを出現させる。一方、当該位置が、所定のキャラクタが出現できない位置の場合は、当該位置に探索中オブジェクトを配置し、所定のキャラクタが出現可能な位置に到達するまでの間、当該探索中オブジェクトをゲーム空間内で所定距離移動させて、当該移動後の位置において所定のキャラクタが出現可能か否かを判定する処理を繰り返す。そして、探索中オブジェクトが所定のキャラクタが出現可能な位置に到達すれば、当該位置に所定のキャラクタを出現させる。

 

これを見てスーパーマリオの特許だとは普通は思わないかもしれない。マリオの特許かどうかを素早く判定する方法は、図面を見ることだ。この特許には下記のような図面がある。これはマリオだ。

特開2023-169896の図4

さてしかしこの特許の課題とか解決手段とかを見てもあたりまえのことしか書いてないのである。「リスポーンできる場所ならすぐリスポーンするんだけど、そうじゃない場所だった場合には困るだろ? だからリスポーンできる位置まで仮のキャラを移動させてそこでリスポーンするんだよ」という。

ところでスーパーマリオワンダーにはマルチプレイ時の復活に関して下記のような説明がされていた。

ミスをすると「タマシイ」となってさまよい、カウントが0になる前に他のプレイヤーにふれることでその場で復活!

スーパーマリオブラザーズ ワンダー : マリオも仲間も一緒に冒険 | Nintendo Switch | 任天堂

 

この内容が請求項6に書かれていた。

【請求項6】
  前記所定のキャラクタは、プレイヤの操作に基づいて移動制御され、前記ゲーム空間内のオブジェクトとの衝突判定が行われ得るプレイヤキャラクタであり、
  前記プレイヤキャラクタが移動制御可能な状態で前記出現予定位置にプレイヤキャラクタを出現させる、請求項1に記載のゲームプログラム。

 

つまり、、この特許からの視点では、上記のタマシイのシステムは、ゲームを成立させるための制約としてのルールづけではなく、あくまで「その位置でリスポーンできるかどうかを判定するための一つの方法」として「タマシイをユーザーに操作させて他のキャラに衝突したとき、そこをリスポーン可能な位置(リスポーンしたあとにゲームが続行できる位置)と判定する」というような説明になっている感じである。

 

いや、確かに、単純に「他のキャラにぶつかるまで移動させないとリスポーンできないんだよ」ってのはなんか、それってゲームのルールですよね。特許じゃないですよねみたいな話になりそう。

でもだからってそれを、
「死んだ位置でリスポーンしたら無限に死ぬから、いい位置にリスポーンさせる方法が必要
 → そのリスポーン位置をプレイヤーに知らせるために、そこまで移動する間の仮のキャラを表示したりするんだよ
 → その仮のキャラをプレイヤーに操作させて他のプレイヤキャラに当たったら、そこはリスポーン可能位置と判定するのもそのうちの一つだよね」
みたいな流れで説明しているのは… このタマシイのシステムが、このゲームの開発中に本当にこういう流れで試行錯誤として生まれたのか、それとも特許として出願するために考え出されたロジックなのか、どっちなのか、自分は割と気になる。

 


 

特許7397237 - ゼルダの伝説ToTKのスクラビルドの特許

さて以前にToTKの特許がいっぱい出てたというエントリを書いていたのだけど、その時点では公開されていなかったスクラビルドウルトラハンドに関する特許が去年の12月に登録されていたようだった。それがこの特許73927237である。

https://www.j-platpat.inpit.go.jp/c1800/PU/JP-7397237/FF578A14C4ABCDE3EBEEEC7832A1FE5B4FCA31F362192A473C5A88996DEF3557/15/ja

【特許番号】特許第7397237号(P7397237)
【登録日】令和5年12月4日(2023.12.4)
【発行日】令和5年12月12日(2023.12.12)
【発明の名称】情報処理システム、情報処理プログラム、情報処理方法、および情報処理装置
【出願番号】特願2023-523122(P2023-523122)
【出願日】令和4年3月3日(2022.3.3)
【要約】
仮想オブジェクト同士を接続して複数の仮想オブジェクトからなるオブジェクトを生成する場合にユーザビリティを向上させることが可能な情報処理システムを提供する。情報処理システムの一例は、複数の仮想オブジェクトのうちの第1オブジェクトをユーザの選択操作によって選択し、選択した第1オブジェクト、及び、複数の仮想オブジェクトのうちの第2オブジェクトのそれぞれの接着位置を示す接着オブジェクトを生成する。ユーザの接着指示に応じて、第1オブジェクトと第2オブジェクトとをそれぞれの接着位置において接着する。

つまり、A,Bの2つをくっつけるような操作をやるときに、

  • ユーザはそのうちの1つだけを選択する(選択して操作する)
  • A,Bの接着位置を示す接着オブジェクトをつくって表示する

みたいなことがポイントだとしている。ここでの接着オブジェクトは、例えば下記の図16にある78で示されているものであり、これは自分も「これ特許で出願されそうだな」って思っていたところだった。

図16

特許明細書の文面には、この接着オブジェクトのことだけではなく、リンクが持ち上げて動かしている物体(明細書内では「選択オブジェクト」と書かれている)と他の物体との位置関係をわかりやすくするために、選択オブジェクトの像を他の物体に投影するとか、中心点を描画するとか、プレイヤーキャラの動きに合わせて選択オブジェクトがどう動くかとか、さらには、所定の解除条件を満たす入力がなされた場合には接着が解除されることなどが記載されている。

既にこの特許の分割で 特開2024-015493 が出願されている。これは「オブジェクトそれぞれに、他の箇所よりも優先的に接着位置となるような位置が設定されている」というものだ。

他の分割出願が今後どれだけ増えるのかは要ウオッチかもしれない。

 

(2024-02-05) id:sailorojiさんからスクラビルドじゃなくてウルトラハンドだと指摘を頂きました。指摘ありがとうございます。なぜ間違えたのだろう…

pythonのasyncioの勉強をしていました

あけましておめでとうございます。というエントリを書こうとしてたんだけどいいネタがなくてこのままでは2月になってしまうというところでなんでもいいから書こうとなっています。

httpでストリーミング的にデータを垂れ流してくるようなサーバがあってそこから適当にデータをダウンロードしつつ処理をしたい。できればpythonで、という相談を受けたのでasyncioってやつを使ってみたのをメモっときたいと思いました。

 

 

まず無限に応答を返すようなhttpサーバを建てる必要があった。

  • MacOSでは標準で搭載されているapacheを有効にしてcgiを動かした。このへんは他のWebサイトにもいくらでも載ってるので割愛である。/Library/WebServer/CGI-Executables/ にcgiスクリプトを入れたらアクセスできるようになる。
  • 下記の無限に数字が出力されつづけるinfinity.plを上記ディレクトリに配置した。IO::Handleを使ってautoflush(1)をしているところがポイントで、これをやらないとバッファリングされてしまってタイミングよくクライアントに応答が送られない感じになる。

    #!/opt/local/bin/perl                                                           

    use CGI;

    use IO::Handle;

     

    STDOUT->autoflush(1);

    my $q = new CGI;

    print $q->header();

    for (my $n = 0; ; $n++) {

        print "$n\n";

        sleep(1);

    }

  • ブラウザではよくわからないのでcurlで出力してみるとちゃんと1秒毎に数字が表示されて動いていた。

なんでperlなのか、pythonっていってたじゃんかと思われるかもしないが、それはこのへんは主題じゃないから。次が本番のpythonのクライアント

  • aiohttpってやつを使えば非同期でhttpのリクエストを出してレスポンスを受けとれる。

    import aiohttp

    import asyncio

     

    async def main() :

        async with aiohttp.ClientSession() as session:

            async with session.get('http://localhost/cgi-bin/test.pl') as resp:

                print(resp.status)

                print(await resp.text())

     

    asyncio.run(main());

    これはいろんなWebページに良く載ってるやつで、これをTaskにして複数個並列に実行させてスクレイピングをやるよみたいな例でよく出ている。でもこれだとresp.textをawaitしているので結局最後まで受信しないとテキストが出力されない。
  • 無限に応答を返しつづけるようなサーバに対しては、
    https://docs.aiohttp.org/en/stable/client_quickstart.html
    の、「Streaming Response Content」のセクションに解説があった。下記のコードで…つまりresp.text()とかではなくresp.content.read(20)で受けるとサーバから受信したタイミングで処理ができる。

    import aiohttp

    import asyncio

     

    async def main():

        async with aiohttp.ClientSession() as session:

            async with session.get('http://localhost/cgi-bin/infinity.pl') as resp:

                while (1):

                    print(await resp.content.read(20))

    asyncio.run(main())

  • read(20)でやってみたんだけど、これは
    https://docs.python.org/ja/3.6/library/asyncio-stream.html#asyncio.StreamReader
    のreadメソッドで引数は一度に読みとるbyte数だった。read(10000)にしても動作は変わらなかったので、受信したタイミングで受信する最大バイト数を指定しており、それより小さいデータしか受信できてなくても応答が返ってくるようだった。あたりまえだがこれをread(1)にすると1バイトずつしか取ってくれなかった。
  • 受信中に他の処理をしたい場合にはasyncioのcreate_taskを使う必要があるとのことだった。3秒経ったら止めるフラグを立てる下記のようなコードを作って確認した。

    import aiohttp

    import asyncio

     

    cont = True

    async def timeout(duration):

        await asyncio.sleep(duration)

        global cont

        cont = False

     

    async def connect():

        global cont

        async with aiohttp.ClientSession() as session:

            async with session.get('http://localhost/cgi-bin/infinity.pl') as resp:

                while (cont):

                    print(await resp.content.read(20))

     

     

    async def main():

        t1 = asyncio.create_task(connect())

        t2 = asyncio.create_task(timeout(3))

        await t1

        await t2

     

    asyncio.run(main())

  • 実際のところ「3秒だけ情報を取得する」みたいなのだったらもっと他にやりかたいっぱいあるだろという気がするがいろんなやりかたを試しておきたかった。
  • main()と、taskのawaitはわりと理解しづらい気がした。たとえば上のコードでは「await t2」は無くてもいい、いやむしろ無いほうが良いくらいなのだけど、そういうのはWebで出てきたサンプルをちょろちょろコピペして「やったー動いたー」ってやってるとわからない気がする。

ストリーミングを説明してくれているサイトでいいところがあるのかよくわからなかったので公式っぽいところを参考にしてみたんだけど動作するものはわりと簡単に作れた。一方でpythonのコルーチンとかスレッドのモデルは、asyncio.run(main())のところはわりと面白いなと思う一方で、いまいちまだ自分の中であまりちゃんと理解ができてない感じなのでもうちょっとがんばってドキュメント(https://docs.python.org/ja/3/library/asyncio-task.html#)とリファレンスを読んでいく必要がありそう。

2023年に見たアニメで好きなOP/EDたち

自分あんまり網羅的にアニメとか見てないのでもっといいのがきっとあるんだろうと思うのだけどこんだけ大量のアニメ番組を全部見てるやつとかすげー少ないだろうから自分が見たなかでいいなと思ったのを紹介するでもよいのかとも思う。

 

「お兄ちゃんはおしまい!」OP「アイデン貞貞メルトダウン

このアニメは話題になったと思うのだけどその半分くらいはこのOPのインパクトがあってのこそなのではないかという気がする。そういう意味ですごい。

 

TVアニメ『お兄ちゃんはおしまい!』“おにまい”OPムービー(ノンクレジット)/OPテーマ「アイデン貞貞メルトダウン」えなこ feat.P丸様。 - YouTube

 

下のカットとかちょっと意味不明だけど勢いがあってよかった。

 

「英雄王、武を極めるため転生す 〜そして、世界最強の見習い騎士♀〜」OP「セルフハグ・ビッグラヴ (Selfhug Biglove)」

【TVアニメ】『英雄王、武を極めるため転生す』ノンクレジットED|ゆいにしお「セルフハグ・ビッグラヴ」 - YouTube

おしゃれな感じでよかった

 

「推しの子」OP「アイドル」

これはここで紹介するまでもなく良かった。

【推しの子】ノンクレジットオープニング|YOASOBI「アイドル」 - YouTube

個人的には↓のカットがめちゃくちゃ好きだった。

「ワールドダイスター」OP「ワナビスタ!」ED「トゥ・オブ・アス」

TVアニメ「ワールドダイスター」ノンクレジットエンディング - YouTube

 TVアニメ「ワールドダイスター」ノンクレジットオープニング - YouTube

両方すごく好きな曲なのでアニメを見ようと思ったのだが自分にはちょっと難しかった。2話くらいまでしか見ることができなかった。

このOP/ED曲は良かったのだがOPもEDも映像はYouTubeを見てもわかるようにいまいちぱっとしなくて、どっちも映像なしで聴いてたほうがいいんじゃないかという気がしてしまった。

 

アイドルマスター シンデレラガールズ U149」ED「グッデイ・グッナイ」

【アニメ】「アイドルマスター シンデレラガールズ U149」第10話ノンクレジットエンディング「グッデイ・グッナイ」【アイドルマスター】 - YouTube

10話でこれが流れてきて「えっここでこんな新しい曲をつっこんでくるの凄くね?」と思ったが、本来これがメインのED曲でそれまでの話は全部特殊EDだということだった。11話も特殊EDだったのでこの曲が流れたのは結局2話だけだったし、どちらもライブシーン後に流れる曲になっているのでEDに派手なアニメがあるわけでもなかったけどめちゃくちゃ良かった。

 

「私の推しは悪役令嬢。」ED「O.C. 〜Optimum Combination〜」

【ノンクレジットED】TVアニメ『私の推しは悪役令嬢。』/ 「O.C. 〜Optimum Combination〜 Episode1 ver.」レイ(CV.芹澤優) - YouTube

これは好きなので見たいと思っているがまだ見れていない(最近忙しい)。OPの「レイジョアハンズ!! 〜Raise Y/Our Hands!!〜」も良かった。

 

ポーション頼みで生き延びます!」OP「tailwind」

TVアニメ「ポーション頼みで生き延びます!」ノンクレジットOP|katagiri「tailwind」 - YouTube

EDの「Love is a potion」もかわいい感じで良かった。

 

「でこぼこ魔女の親子事情」ED「Welcome!」

「Welcome!」|「でこぼこ魔女の親子事情」エンディング映像 - YouTube

低予算感があふれているのだけど一方でセンスがあって非常に良いEDだった。

EDだけじゃなくOPも、アニメ本編もそういう感じでセンスの良さしか感じなかった。2023年で一番おすすめのアニメはなんだったかと聞かれてこれを答えた。

 

「豚のレバーは加熱しろ」OP「私が笑う理由は」

アニメ『豚のレバーは加熱しろ』ノンクレジットオープニング|ASCA「私が笑う理由は」 - YouTube

どこがどうとはうまく言えないが良い曲なんだ。

 

聖女の魔力は万能です Season2」OP「Semisweet Afternoon」

TVアニメ『聖女の魔力は万能です Season2』 ノンクレジットオープニング映像|結城アイラ「Semisweet Afternoon」 - YouTube

ストリングスアレンジが良かった。

 

異世界転生モノ、アニメ本編はもうかなり食傷気味で見なくていいなと思っちゃうようなものが多いのにOPEDにいい曲が入ってくることが増えて困ってしまう1年だった。

今年買ったコンピュータたち

なんかいろいろあったんだけどいつものように今年買ったものを書く。

 

Apple MacBook Air (M1 late 2020)

今年1月、RAM8GB, SSD512GBのモデルの中古が税込96000円で売っていたのを発見し、1週間考えて、結果購入した。もともと持っていた、同じくRAM8GB, SSD512GBのearly 2020を売り払ったところ66000円くらいで売れたので、3万円でM1にリプレースできたということになる。

売り払ったearly 2020は10分使うとCPU(Core i5)の温度が100℃になってしまい、定格のクロックで動作しつづけることができないという、自分からしてみれば「これは不良品一歩手前じゃねーか」みたいな感じの機械だったのだけど、そんなことを気にしない人にとってはちゃんとしたMacBook Airなわけで、自分のようなやつに不機嫌になりながら使われつづけるよりも、たまにスタバでドヤ顔するために使われたほうが幸せなのでそうなってほしいなと思いました。

Apple M1の省電力性能と安定性はすばらしく、Euro Truck Simulator 2(ETS2)が1920x1200の解像度で快適に遊べてしまう。Core i5-1035NG7のMacBook Airでは描画品質をかなり下げて1408x880に落としたりしても発熱でプチフリが発生して(ゲーム内で)事故るみたいな状況が多発し、フルHD解像度にするなどはとても無理という感じだったが、このM1では1920x1200で描画品質をultraに設定してもわりと問題なく遊べてしまう。1035NG7はすぐに15Wくらい電力を喰っていたがM1は5Wでたいていのコトが済んでしまう。アイドル時も1035NG7は1W以上消費していたところM1は80mW未満だったりする。できることは殆ど同じなのになにかが根本的に違う。

 

 

Chuwi minibook X (N100)

minibook Xはキーボードがまともな配列なので興味があった。N100も、あのちょっと良かったGoldmont plusの子孫なので気になっていた。わりと期待通りだし可愛い製品ではあるのだが、キーボードのキータッチがかなり悪いのと、タッチパッドの操作性も悪く、なんだかんだ言って使うのがちょっと苦痛である。タッチパッドは押し込みを検知するための物理ボタンが残念ポイントではあるのだが、その他にタッチパッドを触ってから画面上のマウスポインタが動くまでに微妙に遅延があり、それが操作性の悪さに直結している。なんとかならないものか。

N100には期待していたがこの前にM1を見てしまっているせいでわりと微妙な評価になってしまう。全体的にN100はM1の半分以下の性能しかない。それでいてN100はM1よりも消費電力が大きい。そしてキーボードの出来がわるい。全体的に良さげなのに残念だ。もうちょっと軽ければ魅力的だったのにとか思わざるを得ない。

 

 

Minisforum UM790pro

Ryzen9 7940HS搭載のminiPC。不具合がある個体をつかんでしまった報告がある中で、自分に届いたものはあまり不具合がなさそうだった。

「イヤホン端子からの出力を聞いていると音の出始めのタイミングでブチ音が聞こえる」という不具合がどこかのサイトで書かれていたが、それは音声出力の電源を不要なときにOFFにしているからONにしたタイミングでブチ音が鳴ってしまうのであろうと思う。自分はこれはそういうものだと思っているのであまり気にならなかった。

USB PDからの給電で動作するとはあまり思ってなかったし、動作しなかったというブログもみかけたのだが、自分のものは65WのACアダプタとe-Markerいりのケーブルで繋いでみたらちゃんと起動した。65Wだと自動的にCPUパワーが抑制される感じで、意外にちゃんと動くので凄いと思った。

RAM 64GBのモデルを購入して「この半分も使うことは当面ないだろうな」と思っていたが、KritaのStable Diffusion Pluginを動かしてみたら32GBをGPUに使われて「使われることがあるとは…」とびっくりした。

買ってすぐにUM780XTXが発売されてちょっと凹んだりもしたけど同じくらいの価格でCPUがグレードダウンしてWindows Homeになっていることを考えればまあそこまで落胆するほどのことはないかな。

 

Xiaomi SmartBand 8

買って1ヶ月、2週間に1回充電するペースで毎日つけている。歩数の心拍数と睡眠時間がわかるだけだが、とくに睡眠時間がわかるのは意外に嬉しかった。mi band 4と違って充電が楽なのもよかった。簡単に着脱できるようにしたくて金属ベルトを買ってたんだけどPCを傷つけそうなので平日は最初に付属していたやつを使っている。

 


 

去年と一昨年はほとんどコンピュータ的なものを買わなかったのだけど(去年はpi400だけだった)、今年はたくさんコンピュータを買った。M1, Gracemont, Zen4と新しめのCPUコアを使えているのは良いことだ。そしてこの中ではGracecmontのN100がいまいちだった。次のCrestmontもあまりアーキテクチャ的には変わらないんだがチップ全体の構成やプロセスルールとかで化けるのかもしれない。

Xiaomi Smart Band 8を買っていました

11月22日、Amazonのなんたらセールで安くなっていたので買った。日本版を買ったつもりだったが後で見てみると「グローバル版(日本語対応)」というやつを買っていた。何か違いがあるのかどうかいろいろ調べてみたけどわからず。届いて手元にあるSmart Band 8のModel No.はM2239B1となっており、日本版の販売ページなどで書かれているBHR7165GLという型番とは明らかに違うのであるが、日本版のレビューブログなどに掲載されている箱や実機の裏面の写真にはM2239B1という型番が記されているので多分同じものなのだろうと思いたい。

 

 

band 7からプラットフォームが新しくなって画面のフレームレートが上がりその代わりLineの返信ができなくなったりしているという。自分は腕時計からLineの返信をやりたいなんてことは思わないので全く問題なかった。個人的には画面のフレームレートが40fps未満だとやはりチープ感があり、60fpsになるとちょっとちゃんとした機械だなという印象になるのでそこはとても大きい。

 

 

mi band 4を買ったのはもう4年近く前のことで、あれはあれで良かったんだけどちょっと放置してたら電池切れでpair first画面になってしまい、なぜかそこから再ペアリングすることがどうしてもできずに廃棄してしまった。当時のエントリを見ると結局歩数計としてしか使わなかったみたいなことが書かれていた。たぶんコロナのせい。

 

mi band 4のときは心拍数の自動計測をonにしていると電池の持ちが短かくなるかなにかで、そういう機能を使っていなかったようなのだが、今回は心拍モニタリングをonにしていても2週間以上電池が持つのでonにして使っている。見ていて楽しいので当時も電池の持ちなど気にせずonにしておけばよかったと思った。

 

 

200種類以上のウオッチフェイスが選べるという話で、中には簡単なゲームが遊べるものもある。しかしそういうものが用意されている一方でカレンダーが表示されるものがないのは何故なんだという気がした。操作をしない時計画面の表示のタイミングではあまり凝ったロジックを実装できないということなのかもしれないし(でもこれが理由ならタップしたらカレンダーが出るのは作れそうな気がする)、祝休日の表示のサポートが割とUIも含めて難しいというのがあるのかもしれない。

 

 

他の人にこのSmart Band 8のことを話すとGPSとかNFCが付いてないかを聞かれるのだけどどちらも個人的にはあまり必要性を感じていなくて、でも付いてたら楽しいのかな? わからん。

毎年このシリーズを買ってる人のレビューを見ると、自分がいいなと思った心拍や睡眠の測定などは5や6からずっと実用的だったみたいで、今回の8では照度計が付いたのが機能的には大きいらしい。いきなり8を買った自分のような人間にとっては、あたりまえのように照度計が付いていて何の問題もなく機能しているのが普通だと思ってしまったりしていたが、これは着実に進化を重ねてきた結果の賜物なのだった。

料理のレシピが特許になるのかどうか

ちょっとまえの特許のエントリに対して「ソフトウェアでここまで広範囲な特許や詳細な特許が認められ、料理レシピに特許がないのはアンバランス」「料理のようにアレンジで進化していく文化にならない」というようなコメントがあった。

 

結論としては料理のレシピのような特許はバンバン出願されているし登録もされている。業として実施しないことが前提だからレシピサイトでは誰も特許なんて気にしていないだけで、たとえばカレーを大規模に提供しようとした場合にハウス食品から訴えられてしまう可能性はわりとあるんじゃないか。レシピが進化していっているのは小規模に提供しているからであって特許制度は関係ないと思う。

 

続きを読む

Ryzen 9 7940HSのPCを買った

Minisforum UM790 Pro というPCを買った。忙しくてまだほとんど使っていない。いちおうCineBench R23をやってみたところベンチマーク通りの性能が出ているのでOKと思った。memtest86をやっておきたいような気はしている。

 

 

夏に
「N305のミニPCにリプレースするべきな気がしてきました」
と書いていた。
でもさすがに自分の最強のメインマシンとして使うのにN305はさすがにないなと考えていて、一方でIntelのP/EコアよりもZen4のほうがエレガントで魅力的でよいように思えた。そして7940HSでは統合GPUの世代が新しくなった。FP32で4.3TFLOPS、FP64で537MFLOPSが出せるらしい。30年前にスーパーコンピュータを知ったとき、世界最高のスパコンでも1TFLOPSに到達していなかった。この手のひらに載せることもできる130mm×126mmの機械に当時の世界最高以上の性能が入るというのだ。これは買うべきな気がした。

 

 

でも、いまのところ何をしていいのか全然思いつかない。これは
「ドリルを買う人が欲しいのは『穴』である」
とかいうのがちょっと嘘で、
「ドリルを買う人は穴が欲しいわけではなく、単純にドリルを所有したいだけの場合がある」
というやつに似ているなと思った。