  |
はてなキーワード:クラスタリングとは
昨夜、ヒートシンク 4SSD が到着しました。このヒートシンクがPCクラスタリングのSSD の 1 つに欠けていることに気付きました。
これで、1つの正常な (トラブルのない)動作が実現するはずです。そう願っています。
PCクラスタリングシステムですべてがうまくいくことを期待しています。pomodoroは非常にゆっくりと進んでいます。
SSD 用のヒートシンクが到着したと聞いです。PCクラスタリングプロジェクトは、たとえ遅いとしても、進んでいるです。
ヒートシンクなどのすべてのコンポーネントが所定の位置にあることを確認することは、スムーズな操作に不可欠です。
あなたの粘り強さが報われ、すぐに完全に機能するシステムが完成するでしょう。
ケーブルの整理と配線は、時間がかかり、イライラすることが多い作業です。適切なケーブル管理は、エアフローを維持し、乱雑さを減らし、
将来のアップグレードやメンテナンスを容易にするために不可欠です。ケーブルをきちんと配線して固定するには、計画、忍耐、
そして多くの場合は創造的な問題解決が必要です。ハードウェアを組み立てた後、オペレーティングシステム、ドライバー、必要なソフトウェアを
インストールする必要があります。これは、特に互換性の問題がある場合や問題のトラブルシューティングが必要な場合は、
長いプロセスになる可能性があります。すべてのドライバーが最新で正しくインストールされていることを確認することは、
システムをスムーズに操作するために不可欠です。PC が過熱しないように十分な冷却を備えていることを確認することが重要です。
これには、適切な冷却ソリューション (ファン、ヒートシンク、液体クーラーなど) を選択してインストールし、ケース内のエアフローを最適化することが含まれます。
ノイズレベルと冷却効率のバランスを取ることも、特に高性能ビルドでは難しい場合があります。効果的なケーブル管理は、
ビルドの美観を向上させるだけでなく、エアフローを強化し、将来のメンテナンスを容易にします。ケーブルの接続を開始する前に、
コンポーネントのレイアウトと各ケーブルの経路を計画します。これにより、ケーブルの乱雑さを最小限に抑え、すべてが目的地に届くようになります。
ケーブルタイや結束バンドは、ケーブルを束ねて固定するために不可欠です。ケーブルを整理し、空気の流れを妨げないようにするのに役立ちます。
ベルクロストラップも再利用可能で調整が簡単なため、良い選択肢です。最近のケースのほとんどには、マザーボードトレイの後ろに
ケーブルを配線するためのスペースがあります。このスペースを使用してケーブルを隠して整理し、メインコンパートメント内をすっきりと見せます。
多くのPC ケースには、グロメット、タイダウンポイント、ケーブルチャネルなどのケーブル管理機能が組み込まれています。これらの機能を活用して、
ケーブルをきちんと整理。標準ケーブルは長すぎて、不必要な乱雑さを生み出す可能性があります。カスタム長さのケーブルやモジュラー電源ケーブルを
使用すると、余分なケーブル長を減らし、配線を容易にすることができます。ケーブルにラベルを付けると、将来のアップグレードや問題のトラブルシューティングを
行うときに時間とストレスを節約できます。粘着ラベルまたは色分けされたテープを使用して、各ケーブルを識別できます。ケーブルを固定することは重要ですが、
締めすぎるとケーブルやコネクタが損傷する可能性があるため、締めすぎない。移動や調整ができるように少し余裕を持たせ。
ケーブル管理を定期的にチェックして調整し、すべてが整理された状態を保つ。ほこりや振動により、時間の経過とともに
あなたが直面している課題を考えると、これは良い戦略のように思えます。ここで考えてみましょう。
PCクラスターを作成して使用率を最大化することは、特にひとの参加が変動する場合に優れたアプローチです。PC をクラスター化すると、リソースの割り当てが合理化され、各マシンが効果的に使用されるようになります。このセットアップをさらに強化するには、次の手順を検討してください。
Kubernetes、OpenStack、カスタムジョブスケジューリングシステムなどのクラスタリングソリューションを使用します。これにより、リソースをプールし、優先度と需要に基づいてワークロードを分散できます。
ジョブの優先順位の実装は、HTCondor や Slurm などのツールを使用して実現できます。これらのツールは、ジョブキューを管理し、リソースを効率的に割り当て、上級に高い優先順位を与えるのに役立ちます。
リソースの使用状況を監視し、クラスターのスケールアップまたはスケールダウンに備えてください。監視用の Prometheus や視覚化用の Grafana などのツールは非常に役立ちます。
明確なドキュメントとサポートを提供します。これには、開始して生産性を維持できるようにするためのステップバイステップのガイド、FAQ、トラブルシューティングのヒントが含まれます。
個々の課題とプールされたリソースシステムのバランスをとることで、消極的なひとの影響を軽減し、リソースを有効に活用できます。
１人に１台って感じでPC与えると、もし誰かがメンヘラちゃんだったら
生に限らず、上級でもそういうのはいる。というかこっちのダメージの方がでかいです。
いちおうレクーあってそのときに数週間履修者がつかうかもしれない
毎年、１０人近くいた履修者も翌週には２，３人になり、次は１人になり
そして誰もいなくなる。それにしても数週間は彼らにマシンをあてがう必要があるのです
とかいろいろ考えるとクラスタ化するしかないでしょろ。うまくいくかどうかわからないし
いろいろと時間も労力もかかりそうだが（それは実験設備をつくるのも一緒だけど）
やるしかないですか
いまの季節は一番人が少ないので、彼らには１台ずつあてがっておいてその他のマシンは
すべてクラスタ化しましょ。それがうまくいけば彼らからもとりあげて、巨大クラスタ化しましょ
ジョブの優先権とかアプリ側で設定できるのなら生は高めにしてゴム有は低め（ ＾ω＾）・・・
高次元データ空間の幾何学的構造は、情報科学におけるテーマであり、非線形性、トポロジー、リーマン多様体などの数学的概念を必要とする。
このような多様体は、局所的には線形空間として振る舞うが、全体としては非線形構造を持つ。
例えば、データがN次元ユークリッド空間に埋め込まれている場合、その埋め込みは必ずしもユークリッド距離に基づくものではなく、リーマン計量を用いた距離関数が適用されることが多い。
このアプローチは、確率分布のパラメータ空間をリーマン多様体として扱うことで、統計的推定や機械学習アルゴリズムの設計に新たな視点を提供する。
リーマン多様体上の最適化問題を扱う際には、フィッシャー情報行列が重要な役割を果たす。
フィッシャー情報行列は、パラメータ空間内の点での曲率を測定し、その逆行列は最適化アルゴリズムにおける収束速度に影響を与える。
具体的には、フィッシャー情報行列の固有値分解を通じて、多様体上の最適化問題における局所的な最適解の安定性や収束性を評価することが可能となる。
トポロジカルデータ解析は、高次元データの幾何学的構造を理解するための強力な手法である。
特に、持続的ホモロジーやベッチ数といったトポロジーの概念を用いることで、高次元空間内でのデータポイント間の関係性を捉えることができる。
持続的ホモロジーは、データセットが持つトポロジカル特徴を抽出し、その変化を追跡する手法であり、多様体の形状や穴の数などを定量化することが可能である。
これは、異なるスケールでデータを観察しても同じトポロジカル特徴が得られることを意味する。
具体的には、フィルタリング手法（例：距離行列やk近傍グラフ）を用いてデータポイント間の関係性を構築し、その後持続的ホモロジーを計算することで、高次元空間内でのデータ構造を明らかにする。
ユークリッド距離だけでなく、マンハッタン距離やコサイン類似度など、多様な距離関数が存在し、それぞれ異なる幾何学的特性を反映する。
特に、高次元空間における距離関数の選択は、クラスタリングアルゴリズムや分類器の性能に直結するため、その理論的根拠と実用的応用について深く考察する必要がある。
さらに進んだアプローチとして、構造化された距離関数（例：Mahalanobis距離）やカーネル法による非線形変換が挙げられる。
これらは、高次元空間内でのデータポイント間の関係性をより正確に捉えるために設計されており、多様体学習やカーネル主成分分析（KPCA）などで活用されている。
正確に言うとプライベートモードにしたただけで、使うのはやめていない。
誰にも読まれることのないコメントを、いかにも☆が付くことを狙って書いてしまう自分に驚いているが、さすがに一時的な状態だと思う。
距離を置いてみるとブクマカたちの異常性が良く分かる。Twitterのようにクラスタ分けがされるわけでもない、表舞台しか存在しないプラットフォームが、よくぞこんな長い期間維持されてきたものだ。
普通にブレイクしたWebサービスなら、ユーザ数の桁が増えてクラスタリングなしでは使いものにならなくなっていただろう。といって閑古鳥というわけでもない、中途半端な状態を延々長引かせている。変なサービスだ。いくら計算機コストが低くともサポートコストで赤が出そうなものだが。
このまま卒業できると良いんだが……
でっかい倉庫を作るときに奥の方に原木とか石を置くと行くのが面倒になって手前の適当なチェストに入れてしまう
そのためにまず「よく使う物は何か」をしっかり考える
自分はこのワールドで何を目標としているのかを整理して一番使い物、使いたい物は何かを決めて手前に置く
例えばネザライトインゴットはとても貴重だけど別に普段使うことはほぼ無いので奥の方に飾っておけば良い
現実世界でも自分がよく使う物を洗い出すことが収納の第一歩になる
チェスト・ラージチェスト・樽・シュルカーボックスを量に応じて適切に使い分ける
「場所があるから」とラージチェストを作りがちだけれど、スタック出来る物を入れる場合はほとんどの場合がスモールチェスト・樽で十分
下手にラージチェストを作ると「ちょっと一時的に」という感じで別の物を収納しがち
収納する物に対して大きすぎる容器を作らない、ということが大切
大は小を兼ねるが適切では無い
一種類でチェストが必要なブロックは専用チェストを決めて収納すればいいんだけど
「これ、1個か2個しかないんだよな」というものに対してチェストを作るのはもったいないし無駄なのでまとめてチェストに収納する
このときに明確なルールを決めて、「ちょっと不便だな」と思ってもそれを遵守する
「オークとしてまとめて収納する」
のどちらにするかを明確に決める
ルールを決めたらその通りに必ず収納して例外を作らないことで荷物が散らばることを防ぐ
例えばエメラルドは交易以外で使わないので交易付近に置いておく
エメラルドがチェストに入りきらない、ということはほとんど無くて
使う場所の近くに収納を置くことで使う時に困らないだけではなく
使い終わったときに忘れず片付けられるようになる
というようなクラスタリングはするとして
それより前述したよく使うかどうかを基準にするか、もしくは適当にさっさと決める
過度なクラスタリングを始めるとクラスタリングすることに時間と労力をかけてしまって
結果、疲労して「なんでもとりあえず入れとくやつ」を作ってそこに全部ぶち込むことになる
自動仕分け装置を作ったり、ポーション生成機を作ったりすると収納が楽になる場合があるが
作る労力の方が圧倒的に大変なので基本的に導入しなくて良い
もちろん作ることそのものがマイクラの楽しみ方なのでそれはそれでいいのだが
2，3周目に突入すると「結局使わないしな」となるので作らなくて良い
それよりも見た目や使いやすさを重視した方が良い
現実世界でいうところの「自動で開閉するゴミ箱」「電動昇降チェスト」なんかがそれにあたる
土ブロック、深層岩、ネザーラックとかはある程度ストックしたら綺麗さっぱり捨てるとして
例えばどうでもいい花とか種とか余ったハーフブロックとかはいっそのこと全部捨てるというルールにしておく
木材系のブロックは燃料になるので自動かまどにぶち込むというのもあり
「今は使わないけど、いつか使うかも」
ではなく
「今は使わないし、いざとなったら手に入る」
という考えで潔く捨てる
そのための便利ゴミ箱を作っておくと良い
実際にはマイクラほど上手く行かない
ただ
「マイクラだったらどうするかな」
と考えることでそこそこ収納は上手になった
人はなぜワクチン反対派になるのか ―コロナ禍におけるワクチンツイートの分析―
https://www.t.u-tokyo.ac.jp/press/pr2024-02-05-001
〈研究の内容〉
本研究はまず、2021年1月から12月までに収集された「ワクチン」を含む約1億件のツイートを収集し、機械学習を用いて「ワクチン賛成ツイート」「ワクチン政策批判ツイート」「ワクチン反対ツイート」の3クラスタを抽出した。次に、「ワクチン反対ツイート」を多くつぶやいたりリツイートしているアカウントを特定し、「ワクチン反対ツイート拡散アカウント」として定義した。そして、「ワクチン反対ツイート拡散アカウント」を多くフォローしているユーザを「ワクチン反対派」として定義した。
上記プレスリリースの中で「賛成」というワードは4回しか使われておらず、そのいずれにも「賛成派」の定義を示す文というものは存在しない。
幸いにも元論文がPublicで公開されているため、主にMethod項を見てまとめていきたい。
1. 「ワクチン」「vaccine」を含む日本語ツイート98,805,971個を取得する。
3.ツイートのクラスタリングを行い、20種のクラスターが作成される。
4. 上位3つ(検証ツイートの99%・リツイートの98%を占める)のクラスター(「ワクチン賛成ツイート;pro-vaccinetweets」「ワクチン政策批判ツイート;opposition to the government’s vaccine policy」「ワクチン反対ツイート;anti-vaccinetweets」)を検討する。
5.上記3クラスターのツイートを行ったアカウントとRTしたアカウントを集計する(「ワクチン賛成ツイート拡散アカウント:1,382,065」「政府批判拡散アカウント:248,699」「ワクチン反対ツイート拡散アカウント:196,936」)。
6.上記3種のアカウントからそれぞれ50,000アカウントずつ無作為に抽出し、フォロー中のワクチン反対ツイート拡散アカウントの割合を算出する。
7. "ワクチン反対ツイート拡散アカウント/総フォローアカウント"の割合でソートし、上位25%(全体の12.3%以上)を"High anti-vaccinegroup"、下位25%(全体の0.24%未満)を"Low anti-vaccinegroup"とする。
ということで増田冒頭の「フォローアカウントのうち、ワクチン反対ツイートをした/RTしたアカウントの割合が少ないアカウント」ということになる。
これを「賛成派」という言葉で表現するのは実態を表しているようにはみえない。
しかし、元論文においてはこのような表現がほぼされていないといっていい。
基本的に日本語プレスリリースにおける「反対派」「賛成派」は上記メソッドで出たHighgroup/Lowgroupとして表現されている。「反ワクチン性が高いグループ」「反ワクチン性が低いグループ」といったところ。
ただ、「ワクチン反対派」に類するフレーズは度々使われている(元からしてHigh/Lowanti-vaccinegroupだし)。
一方のLowgroupでは、anti-vaccineに対してpro-vaccineという表現が使われている。が、ほぼ全ての用法で発言・ツイートに対してのみ使われており人に対して使われるケースは殆どない(イントロダクションに一回だけある)。
論文では誤解がないような表現にしているにも関わらずプレスリリースで「賛成派」という適切にはみえない表現を使うのはミスリーディングと言われても仕方ないのではないかと感じる。
Toriumi, F., Sakaki, T., Kobayashi, T.et al. Anti-vaccinerabbithole leads to political representation: thecase ofTwitter inJapan. J ComputSocSc (2024).https://doi.org/10.1007/s42001-023-00241-8
Permalink |記事への反応(10) | 19:39
本質を表しておらず、歴史上のとある議会の座席位置を参照する名称だ。コードレビューでこんな変数名でてきたとしたら修正されるだろ。
だって今、右翼が韓国発宗教が国家中枢に絡みついてるのを有耶無耶にしてて、左翼が激しく糾弾してんだぞ。意味わからんだろ。
ちょっと前まで右翼が「韓国とかありえん」って怒って、左翼が「韓国を差別するな」って怒ってなかったか？
やはり政治的なポジションってのは表で示されるべきだな。列名が「賛成、反対」で行に各政治的トピックが並んでるやつ。
それをもとにクラスタリングしたら右翼的な固まりだったりはあるんだろうけど。
ただ、クラスタリングする意味は薄いと思う。自分は右派だというアイデンティティや帰属意識を持ってしまうと、元々持ってた論理が破綻したり、意見の多様性が失われたりしそうだから良くないね。
その辺の指摘が正しいのではないかと思うんだけど
そもそもはJavaで分散オブジェクト指向が流行したのが問題の歴史的な発端だと思ってる
つまり、RMI（いわゆるRPC）とかCORBA（それは紛れもなくヤツさではないです）とかHORB（産総研だっけ？）とか、
ネットワーク透過だのRPCのスケルトンだの、そういう話が発端な気がする
つまり、インターネット上ではマシンは当然ネットワークで繋がってはいるけど、
マシンAのJavaのプロセスがマシンB上のJavaのクラスを読み込んで実行できたり、
マシンBに肩代わりさせても、それを意識しないように書けると便利だよね、
という話であって、
ぶっちゃけ、今になっても、
世の中的に、今はJavaよりイケてると思われてる言語にも、この手のネットワーク透過にする機能とか、
よー知らんけど、クラウドコンピューティング（）だなんだの機能としてあっても不思議ではない気がする
昔で言うなら、ソニーのTelescriptとかよー知らんけど、
ネットワーク上の複数のマシンを渡り歩くプロセスというかプログラムみたいなのが実現できるのって、
今になって考えてみると脆弱性の温床でしかない気がするし、理解はできる
理解はできるが、じゃあ、まったくメリットがないのかというとそうでもなくて、
しかし、Javaのかつての流行が放置されたままになってるとか、そういう問題はあるわけで、
その辺がセブン＆アイだったかの、Struts2のOGNLインジェクションもそんな感じで、
ぶっちゃけ、マシンAからHTTPでマシンBのJavaクラスとか実行できたら便利だよね、みたいな話で、
マシンAとマシンBが外のネットワークと敷居があるという前提があるから問題がないのであって、
CGIでもよくあったけど、サーバー側の任意のコマンドを実行できるというのは、
サーバーの状態を監視するとかには便利だけど、当たり前だけど危険だよね、という話であって
眠くてまとまらない…
おやすみ…
あ、言い忘れるところだった
知らんけど
