2020年12月27日 (日)

ドスパラでRyzen 7 5800Xが購入できた

前回の記事「amazon.com で Ryzen 7 5800X が購入できない…」の続き。

相変わらず主要な通販サイトでRyzen 7 5800Xの在庫を確認しては嘆息する日々が続いていた私だったが、つい先ほど(日曜日の14時ころ)ドスパラの通販サイトを見に行くと、なんと在庫がある!

すかさずカートに入れ、マザボとクーラーも必要なので一緒に購入(ASRock B550 PG Velocitaと虎徹 MarkII)。明日届くそうだ。さすがドスパラ。素晴らしい。

で、せっかくだからまたブログに書くかと思い立ち、他のRyzen 5000の在庫状況も確認しておこうと思って検索すると… 在庫があるのはRyzen 5 5600Xだけ。5800Xは見慣れた「在庫切れ」に戻っていた。どうやら購入できたのは単なる偶然のギリギリセーフ状態だったらしい。「いやー、なんというラッキー」と思って、何とはなしに再び商品検索画面に戻ると、5600Xも在庫切れになっていた。

最初に5800Xをポチってからここまで約30分程度。昨夜は在庫切れだった5800X(夜10時ころに確認していた)が、いつから在庫ありになっていたのか知らないが、Ryzenの5000シリーズは本当に入荷するとすぐに売り切れてしまう状態が続いているのだと改めて実感したよ。

しかし、なぜこんなことになっているのだろう。AMDの予想を超えて売れまくってるってことなのか?それとも、そういう単純できれいな話ではない何かがあるのだろうか。

2020年12月15日 (火)

amazon.com で Ryzen 7 5800X が購入できない…

AMDが先月発売した新Ryzen (いわゆるZen3)。日本に限らず全世界的に品薄で、特に上位モデルはなかなか買えないようだ。私も 5800X が欲しいと思っているのだが、なかなか買えずにいる。

国内の主要サイトに加え、アメリカの amazon.com を毎日チェックする日が続いていたのだが、今日とつぜん amazon.com で 5800X が、ずっと「Out of Stock」(在庫切れ) だったものが「Available to ship in 1-2 days」(1~2日後に発送) になった。すかさず購入しようとしたのだが… 残念、エラーで買えなかった。

その画面がこちら (画像クリックで拡大)。


Amazon1

実はたまに amazon.com で買い物をしているのだが、こういう表示は見たことがない。いわゆる「おま国」っぽいことを言われているように見える。でも、検索結果では


Amazon2

のように「Ship to Japan」(日本へ発送) と言っているし、商品説明も

Amazon3

となっていて、日本で個人輸入した際の税金なんかも教えてくれて、日本に発送する気マンマンに見える。

そもそも、日本に発送できない商品の場合は、この画面で警告が出るのだ。普通は。

Amazon4

(ちなみに、ボタン電池は「爆発の危険がある」ということで、飛行機に積めない決まりなのだそうだ。これは日本でもそう。)

うーむ。なぜ買えないのだ、Ryzen。

2020年8月19日 (水)

お上手ですこと

「お上手ですこと。」というセリフを見ると、僕にはその話者が「女性」「上流・上品」であるように聞こえる。この後に笑い声が続くなら、間違いなく「オホホ」だ。「ハハハ」とか「エヘヘ」ではない。「ガハハ」なんてありえない。(いや、ジャイアンが「お上手ですこと ガハハ」ならアリかもしれない。笑いを誘う意図的なギャップだ。)

このニュアンスを作り出しているのは「お」と「こと」だと思う。「お」は「丁寧語」や「美化語」を作る接頭辞で、過剰な使用が話題になったりすることもあり、素性が良く知られていると思う。では「こと」の方は何か?

