  |
はてなキーワード: MAXとは
どうせ買うならフル装備でいきたいよな
とりあえず予算まとめるか
・iPhone 16 Pro Max（1TB）……249,800円
・AppleCare+（盗難・紛失プラン）……34,800円
・MagSafe充電器……6,800円
・Belkin 3-in-1 MagSafe充電スタンド（iPhone・Apple Watch・AirPods用）……19,800円
・モバイルバッテリー（MagSafe対応・Anker製）……12,000円
・USB-C to USB-Cケーブル（2m）……4,500円
・AirPods Max（スペースブラック）……84,800円
・MagSafe対応レザーケース（高級モデル）……12,800円
・Spigen製耐衝撃ケース（アウトドア用）……7,000円
・iCloud+（12TBプラン・月額9,000円×12ヶ月）……108,000円
・Apple One（月額1,200円×12ヶ月）……14,400円
・Apple Watch Ultra 2……128,800円
・Apple Vision Pro（iPhoneとの相性最高らしい）……599,800円
・AirTag（4個セット・カバンや財布に入れる）……14,800円
・Apple信者になるためのセミナー参加費……30,000円
👉 1,397,800円
無理ゲーすぎる
俺はiPhoneを諦めた
Spotifyは不具合を直す気はないしチャットでの問い合わせの品質もクソだし、何よりユーザーにコストを掛けさせていることに対して決して謝罪をしない。ユーザー体験は最悪に不愉快。不具合は勿論解決しない
Spotifyをブラウザから再生したところ、1日の初回に必ず音量MAXで再生され始めるというかなり不愉快な不具合に数日悩まされる
検索しても、アプリ版ではここの設定をいじれというのは出てくるが、ブラウザからのケースについてはあまり情報なし（この点だけは近年のGoogleの悪化に原因を帰すべきかもしれない）
重い腰を上げてSpotifyのチャットサポートにアクセスする この時点ではよくある現象なのだからすぐに解決するだろうと思っていた
自動応答に何回も「アプリのキャッシュをクリアしたか」などの質問をされ「アプリじゃなくてデスクトップPCから起動してるブラウザです」と応答することを数回繰り返し、リアルタイムチャット応答の有人窓口に繋がる
まず「力になります」的な一見頼もしいことを言うが、決して「ご迷惑をお掛けしております」のような謝罪はしない まあ名前もカプリハンとか言ってるし文化が違うんだろう
近年の国際経済情勢においてプレゼンスを低下させ続ける国にしかネイティヴスピーカーがいない言語でリアルタイムチャットに応答してくれる時点でありがたいというものだ
しかし一応有人のはずなのに応答が噛み合わないこと甚だしく、UX的には機械の自動応答とそこまで違わない 噛み合わないせいでこれは生成AIによる応答ではないんだろうなとうっすら思う 翻訳にChatGPTは使ってるかもだが
噛み合わないというのは「会話のログを読んで文脈状況は把握した上で解決のために尽力するぜ！」っつって来てるのに、「アプリはAndroidですか？それともパソコン？」と聞いてくることなど
やり取りが少し進展したら「これは難しいのでチームに聞いてくる」とか言って5分待たせたり、「すみません」の一言もないまま担当者が変わったり、一応答しただけでまた次の担当者にたらい回しにされたりする
最初の一回目たらい回しくらいまでは「まあFAQにあるようなレベルではない多少レアな事象なのかもしれないが、より詳しい人に繋ぐことで解決の道を探ってるのだろう」と思えたが、徐々に白けてくる
なんでここまでみんな揃いも揃って無責任なんだよ ユーザーに謝ったらこのオペレータ職は賞与減額されるシステムか？
如何だろうか まず「1.違うインターネットを接続してみる。」（「インターネット“を”接続」、LLMではあり得ない非ネイティブの日本語ありがてえな）は私のデスクトップPCを違う回線に持っていって接続するという意味か？を聞いた
「そうです」という回答
手間が掛かりすぎるしそもそもPCを繋がせてくれるような適切な環境の当てが思いつかない 「この手順省略していいか？」って聞いたんだけど、まあ今思うと先方は直す手立てを考えているとかではなく、体の良いお引き取り口実を探していただけのように思える
「これらを全部試しても結局問題が解決しなかった時に、メール等で今回やり取りしたチャット情報を引き継いで問い合わせを継続することは可能か？」を聞く 正直絶対解決しない気がしていたので
「このチャットフォームを閉じなければ継続することができます」と言明。
「はい」
そうして、「1.違うインターネットを接続してみる。」「4.他のデバイスを試す.」以外のを全て実行して、Spotifyに再ログインした結果、音量を下げた設定は記憶されておらずMAXになっていたままだった
当たり前だが、チャットページにアクセスしても問い合わせのログには繋がらなかった 平気で嘘を付くのはモラルがヤバいのかそういうマニュアルがあったのかだけは気になってる
今はSpotify Premiumの退会を健闘しているところ Apple Musicが第一候補だけどYouTube Musicってどうなの
beautyaki
@j_sakkin
女性の表現を見て『やだ気持ち悪いやめてほしい』と違和感を持った女性が多く声を上げる。そこに女性ではない男性が『いや？違和感ない、ありだよね、過剰な反応だ』と言う。これの何の意味があるの？
ハナブサ ノブユキ
@Hanapan8723
まず私は、男性視点、女性視点という大きな主語の枠での話はしていないです。
beautyaki
@j_sakkin
そうじゃなくて。あなた男性でしょ？あなたの意見は男性視点よね？って話。
ハナブサ ノブユキ
@Hanapan8723
人に言っていいことと悪いことがある
情けないと言われようがいいわ
泣いたよ、悔しくて
そうじゃないと言ったところで「それはあなたが男性だから」で返され燃やされる
自分の加害はまったく気にしていない
r.max
@rmaxxxxxxxxx
MovieFan
@MovieFa35317289
MovieFan
@MovieFa35317289
kaori matui
@KaoriMatui
とにかくヤらせろ草
とかも来るよ。
riri
@vivid13839015
これはそう。
@ItUFhxx4Cx2060
本当に男羨ましい🥹🥹🥹🥹🥹
『ちびうさ』のベンチプレス、スクワット、デッドリフトのMAXを教えて頂けないでしょうか？
了解しました！『ちびうさ』を「美少女戦士セーラームーン」のキャラクター、ちびうさ（セーラーちびムーン）として仮定し、彼女のベンチプレス、スクワット、デッドリフトのMAX重量を楽しく推測してみますね。ちびうさは小柄で華奢な外見ですが、セーラー戦士としての超人的な力を持っていると仮定すると、見た目以上のパワーを発揮できるかもしれません。
仮定の設定
年齢と体格: ちびうさは見た目が小学生くらい（約6～10歳程度）ですが、実際は未来から来た900歳以上の存在。体重はアニメ的な軽さで約20～30kgと仮定。
セーラー戦士の力: 通常の人間を超える筋力を持つが、メイン戦士（セーラームーンやセーラーマーズなど）ほどではない中級レベル。
トレーニング経験: 未来のクリスタルトーキョーで多少の戦闘訓練を受けていると想定。
推測MAX重量
小柄な体格を考慮しつつ、セーラー戦士の力を加味すると、約50～70kgくらいが妥当かなと思います。通常の小学生女子の数倍の力を持ちつつも、重いバーベルを安定させる技術は少し未熟と仮定。
下半身の力は戦士としての跳躍力や敏捷性に繋がるので、少し高めに設定。約80～100kgくらいはいけるかもしれません。ピンクの髪を揺らしながら軽快にしゃがみ込む姿が目に浮かびますね！
背筋力と全身の協調性が求められる種目。ちびうさの華奢な見た目とは裏腹に、セーラーパワーで約90～120kgくらいを持ち上げられそう。未来のプリンセスとしての意地を見せそうです。
ベンチプレス: 50～70kg
もちろん、これは完全に私の想像に基づく仮説です！ちびうさがジムで「月に代わってリフトよ！」と叫びながらバーベルを上げる姿を想像すると、ちょっと楽しいですね。もし別の仮定や条件を加えたい場合は、ぜひ教えてください！
以下の問題を徹底的に抽象数学を用いて定式化しなさい。また、具体的実装についても定式化しなさい。ただし、文献はarxiv等の信頼できる情報源のみを利用しなさい。
本報告では、ユーザー集合Uとアイテム集合Iからなる推薦システムを、圏論と行列代数の統合的枠組みで再構築する。特にarXiv論文[2][7]で提案されたSheaf4Recアーキテクチャと、古典的マトリックス分解手法[3][8]を統合した新しい定式化を提案する。実装戦略としてApache Spark[4]を活用した分散処理を採用し、理論的保証と計算効率の両立を実現する。
圏RecSysを次のように定義する：
各ユーザーu∈Uの行動履歴f(u)⊆Iは、圏論的データモデル[7]において層(sheaf)構造で表現される。具体的には：
各スコア関数g_j:2^I×I→ℝ^mは、層の断面(section)として定式化される：
g_j = \bigoplus_{i=1}^m \mathcal{F}_i \otimes \mathcal{G}_j
ここで$\mathcal{F}_i$はアイテムiの特徴層、$\mathcal{G}_j$はスコアタイプjの重み層[2]。
任意のS⊆T⊆Iに対して、層的接続写像δ:F(S)→F(T)が存在し、次を満たす：
\forall j, \|g_j(S) - δ(g_j(T))\| ≤ L_j \cdot d_H(S,T)
ユーザー-アイテム行列R∈ℝ^{|U|×m}を以下のように分解[3]：
R ≈ UΣV^T \quad (U∈ℝ^{|U|×r}, Σ∈ℝ^{r×r}, V∈ℝ^{m×r})
Apache Spark[4]を活用した分散計算フレームワーク：
from pyspark.mllib.recommendation import ALS model = ALS.trainImplicit( ratings=interactions, rank=100, iterations=10, lambda_=0.01, blocks=200 # 分散処理用ブロック数 )
g_1(u,i) = U_u \cdot V_i^T
g_2(u,i) = \text{SheafConv}(F(u), F(i); \Theta)
g_3(u,i) = \sum_{t∈T_{ui}} e^{-λ(t-t_0)}
h(Y)_i = \bigoplus_{j=1}^n w_{ij} \otimes y_{ij}
ここで⊕はmax-pooling、⊗はアダマール積[2]。重み行列W=(w_{ij})は以下の最適化問題で決定：
\min_W \sum_{u∈U} \|R(u) - h(G(u))\|_F^2 + λ\|W\|_*
val interactions = spark.read.parquet("hdfs://interactions") val model = new ALS() .setRank(100) .setBlocks(200) .run(interactions) val scores = model.userFeatures .join(itemFeatures) .map { case (u, (v_u, v_i)) => (u, dotProduct(v_u, v_i)) }
| 手法 | 時間計算量 | 空間計算量 |
| 集中処理[3] | O(m^3) | O(m^2) |
| 分散処理[4] | O(m^2/p) | O(m√p) |
| Sheaf4Rec[7] | O(m log m) | O(m) |
ここでpは並列度、mはアイテム数[4][7]。
ブロックSVDアルゴリズム[3]は、任意のε>0に対してO(log(1/ε))反復でε近似解を達成する。
証明の概略：
\|R - U^{(k)}Σ^{(k)}V^{(k)T}\|_F^2 ≤ (1 - 1/\text{cond}(R))^k \|R\|_F^2
\|h(Y) - h(Y')\| ≤ \sum_{j=1}^n L_j \|W_j\| \cdot \|y_j - y_j'\|
本論文では、圏論的構造と分散行列分解を統合した新しい推薦システムフレームワークを提案した。Sheaf4Rec[7]の層構造とSpark[4]の分散処理を組み合わせることで、精度と効率の両立を実現。今後の課題として、動的層構造の適応的更新や量子化による計算効率改善が挙げられる。
Citations:
[1] https://arxiv.org/html/2407.13699v1
[2] https://arxiv.org/html/2304.09097v3
[3] https://www.cs.toronto.edu/~mvolkovs/sigir2015_svd.pdf
[4] https://ics.uci.edu/~cs237/projects2020/4_reports.pdf
[5] https://arxiv.org/abs/2502.10050
[6] https://arxiv.org/pdf/2109.08794.pdf
睡眠=怠惰な時間だと思ってる節があって子供が産まれて、2、3時間下手したら1時間おきに夜中に起きて母乳あげなきゃ日が続いてるのに日中眠い時も常にくだらない理由で叩き起された
どんなに理由を説明しても全く理解せず、夕方ウトウトしてたら起こされ｢僕のご飯は？｣
昼間ウトウトしてたら｢○○(クッソどうでもいいこと)やっていい？｣
元々貧血気味で、母乳って血で作られるからただでさえ眠いのにお願いだから寝かせてって懇願しても常に話しかけて眠らせないようにするし、もう毎日眠くて眠くて仕方がなくて常にイライラMAXで、少しでも寝ようとすれば叩き起こされて、それで肝心の元旦那は子供が夜泣きしてもグースカ寝てて、そんな日が続いたせいで子供を車に乗せて運転してた時、フッと意識が切れて追突事故を起こしてしまった
幸い子供も向こうの相手も無事で、車もそこまで壊れはしなかったけど元旦那の｢居眠りなんてするなよ、子供に何かあったらどうすんだ｣って言われてこいつとやっていくのは無理だって悟った
離婚して7年経って、実の親の助けもたって子供も普通に育ってるのは救いか
結婚する前はそういう風には見えなかったんだけどな
バイク乗りってかっこいいよな
俺も弱者男性だし、趣味の一つとしてバイクを始めようと思ったわけよ
ジャケット（RS Taichi RSJ328 風速ジャケット） - 約10万円
パンツ（RS Taichi RSP032 シェルパンツ） - 約5万円
グローブ（Alpinestars SMX-2 AIR v2 Gloves） - 約1.5万円
ブーツ（Alpinestars SMX-1 R Boots） - 約3.5万円
遠征費（ツーリング宿泊＆食事代、年3回くらい） - 約20万円
冬用装備（電熱ウェアやグリップヒーター） - 約8万円
旅先の記録を動画に残したい
アクションカメラ（GoPro HERO12 Black + マウント類） - 約7万円
ドローン（DJI Air 3 + NDフィルター） - 約20万円
編集用PC（MacBook Pro M3 Max + Adobe Premiere Pro） - 約30万円
マイク＆インカム（SENA 50S + Rode Wireless GO II） - 約8万円
標準ズームレンズ（SONY FE 24-70mm F2.8 GM II） - 約20万円
望遠レンズ（SONY FE 70-200mm F2.8 GM OSS II） - 約30万円
単焦点レンズ（SONY FE 50mm F1.2 GM） - 約15万円
広角レンズ（SONY FE 16-35mm F2.8 GM II） - 約20万円
カメラバッグ＆三脚＆フィルター類（Lowepro ProTactic BP 450 AW II + Manfrotto Befree Advanced + Kenko フィルター類） - 約10万円
…高すぎるだろ
やっぱり俺には無理だった
俺はバイクを諦めた
ある会社が2つの製品（XとY）を2台の機械（AとB）を使って製造しています。Xの1単位を生産するには、機械Aで50分、機械Bで30分の処理時間が必要です。Yの1単位を生産するには、機械Aで24分、機械Bで33分の処理時間が必要です。
今週の始めの時点で、在庫にはX製品が30単位、Y製品が90単位あります。今週の機械Aの利用可能な処理時間は40時間、機械Bは35時間と予測されています。
今週のX製品の需要は75単位、Y製品の需要は95単位と予測されています。会社の方針は、週末時点でのXとY製品の在庫単位数の合計を最大化することです。
1: 今週、各製品をどれだけ製造するかを決定する問題を線形計画問題として定式化してください。
2: この線形計画問題をglpkを用いて解いてください。
決定変数:
最大化 Z = (x + 30 - 75) + (y + 90 - 95) = x + y - 50
制約条件:
1. 機械Aの処理時間制約: 50x + 24y ≤ 2400 (40時間 = 2400分)
2. 機械Bの処理時間制約: 30x + 33y ≤ 2100 (35時間 = 2100分)
3. X製品の需要制約: x ≥ 45 (需要75 - 在庫30 = 45)
4. Y製品の需要制約: y ≥ 5 (需要95 - 在庫90 = 5)
5. 非負制約: x ≥ 0, y ≥ 0
GLPKで解くために、以下のようなモデルファイル（例：model.mod）を作成します：
/* 決定変数 */ var x >= 45; var y >= 5; /* 目的関数 */ maximize Z: x + y - 50; /* 制約条件 */ s.t. machine_A: 50*x + 24*y <= 2400; s.t. machine_B: 30*x + 33*y <= 2100; end;
このモデルファイルを使用して、コマンドラインで以下のコマンドを実行します：
glpsol --model model.mod -o solution.txt
GLPKが問題を解いた結果は以下です。
Problem: model Rows: 3 Columns: 2 Non-zeros: 6 Status: OPTIMAL Objective: Z = 1.25 (MAXimum) No. Row name St Activity Lower bound Upper bound Marginal ------ ------------ -- ------------- ------------- ------------- ------------- 1 Z B 51.25 2 machine_A NU 2400 2400 0.0416667 3 machine_B B 1556.25 2100 No. Column name St Activity Lower bound Upper bound Marginal ------ ------------ -- ------------- ------------- ------------- ------------- 1 x NL 45 45 -1.08333 2 y B 6.25 5 Karush-Kuhn-Tucker optimality conditions: KKT.PE: max.abs.err = 4.55e-13 on row 2 max.rel.err = 9.47e-17 on row 2 High quality KKT.PB: max.abs.err = 0.00e+00 on row 0 max.rel.err = 0.00e+00 on row 0 High quality KKT.DE: max.abs.err = 0.00e+00 on column 0 max.rel.err = 0.00e+00 on column 0 High quality KKT.DB: max.abs.err = 0.00e+00 on row 0 max.rel.err = 0.00e+00 on row 0 High quality End of output
以下のような最適解が得られます：
Z = 1.25 (週末時点での余剰在庫数)
この結果から、会社は今週、X製品を45単位、Y製品を6.25単位製造するべきであることがわかります。これにより、週末時点での余剰在庫数は1.25単位となり、最大化されます。