辞書をいくつか調べたが、僕が見た国語辞典は例外なく「終助詞」としている。解説や意味の説明はいろいろだが、感動を表す、断定を和らげる、相手に同意を求める、といった働きがあり、新明解などいくつかの辞書は「主として女性語」という感じの注記を加えている。文法情報を掲載している辞書は「用言の終止形に接続」としている。(他の接続を併記している辞書もあるが、終止形接続はすべての辞書が挙げている。)

ところが、

これを MeCab-UniDic で解析すると、「こと」が名詞になってしまう。「名詞 / 普通名詞 / 一般 / *」だ。それに合わせて「です」は連体形と判定される。「です」の連体形というのは、普通は「普通の名詞の前には立たない。用言の連体形に接続する助詞(例えば準体助詞「の」)の前のみ。」ということになっているような気がする。つまり、解析結果がおかしい。

なぜそうなるのかと思っていろいろ調べたら、なんと、UniDic には「こと」という終助詞が登録されていないのだった。

surface が「こと」である語は四つあり、うち三つは「名詞」。残る一つは「副詞」だが… 副詞の「こと」って何だろう?

まさか国語研は「お上手ですこと」を含む言語資料を持っていないのかと一瞬思ったりしたが、さすがにそんなことはなかった。BCCWJ の「少納言」というシステム(https://shonagon.ninjal.ac.jp/ )でコーパスを検索してみたら、「お上手ですこと」は2件見つかった。どちらも小説で、セリフのようだった。つまり、UniDic を作った人たちは「お上手ですこと」という「こと」の用例を知った上で「終助詞『こと』」を語彙表に登録しないと判断したように思われる。つまり、この文の最後の部分は、終助詞「こと」ではない、何か別の品詞と見なすのが妥当と判断したらしい。さすがに「ます」の連体形+名詞「こと」が妥当な解析とは思えないので、UniDic の基となったBCCWJの解析テクストを見てみたいが、そのデータは一般公開されていないのだった。

ま、僕としては「こと」自体はなんでも良くて、その前の「です」が「終止形」と判定されて欲しいだけなのだが、「こと」が名詞のままではそういう解析結果になるはずもなく。かと言って、「終助詞」なんていう機能語を、十分なコーパスもなしにユーザー辞書に新規登録するのは避けたいし。

どうしよう。困った…。

# 因みに、困っているのはこの件です。

2020年7月 5日 (日)

Github は危害を加える可能性があるサイト?

Windows の「標準」ウェブブラザー Edge がアップデートされ、「検索エンジン」の設定がリセットされて Microsoft の検索エンジン Bing で検索するようになってしまった。

それで、いつものように単に github と入力して、当然一番上に表示される github.com にアクセスしようと思ったら「警告」が出た。

Bing

Microsoft によると、どうやら github というのは「デバイスに危害を加える可能性がある悪意のあるソフトウェアがダウンロードされる可能性がある」サイトらしい。

どうしてそうなった?

2020年5月12日 (火)

Excel VBA でウィンドウ枠の固定位置を調べる

Excel の VBA(Visual Basic for Application; 要は Excel 用のマクロ言語)で、「ウィンドウ枠の固定」がしてあるワークシートの、固定位置を調べたくて、方法をウェブで調べた。


だが、見つからない。


しかたがないから MSDN の Excel object model を読みまくって自分で書いた。こんな感じで固定位置(ウィンドウ枠の固定を行った際に固定の基準にしたセル)を調べることができる。


Sub Macro1()
    Dim r As Long, c As Long, i As Integer
    With ActiveWindow
        r = .ScrollRow
        c = .ScrollColumn
        For i = 1 To .Panes.Count
            With .Panes(i)
                r = Min(r, .ScrollRow + .VisibleRange.Rows.Count)
                c = Min(c, .ScrollColumn + .VisibleRange.Columns.Count)
            End With
        Next i
    End With
   
    MsgBox Cells(r, c).Address(False, False)
End Sub


Function Min(x As Long, y As Long)
    If (x < y) Then
        Min = x
    Else
        Min = y
    End If
End Function

※ 上では Min という関数を定義して Macro1 の中で使っているが、もちろんこれはベタ書きしてもいい。


ただし注意点がある。Excel には freeze panes(日本語版では「ウィンドウ枠の固定」)という機能と split panes (日本語版では単に「分割」)という似ているが少し違う機能がある。上のマクロで使っているプロパティは両者の兼用なので、「ウィンドウ枠の固定」ではなく「分割」を行っている場合には誤動作してしまう。本来はあらかじめ ActiveWindow.Split の値を調べて、これが true だったら(true は「分割」が行われていることを示す)「ウィンドウ枠の固定」は行われていないとみなして一律に A1 にするとか、そういう配慮が必要だろう。


ちなみに、最初に解法を探した中で最も参考になったのは「インストラクターのネタ帳」のこのページの記事だった。実はこのサイトにはよくお世話になっている。大変充実したサイトだ。インストラクターのネタ帳に「いつでも正しい結果となるわけではありません 」という注意書き付きの不完全なマクロしかないのを見つけたときには、VBA できちんと調べることは不可能なのかと思って目の前が真っ暗になった…。




ということで、VBAの体で記事にしたが、本当のことを言うと、今回私はVBAでマクロを書いているわけではない。そもそも VBA なんて滅多に書かない。NetOfficeを使うC#のコードを書いているのだ。ExcelやWordのVBA用のオブジェクトモデルというのは COM でできていて、Office PIAとかNetOfficeというのはその COM オブジェクトを CLI から使うラッパーだから、使い方も VBA とほとんど同じ。Office PIA や NetOffice の情報に比べると、VBA の情報の方が圧倒的に多いので、困ったときには NetOffice の情報を探すよりも VBA の情報を探す方が良い情報が見つかりやすいのだ。それで、VBA を使うわけでもないのに「インストラクターのネタ帳」にいつもお世話になっている次第だ。

2020年4月 2日 (木)

LibreOffice を C# アプリから操作

LibreOffice (昔 OpenOffice.org と呼ばれていたオープンソースのオフィスソフト) には UNO と称する API があり、C++ や Java からリモーティングのようなことができるという話は、なんとなく知っていた。

ところが昨日、この UNO という仕組みには CLI バインディングも存在するという話を聞いた。CLI ってことは、C# から使えるってことだ。LibreOffice で Office PIA とか NetOffice みたいなことができると非常に助かる。

で、さっそく調べ始めたのだが、なんというか、CLI/C# は相手にされてないっていうか、情報がほとんど何もない。公式のC#のサンプルソースが、コメントが Javadoc で書いてあったり、ビルド環境が .mk だけだったり、いろいろ厳しい。それなりに調べまくっているのだが、まだサンプルのビルドすらできない。

今回は、とりあえずリンク集だけ。

  • https://api.libreoffice.org/
    • LibreOffice の API に関する本家のページだが、基本 C++ と Java の話ばかり。
    • よく見ると C# のサンプルプログラムが 1 本だけあるが、そのコメントが Javadoc で書いてあるのだった…。
  • https://wiki.openoffice.org/wiki/Documentation/DevGuide/ProUNO/CLI/CLI_Language_Binding
    • OpenOffice 3.0 の話が最新情報として追記されていたり、実行環境が .NET Framework 1.1 だったりするのでかなり古い情報なのだが、どうやらこのページが一番基本的な話がまとまっているような気がする。
  • https://vdlz.xyz/Csharp/Porpose/Office/LIbreOffice/LibreOfficeCSharp.html
    • 僕が今日の昼までに見つけることのできたページの中で一番詳しい。しかも日本語。やったね!
    • "CLI" を「C#でLibre Officeを扱う仕組み」と断言したり、イントロでいきなり「Libra OfficeをC#で操作するためのドキュメントは、全く無いわけではありません。」と言って見せたりする辺りで期待感が高まる。😃

ちゃんと使い物にできたらいいなあ。

2019年2月 1日 (金)

ハードディスクも速くなっているが進歩は遅いようだ

最近はハードディスクも速いんだねぇ」などという記事を書いてから6年経った。だから、という訳では全くないのだが、今日、仕事の帰りに秋葉原に行ってハードディスクを買ってきた。

Seagate のバラクーダ 8TB。「プラッター2TBになって超高速」などと宣伝しているやつだ。

で、さっそく CrystalDiskMark を動かしてみた。

Seagate_8t_diskmark 確かに速いが、当然ながら現代の最新SSDと比べるとシーケンシャルアクセスでも20分の1くらいの性能しか出ていない。また、6年前の東芝3TBハードディスクと比べると10%増しくらいになっているが、それだけだ。その間にSSDのアクセス性能は5倍くらいになっている。

ということで、3.5インチハードディスクも速くなってはいるが、その性能向上の速度はSSDにかなわない。とは言え、ハードディスクが絶滅して完全にSSDに置き換わる日もなかなか来ない。どうしてなんだろう。そういう意味では、ハードディスクの中でも、2.5インチや1.8インチが3.5インチを駆逐しているという感じは全然しない。そもそも1.8インチは2.5インチの脅威になる前に絶滅してしまったような気がする。これもどうしてなのかよくわからない。クリステンセンはどう説明しているのだろうか。

※ なお、6年前とは CrystalDiskMark も変化していて、画面表示の内容が変わっています。6年前の CrystalDiskMark と比較の際にはご注意ください。

2018年7月15日 (日)

「無限ループが発生してもハングアップしません」

最近、Unreal Engine の勉強を(少しだけ)していて、今日は「UE4 ブループリント超入門編」を読んだ。今までブループリントというのは、ゲームに必要になる典型的な処理だけをビジュアルにプログラムできるシステムだと思っていたので、基本機能が一通りそろっていて万能なのだという話は目からうろこだった。

それはともかく、この記事の最後の方にこう書いてある。

ちなみにブループリントは優秀なことに無限ループが発生してもなんとハングアップしません。かわりに無限ループが発生したと判断すればエラーになってエディターに戻ってきますので、安心して実行できますのでご安心ください。

ぱっと見、「止まらないコードはすべて検出してエラーにする」と言っているように見えるが、ブループリントが万能である以上、もちろんそんなことは不可能だ。そこで、実際に無限ループするブループリントを作って試してみた。いや、停止問題とかそういう高級なヤツじゃなくて、ばかみたいなやつ。

Infiniteloop

元記事にならって疑似コードで書けばこんな感じだ。

EventBeginPlay()
{
    while (true)
    {
        PrintString("Iterating...");
    }
    PrintString("Done.");
}

これをコンパイルすると…コンパイルできてしまう。VisualStudioだってコンパイル時にエラーを出す(「無限ループ」とは言わず、「while の後ろの PrintString に至るコードパスが存在しない」とかなんとか言うんだったと思うが)くらいの単純な例なのだが。コンパイルできたので動かしてみると、一瞬画面いっぱいにIterating...が並んで、エラーで止まった。Infinite Loop detected と言っている。なるほど、確かに実行時検出はできているようだ。だが停止問題は実行時にも検出できないはずだし、そもそも1周目では検出できないのに何周か動いたところで検出できるというのも奇妙だ。どういう風に検出しているのだろうか。いろいろ調べたところ、どうやらブループリントでは、「コードの同じ個所を100万回実行したら無限ループとみなして止める」という感じのことをやっているらしい。

なるほど。それならできる。お手軽でナンチャッテ的な手法だが、1フレーム時間(約17ms)を超えて動き続けるコードが(「無限」ループであろうとなかろうと)許されないゲームのスクリプトとしては、非常に実用的なデバッグ法なのだろう。これもまた目からうろこだった。

2018年5月13日 (日)

Wraith PrismクーラーのLED配線と制御

連休中にRyzen 7 2700xを買ったのだが、これにバンドルされているWraith Prismと称するクーラーにはLEDがたくさんついている。それはいいのだが、LEDを制御するための配線でハマったのでメモしておく。
 
このクーラー、ファンを回転させるためのケーブルに加え、LEDを制御するためのケーブルが2本も出ている。箱から出した時点ではコネクターがあり、ゴムのフタがかぶせてあるが、専用ケーブルが2本ついている。以下の画像は4Gamer.netの記事にあったものだが、両方刺すとこんな感じになる。(画像クリックで拡大。)
012
 
これが、間違いの始まり。
 
実は、このLED制御ケーブルは両方刺してはいけないのだった。
クーラー側4ピン、マザボ側専用4ピンのケーブル(上の画像の左側)は配線しなくていい。クーラー側3ピン、マザボ側USB10ピンコネクターになっているケーブルだけ配線すればいいのだ。というか、私のように両方配線してしまうと、うまく発光をコントロールできなくなってしまう。
 
私が使っているマザボはAsRockのAB350M Pro4というものだが、その取説にもこんなイラストが入っていて、いかにも両方刺せと言っている。
Ab350mpro423
(もっとも、取説はよく読むと、「Please note that only one cable should be used at a time」と書いてあった。とは言え、ケーブルを3本示して「only one」と言い、実際には図示しているケーブルのうち2本を接続する、というのは、やはり適切な説明とは思えない。)
だったら、どうしてこんな使わない4ピンケーブルが付いてくるんだ、そもそも無ければ間違えないぞ、という話だが、どうやら、従来のRyzenを含む2700x以外にバンドルされているLEDクーラーは専用4ピンケーブルで制御するので、ある意味、それとの互換用なんじゃないかと思う。(よくわからない。)
 
次に、この「USB」のコネクターをどこに刺すか、ということなのだが、結論から言うと、普通に内蔵USBコネクターのどこかに刺せば良い。だが、AB350M Pro4には「AMD LED Fan USB Header」という名前の(シルクはUSB_5だが)ヘッダーがあり、取説もそこに刺せと言っている。それで、そこに刺すものだと思ってしまった。
 
これが2つ目の間違い。
 
いや、ここに刺してもいいのだが、ケーブルのコネクターはUSBの2列10ピンなのに、実際に配線されているのは3本。また、マザボ側はピンが1列4本。これをどういう風に指すのかがわからず間違えたのだ。
 
結局正解は、USB_5の1/2/3/4番ピンに、USBコネクターの10ピンで言うところの6/7/8/9/10が来るように刺すことだった。上のイラストは、正解がわかってから見ると、確かに正しい刺し方を示しているのだが、この図から正しい刺し方を読み取れなかったのだ。
 
以上が正しい配線で、こう配線した後は、AMDのウェブサイトから「AMD Ryzen Wraith Prism RGB lighting control software powered by Cooler Master」という長い名前のソフトをダウンロードしてインストールすれば、すべてのLEDを好きなように設定できる。
 
なお、このソフトを初めて起動したときに、ファームウェアのバージョンアップがあると言われ、そのアップデートをすることになった。どうも、このクーラーにはLEDを制御するためのマイコンが入っていて、そのファームウェアをUSBで書き込めるようになっているようだ。

2018年5月 4日 (金)

Ryzen アップグレード

約1年前にRyzen 1700でPCを組んだのだが、そのCPUだけRyzen 2700Xにアップグレード。
(ただし、マザーボードのBIOS(というか、UEFI?)は最新版にバージョンアップしてある。)
おおむね各種レビューの通り、クロックが速くなった分だけCPUの動作性能が上がったという感じ。AMDの発表によると、CPUの動作クロック以外にキャッシュレイテンシーの大幅改善みたいなことも書いてあるが、それが利いているのかいないのか、よくわからない。使っているメモリが、DDR4-2400というRyzen的には遅めのものということもあるのかもしれない。
 
 

«CancelEventArgs は Serializable じゃない